Problem with wireless serial transmisson

single channel transmitter 434mhz scheme circuit

Sorry to contradict, although all the previous comments are very valid.

It IS possible to reliably send serial data over an FM/FSK radio link directly from a UART without using Manchester encoding. I do it here on commercial products and at a variety of speeds from 2400 bauds up to in excess of 19200 bauds. The key is to understand why if fails when 'normal' data is sent and to condition the data before transmission to prevent it happening. The PDF mentioned earlier explains what goes wrong and why a data slicer has difficulty when averaging a moving target.

The clue to getting it right, without posting my source code, is to ensure that an equal number of ones and zeroes are present in each byte leaving the UART. It can be done and quite easily. Prototype tests here were done over a 40 metre range using 1mW ERP and in a very noisy RF environment, in fact several other radio links at similar frequencies were being developed and tested in the same room as the receiver. We sent over 3 million data packets, each 32 bytes long with zero loss. The system also recovered from transmitter power down and restart in no more than two packets. Each packet contained different data to simulate a real life scenario and it coped perfectly with any combination of bits in the transmitted UART bytes, including long chains of zeroes and ones.

Brian.

send words to serial using atmega8515

How it is possible without Manchester coding until and unless one uses encoder/decoder. Can you please send me your source code so that I can get the idea how to program.

I'll be very thankful to you.


----------------
Regards
Gaurav Sharma

manchester transmit assembly routine

betwixt said:

The clue to getting it right, without posting my source code, is to ensure that an equal number of ones and zeroes are present in each byte leaving the UART. It can be done and quite easily. Brian.

Click to expand...

Brian,
How is this done with the start/stop bits? Which microcontroller are you using, AVR, 8051, PIC?

I know you don't want to post your source code, however that is the only way I can believe what you are saying (no disrespect intended of course).

I have done similar to what you have done, (8 byte packets only) however it is NOT 100% reliable as you say. The odd time it does not work. I used a start byte, and an 8 bit checksum at the end of every packet. The key to reliability I found was to lower the clock rate on the microcontroller. (anything under 4 MHz was most reliable)

433 mhz manchester coding serial uart

Well, as I stated, I'm not prepared to divulge my source code but this should give you the general idea:

Remember the intention is to keep the number of ones and zeros balanced so the data slicer can easily find the mid point between them. If they are equal, the slicer will adapt to 50% of the recovered signal which gives performance, this is what Manchester (bi-phase) encoding also aims for.

Now consider that UART start and stop bits are opposite polarity so average 50% when added together.

For the data itself, the best way to ensure an equal number of ones and zeroes is to send the compliment of the data bits immediately after the bits themselves. So a one is followed by a zero and vice versa. It takes twice as many bits as normal but for this type of application that isn't usually a problem.

For example, to send 1010 you would 10 01 10 01 the original followed by its compliment. For 1001 you would send 10 01 01 10. you may notice that not only are the bits balanced but there are only 16 different patterns in the resulting stream which may make your software easier to manage.

To transmit one byte, take the high 4 bits and send them as 8, then send the low 4 bits and send them as the next 8. Which ever bytes you send, the result will always be 50/50 1's and 0's. Do not leave long gaps between consecutive bytes.

The whole packet must consist of a preamble to allow the data slicer to adapt, this applies whether using this method or true Manchester, it is just to overcome the time constant of the slicer averaging circuit.

At the receiver, the incoming bit stream is initially ambiguous, it is not possible to find the start and stop bits as they look the same as all the other bits. However, by using the appropriate preamble bytes, there are only a limited number of possible patterns that can look like <start, 8-bits, stop> so if one NOT matching the preamble is found, clear the UART and start reading again immediately so no bits are missed. It should find the correct framing in no more than 3 attempts (3 bytes), from now on the UART should stay in sync with the received bytes. Ignore any more preamble bytes (I double check and re-sync if a dud bytes arrives) and wait for a known start marker to arrive, this could be a null or STX character, anything you want that isn't the same as the preamble data. Then just read the rest of the message, discarding every second bit. Remember these are the bits added at the transmitter to balance the data.

That is it. It is simple to implement, very reliable and because it uses the UART it doesn't need any special software timing loops and can be interrupt driven.

I use PIC processors at each end with the data transfers running as background interrupt driven routines while the real work goes on in the foreground.

Brian.

manchester decoder, synchronize detect

Brian, I totally agree with you, and I have done the exact same thing with an atmega8515. However it is not TRUE manchester encoding. It worked pretty good, but it was not 100%.

wireless serial transmitter

betwixt said:

For example, to send 1010 you would 10 01 10 01 the original followed by its compliment. For 1001 you would send 10 01 01 10. you may notice that not only are the bits balanced but there are only 16 different patterns in the resulting stream which may make your software easier to manage.

