Author Topic: New OOK library for Moteino  (Read 24904 times)

kobuki

  • Sr. Member
  • ****
  • Posts: 289
New OOK library for Moteino
« on: September 08, 2015, 06:21:44 PM »
Instead of the tl;dr below you can just go straight ahead to GitHub and grab the latest code. A lot of useful info has been gathered in this thread, if you have questions or suggestions, please post here.



First I thought I'll just continue an older thread of similar subject for this, but I think that if it gains any notable interest, it's better to have a separate one.

I continued with my OOK/RFM69 project and I can report success. I've succesfully created a working receiver and transmitter solution, and I'm including my current code for review and test for anyone interested. I'm trying to collect my notes in bullet points.

  It's a work in progress, probably many optimisations, code refactorings could be done (some will be done), but it works. Pull requests will be very welcome after I'll have it uploaded to Github. I haven't decided yet if I'm creating a version that uses the original repo as base or I make it completely indepentent. It would be nice to be able to integrate it into the LPL codebase sometime. Maybe Felix is interested in it. I'm including this code here in an attempt to gauge interest.

  I've taken an older version (from when I started coding on it) of Felix's RFM69 lib, gutted it and added the functions I deemed necessary. A note: many settings specified as defaults in the RFM69 DS aren't actually defaults. I had to set some of them explicitly. It is a separate class with a different name, so it can co-exist with the original lib. No inheritance (might be an option later).

  There are 2 modes of operation for reception: polling and interrupt based. When polling, one can just call poll() to see if the OOK signal is currently active or not. Interrupt based means there is an interrupt attached to the pin change and pulse train decoding logic can be put into an ISR.

  Transmission is very simple: after calling transmitBegin(), one can call send() to activate/deactivate the OOK signal. Simple timing loops can be used to modulate a proper pulse train, for instance. No provisions are made to support encoding modes of the RFM69, like Manchester encoding. Instead, I think the simplest and most efficient method for adding support for specific OOK hardware is grabbing and modifying existing freely available code for older transmitters like the RFM01 or RFM12b.

  The minimum length of a pulse is tied to the reciprocal of the maximum bit rate of the OOK mode of the RFM69, which is 32768 Hz, resulting in a 30.52 us resolution. Since most OOK appliances use pulse lenghts close to 1 ms, it's more than adequate.

  The first '1' pulse after a long silence or '0' is always perceived longer than the rest. It can probably be controlled a little better, needs some more experimenting. But see my previous point, it shouldn't pose a problem in practice. Other than this, accuracy is within 10% for short periods (below 500 us) and a lot better for longer ones, near 100%.

  About the included zip: unzip it into a checked out copy of the LPL RFM69 library. It will not overwrite anything, just adds new files. The included test code is very primitive; it's just a playground. Feel free to modify it to fit your needs. I'm yet to test it with a real OOK transmitter. There is a separate receiver and a transmitter sketch.

  About the hardware mod. First, please see the image in the first post of this thread. The left-hand side modification needs to be done for both receivers and transmitters. More precisely: one needs to connect DIO2 of the RFM69 to Pin 3 of the Moteino. That's all. Obviously, a pair of Moteinos or a Moteino as receiver and some OOK hardware is needed for testing.

Any comments or suggestions are very welcome.
« Last Edit: September 28, 2015, 09:00:23 PM by kobuki »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: New OOK library for Moteino
« Reply #1 on: September 08, 2015, 07:14:31 PM »
The Moteinos I have are the 915Mhz variety.  Would  they receive 433Mhz OOK, which is where the majority of OOK sensors broadcast (e.g. Oregon Scientific, Davis Instruments, etc.), just as  as well as a Moteino that's officially 433Mhz?  I'm thinking there might be a difference, given that they are different SKU's.

To me the potential appeal of using the RFM69 for receiving 433Mhz OOK is that hopefully the receiving range will be much greater  than what's otherwise possible with the usual $1 cheap  433Mhz receiver hardware that's commonly available from China on Ebay or AliExpress.

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: New OOK library for Moteino
« Reply #2 on: September 08, 2015, 07:27:31 PM »
It will work, with lowered sensitivity, naturally. I've once accidentally left 433 MHz settings on my 868 MHz module in one of the original LPL code examples and only after about an hour of experimentation I realised that. The motes were about 5m apart with only a door between them, yet RSSI was quite high, around 40..50 dBm. However if you use a dedicated mote for receiving your stations, having the proper radio surely helps. You can even swap the onboard module easily. For testing I'd suggest reducing the distance, though (if the transmitter is somewhere in your backyard or something).

