Author Topic: What is the shortest frame/packet that can be sent and still received?  (Read 14339 times)

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
By choosing a fixed length packet format, it appears that one can save a byte (namely, the packet length).

Then, from section 5.5.2 of the datasheet, it appears that one must include:
1. Preamble
2. sync-word
3. one message byte

This would be with CRC turned off and no address byte.

So, is that the shortest that's possible?  Is the sync-word truly necessary?

[Edit: Also, is it possible to load the next packet into the FIFO before the current packet finishes transmitting?  Basically, I want to be able to send very short packets as quickly as possible (so as to reliably hit a 128usec wide Rx window while in Listen Mode).  Would that necessitate a continuous mode transmission?]
« Last Edit: March 08, 2017, 07:22:56 PM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Is the sync-word truly necessary?

That's a very interesting question. I've wondered how the sync word is really detected. Let's say the preamble was 2 bytes, and the sync word 1 byte. The bit synchronizer has to lock on to the preamble, and that requires the demodultation to work, and that can occur some way into the preamble. So now let's say the sync word was set to 0xAA. If the sync word came directly after the preamble we'd get this:

101010101010101010101010

This could match anywhere in this stream after the bit synchronizer has locked! So my assumption is that some means to indicate where the sync word starts is present in the stream. That could easily be done by replicating the last bit of the preamble because they are supposed to be alternating, so what is actually transmitted is this:

1010101010101010010101010

If this is how they've done it then the sync position (i.e. the byte alignment for data) can be done without a sync word at all as the repeated preamble bit tells you where the data starts.

It appears from the sx1231h that you can turn sync word detection off by clearing the SyncOn bit in RegSyncConfig. So this is consistent, the answer is you don't need a sync word.

Mark.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
I wonder if even the preamble can be done away with?  Figure 33 in the datasheet for a fixed length packet seems to suggest both the preamble and the sync word can each be zero bytes long.  If I'm reading the figure correctly (?), a minimum packet would be just 1 byte long: just one byte of message.

ChemE

  • Sr. Member
  • ****
  • Posts: 419
  • Country: us
I was able to get down to 0 bytes of preamble but my range suffered a bit.  Any further than about 6' and I could no longer get packets across.  1 byte of preamble got me to 30' or so and then the 2nd preamble byte got me to 150'+.  All at power level 0 with a RFM69W mind.

https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/send-waaay-fewer-packets/

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Thanks, ChemE.  That's good to know.  In my case I'm not afraid to go higher on the Tx power, as that would be coming from the gateway.

Turns out that the standard packet made by the RFM69 library is too large to fit inside a 128uSec Rx window.  That's why I need to pare down the size.
« Last Edit: March 09, 2017, 07:22:20 AM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Quote
Is the sync-word truly necessary?

The problem without sync word is that you'd receive something anytime the RSSI threshold is met. So it means lots of garbage if you're not alone out in the woods. In fact I've had to increase the sync id to 3 bytes because I saw frequent phantom packets with 2 given that my RSSI thresh is at 255.

Quote
a minimum packet would be just 1 byte long

A related nugget: in variable packet length mode the length of a packet can be zero, resulting in a 1 byte message (just the 0 length byte). This is important since only the packet contents are encrypted in 16 byte chunks, not the length byte (obviously). So a 0 byte payload packet is 1 byte long (not counting preamble and sync) and a 1 byte payload is 17 bytes long. This can be used to send small sync packets.

Joe

joelucid

  • Hero Member
  • *****
  • Posts: 868
Quote
So my assumption is that some means to indicate where the sync word starts is present in the stream.

The datasheet describes sync word detection just as a bit shift register. It would be interesting to check if packets can be received correctly if the sync word has the same pattern as the preamble. My bet is no.

Joe

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
The datasheet describes sync word detection just as a bit shift register. It would be interesting to check if packets can be received correctly if the sync word has the same pattern as the preamble. My bet is no.
Joe

There would be a whole shed load of forbidden sync word values if that were the case, a continual bit shift and compare operation is done in things like 4B5B encoding but in that there is a unique sync pattern even under bit shifting conditions. There's no encoding here, and the sync word can be arbitrarily selected, so there has to be a delimiter in the stream. Plus it won't know what is data and what isn't, so where is it supposed to stop checking?

Edit: Also you can turn sync word off using the SyncOn bit, so if you turn it off how is it supposed to byte align data into the FIFO without a delimiter?

