Computing stuff tied to the physical world

Remote ports

In AVR, Software on Feb 15, 2009 at 00:07

Yesterday was about local “ports” on the Arduino’ish JeeNode. Today, this is extended to remote ports. Here’s a sketch which controls ports wirelessly:

Remote ports

It’s almost like the local one, except for some headers and declarations at the top and a new “bob.poll()” in the main loop. Where “bob” is defined as the object representing a remote node with id ‘B’ (id’s ‘A’ through ‘Z’ are available for general use). Welcome to the world of messaging and transport independence.

This is a test setup with two JeeNodes:

Remote ports

The receiver (top) is powered by a 3x AAA battery pack (it turns out that 3x NiMh ≈ 4V). The transmitter (bottom) is tied to the USB port. This test sends 25 packets per second through the air (data + ack at 80 msec intervals). Probably OK for a quick test, but not for prolonged use!

This test setup makes it easy to check range by walking around with the receiver. Turns out that it’s just fine for my purposes: this works across 3 stone walls / concrete floors. Data rate is ≈ 57600 baud.

The changes to the Ports library have been included in the new release and in subversion, see also the previous post. Two new examples have been added: blink_xmit and blink_recv. The receiver code decodes and interprets each packet and performs all port I/O requested by the transmitter. Input values are then sent back in the ack packet.

The Arduino-0013 IDE compiles “blink_xmit” and “blink_recv” to 3128 and 2644 bytes, respectively. So there’s plenty of room for more functionality.

  1. Have you considered “Scaleable Node Address Protocol” for use with the RFM12B?

    I posted about this in January 2009 here:

  2. Thanks for the link – did come across it before, I’ve just gone through the protocol specs in more detail. Although I like the basic design, it has more generality than I really need (24-bit src/dst addresses, larger packets, 7 checksum methods) and it appears to lack versioning. I’m not sure SNAP offers me more than my current RF12 driver. Mainly because in these contexts you get to control all end points with no inter-operability issues, so protocol choices are not as far-reaching.

    What I currently have in mind will support 30 nodes in up to 250 groups.

Comments are closed.