I2C communication

[erico]

Hello respected members of this forum,
I have a project that requires reading of the saved blood glucose level measurements on a glucometer. The glucometer I am using for my my project has a USB cable and the stored glucose data could be downloaded on a PC with the glucometer software.
I am trying to tap into the stored data using Arduino Uno and all my effort have not been successful. I also open the inner circuit of the glucometer and I realised that it contain a I2C device (24128C) and microcontoller. The microcontroller (master) in the glucometer circuit is sending storing some data in the I2C device (slave) but I don't know how to hack into this data.
I will be glad and extremely grateful for your input in this project. Thanks for your anticipated response.
Best regards.

[Fungus]

With just an Arduino?

It's not easy, certainly not a case of messing around with the Wire library. You might be better off setting two pins to INPUT_NOPULLUP and decoding the bus in software instead of using the I2C interface. There's not much RAM so record just the pin state changes then decode it later. digitalRead() will be much too slow, you'll need to access the pins directly.

[erico]

Hello Fungus,
Thanks for support, it's much appreciated. I don't mind using any other means other than arduino, so if you have any other way I can read the data from the glucometer please help. And please can you please write a sample code I can use to acces  the INPUT_NOPULLUP pin directly without using the digitalRead() function.
Thanks for your anticipated response.
Best reagards

[EmmanuelFaure]

Arduino is fine. Hack your glucometer by desoldering the EEPROM. Then use the Arduino as an I2C slave. Collect the data. Done.

[Fungus]

Hello Fungus,
Thanks for support, it's much appreciated. I don't mind using any other means other than arduino, so if you have any other way I can read the data from the glucometer please help.

I'd connect it to my Rigol DS1054Z and set it to decode I2C but I don't know what you have available.

And please can you please write a sample code I can use to acces  the INPUT_NOPULLUP pin directly without using the digitalRead() function.

Google for "Arduino I2C sniffer", there's bound to be something.

[erico]

Hello EmanuelFaure,
Thanks so much for your input but is it possible to write code to make my arduino a slave has the datasheet of the master microcontroller is not released by the glucometer manufacturer.
Thanks for your anticipated response. Best regards

[KL27x]

You probably don't even need to desolder the EEPROM. It is easier to implement Master mode, anyhow. Put your Arduino on the I2C bus and away we go.

I don't see why you would not use an Arduino, if that's what you're confortable with. Just find I2C library for Arduino that isn't buggy as hell, and read the EEPROM as Master. Reading an EEPROM is probably the first, easiest thing you can do with I2C. You can find the EEPROM I2C address with a scope or LA. Or you can just look it up by part number/datasheet.

The only major snafu is if the master on the original circuit isn't implementing any multimaster standard of dealing with bus collision. And/or it may have some kind of watchdog/reset for dealing with unresponsive/busy EEPROM.  In which case, the glucometer might malfunction when you do this. Bets are it will be fine, and/or you can reset the device after you read off the data, periodically.

[erico]

Hello KL27X,
This forum is interesting and I really appreciate your support. Please do I have to declare my arduino as master and the EEPROM device as slave or vice versa?
Best regards

[KL27x]

An EEPROM is slave, already. It doesn't have any brain/reason to be a master. Look up the datasheet, if you can identify it. Or use LA to decode its slave address. That's about all you need to know about it.

As Master, your Arduino can read EEPROM whenever it wants. I2C is open drain data and clock line, so that multiple masters and slaves can share the same bus. If it's being used, any competent I2C code/library will have tools to deal with that. In your case, you can simply retry until your master gets control of the bus.

A glucometer.... I doubt it is going to be using up much bandwidth doing and recording thousands of readings per second... but who knows. You can figure that out with the software/docs it came with, what is the frequency of readings it does. There is likely 99% nothing going on at a given time on the I2C bus. Plenty of time for you to read the EEPROM without disrupting the original circuit.

If the device firmware is crap and this crashes/resets the firmware on the circuit's master, you can probably use a scope/LA to add some some trigger in your firmware to time your readings in this vast deadspace so the original master doesn't even know ur on the bus.

The OTHER way of doing it, which has already been suggested, is to make your Arduino take the place of the EEPROM. So your Arduino would have to record the data. This requires interrupt, because the master decides when it reads/writes. This makes it more complicated. But it is an option, if you require it.

