Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-06-05 Thread Ivica Ico Bukvic 
Thank you very much!

 

From: Julian Brooks [mailto:jbee...@gmail.com] 
Sent: Monday, June 03, 2013 6:11 AM
To: Ivica Bukvic
Cc: pd-list; Martin Peach; George Naylor
Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd

 

Hey Ivica,

All the info is on this thread:
http://www.mail-archive.com/pd-list@iem.at/msg57752.html

The object is [gpio] and whilst working fine, is pretty basic.  Jaime's
helpfile is very useful and recommended.

OAN - Had a quick look at your site for the RPI version of pd-l2ork - really
excellent documentation, looks great, hats off to you.

Should have more time next month to properly engage with pd-l2ork - looking
forward to it.

Cheers,

Julian

 

On 3 June 2013 05:42, Ivica Bukvic  wrote:

Joining late to the discussion--is there now a native Pd external that
allows direct connection to RPi pins or is there still a need to use
middleware to access the data steam? If former, where can one get their
hands on the source--I would love to include it in the next pd-l2ork RPi
release?

Please advise.

On May 23, 2013 8:20 AM, "Julian Brooks"  wrote:

Just checked it again and noticeably in comparison to all our previous
testing there is now (as good as) zero errors from the sensors.  Rock solid.
Joy.

 

On 23 May 2013 13:16, Julian Brooks  wrote:

Hey Martin,

Many thanks for the extra wiring diagram.

We managed to confirm both sensors are working via pin11 from the IC going
between earth & 3v with gpio17 disconnected and running i2cdetect.

That was really useful as it was the first definite confirmation that both
sensors are working correctly.

In the process of doing that we also discovered that the line from gpio17 to
IC pin11 was in fact not connected to gpio17 at all!

To try and keep the protoplate reasonably tidy we'd soldered to the
underneath of the plate.  Somehow in the flipping from one side to the other
we'd messed up and missed by two connecting it to ground and therefore
making complete sense as to why only one sensor was working.

This is also after spending a half hour this morning checking and double
checking all the various lines and connections.  

So working now - blimey.

OAN - Whilst wanting to progress the Pd patch last night, having left it
since last Friday, I plugged the box with all our gubbins in and promptly
blew up the Pi - proper fried it it seems.  Loose power cable to the Pi and
we think it was touching a screw on the box.  Kapput.

The RPi was a rev1 board and my other is rev2 and the custom image I made
doesn't work on the rev2 board.  Always know this was a possible issue but,
you know, got a ton of other stuff to be getting on with.

 

So spent until 4am building a fresh image from
http://moebiuslinux.sourceforge.net/

and works really well so far-which is good.  Didn't get my patching done
though:)

Long way of saying that I've updated my C file to reflect this and all
working lovely.

Thank you thank you thank you.

Been much fun,

Julian

P.S. Will give this thread a nudge when I've documented it all (it's a
whopper)

 

 

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

 

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-06-03 Thread Julian Brooks 
Hey Ivica,

All the info is on this thread:
http://www.mail-archive.com/pd-list@iem.at/msg57752.html

The object is [gpio] and whilst working fine, is pretty basic.  Jaime's
helpfile is very useful and recommended.

OAN - Had a quick look at your site for the RPI version of pd-l2ork -
really excellent documentation, looks great, hats off to you.

Should have more time next month to properly engage with pd-l2ork - looking
forward to it.

Cheers,
Julian


On 3 June 2013 05:42, Ivica Bukvic  wrote:

> Joining late to the discussion--is there now a native Pd external that
> allows direct connection to RPi pins or is there still a need to use
> middleware to access the data steam? If former, where can one get their
> hands on the source--I would love to include it in the next pd-l2ork RPi
> release?
>
> Please advise.
> On May 23, 2013 8:20 AM, "Julian Brooks"  wrote:
>
>> Just checked it again and noticeably in comparison to all our previous
>> testing there is now (as good as) zero errors from the sensors.  Rock
>> solid.  Joy.
>>
>>
>> On 23 May 2013 13:16, Julian Brooks  wrote:
>>
>>> Hey Martin,
>>>
>>> Many thanks for the extra wiring diagram.
>>>
>>> We managed to confirm both sensors are working via pin11 from the IC
>>> going between earth & 3v with gpio17 disconnected and running i2cdetect.
>>>
>>> That was really useful as it was the first definite confirmation that
>>> both sensors are working correctly.
>>>
>>> In the process of doing that we also discovered that the line from
>>> gpio17 to IC pin11 was in fact not connected to gpio17 at all!
>>>
>>> To try and keep the protoplate reasonably tidy we'd soldered to the
>>> underneath of the plate.  Somehow in the flipping from one side to the
>>> other we'd messed up and missed by two connecting it to ground and
>>> therefore making complete sense as to why only one sensor was working.
>>>
>>> This is also after spending a half hour this morning checking and double
>>> checking all the various lines and connections.
>>>
>>> So working now - blimey.
>>>
>>> OAN - Whilst wanting to progress the Pd patch last night, having left it
>>> since last Friday, I plugged the box with all our gubbins in and promptly
>>> blew up the Pi - proper fried it it seems.  Loose power cable to the Pi and
>>> we think it was touching a screw on the box.  Kapput.
>>>
>>> The RPi was a rev1 board and my other is rev2 and the custom image I
>>> made doesn't work on the rev2 board.  Always know this was a possible issue
>>> but, you know, got a ton of other stuff to be getting on with.
>>>
>>> So spent until 4am building a fresh image from
>>> http://moebiuslinux.sourceforge.net/
>>> and works really well so far-which is good.  Didn't get my patching done
>>> though:)
>>>
>>> Long way of saying that I've updated my C file to reflect this and all
>>> working lovely.
>>>
>>> Thank you thank you thank you.
>>>
>>> Been much fun,
>>>
>>> Julian
>>>
>>> P.S. Will give this thread a nudge when I've documented it all (it's a
>>> whopper)
>>>
>>
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-06-02 Thread Ivica Bukvic 
Joining late to the discussion--is there now a native Pd external that
allows direct connection to RPi pins or is there still a need to use
middleware to access the data steam? If former, where can one get their
hands on the source--I would love to include it in the next pd-l2ork RPi
release?

Please advise.
On May 23, 2013 8:20 AM, "Julian Brooks"  wrote:

> Just checked it again and noticeably in comparison to all our previous
> testing there is now (as good as) zero errors from the sensors.  Rock
> solid.  Joy.
>
>
> On 23 May 2013 13:16, Julian Brooks  wrote:
>
>> Hey Martin,
>>
>> Many thanks for the extra wiring diagram.
>>
>> We managed to confirm both sensors are working via pin11 from the IC
>> going between earth & 3v with gpio17 disconnected and running i2cdetect.
>>
>> That was really useful as it was the first definite confirmation that
>> both sensors are working correctly.
>>
>> In the process of doing that we also discovered that the line from gpio17
>> to IC pin11 was in fact not connected to gpio17 at all!
>>
>> To try and keep the protoplate reasonably tidy we'd soldered to the
>> underneath of the plate.  Somehow in the flipping from one side to the
>> other we'd messed up and missed by two connecting it to ground and
>> therefore making complete sense as to why only one sensor was working.
>>
>> This is also after spending a half hour this morning checking and double
>> checking all the various lines and connections.
>>
>> So working now - blimey.
>>
>> OAN - Whilst wanting to progress the Pd patch last night, having left it
>> since last Friday, I plugged the box with all our gubbins in and promptly
>> blew up the Pi - proper fried it it seems.  Loose power cable to the Pi and
>> we think it was touching a screw on the box.  Kapput.
>>
>> The RPi was a rev1 board and my other is rev2 and the custom image I made
>> doesn't work on the rev2 board.  Always know this was a possible issue but,
>> you know, got a ton of other stuff to be getting on with.
>>
>> So spent until 4am building a fresh image from
>> http://moebiuslinux.sourceforge.net/
>> and works really well so far-which is good.  Didn't get my patching done
>> though:)
>>
>> Long way of saying that I've updated my C file to reflect this and all
>> working lovely.
>>
>> Thank you thank you thank you.
>>
>> Been much fun,
>>
>> Julian
>>
>> P.S. Will give this thread a nudge when I've documented it all (it's a
>> whopper)
>>
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-05-23 Thread Julian Brooks 
Just checked it again and noticeably in comparison to all our previous
testing there is now (as good as) zero errors from the sensors.  Rock
solid.  Joy.


On 23 May 2013 13:16, Julian Brooks  wrote:

> Hey Martin,
>
> Many thanks for the extra wiring diagram.
>
> We managed to confirm both sensors are working via pin11 from the IC going
> between earth & 3v with gpio17 disconnected and running i2cdetect.
>
> That was really useful as it was the first definite confirmation that both
> sensors are working correctly.
>
> In the process of doing that we also discovered that the line from gpio17
> to IC pin11 was in fact not connected to gpio17 at all!
>
> To try and keep the protoplate reasonably tidy we'd soldered to the
> underneath of the plate.  Somehow in the flipping from one side to the
> other we'd messed up and missed by two connecting it to ground and
> therefore making complete sense as to why only one sensor was working.
>
> This is also after spending a half hour this morning checking and double
> checking all the various lines and connections.
>
> So working now - blimey.
>
> OAN - Whilst wanting to progress the Pd patch last night, having left it
> since last Friday, I plugged the box with all our gubbins in and promptly
> blew up the Pi - proper fried it it seems.  Loose power cable to the Pi and
> we think it was touching a screw on the box.  Kapput.
>
> The RPi was a rev1 board and my other is rev2 and the custom image I made
> doesn't work on the rev2 board.  Always know this was a possible issue but,
> you know, got a ton of other stuff to be getting on with.
>
> So spent until 4am building a fresh image from
> http://moebiuslinux.sourceforge.net/
> and works really well so far-which is good.  Didn't get my patching done
> though:)
>
> Long way of saying that I've updated my C file to reflect this and all
> working lovely.
>
> Thank you thank you thank you.
>
> Been much fun,
>
> Julian
>
> P.S. Will give this thread a nudge when I've documented it all (it's a
> whopper)
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-05-23 Thread Julian Brooks 
Hey Martin,

Many thanks for the extra wiring diagram.

We managed to confirm both sensors are working via pin11 from the IC going
between earth & 3v with gpio17 disconnected and running i2cdetect.

That was really useful as it was the first definite confirmation that both
sensors are working correctly.

In the process of doing that we also discovered that the line from gpio17
to IC pin11 was in fact not connected to gpio17 at all!

To try and keep the protoplate reasonably tidy we'd soldered to the
underneath of the plate.  Somehow in the flipping from one side to the
other we'd messed up and missed by two connecting it to ground and
therefore making complete sense as to why only one sensor was working.

This is also after spending a half hour this morning checking and double
checking all the various lines and connections.

So working now - blimey.

OAN - Whilst wanting to progress the Pd patch last night, having left it
since last Friday, I plugged the box with all our gubbins in and promptly
blew up the Pi - proper fried it it seems.  Loose power cable to the Pi and
we think it was touching a screw on the box.  Kapput.

The RPi was a rev1 board and my other is rev2 and the custom image I made
doesn't work on the rev2 board.  Always know this was a possible issue but,
you know, got a ton of other stuff to be getting on with.

So spent until 4am building a fresh image from
http://moebiuslinux.sourceforge.net/
and works really well so far-which is good.  Didn't get my patching done
though:)

Long way of saying that I've updated my C file to reflect this and all
working lovely.

Thank you thank you thank you.

Been much fun,

Julian

P.S. Will give this thread a nudge when I've documented it all (it's a
whopper)
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-05-17 Thread Martin Peach 

Yep. Here's a diagram that shows the wiring.

Martin

On 2013-05-17 11:42, Julian Brooks wrote:

Aargh - you're right, I am confused (so very)...

So, to be clear
#define SENSOR_SELECT_PIN 11
should be
#define SENSOR_SELECT_PIN 17
After all?

It is then going to pin 11 on the 4051.

Running as root so need for sudo (yes I know)

As Max Romeo said:
"One step forwards, two steps backwards" :)

J

Will try the led test and the updated code when I can get back to it in
a couple of days or so.


On 17 May 2013 16:20, Martin Peach mailto:martin.pe...@sympatico.ca>> wrote:

It looks like you're confused about the GPIO pin.
SENSOR_SELECT_PIN should be 17 because that's what the ARM chip
calls it. The fact that it is on pin 11 of the header is irrelevant
to the program.
The next confusing thing is that GPIO17 on pin 11 of the header
connects to pin 11 of the 4051.
If you want to see if the pin is working you can put an LED from pin
11 of the header to ground and see if it flashes when you run the
program.
I had to run it as sudo because regular users don't have permission
to access the GPIO pins.

Martin


On 2013-05-17 10:50, Julian Brooks wrote:

Sorry meant to attach the code (doh!).

My compadre has all the photo's on his phone so will give him a
nudge
now and get back to you when I hear from him...

(hey George:)

Thanks for the testing tip - of course, seems so obvious now
that you've
said it.

And I guess we can't definitely confirm that the pin switches
although
the last big problem we had was that I'd set the switch to pin
17 rather
than pin 11 (gpio 17).  What would happen then is that we would
get one
reading from the 1st sensor and then it would stall/quit-out.

More soon hopefully,

Julian


On 17 May 2013 15:14, Martin Peach mailto:martin.pe...@sympatico.ca>
>> wrote:

 On 2013-05-17 09:39, Julian Brooks wrote:

 Hey Martin,

 Can I please peck your head hopefully one last time?


 Sure.


 We're so close, got the hardware for the installation
up and
 running,
 box made etc etc.

 Could you have a once-over of our code:
 Still only seeing one sensor though all of our multimeter
 testing says
 sensor 2 is fine and ready to go.  I think it has to be
a code
 problem
 in the C file but I just_can't\-see\-it!!


 You need to show me your code... The file I sent was to
read two
 sensors. The second was the 1X8 sensor so it reads a different
 number of bytes. You have to change that, everything else
should be
 the same..



 Keep wondering if there's a way of being able to test
the 2nd
 sensor in
 a similar vein to sensor 1 with 'i2cdetect', like if we
could
 shift the
 IC switcher so it would allow us to run the test on the
2nd one.


 Yes, just connect the A select line of the 4051 (pin 11)
directly to
 3.3V or ground to select one or the other. But disconnect
the GPIO
 pin when you do that.



 Pd is receiving on both sends (44l & 44l2) but all we
have is one
 sensors readings - same in the prints from the C file.


 Sounds like the multiplexer isn't working right. Do you
have a photo
 of your setup? Can you confirm that the GPIO pin switches?

 Martin




_
Pd-list@iem.at  mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/__listinfo/pd-list






<>___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-05-17 Thread Julian Brooks 
Aargh - you're right, I am confused (so very)...

So, to be clear
#define SENSOR_SELECT_PIN 11
should be
#define SENSOR_SELECT_PIN 17
After all?

It is then going to pin 11 on the 4051.

Running as root so need for sudo (yes I know)

As Max Romeo said:
"One step forwards, two steps backwards" :)

J

Will try the led test and the updated code when I can get back to it in a
couple of days or so.


On 17 May 2013 16:20, Martin Peach  wrote:

> It looks like you're confused about the GPIO pin.
> SENSOR_SELECT_PIN should be 17 because that's what the ARM chip calls it.
> The fact that it is on pin 11 of the header is irrelevant to the program.
> The next confusing thing is that GPIO17 on pin 11 of the header connects
> to pin 11 of the 4051.
> If you want to see if the pin is working you can put an LED from pin 11 of
> the header to ground and see if it flashes when you run the program.
> I had to run it as sudo because regular users don't have permission to
> access the GPIO pins.
>
> Martin
>
>
> On 2013-05-17 10:50, Julian Brooks wrote:
>
>> Sorry meant to attach the code (doh!).
>>
>> My compadre has all the photo's on his phone so will give him a nudge
>> now and get back to you when I hear from him...
>>
>> (hey George:)
>>
>> Thanks for the testing tip - of course, seems so obvious now that you've
>> said it.
>>
>> And I guess we can't definitely confirm that the pin switches although
>> the last big problem we had was that I'd set the switch to pin 17 rather
>> than pin 11 (gpio 17).  What would happen then is that we would get one
>> reading from the 1st sensor and then it would stall/quit-out.
>>
>> More soon hopefully,
>>
>> Julian
>>
>>
>> On 17 May 2013 15:14, Martin Peach > > wrote:
>>
>> On 2013-05-17 09:39, Julian Brooks wrote:
>>
>> Hey Martin,
>>
>> Can I please peck your head hopefully one last time?
>>
>>
>> Sure.
>>
>>
>> We're so close, got the hardware for the installation up and
>> running,
>> box made etc etc.
>>
>> Could you have a once-over of our code:
>> Still only seeing one sensor though all of our multimeter
>> testing says
>> sensor 2 is fine and ready to go.  I think it has to be a code
>> problem
>> in the C file but I just_can't\-see\-it!!
>>
>>
>> You need to show me your code... The file I sent was to read two
>> sensors. The second was the 1X8 sensor so it reads a different
>> number of bytes. You have to change that, everything else should be
>> the same..
>>
>>
>>
>> Keep wondering if there's a way of being able to test the 2nd
>> sensor in
>> a similar vein to sensor 1 with 'i2cdetect', like if we could
>> shift the
>> IC switcher so it would allow us to run the test on the 2nd one.
>>
>>
>> Yes, just connect the A select line of the 4051 (pin 11) directly to
>> 3.3V or ground to select one or the other. But disconnect the GPIO
>> pin when you do that.
>>
>>
>>
>> Pd is receiving on both sends (44l & 44l2) but all we have is one
>> sensors readings - same in the prints from the C file.
>>
>>
>> Sounds like the multiplexer isn't working right. Do you have a photo
>> of your setup? Can you confirm that the GPIO pin switches?
>>
>> Martin
>>
>>
>>
>>
>> __**_
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/**
>> listinfo/pd-list 
>>
>>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-05-17 Thread Martin Peach 

It looks like you're confused about the GPIO pin.
SENSOR_SELECT_PIN should be 17 because that's what the ARM chip calls 
it. The fact that it is on pin 11 of the header is irrelevant to the 
program.
The next confusing thing is that GPIO17 on pin 11 of the header connects 
to pin 11 of the 4051.
If you want to see if the pin is working you can put an LED from pin 11 
of the header to ground and see if it flashes when you run the program.
I had to run it as sudo because regular users don't have permission to 
access the GPIO pins.


Martin

On 2013-05-17 10:50, Julian Brooks wrote:

Sorry meant to attach the code (doh!).

My compadre has all the photo's on his phone so will give him a nudge
now and get back to you when I hear from him...

(hey George:)

Thanks for the testing tip - of course, seems so obvious now that you've
said it.

And I guess we can't definitely confirm that the pin switches although
the last big problem we had was that I'd set the switch to pin 17 rather
than pin 11 (gpio 17).  What would happen then is that we would get one
reading from the 1st sensor and then it would stall/quit-out.

More soon hopefully,

Julian


On 17 May 2013 15:14, Martin Peach mailto:martin.pe...@sympatico.ca>> wrote:

On 2013-05-17 09:39, Julian Brooks wrote:

Hey Martin,

Can I please peck your head hopefully one last time?


Sure.


We're so close, got the hardware for the installation up and
running,
box made etc etc.

Could you have a once-over of our code:
Still only seeing one sensor though all of our multimeter
testing says
sensor 2 is fine and ready to go.  I think it has to be a code
problem
in the C file but I just_can't\-see\-it!!


You need to show me your code... The file I sent was to read two
sensors. The second was the 1X8 sensor so it reads a different
number of bytes. You have to change that, everything else should be
the same..



Keep wondering if there's a way of being able to test the 2nd
sensor in
a similar vein to sensor 1 with 'i2cdetect', like if we could
shift the
IC switcher so it would allow us to run the test on the 2nd one.


Yes, just connect the A select line of the 4051 (pin 11) directly to
3.3V or ground to select one or the other. But disconnect the GPIO
pin when you do that.



Pd is receiving on both sends (44l & 44l2) but all we have is one
sensors readings - same in the prints from the C file.


Sounds like the multiplexer isn't working right. Do you have a photo
of your setup? Can you confirm that the GPIO pin switches?

Martin




___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list




___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-05-17 Thread Julian Brooks 
Sorry meant to attach the code (doh!).

My compadre has all the photo's on his phone so will give him a nudge now
and get back to you when I hear from him...

(hey George:)

Thanks for the testing tip - of course, seems so obvious now that you've
said it.

And I guess we can't definitely confirm that the pin switches although the
last big problem we had was that I'd set the switch to pin 17 rather than
pin 11 (gpio 17).  What would happen then is that we would get one reading
from the 1st sensor and then it would stall/quit-out.

More soon hopefully,

Julian


On 17 May 2013 15:14, Martin Peach  wrote:

> On 2013-05-17 09:39, Julian Brooks wrote:
>
>> Hey Martin,
>>
>> Can I please peck your head hopefully one last time?
>>
>>
> Sure.
>
>
>  We're so close, got the hardware for the installation up and running,
>> box made etc etc.
>>
>> Could you have a once-over of our code:
>> Still only seeing one sensor though all of our multimeter testing says
>> sensor 2 is fine and ready to go.  I think it has to be a code problem
>> in the C file but I just_can't\-see\-it!!
>>
>>
> You need to show me your code... The file I sent was to read two sensors.
> The second was the 1X8 sensor so it reads a different number of bytes. You
> have to change that, everything else should be the same..
>
>
>
>  Keep wondering if there's a way of being able to test the 2nd sensor in
>> a similar vein to sensor 1 with 'i2cdetect', like if we could shift the
>> IC switcher so it would allow us to run the test on the 2nd one.
>>
>
> Yes, just connect the A select line of the 4051 (pin 11) directly to 3.3V
> or ground to select one or the other. But disconnect the GPIO pin when you
> do that.
>
>
>
>> Pd is receiving on both sends (44l & 44l2) but all we have is one
>> sensors readings - same in the prints from the C file.
>>
>
> Sounds like the multiplexer isn't working right. Do you have a photo of
> your setup? Can you confirm that the GPIO pin switches?
>
> Martin
>
>
/* d6t_reader.c is a program that reads from omron d6t IR sensors using the raspberry pi i2c bus */
/* It sends sensor packets in a form readable by a pure-data [netreceive] object. */
// based on elinux.org/interfacing_with_I2C_Devices
// Martin Peach 20130416
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
//#include 
#include 
#include 
#include 
#include 
#include 
// Set a Pd [netreceive] to listen on this PORT
#define PORT 3
// Pd is running on this machine IP
//#define IP "192.168.2.15" 
#define IP "127.0.0.1"
// The SENSOR_PACKET_SIZE is 35 for D6T44L, 19 for D6T8L
#define D6T44L_SENSOR_PACKET_SIZE 35
#define D6T44L2_SENSOR_PACKET_SIZE 35
// PD_SELECTOR is the first item in the message sent to netrecceive
#define D6T44L_PD_SELECTOR "d6t44l"
#define D6T44L2_PD_SELECTOR "d6t44l2"
// SENSOR_SELECT_PIN connects to A of a 4051 multiplexer to select X0 or X1 output for the i2c clock.
// GPIO_17 is rPi GPIO_GEN_0, pin 11 on the P1 header.
#define SENSOR_SELECT_PIN 11
// calc_crc and D6T_checkPEC are from Omron's crc code from the DST-44L/DST-8L Thermal Sensor Whitepaper
unsigned char calc_crc (unsigned char data);
int D6T_checkPEC (unsigned char *buf, int pPEC);

int gpio_init(int gpio_number, int direction);
int gpio_write(int gpio_number, int value);
int gpio_free(int gpio_number);

void  sigint_handler(int sig);

/* non-zero direction is output */
#define GPIO_IN 0
#define GPIO_OUT 1
// Executes when the user presses Ctrl+C. Frees up GPIO pins

void sigint_handler(int sig)
{
gpio_free(SENSOR_SELECT_PIN);
exit (sig);
}

