We Keep Coding

Possible to modify mini controller/micro controller code on store product?

My girlfriend recently bought a product for her skin, its basically a mask with lights on the inside that runs a power cord similar to an auxiliary cord into an auxiliary port on a mini controller. It is only good for 30 uses, every time you turn it on, an lcd screen counts down til it hits 0, then you have to buy a new controller.
I find it extremely wasteful to buy a new plastic controller after 30 uses. My question is it possible to somehow connect this device to my laptop through the aux port or aux port extension and modify the code written on it.
I work as a web developer by trade, so I am no stranger to code. I just need to know how to connect it, read the code and compile the code, etc, to modify the counter or remove it.
It is ЯU 94v-0 mini controller (Yes, the R is backwards)
Interestingly enough if I plug the mask into my iPhone or Mac, it will power one set of lights (there are two types/sets), but not the other.
Thanks in advance for the hackery advice.

I Have Better IDEA! Just buy new device (This device has an memory ATMLH436, which is basically same as AT24C02 eeprom chip), disconnect the WP pin and connect it only with the VCC pin, it then can't write the counter down (since it will be write protected), every time you pull the batteries out and in again, it will be as fresh as new. Should work like a charm :D
Here is the historical answer, maybe usefull to someone in the future:
How to hack instruction.
This device has an memory ATMLH436, which is basically same as AT24C02 eeprom chip, which is an EPROM with I2C interface, it is 2 KBytes memory. And the counter is most likely stored on this element.
You need to buy a new device, connect the not used eeprom to a i2c programator (you need to buy one, or ask a friend, I remeber this as a simple device connected to a rs232 port, but you can find one for usb), read the memory content and store it in a file and then you can use this file to reprogram the eprom to the original "new" state every time you want.
How to connect the i2c eeprom to mac:
hmmm, you need to have an i2c programator, that's first step.
Check the one you're about to buy if it has a Macintosh compatible software for reading/ writing.
If not, maybe use other computer.
remeber that in order to be able to program the device you need to connect the pin 7 (Write protect pin) to the ground. Here's the chip spec: http://www.atmel.com/Images/doc0180.pdf
Basically in oreder to communicate with the device you need:
know the address of the device - it is set by the A0,A1,and A2 pins connected either to ground or VCC - the programator soft will require that address.
connect the SDA, SCL and GND pins to the programator.
the chip need power supply of 5V connected beetween GND (-) and VCC (+) to operate.
In order to program the WP pin needs to be connected to GND.
There are big chances that: A0,A1,A2 and WP are grounded, but I can't be sure.
In case of this scenario the address of the device is 1010000 and there's nothing left that needs to be done in oreder to program it. I assume if the WP pin is not grounded you can disconnect it from whatever it is connected to and hardwire it to ground - should not affect normal operation of the device. probably you don't need to unsolder the chip in order to be able to read/write it, you need to connect GND, SDA, SCL and VCC. I would make a connector for these 4 pins to have it accessible from ouside of the device.
In order to make my life easier for many reprogram cycles, I would solder some connector to not have to disssassemble the device each time I need to reprogram it.
There are small chances that the counter is in the fat black round dot on the PCB, in which case there's nothing you can do to reset it since it is some custom chip without spec - if you have a great lab with X-RAY machine (like https://www.hawkerrichardson.com.au/electronic-production-systems/inspection-test-a-repair/unicomp-ax-8200) and other such stuff + lot of experience you could :) but rather not many people have such toys since they are very expensive :)
There are some pins to connect to the rounded chip, but I don't have any idea how to use them, what's the protocol or anything...
but if they could produce eprom inside of it, they wouldn't probably use any additional external eeprom because of the costs. But since eeprom production is not so easy as the regular chip, they use rather external memory from other supplier rather that producing one by themself - it's one logical argument that the counter is there in the AT24C02.

