Berlinengineer Sara Reichert für EinsteinsTraum

Sha Xin Wei: PLSS hacking

Date: August 13, 2011 6:56:17 AM EDT

Hi Michal, Hi Morgan,

This is all great -- can't wait ti see the data come trickling into Ozone soon!     But let's design for a world in which we have dense set of sensors, where dense means approximately  continuous in space, time, as well as data-space.   Practically speaking, this means on the order of video density, i.e. tens of millions of channels per unit time.   In the face of such density, it makes sense to use a minimax design tactic:  minimum bandwidth needed to maximally intercalate vegetal / soil activity with social activity.

Another design tactic I would us to try in most of our sensor work is to use a push model instead of regular polling (a pull model).  This means I'd like the sensor to emit data when there is a change above a delta.   Ideally that delta should be tunable by an application programmer.   This means the sensor data should arrive from the analog world with irregular intervals of time.    (Thanks to Joel Ryan and his work with gestural musical sensing.)

Tim and Flower's timelapse data show us that our fastest growing plants -- the morning glories -- had a "frequency"  of about one macroscopic (human legible) cycle of creeper per hour.   (Ask Natasha Myers @ York for a technical term :)    I don't know what the frequency should be, but I would like to work with the lowest possible frequency that we can.

The research challenge is in fact : How can we intercalate the slow rhythms of sidereal and vegetal activity (hour) with human rhythms (second) in a way that is legible to us?

This goes to the heart of the fact most "environmental" sensor art is boring or has the same affect as noise.   Rather than fetishize the boring or noise as aesthetics, let's see what we can do with streams of sparse, irregular sensor data.

Xin Wei 

Morgan Sutherland: PLSS hacking

Date: August 12, 2011 6:25:01 PM EDT

Hey Michal,

On 2011-08-12, at 6:15 PM, Michal Seta wrote:
> I considered multicast but have not yet tried it with the arduino.  It's probably doable...

Probably not worth the time/headache. Should be sufficient to put a sticker with the send/receive IP's on the box and maybe make an API over ethernet where you can change the outbound IP's if it's trivial. 

Not being a plant expert, I don't know what data rate makes sense, once an hour?  I can make it configurable.

At least ten time per second or so, and do make it tunable. No reason to cut bandwidth for no reason – we believe in keeping as much data as possible for as 'long' as it's practical (just don't send at max speed / w/o delays!)

> The recent version of arduino (0022) includes the RawUDP code by Björn Hartmann.

Great, then you're set.

> I know of at least 2 objects for Pd that can handle tcp.  One pair (send/receive) developed at Concordia.

UDP is preferred.

> I can, right now, communicate locally with Pd (in UDP) using static IPs but the system does not rely on this communication to function.  I intend to use Pd to prototype a monitoring and configuration interface.

Great! Thank you. This is a nice surprise for me – I assumed I was going to have to do this in September/October.

Cheers,

Morgan Sutherland: PLSS hacking

Date: August 12, 2011 12:18:04 PM EDT

What I meant to say is that it might be easier to roll your own OSC "library" since making a basic OSC message without timestamps, bundles and wildcards does not require a library to do – it's just a int/float with a string identifier and type tag appended. Like:

oscPacket = sprintf("/path/to, i, %c", number);
ethernet.udpSend(oscPacket);

I referred you to OSCuino because the functions sendOSCfloats and sendOSCthings will show you how to construct a proper OSC message w/ AVR C. So if the ethernet library is stable, no need to bother with a half-working OSC library on top of it just to do some string formatting!

For future maintenance, I'm of the opinion the things should be kept simple in terms of implementation so that people in the future can figure them out easily rather than simple of interface (which more often then not means complex implementation).

I had a look at the Arduino ethernet library and to my surprise it doesn't support UDP (only TCP). Somebody has written here a modified version that uses UDP: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1231346812 (not sure if you found this already). You can give it a try, but some people have compile errors. The other option would be to find a TCP object fro Pd. Or rather than using Pd, you could write a little Python/Ruby/C script that receives the data and broadcasts it on localhost for Pd or Max to pick up.

All that said, if you can get the OSC library working, then by all means use it. Just trying to make suggestions to make your life easier!

Thanks Michal.

Sha Xin Wei: PLSS hacking

Date: August 12, 2011 11:46:02 AM EDT

Yes, when Michal and I talked, I expressed a preference for an  arduino box that could stand alone on our local Ethernet and send out data without tying up a whole computer (a capital gear overkill vs software library overkill :) 

