New OOK library for Moteino

[markbee]

Nice!

Do you have any example code/ libs?

[kobuki]

Hey guys, this is very cool! I also use Moteinos to control RF power sockets. I've used OOK in packet mode which allows for the radio to create the timings. Just switch off the preamble, select OOK, fixed packet length and select the baud rate to get the right timings. Works like a charm without HW mods. Only receive though.

https://lowpowerlab.com/forum/index.php/topic,1115.msg7221.html#msg7221

Thanks for the heads-up. Yeah, I am aware packet mode is possible in OOK mode as well, but I wanted complete control over the timing via software, have per-pulse interrupts (they're sufficiently long in most OOK protocols for that) and create a library that is simple and makes it easy to port other solutions to the RFM69. I might still implement packet mode, my only problem is that most coding schemes aren't based on any standard, so to create the correct timings, a peculiar bit layot must be created to be able to feed into the FIFO of the chip, and decoding, too, can only be done by manual programming. It's not impossible, but I find direct control better suited for now.

[kobuki]

Do you have any example code/ libs?

See on GitHub.

[markbee]

Today I tested your library with a 434MHz remote switch but ran into timing problems. As you can see from the attached logic analyzer chart the timing with the dump-sketch doesn't correspondend with measured values.
The begin of the bit burst ist clearly identified by the 10.6ms pause. But afterwards the edges aren't recognized only the full pulse and there are a lot of very short false signals.
Maybe polling is to slow and it would be better to decode with the interrupt based routine.
I adjusted the REG_OOKFIX to 30 - maybe this comes into play for the wrong readings.

Cheers
markbee

EDIT: Just recognized in the library that the signal is polled with interrupt. I somehow thought the polling is done software-wise. So the next step may be to write an ISR to get the correct timings.

[kobuki]

A quick suggestion: move the receiver/transmitter further apart; raise rssi and fixed threshold; if you use a moteino for tx, lower the output power. This has always helped for me. The module is very sensitive and easily overshot and that results in many false readings, mostly short '1' signals. Someone else in this thread even posted nice scope screenshots about it.

Polling mode is fine, down to probably about 50 us. Interrupt mode is not going to help, but it's good for other applications.

[markbee]

yeah the scope pictures that was me

I already played a lot with REG_OOKFIX and REG_RSSITHRESH but to no avail. It does not get the edges but that ist very constant - so it looks more like it is counting the whole pulse, but does that quite precise.

[kobuki]

EDIT: Just recognized in the library that the signal is polled with interrupt. I somehow thought the polling is done software-wise. So the next step may be to write an ISR to get the correct timings.

Nope, it's not. It's polled directly in loop(). Feel free to rewrite/fix the dumper code to fit your needs - it's nothing more than some playground, however I did use it to decode that cheap 433.9 MHz thermometer. So it can have a few use cases.

BTW, are you hooking up the DIO2 of the mote you do the polling on? Or is it the transmitter side on your image? I'm confident the mote is able to capture your signal properly. Your case might be an outlier that needs more tuning, but I'm sure it's possible. It must have something to do with too strong/distorted rf signal.

[markbee]

In the previous logic analyzer picture the switch remote was hooked to the logic analyzer. I now hooked the logic analyzer to DIO2/ Pin3 (_interruptPin) and hmmm... the timing printed out by the code seems to be bang on (logic analyzer timing is identical with the timing spit out by the code). So there is something running afoul in the RFM69 as it seems and it's not the code which is the problem. I'm afraid I have to dig deeper into the datasheet

[kobuki]

One more hint: try lowering/increasing the bandwidth. I've added simple functions for that on the library class; see related defines at the end of RFM69OOKregisters.h. I'm curious about what you'll find.

EDIT: one more thing. It's important to use the proper frequency for reception. I first thought that the weather transmitter is transmitting on 433.92, but in fact it's on 433.90. My garage opener transmitter keyfob is exactly at 433.92 -- basically any skew made reception impossible or produced similar results to the ones you showed.

[markbee]

Ok it's working now I fine tuned some registers (BW registers e.g.) and now have a clear signal and timing from sender (remote switch) and receiver (Moteino R5USB) is almost identical (see chart and measurements).
The logic analyzer printout shows on top (CH0) the receiver and on CH1 the transmitter. You can also see the delay of the two signals.

Cheers
markbee

BTW the actual github files produce some compiler errors. I implemented the register settings as methods in a fork/ my own library. But I think you will put up the working files soon, so I don't do any pull requests

[kobuki]

Cool! Can you tell me what the actual delay is in microsecs? It's hard to see on the image. So the only thing was the BW? What values made it at the end?

My IDE compiles my GitHub code without a single warning. Can you copypaste the errors you see? I'm using the newest IDE (v1.6.5), this might be the problem, but I want to fix it ASAP if it causes compilation problems for others. Any significant change you think is worth integrating into the base?

[markbee]

The signal length for the short pulse is about 340µs, the long pulse is about 1ms (measurement directly from the remote switch encoder IC). The deviation from the 434MHz remote switch to the actual signal received on the RFM69 is about 10%.
I adjusted the register  RF_RXBW_MANT and RF_RXBW_EXP to 125 kHz and if you have a look at the attached spectrum analyzer screenshots from two different remote switches (same manufacturer) you can see why 
I also adjusted REG_OOKFIX, the frequency and did some changes to the code.
It's interesting to see how the frequency of both of the remote switches differ, so it's obvious you have to set the proper frequency in the code/ for the RFM 69.

I will test your actual github files later asap and post the compiler errors.

Cheers
Markus

[kobuki]

Thanks. What did you have to change in the code? I think finding a middle value for frequency and somewhat larger BW will make all your transmitters work.

You have all sorts of good equipment at your disposal

[WhiteHare]

@Markus What type of TI spectrum analyzer is it that you're using?  Judging from the output, it looks like it might be "affordable," yet a nice upgrade from using a cheapo RTL-SDR with SDR#.

[markbee]

It's this one:

http://www.ti.com/tool/MSP-SA430-SUB1GHZ

It's only sub GHz and only three but important frequency ranges. Bought it cheap some time ago...

BTW I compared the sender (434MHz remote switch) and receiver Moteino R5USB pulses in a table if anyone is interested:

TX   RX   Diff. %
338   348   2,96%
1002   980   -2,20%
339   356   5,01%
1003   980   -2,29%
339   356   5,01%
1002   980   -2,20%
1020   996   -2,35%
336   348   3,57%
340   328   -3,53%
1005   1008   0,30%
1022   1028   0,59%
336   324   -3,57%
340   336   -1,18%
1006   992   -1,39%
1022   1000   -2,15%
336   348   3,57%
340   324   -4,71%
1006   996   -0,99%
1023   1012   -1,08%
336   340   1,19%
340   332   -2,35%
1007   996   -1,09%
1023   1004   -1,86%
336   340   1,19%
341   344   0,88%
1007   992   -1,49%
1023   1000   -2,25%
336   348   3,57%
341   340   -0,29%
1007   1008   0,10%
1023   1000   -2,25%
336   332   -1,19%
341   320   -6,16%
1007   1016   0,89%
1023   996   -2,64%
336   356   5,95%
341   328   -3,81%
1007   996   -1,09%
1024   1024   0,00%
336   320   -4,76%
1025   996   -2,83%
337   356   5,64%
1026   1012   -1,36%
337   308   -8,61%
1026   1012   -1,36%
337   348   3,26%
1027   1008   -1,85%
337   344   2,08%
341   328   -3,81%

Cheers
markbee