Hi all,
We've been after some sensors for motion detection on the RPi and Martin Peach spotted these (thanks again Martin!)
http://uk.farnell.com/omron-electronic-components/d6t-44l-06/sensor-thermal-...
They're fairly new and I've not been able to find anything about anyone making use of them on the RPi as of yet (though after posting a question on the RPi forum I did note that Farnells stock went from 48 the 4 in three days, so maybe something soon eh?:).
I've got absolutely no idea what I'm doing with this so could do with some 'hand-holding'.
What I would much prefer would be to keep everything within Pd if possible...
1st off, and possibly dumb question - do we need [hid]? - My previous experience with xbee sensors did, so this is why I'm asking.
There are a few mentions of using python to get the data received on the Pi and then OSC'ing that into Pd but Miller mentioned on another thread "gpio on the raspberry pi from within pd ?" about writing an external to keep it within Pd. Any news/progress/tips on that front?
In the same thread Charles Goyard seems to have it working with [textfile], which seems far too simple (I'd very much like that if that was the case)
The sensor transmits the data as i2c but I haven't found anything in the archives particularly about anyone translating i2c directly in Pd yet?
We're going to fire the sensors up and see what happens in an hour or so and then come back to it tonight for a proper session so any and all pointers gratefully accepted.
I'll be back to let you know our 1st results soon.
Cheers,
Julian
On 2013-03-27 06:31, Julian Brooks wrote:
Hi all,
We've been after some sensors for motion detection on the RPi and Martin Peach spotted these (thanks again Martin!)
http://uk.farnell.com/omron-electronic-components/d6t-44l-06/sensor-thermal-...
They're fairly new and I've not been able to find anything about anyone making use of them on the RPi as of yet (though after posting a question on the RPi forum I did note that Farnells stock went from 48 the 4 in three days, so maybe something soon eh?:).
I've got absolutely no idea what I'm doing with this so could do with some 'hand-holding'.
What I would much prefer would be to keep everything within Pd if possible...
1st off, and possibly dumb question - do we need [hid]? - My previous experience with xbee sensors did, so this is why I'm asking.
[hid] is for USB devices so no.
There are a few mentions of using python to get the data received on the Pi and then OSC'ing that into Pd but Miller mentioned on another thread "gpio on the raspberry pi from within pd ?" about writing an external to keep it within Pd. Any news/progress/tips on that front?
http://www.gigamegablog.com/2012/11/04/beaglebone-coding-101-i2c/ talks about using i2c and python with the beaglebone which is a similar machine. It even uses code written for the Pi (https://github.com/adafruit/Adafruit-Raspberry-Pi-Python-Code). Using python ans OSC seems to be the easiest way to get started.
In the same thread Charles Goyard seems to have it working with [textfile], which seems far too simple (I'd very much like that if that was the case)
The sensor transmits the data as i2c but I haven't found anything in the archives particularly about anyone translating i2c directly in Pd yet?
I just got one of these and I'm going to try it with an arduino since the i2c there is easier to use. The arduino can talk to Pd using [comport].
Martin
We're going to fire the sensors up and see what happens in an hour or so and then come back to it tonight for a proper session so any and all pointers gratefully accepted.
I'll be back to let you know our 1st results soon.
Cheers,
Julian
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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/...
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.
We did put our pi prototype/breadboard together though:
http://www.coolcomponents.co.uk/catalog/raspberry-proto-plate-p-1104.html
which will be useful for experimenting.
Off to gen up on i2c, python and other such things I currently know nothing about.
Back soon with further info.
Cheers,
Julian
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/...
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. You write the value 0x4C (76) to address 7 and then request 32 bytes, which are 16 little-endian integers. The numbers are in tenths of a degree Celsius. I needed a 1 or 2ms delay between sending the command and requesting the data or the sensor would stop responding after 3 packets.
Martin
We did put our pi prototype/breadboard together though:
http://www.coolcomponents.co.uk/catalog/raspberry-proto-plate-p-1104.html
which will be useful for experimenting.
Off to gen up on i2c, python and other such things I currently know nothing about.
Back soon with further info.
Cheers,
Julian
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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/...
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
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
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
Also check this out: it seems to have everything except how to make a pd external from it. http://www.instructables.com/id/Raspberry-Pi-I2C-Python/
Martin
Thanks Martin, really useful stuff.
I've got i2cdetect on the RPi which is how I knew that [gpio] was setting hi & lo. And good to hear you'll be wrestling with this on the Pi as well.
In some ways this is good news as we've setup everything from the 'instructables' page already and now just need to get the bloody thing going (have to to sort the housings out).
Another possible issue is that from my reading it seems that the RPi doesn't do 'clock-stretching', though I have found a link where they slow the i2c bus down. http://www.hobbytronics.co.uk/raspberry-pi-i2c-clock-stretching
Another one here too: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=34734&p=29429...
That's interesting as they talk about setting up more GPIO pins for i2c to run 2 sensors.
Not being able to change the sensors address is a real pain though, as one of the things that I keep reading about i2c is it's ability to run up to 128 sensors on the same line - kinda defeats the object! Must be a way round it.
"You can use the 5V from the GPIO header on the pi. From the schematic pin 2 is 5V. Ground is on pin 6. Pin 3 is the i2c data and pin 5 is the clock. Pullup resistors are already installed on those lines."
Yes, found a good diagram for the GPIO schematic. http://elinux.org/RPi_Low-level_peripherals#GPIO_hardware_hacking
My understanding was that what we can't do is send data from the sensor at 5v back into the RPi at 3.5v and it's there that we need to drop the voltage back to 3.5. Noticeably though the 'instructables' link says they just did it anyway and was fine (with a disclaimer attached on to it).
We got some 4.7k resistors as you recommended - do we only need these before the sensors? The pdf from digikey has a diagram with a voltage transformer that we've been presuming is what we need to do?? Presumably if we put more resistors next to the Pi then we wont have enough voltage to lift the pin high (many ???). There's also lots of code (C?) on that pdf, anything you've made use of?
This is the little add-on board http://adafruit.com/products/757 I did read it's doable with mos-fet but seemed like another layer where we can screw-up so have taken the simple option.
Still don't get how we tie in the clock and the messages but I'm sure it'll become clearer when we actually get to the point where we can start it up.
Cheers,
Julian
On 7 April 2013 14:28, Martin Peach martin.peach@sympatico.ca wrote:
Also check this out: it seems to have everything except how to make a pd external from it. http://www.instructables.com/**id/Raspberry-Pi-I2C-Python/http://www.instructables.com/id/Raspberry-Pi-I2C-Python/
Martin
On 2013-04-07 17:42, Julian Brooks wrote:
Thanks Martin, really useful stuff.
I've got i2cdetect on the RPi which is how I knew that [gpio] was setting hi & lo. And good to hear you'll be wrestling with this on the Pi as well.
In some ways this is good news as we've setup everything from the 'instructables' page already and now just need to get the bloody thing going (have to to sort the housings out).
Another possible issue is that from my reading it seems that the RPi doesn't do 'clock-stretching', though I have found a link where they slow the i2c bus down. http://www.hobbytronics.co.uk/raspberry-pi-i2c-clock-stretching
Another one here too: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=34734&p=29429...
That's interesting as they talk about setting up more GPIO pins for i2c to run 2 sensors.
Not being able to change the sensors address is a real pain though, as one of the things that I keep reading about i2c is it's ability to run up to 128 sensors on the same line - kinda defeats the object! Must be a way round it.
Maybe there's a way to program the address but so far its a secret known only to Omron.
"You can use the 5V from the GPIO header on the pi. From the schematic pin 2 is 5V. Ground is on pin 6. Pin 3 is the i2c data and pin 5 is the clock. Pullup resistors are already installed on those lines."
Yes, found a good diagram for the GPIO schematic. http://elinux.org/RPi_Low-level_peripherals#GPIO_hardware_hacking
My understanding was that what we can't do is send data from the sensor at 5v back into the RPi at 3.5v and it's there that we need to drop the voltage back to 3.5. Noticeably though the 'instructables' link says they just did it anyway and was fine (with a disclaimer attached on to it).
The schematic for the RPi shows the resistors already installed, you don't need to add any. The resistors pull the bus voltage up to 3.3V when nothing is driving it to ground. Nobody is sending 5V signals, the i2c bus is either driven (clamped to 0V) or not driven, in which case the resistors bring the voltage to 3.3V, which is high enough for the 5V sensor inputs to read as 1.
We got some 4.7k resistors as you recommended - do we only need these before the sensors? The pdf from digikey has a diagram with a voltage transformer that we've been presuming is what we need to do?? Presumably if we put more resistors next to the Pi then we wont have enough voltage to lift the pin high (many ???). There's also lots of code (C?) on that pdf, anything you've made use of?
Yes that's what I got the crc calculation from, but as I said it doesn't give me the right result :(
This is the little add-on board http://adafruit.com/products/757 I did read it's doable with mos-fet but seemed like another layer where we can screw-up so have taken the simple option.
Yes you don't need any level shifter, the pullup resistors are enough, both 3.3V and 5V systems use the same voltage for 0.
Martin
On 2013-04-07 04:30, Julian Brooks wrote: ...
Also got a voltage transformer that works with i2c as the rpi is 3.5v and sensors 5v.
You can use the 5V from the GPIO header on the pi. From the schematic pin 2 is 5V. Ground is on pin 6. Pin 3 is the i2c data and pin 5 is the clock. Pullup resistors are already installed on those lines.
...
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?
You can't set the addresses. The only way to have two devices with the same address would be to gate the clock using another GPIO pin to control a chip like the CD4051 analog multiplexer so that only one of the sensors receives the clock signal.
Martin
-
Julian Brooks -
Martin Peach