The correct way to hack this thing would be to listen to the I2C communication line with a scope. Note the exact binary sequence.
Then remove the external eeprom entirely and replace it with another MCU, which only has one task and that is to reply as the main MCU expects it to do. Though of course it never saves the down-counter.
Essentially you'd get this sequence each time you power up:
Main MCU: "Hello my eeprom, can I get the counter?"
Hack MCU: "Err yes I am totally an eeprom, the counter is 5."
Main MCU: "Store the counter value 6".
Hack MCU: "Roger that" (does nothing).
You'll get the same sequence over and over.
To succeed you need to know: microcontroller programming, I2C, basic electronics, soldering.

How to capture an Infrared signal pattern & frequency for later use?

I'm wanting to create an Android app that will send IR signals, but I don't know how to find the signal patterns or the frequencies from the original transmitter.
I purchased a small USB IR receiver (not Microsoft, but uses the Microsoft EHome drivers) and I can see the patterns from WinLIRC, but they are barely consistent, and trying to use any of them doesn't work on the receiver. I also am not sure what frequency to transmit on. I have my app sending back the signals and I can see them in LIRC, and they're accurate, but the receiver from the original remote doesn't respond to it.
How can I get the info from the original transmitter, accurately, without spending tons of money on something like an oscilloscope?

How should I manage Bluetooth connections in Android?

Q. What are your best practices in managing bluetooth connectivity?
I've read the android bluetooth guide & many bluetooth connectivity tutorials. Not helpful with encapsulation-design nor best practices.
When should I open/close the connection?
Is the "connection" with a single bluetooth device called a "socket" connection?
Can a single connection send data while listening? (...or between listening states).
I've never coded connectivity with external devices before. It took two weeks for me to wrap my head around the code that scans for near-by bluetooth devices and throw them into a ListView. Listeners, Broadcasts, and Adapters!
My project will be printing 1-40 receipts every 15 minutes on a bluetooth receipt printer. At the moment, security is not an issue. On the same connection, it will also be receiving data (sending & receiving simultaneously does not appear to be necessary but would be useful). I'm not yet sure how the devices are configured on this single dongle device but I would guess the devices are connected via USB controller to the dongle.
So far, I have 1 object to manage a single I/O connection. Staticly I open an activity to select a connection (to later save the label, mac, and pin in the database). Based on tutorials, I have "open", "listen", "send", and "close" methods. What confuses me is "how" to use these functions. Can I leave a connection open all day (10hrs) and use it every 3mins? Should I open/close the connection when sending or requesting data? Where would I detect the need to reconnect?

sorry for the short answer, but from my practice with the Bluetooth API, I have found that this video describe the things very good (totally personal opinion...)
Video 1
In addition this is useful when you do NOT have any previous experience
Tutorial
And as last check out this question in stackoverflow it has a bunch of good references and examples!!
Again sorry for the shortage, but I believe that if you check these out at least most of your questions and concerns will become answered!
:)
EDIT
So, let me be a bit more descriptive and share some of my experience.
I have written an App that communicates with BLE device that has 3 functions
double sided event driven button (push the button on phone -> event is fired to the device; push the button on the BLE device -> event is fired to the phone)
send request from phone -> BLE device answers with current battery percentage
continuously reading strength signal (as aprox. distance) between the phone and the BLE device
So far so good, now the things is that the basic approach is:
Search for BLE devices (bluetooth search or "discovery" of nearby bluetooth devices)
Here you will need android permissions!
Choose the device you want to connect to
To differ the devices (maybe there are a lot around you :) ) you can use BLE device's name or UUID or ... best - use the name ;)
After both devices connect to each other you can then start the Gatt communication. The approach with state machine is a little too much overkill for me. But anyway the communication is done through bytes (in my case...)
In one of the videos/resources there was something specific and VERY HELPFUL at least for me! To be honest I don't remember it exactly, but the idea was that before any communication it's RECOMMENDED to read/get all the options from the BLE device or something similar...
Maybe it was something like discoverOptions() or something like that
Great thing will be to know your device "communication codes" or at least I call them that way.
Check this link for example: Link
** Now you can see there are tables with the USEFUL INFO! E.g. if you want to read the battery level you navigate to this page and find that in order to read the battery, the service name is UUID XXXXX and you need to send 0x01 to the BLE device and it will "answer" to your call with some data which is again in bytes.
I really hope that this is somehow helpful!
PLEASE NOTE
This is strictly coming from my experience and there could be some mismatches or wrong terms, but that's how I personally see the things and because my project was long ago, I don't remember most of the things exactly.