Sorry it turned out to be on the bleeding edge!   But I look forward to seeing the data available on OSC.  Can it be broadcast to all machines on local net via some usual convention?   I expect the data rate to be very low so this would eat very little bandwidth.

JA watered the plants last week, said they need basic human live attention too.

PLSS will live again!
Xin Wei 

Michal Seta: PLSS hacking

Date: August 12, 2011 11:22:49 AM EDT

Thank you [Morgan] for the pointers on OSC arduino, I had a quick look at both and Adrian's seems like a very cool tool to have in one's toolbox.  However, both of these solutions use serial communication while my understanding is that we want to communicate over the ethernet.  The OSC library I found wraps the ethernet library and adds the OSC protocol.  I do agree that OSC may be an overkill for sending 8 ints around but Xin Wei expressed interest in using OSC.  In the end it all depends on the end-user/maintener who will make use of this and eventually expand on it.  

I could keep it extremely simple and send just an array of 8 ints or some kind of property list or dictionary if that is what you prefer.

Morgan Sutherland: PLSS hacking

Date: August 11, 2011 9:57:36 PM EDT


Just quickly for now, I try to stay away from OSC libraries because OSC is just a (transport agnostic) naming profile and and the libraries are overkill for sending a few floats. You might have better luck sending strings formatted as OSC messages straight over UDP. There should be a library for that shield with a sendUDP() function. Have a look at Adrian's OSCuino and Andrew Bensons OSC Arduino sketches for inspiration. Away from a computer at the moment, so can't check.

Michal Seta: PLSS hacking

On 2011-08-11, at 9:39 PM, Michal Seta wrote:

Here's a little update because I suppose you're back in town.  I have tracked down an OSC library for the ethernet shield which turned out to be a bit of a puzzle (made for an older version of arduino).  I've found an updated fork but with lots of typos/errors that I managed to iron out and made my own fork :https://github.com/djiamnot/Z_OSC
There are still some mysterious issues but I have actually had a successful OSC communication between the arduino and a Pd patch.  I was a bit delayed due to some family distraction and the OSC bugs chase but I am back on the track.  I think that by next week I will heave the thing working.  I will let you know when I am closer to the finish.

Michal Seta: Reproducibility and Monotonicity of sensor systems

On 2011-03-19, at 12:37 PM, Michal Seta wrote:

Thank you all for your comments, this discussion makes it all much clearer for me, especially the role of the LED indicator.  I too believe that the intuitive/social aspect is more appropriate for PLSS.  In any case, I had no intention of interfering with the original goals and philosophy of PLSS but I think I needed a better understanding.  I was under a wrong impression, for instance, that the LED was to serve as a binary indicator.

See my other inline comments below:  

(> blue Morgan, >> red Xin Wei)

On Fri, Mar 18, 2011 at 11:13 PM, Morgan Sutherland <skiptracer@gmail.com> wrote:

> The ONLY qualities that we should try to guarantee is that, for each given sensor in each given location:

> I think that in addition to these two qualities, we should also do our best to insure that reading the LED's is an unambiguous as possible. This is the argument for using digital – going the analog route, given that we do not have a tremendous amount of expertise or time available, will result in an effectively linear relationship between the output of the sensor (which varies linearly with measured soil humidity) and the brightness of the LED, which leads to a very ambiguous signal.

> I don't think that a reading of only one LED can be unambiguous (unless it is simply a matter of on/off situation which I don't believe is the preferred solution here).  My reading of Xin Wei's comments is that letting the human interpret the LED is part of the equation.

 

>> This should be MUCH easier to implement, MUCH less work.

 

> I actually disagree here. I think that passing the sensor values through the microcontroller and back out to the LED's will be slightly more work than making a delicate analog circuit, attaching it to each sensor, and water-proofing it, especially since I think we would need to use an op-amp + a few resistors per sensor. I have aesthetic preference for simple analog solutions vs. verbose digital solutions however.

Am I reading this correctly?  You mean building n copies of analog circuit and water-proofing them is less work than incorporating one more wire into the design and writing one program (with instantiations of 1 class)?  In any case, I am definitely in favor of an elegant analog solution.  Do we actually need an op-amp and a few resistors?  I understand that there is some concern about linear vs. non-linear solution but in the long run, if left to humans, they will learn to interpret the reading regardless of it being linear or not.  I think that a simple solution (LED + resistor) will yield a reliable reading of the soil's humidity.

 

>> Use analog first.   Digital only when you must, and understand what reductions you are incurring.

Carrots

I harvested the carrots today. Only a few grew to full size 

I ate two straight out of the soil.

Let this serve as proof that it is possible to make sweet life grow in irregular places.