Omron D6T-8L on I2C

Hi everybody,

I am trying to get a Omron D6T (http://media.digikey.com/pdf/Data%20Sheets/Omron%20PDFs/D6T44L_8L_Appl_Note.pdf) sensor to talk to my Pi (and vice versa) and thought it would not be a big problem as I have another thermal sensor running over I2C (as of now, the D6T is on the bus exclusively). The intitial steps worked fine, and my sensor appears with its standard address (0x0a) when calling

Code: Select all

i2detect -y 1

So I went straight for my modified C++ program to read/write some data, only to get an errno #5 I/O error while writing.
I then went one step back and tried to send a packet from shell using

Code: Select all

i2cset -y 1 0x0a 0x00 0x4c

Which is stitched together from various sources of the net, to my belief, "-y 1" refers to /dev/i2c-1, where my sensor is connected, and where it also shows up (see above). Then I specify the sensor address on the bus (0x0a, this is the "unshifted" address), a target register (I really only guess zero here, as I can not recall reading about a specific register to write to) and the command, that I want to send (0x4c) to receive the readings back. Correct me if I'm wrong here.
So, in the end, if I try that, I get "Error: Write failed" again. I know, similar errors are covered all over the net, including here, but so far nothing really applied to my situation. After all, the sensor is listed in i2cdetect and I do only want to write one byte (0x4c), differing from the problem descriptions that I found.

So, my first ideas as to what I should do or think about:

The sensor has some very strange connector that I can not get my hands on in germany in the next few days with affordable effort (3$ worth connectors plus 18$ shipping is kind of the best offer) - so i just soldered my four wires to the pads of the connector, beeped everything through (no obvious shorts! Around 1kOhm between SCL/SDA and Ground, if I remember correctly) and connected it to the Pi. I guess that if the sensor shows up in i2cdetect and does not show up when not connected means that I broke nothing, right?

I was using the sensor powered with 5V from the GPIO pins and using the signal level of 3.3V - no problem with the other thermal sensor (TPA81), which is still working, and of course without any pull-ups to 5V. As I see a problem in that signal level, I included a Sparkfun converter (the two Tx parts) - the detection still works, the writing still doesn't. Will I need pull-ups to 5V on the sensor side now? I am not sure of that.

And this is where my wisdom is through - If anything of the above is obviously false, please let me know. If you have any additional ideas as to what to do, please tell me, too Should you have the same sensor and some code to read from it that works for you, please feel free to post it here

So, after some time I found the time to fiddle around with that again. Turns out that even though the I²C protocol works in that way, my "write" command does already seem to do all the address work for me, as long as I specify the 7-bit (unshifted) address first. A similar thing is also valid for i2cset, that needs to be called in this way:

Code: Select all

i2cset -y 1 0x0a 0x4c i

I.e. without a remote address to write to, and with the "i" in the end to specify I²C-data.

So, the next thing for me is: I want to use the sensor in the Robot Operating System ([url]ROS.org[/url]), where you can easily wirte a publisher that can send information obtained from a sensor like this. Of course, I want to read the sensor often, but at an update rate of 1Hz, I get "Bad File descriptor" Errors after a few minutes when opening the I²C bus - I want to open and close the bus with each reading as there could potentially be more sensors on the bus that may be read by other publishers. Having the bus constantly in use would then block the other nodes.

I noticed that I get a Filehandle with value "9" in the beginning, which is "11" when the bad file descriptor errors occur. Does anyone know if it is usual for the same hardware resource to be assigned different "addresses" (which is how I interpret the value of the filehandle) over time in Linux/Unix in general and Raspbian in specific?

Cheers, Jo

I Think, I'm going to freak out - the problem I got should be known by now, and as it is somehow connected to the "files" I'm using, I thought I'd check what's going on by using strace -e trace=open. So, in that environment, my code has now been running for some hours without an error. I don't get it...

Hello JoMu,

i´am working in the same sensor (D6T-44L indeed) Did you manage to get this sensor talk to the raspi? Could your read out some reliable data out of the sensor? Are there existing kernel modules?

Hey Sepp,
I did indeed manage to get this working, and it's running pretty reliable now. Sadly, I don't really recall what I changed to fix the problem stated here. But if you are using ROS, I could probably upload my running code here (or we can manage to exchange that in some other way).
Cheers

Okay, there you go.

I just fiddled around with my ROS packages a little so that now everything should be in that one package that I attached. I didn't test whether it compiles or not, but am pretty confident

If you are not using ROS, it might pose a certain hurdle to get used to how it works. Have a look at the website http://www.ros.org/ and especially on this compact how-to on installing ROS on the RPi http://wiki.ros.org/groovy/Installation/Raspbian. It takes a little while, but it's certainly faster than building it yourself.

As you have probably read in the D6T white paper (http://www.mouser.com/pdfdocs/D6T01_ThermalIRSensorWhitepaper.pdf), the sensors have one more output than there are pixels, so that the first (addtional) temperature reading refers to the sensor temperature. Thus, the 8L sensor has 9 measurements and the 44L one has 17.

If you are not using ROS, you will probably still find what you need in the code. The src folder should be pretty self-explanatory.

If there is any trouble, please let me know, I will then see what I can do.

Cheers

In the meantime i played around with some code i found here: http://lists.puredata.info/pipermail/pd-list/2013-04/102381.html
This works pretty well. In short: this is a server that reads data from D6T-8L or D6T-44L by i2c and can deliver them to a client as udp-packets. There´s also source-code for puredata that visualizes this data. This works as well, but i connected to the D6T-Server by an c# application and managed to visualize the sensor readings.
Thanks to JoMu for the source-code. That gave me some usefull hints.

Hey JoMu and DaSepp! I am also working with the same temperature sensor not with the Pi though. I am stuck in a few places but I think your discussions here helped. But as a general question, I wanted to understand how reliable are the temperature data collected from the sensor? Thanks in advance