Then just read the rest of the message, discarding every second bit. Remember these are the bits added at the transmitter to balance the data.

Click to expand...

Really nice logic !! Appreciate that...

But every second bit ?? Its first as i think data enters from bit D0 means LSB in serial.

And secondly, In my program I'm controlling the speed of motor by making a pulse train of 70% duty cycle using timer and then fed it to the L293D driver when appropriate button is pressed at transmitter unit. Let us suppose we have we want forward direction of motor. Then in this case at IN0 of L293D we have that duty cycle(70%) and at IN1 of L293D we have 0 considering only single motor.

So by combination of IN0 and IN1 the motor doesn't get 100 percent power. As in my case there is 70% duty cycle so only 7/10 percent of total power is fed to motor so its speed is slow.

Now tell me how can I send this complete pulse train via this logic ??

--------------------
Regards
Gaurav Sharma

manchester coding for serial transmission

Thanks for your comments.

Regarding it not being true Manchester encoding, that is absolutely true but there is nothing inherently 'protected' in Manchester coding either, like my example, it is only a way of ensuring a balanced frequency distribution of carrier energy. I would never say it was 100% reliable but tests have shown it to be *almost* 100% reliable in that given a poor signal path it showed over 3 million packets were transferred without a single error, these incidentally were sent as 16 data byte blocks at a high baud rate with the carrier switched off for 1.5 seconds between blocks. In other words, it had to re-adapt and re-sync every time.

Perhaps I should have said 'alternate bits' instead of every second bit but in truth, it depends on the order they were constructed at transmission. The bytes from the UART will normally be LSB first but the order of the bits in that byte is decided before sending. They are discarded by firmware after being read from the UART.

This system will never be able to cope with PWM as it is but to use it for motor control should be a very simple task. Gaurav, you state that you have a timer to generate the pulse train before sending it to the L293D. All you have to do is send a data byte (or more if necessary) and use that to program your timer duty cycle. The nice thing about my encoding method is that it does not rely on any timers except the one generating the UART bit clock, this is usually a hardware timer anyway. You can also use UART receive interrupts to alert the program that new data has arrived. This should leave almost all the processor time free to control your motor.

For example, send data byte 0x00, software sets duty cycle to 0%, send 0x80 to tell the software to generate 50% and send 0xFF to set 100%. That gives you control of the duty cycle in better than 0.5% steps and your code holds it steady until instructed to change it again so the amount of RF data sent could be quite small.

Brian.

nrf2401a basic

Thanks for reply first..

Regarding PWM, You mean to say I have to make that pulse in receiving microcontroller rather than in transmitting microcontroller. And generate that pulse in receiving microcontroller by transferring byte from transmitting microcontroller. Right ?

-------------
Regards
Gaurav Sharma

how can i send serial wireless

That is correct.

The transmitter sends INSTRUCTIONS to the receiver rather than the PWM itself.

The PWM is generated in the receiver microcontroller with the duty cycle it is told by the instruction.

You can of course expand the principle to use multi-byte instructions, either to give better PWM control or to do something completely different.

Brian.

serial to manchester encoded data circuit

That is OK!!

Now the problem I am facing is "How to separate out data and its complement in receiver microcontroller." As you gave example in your previous post.

Please tell me this trick.

----------------
Regards
Gaurav Sharma

duty holtek login

This is very easy. I use PIC 16F628A in my design but the principle applies to all controllers.

1. Read the byte from the UART into a register
2. Shift the register right (RRC instruction on PIC puts bit in the C flag)
3. Shift the register right again, overwriting previous C flag contents
4. Shift the result register right, copying C into its most significant bit
5. Repeat steps 2 to 4, four times

that will copy alternate bits from the UART into the 'result' register top four bits.

6. Wait for the next byte from the UART
7. Repeat steps 1 to 4 again.

Now two received bytes are converted to one by discarding (step 2) every other bit. The top four bits in the result continue to be shifted along as the bits from the second UART byte are processed until all 8 bits are in place.

Depending on the order you prepare the data before transmission, you may have to shift left instead of right and possibly swap steps 2 and 3. So long as you do the same at both ends it will work, all that changes is the order the bits are
transmitted.

Basically, by using a shift register you are copying the carry 'C' flag from one register to another. Shifting with the RRC and RLC instructions moves the end bit of the byte into the C flag. If you then RRC/RLC with a different register, the carry bit is moved into that register. By shifting twice (steps 2 and 3) you throw away every second bit.

Brian.

problème transmission série wifi

OK I completely got it what you are saying.