int gpio_init(int gpio_number, int direction)
{
FILE*fp;
//create a variable to store whether we are sending a '1' or a '0'
charset_value[4];
charpath[128];
//Using sysfs we need to write "38" to /sys/class/gpio/export
//This will create the folder /sys/class/gpio/gpio38
// use fopen instead of open because we don't want buffering
if ((fp = fopen("/sys/class/gpio/export", "ab")) == NULL)
{
printf("Cannot open export file.\n");
return(1);
}
//Set pointer to beginning of the file (is this necessary?)
rewind(fp);
//Write our value of "38" to the file
sprintf(set_value,"%d", gpio_number);
fwrite(&set_value, sizeof(char), strlen(set_value), fp);
fclose(fp);

printf("...export file accessed, new pin now accessible\n");

//Open the pin's sysfs file in binary for reading and writing, store file pointer in fp
sprintf(path, "/sys/class/gpio/gpio%d/direction", gpio_number);
if ((fp = fopen(path, "rb+")) == NULL)
{
printf("Cannot open direction file.\n");
return(2);
}
//Set pointer to beginning of the file
rewind(fp);
//Write our value of "out" to the file
if (direction) strcpy(set_value,"out");
else strcpy(set_value,"in");
fwrite(&set_value, sizeof(char), strlen(set_value), fp);
fclose(fp);
printf("...direction set to %sput\n", (direction)?"out

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-05-17 Thread Martin Peach 

On 2013-05-17 09:39, Julian Brooks wrote:

Hey Martin,

Can I please peck your head hopefully one last time?



Sure.


We're so close, got the hardware for the installation up and running,
box made etc etc.

Could you have a once-over of our code:
Still only seeing one sensor though all of our multimeter testing says
sensor 2 is fine and ready to go.  I think it has to be a code problem
in the C file but I just_can't\-see\-it!!



You need to show me your code... The file I sent was to read two 
sensors. The second was the 1X8 sensor so it reads a different number of 
bytes. You have to change that, everything else should be the same..




Keep wondering if there's a way of being able to test the 2nd sensor in
a similar vein to sensor 1 with 'i2cdetect', like if we could shift the
IC switcher so it would allow us to run the test on the 2nd one.


Yes, just connect the A select line of the 4051 (pin 11) directly to 
3.3V or ground to select one or the other. But disconnect the GPIO pin 
when you do that.




Pd is receiving on both sends (44l & 44l2) but all we have is one
sensors readings - same in the prints from the C file.


Sounds like the multiplexer isn't working right. Do you have a photo of 
your setup? Can you confirm that the GPIO pin switches?


Martin


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-05-17 Thread Julian Brooks 
Hey Martin,

Can I please peck your head hopefully one last time?

We're so close, got the hardware for the installation up and running, box
made etc etc.

Could you have a once-over of our code:
Still only seeing one sensor though all of our multimeter testing says
sensor 2 is fine and ready to go.  I think it has to be a code problem in
the C file but I just_can't\-see\-it!!

Keep wondering if there's a way of being able to test the 2nd sensor in a
similar vein to sensor 1 with 'i2cdetect', like if we could shift the IC
switcher so it would allow us to run the test on the 2nd one.

Pd is receiving on both sends (44l & 44l2) but all we have is one sensors
readings - same in the prints from the C file.

As per usual any and all comments/advice gratefully received.

Cheers,

Julian


On 9 May 2013 23:42, Julian Brooks  wrote:

> Hallo again,
>
> 10k's and clock now at 3.3v but the IC only works at 5v.
>
> Got a bit carried away before - my friend George, who's the sensor
> co-explorer, is normally only available on Friday's so very much had that
> Friday feeling - and of course giddy with the sensors all finally working.
> Started to lose the plot with it all last weekend and was getting a bit
> frenzied with my interactions on the breadboard - was probably the wise
> thing to just put it down for a few days and come back with a clear head.
>
> Think my codes still a bit buggy as I'm only getting one sensor coming
> into Pd but have 2 sets from the console.
>
> Back to it,
>
> Julian
>
>
> On 9 May 2013 18:41, Martin Peach  wrote:
>
>> On 2013-05-09 12:25, Julian Brooks wrote:
>>
>>> Hey Martin / all,
>>>
>>> Had to put this down for a few days but back at it today.
>>>
>>> Finally got it working - huzzah!
>>>
>>
>> That's great!
>>
>>
>>
>>> I changed the c file so that although it's gpio17 it's actually pin 11
>>> (define_SENSOR_SELECT_PIN) and boom!
>>> Why the numbering scheme is so confusing is beyond me but anyway.
>>>
>>> Also for us we're running the IC at 5v as well as the 10k resistors on
>>> the clock line.
>>>
>>>
>> Unless you have level shifters you should have the 10ks to 3.3V.
>> (Although at 10k, it's probably not too dangerous to go to 5V)
>>
>>
>>
>>
>>  Thanks again Martin - you rock.
>>>
>>> Have a great weekend,
>>>
>>>
>> Have a great sensation;)
>>
>> Martin
>>
>>
>>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-05-09 Thread Julian Brooks 
Hallo again,

10k's and clock now at 3.3v but the IC only works at 5v.

Got a bit carried away before - my friend George, who's the sensor
co-explorer, is normally only available on Friday's so very much had that
Friday feeling - and of course giddy with the sensors all finally working.
Started to lose the plot with it all last weekend and was getting a bit
frenzied with my interactions on the breadboard - was probably the wise
thing to just put it down for a few days and come back with a clear head.

Think my codes still a bit buggy as I'm only getting one sensor coming into
Pd but have 2 sets from the console.

Back to it,

Julian


On 9 May 2013 18:41, Martin Peach  wrote:

> On 2013-05-09 12:25, Julian Brooks wrote:
>
>> Hey Martin / all,
>>
>> Had to put this down for a few days but back at it today.
>>
>> Finally got it working - huzzah!
>>
>
> That's great!
>
>
>
>> I changed the c file so that although it's gpio17 it's actually pin 11
>> (define_SENSOR_SELECT_PIN) and boom!
>> Why the numbering scheme is so confusing is beyond me but anyway.
>>
>> Also for us we're running the IC at 5v as well as the 10k resistors on
>> the clock line.
>>
>>
> Unless you have level shifters you should have the 10ks to 3.3V. (Although
> at 10k, it's probably not too dangerous to go to 5V)
>
>
>
>
>  Thanks again Martin - you rock.
>>
>> Have a great weekend,
>>
>>
> Have a great sensation;)
>
> Martin
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-05-09 Thread Martin Peach 

On 2013-05-09 12:25, Julian Brooks wrote:

Hey Martin / all,

Had to put this down for a few days but back at it today.

Finally got it working - huzzah!


That's great!



I changed the c file so that although it's gpio17 it's actually pin 11
(define_SENSOR_SELECT_PIN) and boom!
Why the numbering scheme is so confusing is beyond me but anyway.

Also for us we're running the IC at 5v as well as the 10k resistors on
the clock line.



Unless you have level shifters you should have the 10ks to 3.3V. 
(Although at 10k, it's probably not too dangerous to go to 5V)





Thanks again Martin - you rock.

Have a great weekend,



Have a great sensation;)

Martin



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-05-09 Thread Julian Brooks 
Hey Martin / all,

Had to put this down for a few days but back at it today.

Finally got it working - huzzah!

I changed the c file so that although it's gpio17 it's actually pin 11
(define_SENSOR_SELECT_PIN) and boom!
Why the numbering scheme is so confusing is beyond me but anyway.

Also for us we're running the IC at 5v as well as the 10k resistors on the
clock line.

Thanks again Martin - you rock.

Have a great weekend,

Julian


On 3 May 2013 18:17, Martin Peach  wrote:

> On 2013-05-03 12:34, Julian Brooks wrote:
>
>> Ok - thanks for that, makes more sense now.
>>
>> When I run the C code this happens:
>>
>> "./jb_d6t_reader_ic3 0
>> ...export file accessed, new pin now accessible
>> ...direction set to output
>> ./jb_d6t_reader_ic3: initialized:0
>> Write failed (5)
>>  >> Input/output error <<
>> ...unexport file accessed, pin now inaccessible"
>>
>> I've done my best to go through the code and make changes where
>> appropriate.
>>
>> Replaced D6T8L with DRT44L2 and changed packet size.
>> Altered all references for 2nd sensor to DRT44L2 and also changed i2c-1
>> to 0 for rev1 board.
>>
>> Weirdly I can't access the i2c bus anymore?
>> cat /dev/i2c*
>> cat: /dev/i2c-0: Input/output error
>> cat: /dev/i2c-1: Input/output error
>>
>>
> Yes I get that too. (unless the sensor returns one byte it's probably
> normal) But "i2cdetect -y 1" still shows a sensor at 0x0A.
> I run the code as "sudo ./d6t_reader 0", otherwise I don't have permission
> to set the GPIO pin.
> I don't get any write errors though.
> Are you writing to the correct i2c?
> There are two places in the code that could throw the write error. Maybe
> change the message so you can tell which one it is.
> Anyway the setup should work with the old code (only one sensor), the 4051
> circuit should have no effect on the communication betwen the Pi and one of
> the sensors, the select pin select which sensor receives the clock. So if
> the older code isn't working the circuit is wrong, otherwise the code is
> buggy.
>
> Martin
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-05-03 Thread Martin Peach 

On 2013-05-03 12:34, Julian Brooks wrote:

Ok - thanks for that, makes more sense now.

When I run the C code this happens:

"./jb_d6t_reader_ic3 0
...export file accessed, new pin now accessible
...direction set to output
./jb_d6t_reader_ic3: initialized:0
Write failed (5)
 >> Input/output error <<
...unexport file accessed, pin now inaccessible"

I've done my best to go through the code and make changes where appropriate.

Replaced D6T8L with DRT44L2 and changed packet size.
Altered all references for 2nd sensor to DRT44L2 and also changed i2c-1
to 0 for rev1 board.

Weirdly I can't access the i2c bus anymore?
cat /dev/i2c*
cat: /dev/i2c-0: Input/output error
cat: /dev/i2c-1: Input/output error



Yes I get that too. (unless the sensor returns one byte it's probably 
normal) But "i2cdetect -y 1" still shows a sensor at 0x0A.
I run the code as "sudo ./d6t_reader 0", otherwise I don't have 
permission to set the GPIO pin.

I don't get any write errors though.
Are you writing to the correct i2c?
There are two places in the code that could throw the write error. Maybe 
change the message so you can tell which one it is.
Anyway the setup should work with the old code (only one sensor), the 
4051 circuit should have no effect on the communication betwen the Pi 
and one of the sensors, the select pin select which sensor receives the 
clock. So if the older code isn't working the circuit is wrong, 
otherwise the code is buggy.


Martin


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-05-03 Thread Julian Brooks 
Ok - thanks for that, makes more sense now.

When I run the C code this happens:

"./jb_d6t_reader_ic3 0
...export file accessed, new pin now accessible
...direction set to output
./jb_d6t_reader_ic3: initialized:0
Write failed (5)
>> Input/output error <<
...unexport file accessed, pin now inaccessible"

I've done my best to go through the code and make changes where appropriate.

Replaced D6T8L with DRT44L2 and changed packet size.
Altered all references for 2nd sensor to DRT44L2 and also changed i2c-1 to
0 for rev1 board.

Weirdly I can't access the i2c bus anymore?
cat /dev/i2c*
cat: /dev/i2c-0: Input/output error
cat: /dev/i2c-1: Input/output error

Tried to follow the code to figure where it's falling down but I'm not
getting it.

Also do I still need 1 or 0 after './jb_d6t_reader_ic(n)? 1 seems to make
it to go into PEC spiral with no readings.

Read failed (5)
>> Input/output error <<
D6T_checkPEC says 0x8F
Read failed (5)
>> Input/output error <<
D6T_checkPEC says 0x8F
Read failed (5)
>> Input/output error <<
D6T_checkPEC says 0x8F
Read failed (5)
>> Input/output error <<
D6T_checkPEC says 0x8F
Read failed (5)
>> Input/output error <<
D6T_checkPEC says 0x8F
Read failed (5)
>> Input/output error <<

etc etc.

i2cdetect -y 0 also draws a blank.

Very best wishes,

Julian




On 3 May 2013 16:31, Martin Peach  wrote:

> On 2013-05-03 10:26, Julian Brooks wrote:
>
>> Hey Martin / all,
>>
> ..
>
>> This is what we have and aren't sure if it's correct
>>
>
> Yes it's a bit wrong...
>
>
>  16 to 3.3v RPi
>> 14 to SCL (sensor 1)
>>
>
> Yes, pin 3 is connected through to pin 13 when pin 11 is low, and to pin
> 14 when 11 is high. So it's actually sensor 2 on pin 14.
>
>
>  13 to SCL (sensor 2)
>>
>
> Is actually sensor 1
>
>
>  [Each SCL has 10k resistor and a feed of 3.3v from RPi]
>> 11 to  P1-11 (GPIO 17) - RPi
>>
>
> Yes, 11 selects which channel. 9,10, and 11 make up a 3-bit address which
> selects which of the 8 output channels is connected to the input on pin 3.
> If you only have 2 sensors the two extra selector pins must be set low.
>
>
>  10 to SDA (sensor 1)
>>
>
> 10 to Ground or another selector pin if you have more than 2 sensors
> The sensor data pins are connected directly to the RPi SDA pin, only the
> SCL line goes through the 4051.
>
>
>  9   to SDA (sensor 2)
>>
>
> 9 to Ground or another selector pin
>
>  7   to Ground
>>
>
> Also, 6 (Inhibit) must be low for the chip to function (this permits
> expanding to more than 8 channels by using more 4051s)
> Pin 8 to Ground
>
>
>  3   to SDA P1-03 (GPIO 0) - RPi
>>
>
> 3 to SCL RPi, you're switching the clock line, not the data
>
>
>
>> The power for the sensors is wired directly into 5v from the RPi.
>> The ground for the sensors is wired directly into the RPi.
>>
>>
> Martin
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-05-03 Thread Julian Brooks 
Hey Martin / all,

Oh there's much chin scratching and head shaking going on at our end atm...

Can we ask if we have the hardware configured correctly before moving onto
software issues please:

Attached is the diagram of our 4051 mux'er.

This is what we have and aren't sure if it's correct
16 to 3.3v RPi
14 to SCL (sensor 1)
13 to SCL (sensor 2)
[Each SCL has 10k resistor and a feed of 3.3v from RPi]
11 to  P1-11 (GPIO 17) - RPi
10 to SDA (sensor 1)
9   to SDA (sensor 2)
7   to Ground
3   to SDA P1-03 (GPIO 0) - RPi

The power for the sensors is wired directly into 5v from the RPi.
The ground for the sensors is wired directly into the RPi.

I'm not sure if this has happened after running the code for the sensors
but I'm now unable to access the i2c busses:

cat /dev/i2c*
cat: /dev/i2c-0: Input/output error
cat: /dev/i2c-1: Input/output error

I note from the code that we're now using gpio17 instead of the i2c busses
which would account for that error I guess?

Few more coding issues but feel like we could do with some confirmation
that the hardware's correct before moving on?

Cheers,

Julian


On 29 April 2013 16:38, Martin Peach  wrote:

> Here's a patch to display data from two D6T sensors on the same I2C bus.
> The clock line is switched using a 4051 analog multiplexer. The control
> line is GPIO_17 of the Pi connected to A of the 4051 (B, C and Inhibit are
> at 0V). 10k resistors to 3.3V are on each sensor's clock line at X0 and X1
> of the 4051 (I2C clock connects to X). Because the code accesses the GPIO
> file system it needs to be run as root. I have two different sensors so the
> code reads two different packet lengths. Just a proof of concept, there
> could be up to 8 identical sensors on the same bus with this setup.
>
> Martin
>
>
> On 2013-04-25 20:04, Julian Brooks wrote:
>
>> Just spotted this:
>> https://github.com/kadamski/i2c-gpio-param
>> Could be useful
>>
>>
>> On 25 April 2013 15:54, Martin Peach > > wrote:
>>
>> On 2013-04-25 10:37, Julian Brooks wrote:
>>
>> 'Nother 2 dumb questions:
>> What's the difference between the ones that have
>> spider/centipede type
>> legs and the straight ones (which would be best to get).
>>
>>
>> The PDIP package is what you want, not the SOIC. The only difference
>> is size. DIP packages are human-friendly, surface mount is for robots.
>>
>>
>> And also are you attaching the MC14051 to any type of
>> board/adaptor or
>> just soldering straight on to the pins?
>>
>>
>> I have it in a breadboard right now, to make it more permanent I
>> would solder a socket to a prototyping board then (after verifying
>> the connections) plug the chip into the socket. Soldering to the
>> pins makes it difficult to replace the IC, and risks damaging it
>> with the heat if you're not good at soldering quickly and to the
>> point. A CD4051 would also work, it's basically the same circuit.
>>
>> Martin
>>
>>
>>
>>
>
<>___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-29 Thread Julian Brooks 
:) - ta


On 29 April 2013 23:07, Martin Peach  wrote:

> On 2013-04-29 17:59, Julian Brooks wrote:
>
>> BTW
>> This is the multiplexer:
>> http://uk.farnell.com/jsp/**search/productdetail.jsp?sku=**1106109
>> and the housing:
>> http://uk.farnell.com/jsp/**search/productdetail.jsp?sku=**1103846
>>
>> Think these are right?
>>
>>
>
> Yes.
>
> Martin
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-29 Thread Martin Peach 

On 2013-04-29 17:59, Julian Brooks wrote:

BTW
This is the multiplexer:
http://uk.farnell.com/jsp/search/productdetail.jsp?sku=1106109
and the housing:
http://uk.farnell.com/jsp/search/productdetail.jsp?sku=1103846

Think these are right?




Yes.

Martin


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-29 Thread Martin Peach 
Ordinary 5% resistors will work fine. Probably anything from 1k to 100k 
would work. Most likely you have a loose connection somewhere. Did you 
try running the bus at a lower speed? If your wiring is long (> 10cm) 
it may be better to run it slower.


Martin

On 2013-04-29 17:44, Julian Brooks wrote:

Hi Martin / all,

Possibly overly-nerdy question here:

I'm buying the various bits and pieces we require for the multiplexer
and I'm noticing quite a difference in pricing options for the pull-up
resistors.
There's this one:
http://uk.farnell.com/welwyn/rc55-10k-0-1/resistor-10k-250mw-0-1/dp/9499938
which is 86p each.
Or there's something like this:
http://uk.farnell.com/multicomp/mcf-0-25w-10k/resistor-10k-250mw-5/dp/9339060
which is 2p each.

The former's spec sheet talks about its very low noise ratio and
thinking on from reading the sensors spec sheet it's also pushed there
to use low-noise components.

Do you think it actually makes any difference?  I have to buy a minimum
50 of the cheap ones so buying a couple of the dearer ones doesn't
actually make much of a difference.

It got me thinking as you mentioned that your getting virtually no PEC
errors from the sensors whereas as we are getting them very regularly.
I had been thinking it was the soldering of those pernickety sensors but
could it also be the cheap 4k resistors currently on our board?

Cheers,

Julian


On 29 April 2013 16:38, Martin Peach mailto:martin.pe...@sympatico.ca>> wrote:

Here's a patch to display data from two D6T sensors on the same I2C
bus. The clock line is switched using a 4051 analog multiplexer. The
control line is GPIO_17 of the Pi connected to A of the 4051 (B, C
and Inhibit are at 0V). 10k resistors to 3.3V are on each sensor's
clock line at X0 and X1 of the 4051 (I2C clock connects to X).
Because the code accesses the GPIO file system it needs to be run as
root. I have two different sensors so the code reads two different
packet lengths. Just a proof of concept, there could be up to 8
identical sensors on the same bus with this setup.

Martin


On 2013-04-25 20:04, Julian Brooks wrote:

Just spotted this:
https://github.com/kadamski/__i2c-gpio-param

Could be useful


On 25 April 2013 15:54, Martin Peach mailto:martin.pe...@sympatico.ca>
>> wrote:

 On 2013-04-25 10:37, Julian Brooks wrote:

 'Nother 2 dumb questions:
 What's the difference between the ones that have
 spider/centipede type
 legs and the straight ones (which would be best to get).


 The PDIP package is what you want, not the SOIC. The only
difference
 is size. DIP packages are human-friendly, surface mount is
for robots.


 And also are you attaching the MC14051 to any type of
 board/adaptor or
 just soldering straight on to the pins?


 I have it in a breadboard right now, to make it more
permanent I
 would solder a socket to a prototyping board then (after
verifying
 the connections) plug the chip into the socket. Soldering
to the
 pins makes it difficult to replace the IC, and risks
damaging it
 with the heat if you're not good at soldering quickly and
to the
 point. A CD4051 would also work, it's basically the same
circuit.

 Martin








___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-29 Thread Julian Brooks 
BTW
This is the multiplexer:
http://uk.farnell.com/jsp/search/productdetail.jsp?sku=1106109
and the housing:
http://uk.farnell.com/jsp/search/productdetail.jsp?sku=1103846

Think these are right?


On 29 April 2013 22:44, Julian Brooks  wrote:

> Hi Martin / all,
>
> Possibly overly-nerdy question here:
>
> I'm buying the various bits and pieces we require for the multiplexer and
> I'm noticing quite a difference in pricing options for the pull-up
> resistors.
> There's this one:
> http://uk.farnell.com/welwyn/rc55-10k-0-1/resistor-10k-250mw-0-1/dp/9499938
> which is 86p each.
> Or there's something like this:
>
> http://uk.farnell.com/multicomp/mcf-0-25w-10k/resistor-10k-250mw-5/dp/9339060
> which is 2p each.
>
> The former's spec sheet talks about its very low noise ratio and thinking
> on from reading the sensors spec sheet it's also pushed there to use
> low-noise components.
>
> Do you think it actually makes any difference?  I have to buy a minimum 50
> of the cheap ones so buying a couple of the dearer ones doesn't actually
> make much of a difference.
>
> It got me thinking as you mentioned that your getting virtually no PEC
> errors from the sensors whereas as we are getting them very regularly.  I
> had been thinking it was the soldering of those pernickety sensors but
> could it also be the cheap 4k resistors currently on our board?
>
> Cheers,
>
> Julian
>
>
> On 29 April 2013 16:38, Martin Peach  wrote:
>
>> Here's a patch to display data from two D6T sensors on the same I2C bus.
>> The clock line is switched using a 4051 analog multiplexer. The control
>> line is GPIO_17 of the Pi connected to A of the 4051 (B, C and Inhibit are
>> at 0V). 10k resistors to 3.3V are on each sensor's clock line at X0 and X1
>> of the 4051 (I2C clock connects to X). Because the code accesses the GPIO
>> file system it needs to be run as root. I have two different sensors so the
>> code reads two different packet lengths. Just a proof of concept, there
>> could be up to 8 identical sensors on the same bus with this setup.
>>
>> Martin
>>
>>
>> On 2013-04-25 20:04, Julian Brooks wrote:
>>
>>> Just spotted this:
>>> https://github.com/kadamski/**i2c-gpio-param
>>> Could be useful
>>>
>>>
>>> On 25 April 2013 15:54, Martin Peach >> > wrote:
>>>
>>> On 2013-04-25 10:37, Julian Brooks wrote:
>>>
>>> 'Nother 2 dumb questions:
>>> What's the difference between the ones that have
>>> spider/centipede type
>>> legs and the straight ones (which would be best to get).
>>>
>>>
>>> The PDIP package is what you want, not the SOIC. The only difference
>>> is size. DIP packages are human-friendly, surface mount is for
>>> robots.
>>>
>>>
>>> And also are you attaching the MC14051 to any type of
>>> board/adaptor or
>>> just soldering straight on to the pins?
>>>
>>>
>>> I have it in a breadboard right now, to make it more permanent I
>>> would solder a socket to a prototyping board then (after verifying
>>> the connections) plug the chip into the socket. Soldering to the
>>> pins makes it difficult to replace the IC, and risks damaging it
>>> with the heat if you're not good at soldering quickly and to the
>>> point. A CD4051 would also work, it's basically the same circuit.
>>>
>>> Martin
>>>
>>>
>>>
>>>
>>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-29 Thread Julian Brooks 
Hi Martin / all,

Possibly overly-nerdy question here:

I'm buying the various bits and pieces we require for the multiplexer and
I'm noticing quite a difference in pricing options for the pull-up
resistors.
There's this one:
http://uk.farnell.com/welwyn/rc55-10k-0-1/resistor-10k-250mw-0-1/dp/9499938
which is 86p each.
Or there's something like this:
http://uk.farnell.com/multicomp/mcf-0-25w-10k/resistor-10k-250mw-5/dp/9339060
which is 2p each.

The former's spec sheet talks about its very low noise ratio and thinking
on from reading the sensors spec sheet it's also pushed there to use
low-noise components.

Do you think it actually makes any difference?  I have to buy a minimum 50
of the cheap ones so buying a couple of the dearer ones doesn't actually
make much of a difference.

It got me thinking as you mentioned that your getting virtually no PEC
errors from the sensors whereas as we are getting them very regularly.  I
had been thinking it was the soldering of those pernickety sensors but
could it also be the cheap 4k resistors currently on our board?

Cheers,

Julian


On 29 April 2013 16:38, Martin Peach  wrote:

> Here's a patch to display data from two D6T sensors on the same I2C bus.
> The clock line is switched using a 4051 analog multiplexer. The control
> line is GPIO_17 of the Pi connected to A of the 4051 (B, C and Inhibit are
> at 0V). 10k resistors to 3.3V are on each sensor's clock line at X0 and X1
> of the 4051 (I2C clock connects to X). Because the code accesses the GPIO
> file system it needs to be run as root. I have two different sensors so the
> code reads two different packet lengths. Just a proof of concept, there
> could be up to 8 identical sensors on the same bus with this setup.
>
> Martin
>
>
> On 2013-04-25 20:04, Julian Brooks wrote:
>
>> Just spotted this:
>> https://github.com/kadamski/**i2c-gpio-param
>> Could be useful
>>
>>
>> On 25 April 2013 15:54, Martin Peach > > wrote:
>>
>> On 2013-04-25 10:37, Julian Brooks wrote:
>>
>> 'Nother 2 dumb questions:
>> What's the difference between the ones that have
>> spider/centipede type
>> legs and the straight ones (which would be best to get).
>>
>>
>> The PDIP package is what you want, not the SOIC. The only difference
>> is size. DIP packages are human-friendly, surface mount is for robots.
>>
>>
>> And also are you attaching the MC14051 to any type of
>> board/adaptor or
>> just soldering straight on to the pins?
>>
>>
>> I have it in a breadboard right now, to make it more permanent I
>> would solder a socket to a prototyping board then (after verifying
>> the connections) plug the chip into the socket. Soldering to the
>> pins makes it difficult to replace the IC, and risks damaging it
>> with the heat if you're not good at soldering quickly and to the
>> point. A CD4051 would also work, it's basically the same circuit.
>>
>> Martin
>>
>>
>>
>>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-29 Thread Julian Brooks 
Super-useful, thanks Martin.

Will be testing it out in a couple of days so will report back then.

Julian


On 29 April 2013 16:38, Martin Peach  wrote:

> Here's a patch to display data from two D6T sensors on the same I2C bus.
> The clock line is switched using a 4051 analog multiplexer. The control
> line is GPIO_17 of the Pi connected to A of the 4051 (B, C and Inhibit are
> at 0V). 10k resistors to 3.3V are on each sensor's clock line at X0 and X1
> of the 4051 (I2C clock connects to X). Because the code accesses the GPIO
> file system it needs to be run as root. I have two different sensors so the
> code reads two different packet lengths. Just a proof of concept, there
> could be up to 8 identical sensors on the same bus with this setup.
>
> Martin
>
>
> On 2013-04-25 20:04, Julian Brooks wrote:
>
>> Just spotted this:
>> https://github.com/kadamski/**i2c-gpio-param
>> Could be useful
>>
>>
>> On 25 April 2013 15:54, Martin Peach > > wrote:
>>
>> On 2013-04-25 10:37, Julian Brooks wrote:
>>
>> 'Nother 2 dumb questions:
>> What's the difference between the ones that have
>> spider/centipede type
>> legs and the straight ones (which would be best to get).
>>
>>
>> The PDIP package is what you want, not the SOIC. The only difference
>> is size. DIP packages are human-friendly, surface mount is for robots.
>>
>>
>> And also are you attaching the MC14051 to any type of
>> board/adaptor or
>> just soldering straight on to the pins?
>>
>>
>> I have it in a breadboard right now, to make it more permanent I
>> would solder a socket to a prototyping board then (after verifying
>> the connections) plug the chip into the socket. Soldering to the
>> pins makes it difficult to replace the IC, and risks damaging it
>> with the heat if you're not good at soldering quickly and to the
>> point. A CD4051 would also work, it's basically the same circuit.
>>
>> Martin
>>
>>
>>
>>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-29 Thread Martin Peach 
Here's a patch to display data from two D6T sensors on the same I2C bus. 
The clock line is switched using a 4051 analog multiplexer. The control 
line is GPIO_17 of the Pi connected to A of the 4051 (B, C and Inhibit 
are at 0V). 10k resistors to 3.3V are on each sensor's clock line at X0 
and X1 of the 4051 (I2C clock connects to X). Because the code accesses 
the GPIO file system it needs to be run as root. I have two different 
sensors so the code reads two different packet lengths. Just a proof of 
concept, there could be up to 8 identical sensors on the same bus with 
this setup.


Martin

On 2013-04-25 20:04, Julian Brooks wrote:

Just spotted this:
https://github.com/kadamski/i2c-gpio-param
Could be useful


On 25 April 2013 15:54, Martin Peach mailto:martin.pe...@sympatico.ca>> wrote:

On 2013-04-25 10:37, Julian Brooks wrote:

'Nother 2 dumb questions:
What's the difference between the ones that have
spider/centipede type
legs and the straight ones (which would be best to get).


The PDIP package is what you want, not the SOIC. The only difference
is size. DIP packages are human-friendly, surface mount is for robots.


And also are you attaching the MC14051 to any type of
board/adaptor or
just soldering straight on to the pins?


I have it in a breadboard right now, to make it more permanent I
would solder a socket to a prototyping board then (after verifying
the connections) plug the chip into the socket. Soldering to the
pins makes it difficult to replace the IC, and risks damaging it
with the heat if you're not good at soldering quickly and to the
point. A CD4051 would also work, it's basically the same circuit.

Martin





#N canvas 2 0 1015 665 10;
#X obj 34 21 unpack 1 2 3 4 5 6 7 8 9;
#X obj 34 -51 netreceive 3 1;
#X floatatom 34 147 5 0 0 0 - - -;
#X floatatom 74 147 5 0 0 0 - - -;
#X floatatom 114 147 5 0 0 0 - - -;
#X floatatom 154 147 5 0 0 0 - - -;
#X floatatom 194 147 5 0 0 0 - - -;
#X floatatom 234 147 5 0 0 0 - - -;
#X floatatom 274 147 5 0 0 0 - - -;
#X floatatom 314 147 5 0 0 0 - - -;
#X floatatom 354 146 5 0 0 0 - - -;
#X obj 57 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -260097
-1 -1 6756 1;
#X obj 77 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 6782 1;
#X obj 97 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 6731 1;
#X obj 117 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 6350 1;
#X obj 137 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 6502 1;
#X obj 157 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 6604 1;
#X obj 177 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 6756 1;
#X obj 197 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 7188 1;
#X obj 217 215 vsl 15 128 0 500 0 0 empty empty empty 0 -9 0 10 -4034
-1 -1 7137 1;
#X obj 34 -11 route d6t8l d6t44l;
#X obj 462 6 unpack 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17;
#X floatatom 416 41 5 0 0 0 - - -;
#X floatatom 479 201 5 0 0 0 - - -;
#X floatatom 602 201 5 0 0 0 - - -;
#X floatatom 719 201 5 0 0 0 - - -;
#X floatatom 843 201 5 0 0 0 - - -;
#X floatatom 480 269 5 0 0 0 - - -;
#X floatatom 601 269 5 0 0 0 - - -;
#X floatatom 720 269 5 0 0 0 - - -;
#X floatatom 842 269 5 0 0 0 - - -;
#X floatatom 482 336 5 0 0 0 - - -;
#X floatatom 603 336 5 0 0 0 - - -;
#X floatatom 723 336 5 0 0 0 - - -;
#X floatatom 846 336 5 0 0 0 - - -;
#X floatatom 483 407 5 0 0 0 - - -;
#X floatatom 601 407 5 0 0 0 - - -;
#X floatatom 723 407 5 0 0 0 - - -;
#X floatatom 847 407 5 0 0 0 - - -;
#X obj 274 198 cnv 15 24 24 empty p01_rcv empty 20 12 0 14 -211168
-262144 0;
#X obj 304 198 cnv 15 24 24 empty p02_rcv empty 20 12 0 14 -174112
-262144 0;
#X obj 334 198 cnv 15 24 24 empty p03_rcv empty 20 12 0 14 -170016
-262144 0;
#X obj 364 198 cnv 15 24 24 empty p04_rcv empty 20 12 0 14 -182368
-262144 0;
#X obj 274 228 cnv 15 24 24 empty p05_rcv empty 20 12 0 14 -137025
-262144 0;
#X obj 304 228 cnv 15 24 24 empty p06_rcv empty 20 12 0 14 -174112
-262144 0;
#X obj 334 228 cnv 15 24 24 empty p07_rcv empty 20 12 0 14 -194720
-262144 0;
#X obj 364 228 cnv 15 24 24 empty p08_rcv empty 20 12 0 14 -202912
-262144 0;
#X obj 274 258 cnv 15 24 24 empty p09_rcv empty 20 12 0 14 -132865
-262144 0;
#X obj 304 258 cnv 15 24 24 empty p10_rcv empty 20 12 0 14 -198816
-262144 0;
#X obj 334 258 cnv 15 24 24 empty p11_rcv empty 20 12 0 14 -256480
-262144 0;
#X obj 364 258 cnv 15 24 24 empty p12_rcv empty 20 12 0 14 -260960
-262144 0;
#X obj 274 288 cnv 15 24 24 empty p13_rcv empty 20 12 0 14 -149377
-262144 0;
#X obj 304 288 cnv 15 24 24 empty p14_rcv empty 20 12 0 14 -231776
-262144 0;
#X obj 334 288 cnv 15 24 24 empty p15_rcv empty 20 12 0 14 -260576
-262144 0;
#X obj 364 288 cnv 15 24 24 empty p16_rcv empty 20 12 0 14 -260640
-262144 0;
#X msg 406 231 \; p01_rcv color \$1 0;
#X msg 526 231 \; p02_rcv color \$1 0;
#X msg 646 231 \; p03_rcv

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-25 Thread Julian Brooks 
Just spotted this:
https://github.com/kadamski/i2c-gpio-param
Could be useful


On 25 April 2013 15:54, Martin Peach  wrote:

> On 2013-04-25 10:37, Julian Brooks wrote:
>
>> 'Nother 2 dumb questions:
>> What's the difference between the ones that have spider/centipede type
>> legs and the straight ones (which would be best to get).
>>
>
> The PDIP package is what you want, not the SOIC. The only difference is
> size. DIP packages are human-friendly, surface mount is for robots.
>
>
>  And also are you attaching the MC14051 to any type of board/adaptor or
>> just soldering straight on to the pins?
>>
>
> I have it in a breadboard right now, to make it more permanent I would
> solder a socket to a prototyping board then (after verifying the
> connections) plug the chip into the socket. Soldering to the pins makes it
> difficult to replace the IC, and risks damaging it with the heat if you're
> not good at soldering quickly and to the point. A CD4051 would also work,
> it's basically the same circuit.
>
> Martin
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-25 Thread Martin Peach 

On 2013-04-25 10:37, Julian Brooks wrote:

'Nother 2 dumb questions:
What's the difference between the ones that have spider/centipede type
legs and the straight ones (which would be best to get).


The PDIP package is what you want, not the SOIC. The only difference is 
size. DIP packages are human-friendly, surface mount is for robots.



And also are you attaching the MC14051 to any type of board/adaptor or
just soldering straight on to the pins?


I have it in a breadboard right now, to make it more permanent I would 
solder a socket to a prototyping board then (after verifying the 
connections) plug the chip into the socket. Soldering to the pins makes 
it difficult to replace the IC, and risks damaging it with the heat if 
you're not good at soldering quickly and to the point. A CD4051 would 
also work, it's basically the same circuit.


Martin



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-25 Thread Julian Brooks 
'Nother 2 dumb questions:
What's the difference between the ones that have spider/centipede type legs
and the straight ones (which would be best to get).
And also are you attaching the MC14051 to any type of board/adaptor or just
soldering straight on to the pins?

Thanks for the above info too - really helpful.


On 25 April 2013 14:57, Martin Peach  wrote:

> On 2013-04-25 07:10, Julian Brooks wrote:
>
>>
>> "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:)
>>
>>
> Yesterday I connected a sensor clock line through a MC14051 analog
> multiplexer running at 3.3V, with the sensor side clock pin pulled up to
> 3.3V via a 10k resistor and it works fine. The next step is to switch the
> clock line using a GPIO pin so I can read 2 sensors off the same i2c bus.
> This setup should work with up to 8 sensors with the same address, using 3
> GPIO pins to select a sensor, but the clock line must only be switched
> between 12c reads.
>
>
>
>> 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 10 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)?
>>
>>
> Yes, netbuf is where the string sent to Pd is constructed. It only needs
> to be as large as the message, I made it too long to be sure it wouldn't
> cause trouble. The length doesn't need to be a multiple of anything.
>
>
>
>  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.
>>
>>
> You can comment out any lines with 'printf' in them by prefixing a double
> slash //. I have been running it headless via ssh as:
> nohup ./d6treader 0 >> /dev/null &
> This sends all the text output to nowhere and also keeps the program
> running after I close the connection. (I had it running for a day without
> redirecting output and it nearly filled up the sd card.)
>
> Martin
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-25 Thread Martin Peach 