If you buy an EEPROM and stick it in a breadboard, and connect it to your Arduino, you're halfway home. Learn to read this EEPROM. Write the data to Arduino's own EEPROM, so you can read it out on your programmer software (if you have a proper AVR programmer, anyway; I'm not sure if you can do this with an Arduino Sketchloader "programmer"). Then connect it to your glucometer and change the slave address which is called. Repeat. Verify you're reading EEPROM correctly. Modify as necessary to make it do what you want.

That said, there are many potential pitfalls. It will not necessarily be a cakewalk. But it might be. So best to address those problems if/when they arise. 7 bit vs 10 bit addressing, or whatnot. (if there's only 1 EEPROM on the bus, there's no reason it should be using a part with a 10 bit address, lol. Also maximum baud rate for the part in question... what happens when the other master detects the bus is busy when your Arduino is on it.. etc. But reading the EEPROM should probably be easy... EEPROMs tend to follow protocol, if the manufacturer wants to sell any and make a profit.)

[erico]

Hello KL27X,
Thanks for your motivating support. The device addressing of the EEPROM is given below according to the datasheet and I want to confirm if the address am choosing is right: Slave address = 1010000. The A2, A1, and A0 of the chip were not connected to anything.


Device Addressing
The Master initiates data transfer by creating a START
condition on the bus. The Master then broadcasts an 8?bit
serial Slave address. The first 4 bits of the Slave address are
set to 1010, for normal Read/Write operations (Figure 3).
The next 3 bits, A2, A1 and A0, select one of 8 possible Slave
devices and must match the state of the external address pins.
The last bit, R/W, specifies whether a Read (1) or Write (0)
operation is to be performed.

[KL27x]

Yeah, address 1010000X. PM replied.

[erico]

Hello respected members of this great platform,
I used a Saleae logic analyzer to read the data from my glucometer EEPROM component and the result aquired from the analyzer is colour coded below. The EEPROM device used in the glucometer is 24128C in case you want to lookup its datasheet online. I will grateful if someone could please explain the result has I am new in this field. I actually want to know the data that the microcontroller in the glucometer is sending to the EEPROM and the data that the EEPROM device is sending back.
Thanks so much for your anticipated response guys.
Best regrads.
Time , Analyzer Name, Decoded Protocol Result
0.000006875000000,I2C,Setup Write to [0xA0] + ACK
0.000068125000000,I2C,0x00 + ACK
0.000128416666667,I2C,0xFC + ACK
0.000203958333333,I2C,Setup Read to [0xA1] + ACK
0.000263750000000,I2C,0x02 + ACK
0.000321291666667,I2C,0x00 + NAK
0.000409208333333,I2C,Setup Write to [0xA0] + ACK
0.000470541666667,I2C,0x00 + ACK
0.000530833333333,I2C,0xFE + ACK
0.000606833333333,I2C,Setup Read to [0xA1] + ACK
0.000666666666667,I2C,0x02 + ACK
0.000724083333333,I2C,0x00 + NAK
0.000819041666667,I2C,Setup Write to [0xA0] + ACK
0.000880458333333,I2C,0x01 + ACK
0.000941333333333,I2C,0x08 + ACK
0.001014500000000,I2C,Setup Read to [0xA1] + ACK
0.001074291666667,I2C,0x0F + ACK
0.001132458333333,I2C,0x21 + ACK
0.001190125000000,I2C,0x11 + ACK
0.001247791666667,I2C,0x17 + NAK
0.001356666666667,I2C,Setup Write to [0xA0] + ACK
0.001418083333333,I2C,0x01 + ACK
0.001478916666667,I2C,0x0C + ACK
0.001552583333333,I2C,Setup Read to [0xA1] + ACK
0.001612375000000,I2C,0x6C + ACK
0.001670541666667,I2C,0x00 + ACK
0.001727708333333,I2C,0x06 + ACK
0.001785375000000,I2C,0x00 + NAK

[KL27x]

FYI, so far everything you have posted here is a READ, not a write.

The datasheet shows this EEPROM has 16kB of memory. And presumably this is a datalogging portable glucometer that logs readings over a long time period, while not connected to a computer? If this is NOT the case, the EEPROM could be storing god-knows-what. Arrays. Constants. Program memory (if the device was coded in BASIC STAMP, lol). Anything.

If the EEPROM is used to store readings, you will want to capture with your LA while
1. the device is actually writing to the EEPROM, not reading.
or
2. When the device is actually reading a bunch of data off the EEPROM at a time... such as while you connect it to a computer to display the data that was collected over time. This would likely be long strings of sequential reads.

Until you capture at least one WRITE, you don't even know if the device is storing any data on the EEPROM. It could just be preflashed data on there.

It is unlikely that what you have posted so far will provide any further insight, but maybe someone else has some better ideas.

If this is not some sort of data logging device, you might be barking up the wrong tree, entirely.

[erico]

Hello,
Thanks KL27X for your continuous support. The glucometer am using is the GlucoRx Nexus TD-4277 and I also don't mind using any other glucometer, all I need is to be able to access the glucose measurement. Thus, I am looking forward for ideas from the members.
Best regards

[KL27x]

In this case, it doesn't look like it's logging any data.

So....

Any chance the display has its own driver, and that it is ALSO on the I2C bus? (If it needs a 16kB EEPROM, then this isn't far-fetched, lol). If so, you can try to intercept the I2C to the display and decode that information to get your reading.

Of course the long but sure way would be to figure out where the ADC pin on the micro is and do your own ADC reading with your Arduino. And make a conversion table so that your results match w/e is shown on the screen. In many ways this would be easiest, for someone who has experience with coding. There is some sensor on the device, probably optical. And it connects to the micro somewhere, possibly with an opamp inbetween. (Or, this could be some epoxy blob/FPGA nonsense.) On second thought, if it takes that long to get a reading and it needs 16kB of EEPROM, the algorithm is probably pretty complicated... so yeah.. hacking the display is your best bet.

[erico]

Thanks KL27X, have also taught of hacking the data from the display since the glucose readings are shown on the display but I don't know how to go about it. Can you please give me tips on hacking the display.
Best regards

[EmmanuelFaure]

Record the image with a webcam and extract the displayed number by image processing. BTW Labview vision developpement module have a a feature for this. Click :

http://www.ni.com/example/30534/en/

[KL27x]

Depends...

If the display is driven by the main microprocessor, you're bunked. There are lots of I/O's needed to drive LCD. And tapping them all and decoding is not a job for me, even. Unless I have 6 months and a lot of motivation.

If it has a separate driver, you would have half a chance. But since it is a custom LCD, chances are not that good that it does. If it has a separate driver, you can identify there's another IC which is driving the display. Then you can take a crack at using LA to see what's being communicated between the main micro and the LCD driver. And if you record and correlate enough data comparing to what's on the display, you might crack that nut. But that's a tough one, too.

So.... video processing might be easier and faster... haha.

Good luck!

[KL27x]

•Large non-deletable Memory – 1000 readings stored with day averages, especially suitable for Diabetic drivers complying with DVLA guidelines (http://www.dft.gov.uk/dvla/medical/Annex%203%20changes%20to%20Diabetes%20update.aspx)

So it does store up to 1000 readings.
That doesn't mean it is necessarily storing them on the external EEPROM, but that is most likely... since it claims "nonerasable memory" and 1000 readings might take several thousand bytes... So you would still have to find out where, at what EEPROM location it starts storing these readings, and then decode to figure out how to convert it into required units. So getting data dump from PC link while hooked to LA should show you something.

When I clicked on the youtube link for your glucometer, youtube kept showing more and more related vids. Before I closed it, I heard a glucometer talking. So I had another dumb idea eneter my head.  Prerecorded voice will be stored on external EEPROM storage device. So if you get one of those, you might be able to determine which EEPROM location corresponds to each number, and then make algorithm to turn that into the reading. I'm sure this is totally not practical, but just in case you are determined.

[anfang]

With just an Arduino?

It's not easy, certainly not a case of messing around with the Wire library.

What is wrong with using the Wire library?

[erico]

Hello KL27X,
Thanks for your continuous and unrelenting support and I am sorry for the late response.  The results extracted from the LA while the glucometer is connected to the PC link is attached. I got this result on clicking download from the glucometer software on the PC while the LA was connected to the glucometer EEPROM.

Time , Analyzer Name, Decoded Protocol Result
0.000006916666667,I2C,Setup Write to [0xA0] + ACK
0.000068291666667,I2C,0x00 + ACK
0.000128666666667,I2C,0x00 + ACK
0.000201500000000,I2C,Setup Read to [0xA1] + ACK
0.000261416666667,I2C,0xFF + ACK
0.000320500000000,I2C,0xFF + NAK
0.165068291666667,I2C,Setup Write to [0xA0] + ACK
0.165129666666667,I2C,0x00 + ACK
0.165190083333333,I2C,0xFE + ACK
0.165266083333333,I2C,Setup Read to [0xA1] + ACK
0.165325875000000,I2C,0x02 + ACK
0.165383250000000,I2C,0x00 + NAK
0.165471291666667,I2C,Setup Write to [0xA0] + ACK
0.165532625000000,I2C,0x00 + ACK
0.165593041666667,I2C,0xFC + ACK
0.165668750000000,I2C,Setup Read to [0xA1] + ACK
0.165728583333333,I2C,0x02 + ACK
0.165785958333333,I2C,0x00 + NAK
0.290120916666667,I2C,Setup Write to [0xA0] + ACK
0.290182291666667,I2C,0x00 + ACK
0.290242708333333,I2C,0xFE + ACK
0.290318833333333,I2C,Setup Read to [0xA1] + ACK
0.290378666666667,I2C,0x02 + ACK
0.290436083333333,I2C,0x00 + NAK
0.290529416666667,I2C,Setup Write to [0xA0] + ACK
0.290590708333333,I2C,0x00 + ACK
0.290651125000000,I2C,0xFC + ACK
0.290726791666667,I2C,Setup Read to [0xA1] + ACK
0.290786708333333,I2C,0x02 + ACK
0.290844250000000,I2C,0x00 + NAK
0.290931958333333,I2C,Setup Write to [0xA0] + ACK
0.290993166666667,I2C,0x00 + ACK
0.291053416666667,I2C,0xFE + ACK
0.291129541666667,I2C,Setup Read to [0xA1] + ACK
0.291189458333333,I2C,0x02 + ACK
0.291247000000000,I2C,0x00 + NAK
0.291341958333333,I2C,Setup Write to [0xA0] + ACK
0.291403208333333,I2C,0x01 + ACK
0.291463916666667,I2C,0x10 + ACK
0.291537125000000,I2C,Setup Read to [0xA1] + ACK
0.291597041666667,I2C,0x10 + ACK
0.291654583333333,I2C,0x21 + ACK
0.291712375000000,I2C,0x03 + ACK
0.291770125000000,I2C,0x01 + NAK
0.291878041666667,I2C,Setup Write to [0xA0] + ACK
0.291939250000000,I2C,0x01 + ACK
0.292000000000000,I2C,0x14 + ACK
0.292073750000000,I2C,Setup Read to [0xA1] + ACK
0.292133708333333,I2C,0x6F + ACK
0.292192416666667,I2C,0x00 + ACK
0.292249750000000,I2C,0x06 + ACK
0.292307416666667,I2C,0x00 + NAK
0.321140791666667,I2C,Setup Write to [0xA0] + ACK
0.321202166666667,I2C,0x00 + ACK
0.321262541666667,I2C,0xFE + ACK
0.321338666666667,I2C,Setup Read to [0xA1] + ACK
0.321398458333333,I2C,0x02 + ACK
0.321455833333333,I2C,0x00 + NAK
0.321549208333333,I2C,Setup Write to [0xA0] + ACK
0.321610583333333,I2C,0x00 + ACK
0.321671000000000,I2C,0xFC + ACK
0.321746666666667,I2C,Setup Read to [0xA1] + ACK
0.321806583333333,I2C,0x02 + ACK
0.321864083333333,I2C,0x00 + NAK
0.321951708333333,I2C,Setup Write to [0xA0] + ACK
0.322012916666667,I2C,0x00 + ACK
0.322073291666667,I2C,0xFE + ACK
0.322149458333333,I2C,Setup Read to [0xA1] + ACK
0.322209375000000,I2C,0x02 + ACK
0.322266916666667,I2C,0x00 + NAK
0.322361708333333,I2C,Setup Write to [0xA0] + ACK
0.322422916666667,I2C,0x01 + ACK
0.322483666666667,I2C,0x10 + ACK
0.322556958333333,I2C,Setup Read to [0xA1] + ACK
0.322616875000000,I2C,0x10 + ACK
0.322674416666667,I2C,0x21 + ACK
0.322732208333333,I2C,0x03 + ACK
0.322789958333333,I2C,0x01 + NAK
0.322897875000000,I2C,Setup Write to [0xA0] + ACK
0.322959083333333,I2C,0x01 + ACK
0.323019833333333,I2C,0x14 + ACK
0.323093625000000,I2C,Setup Read to [0xA1] + ACK
0.323153583333333,I2C,0x6F + ACK
0.323212291666667,I2C,0x00 + ACK
0.323269583333333,I2C,0x06 + ACK
0.323327250000000,I2C,0x00 + NAK

[KL27x]

Well, it looks like you have several things here

There are like 3 consecutive readings of
0x02, 0x00
These are repeated once or twice. I bet this is some kind of setup/config. Dunno, really

And then there is an 8 byte string, starting at address 0x01, 0x10.... this actually looks like it might be something.
0x10, 0x21, 0x03, 0x01
0x6F, 0x00, 0x06, 0x00

I would start by trying to correlate this with the readings you got from the device. I would think there are more where this came from.
This is 8 bytes.... x 1000 recording would take up 8kb. Which is half the size of your EEPROM. I would guess this just might be one reading. Who knows?

Would hope if this is one reading, you could get 999 more, and not just this stuff you got repeating over and over.

Some of these bytes could be ASCII? might wanna print that out just in case.** But w/e, you gotta start with the software on the PC. What DATA VARIABLES* does it show 1000 of. And have matching set of data from the LA. More the merrier. You got (maybe) one reading here of 1000, and only one shoe of the pair. You have to figure out how the data is formatted, yourself.

*Glucose level... How many digits? What resolution? When you figure this out, you will know how many bits it takes for that part.
Datestamp? Timestamp? down to the minute? Down to the second?
Figure out what is being recorded and get some matching I2C readings and PC output to try to make some sense of it.

**LOL, probably not anything in ASCII. But... 8kB free..? mebbe.