Mark.
« Last Edit: March 09, 2017, 07:13:49 AM by perky »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us

A related nugget: in variable packet length mode the length of a packet can be zero, resulting in a 1 byte message (just the 0 length byte). This is important since only the packet contents are encrypted in 16 byte chunks, not the length byte (obviously). So a 0 byte payload packet is 1 byte long (not counting preamble and sync) and a 1 byte payload is 17 bytes long. This can be used to send small sync packets.

Good to know!  I had taken Figure 34 at face value when it said the minimum size for variable was 2 bytes. 

The problem without sync word is that you'd receive something anytime the RSSI threshold is met. So it means lots of garbage if you're not alone out in the woods. In fact I've had to increase the sync id to 3 bytes because I saw frequent phantom packets with 2 given that my RSSI thresh is at 255.


Ah, so that's where the rubber finally hits the road on all of this.  I was beginning to hope that without a preamble it might nonetheless throw out frames that weren't "well formed" (meaning that the "on-the-air" length of each bit was within expected parameters for the given bitrate).

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
This could match anywhere in this stream after the bit synchronizer has locked!

I know that in some OOK implementations there's a kind of "air gap" between the preamble and the data that follows, rather than it all being one continuous bitstream.  Perhaps that's why, and maybe something similar is going on here. 

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: What is the shortest frame/packet that can be sent and still received?
« Reply #10 on: March 12, 2017, 01:16:06 PM »
I've pared it down to where there is no preamble and no CRC and it is transmitting a fixed length packet of payload length 1, but while still using the RFM69 library's default 2 sync bytes.  That works.  However, when I turn off sync words entirely by setting RegSyncConfig=B00000000 on both the sending and receiving nodes, then the transmissions are no longer received.  Must I do something else also?  Transmitter and receiver are close enough together that range shouldn't be an issue.  Indeed, I've tried a whole gamut of different ranges by moving them closer, and that does not appear to make any difference.

« Last Edit: March 12, 2017, 01:46:55 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: What is the shortest frame/packet that can be sent and still received?
« Reply #11 on: March 12, 2017, 02:18:48 PM »
By the way, I'm still getting perfectly useable range even with no preamble.  I'm not pushing the lower limits of transmit power though.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: What is the shortest frame/packet that can be sent and still received?
« Reply #12 on: March 12, 2017, 02:33:21 PM »
OK, I've been able to pare it down to a single sync byte plus 1 payload byte.  However, presently it fails if I drop the sync byte.

[Also, confirming what Joe said, I do pick up quite a bit of garbage unless I raise the RSSI threshhold quite a bit.  Maybe I should search for a clearer channel.   ;) ]
« Last Edit: March 12, 2017, 02:41:21 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: What is the shortest frame/packet that can be sent and still received?
« Reply #13 on: March 12, 2017, 03:20:33 PM »
Interesting result:  with these short Rx windows, I'm actually better off including a preamble.  Otherwise, even a packet that hits inside the Rx window is more likely to not decode correctly (effectively miss), and the result is needing an even wider window than required to accommodate the preamble in order to guarantee a high hit rate.

So, I'm OK with one preamble, but I'd still like to ditch the one remaining sync byte.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: What is the shortest frame/packet that can be sent and still received?
« Reply #14 on: March 12, 2017, 04:37:25 PM »
I think there are equations in the sx1231h datasheet that allows you to calculate the minimum time needed to ensure the bit synchronizer locks, and there's a dependence on bit rate and RxBw (TS_RE), plus 12 bits of received preamble.

Back of a fag packet calculation, For RxBw = 500kHz, Tbit = 1/300kHz with no AGC or AFC:

TS_RE = Tana + Tcf + Tdcc + Trssi + Trssi

Where:
Tana = 20us
Tcf = 21/(4*RxBw) = 10.5us
Tdcc = max(8 , 2^(round(log2(8.RxBw.Tbit)+1)) / (4.RxBw) = 16 / (4*RxBw) = 8us
Trrsi = 2 * Tbit = 6.7us

So TS_RE = 20us + 10.5us + 8us + 6.7us + 6.7us = 52us, or 15.6 Tbits.

Then you need to add 12 bits for the bit synchronizer to lock, so you'll need 27.6 Tbits, or 4 bytes of preamble :o

Mark.