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?
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.
"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?
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?
Obviously things should become clearer when we actually have the sensors connected and we can then see what they spit out (if anything) but it can't hurt to try and head off some of the more obvious questions I have now.
Like, will the data from the sensor appear at the outlet of [gpio]? The same author of *WiringPi* also has the i2c-library - would it be possible to fold this into [gpio]?
Questions questions...
Cheers,
Julian
On 30 March 2013 16:53, Martin Peach martin.peach@sympatico.ca wrote:
On 2013-03-27 18:31, Martin Peach wrote:
On 2013-03-27 17:17, Julian Brooks wrote:
Hey Martin,
Good to hear you've got one of these too.
Yes I meant [comport] with the xbee rather than [hid] sorry, getting my physical input objects confused.
Will check out the links you provided as part of my getting up to speed.
So, managed to get the sensors out of the cardboard box. They are tiny. Like little sci-fi robot eyes.
1st problem is that we don't have any of these: 'JST (Japan Solderless Terminals) - PHR-4 - Housing, 4way, 2mm
http://uk.farnell.com/jst-**japan-solderless-terminals/** phr-4/housing-4way-2mm/dp/**3616204http://uk.farnell.com/jst-japan-solderless-terminals/phr-4/housing-4way-2mm/dp/3616204
Which is a vital £0.04.6 of equipment as the sensors pins are way too tiny to be poking bits of wire into. These attach to the bottom of the board and then 2mm cabling attaches to them and out to the Pi.
Got some off ebay as farnell has a £20 minimum spend that's a bit over getting 10 of those suckers. So going to have to wait a few more days as I can't find any in my vicinity at all. Bollocks.
Yes I got mine at Digikey. You need the terminals as well as the housings. I crimped the terminals to some 28 gauge wire and also put a bit of solder but not too much to plug them up.
Today I managed to get data using an Arduino and the Wire library, with 4.7k pullup resistors on the clock and data lines. The packets are only 32 bytes, not 35 as the app note says. Not sure what's up with that.
I changed the default buffer size in Arduino's wire library from 32 and now I get 35 bytes as advertised. The crc calculation is not giving me the right answer but that doesn't seem to matter. I get 16 pixels of temperature, it's detecting warm as well as cold objects, quite a nifty sensor!
Martin