433Mhz

Can anybody tell me why is the code below, you need the 85,85,85,85, before the rest of the string? Also I noticed in other programs that use this 433mhz transmitter/ receiver system, some use just the letter U, U,U, instead of the 85 why?

Thank you,
Mas11


tx: ' 434MHz UHF transmitter & DS18B20 temp reading routine

high 2 ' turn on DS18B20 temp sensor
wait 1 ' settling time pre temp reading
readtemp 1,b1 ' direct Celsius value returned
low 2 ' turn off DS18B20 to save power!
serout 4,n300,(85,85,85,85,"ABC",b1) 'remote RX wakeup preamble (85=ASCII U =01010101)
pulsout 0,200 ' red LED winks as data sent
sleep 26 ' power down 1min etc (adjust to suit -SLEEP units 2.3 sec)
goto tx ' loop to send more data

ASCII code for "U", decimal 85 and Hexadecimal $55 are all one and the same value which expressed in binary is % 0101 0101.

The purpose of the sequence of characters is as a pre-amble to help the receiving end of the radio link synchronise with the Tx part.
That pre-amble is then flowed by a break/pause whose length is just marginally less than the duration of sending a byte at the selected baudrate to allow the Rx part to better synch with the start of a new byte which will be a qualifier or data.

I believe forum member womai can be credited with first posting about the advantage of the pre-amble and delay prior to the desired data transmission.

There is also a post by hippy which explains why $55 is preferred as opposed to $AA whether the SEROuT is using True or iNverted protocol although at face value the two may seem similar as a sequence of alternating 1's and 0's.
As I am not near a PC this week and iPhone is relatively slow in remote West Aust, I leave it to you to search the forum further for womai's and hippy's past posts.

The 85 or "U" ( and also $55 and %01010101 ) are all the same, an alternating sequence of 1's and 0's when sent via serial. Any of those can be used and it's just a matter of personal preference. I personally don't like use of the decimal 85 as it doesn't reveal the alternating bit pattern. I usually use "U"; although it suffers the same problem it's a shorter sequence to type.

This conditioning sequencing is useful and often essential for the RF receiver to 'stabilise itself' and then reliably determine which are 1's and 0's of the data which subsequently follows.

It's also recommended to put a short pause between sending the "U" preamble and sending the rest of the data to help the receiving PICAXE properly synchronise to the data and not halfway through the "U" sequence itself.

A further comment on the program snippet you included in post 1.

There is a line to turn of the DS18B20 to reduce power consumption.
Yet this device consumes only a max of 1.5mA when performing a temp conversion and far far less when idle.
By comparison (from datasheets and my own tests) many sime 433 MHz Tx modules consume around 10mA when operating/transmitting.
My past posted work has taken the approach to disable the Tx module when not actively required which may also prevent unwanted emissions during idle times.

Rather than including a preamble that allows the RF receiver to "stabilise itself" it would now be better to use the relatively new rfin and rfout commands, as these use Manchester coding that automatically maintains the correct sequence of 1's and 0's.

Yes, but preambles are for slightly different reasons.
It kind of gets the the receiver 'going' and helps sort 'something' from mushiewushie, and it can be parsed better than noise yes?.
In some receivers it can also be used with RSSI to help reject noise and act as a threshold.
It's a kind of multipurpose thing and shouldn't really be ignored just because you have encoded.
You need all the help (techniques) you can get with RF to sort the wheat from the chaff

The usual method is: preamble...synch word (a bit like 'wait')... data (whether Manchester or not).

Thanks for the reply.

Mas11

I normally send a preamble followed by my data in Ascii with a preamble inbetween each block of data like this.

