UART operation for digital radio link
I need some help to catch up again with radio communications. Although I obtained my degree in communication five years ago, I did no practice in the field, since I switched my professional interest to embedded design. Recently, I had to design a simple radio link, and I need to catch up.
It is a point-to-point unidirectional link between two ATMEL AVR family MCU's. At the Tx side I would use hardware UART, and at the Rx side I would use a software UART, since the hardware UART is occupied (the Rx side used as a gateway into a multidrop 485 network for the Tx).
I bought a few FM Tx and Rx modules and I am ready to go. I have read through many posts here, and also did some research on the internet and through books, but still not sure. My data rate should not exceed 1kb/s, and the frequency is 433MHz.
I need some advice here regarding the UART operation. I know about preamble, Manchester etc, but...
Let's say the UART is idle for a while, i.e.there is logical '1' at the input of the Tx module. Since the Tx is on, it will transmit '1's all the time, and the Rx will be also idle as there is no start bit at its input.
What happens once I switch on the Tx UART? If I start to send data I guess because of the DC level the character will not be interpreted correctly? I know for this preamble technique, but if I send let's say three bytes of preamble, how could I distinct when the preamble finishes and the data start - let's say the first preamble byte is not interpreted correctly, then after the two correctly received preamble bytes I should expect another preamble byte, not data (couldn't this way data be lost?).
If I go on to Manchester coding, I have the same concern with lost bytes of preamble, since UART Tx was idle for a while, RF Tx transmitting '1's all the time - lost DC balance at the Rx. Also, what to do with the starting '0' in UART transmission? How I make hardware UART transmitting Manchester?
Many thanks in advance
In an modern FM transmitter there is a control loop called a phase locked loop that keeps the frequency of the transmitter at the center of the channel. This is contrary to the operation of an FM transmitter, since the information is imparted in the deviation in frequency ±Δfm away from the channel center frequency. There are two ways that the FM modulation is imparted onto the carrier. For your low data rate application, you should make sure that you use #2:
1) in the control voltage to the VCO oscillator, there is a dc blocking capacitance, and a digital signal is AC coupled onto the control voltage. In this type of design, you want the open loop bandwidth of the PLL loop filter to very small, perhaps < 0.1 the data rate. Since you have such a low data rate (1kbps) the PLL will be fighting your modulation signal, causing a sawtooth frequency output.
2) the control loop in the PLL is the only voltage controlling the VCO. In the PLL digital dividers, you change the divisor ratio to impart the modulation. Let say that you have a 433 MHz carrier, and you want it to deviate ±100 KHz. If your PLL uses a 100 KHz reference frequency, the divisor ratio would change from 4331 to 4329, corresponding to a transmitted frequency of 433.1 MHz and 429.9 MHz. In this case, the PLL Loop filter has to have a very wide bandwidth, perhaps 10 times the data rate.
One benefit of #2 above is that if you send a long period of 1's, the frequency just stays at 433.1 MHz, and the very next 0 you send will have the frequency change to the correct 429.9 MHz without the need for a header.
hi,
I've done a 'PIC to PIC' radio link for a friend a while ago, I used manchester encoding as well, for the DC balance, and bit synchronisation. I didn't use a hardware UART, both Tx and Rx were software, with a 2.4 (ish)kb/s.
I ended up having 4 bytes preamble, consisting of 3: 0x55, and 1: 0x99. After that was a 'sync' byte, that deliberatley violated the manchester ecoding scheme, by having 00011101. I think this is common practice, since three 0's, or three 1's can never occur anywhere in the manchester encoded data, only in your 'sync byte'. So once you've detected that, you know that anything after it is data.
When people use a PLL, they want as many transistions as possible, so the preamble usually consists of 0x55 (01010101), which in manchester encoding means 1111. However, for your reciever, you could try sending 00110011. Because, there can be a maximum of two transistions per manchester 'bit' (sorry if you already know this). So, you want to ignore any transistions between 'bits' and only look for transistions in the middle of bits. And that byte only has transistion in the middle of bits.
As for using a UART, this site (wonderful site it is :))
http://www.quickbuilder.co.uk/qb/articles/
Uses a UART, and cleverly uses the start and stop bits as part of the manchester code. This is what I based my design on, before I moved to a CPLD for the baseband.
Also Microchip.com has an application note for using a PIC micro for 'kelloq' radio transmission. I assume Atmel will have something similar for their chips.
just to recap, don't 'use' the preamble as data, its there to get the DC balance back in the RF Rx. It might be wise to have your Rx micro look for the preamble, but not 'accurately'. Otherwise, if you look for exactly 3 bytes, of say 0x55, the RF Rx won't have time to set its DC balance. You can however, have you Rx micro look for any change in the signal, so its not looking for the exact value of the preamble, its just looking at transistions in the signal, and setting up a timer to sample in the correct place. Say you've got a simple counter, once this gets to '8', that means you've got enough transistions that are equally spaced for you to start looking for your sync byte.
Sorry, went on a bit there, but I spent ages trying to perfect the datalink with manchester encoding, after all, you don't want cut-outs because you've missed a tiny bit of the preamble or sunc byte.
Right, good luck, and I'm sure that link will explain it far better than I can. Ignore the parts you know already, hope this helps.
BuriedCode.