On 2013-04-25 07:10, Julian Brooks wrote:


"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:)



Yesterday I connected a sensor clock line through a MC14051 analog 
multiplexer running at 3.3V, with the sensor side clock pin pulled up to 
3.3V via a 10k resistor and it works fine. The next step is to switch 
the clock line using a GPIO pin so I can read 2 sensors off the same i2c 
bus. This setup should work with up to 8 sensors with the same address, 
using 3 GPIO pins to select a sensor, but the clock line must only be 
switched between 12c reads.




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 10 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)?



Yes, netbuf is where the string sent to Pd is constructed. It only needs 
to be as large as the message, I made it too long to be sure it wouldn't 
cause trouble. The length doesn't need to be a multiple of anything.




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.



You can comment out any lines with 'printf' in them by prefixing a 
double slash //. I have been running it headless via ssh as:

nohup ./d6treader 0 >> /dev/null &
This sends all the text output to nowhere and also keeps the program 
running after I close the connection. (I had it running for a day 
without redirecting output and it nearly filled up the sd card.)


Martin


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-25 Thread Julian Brooks 
"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 10 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:)

J


On 23 April 2013 14:45, Martin Peach  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 > > 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
>>
>>
>>
>>

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-24 Thread Julian Brooks 
Quick edit for archives:
sudo modprobe i2c)bcn2708 baudrate=9
should be
sudo modprobe i2c_bcm2708 baudrate=9



