Improvements for RF

Hi everyone,

I've talked a little about this before, but with the LightwaveRF, 433Mhz and Weather Station threads it seemed like a good time to post up and get everyone's ideas.

The Problem

Loads of cheap home automation type devices are 433Mhz (or 868Mhz) and you can get radio modules that receive/transmit the data very cheaply, making them a perfect way to control stuff (or sense) around the house. The problem is that the data that comes in from the receivers (or that has to be sent) is basically a 'raw' waveform, and has to be carefully timed. To make matters worse, every different device seems to have its own set of timings, and inbetween the signals from devices the waveform is basically random noise.

In an ideal world we'd be able to use Espruino to decode several different kinds of signal all at once (doorbell, temperature sensors, light switches) and then to maybe send out signals as well, so it could act as a bridge between different devices and do intelligent things with them.

Transmit

This one's relatively easy. You can use digitalPulse to send timed pulses, but it's not that pretty - and for the faster signals we start to hit problems with execution speed in Espruino.

I'd propose allowing digitalPulse to take an array of times, for instance:

digitalPulse(A0, 1 /* initial pulse polarity */, [ 0.2 /* pulse high time */ ,0.3 /* pulse low time */ ,0.1 /* pulse high time */ ,0.4 /* pulse low time */  ]);

but I'm open to other ideas... Another one is allowing Waveform to send/receive binary data from GPIO (rather than just analog). That would be pretty cool (and maybe not too hard), but often the radio protocols don't send 'clocked' data - in which case it's maybe not that useful.

Receive

This one is the worst. While most 433Mhz devices tend to send pulses of a minimum of 0.2ms, the random noise that creeps in between transmissions can be less. Even at 0.2ms it's too fast for Espruino to really do anything clever to isolate the signal, and the input buffer can overrun pretty easily.

It seems that with a bit of work we can write a receiver for each protocol, but when you combine them all together I think it's going to be too slow to work properly.

This leaves us with few things that could be done:

• Make Espruino faster - I should put some more work into this anyway, but I'm not sure it's ever really going to be fast enough to deal with random noise coming in down the radio.
  
• Implement some kind of native code radio analyser inside Espruino. This would be easy, except ideally it would handle several different radio protocols at once - it could get quite complex and I'm not sure it should really be part of the firmware...
  
• Allow native code (assembler via E.nativeCall) to be called directly from an interrupt, and then someone enthusiastic could write a decoder for whatever standards were required as assembly (or write it in C and pre-compile it). To be useful this would also require that there was some better handling of saving the assembler to Flash (@JumJum's already done some work here), and probably also some way to call a few Espruino internal functions from Assembler.
  
  

I guess the last one is my preference as it's most flexible and most useful for other things (especially if a C compiler gets integrated to allow inline C code), but it's quite a lot of work.

Does anyone have any thoughts about how to nicely decode all these different radio standards on Espruino?

Regarding transmit, the array of times would be excellent. If nothing else it simplifies it and can ensure a perfect waveform. With a slight optimisation I was able to get LightwaveRF working with a simple loop around digitalPulse, rather than eval() a string of digitalPulse commands, but it is right on the verge of being too slow.

Regarding receive, I have a device called NinjaBlock which was another Kickstarter which is a home automation and sensor hub. It is a BeagleBone with an attached Arduino cape that does 433Mhz transmit and receive.

Running on the BeagleBone was a Node.js app which talked to their cloud API. You can put the NinjaBlock into learning mode, activate a 433Mhz device such as a doorbell or PIR sensor, and it would learn it. From there you can set it to take actions, e.g. if PIR sensor then take photo and upload to Dropbox. Additionally you could send 433Mhz signals to control devices.

It supported lot of sensors and devices, mainly the cheap ones from eBay. It didn't support LightwaveRF, I guess because the protocol is a little more involved.

Anyway, this is all to say that they have managed to decode different radio signals with an Arduino, and it is open source in case some of the code is helpful:

https://github.com/ninjablocks/arduino

Thanks! I'd heard of NinjaBlocks and knew they were 433Mhz, but didn't realise they'd got support for non-ninja devices. That's pretty cool of them.

I'm surprised about the learning... That must be tricky. Looking at what I get out of my receiver here it's a total mess. What I usually do is pull the transmitter apart and figure out what the signal is by hooking onto the PCB :)

I guess just running their code on an Arduino would be the sensible thing, but as I'm doing Espruino I can't really bring myself to do that :)

I think that to implement a proper receiver that you could teach I'd end up doing some kind of state machine, but it seems really involved. It'd be much better to just be able to execute normal code very quickly :)

On closer inspection, it looks like they based the receiver code on an Arduino project called RCSwitch which appears to listen for and implement 3 different protocols:

http://code.google.com/p/rc-switch/sourc­e/browse/trunk/RCSwitch.cpp

These protocols I assume cover a wide variety of those cheap Chinese 433Mhz sensors from eBay, and can "learn" them, but it is not as if it is pulling an unknown protocol out of the air. That would be too difficult with the noise as you say.

With that in mind I guess one would have to implement the protocol for whatever device(s) they are using. So the ability to have the tools/functions available to do that with fast execution is the most useful. So the native code idea sounds like the most flexible.

I am planning on getting my 433 sensors such as temp, humidity, PIR, doorbell, all hooked up to the Espruino, as well as LightwaveRF. So I'll have to figure out how to detect each protocol. This would make a cool 433Mhz sniffer project too ;)

My experience with this in it's current state has been that with or without debounce (is debounce implemented as efficiently as it (sh|c)ould be? It seems to make little difference, even though it should be filtering out almost all the noise in my system, including the training bursts), you cannot have the espruino wait for and respond to an RF command. It can turn on listening, and grab a response, but it can't wait for spontaneous commands from afar.

The next question, is whether it ever could be made to perform well enough for that. That means almost constantly getting interrupts and handling them, while also acting like an Espruino.

I think option 3 is the most versatile, and would probably have applications outside RF processing too. Would this be fast enough that the Espruino could run other code acceptably while listening to a 433mhz rf receiver continuously?

debounce in setWatch is actually done after the events have been stuck in the event queue - so as you say it's not as efficient as it could be. It's actually quite a bit a harder one to do debounce in an IRQ - although it could be done later.

And yes, I think with option 3 it could be very fast. I'll have a think about that - I've been seeing more and more things that could be done with native code on IRQs - like the ability to execute code on a timer... It could mean that a decent charlieplexing library could be made, and it might even allow us to do some kind of DMA'd VGA library.