BTW, Davis uses 915 MHz in the US/AU and 868 MHz in EU/UK, and FSK. I have a quite close friendship with its protocol ;)

markbee

  • NewMember
  • *
  • Posts: 18
Re: New OOK library for Moteino
« Reply #3 on: September 09, 2015, 08:00:11 AM »
Awesome work! I'm also currently working on implementing OOK with the RFM69.
I tested the receiver and transmit code and got at least data (with a 433MHz switch device) when I tested the receiver code.
But I always get a lot of random data between the "real" data - looks like the threshold has to be adjusted?
I had no luck with the transmit code - there weas neither data received with the receiver code nor could I see any transmission with a RF Spectrum Analyzer.
Cheers
markbee

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: New OOK library for Moteino
« Reply #4 on: September 09, 2015, 08:10:09 AM »
Thanks!

Yes, the sensitivity could be tuned. The normal RSSI threshold doesn't seem to play a role. I'll need to look into this. However random noise is being picked up by all receivers all the time, it's not abnormal. The important bit is that a well-defined pulse train can be caught and decoded. Most noise will fail at a very early stage of an attempted decoding process.

Transmitter: are you using the same moteino, with DIO2 connected to Pin3? It should work, my wonky test receiver code was happily and identifyably capturing the pattern the test transmitter generated, for 1-2 hours until I turned the motes off.

markbee

  • NewMember
  • *
  • Posts: 18
Re: New OOK library for Moteino
« Reply #5 on: September 09, 2015, 10:44:28 AM »
I changed from my R5-USB 434MHz (DIO2 connected to Moteino Pin3) to the same modules with 868MHz and can read the transmitted bits (at least the 950*1000L delay is easy to identify). The bits preceding the long pause seem to be the bits I send, but are inverted? The timing is also a bit out of the programmed delay.
For example if I program the following 6 bits:
Code: [Select]
//snip
radio.send(1);
  delayMicros(100L);

  radio.send(0);
  delayMicros(500L);
 
  radio.send(1);
  delayMicros(100L);
 
  radio.send(0);
  delayMicros(500L);

  radio.send(1);
  delayMicros(100L);
 
  radio.send(0);
  delayMicros(950 * 1000L);

//snap

I get values like:

19 0 68
0 1 392
1 0 184
2 1 476
3 0 168
4 1 944972

19 0 384
0 1 384
1 0 228
2 1 476
3 0 132
4 1 945460

19 0 116
0 1 400
1 0 184
2 1 476
3 0 160
4 1 944868

19 0 52
0 1 420
1 0 184
2 1 472
3 0 156
4 1 944948
5 0 412
6 1 156
7 0 484
8 1 144
9 0 945524

and so on.

I'm not sure if I the bits are one after another but I would absolutely call this a succes for your code.

One of my first wishes would be to fine tune the threshold like having a "squelch" at least for debugging to see how good the timings are. I didn't test the interrupt sending/ receiving - do you have any code for that?

Cheers
markbee

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: New OOK library for Moteino
« Reply #6 on: September 09, 2015, 11:23:39 AM »
The bits getting inverted must be some coding mistake on my part, TBH I only really cared cared about the lenght of the 0/1 pulses. Feel free to correct it if you'd like. I suggest lowering the output power for the transmitter. In close distances it seems to overshoot a lot. Additionally, I will probably need to set the fixed threshold per specs to make things more robust. Unfortunately there is only code for this module for OOK on the net, not much explaining for settings of the various parameters. I will give a shot at optimising the reception stability tonight and try with 433 MHz too.

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: New OOK library for Moteino
« Reply #7 on: September 09, 2015, 01:13:17 PM »
I tuned RSSI parameters, namely REG_OOKFIX and REG_RSSITHRESH. This made reception a lot more robust and eliminated most of the noise. Modified the receiver sample a bit to allow easier eyeballing the results. In 433 MHz mode the receiver is more precise at capturing the timings of the transmitter. In 868 MHz mode the received first burst is longer than it should be, but again, I'm intentionally testing the lower end of the timing limits. Timing resolution is about 30 us. In practice, OOK devices use very long pulses, closer to 1 ms. I'm using the same 868 MHz module for both frequency bands.