I tried changing the baud rate with
> sudo modprobe -r i2c_bcm2708
> sudo modprobe i2c)bcn2708 baudrate=9
> but it works fine at the default 10.
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-23 Thread Julian Brooks 
On 23 April 2013 14:45, Martin Peach  wrote:

> Yes that would work too, if you can handle the soldering ;(
>

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.

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.


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).

Another way would be to have the Pd patch request a reading from a specific
> sensor.
>

Can we do that if they have the same address?

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

Yep - it is very specific,  bloody good tho'.

Julian

>
> 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 > > 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 > > 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 > >
>> wrote:
>>
>> On 2013-04-20 21

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-23 Thread Martin Peach 

On 2013-04-23 09:32, Julian Brooks wrote:
...



Maybe there's something I'm missing here then:

The average temp that comes out of [unpack 1] is way higher than the
rest of the readings.  At the moment [unpack 1] says '212' yet a quick
averaging of the other 16 readings is around '180'?



That's right. The first reading is of an internal reference, it's 
usually a few degrees warmer than the environment.


Martin

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-23 Thread Martin Peach 

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 mailto:jbee...@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 mailto:jbee...@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 mailto:martin.pe...@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








___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-23 Thread Julian Brooks 
  and there's a document there that has something about using multiple
> sensors on one bus:
>
> http://www.mouser.com/catalog/specsheets/D6T-01_ThermalIRSensor-Whitepaper.pdf
>
> That's a much better doc.


Seems to me the easiest way to multiplex them would be to put a CD4051 on
> the clock line and use up to 3 GPIO pins to select which of up to 8 sensors
> receives the clock. The only tricky bit would be making sure the clock is
> at the right level when the switching tales place, you might need ~10k
> pullups to 3.3V on the sensor clock pins.


(did you spot my previous post with this and if so would that work?)

 Yes that's what happens already. I was getting errors at first because the
crc calculation was being done over both the write and read packets. I
found that calculating only the read packet gives the correct value
almost always. If the PEC is wrong, the code simply asks for another
packet. At the moment I'm getting almost no errors

Maybe there's something I'm missing here then:

The average temp that comes out of [unpack 1] is way higher than the rest
of the readings.  At the moment [unpack 1] says '212' yet a quick averaging
of the other 16 readings is around '180'?

>
>
Yes, it even works as an icecube detector!


:D
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-23 Thread Martin Peach 

On 2013-04-23 04:42, Julian Brooks 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.



