On 2013-04-07 04:30, Julian Brooks wrote:
Hey Martin / list,
This is all marvellous news.
Going a bit slower at our end, not helped by Easter holidays, trips to the seaside (bit chilly) and the plethora of children that require our undivided attention.
ebay parts arrived today and don't fit which is annoying to say the least. Spent several hours tracking down the correct housings and pins and then finding somewhere in the U.K. that would sell me less than a hundred housings or a thousand pins. Ended up with 5 and a 100 respectively.
Also got a voltage transformer that works with i2c as the rpi is 3.5v and sensors 5v.
Am planning on blogging all the info when done but if anyone wants any specifics before then please say.
I'm slowly making some headway with getting my head around the gpio pins and setting those up to use with Miller's [gpio]. I can now access the i2c pins via [gpio] and send them 1 or 0 setting the pins hi and lo which is a start.
Also found where to set the baud rate from within the RPi which will be useful. Although the sensor mentions 1000k as baud rate I'm thinking that 9600 would be better for overhead reasons. Perhaps we should get it working as is before starting to change too many settings?
I2c is a synchronous serial protocol. The clock is transmitted on a separate wire. Usually it runs a lot faster than asynchronous serial. I set the frequency in the Arduino to 800kHz but the sensor was working at 1MHz as well. You control the sample rate by requesting sensor packets at the rate you want. (Or you could bit-bang the gpio pins to get the data manually, but that's very slow) There is a package named i2c-tools that ought to be available for rpi. It has commands like i2cdetect and i2cdump that should detect and read the sensor.
Still absolutely no idea how to setup sending and receiving 16b messages plus how to add in the delay but we /will/ get there in the end.
I have my pi now so I can get into that as soon as I have time.
"You write the value 0x4C (76) to address 7 and then request 32 (35) bytes, which are 16 little-endian integers."
Any ideas how we would go about formulating messages for this from within Pd?
Should we be looking at [comport] at all?
No. Somehow you need to access the i2c device, probably the same way you access gpio pins, by writing to pseudofiles somewhere in the system.
I've found this to be the most informative info for the d6t so far: http://media.digikey.com/pdf/Data%20Sheets/Omron%20PDFs/D6T44L_8L_Appl_Note....
With my limited understanding it seems to be saying it's big-endian (msb first, p.4) ?
We have 2 sensors so we need to figure out how to set the 7bit addresses. Also that the data bit width is 8 - so I'm confused as to what the 35 bytes are and where they come from?
It's a list of bigendian values followed by an error correction code. The first pixel is a reference, usually reads about 24 degrees, the next 16 are the image. The error code is a crc-8. I haven't been able to get the right number for the crc yet, probably because it's calculated on bits not bytes and the 12c protocol inserts bits between the bytes for ACK and NACK (?). From a terminal you should be able to detect it with "i2cdetect" and read it with "i2cdump 1 7 35".
Martin