<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 23 April 2013 14:45, Martin Peach <span dir="ltr"><<a href="mailto:martin.peach@sympatico.ca" target="_blank">martin.peach@sympatico.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes that would work too, if you can handle the soldering ;(<br></blockquote><div><br></div><div>Don't think I can tbh - Don't like soldering at the best of times and those teeny pins and housings almost drove us to despair. <br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suppose you could modify the c code to run two sensors and send the data to two different port numbers, or use two different selectors for the message.</blockquote><div> </div><div>Don't think this is possible with the rev1 board - I do have a rev2 so might have to jump ship, though my super minimal image has some networking issues - I can't get it to ssh and register on home network with fixed ip on rev2 (must be sortable).<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Another way would be to have the Pd patch request a reading from a specific sensor.<br></blockquote>
<div> </div><div>Can we do that if they have the same address? <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm trying to think how this could be generalized into a useful Pd external but it seems very specific to a particular setup.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>
Yep - it is very specific, bloody good tho'.<br><br></div><div>Julian<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
<br>
Martin</font></span><div class="im"><br>
<br>
On 2013-04-23 05:06, Julian Brooks wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Bit more digging re ic switch:<br>
My understanding is that if we got one of these:<br>
<a href="http://uk.farnell.com/roth-elektronik/re933-03/adaptor-smd-tssop-16-0-65mm/dp/1426182" target="_blank">http://uk.farnell.com/roth-<u></u>elektronik/re933-03/adaptor-<u></u>smd-tssop-16-0-65mm/dp/1426182</a><br>
and one of these:<br>
<a href="http://uk.farnell.com/nxp/pca9546apw/ic-switch-4ch-i2c-16tssop/dp/2212120" target="_blank">http://uk.farnell.com/nxp/<u></u>pca9546apw/ic-switch-4ch-i2c-<u></u>16tssop/dp/2212120</a><br>
we should in theory be able to run both sensors off the same pins?<br>
BUT - would the current code you wrote function better/easier if the<br>
sensors were run from 2 separate sets of pins - ie how to parse the info<br>
from one patch sounds tricky and presume much simpler with 2<br>
[netreceive] objects attached to 2 C files?<br>
<br>
J<br>
<br>
<br>
On 23 April 2013 09:42, Julian Brooks <<a href="mailto:jbeezez@gmail.com" target="_blank">jbeezez@gmail.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:jbeezez@gmail.com" target="_blank">jbeezez@gmail.com</a>>> wrote:<br>
<br>
Hey Martin / all,<br>
<br>
Omron tech support finally got back to me re the address issue, this<br>
is what they had to say:<br>
<br>
"D6T sensor can not change the address.<br>
When you connect multiple sensors we recommend that you use the IC<br>
switching.<br>
Please refer to the below document.<br>
<a href="http://media.digikey.com/pdf/Data%20Sheets/Omron%20PDFs/D6T44L_8L_Appl_Note.pdf" target="_blank">http://media.digikey.com/pdf/<u></u>Data%20Sheets/Omron%20PDFs/<u></u>D6T44L_8L_Appl_Note.pdf</a><br>
"<br>
<br>
<br>
I've been through the spec sheet several times and don't see<br>
anything (admittedly not sure exactly what I'm looking for though)<br>
that relates to IC switching.<br>
<br>
We've still got 2 of these doing nothing currently if they could be<br>
brought into action:<br>
<a href="http://adafruit.com/products/757" target="_blank">http://adafruit.com/products/<u></u>757</a><br>
<br>
Or people on the RPi forum seem to have got the 2nd i2c pins going<br>
but that seems to be for rev.2 boards only (I think - have posted a<br>
question on the thread to ask).<br>
<br>
Also asked tech support about the PEC errors but no response to that<br>
one.<br>
<br>
I've noticed that the PEC doesn't trigger errors all the time so am<br>
wondering if it's possible to filter the errors out of the data<br>
somehow in the C file?<br>
<br>
Still delighted though - the sensors great!<br>
<br>
Cheers,<br>
<br>
Julian<br>
<br>
<br>
<br>
On 22 April 2013 00:20, Julian Brooks <<a href="mailto:jbeezez@gmail.com" target="_blank">jbeezez@gmail.com</a><br></div></div><div><div class="h5">
<mailto:<a href="mailto:jbeezez@gmail.com" target="_blank">jbeezez@gmail.com</a>>> wrote:<br>
<br>
Wonder if it's a difference between rev boards on the Pi?<br>
<br>
I've also built a custom image based on Hexxeh's minimal install<br>
which is working great for audio stuff. My Pd patch that<br>
wouldn't run without overclocking on a standard Raspian is now<br>
working fine on the rev1 256mg board. So I've been adding stuff<br>
as and when it comes up to try and keep t is minimal as poss.<br>
<br>
I'm also not sure what installed libi2c-dev? Guess I'll have to<br>
wait and see what squeals.<br>
<br>
Of possible interest is this message when removing the lib with<br>
apt-get:<br>
The following packages will be REMOVED:<br>
libi2c-dev<br>
0 upgraded, 0 newly installed, 1 to remove and 11 not upgraded.<br>
After this operation, 19.5 kB disk space will be freed.<br>
Do you want to continue [Y/n]? y<br>
(Reading database ... 33610 files and directories currently<br>
installed.)<br>
Removing libi2c-dev ...<br>
Removing 'diversion of /usr/include/linux/i2c-dev.h to<br>
/usr/include/linux/i2c-dev.h.<u></u>kernel by libi2c-dev'<br>
<br>
So guess the diversion was messing with the compile for the C code.<br>
<br>
Anyway - code runs and I can compile C files too so all ok so far.<br>
<br>
Thanks again for everything Martin,<br>
<br>
Julian<br>
<br>
<br>
<br>
<br>
<br>
On 21 April 2013 06:45, Martin Peach <<a href="mailto:martin.peach@sympatico.ca" target="_blank">martin.peach@sympatico.ca</a><br></div></div><div class="im">
<mailto:<a href="mailto:martin.peach@sympatico.ca" target="_blank">martin.peach@<u></u>sympatico.ca</a>>> wrote:<br>
<br>
On 2013-04-20 21:09, Julian Brooks wrote:<br>
<br>
Oh and btw<br>
<br>
Still don't know why I can't compile the .c files on the<br>
pi with<br>
libi2c-dev installed but I can't. Presuming the<br>
compiling is working<br>
for you Martin?<br>
<br>
<br>
Yes it works for me. I don't have the same<br>
/usr/include/linux/i2c-dev.h as you so no redefinition<br>
errors, not sure which package(s) install that file.<br>
<br>
Martin<br>
<br>
<br>
<br>
<br>
<br>
</div></blockquote>
<br>
</blockquote></div><br></div></div>