It means if I want to transmit 4 bits (data) I have to transmit 8 bits. Similarly, if I want to transmit 8 bits then i have to transmit 16 bits means in 2 bytes.
And then accordingly perform rotate operation as to extract data. Right ??

And secondly, I want to ask for how to synchronize receiver and transmitter on power on or it is not required ?

-------------------
Regards
Gaurav Sharma

continuous serial data transmission from 89c51

gaurav_sharma132 said:

OK I completely got it what you are saying.

It means if I want to transmit 4 bits (data) I have to transmit 8 bytes. Similarly, if I want to transmit 8 bits then i have to transmit 16 bits means in 2 bytes.

Click to expand...

Almost, because you transmit the compliment of each bit as well as the bit itself, you always send twice as many bits as in your original data. To transmit 4 bits you have to send 8 bits, not 8 bytes! In other words, each byte you read from the UART can have 4 bits of data extracted from it.

To achieve sync, send a string of 0xA6 bytes to the transmitter UART.

I leave the next part to you to work out:
Draw (on paper) the 1's and 0's that will actually be transmitted, begin with the 'start' bit from the UART, then 0xA6, then the stop bit. Now repeat the whole pattern a few times. You will see that there are three possible places along your line of digits that could be interpreted as data frames (start and stop look OK with eight bits between) but only one will actually have 0xA6 between start and stop. All you have to do is reset your receiver UART if it *DOESN'T* see 0xA6 so it can try again. If you do it quickly enough, you can start looking for the next start bit straight away. In theory, you should find the correct framing within three tries.

An interesting exercise !

Brian.

manchester uart

Cant we use 55h or 0AAh three or four times to synchronize receiver and transmitter...??

After synchronizing i have to simple transmit my data (data + its complement ) na ?

And secondly in your example of data 1010 it is transmitted as 10 01 10 01 but in this 10011001 there is continuous transmission of 0's and 1's. Is this works ?

Also note I'm using AT89c51
---------------------
Regards
Gaurav Sharma

radiotronix + pic18

Unfortunately, 55h and AAh are only alternating bits when not encoded. You might be able to use them and then switch to my coding scheme to send the data but it is probably easier to encode everything. Please remember that the whole reason for encoding this way is to ensure an even distribution of 1s and 0s in the data stream so the receiver's data slicer can work optimally. Even if you used 55 or AA to sync the stream, you would lose the sync as soon as an asymetric byte was transmitted. You also have to send a special byte to mark where the sync finishes and data starts and this too would have to be symetric. If you don't use the special byte it would not be possible to send AA or 55 as first data bytes, they would still be seen as sync.

Yes, my example with spaces between the bits was just to emphasize the bits being paired, in reality the bytes should be sent back-to-back with as short as possible delay between them. Any delay will upset the data slicer as the average signal level will fall. I prepare the data packet before transmission so I can reload the UART as soon as the previous byte has been sent. Depending on your micro clock speed, you probably have plenty of time for lots of instructions before needing to reload the UART anyway.

I have never used any 'AT' processors but I imagine they work much as most other device do. There is little difference between the operation of microcontrollers these days, only the speed and built in interfaces changes. Almost all my work is now on PIC devices, ranging from the 10F202 up to the 18F46J11.

ic str433

Q1.
What I'm trying to say is as in your example of transmitting 1010 is transmitted as 10011001.
My question is: Is this OK ? As there is continuous transmission of 0's and 1's in this 8 bit data(data + its complement).

Q2.
I'm taking about 55h or 0AAh(one of this) to use only to synchronize receiver and transmitter as both are balanced bits( AC coupled).

Q3.
We have to synchronize before every data byte to be transferred ?

---------------------
Regards
Gaurav Sharma

wireless serial projects ask

A1.
Correct, to transmit 1010 you would load 10011001 in the UART transmit register.

If you wanted to send 8 bits, for example 10101111 you would send it as two bytes, the first 10011001 then 10101010, the first 4 bits and compliments then the second 4 bits and compliments.

A2.
You can use 55h or AAh but as soon as you have sync you would have to switch to the encoded data. Remember that the transmitter does not know when the receiver has reached sync. It is better to encode everything, including the sync bytes.

A3.
You only have to sync once per data packet. A packet can be as many bytes as you want. But, if you interrupt the transmission for more than a few mS, the receiver will forget its slice level and you will have to synchronize again.

Sorry for not explaining better - I design things in my thoughts but forget nobody can read my mind

Brian.

betwixt said:

A1.
Correct, to transmit 1010 you would load 10011001 in the UART transmit register.

If you wanted to send 8 bits, for example 10101111 you would send it as two bytes, the first 10011001 then 10101010, the first 4 bits and compliments then the second 4 bits and compliments.

Click to expand...

Is this data 10011001 is AC coupled ? (As there is continuous 0's and 1's which cause DC coupling)