I uploaded the code to Github for easier management, see: https://github.com/kobuki/RFM69OOK. I haven't bothered with copyrights, etc. yet, but it's an obvious derivative of Felix's library so I left his original copyright stuff there for now. Pull requests are welcome for notable improvements :)

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: New OOK library for Moteino
« Reply #8 on: September 09, 2015, 09:09:01 PM »
Updated the Github repo:

More testing code
 - simple pulse width dumper (OOKReceiveTest2)
 - a working implementation of a Lidl L08037B outdoors temperature sensor OOK decoder (OOKReceiveTest3) -- what I had around...

So far, everything's working as expected. Especially when considering that I'm using a 868 MHz radio for this 433 MHz device with an antenna tuned for the former ;) I'm planning to introduce simple funcions for fine-tuning the radio for various OOK devices and test IRQ-based code. Currently I'm having problems with the IRQ code when using the HW serial routines.

I also can't seem to read out a sensible RSSI value when I receive a '1'. Anyone has an idea what could be happening with it?

markbee

  • NewMember
  • *
  • Posts: 18
Re: New OOK library for Moteino
« Reply #9 on: September 10, 2015, 10:03:34 AM »
I tested your code and had problems with the noise (as I had before). I received a lot of data (noise) when testing the receive code with either the transmit code on a R5-USB nearby or a 433.9MHz remote switch nearby.
So I checked my test setting with an oscilloscope and found a very interesting effect. If the transmitter is very near, the RFM69 seems to overdrive and keep this status even if you cut it from the power supply for a short time.

See attached pictures with clear signal and overdrive situation.


kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: New OOK library for Moteino
« Reply #10 on: September 10, 2015, 10:16:01 AM »
I tested your code and had problems with the noise (as I had before). I received a lot of data (noise) when testing the receive code with either the transmit code on a R5-USB nearby or a 433.9MHz remote switch nearby.

I suggest lowering the output power for the transmitter. In close distances it seems to overshoot a lot. Additionally, I will probably need to set the fixed threshold per specs to make things more robust.

Yeah, I know. Thanks for the shots btw, they are the missing presentation of scientific evidence :) The interesting thing is the other thing you mentioned after power cutoff. I sometimes experience other weird behaviour, like interrupts triggering continuously for no reason until I reset the mote by unplugging and replugging it into the USB socket.

I'm currently testing the interrupt-based decoder, it's working so far, soon to be pushed to GitHub.

EDIT: Suggestion: try lowering REG_RSSITHRESH while raising REG_OOKFIX. One at a time. I think lowering RSSI sensitivity should help. The RFM69 module is indeed a very sensitive one, so probably some tuning might be needed for each installation.
« Last Edit: September 10, 2015, 10:32:11 AM by kobuki »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: New OOK library for Moteino
« Reply #11 on: September 10, 2015, 10:52:43 AM »
It doesn't look like a proper manchester encoding either.  The lows are all lasting about the same amount of time, and some of the highs look like much more than 2x the duration of the low.

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: New OOK library for Moteino
« Reply #12 on: September 10, 2015, 10:57:14 AM »
Yeah. Basically all codes I've looked at use some unique timing scheme. Common in most ones though is that they use simple pulse lenght coding to represent 0 and 1 binary digits.

Just uploaded some code to GitHub, including a working IRQ-based decoder.

markbee

  • NewMember
  • *
  • Posts: 18
Re: New OOK library for Moteino
« Reply #13 on: September 10, 2015, 11:10:07 AM »
Ok was thinking about REG_OOKFIX at the same time  ;) and upped REG_OOKFIX which is the way it definitely works now.
This is how it looks like with your transmit code:

1 0 324
2 1 308
3 0 212
4 1 216
5 0 104
6 1 332
7 0 308
8 1 220
9 0 216
10 1 112
11 0 348
12 1 300
13 0 212
14 1 204
15 0 124

and so on.

So if you have the transmitter nearby (e.g. to eliminate noise) this might be the way to go.

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: New OOK library for Moteino
« Reply #14 on: September 10, 2015, 11:17:58 AM »
Cool. Until I set the OOK fixed threshold value, I also received a lot more noise.

What I can't seem to achieve is getting RSSI values out of the chip. It always reads -128 when calling readRSSI(), whether I use the force parameter or not. I called it in a loop every 100 us, and nothing. The same transmitter was operating and I could receive it just fine, so obviously some RSSI change must have occurred. No dice.
« Last Edit: September 10, 2015, 11:24:58 AM by kobuki »