Computing stuff tied to the physical world

Reporting serial packets

In Software on Oct 16, 2012 at 00:01

The RF12demo sketch was originally intended to be just that: a demo, pre-flashed on all JeeNodes to provide an easy way to try out wireless communication. That’s how it all started out over 3 years ago.

But that’s not where things ended. I’ve been using RF12demo as main sketch for all “central receive nodes” I’ve been working with here. It has a simple command-line parser to configure the RF12 driver, there’s a way to send out packets, and it reports all incoming packets – so basically it does everything needed:

  [RF12demo.8] A i1* g5 @ 868 MHz 
  DF I 577 10

  Available commands:
    <nn> i     - set node ID (standard node ids are 1..26)
                 (or enter an uppercase 'A'..'Z' to set id)
    <n> b      - set MHz band (4 = 433, 8 = 868, 9 = 915)
    <nnn> g    - set network group (RFM12 only allows 212, 0 = any)
    <n> c      - set collect mode (advanced, normally 0)
    t          - broadcast max-size test packet, with ack
    ...,<nn> a - send data packet to node <nn>, with ack
    ...,<nn> s - send data packet to node <nn>, no ack
    <n> l      - turn activity LED on PB1 on or off
    <n> q      - set quiet mode (1 = don't report bad packets)
  Remote control commands:
    <hchi>,<hclo>,<addr>,<cmd> f     - FS20 command (868 MHz)
    <addr>,<dev>,<on> k              - KAKU command (433 MHz)
  Flash storage (JeeLink only):
    d                                - dump all log markers
    <sh>,<sl>,<t3>,<t2>,<t1>,<t0> r  - replay from specified marker
    123,<bhi>,<blo> e                - erase 4K block
    12,34 w                          - wipe entire flash memory
  Current configuration:
   A i1* g5 @ 868 MHz

This works fine, but now I’d like to explore a real “over-the-wire” protocol, using the new EmBencode library. The idea is to send “messages” over the serial line in both directions, with named “commands” and “events” going to and from the attached JeeNode or JeeLink. It won’t be convenient for manual use, but should simplify things when the host side is a computer running some software “driver” for this setup.

Here’s the first version of a new rf12cmd sketch, which reports all incoming packets:

Screen Shot 2012 10 14 at 15 31 51

Couple of observations about this sketch:

  • we can no longer send a plain text “[rf12cmd]” greeting, that too is now sent as packet
  • the greeting includes the sketch name and version, but also the decoder’s packet buffer size, so that the other side knows the maximum packet size it may use
  • invalid packets are discarded, we’re using a fixed frequency band and group for now
  • command/event names are short – let’s not waste bandwidth or string memory here
  • I’ve bumped the serial line speed to 115200 baud to speed up data transfers a bit
  • there’s no provision (yet) for detecting serial buffer overruns or other serial link errors
  • incoming data is sent as a binary string, no more tedious hex/byte conversions
  • each packet includes the frequency band and netgroup, so the exchange is state-less

The real change is that all communication is now intended for computers instead of us biological life-forms and as a consequence some of the design choices have changed to better match this context.

Tomorrow, I’ll describe a little Lua script to pick up these “serial packets”.

  1. Looking good, just wondered if pushBytes should be referencing the decoder instead on encoder or not?

  2. Don’t follow, I’m afraid. I’m encoding RF12 to send over serial. You mean bad naming choice?

    • I don’t know about the encoder/decoder, I think encoder is right, but I do think the function might be renamed to something like “pushRF12” or “pushRX”, because that’s what you’re doing: if it was just pushing bytes, there shouldn’t be a push of “rx”, BAND, GROUP etc.

  3. JCW, I don’t remember if you’ve explained which “wire” exactly you wanted to standardize. One way to understand your plan could have been that Jeenode-to-Jeenode transmission will be bencoded so now Paul might expect decoding of bencoded data to more readable format.

    • Wait… Bencode is too wasteful for JeeNode-to-JeeNode. I’m encoding over serial link and within the ZeroMQ system on the Linux etc side of things. Will try to clear this up as I start describing more of what goes on on the host side – not quite there yet, right now.

  4. Thanks for this, i’ve just started hooking up jeenodes to a mqtt broker via ethernet shield without using jeelinks, also not there yet… Looking forward to the next post!

  5. Sorry, it was just the way I read it as incoming data in the main loop. I expected this was from another node and needed decoding to be useful. I think I also presumed the data from another node would also be encoded already and therefore wouldn’t need to be again. Think I’ve just missed the point a bit, :@)

Comments are closed.