Seems Digikey stopped selling the part, Mouser has it now 
(http://ca.mouser.com/ProductDetail/Omron/D6T-44L-06/?qs=%2fha2pyFaduiRuNG9v%2frw9TOAJzjSw0m3hi0MOmJaH6Q%3d),
 and there's a document there that has something about using multiple 
sensors on one bus:

http://www.mouser.com/catalog/specsheets/D6T-01_ThermalIRSensor-Whitepaper.pdf



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


That will only convert levels, it's not a multiplexer. I found that the 
sensor works fine with the pullups to 3.3V on the RPi.
Seems to me the easiest way to multiplex them would be to put a CD4051 
on the clock line and use up to 3 GPIO pins to select which of up to 8 
sensors receives the clock. The only tricky bit would be making sure the 
clock is at the right level when the switching tales place, you might 
need ~10k pullups to 3.3V on the sensor clock pins.




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?



Yes that's what happens already. I was getting errors at first because 
the crc calculation was being done over both the write and read packets. 
I found that calculating only the read packet gives the correct value 
almost always. If the PEC is wrong, the code simply asks for another 
packet. At the moment I'm getting almost no errors.



Still delighted though - the sensors great!



Yes, it even works as an icecube detector!

Martin


Cheers,

Julian



On 22 April 2013 00:20, Julian Brooks mailto:jbee...@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 mailto:martin.pe...@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







___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-23 Thread Julian Brooks 
Sorry - meant to add this link from RPi forum about running 2 i2c busses:
"enable both i2c busses"
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=33092&p=336846#p336846



On 23 April 2013 10: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  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  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  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



>>>
>>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-23 Thread Julian Brooks 
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  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  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  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
>>>
>>>
>>>
>>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-23 Thread Julian Brooks 
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  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  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
>>
>>
>>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-21 Thread Julian Brooks 
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  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
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-20 Thread Martin Peach 

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



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-20 Thread Martin Peach 
6  7  8  9  a
  b  c  d  e
 f  0123456789abcdef
 00: ff XX XX XX XX XX XX ff XX XX XX XX
ff ff ff XX.XX....X
 10: XX ff XX XX XX XX XX ff XX ff XX ff
XX XX ff XXX.X.X.X.XX.X
 20: ff XX XX ff XX XX ff XX XX XX XX ff
XX XX XX ff.XX.XX..XXX.
 30: XX ff XX ff XX XX XX XX ff ff ff XX
XX XX XX XXX.X....X
 40: XX XX XX ff XX ff XX XX XX 64 XX XX
d5 XX XX ffXXX.X.XXXdXX?XX.
 50: XX ff XX XX XX XX XX XX XX ff XX XX
ff XX XX XXX.XXX.XX.XXX
 60: ff XX XX XX ff XX XX XX XX XX XX XX
XX ff XX XX.XXX..XX
 70: XX XX XX XX XX XX XX ff XX XX XX XX
XX XX XX XXXXX.
 80: XX ff XX XX ff ff XX XX XX ff XX XX
XX XX XX XXX.XX..XXX.XX
 90: XX XX ff XX XX ff XX ff XX ff ff XX
XX ff ff XXXX.XX.X.X..XX..X
 a0: XX ff XX XX ff XX XX XX XX XX XX XX
XX XX ff XXX.XX.X.X
 b0: XX XX ff XX XX XX ff XX XX ff XX XX
XX XX XX XXXX.XXX.XX.XX
 c0: XX XX XX XX ff XX XX ff ff XX XX ff
ff XX XX XX.XX..XX..XXX
 d0: XX XX XX XX XX ff XX ff XX XX XX XX
XX ff XX ffX.X.X.X.
 e0: XX XX XX ff XX ff XX XX XX XX XX XX
XX XX ff XXXXX.X..X
 f0: ff XX ff ff XX XX XX XX XX XX XX XX
XX XX ff XX.X..XX.X


 Progress at least.

 Cheers,

 Julian







 On 12 April 2013 11:27, Julian Brooks
mailto:jbee...@gmail.com>
 <mailto:jbee...@gmail.com
<mailto:jbee...@gmail.com>>> wrote:

 Message resent for thread archives
with smaller picture size.

 Julian

 -- Forwarded message
------
     From: *Julian Brooks*
mailto:jbee...@gmail.com>
<mailto:jbee...@gmail.com
<mailto:jbee...@gmail.com>>>
 Date: 11 April 2013 19:24
 Subject: Re: [PD] Sensors GPIO
Raspberry Pi Pd
 To: Martin Peach
mailto:martin.pe...@sympatico.ca>
 <mailto:martin.peach@__sympatico.ca
<mailto:martin.pe...@sympatico.ca>>>
 Cc: PD List mailto:pd-list@iem.at>
<mailto:pd-list@iem.at
<mailto:pd-list@iem.at>>>


 Hey Martin / list,

 Finally got all the stuff and ...

 It’s not working!

 We spent the day soldering cables
and connecting stuff up as per
 the Omron ‘App Note 01’ spec sheet.

 Started off super-conservative
using the  I2C level converter
 (case 3 page 4)

http://www.adafruit.com/__products/757#Blog/Flickr

<http://www.adafruit.com/products/757#Blog/Flickr>

 We tried resistors on both sides
(being super paranoid!) and
 then we took  the low (Pi) side
ones off.

 We then moved on to case 2 page 3
of this same document…

 At each stage we checked with
“I2Cdetect –Y 1” and nothing was
 visible.

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-20 Thread Martin Peach 
 ff XX ff XX ff
XX XX ff XXX.X.X.X.XX.X
 20: ff XX XX ff XX XX ff XX XX XX XX ff
XX XX XX ff.XX.XX..XXX.
 30: XX ff XX ff XX XX XX XX ff ff ff XX
XX XX XX XXX.X....X
 40: XX XX XX ff XX ff XX XX XX 64 XX XX
d5 XX XX ffXXX.X.XXXdXX?XX.
 50: XX ff XX XX XX XX XX XX XX ff XX XX
ff XX XX XXX.XXX.XX.XXX
 60: ff XX XX XX ff XX XX XX XX XX XX XX
XX ff XX XX.XXX..XX
 70: XX XX XX XX XX XX XX ff XX XX XX XX
XX XX XX XXXXX.
 80: XX ff XX XX ff ff XX XX XX ff XX XX
XX XX XX XXX.XX..XXX.XX
 90: XX XX ff XX XX ff XX ff XX ff ff XX
XX ff ff XXXX.XX.X.X..XX..X
 a0: XX ff XX XX ff XX XX XX XX XX XX XX
XX XX ff XXX.XX.X.X
 b0: XX XX ff XX XX XX ff XX XX ff XX XX
XX XX XX XXXX.XXX.XX.XX
 c0: XX XX XX XX ff XX XX ff ff XX XX ff
ff XX XX XX.XX..XX..XXX
 d0: XX XX XX XX XX ff XX ff XX XX XX XX
XX ff XX ffX.X.X.X.
 e0: XX XX XX ff XX ff XX XX XX XX XX XX
XX XX ff XXXXX.X..X
 f0: ff XX ff ff XX XX XX XX XX XX XX XX
XX XX ff XX.X..XX.X


 Progress at least.

 Cheers,

 Julian







 On 12 April 2013 11:27, Julian Brooks
mailto:jbee...@gmail.com>
 <mailto:jbee...@gmail.com
<mailto:jbee...@gmail.com>>> wrote:

 Message resent for thread archives
with smaller picture size.

 Julian

 -- Forwarded message
------
     From: *Julian Brooks*
mailto:jbee...@gmail.com>
<mailto:jbee...@gmail.com
<mailto:jbee...@gmail.com>>>
 Date: 11 April 2013 19:24
 Subject: Re: [PD] Sensors GPIO
Raspberry Pi Pd
 To: Martin Peach
mailto:martin.pe...@sympatico.ca>
 <mailto:martin.peach@__sympatico.ca
<mailto:martin.pe...@sympatico.ca>>>
 Cc: PD List mailto:pd-list@iem.at>
<mailto:pd-list@iem.at
<mailto:pd-list@iem.at>>>


 Hey Martin / list,

 Finally got all the stuff and ...

 It’s not working!

 We spent the day soldering cables
and connecting stuff up as per
 the Omron ‘App Note 01’ spec sheet.

 Started off super-conservative
using the  I2C level converter
 (case 3 page 4)

http://www.adafruit.com/__products/757#Blog/Flickr

<http://www.adafruit.com/products/757#Blog/Flickr>

 We tried resistors on both sides
(being super paranoid!) and
 then we took  the low (Pi) side
ones off.

 We then moved on to case 2 page 3
of this same document…

 At each stage we checked with
“I2Cdetect –Y 1” and nothing was
 visible.

 The grid shows no attached devices
every time we run it.

 We re-booted at every stage
following the various online
 tutorials/methods of setting up I2C

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-20 Thread Martin Peach 
   30: XX ff XX ff XX XX XX XX ff ff ff XX
XX XX XX XXX.X....X
 40: XX XX XX ff XX ff XX XX XX 64 XX XX
d5 XX XX ffXXX.X.XXXdXX?XX.
 50: XX ff XX XX XX XX XX XX XX ff XX XX
ff XX XX XXX.XXX.XX.XXX
 60: ff XX XX XX ff XX XX XX XX XX XX XX
XX ff XX XX.XXX..XX
 70: XX XX XX XX XX XX XX ff XX XX XX XX
XX XX XX XXXXX.
 80: XX ff XX XX ff ff XX XX XX ff XX XX
XX XX XX XXX.XX..XXX.XX
 90: XX XX ff XX XX ff XX ff XX ff ff XX
XX ff ff XXXX.XX.X.X..XX..X
 a0: XX ff XX XX ff XX XX XX XX XX XX XX
XX XX ff XXX.XX.X.X
 b0: XX XX ff XX XX XX ff XX XX ff XX XX
XX XX XX XXXX.XXX.XX.XX
 c0: XX XX XX XX ff XX XX ff ff XX XX ff
ff XX XX XX.XX..XX..XXX
 d0: XX XX XX XX XX ff XX ff XX XX XX XX
XX ff XX ffX.X.X.X.
 e0: XX XX XX ff XX ff XX XX XX XX XX XX
XX XX ff XXXXX.X..X
 f0: ff XX ff ff XX XX XX XX XX XX XX XX
XX XX ff XX.X..XX.X


 Progress at least.

 Cheers,

 Julian







 On 12 April 2013 11:27, Julian Brooks
mailto:jbee...@gmail.com>
 <mailto:jbee...@gmail.com
<mailto:jbee...@gmail.com>>> wrote:

 Message resent for thread archives
with smaller picture size.

 Julian

 -- Forwarded message --
                 From: *Julian Brooks*
        mailto:jbee...@gmail.com>
<mailto:jbee...@gmail.com
<mailto:jbee...@gmail.com>>>
 Date: 11 April 2013 19:24
 Subject: Re: [PD] Sensors GPIO
Raspberry Pi Pd
 To: Martin Peach
mailto:martin.pe...@sympatico.ca>
 <mailto:martin.peach@__sympatico.ca
<mailto:martin.pe...@sympatico.ca>>>
 Cc: PD List mailto:pd-list@iem.at>
<mailto:pd-list@iem.at <mailto:pd-list@iem.at>>>


 Hey Martin / list,

 Finally got all the stuff and ...

 It’s not working!

 We spent the day soldering cables
and connecting stuff up as per
 the Omron ‘App Note 01’ spec sheet.

 Started off super-conservative
using the  I2C level converter
 (case 3 page 4)
http://www.adafruit.com/__products/757#Blog/Flickr
<http://www.adafruit.com/products/757#Blog/Flickr>

 We tried resistors on both sides
(being super paranoid!) and
 then we took  the low (Pi) side
ones off.

 We then moved on to case 2 page 3
of this same document…

 At each stage we checked with
“I2Cdetect –Y 1” and nothing was
 visible.

 The grid shows no attached devices
every time we run it.

 We re-booted at every stage
following the various online
 tutorials/methods of setting up I2C
GPIO on the Pi (checked &
 double checked).


 As you can see

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-19 Thread Julian Brooks 
on only works half the time, as I also found on the Arduino. All 
>>>>>> you
>>>>>> need to do is write the 0x4C command once, wait a millisecond or so and
>>>>>> then read it.
>>>>>> Another issue is that I tried this with the 8X1 sensor, not the 4X4
>>>>>> one, so the code reads 19 bytes (need to change the expected read size in
>>>>>> the code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c
>>>>>> driver maximum, so you may not get the last part of a packet.
>>>>>> I'll try it later with a 4X4 sensor to see what happens.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>> On 2013-04-19 07:01, Julian Brooks wrote:
>>>>>>
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> Did you manage to make any progress with the sensor on the Pi?
>>>>>>> I also wanted to ask whether the output we're receiving from i2cdump
>>>>>>> makes any sense to you as it doesn't to us currently?  Tried
>>>>>>> searching
>>>>>>> around for possible info on the 'XX' & 'ff' but drawing a blank here.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Julian
>>>>>>>
>>>>>>>
>>>>>>> On 13 April 2013 01:11, Julian Brooks >>>>>> <mailto:jbee...@gmail.com>> wrote:
>>>>>>>
>>>>>>> Hey all,
>>>>>>>
>>>>>>> Some success finally:
>>>>>>>
>>>>>>> Hurrah!!
>>>>>>>
>>>>>>> The scl breakout pin on the pi proto plate wasn't working
>>>>>>> properly.
>>>>>>>
>>>>>>> When unscrewed halfway it works, when fully screwed in it
>>>>>>> doesn't.
>>>>>>>
>>>>>>> So - now got this:
>>>>>>>
>>>>>>> i2cdetect -y 0
>>>>>>>
>>>>>>> 0 1 2 3 4 5 6 7 8 9 a b c d e f
>>>>>>>
>>>>>>> 00: -- -- -- -- -- -- -- 0a -- -- -- -- --
>>>>>>>
>>>>>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>>>
>>>>>>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>>>
>>>>>>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>>>
>>>>>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>>>
>>>>>>> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>>>
>>>>>>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>>>
>>>>>>> 70: -- -- -- -- -- -- -- --
>>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>>     i2cdump -y 0 0xa
>>>>>>> No size specified (using byte-data access)
>>>>>>>
>>>>>>> Gives a whole host of stuff I don't yet understand but I don't
>>>>>>> care
>>>>>>> currently as something is actually happening.
>>>>>>>
>>>>>>> Will figure out a way of saving the console info (any hints
>>>>>>> anyone?)  as it gets badly mangled when cutting and pasting  but
>>>>>>> basically something like this:
>>>>>>>
>>>>>>> i2cdump -y 0 0xa
>>>>>>> No size specified (using byte-data access)
>>>>>>>   0  1  2  3  4  5  6  7  8  9  a  b  c  d  e
>>>>>>> f  0123456789abcdef
>>>>>>> 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX
>>>>>>>  .XX....X
>>>>>>> 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX
>>>>>>>  X.X.X.X.XX.X
>>>>>>> 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff
>>>>>>>  .XX.XX..XXX.
>>>>>>> 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX
>>>>>>>  X.X....XX

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-19 Thread Julian Brooks 
;>> around for possible info on the 'XX' & 'ff' but drawing a blank here.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Julian
>>>>>>
>>>>>>
>>>>>> On 13 April 2013 01:11, Julian Brooks >>>>> <mailto:jbee...@gmail.com>> wrote:
>>>>>>
>>>>>> Hey all,
>>>>>>
>>>>>> Some success finally:
>>>>>>
>>>>>> Hurrah!!
>>>>>>
>>>>>> The scl breakout pin on the pi proto plate wasn't working
>>>>>> properly.
>>>>>>
>>>>>> When unscrewed halfway it works, when fully screwed in it doesn't.
>>>>>>
>>>>>> So - now got this:
>>>>>>
>>>>>> i2cdetect -y 0
>>>>>>
>>>>>> 0 1 2 3 4 5 6 7 8 9 a b c d e f
>>>>>>
>>>>>> 00: -- -- -- -- -- -- -- 0a -- -- -- -- --
>>>>>>
>>>>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>>
>>>>>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>>
>>>>>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>>
>>>>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>>
>>>>>> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>>
>>>>>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>>
>>>>>> 70: -- -- -- -- -- -- -- --
>>>>>>
>>>>>> and
>>>>>>
>>>>>> i2cdump -y 0 0xa
>>>>>> No size specified (using byte-data access)
>>>>>>
>>>>>> Gives a whole host of stuff I don't yet understand but I don't
>>>>>> care
>>>>>> currently as something is actually happening.
>>>>>>
>>>>>> Will figure out a way of saving the console info (any hints
>>>>>> anyone?)  as it gets badly mangled when cutting and pasting  but
>>>>>> basically something like this:
>>>>>>
>>>>>> i2cdump -y 0 0xa
>>>>>> No size specified (using byte-data access)
>>>>>>   0  1  2  3  4  5  6  7  8  9  a  b  c  d  e
>>>>>> f  0123456789abcdef
>>>>>> 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX
>>>>>>  .XX....X
>>>>>> 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX
>>>>>>  X.X.X.X.XX.X
>>>>>> 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff
>>>>>>  .XX.XX..XXX.
>>>>>> 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX
>>>>>>  X.X....X
>>>>>> 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff
>>>>>>  XXX.X.XXXdXX?XX.
>>>>>> 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX
>>>>>>  X.XXX.XX.XXX
>>>>>> 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX
>>>>>>  .XXX..XX
>>>>>> 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX
>>>>>>  XXX.
>>>>>> 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX
>>>>>>  X.XX..XXX.XX
>>>>>> 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX
>>>>>>  XX.XX.X.X..XX..X
>>>>>> a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX
>>>>>>  X.XX.X.X
>>>>>> b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX
>>>>>>  XX.XXX.XX.XX
>>>>>> c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX
>>>>>>  .XX..XX..XXX
>>>>>> d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff
>>>>>>  X.X.X.X.
>>>>>> e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX
>>>>>>  XXX.X..X
>>>>>> f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX
>>>>>>  .X..XX.X
>>>>>>
>>>>>>
>>>>>> Prog

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-19 Thread Julian Brooks 
>>>> When unscrewed halfway it works, when fully screwed in it doesn't.
>>>>>
>>>>> So - now got this:
>>>>>
>>>>> i2cdetect -y 0
>>>>>
>>>>> 0 1 2 3 4 5 6 7 8 9 a b c d e f
>>>>>
>>>>> 00: -- -- -- -- -- -- -- 0a -- -- -- -- --
>>>>>
>>>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>
>>>>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>
>>>>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>
>>>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>
>>>>> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>
>>>>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>>
>>>>> 70: -- -- -- -- -- -- -- --
>>>>>
>>>>> and
>>>>>
>>>>> i2cdump -y 0 0xa
>>>>> No size specified (using byte-data access)
>>>>>
>>>>> Gives a whole host of stuff I don't yet understand but I don't care
>>>>> currently as something is actually happening.
>>>>>
>>>>> Will figure out a way of saving the console info (any hints
>>>>> anyone?)  as it gets badly mangled when cutting and pasting  but
>>>>> basically something like this:
>>>>>
>>>>> i2cdump -y 0 0xa
>>>>> No size specified (using byte-data access)
>>>>>   0  1  2  3  4  5  6  7  8  9  a  b  c  d  e
>>>>> f  0123456789abcdef
>>>>> 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX
>>>>>  .XX....X
>>>>> 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX
>>>>>  X.X.X.X.XX.X
>>>>> 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff
>>>>>  .XX.XX..XXX.
>>>>> 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX
>>>>>  X.X....X
>>>>> 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff
>>>>>  XXX.X.XXXdXX?XX.
>>>>> 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX
>>>>>  X.XXX.XX.XXX
>>>>> 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX
>>>>>  .XXX..XX
>>>>> 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX
>>>>>  XXX.
>>>>> 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX
>>>>>  X.XX..XXX.XX
>>>>> 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX
>>>>>  XX.XX.X.X..XX..X
>>>>> a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX
>>>>>  X.XX.X.X
>>>>> b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX
>>>>>  XX.XXX.XX.XX
>>>>> c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX
>>>>>  .XX..XX..XXX
>>>>> d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff
>>>>>  X.X.X.X.
>>>>> e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX
>>>>>  XXX.X..X
>>>>> f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX
>>>>>  .X..XX.X
>>>>>
>>>>>
>>>>> Progress at least.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Julian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 12 April 2013 11:27, Julian Brooks >>>> <mailto:jbee...@gmail.com>> wrote:
>>>>>
>>>>> Message resent for thread archives with smaller picture size.
>>>>>
>>>>> Julian
>>>>>
>>>>> -- Forwarded message --
>>>>> From: *Julian Brooks* >>>> jbee...@gmail.com>>
>>>>> Date: 11 April 2013 19:24
>>>>> Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd
>>>>> To: Martin Peach >>>> <mailto:martin.peach@**sympatico.ca
>>>>> >>
>>>>> Cc: PD List mailto:pd-list@iem.at>>
>>>>>
>&g

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-19 Thread Julian Brooks 
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>
>>>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>
>>>> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>
>>>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>>>
>>>> 70: -- -- -- -- -- -- -- --
>>>>
>>>> and
>>>>
>>>> i2cdump -y 0 0xa
>>>> No size specified (using byte-data access)
>>>>
>>>> Gives a whole host of stuff I don't yet understand but I don't care
>>>> currently as something is actually happening.
>>>>
>>>> Will figure out a way of saving the console info (any hints
>>>> anyone?)  as it gets badly mangled when cutting and pasting  but
>>>> basically something like this:
>>>>
>>>> i2cdump -y 0 0xa
>>>> No size specified (using byte-data access)
>>>>   0  1  2  3  4  5  6  7  8  9  a  b  c  d  e
>>>> f  0123456789abcdef
>>>> 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX
>>>>  .XX....X
>>>> 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX
>>>>  X.X.X.X.XX.X
>>>> 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff
>>>>  .XX.XX..XXX.
>>>> 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX
>>>>  X.X....X
>>>> 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff
>>>>  XXX.X.XXXdXX?XX.
>>>> 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX
>>>>  X.XXX.XX.XXX
>>>> 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX
>>>>  .XXX..XX
>>>> 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX
>>>>  XXX.
>>>> 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX
>>>>  X.XX..XXX.XX
>>>> 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX
>>>>  XX.XX.X.X..XX..X
>>>> a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX
>>>>  X.XX.X.X
>>>> b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX
>>>>  XX.XXX.XX.XX
>>>> c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX
>>>>  .XX..XX..XXX
>>>> d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff
>>>>  X.X.X.X.
>>>> e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX
>>>>  XXX.X..X
>>>> f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX
>>>>  .X..XX.X
>>>>
>>>>
>>>> Progress at least.
>>>>
>>>> Cheers,
>>>>
>>>> Julian
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 12 April 2013 11:27, Julian Brooks >>> <mailto:jbee...@gmail.com>> wrote:
>>>>
>>>> Message resent for thread archives with smaller picture size.
>>>>
>>>> Julian
>>>>
>>>> -- Forwarded message --
>>>> From: *Julian Brooks* >>> jbee...@gmail.com>>
>>>> Date: 11 April 2013 19:24
>>>> Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd
>>>> To: Martin Peach >>> <mailto:martin.peach@**sympatico.ca 
>>>> >>
>>>> Cc: PD List mailto:pd-list@iem.at>>
>>>>
>>>>
>>>> Hey Martin / list,
>>>>
>>>> Finally got all the stuff and ...
>>>>
>>>> It’s not working!
>>>>
>>>> We spent the day soldering cables and connecting stuff up as per
>>>> the Omron ‘App Note 01’ spec sheet.
>>>>
>>>> Started off super-conservative using the  I2C level converter
>>>> (case 3 page 4) http://www.adafruit.com/**
>>>> products/757#Blog/Flickr<http://www.adafruit.com/products/757#Blog/Flickr>
>>>>
>>>> We tried resistors on both sides (being super paranoid!) and
>>>> then we took  the low (Pi) side ones off.
>>>>
>>>> We then moved on to case 2 page 3 of this same document…
>>>>
>>>> At each stage we c

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-19 Thread Julian Brooks 
t understand but I don't care
>>> currently as something is actually happening.
>>>
>>> Will figure out a way of saving the console info (any hints
>>> anyone?)  as it gets badly mangled when cutting and pasting  but
>>> basically something like this:
>>>
>>> i2cdump -y 0 0xa
>>> No size specified (using byte-data access)
>>>   0  1  2  3  4  5  6  7  8  9  a  b  c  d  e
>>> f  0123456789abcdef
>>> 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX
>>>  .XX....X
>>> 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX
>>>  X.X.X.X.XX.X
>>> 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff
>>>  .XX.XX..XXX.
>>> 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX
>>>  X.X....X
>>> 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff
>>>  XXX.X.XXXdXX?XX.
>>> 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX
>>>  X.XXX.XX.XXX
>>> 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX
>>>  .XXX..XX
>>> 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX
>>>  XXX.
>>> 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX
>>>  X.XX..XXX.XX
>>> 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX
>>>  XX.XX.X.X..XX..X
>>> a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX
>>>  X.XX.X.X
>>> b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX
>>>  XX.XXX.XX.XX
>>> c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX
>>>  .XX..XX..XXX
>>> d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff
>>>  X.X.X.X.
>>> e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX
>>>  XXX.X..X
>>> f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX
>>>  .X..XX.X
>>>
>>>
>>> Progress at least.
>>>
>>> Cheers,
>>>
>>> Julian
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 12 April 2013 11:27, Julian Brooks >> <mailto:jbee...@gmail.com>> wrote:
>>>
>>> Message resent for thread archives with smaller picture size.
>>>
>>> Julian
>>>
>>> -- Forwarded message --
>>> From: *Julian Brooks* >> jbee...@gmail.com>>
>>> Date: 11 April 2013 19:24
>>> Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd
>>> To: Martin Peach >> <mailto:martin.peach@**sympatico.ca 
>>> >>
>>> Cc: PD List mailto:pd-list@iem.at>>
>>>
>>>
>>> Hey Martin / list,
>>>
>>> Finally got all the stuff and ...
>>>
>>> It’s not working!
>>>
>>> We spent the day soldering cables and connecting stuff up as per
>>> the Omron ‘App Note 01’ spec sheet.
>>>
>>> Started off super-conservative using the  I2C level converter
>>> (case 3 page 4) http://www.adafruit.com/**
>>> products/757#Blog/Flickr<http://www.adafruit.com/products/757#Blog/Flickr>
>>>
>>> We tried resistors on both sides (being super paranoid!) and
>>> then we took  the low (Pi) side ones off.
>>>
>>> We then moved on to case 2 page 3 of this same document…
>>>
>>> At each stage we checked with “I2Cdetect –Y 1” and nothing was
>>> visible.
>>>
>>> The grid shows no attached devices every time we run it.
>>>
>>> We re-booted at every stage following the various online
>>> tutorials/methods of setting up I2C GPIO on the Pi (checked &
>>> double checked).
>>>
>>>
>>> As you can see we’re using a pi protoplate:
>>>
>>> 
>>> https://www.adafruit.com/**products/801<https://www.adafruit.com/products/801>
>>>
>>> In the photo I’ve attached the cables are coded as follows:
>>>
>>> Orange   GND
>>>
>>> Yellow5v
>>>
>>> BlueSCL
>>>
>>> Green SDA
>>>
>>> The white is also 5v for the pull up resistors.
>>>
>>> The resistor values are 4.7k btw.
>>>
>>> We have tested the cable that terminates at the sensor and all
>>> that is OK.
>>>
>>> I put a multimeter on the GND and SDA solder points on the
>>> sensor itself and got 3.7v…
>>>
>>> I put a multimeter on the GND and SCL solder points on the
>>> sensor itself and got 0.0v…
>>>
>>> Don’t know if this means anything or could be useful to know!
>>>
>>> Stuck and frustrated now but hey, 3 weeks ago I knew absolutely
>>> bugger all about any of this and now I do (sort of).
>>>
>>> I'm thinking we could do with the most basic i2c sensor we can
>>> find as we have nothing to compare.
>>>
>>> Tonight I'm going to d/l a fresh raspbian and start from scratch
>>> to check that end.
>>>
>>> Feel like if we can't get past the 'i2c-tools' tests we're
>>> screwed - never mind getting it in and out of Pd.
>>>
>>> Any thoughts/pointers/options from anyone will be really
>>> appreciated?
>>>
>>>
>>> Cheers,
>>>
>>>
>>> Julian
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> __**_
>>> Pd-list@iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/**
>>> listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>
>>>
>>>
>>
>


hello-2.changes
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-19 Thread Julian Brooks 
>> b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX
>>  XX.XXX.XX.XX
>> c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX
>>  XXXX.XX..XX..XXX
>> d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff
>>  X.X.X.X.
>> e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX
>>  XXX.X..X
>> f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX
>>  .X..XX.X
>>
>>
>> Progress at least.
>>
>> Cheers,
>>
>> Julian
>>
>>
>>
>>
>>
>>
>>
>> On 12 April 2013 11:27, Julian Brooks > <mailto:jbee...@gmail.com>> wrote:
>>
>> Message resent for thread archives with smaller picture size.
>>
>> Julian
>>
>> -- Forwarded message --
>> From: *Julian Brooks* > jbee...@gmail.com>>
>> Date: 11 April 2013 19:24
>> Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd
>> To: Martin Peach > <mailto:martin.peach@**sympatico.ca >>
>> Cc: PD List mailto:pd-list@iem.at>>
>>
>>
>> Hey Martin / list,
>>
>> Finally got all the stuff and ...
>>
>> It’s not working!
>>
>> We spent the day soldering cables and connecting stuff up as per
>> the Omron ‘App Note 01’ spec sheet.
>>
>> Started off super-conservative using the  I2C level converter
>> (case 3 page 4) http://www.adafruit.com/**
>> products/757#Blog/Flickr<http://www.adafruit.com/products/757#Blog/Flickr>
>>
>> We tried resistors on both sides (being super paranoid!) and
>> then we took  the low (Pi) side ones off.
>>
>> We then moved on to case 2 page 3 of this same document…
>>
>> At each stage we checked with “I2Cdetect –Y 1” and nothing was
>> visible.
>>
>> The grid shows no attached devices every time we run it.
>>
>> We re-booted at every stage following the various online
>> tutorials/methods of setting up I2C GPIO on the Pi (checked &
>> double checked).
>>
>>
>> As you can see we’re using a pi protoplate:
>>
>> 
>> https://www.adafruit.com/**products/801<https://www.adafruit.com/products/801>
>>
>> In the photo I’ve attached the cables are coded as follows:
>>
>> Orange   GND
>>
>> Yellow5v
>>
>> BlueSCL
>>
>> Green SDA
>>
>> The white is also 5v for the pull up resistors.
>>
>> The resistor values are 4.7k btw.
>>
>> We have tested the cable that terminates at the sensor and all
>> that is OK.
>>
>> I put a multimeter on the GND and SDA solder points on the
>> sensor itself and got 3.7v…
>>
>> I put a multimeter on the GND and SCL solder points on the
>> sensor itself and got 0.0v…
>>
>> Don’t know if this means anything or could be useful to know!
>>
>> Stuck and frustrated now but hey, 3 weeks ago I knew absolutely
>> bugger all about any of this and now I do (sort of).
>>
>> I'm thinking we could do with the most basic i2c sensor we can
>> find as we have nothing to compare.
>>
>> Tonight I'm going to d/l a fresh raspbian and start from scratch
>> to check that end.
>>
>> Feel like if we can't get past the 'i2c-tools' tests we're
>> screwed - never mind getting it in and out of Pd.
>>
>> Any thoughts/pointers/options from anyone will be really
>> appreciated?
>>
>>
>> Cheers,
>>
>>
>> Julian
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> __**_
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/**
>> listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>
>>
>>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-19 Thread Julian Brooks 
 XX XX XX
>>>  XXX.
>>> 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX
>>>  X.XX..XXX.XX
>>> 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX
>>>  XX.XX.X.X..XX..X
>>> a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX
>>>  X.XX.X.X
>>> b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX
>>>  XX.XXX.XX.XX
>>> c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX
>>>  .XX..XX..XXX
>>> d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ff
>>>  X.X.X.X.
>>> e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XX
>>>  XXX.X..X
>>> f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX
>>>  .X..XX.X
>>>
>>>
>>> Progress at least.
>>>
>>> Cheers,
>>>
>>> Julian
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 12 April 2013 11:27, Julian Brooks >> <mailto:jbee...@gmail.com>> wrote:
>>>
>>> Message resent for thread archives with smaller picture size.
>>>
>>> Julian
>>>
>>> -- Forwarded message --
>>> From: *Julian Brooks* >> jbee...@gmail.com>>
>>> Date: 11 April 2013 19:24
>>> Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd
>>> To: Martin Peach >> <mailto:martin.peach@**sympatico.ca 
>>> >>
>>> Cc: PD List mailto:pd-list@iem.at>>
>>>
>>>
>>> Hey Martin / list,
>>>
>>> Finally got all the stuff and ...
>>>
>>> It’s not working!
>>>
>>> We spent the day soldering cables and connecting stuff up as per
>>> the Omron ‘App Note 01’ spec sheet.
>>>
>>> Started off super-conservative using the  I2C level converter
>>> (case 3 page 4) http://www.adafruit.com/**
>>> products/757#Blog/Flickr<http://www.adafruit.com/products/757#Blog/Flickr>
>>>
>>> We tried resistors on both sides (being super paranoid!) and
>>> then we took  the low (Pi) side ones off.
>>>
>>> We then moved on to case 2 page 3 of this same document…
>>>
>>> At each stage we checked with “I2Cdetect –Y 1” and nothing was
>>> visible.
>>>
>>> The grid shows no attached devices every time we run it.
>>>
>>> We re-booted at every stage following the various online
>>> tutorials/methods of setting up I2C GPIO on the Pi (checked &
>>> double checked).
>>>
>>>
>>> As you can see we’re using a pi protoplate:
>>>
>>> 
>>> https://www.adafruit.com/**products/801<https://www.adafruit.com/products/801>
>>>
>>> In the photo I’ve attached the cables are coded as follows:
>>>
>>> Orange   GND
>>>
>>> Yellow5v
>>>
>>> BlueSCL
>>>
>>> Green SDA
>>>
>>> The white is also 5v for the pull up resistors.
>>>
>>> The resistor values are 4.7k btw.
>>>
>>> We have tested the cable that terminates at the sensor and all
>>> that is OK.
>>>
>>> I put a multimeter on the GND and SDA solder points on the
>>> sensor itself and got 3.7v…
>>>
>>> I put a multimeter on the GND and SCL solder points on the
>>> sensor itself and got 0.0v…
>>>
>>> Don’t know if this means anything or could be useful to know!
>>>
>>> Stuck and frustrated now but hey, 3 weeks ago I knew absolutely
>>> bugger all about any of this and now I do (sort of).
>>>
>>> I'm thinking we could do with the most basic i2c sensor we can
>>> find as we have nothing to compare.
>>>
>>> Tonight I'm going to d/l a fresh raspbian and start from scratch
>>> to check that end.
>>>
>>> Feel like if we can't get past the 'i2c-tools' tests we're
>>> screwed - never mind getting it in and out of Pd.
>>>
>>> Any thoughts/pointers/options from anyone will be really
>>> appreciated?
>>>
>>>
>>> Cheers,
>>>
>>>
>>> Julian
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> __**_
>>> Pd-list@iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/**
>>> listinfo/pd-list <http://lists.puredata.info/listinfo/pd-list>
>>>
>>>
>>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-19 Thread Julian Brooks 
Hey Martin,

This is wonderful news.

Will add some more when I have an opportunity to test it out.

Yah!

Julian


On 19 April 2013 14:36, Martin Peach  wrote:

> Hi Julian,
> Yes I've been messing with coding it in c on the pi and sending the data
> to a [netreceive] in a Pd patch on another machine. I'm attaching the
> source code for the pi part and the Pd patch.
> The code can be compiled on the pi with
> gcc -o hello hello.c
> You need to set the IP address of the receiving machine in the code (I
> have 192.168.2.15, it could be 127.0.0.1 for the same machine).
> I tried changing the baud rate with
> sudo modprobe -r i2c_bcm2708
> sudo modprobe i2c)bcn2708 baudrate=9
> but it works fine at the default 10.
> It seems that you only need to write the command once, after that simply
> reading gets you another packet. Using a combined write/read operation only
> works half the time, as I also found on the Arduino. All you need to do is
> write the 0x4C command once, wait a millisecond or so and then read it.
> Another issue is that I tried this with the 8X1 sensor, not the 4X4 one,
> so the code reads 19 bytes (need to change the expected read size in the
> code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver
> maximum, so you may not get the last part of a packet.
> I'll try it later with a 4X4 sensor to see what happens.
>
> Martin
>
>
> On 2013-04-19 07:01, Julian Brooks wrote:
>
>> Hi Martin,
>>
>> Did you manage to make any progress with the sensor on the Pi?
>> I also wanted to ask whether the output we're receiving from i2cdump
>> makes any sense to you as it doesn't to us currently?  Tried searching
>> around for possible info on the 'XX' & 'ff' but drawing a blank here.
>>
>> Cheers,
>>
>> Julian
>>
>>
>> On 13 April 2013 01:11, Julian Brooks > <mailto:jbee...@gmail.com>> wrote:
>>
>> Hey all,
>>
>> Some success finally:
>>
>> Hurrah!!
>>
>> The scl breakout pin on the pi proto plate wasn't working properly.
>>
>> When unscrewed halfway it works, when fully screwed in it doesn't.
>>
>> So - now got this:
>>
>> i2cdetect -y 0
>>
>> 0 1 2 3 4 5 6 7 8 9 a b c d e f
>>
>> 00: -- -- -- -- -- -- -- 0a -- -- -- -- --
>>
>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>
>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>
>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>
>> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>
>> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>
>> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>
>> 70: -- -- -- -- -- -- -- --
>>
>> and
>>
>> i2cdump -y 0 0xa
>> No size specified (using byte-data access)
>>
>> Gives a whole host of stuff I don't yet understand but I don't care
>> currently as something is actually happening.
>>
>> Will figure out a way of saving the console info (any hints
>> anyone?)  as it gets badly mangled when cutting and pasting  but
>> basically something like this:
>>
>> i2cdump -y 0 0xa
>> No size specified (using byte-data access)
>>   0  1  2  3  4  5  6  7  8  9  a  b  c  d  e
>> f  0123456789abcdef
>> 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX
>>  .XX....X
>> 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XX
>>  X.X.X.X.XX.X
>> 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff
>>  .XX.XX..XXX.
>> 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XX
>>  X.X....X
>> 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ff
>>  XXX.X.XXXdXX?XX.
>> 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XX
>>  X.XXX.XX.XXX
>> 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX
>>  .XXX..XX
>> 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XX
>>  XXX.
>> 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XX
>>  X.XX..XXX.XX
>> 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XX
>>  XX.XX.X.X..XX..X
>> a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XX
>>  X.XX.X.X
>> b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XX
>>  XX.XXX.XX.XX
>> c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX
>>  .XX..XX..XXX
>> d0: XX XX XX XX XX ff XX ff XX XX XX XX

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-19 Thread Martin Peach 

Hi Julian,
Yes I've been messing with coding it in c on the pi and sending the data 
to a [netreceive] in a Pd patch on another machine. I'm attaching the 
source code for the pi part and the Pd patch.

The code can be compiled on the pi with
gcc -o hello hello.c
You need to set the IP address of the receiving machine in the code (I 
have 192.168.2.15, it could be 127.0.0.1 for the same machine).

I tried changing the baud rate with
sudo modprobe -r i2c_bcm2708
sudo modprobe i2c)bcn2708 baudrate=9
but it works fine at the default 10.
It seems that you only need to write the command once, after that simply 
reading gets you another packet. Using a combined write/read operation 
only works half the time, as I also found on the Arduino. All you need 
to do is write the 0x4C command once, wait a millisecond or so and then 
read it.
Another issue is that I tried this with the 8X1 sensor, not the 4X4 one, 
so the code reads 19 bytes (need to change the expected read size in the 
code). The 4X4 sensor sends 35 bytes which is 3 more than the i2c driver 
maximum, so you may not get the last part of a packet.

I'll try it later with a 4X4 sensor to see what happens.

Martin

On 2013-04-19 07:01, Julian Brooks wrote:

Hi Martin,

Did you manage to make any progress with the sensor on the Pi?
I also wanted to ask whether the output we're receiving from i2cdump
makes any sense to you as it doesn't to us currently?  Tried searching
around for possible info on the 'XX' & 'ff' but drawing a blank here.

Cheers,

Julian


On 13 April 2013 01:11, Julian Brooks mailto:jbee...@gmail.com>> wrote:

Hey all,

Some success finally:

Hurrah!!

The scl breakout pin on the pi proto plate wasn't working properly.

When unscrewed halfway it works, when fully screwed in it doesn't.

So - now got this:

i2cdetect -y 0

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- 0a -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

and

i2cdump -y 0 0xa
No size specified (using byte-data access)

Gives a whole host of stuff I don't yet understand but I don't care
currently as something is actually happening.

Will figure out a way of saving the console info (any hints
anyone?)  as it gets badly mangled when cutting and pasting  but
basically something like this:

i2cdump -y 0 0xa
No size specified (using byte-data access)
  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e
f  0123456789abcdef
00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX.XX....X
10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XXX.X.X.X.XX.X
20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff.XX.XX..XXX.
30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XXX.X....X
40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ffXXX.X.XXXdXX?XX.
50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XXX.XXX.XX.XXX
60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX.XXX..XX
70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XXXXX.
80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XXX.XX..XXX.XX
90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XXXX.XX.X.X..XX..X
a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XXX.XX.X.X
b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XXXX.XXX.XX.XX
c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX.XX..XX..XXX
d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ffX.X.X.X.
e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XXXXX.X..X
f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX.X..XX.X


Progress at least.

Cheers,

Julian







On 12 April 2013 11:27, Julian Brooks mailto:jbee...@gmail.com>> wrote:

Message resent for thread archives with smaller picture size.

Julian

-- Forwarded message --
From: *Julian Brooks* mailto:jbee...@gmail.com>>
    Date: 11 April 2013 19:24
Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd
To: Martin Peach mailto:martin.pe...@sympatico.ca>>
Cc: PD List mailto:pd-list@iem.at>>


Hey Martin / list,

Finally got all the stuff and ...

It’s not working!

We spent the day soldering cables and connecting stuff up as per
the Omron ‘App Note 01’ spec sheet.

Started off super-conservative using the  I2C level converter
(case 3 page 4

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-19 Thread Julian Brooks 
Hi Martin,

Did you manage to make any progress with the sensor on the Pi?
I also wanted to ask whether the output we're receiving from i2cdump makes
any sense to you as it doesn't to us currently?  Tried searching around for
possible info on the 'XX' & 'ff' but drawing a blank here.

Cheers,

Julian


On 13 April 2013 01:11, Julian Brooks  wrote:

> Hey all,
>
> Some success finally:
>
> Hurrah!!
>
> The scl breakout pin on the pi proto plate wasn't working properly.
>
> When unscrewed halfway it works, when fully screwed in it doesn't.
>
> So - now got this:
>
> i2cdetect -y 0
>
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
>
> 00: -- -- -- -- -- -- -- 0a -- -- -- -- --
>
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
> 70: -- -- -- -- -- -- -- --
>
> and
>
> i2cdump -y 0 0xa
> No size specified (using byte-data access)
>
> Gives a whole host of stuff I don't yet understand but I don't care
> currently as something is actually happening.
>
> Will figure out a way of saving the console info (any hints anyone?)  as
> it gets badly mangled when cutting and pasting  but basically something
> like this:
>
> i2cdump -y 0 0xa
> No size specified (using byte-data access)
>  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 0123456789abcdef
> 00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX.XX....X
> 10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XXX.X.X.X.XX.X
> 20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff.XX.XX..XXX.
> 30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XXX.X....X
> 40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ffXXX.X.XXXdXX?XX.
> 50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XXX.XXX.XX.XXX
> 60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX.XXX..XX
> 70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XXXXX.
> 80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XXX.XX..XXX.XX
> 90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XXXX.XX.X.X..XX..X
> a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XXX.XX.X.X
> b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XXXX.XXX.XX.XX
> c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX.XX..XX..XXX
> d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ffX.X.X.X.
> e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XXXXX.X..X
> f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX.X..XX.X
>
>
> Progress at least.
>
> Cheers,
>
> Julian
>
>
>
>
>
>
>
> On 12 April 2013 11:27, Julian Brooks  wrote:
>
>> Message resent for thread archives with smaller picture size.
>>
>> Julian
>>
>> -- Forwarded message --
>> From: Julian Brooks 
>> Date: 11 April 2013 19:24
>> Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd
>> To: Martin Peach 
>> Cc: PD List 
>>
>>
>> Hey Martin / list,
>>
>> Finally got all the stuff and ...
>>
>> It’s not working!
>>
>> We spent the day soldering cables and connecting stuff up as per the
>> Omron ‘App Note 01’ spec sheet.
>>
>> Started off super-conservative using the  I2C level converter (case 3
>> page 4) http://www.adafruit.com/products/757#Blog/Flickr
>>
>> We tried resistors on both sides (being super paranoid!) and then we
>> took  the low (Pi) side ones off.
>>
>> We then moved on to case 2 page 3 of this same document…
>>
>>  At each stage we checked with “I2Cdetect –Y 1” and nothing was visible.
>>
>> The grid shows no attached devices every time we run it.
>>
>> We re-booted at every stage following the various online
>> tutorials/methods of setting up I2C GPIO on the Pi (checked & double
>> checked).
>>
>>
>>  As you can see we’re using a pi protoplate:
>>
>> https://www.adafruit.com/products/801
>>
>>
>>
>> In the photo I’ve attached the cables are coded as follows:
>>
>>
>>
>> Orange   GND
>>
>> Yellow5v
>>
>> BlueSCL
>>
>> Green SDA
>>
>>
>>
>> The white is also 5v for the pull up resistors.
>>
>> The resistor values are 4.7k btw.
>>
>>
>>
>> We have tes

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-12 Thread Julian Brooks 
Hey all,

Some success finally:

Hurrah!!

The scl breakout pin on the pi proto plate wasn't working properly.

When unscrewed halfway it works, when fully screwed in it doesn't.

So - now got this:

i2cdetect -y 0

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- 0a -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

and

i2cdump -y 0 0xa
No size specified (using byte-data access)

Gives a whole host of stuff I don't yet understand but I don't care
currently as something is actually happening.

Will figure out a way of saving the console info (any hints anyone?)  as it
gets badly mangled when cutting and pasting  but basically something like
this:

i2cdump -y 0 0xa
No size specified (using byte-data access)
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
0123456789abcdef
00: ff XX XX XX XX XX XX ff XX XX XX XX ff ff ff XX.XX....X
10: XX ff XX XX XX XX XX ff XX ff XX ff XX XX ff XXX.X.X.X.XX.X
20: ff XX XX ff XX XX ff XX XX XX XX ff XX XX XX ff.XX.XX..XXX.
30: XX ff XX ff XX XX XX XX ff ff ff XX XX XX XX XXX.X....X
40: XX XX XX ff XX ff XX XX XX 64 XX XX d5 XX XX ffXXX.X.XXXdXX?XX.
50: XX ff XX XX XX XX XX XX XX ff XX XX ff XX XX XXX.XXX.XX.XXX
60: ff XX XX XX ff XX XX XX XX XX XX XX XX ff XX XX.XXX..XX
70: XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX XXXXX.
80: XX ff XX XX ff ff XX XX XX ff XX XX XX XX XX XXX.XX..XXX.XX
90: XX XX ff XX XX ff XX ff XX ff ff XX XX ff ff XXXX.XX.X.X..XX..X
a0: XX ff XX XX ff XX XX XX XX XX XX XX XX XX ff XXX.XX.X.X
b0: XX XX ff XX XX XX ff XX XX ff XX XX XX XX XX XXXX.XXX.XX.XX
c0: XX XX XX XX ff XX XX ff ff XX XX ff ff XX XX XX.XX..XX..XXX
d0: XX XX XX XX XX ff XX ff XX XX XX XX XX ff XX ffX.X.X.X.
e0: XX XX XX ff XX ff XX XX XX XX XX XX XX XX ff XXXXX.X..X
f0: ff XX ff ff XX XX XX XX XX XX XX XX XX XX ff XX.X..XX.X


Progress at least.

Cheers,

Julian







On 12 April 2013 11:27, Julian Brooks  wrote:

> Message resent for thread archives with smaller picture size.
>
> Julian
>
> -- Forwarded message --
> From: Julian Brooks 
> Date: 11 April 2013 19:24
> Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd
> To: Martin Peach 
> Cc: PD List 
>
>
> Hey Martin / list,
>
> Finally got all the stuff and ...
>
> It’s not working!
>
> We spent the day soldering cables and connecting stuff up as per the Omron
> ‘App Note 01’ spec sheet.
>
> Started off super-conservative using the  I2C level converter (case 3 page
> 4) http://www.adafruit.com/products/757#Blog/Flickr
>
> We tried resistors on both sides (being super paranoid!) and then we took
> the low (Pi) side ones off.
>
> We then moved on to case 2 page 3 of this same document…
>
>  At each stage we checked with “I2Cdetect –Y 1” and nothing was visible.
>
> The grid shows no attached devices every time we run it.
>
> We re-booted at every stage following the various online tutorials/methods
> of setting up I2C GPIO on the Pi (checked & double checked).
>
>
>  As you can see we’re using a pi protoplate:
>
> https://www.adafruit.com/products/801
>
>
>
> In the photo I’ve attached the cables are coded as follows:
>
>
>
> Orange   GND
>
> Yellow5v
>
> BlueSCL
>
> Green SDA
>
>
>
> The white is also 5v for the pull up resistors.
>
> The resistor values are 4.7k btw.
>
>
>
> We have tested the cable that terminates at the sensor and all that is OK.
>
> I put a multimeter on the GND and SDA solder points on the sensor itself
> and got 3.7v…
>
> I put a multimeter on the GND and SCL solder points on the sensor itself
> and got 0.0v…
>
>
>
> Don’t know if this means anything or could be useful to know!
>
> Stuck and frustrated now but hey, 3 weeks ago I knew absolutely bugger all
> about any of this and now I do (sort of).
>
> I'm thinking we could do with the most basic i2c sensor we can find as we
> have nothing to compare.
>
> Tonight I'm going to d/l a fresh raspbian and start from scratch to check
> that end.
>
> Feel like if we can't get past the 'i2c-tools' tests we're screwed - never
> mind getting it in and out of Pd.
>
> Any thoughts/pointers/options from anyone will be really appreciated?
>
>
> Cheers,
>
>
> Julian
>
>
>
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-11 Thread Julian Brooks 
Hey Martin,

Ok, good stuff - progress.
Will check all connections again (have to be tomorrow now).

Nice one,

Julian


On 11 April 2013 20:25, Martin Peach  wrote:

> On 2013-04-11 14:24, Julian Brooks wrote:
>
>> Hey Martin / list,
>>
>> Finally got all the stuff and ...
>>
>> It’s not working!
>>
>> We spent the day soldering cables and connecting stuff up as per the
>> Omron ‘App Note 01’ spec sheet.
>>
>> Started off super-conservative using the  I2C level converter (case 3
>> page 4) 
>> http://www.adafruit.com/**products/757#Blog/Flickr
>>
>> We tried resistors on both sides (being super paranoid!) and then we
>> took  the low (Pi) side ones off.
>>
>> We then moved on to case 2 page 3 of this same document…
>>
>> At each stage we checked with “I2Cdetect –Y 1” and nothing was visible.
>>
>> The grid shows no attached devices every time we run it.
>>
>> We re-booted at every stage following the various online
>> tutorials/methods of setting up I2C GPIO on the Pi (checked & double
>> checked).
>>
>>
>> As you can see we’re using a pi protoplate:
>>
>> https://www.adafruit.com/**products/801
>>
>> In the photo I’ve attached the cables are coded as follows:
>>
>> Orange   GND
>>
>> Yellow5v
>>
>> BlueSCL
>>
>> Green SDA
>>
>> The white is also 5v for the pull up resistors.
>>
>> The resistor values are 4.7k btw.
>>
>> We have tested the cable that terminates at the sensor and all that is OK.
>>
>> I put a multimeter on the GND and SDA solder points on the sensor itself
>> and got 3.7v…
>>
>> I put a multimeter on the GND and SCL solder points on the sensor itself
>> and got 0.0v…
>>
>>
> If you have pullup resistors you should get the same 3.7V on SCL (with it
> switched on and not running any code), so probably your pin isn't connected
> somewhere.
>
> Martin
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-11 Thread Martin Peach 

On 2013-04-11 14:24, Julian Brooks wrote:

Hey Martin / list,

Finally got all the stuff and ...

It’s not working!

We spent the day soldering cables and connecting stuff up as per the
Omron ‘App Note 01’ spec sheet.

Started off super-conservative using the  I2C level converter (case 3
page 4) http://www.adafruit.com/products/757#Blog/Flickr

We tried resistors on both sides (being super paranoid!) and then we
took  the low (Pi) side ones off.

We then moved on to case 2 page 3 of this same document…

At each stage we checked with “I2Cdetect –Y 1” and nothing was visible.

The grid shows no attached devices every time we run it.

We re-booted at every stage following the various online
tutorials/methods of setting up I2C GPIO on the Pi (checked & double
checked).


As you can see we’re using a pi protoplate:

https://www.adafruit.com/products/801

In the photo I’ve attached the cables are coded as follows:

Orange   GND

Yellow5v

BlueSCL

Green SDA

The white is also 5v for the pull up resistors.

The resistor values are 4.7k btw.

We have tested the cable that terminates at the sensor and all that is OK.

I put a multimeter on the GND and SDA solder points on the sensor itself
and got 3.7v…

I put a multimeter on the GND and SCL solder points on the sensor itself
and got 0.0v…



If you have pullup resistors you should get the same 3.7V on SCL (with 
it switched on and not running any code), so probably your pin isn't 
connected somewhere.


Martin



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-07 Thread Martin Peach 

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=294297&hilit=i2c+gpio+direction#p294297

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


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-07 Thread Julian Brooks 
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=294297&hilit=i2c+gpio+direction#p294297

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

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-07 Thread Martin Peach 

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


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-07 Thread Martin Peach 
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


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-07 Thread Martin Peach 

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

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-04-07 Thread Julian Brooks 
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.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?

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

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-03-30 Thread Martin Peach 

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/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


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-03-27 Thread Martin Peach 

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/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.
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




___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-03-27 Thread Julian Brooks 
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/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.

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

Re: [PD] Sensors GPIO Raspberry Pi Pd

2013-03-27 Thread Martin Peach 

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-mems-4x4/dp/2218000

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




___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list