Preamble length when using "Dumb" RF modules...

[Grogster]

Hi folks.

Is there any kind of rule as to how many bytes of preamble you send when using "Dumb" RF transmitter/receiver sets?

In my current experiment, I am using 10x "U" characters, to sync the data-slicer in the receiver, and that is working just fine.

So my questions are should I be using more then ten bytes? Would more then ten sync bytes increase reliability etc? One would think that more preamble bytes will give the receiver more time to sync the data-slicer, and so in theory, should be more reliable.

...or is that false logic?

How many sync bytes do others here use?

TX/RX pair are Radiometrix NTX2/NRX2, the 10kbps version.
Baud-rate is 2400.

As I say: everything is working 100%, I am just curious as to if I perhaps should be using more preamble bytes or not. Perhaps it is simply a case of "Whatever works."?

 

[srnet]

Seen that post somewhere else ........

Shirley an experiment is called for ?

Slug the transmitter in some way, in a tin box for instance. Repeatedly send a standard messages, "QuickBrownFox etc, and then see at what distance the message is received 100% with 2 preamble bytes, then 3 etc. If you slug the TX enough the useable range you ought to able to get the range down to around 10-20M, so testing in the garden or street is possible.


At least then you will actually know the minimum preamble for reliable operation.

 

[westaust55]

Here:http://www.picaxeforum.co.uk/showthread.php?11531-433-MHz-wireless-link-trick&highlight=Preamble
Womai (Wolfgang) first alluded to the benefits of a preamble and his example had 10 $55 characters.
Within this thread and another the actual purpose/mechanism for the preamble and by hippy why it should be $55 and not $AA for both high and low idle comms is explained.

 

[MFB]

Can't you just use the rfout and rfin commands and the Manchester encoding do the bit balancing automatically?

 

[Grogster]

Thanks guys.


@ srnet - probably on the Backshed Forums - I am a member there too, and posted the thread there, but no replies, so I thought I would see what the folks here thought.
@ westaust55 - thanks - will read that thread.
@ MFB - I could, but I developed the prototype system without using RFIN and RFOUT, so in order to maintain compatibility across the transmitter units, I need to stick with unencoded serout commands. Future designs will, naturally, use RFIN and RFOUT, but I can't in this case.

 

[hippy]

Is there any kind of rule as to how many bytes of preamble you send when using "Dumb" RF transmitter/receiver sets?

I don't know of any absolute rule, only that sending more than needed does no harm but too few and the data slicer won't be primed as well as it could be.

Shirley an experiment is called for ?

That could be a challenge because I think there's more to it than reducing TX power or checking when a message gets through or not. We are not looking for point of failure but looking for an optimal which is an unknown point beyond not failing.

Even a not very well primed data slicer can deliver 'perfect results' so how does one distinguish a not very well primed data slicer from one which is perfectly primed ?

One needs to determine how close the data slicer reference voltage is to the ideal after the preamble. That can be indirectly determined by how soon the data slicing fails in the presence of a permanent high or permanent low after the preamble; the more ideal the longer it takes to deliver a faulty result.

 

[srnet]

That could be a challenge because I think there's more to it than reducing TX power or checking when a message gets through or not. We are not looking for point of failure but looking for an optimal which is an unknown point beyond not failing.

I dont think so, its easy to write some software that sits there listing for 'messages'

You set the premable for 2 sync characters and run it for 1 hour, the software counts the number of valid 'messages' received.

You set the preamble to 5 sync characters and run it again for 1 hour.

Now ignore for a moment "looking for point of failure but looking for an optimal which is an unknown point beyond not failing" (??).

If 5 sync characters gave a better result than 2 sync characters (i.e more messages received) which in practice would be the best choice to use ..........

 

[westaust55]

For completeness of information, further to post 3, it is at post 14 here:http://www.picaxeforum.co.uk/showthread.php?17531-Serial-Wireless-etc-Questions/page2
that the logic behind the use of $55 is the best preamble.

Forgot to mention earlier that my own work with 433 MHz has usually had about 6 preamble bytes without experiencing difficulties/loss of data over ~30 to 40 metres on a suburban house block

 

[hippy]

If 5 sync characters gave a better result than 2 sync characters (i.e more messages received) which in practice would be the best choice to use ..........

Obvious 5 but at some point you reach a number at which there appears to be no difference, but there technically is; N-1 isn't as good as N but N is just as good as N+1.

Sending 5 may appear 'good enough' but would 6 be better ? Or 7, or 8 ? Or are we now sending more than necessary ? We can answer what is a minimal N but not what is an optimal N, only know it is higher than minimal but not by how much.

Sending messages and checking results works to a limited extent if sending $00 and/or $FF repeatedly but any other data which changes keeps the data-slicer level changing so you can't tell if it's just above the limit of working or closer to ideal.

The reason for seeking an ideal is that it is likely to be more ideal for other receivers. Good enough for one might not be good enough for any other.

 

[srnet]

O

bvious 5 but at some point you reach a number at which there appears to be no difference

Yes you would expect there will be a point where there is no measurable difference.

 

[hippy]

Yes you would expect there will be a point where there is no measurable difference.

True and that's the minimum to use but not necessarily the optimal value to use.

There's a value which works for those particular tests but it's not necessarily the optimal value for all cases ( which won't have been tested ). If the receiver breaks and a replacement is substituted that may not behave exactly the same, it may fail where the current one passes. It can be the same if someone replicates the project. A more optimal value is more likely to work for all cases.

It's "how many does this project need" versus "how many should this project have". Unless saying it should have as many as are needed the second question remains wide open.

 

[Dippy]

http://www.radiometrix.com/files/additional/your-data-over-a-simple-radio-link.pdf
QI.