On 2013-04-23 04:42, Julian Brooks wrote:
Hey Martin / all,
Omron tech support finally got back to me re the address issue, this is what they had to say:
"D6T sensor can not change the address. When you connect multiple sensors we recommend that you use the IC switching. Please refer to the below document. http://media.digikey.com/pdf/Data%20Sheets/Omron%20PDFs/D6T44L_8L_Appl_Note.... "
I've been through the spec sheet several times and don't see anything (admittedly not sure exactly what I'm looking for though) that relates to IC switching.
Seems Digikey stopped selling the part, Mouser has it now (http://ca.mouser.com/ProductDetail/Omron/D6T-44L-06/?qs=%2fha2pyFaduiRuNG9v%...), and there's a document there that has something about using multiple sensors on one bus: http://www.mouser.com/catalog/specsheets/D6T-01_ThermalIRSensor-Whitepaper.p...
We've still got 2 of these doing nothing currently if they could be brought into action: http://adafruit.com/products/757
That will only convert levels, it's not a multiplexer. I found that the sensor works fine with the pullups to 3.3V on the RPi. Seems to me the easiest way to multiplex them would be to put a CD4051 on the clock line and use up to 3 GPIO pins to select which of up to 8 sensors receives the clock. The only tricky bit would be making sure the clock is at the right level when the switching tales place, you might need ~10k pullups to 3.3V on the sensor clock pins.
Or people on the RPi forum seem to have got the 2nd i2c pins going but that seems to be for rev.2 boards only (I think - have posted a question on the thread to ask).
Also asked tech support about the PEC errors but no response to that one.
I've noticed that the PEC doesn't trigger errors all the time so am wondering if it's possible to filter the errors out of the data somehow in the C file?
Yes that's what happens already. I was getting errors at first because the crc calculation was being done over both the write and read packets. I found that calculating only the read packet gives the correct value almost always. If the PEC is wrong, the code simply asks for another packet. At the moment I'm getting almost no errors.
Still delighted though - the sensors great!
Yes, it even works as an icecube detector!
Martin
Cheers,
Julian
On 22 April 2013 00:20, Julian Brooks <jbeezez@gmail.com mailto:jbeezez@gmail.com> wrote:
Wonder if it's a difference between rev boards on the Pi? I've also built a custom image based on Hexxeh's minimal install which is working great for audio stuff. My Pd patch that wouldn't run without overclocking on a standard Raspian is now working fine on the rev1 256mg board. So I've been adding stuff as and when it comes up to try and keep t is minimal as poss. I'm also not sure what installed libi2c-dev? Guess I'll have to wait and see what squeals. Of possible interest is this message when removing the lib with apt-get: The following packages will be REMOVED: libi2c-dev 0 upgraded, 0 newly installed, 1 to remove and 11 not upgraded. After this operation, 19.5 kB disk space will be freed. Do you want to continue [Y/n]? y (Reading database ... 33610 files and directories currently installed.) Removing libi2c-dev ... Removing 'diversion of /usr/include/linux/i2c-dev.h to /usr/include/linux/i2c-dev.h.kernel by libi2c-dev' So guess the diversion was messing with the compile for the C code. Anyway - code runs and I can compile C files too so all ok so far. Thanks again for everything Martin, Julian On 21 April 2013 06:45, Martin Peach <martin.peach@sympatico.ca <mailto:martin.peach@sympatico.ca>> wrote: On 2013-04-20 21:09, Julian Brooks wrote: Oh and btw Still don't know why I can't compile the .c files on the pi with libi2c-dev installed but I can't. Presuming the compiling is working for you Martin? Yes it works for me. I don't have the same /usr/include/linux/i2c-dev.h as you so no redefinition errors, not sure which package(s) install that file. Martin