Author Topic: Sync bytes used by RFM69 library  (Read 19693 times)

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Sync bytes used by RFM69 library
« Reply #15 on: March 15, 2017, 06:46:00 AM »
During preamble reception the radio does AGC, AFC etc. I don't think it's reasonable to assume that it can detect whether the signal actually is preamble at the same time.

AGC and AFC can either be triggered manually or by a restart using RSSI threshold, so no AFC or AGC could be used when continually scanning with RSSI threshold set to 255, but that's the same situation as yours I think.

Also the frequency of phantom packets would be much lower than what I'm seeing if a full preamble had to be seen to restart sync address detection.

Full preamble length is not know by the receiver (at least the length of a properly decoded preamble it actually receives  isn't), so the preamble length that is detected is really relatively short in comparison to the full preamble length, what's important is waiting for the delimiter at the end of that preamble. So this means more chance of random 1010 type patterns retrigerring the sync word detection mechanism than if using full preamble length.

Mark.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Sync bytes used by RFM69 library
« Reply #16 on: March 15, 2017, 07:17:59 AM »
Quote
waiting for the delimiter at the end of that preamble

Sounds like your theory has morphed into the radio just adding a delimiter bit in front of the sync word when comparing the bitshift register to avoid detecting address match during preamble. That's certainly possible and still compatible with the phantom packet frequency I observe. If its a 4 bits delimiter I think it's probably incompatible with my observations.

That wouldn't change the conclusion that even a 2 byte sync word is cutting it close when running at a 255 thresh.

Joe

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Sync bytes used by RFM69 library
« Reply #17 on: March 15, 2017, 07:50:27 AM »
Yes, I suspect this is in reality is really just a continually shifting register as you stated but with a short delimiter, possible only one repeated bit, at the end of the preamble. I can't see how using zero sync words could actually work without it. In which case chosing sync words with 'good auto-correlation functions' would reduce the false triggering:
http://community.silabs.com/t5/Proprietary-Knowledge-Base/EZRadioPRO-and-Sync-Word-Selection/ta-p/113455

Mark.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Sync bytes used by RFM69 library
« Reply #18 on: March 15, 2017, 08:05:23 AM »
You know, now that I think about it I think I have evidence for the delimiter bit: I have some code that controls these 433mhz rf AC-sockets. I do it in packet mode, with 0 byte preamble, and send the bytes that generate the reverse engineered code. That's always worked well for me.

But when Tom tested it, his sockets wouldn't respond. When he looked at the generated signal he consistently found an extra 1 transmitted in front of the sequence. In the end he just added a couple of 0's to the actual sequence to separate it in time from the control code and that worked. But it seems that this 1 might have been the delimiter.

Joe

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Sync bytes used by RFM69 library
« Reply #19 on: March 15, 2017, 08:27:46 AM »
Yes, I suspect this is in reality is really just a continually shifting register as you stated but with a short delimiter, possible only one repeated bit, at the end of the preamble. I can't see how using zero sync words could actually work without it. In which case chosing sync words with 'good auto-correlation functions' would reduce the false triggering:
http://community.silabs.com/t5/Proprietary-Knowledge-Base/EZRadioPRO-and-Sync-Word-Selection/ta-p/113455

Mark.

I'm assuming (?) that the data whitening applies to the payload only, and not the sync words. 

Is the property of "good auto-correlation" an abstract mathematical property that's hardware independent, or rather does it  (I'm guessing) depend on how the underlying hardware works?  In which case, how do we choose good sync words for the RFM69 that have good "auto correlation"?  I have not even an inkling, other than to apparently avoid repeating bit patterns (as suggested by the Silicon Labs link) that look like a preamble.

Ay yi yi.  Sometimes it feels like we practically have to be able to build an RFM69 all the way up from gates and transistors in order just to use one!
« Last Edit: March 15, 2017, 08:48:46 AM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Sync bytes used by RFM69 library
« Reply #20 on: March 15, 2017, 08:52:38 AM »
@ joelucid: Aha, that's an interesting observation.

