[Protocol] Alternatives for wireless telemetry and remote control

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(This question is not strictly limited to wireless, as my need is for application layer, although the link/transport layer involves nRF24L01+.)

 

What are viable, preferably standardized, options and alternatives for application layer telemetry and remote control?

 

Goal:
Interface Raspberry Pi controller with sensors/remotes, with main constraints being on ATmega side in terms of sketch size and RAM usage. RPi will send commands to, and receive notifications and telemetry from, these ATmegas.

Application layer communication is what I need. Data is validated in previous layers. Only correct and valid data will be parsed.

 

Brief background:
I aim to build sensors based on ATmega (currently Arduino pro mini) and nRF24L01+. Some will also have remote controllable devices connected, such as lights.
My communication will be mainly toward Raspberry Pi, running Python (preferably), interfacing nRF24L01+ over hardware driven SPI.
I'm using AES-256 for CBC-encryption and SipHash-2-4 as MAC to protect the data over the air from eavesdropping, MITM and replay attacks. (May sound like overkill but it's been fairly straight forward and simple.)

nRF24L01+ can send at most 32 bytes per transmission, so my initial 32-byte package will contain an 8-bytes start sequence including number of encrypted blocks, a 16-byte initialization vector for AES, and an 8-byte MAC for the first 24 bytes.
After this initial package, each transmission will contain a counter for the current block, a 16-byte encrypted block, and an 8-byte MAC (of the first 17 bytes), for a total of 25 bytes. I will only decrypt that which has a valid MAC.

 

Also, as a learning experience, I have been building the AVR application with a task manager at its core. All tasks have been possible to split up into smaller chunks and no single block takes more than one millisecond to execute before it yields and potentially lets other ready-to-execute code run. (With the exception of the odd case where multiple debug printouts follow one another.)

 

Constraints:
My largest sketch so far, with most debugging code disabled, takes up roughly 17 / 30 kB program storage and 1.4 / 2 kB RAM (including 320 byte data buffer which will shrink once I know the final size requirement). It is mostly done, and already using as many of the intended function calls to external libraries as possible for a complete picture, although I have not yet implemented everything in detail.
Preferably the incoming data should be possible to process as a stream, up to 16 or 32 bytes at a time. If I can avoid parsing everything at once, I require less buffer space. (RAM is precious on the ATmega.)

 

Current alternatives:

  • Google Protocol Buffers using nanopb - adds roughly 7 kB program storage for encode (3 kB) and decode (4 kB) of simple sensor data.
    Benchmarks indicate the stack usage is potentially too high for me, although they do claim to use a very large message with all different types represented.
    The overhead is very high, but this is otherwise a very tempting and flexible option.
  • Roll-my-own type, with simple (and rigid) data structure.
    Will require a little bit more effort to design and implement for both ATmega and Python on Raspberry Pi.

 

Last Edited: Fri. Oct 16, 2015 - 12:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

logan893 wrote:
What are viable, preferably standardized, options and alternatives for application layer telemetry and remote control?

  • MQTT-SN

    http://mqtt.org/documentation

    Andy’s Twittering House (MQTT)

    but I'm not certain that a complete MQTT-SN message will fit within a nRF24 frame.

  • A gateway that contains a nRF24 transceiver with a broker application on the gateway.

  • ESP8266 WiFi-to-UART chip or module.  Use HTTP GET and PUT.

 

 

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your suggestion, stevech. Those MiniWireless look interesting, however for this project I will stick with nRF24L01+ as I have many of these chips available, and they suit my needs very well.

 

RadioHead library does support nRF24L01+, however I am already using an nRF24 library which I have customized to fit my needs in this task manager. On top of this I will still need an application layer, which these do not seem to provide.

 

gchapman, I've looked at MQTT-SN a little and it is interesting. I will see how much effort is required to get a library to use RAM buffers for parsing incoming, and buffering outgoing, messages which I can then send via nRF24L01+. I do not require that each message fits in one 32-byte frame, as I will be encrypting the data (and have plenty of overhead anyway.) And the current project won't require extremely time critical RF communication.

 

I may go with MQTT-SN as long as I can get a framework working with a footprint below the 7 kB program storage size of nanopb encode/decode, and within whatever RAM/stack limit will be necessary.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Logan.

 

Are you aware of this work?

 

http://maniacbug.github.io/RF24N...

 

... and his blog entries http://maniacbug.wordpress.com/2...

 

Cheers,

 

Ross

 

 

Ross McKenzie ValuSoft Melbourne Australia

Last Edited: Wed. Sep 10, 2014 - 11:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

valusoft, yes, I have read about that RF24 star topology network library. I believe the RF24 library I am using is originally based on maniacbug's library.

 

I wasn't at first interested in using the RF24Network library, I didn't think I would benefit from it. However perhaps I will give it a try, with some slight modification to better merge with my task manager.

 

I could exactly fit the 24-byte cipher+MAC (and also 24-byte IV+MAC) blocks into the RF24Network system straight away. I should even be able to truncate the initiation vector's 8-byte MAC to 7 bytes if I need a message length variable. Or I can use use the type field, since I doubt in my current implementation I will be having a need for sending more than 127*16 or even 63*16 bytes of data in one go. And if I do, I can just require the transfer is initiated with a new IV.

 

Is the upper half (128-256) of the "type" field (system reserved) used for anything currently? If it is, I cannot find it in the code.

 

This still leaves me with the need of implementing something in the application layer myself... I suppose that's the way I may have to go.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

logan893 wrote:
What are viable, preferably standardized, options and alternatives for application layer telemetry and remote control?

...

I aim to build sensors based on ATmega (currently Arduino pro mini) and nRF24L01+.

A fyi, if willing to move to a larger Arduino compatible, is CoAP with a RF megaAVR.

802.15.4 can be added to Raspberry Pi by RF megaAVR or a USB SAM3 plus Atmel 802.15.4 transceiver.

Stack = application, CoAP, 6LoWPAN, 802.15.4

CoAP - Constrained Application Protocol, Implementations

Zigduino

NooliBee

Noolitic / Nooliberry Wiki (GitHub)

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Sep 11, 2014 - 03:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Logan,

 

any chance you gona publish your work? I was following the development of libraries for the nRF24L01+ since a while, and I think the rf24networks libraries from https://github.com/TMRh20/RF24Ne... are very interesting, but in my opinion were missing the encryption/MAC stuff you are talking about. Sounds like you have a solution to this...

 

cheers, Tony