IMPORTANT:
This is only a summery of STUCI's provided links above. He has since updated his answer and I have not updated/edited this summery. Topics in my summery are not explanatory but provided for reference and help in generating specific questions.
Original Post...
Thank you Stuci! Some of that was helpful:- some not. I thought it best to collect my thoughts and see what has been explained and if anything hasn't.
(I can't post this much in a comment tho, sorry)
PLEASE CALL ME ON ANYTHING THAT IS INCORRECT.
Video of Bluetooth LE
(Covers a bunch of random things)
While I "dont-like" videos of code:- I watched it because it was recommended ... and I am glad I did. While not very helpful it did introduce some concepts I was unaware of. Since I am targeting old android devices (v8+) the LE features are inconsequential.
Pushing Data: [Depending on the source feature-set], one does not need to continually pull data (ex. with a temperature sensor) but some devices can "push" it to the device on change. Seems to use the 'advertisement" design concept.
UUIDs define Services and/or Characteristics of the connected device.
Possibility to write configuration on (to) connected devices.
Characteristics which seem to be simply "settings" that can be assigned over bluetooth. Not sure if this (~19mins) applies to non-gatt connectoins but seems similar to the state-machine that controls
Advertisements which seem to be the "metadata" regarding the devices current state or config (~24mins). Again, not sure if this even applies to non LE Bluetooth.
Leaving Connections Open
Bluetooth connections can indeed remain open; starting at the point which the "startActivityForResult(...) method is successfully called.
Two basic things affect whether or not one would want to maintain an open connection:
Understand the power consumption.
Having the adapter active simply consumes additional power. If one can keep the adapter shut-off while it is not "absolutely-needed" will mearly save battery power.
Accidental disconnects are managed.
Other than leaving the connection continually connected, one could disconnect & reconnect regularly at specified intervals to ensure a connection is up.
In the thread(s) used for I/O, one could check for a disconnect and reconnect (possibly starting a new thread).
I/O Streams pr Connection
A single connection can indeed "have" simultaneous Input & Output streams. I
Since it was suggested, I re-read Android's Bluetooth Guide and under "managing a connection" (talking about a single socket) I noticed this...
Get the InputStream and OutputStream that handle transmissions through the socket, via getInputStream() and getOutputStream(), respectively.
Read and write data to the streams with read(byte[]) and write(byte[]).
...but continues with noting that read & write block each other. Something I still need to look further into. It seems like you cant I/O simultaneously on the same socket???
Max Connections
I also looked into the max connection issue Stuci added and found no documentation on the Android-side. It might exist, I cant find it. However, most people seem to agree that there is a limitation (that could be as low as 4) imposed by whatever hardware you are coding for.
Some notable links:
- How many devices we can pair via Bluetooth of BLE to Android?
- How many maximum device can we pair via Bluetooth to android device at a time?
- https://groups.google.com/forum/#!topic/android-developers/adeBD275u30

Settings for RS232 serial port communication

I am using this library for communicating with serial ports from Java. Also I am using USB to Serial converter to connect to the device.
Here is the documentation that is related to the device :
2.1 Physical Interface
The required physical interface between the host and the VGM is the EIA-232 interface.
2.2 Logical Interface
The serial data link shall operate at the speed of 19,200 bits per second (BPS), with one
start bit, eight data bits, a wake-up bit and one stop bit. The wake-up bit should be set in
the first byte of the message; the wake-up bit should be cleared for the remainder of the
message. The VGM shall clear the wake-up bit when responding to the host.
I am a little puzzled how to setup the rs232 library settings when connecting to the serial port. There are baud settings, data length in bits (5, 6, 7, 8), stop bits (1, 2) and parity setting. When I mess with these settings I of course get different output (most of the time looking like trash). Can you help me guess the settings with regards to the quoted documentation?

From what I understand your protocol requires an additional 9th data bit which is used in some exotic applications like Multidrop bus (see also Stackoverflow 14212660). In your case this 9th bit is called "wake-up bit", but you will not find such a thing or name in your java library or and standard RS232 application.
There is a workaround using standard USB to Serial converters. It is exactly what in Stackoverflow 14212660 is called
and no fudging by using the parity bit as a 9th data bit
So, unless you want to buy specialized hardware - I suggest the 'fudging':
Using the parity settings MARK and SPACE should correspond to your desired setting "wake up bit set", resp. "wake up bit cleared". Our software Docklight Scripting allows you in the free evaluation already to do this kind of temporary parity switching, but I assume there are also other tools or code examples around. MDB / multidrop bus should be good Google keywords for this.

CANopen PDOs using the serial port

I am trying to understand the CANopen protocol.
For now, I do not have any CAN hardware nor the CANopen stack to experiment with.
I would like to know how to write a Java program to simply interpret CANopen messages that are received at the RS-232 port.
Are there CAN interfaces that are installed as a serial port?
Will I be able to write a program to process CANopen messages? I want only to be able to receive and interpret messages. Is it as simple as creating a buffer for the input stream and then break up the transmission into separate messages according to the SOF and EOF? How do I know what is the SOF/EOF since it is only 1-bit long?
Why is there a limit on the number of PDOs of a CAN node?
How do I process the PDO to identify the node from which it is sent and the data type and value? Is the PDO a standard CAN frame?

I don't know of any CAN interface that connects to the serial port (it wouldn't be too hard to create one based on a microcontroller with CAN and serial ports). However, standard serial ports would be too slow to support the higher speeds available in CAN.
Generally, when using the API for a CAN interface, you will be able to read messages consisting of ID, Length and up to eight bytes of data. You don't need to care about SOF/EOF. Even if interfacing directly on the low level with a CAN controller (that is, if you have a CAN interface for which you need to write the driver/API yourself), you still don't need to care about those details. And you don't want to try to access the CAN bus without using a CAN controller at all...
If you want to pretend that you have a CAN interface, you may create a stub function which returns those three items: an ID, a data length and a 64-bit data buffer. This is basically what all CAN interface APIs will give you. And when transmitting CAN messages, you will use the same parameters (ID, length data).
PDOs are defined by their use of the CAN ID field. In theory the number of PDOs for a device is not really that limited, but the predefined connection set have only allocated a small number (four) of PDOs for each node.
The PDOs are standard CAN frames. As mentioned, the CAN ID identifies the PDO. In the predefined connection set (which most devices follow), the CAN ID of all messages consists of a functional part and a module-ID part (the module ID may be hard coded for the device, or configurable by dip switches for example). Bits 10-7 of the CAN ID is the function code and bit 6-0 is the module number. For example TxPDO1 from a device with module ID 0x10 would have CAN ID 0x190. The upper four bits of the 11-bit CAN ID, ((CAN_ID & 0x780) >> 7), gives you the function code (TxPDO1 = 3) and the rest of the bits,(CAN_ID & 0x7f), gives the module id (which in this example was 0x10). So if you read a message on the CAN bus with CAN ID 0x190, you would know that this was a PDO from the device with module ID 0x10.
(A simpler way to express this might be to say that TxPDO1 has CAN ID set to 0x180+<module ID>, TxPDO2 has CAN ID set to 0x280+<module ID>, etc.)
How you should interpret the data in the PDO depends on your device.
I suggest that you find a good CANopen tutorial. Unfortunately most of them make everything sound much more complicated than it really is. So look around until you find one that appears understandable.

There are many CAN interfaces that can run off a serial port - VSCOM, Vector, and many others. There are also free programs that allow you to send and receive raw CAN frames - CANhacker, etc. Google for a few of them.
What I haven't found is a free program that can do interpret CANopen - most are pay programs. The exception is Wireshark for Linux - it uses SocketCAN to pull in packets and can parse all the CANopen frames.
I run my CAN bus a 1 Mbit/s and use a VSCOM interface to monitor it on the serial port.
CANFestival is a good open source stack that ports easily to Linux as well as bare machines.