betwixt said:

A2.
You can use 55h or AAh but as soon as you have sync you would have to switch to the encoded data. Remember that the transmitter does not know when the receiver has reached sync. It is better to encode everything, including the sync bytes.

Click to expand...

Means I have to transmit 55 or AAh in data+its compliment form ?

betwixt said:

Sorry for not explaining better - I design things in my thoughts but forget nobody can read my mind

Click to expand...

No problem !! I'll extract it.

--------------------
Regards
Gaurav Sharma

Be careful when you say "AC coupled", you should never AC couple digital signals!

I think you may not be understanding why the encoding is needed so I will try to explain:

Imagine your transmitter sends 433.0 MHz when the digital input is 0 and 433.1MHz when the input is 1. It looks like it is very easy for the receiver to decide what was being sent by just looking at the incoming frequency. Now take a second transmitter, still perfectly within manufacturers tolerance but not tuned to exactly thew same frequency, this one produces 433.1MHz and 433.2MHZ, still the same amount of shift but because of manufacturing tolerances, 0.1MHz away from the first one. The link would show '0' as '1' and probably random noise where a '1' should be.

I have exagerated the frequency shifts, in reality they are much smaller than 0.1MHz which makes the problem even worse.

Look at how the receiver works, it has to decide if a '0' or '1' was sent even though the frequency may not be known exactly, to keep the circuits simple, they are not exactly tuned and do not have enough processing power (if any at all) to be able to measure the frequency. What they do is convert the incoming frequency to a voltage. They start by converting the 433 MHZ down to a much more manageable frequency, maybe 2 or 3MHz, note that down converting the frequency lowers it by does not change the amount it shifts between '0' and '1' states. So if we started with 433.0 and 433.1 we might end with 2.0 and 2.1MHz, note that as a proportion of frequency the shift is now much greater.

Next, this lower frequency is converted to a voltage, for example 2MHz might give 1 volt and 2.1MHz might give 3 volts. This is a simple process achieved in a conventional FM discriminator.

So now we have a voltage shift which is proportional to the data that was transmitted. It looks as simple as just using the voltage as the digital output or using a comparator to decide if it is above or below a certain level.

This is where it all goes wrong!
If you use a comparator you have to decide where the threshold is between the voltage representing '0' and the voltage representing '1'. Remember that different receivers and transmitters may be on slightly different frequencies so they will produce different voltages from the discriminator. Clearly, no single threshold will work, it has to be adjustable for each combination of transmitter and receiver and this would not be practical to do. In reality, the voltage shift between '0' and '1' may only be a few mV whereas the difference from one module to another may be many times that. What is needed is a device which can track the changes in signal, whatever voltage it produces and still be able to see the instantaneous changes which are the data you are looking for.

This is where the "Data Slicer" comes in to play. It is a very simple circuit consisting of a voltage comparator and an averaging circuit. The voltage from the frequency discriminator is split two ways, one directly to the comparator, the other through the averaging circuit and then to the other comparator input. the averaging circuit is normally nothing more than a series resistor and a capacitor to ground, in other words, a low pass filter. By virtue of not being able to see instantaneous changes in voltage, the averaged voltage will tend to be somewhere between the '0' and '1' voltages. If the direct voltage is above the average the comparator outputs a '1', if below it, it outputs a '0'. The output of the comparator is your recovered data. Note that the average will adapt to whatever the voltage is so it tracks different frequencies, overcoming the manufacturing tolerance problem.

Now we can see why the data has to have a balanced number of '0' and '1' bits. Imagine you are the data slicer and a continuous stream of '0' bits arrives, the frequency will be constant and the average will adapt to it. Now any noise in the signal path will be seen as a '1' because it is above the average. Similarly, if a stream of '1' bits arrived, the averaging circuit would adapt to the '1's frequency and any noise would be below average voltage and produce random '0's.

By ensuring there are no gaps in the data, and the distribution of 1 and 0 bits is balanced, the average will be half way between the '0' voltage and '1' voltage and the comparator will accurately detect both zero and one data with optimum accuracy and noise rejection.

So the whole purpose of encoding is to make life easier for the data slicer in the receiver. It has nothing to do with AC coupling, it is just a simple way of pre-conditioning the data to give it best chance of being decoded.

True Manchester encoding uses a different method of ensuring an equal number of 1s and 0s but for exactly the same reason.

I hope that makes sense! - if it does, please explain it to me !

Brian.

Really nice description Brian. You have good knowledge. Hats off!!

Now my interest in this is increased more.

So can you please refer me any ebook regarding this. So that I can read it myself which prevent you to write here long post and may save your time.

Thanks


---------------
Regards
Gaurav Sharma