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.pdf
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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