serout 0, T2400,($aa,$aa,#volt, $aa, #Amp ,$aa ,#RPM, $aa,#Wind, $aa,#Check,$aa,13,10)

Using Ascii creates a filter from the preamble, and the receiving end just looks for Ascii data and will ignore the rest, the need for non Ascii data between each block of Ascii is to allow the stop bit to be seen or one block of Ascii will flow into the next and corrupt data will result.
I have logged data for a long time using this method and get reliable data over about 50m distance.

A lot is said about preambles but it really isn't clear what they do, and there is a risk of confusing the novices.

In the case of old mechanical RTTY the preamble helped to get the motor up to speed and thus get the mechanicals ready to receive a character.

In the case of a synchronous comms link, then some way of syncing the clock is useful, but if it was a sync link it would have the clock the whole time anyway.

If it is an async link then the start bit is what syncs the UART, nothing else, that being the point of having a start bit. And that is done in the code. All Picaxe serial comms are async.

If it is a superhet receiver and has AGC then receiving a preamble will help to get the agc level right to set the gain so as to minimise noise. But most 433MHz modules, at least the cheap ones that I use, are essentially single stage trfs and thus have no agc or indeed any feedback. So there isn't anything to sync.

Manchester coding is claimed to be good because it allows clock recovery from the signal. Which is fine if you need a clock but if it is async comms you don't, and having one would confuse the timing (adjacent characters do not follow the same clock phasing). It also means the rx can be linked via a capacitor as there is no dc in the signal, but I don't think that is a practical advantage for Picaxe input pins.

If you are using 'idle-high' serial characters then it helps to send a 1-level signal for a short period before the character so the UART can spot the negative-going edge that begins the start bit.

What we all seem to lack is actual data from actual tests of error rates or range. We also lack any details of the UART algorithm in the Picaxe firmware that might help clarify what exactly triggers the decoding of a character and what help it might need to spot a start bit correctly, if any. But what it should be doing is spotting and measuring the start bit and then restarting the same algorithm for any subsequent character, with no timing relationship between the two (by definition).

If anyone has the time and energy to do some tests I expect that would be very useful (how about that as a school project for someone?). Meanwhile, I get 40m range (for short packets with a valid checksum) line of sight with just a simple tx and rx (e.g. telecontrolli RT4-433), and a Picaxe directly connected with no special coding and no preamble.

Happy to be contradicted but lets have some rigour here!

73s

Thanks for the help, but your confusing me with preable and Manchaster coding. All I want to do is send temperature and humidity over a distance of about 10 meters. So if anybody can explain that it would be appreciated.

Thanks,
Mas11

All i would use is as per below, but i am sure others might do it differently.
You will need to name your variables temp, and humidity or what every you want, and change the pin numbers to suit your circuit.
Note the 2 code examples are serout for the TX and serin for the RX.

@geoff07,
Did you try a search for the thread started by womai that I had mentioned?
See here:http://www.picaxeforum.co.uk/showthread.php?11531-433-MHz-wireless-link-trick&highlight=Preamble
I had started some work with 433 MHz Tx and Rx modules about the same time and was also missing data occasionally until I added a preamble PLUS. Brief pause.

As also mentioned above hippy has posted the basis as to why $55 rather than $AA should bs used.
Have you searched for that?

IMHO proof exists that a preamble and pause prior to data certainly helps.

Post 12 here also gives some info:
http://www.picaxeforum.co.uk/showthread.php?17531-Serial-Wireless-etc-Questions/page2

Sitting under some shade overlooking the ocean from the Pilbar coast on a hot (40degC) and humid day while eating my lunch with mobile phone coverage decided to do a quick search and found the previously mentioned thread with hippy's information.
See post 12 here:
http://www.picaxeforum.co.uk/showthread.php?17531-Serial-Wireless-etc-Questions/page2
For why the preamble should comprise a series of $55 values

This extract from the http://www.picaxe.com/docs/axe213.pdf manual states...

"The NKM2401 ‘Manchester encodes’ all data and automatically
sends out the required RF preamble, data, checksum etc. so the user is left to simply
send bytes of data and receive bytes of data"

Therefore, using the PICAXE rfout command will automatically insert a preamble. I have used the NKM2401 chips, and the PICAXE, rf commands with low cost 433MHz wireless to produce robust data links over tens of meters. Just read the above Rev-Ed documentation and go for it!

I would also second MFB's recommendation of using the RFIN / RFOUT commands or an NKM2401. Doing that saves having to hand code the preamble, pause and data qualifiers and generally turns RF comms into 'send eight bytes', 'receive eight bytes'; a far simpler proposition with no need to really understand how it works behind the scenes.

So can i take it that the RFIN and RFOUT commands work with any 433 modules or is that only applicable to Manchester code modules, as my understanding was the modules the OP has are a standard garden varity and not MC modules, i have seen no mention of NKM2401 by the OP so where do that fit in here?

RFIN and RFOUT should work with any dumb RF modules; it's just a sequence of 1's and 0's sent and received, same as would be passed using SEROUT and SERIN but without the complexity of having to do all that.

No, the OP did not mention NKM2401; it's a suggested solution instead of what they are doing.

Let Us not also lose sight of the fact that the RFIN and RFOUT commands are only available on M2 parts and the 28/40X2 parts.
Not available on M, X, X1 parts or the 20X2 when manual2 is consulted.
Many members still have available these "other" chips which may find their way into radio link projects.

Far be it from me to argue with hippy. And there is indeed a lot of material on the subject. But none that I have found actually explains which bit of the system is making use of the preamble and why it makes a difference. If something is being synchronised, then what is that something? As I explained, in a simple rx there is nothing to sync. If there is agc then that might be useful, but cheap rxs don't have agc. If a series of 1s and 0s helps the Picaxe sw to synchronise, then how is that?

By definition, async characters are detected by observing the polarity change due to the occurrence of a start bit after an indeterminate period of the stop bit plus interval delay following a previous character. So the bit clock is reset for every character based on the receipt of the leading edge of the start bit. The sw does not autosense the bit rate, it knows what it has been told to expect. The receipt of one async character says nothing about the arrival of the next. As the bit rate is known, the only issue is phasing, which is set by the start bit of a character for only that character. All assuming a clear channel.

In principle, for reliable async comms, then all you should have to do is to ensure that there is a long enough period of stop bit polarity prior to the start bit for the character to be properly recognised.

If the Picaxe software works differently I would love to know how!

The use of Manchester encoding is slightly different, as in this case, you are sending bursts of pseudo-synchronous comms, and in that case a preamble might help the logic to use the Manchester clock recovery to make fine adjustments to the bit rate that is expected and thus improve the readability. But does it actually do that?

It seems to me that there is a lot of confusion especially amongst novices about radio matters, and we should be able to pin down not just what to do but why. Some aspects of radio are akin to black arts (antenna design and propagation for example) but data comms is straightforward.

In case I have added to the confusion, I second hippy's advice above to novices, and would simply use cheap rx/tx modules, and RFIN/RFOUT in the code. The advantage of RFIN and RFOUT being that the qualifiers (that line up the characters with the bytes into which they go) are done behind the scenes and there is a checksum, the combination of which saves a lot of coding effort compared to doing it yourself.

@ Geoff,

Excuse me for not reading all your post, but from what i have found, these "dumb" RX modules have a sleep mode or low power mode that requires a little time for them to wake up and get on line (what is clamied to be synchronise) so it is an advantage to send a string of "garbage" (preamble) to wake them up prior to the actual data.

>But none that I have found actually explains which bit of the system is
>making use of the preamble and why it makes a difference.
>If something is being synchronised, then what is that something?

No, the preamble DOES NOT synchronize anything. What is does is the following: These cheap, dumb 433 MHz receivers have a variable gain input stage. If there is no actual signal (only random noise) coming in then this stage will have the gain cranked up to maximum, and you will see a random sequence of ones and zeros (i.e. NOT just e.g. a solid low) coming out from the data output. A data byte getting received at this moment would not be processed correctly because the receiver would still react to both signal and baseline noise. The preamble now "conditions" the input stage so it reduces its gain to a proper value and thus ignores the noise.

How many preamble bytes you need depends on a variety of factors - actual data rate, type of receiver, noise level and so on - in my experiments I saw 2-3 when running at 4800 baud, so I normally use 5 bytes to be safe. A scope or logic analyzer is a big help for such investigations.

Second, the receiver chain is AC coupled so it can't transmit a long sequence of all 1's or all 0's - your data must switch polarity sufficiently often and have approximately equal numbers of 1's and 0's over every not-to-long stretch of bits. Manchester coding achieves that naturally since it encodes each bit in a single 1 plus a single 0. There are other schemes that achieve the same thing (e.g. 8 bit / 10 bit encoding, 8b/10b, used in modern Gbps SerDes channels) with less overhead, but Manchester coding is by far the simplest way.

Finally, a marker byte (or bytes) tells the receiving Picaxe where the actual data starts.

To sum up, the preamble is NOT optional, and it is NOT just some "snake oil" miracle cure - there are solid reasons why it has to be used. Second, preamble and Manchester coding (or some other way of achieving DC balance) are two independent conditions to achieve correct data transmission. Please also read carefully through the old thread of mine that Westaust already mentioned, http://www.picaxeforum.co.uk/showthread.php?11531-433-MHz-wireless-link-trick&highlight=Preamble, as it explains some more intricacies (pause after preamble to assure reliable sync to byte boundaries).

So a reliable transmission protocol - tested in practise many times - looks as follows (and NONE of the four steps is optional!):

(1) preamble - conditions the receiver's input amplifier
(2) short (~15 bit periods) pause - assures receiving Picaxe will correctly sync on start of serial byte
(3) marker byte(s) - lets Picaxe detect start of actual data Packet
(4) data packet (Manchester encoded if it is longer than a few bytes so receiver's gain stage can't fall out of lock)

Wolfgang

Absolutely, we tend to go on about preamble in such a general term and there are a million different designs around.
Data-slicer settling, wake-up .. several reasons like I said before.
If a particular dumb module works well without it then hurrah, but it doesn't mean it's a general valid statement for optimum efficiency.

Smart modules tend to have all this done for you, so a 'manual' preamble on a CC1101 (when enabled) may be superfluous.
Many of the Smart encoder chips also do it for you.
The Synch byte/word saves you having to do a wait-for.
Again, smart modules and chips tend to do it all for you.

This is where someone like Myk from Radiometrix would have good input. He's a nitty-gritty radio man rather than a black-box / chip user like most of us here.

Try it with and without. Have a play. Experiment. No preamble, short or long, what's good for your dumbo. Some dumb modules may respond quicker than others. Can't generalise. But, for dumb modules, there are good reasons generally to use preamble and synch.
As they used to say in a cream-cake advert; don't talk ... eat!

The Rx modules don't really cope with a constant signel level, high or low. What they like are changes, preferably a signal that is 50% high and 50% low.

The "UUUUU" preamble produces this and gives the receiver a chance to sort itself out and set the levels for 0 and 1 correctly so the data following is decoded correctly. Normal data is not 50% high and low, a sequence of spaces for example is mostly 0s, so if you are sending a lot of data there's a possibility that it will get unreliable. Manchester encoding fixes this and the data become 50% high and 50% low. There's a lot more from a search for things such as "Manchester Encoding".

The simplest way is to use the rfout and rfin commands and/or the NKM2401 modules. This means that all the hard work has been done and all you do is send and receive packets of 8 bytes.

I've done this using the rfout command on a 14M2 and a NKM2401 connected to an Arduino. It Just Works. The transmit code is:
The receive code looks for the 'X' header, then reads the next 7 characters to get the data.

My opinion if that if you just want to get something working this is the way to go, but if you want to explore data transfer there's a lot of fun to be had experimenting with this.

Chris

geoff07 said:

It seems to me that there is a lot of confusion especially amongst novices about radio matters, and we should be able to pin down not just what to do but why.

Click to expand...

There certainly is confusion particularly with novices copying code which they don't understand nor know why the code is as it is or the reasoning behind it. It doesn't help that source code propagates which isn't entirely sound, usually in not having the pause after the preamble.

Wolfgang's description above is about the best that can be explained without going into greater depth and that's also been repeated in various ways on the forum in the past.

Perhaps what adds to the confusion is that SEROUT and SERIN work with RF more by good fortune than by design. There's something of a disconnect between what is done and what it achieves. One has to work back from an understanding of what RF requires in order to understand why the PICAXE code is as it is.

We introduced the NKM2401 and RFIN and RFOUT commands to ease the use of dumb RF modules to aid novices and others. People are welcome to use other means if they wish but they really need to have some understanding in what they are doing.

I think http://www.picaxe.com/docs/axe213.pdf is an excellent introduction to using dumb RF modules for the novice. The NKM2401 and the RFIN/OUT commands are very easy to use and I have found them to give good results on even the cheapest of RF modules. Its therefore a pity that some of the advice given on this thread may make the task look overly complicated. Surely its better to get a novice's project up and running with as little fuss as possible, which may lead to more detailed experimentation later.

The AXE213 modules are good for anyone who wishes to achieve radio comms links with minimal PiCAXE overhead and knowledge.

I do note that the AXE213 datasheet uses SEROUT and SERIN and while there is mention of a preamble there is no detail as to why as sought by Geoff07.

Thus there is still a place for those seeking more to read past posts by womai and hippy.

Dippy said:

Yes, but preambles are for slightly different reasons.
It kind of gets the the receiver 'going' and helps sort 'something' from mushiewushie,

Click to expand...

Kind of like transmission foreplay ;-)

nbw said:

Kind of like transmission foreplay ;-)

Click to expand...

Exactly!
It gives your node a definite 'grab' as opposed to the random jostling you might receive in a tube-train.
And once your interest has been aroused you will be more responsive to a vigorous modulation.
A superb comparison.

Well Dippy, all i can say is im glade i have never caught a Tube-train the same time as you.
I will stick with the bus from now i think, cant say i really ever got aroused on public transport.

Although it was a good comparison.