"I'm trying to think how this could be generalized into a useful Pd external but it seems very specific to a particular setup."

I do think a more general [i2c] object would be super-useful. Particularly if it could directly open up and access the i2c line. Not sure how he does it but wiringPi has some kind of test routine that figures out what rev board it's on, which is pretty nifty too. If there's a method to incorporate the i2cdetect functions as well then it would be a one-stop-shop - so to speak.

Maybe an additional object to [gpio], plus the 2 omron's as externals / or combined into one and that's definitely the start of a new bad-ass lib:)

OAN - Really impressed with the C program: the drain on system resources is very minimal.

I'm still getting PEC errors on a regular basis though I still think we may have a dodgy connection somewhere down the line - sometimes when i2cdetect the sensor isn't registering and need to give it a little wiggle (not ideal).

Also presuming that as the clock is running at 100000 cycles that the readings being passed to Pd are set here:
char netbuf[256];

in the C code?

(could be talking out of my rear-end here I know)

And I'm also presuming they can be edited in those multiples (128, 512 etc)?

I haven't started experimenting yet but the plan is to run the installation headless.

Is there anything I'll need to change in the code to allow the C program to run from boot:

Like at the moment the readings are being spat out in the xterm (stdout) via 'printf' I think, which is also replicated via the [netreceive] patch, so I'm guessing I can start to trim stuff down.

Thinking aloud here - what I think would be really useful would be a method to have everything start at boot and then a method to route vital test info from both Pd and the C program to one shell so I could ethernet/wireless in via my lappy to check that all is well with the piece.

My leaky memory thinks that there's also a fairly recent workaround for the Pi (for M.E.Grimm I think) with routing pretty much this kind of stuff.

Anyways, thoughts starting to wander, back to it:)

On 23 April 2013 14:45, Martin Peach <martin.peach@sympatico.ca> wrote:

Yes that would work too, if you can handle the soldering ;(
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. Another way would be to have the Pd patch request a reading from a specific sensor.
I'm trying to think how this could be generalized into a useful Pd external but it seems very specific to a particular setup.

Martin

On 2013-04-23 05:06, Julian Brooks wrote:

Bit more digging re ic switch:
My understanding is that if we got one of these:
http://uk.farnell.com/roth-elektronik/re933-03/adaptor-smd-tssop-16-0-65mm/dp/1426182
and one of these:
http://uk.farnell.com/nxp/pca9546apw/ic-switch-4ch-i2c-16tssop/dp/2212120
we should in theory be able to run both sensors off the same pins?
BUT - would the current code you wrote function better/easier if the
sensors were run from 2 separate sets of pins - ie how to parse the info
from one patch sounds tricky and presume much simpler with 2
[netreceive] objects attached to 2 C files?

J

On 23 April 2013 09:42, Julian Brooks <jbeezez@gmail.com
<mailto:jbeezez@gmail.com>> wrote:

Hey Martin / all,

Omron tech support finally got back to me re the address issue, this
is what they had to say:

"D6T sensor can not change the address.
When you connect multiple sensors we recommend that you use the IC
switching.
Please refer to the below document.
http://media.digikey.com/pdf/Data%20Sheets/Omron%20PDFs/D6T44L_8L_Appl_Note.pdf
"

I've been through the spec sheet several times and don't see
anything (admittedly not sure exactly what I'm looking for though)
that relates to IC switching.

We've still got 2 of these doing nothing currently if they could be
brought into action:
http://adafruit.com/products/757

Or people on the RPi forum seem to have got the 2nd i2c pins going
but that seems to be for rev.2 boards only (I think - have posted a
question on the thread to ask).

Also asked tech support about the PEC errors but no response to that
one.

I've noticed that the PEC doesn't trigger errors all the time so am
wondering if it's possible to filter the errors out of the data
somehow in the C file?

Still delighted though - the sensors great!

Cheers,

Julian

On 22 April 2013 00:20, Julian Brooks <jbeezez@gmail.com
<mailto:jbeezez@gmail.com>> wrote:

Wonder if it's a difference between rev boards on the Pi?

I've also built a custom image based on Hexxeh's minimal install
which is working great for audio stuff. My Pd patch that
wouldn't run without overclocking on a standard Raspian is now
working fine on the rev1 256mg board. So I've been adding stuff
as and when it comes up to try and keep t is minimal as poss.

I'm also not sure what installed libi2c-dev? Guess I'll have to
wait and see what squeals.

Of possible interest is this message when removing the lib with
apt-get:
The following packages will be REMOVED:
libi2c-dev
0 upgraded, 0 newly installed, 1 to remove and 11 not upgraded.
After this operation, 19.5 kB disk space will be freed.
Do you want to continue [Y/n]? y
(Reading database ... 33610 files and directories currently
installed.)
Removing libi2c-dev ...
Removing 'diversion of /usr/include/linux/i2c-dev.h to
/usr/include/linux/i2c-dev.h.kernel by libi2c-dev'

So guess the diversion was messing with the compile for the C code.

Anyway - code runs and I can compile C files too so all ok so far.

Thanks again for everything Martin,

Julian

On 21 April 2013 06:45, Martin Peach <martin.peach@sympatico.ca
<mailto:martin.peach@sympatico.ca>> wrote:

On 2013-04-20 21:09, Julian Brooks wrote:

Oh and btw

Still don't know why I can't compile the .c files on the
pi with
libi2c-dev installed but I can't. Presuming the
compiling is working
for you Martin?

Yes it works for me. I don't have the same
/usr/include/linux/i2c-dev.h as you so no redefinition
errors, not sure which package(s) install that file.

Martin