You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • 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?

About

Avatar for Gordon @Gordon started