BTW my system uses 5 preambles and 3 sync bytes, and I set the sync word to 0xAAAAAA to see what happens. As you predicted, it didn't work. Setting it to 0xAAAAAB was fine.

I then repeated the experiment with 0x555555. That didn't work either. So even with a delimiter the sync word shift register is shifting data even during the preamble, the output of the sync word comparitor probably gets enabled once the delimeter is detected but it already has the preamble shifted into it so instantly matches. I think the difference between the 0xAA and 0x55 cases is it requires one extra bit to be shifted in to generate a match.

So I think that answers the question about the shifting.

Mark.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Sync bytes used by RFM69 library
« Reply #21 on: March 15, 2017, 09:10:37 AM »
Quote
So I think that answers the question about the shifting.

Interesting! Thanks for sharing.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Sync bytes used by RFM69 library
« Reply #22 on: March 15, 2017, 09:49:29 AM »
I'm assuming (?) that the data whitening applies to the payload only, and not the sync words. 

Is the property of "good auto-correlation" an abstract mathematical property that's hardware independent, or rather does it  (I'm guessing) depend on how the underlying hardware works?  In which case, how do we choose good sync words for the RFM69 that have good "auto correlation"?  I have not even an inkling, other than to apparently avoid repeating bit patterns (as suggested by the Silicon Labs link) that look like a preamble.

Ay yi yi.  Sometimes it feels like we practically have to be able to build an RFM69 all the way up from gates and transistors in order just to use one!

I would guess auto-correlation is a measure of how well bit shifted versions of the same value match, but I'm as in the dark as you are as to how to calculate such a thing other than as you say avoiding patterns that look like a preamble.

I did find this post that might shed a little light on it:
https://e2e.ti.com/support/rf__digital_radio/etc_rf/f/228/t/313209

Mark.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Sync bytes used by RFM69 library
« Reply #23 on: March 15, 2017, 01:56:59 PM »
I suppose it might be telling that Semtech's default for the number of sync bytes (following a power-up or reset of the sx1231h) is 4, according to the DS.  That's consistent with Joe's theory that 3 is barely the minimum.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: Sync bytes used by RFM69 library
« Reply #24 on: March 15, 2017, 03:31:36 PM »
I think thats the preamble bare minimum for 300kHz BR.
Mark.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: Sync bytes used by RFM69 library
« Reply #25 on: March 15, 2017, 05:03:52 PM »
Which number?  3 bytes or 4 bytes?


joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Sync bytes used by RFM69 library
« Reply #27 on: March 16, 2017, 03:39:56 AM »
Quote
but I'm as in the dark as you are as to how to calculate such a thing other than as you say avoiding patterns that look like a preamble.

The auto-correlation at n is just the sum of the product of the de-dc biased sync word with itself, shifted by n bits. It obviously has a spike at n = 0. It might have other lobes at higher or lower n. The extent of these non 0 lobes shows how much it repeats.

Choosing a good sync word seems to be a science in itself. Here's how bluetooth does it: https://books.google.de/books?id=mUyiREePWHwC&pg=PT92&lpg=PT92&dq=sync+word+autocorrelation&source=bl&ots=0AvJU8ApVs&sig=mqqPrelMnGJ2WxF6xt7xlF7iMo8&hl=en&sa=X&redir_esc=y#v=onepage&q=sync%20word%20autocorrelation&f=false.

And if you use the best two byte sync word (using the third byte as your network address) I bet the side effect is that you might be using the same one as all the others :).

For me this goes into the "later" stack.

EDIT:

I would however caution everybody to switch off auto-discard of non CRC matched packets from time to time and see how much junk hits. My guess is you'll be surprised, esp. if you use the RFM69 default settings. If you're seeing 1% failed transmissions on an otherwise perfect link a too short sync-word might well be the explanation.

Joe
« Last Edit: March 16, 2017, 03:55:35 AM by joelucid »