Problem with wireless serial transmisson

It has been claimed, sending data bits followed by it's complement isn't TRUE manchester code. Why? I think, it's exactly the same.

P.S.:
O.K., reviewing the contributions, I understand, that the difference is in using an UART. In this case, I would like to place an additional comment.

The presented method is almost equivalent to manchester encoding on send, as long as a continuous data stream is emitted by the UART. But it's not fully equivalent on receive, because it misses the ability of synchronizing on a bit level. I don't doubt, that it can work anyway, but the requirements for the receiver bit detector are tighter. If you don't manage to sync on the start bit, the complete packet is lost.

In my opinion, it's rather easy to realize a software deserializer/manchester decoder at the transmission speeds involved with usual SRD systems. It's able to synchronize on a bit level without any compromise.

I'm afraid I do not know of any eBooks that cover this method, I'm self taught, mostly through experimenting although I did go to university for one day!
The morning was to learn 'C' and the afternoon was to learn UNIX, the next day I was told I was a system administrator and I have a certificate to prove it!

Somehow, I managed to install UNIX on a HP9000 server and get it running but to this day I couldn't tell you how I did it.

FvM, the UART system differs from true Manchester mainly in that it uses the start and stop bits from the UART as part of the data stream. In true Manchester coding, the start is found by searching the incoming bit pattern and the data is then sent byte by byte without any framing information. Both systems can lose data sync if bits are lost and although Manchester can re-sync easily, the data is still corrupt and needs sending again.

The main advantage of using the UART is that it removes the strict timing requirements of Manchester decoding. All you do is wait for UART receive interrupts then shuffle the bits around. It can be a background task. I have never seen a microcontroller with a built in Manchester 'UART' so it is normally done with edge detecting software routines. These can use valuable processing time which could be better utilized elsewhere.

Brian.

Is it necessary to rotate data+its compliment received as to extract data.

Cant we simply pick up the whole data+its complement and initiate corresponding event in receiver. For example if I Have to send 0Ah then I have to send 10 01 10 01 or 99H Now in receiver we have to extract 0Ah(by rotating) from 99H...right.

But what I am saying is in receiver we can compare the data received with 99h and if it is matched then stores 0Ah in any register which is data we want, Otherwise resend the data. It prevents any rotating instructions to come into play.

Is it right ?

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

Is it right ?

Click to expand...

Obviously, yes.

How do I receive the data(55h or 0AAh) to synchronize receiver and transmitter. It is bit by bit or complete byte ???

Or If you can please give small programming example.


Thanks


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

Gaurav, yes you can but there is a problem which is more complicated to solve then using shifts.

Don't forget that each byte you send in at the transmitting end comes out as two bytes at the receiver UART. You can use a look-up table to decode the the incoming bytes, there are after all only 16 combinations, but you would only recover 4 bits. You would still have to receive the next byte from the UART, decode it and then merge it with the first byte to get your transmitted data back. You may be better at coding than me but I found the rotate method was easiest, particularly with the PIC architecture.

In my design, I send 20 bytes of 66h as preamble, this is to allow time for the receiver AGC to settle and the data slicer to adapt, then I send one byte of A6h to sync the data stream.

My receive code, which is called every time the UART receives a byte is:


RxPhase is a bit map of the current receive state, it has one bit for preamble detected, one for sync detected and one for data being decoded. The processor is a 16F628A but you should be able to interpret it in Atmelese.

This is only a small part of a much bigger program. In operation there are 32 transmitters, each sending bursts of data for about 10mS and each carries a source identification and several data bytes. There is a delay of about 1.5 seconds between each burst, the actual time is slightly randomized to reduce repeated data collisions.

The units are used for 'life critical' purposes but before anyone points out that 433MHz is prone to interference, all units are within 50 metres of each other and more than 1Km from other sources. That should get you thinking!

Brian.

I am thinking...It is really difficult until and unless I go through some ebook...

May be have to switch to encoder/decoder.


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

Don't give up!

It is really much simpler than you are thinking and the basic principle of digital transmission is worth understanding, you will come across it frequently in electronics problems.

You will see the same encoding schemes used not only in RF transmission but where magnetic recording is used as well, for example in disk drives. In that case, the bits have to be balanced to prevent the heads becoming magnetically polarized. Of course, how disk recordings work is a totally new topic!

I'm afraid I know almost nothing about 'AT' processors although I do have an assembler package here for them. It should be a fairly easy task to write an encoding and decoding routine though. I don't know what languages you program in but you may have to write in assembly language for best results. I use 'C' for anything that requires complex math and assembly language for device that work in mechanical control.

If you want to see lots of assembly routines interacting with each other, take a look at http://www.atv-projects.com/Advanced_ATV_Repeater.html which has several PIC processors and two PLDs working together. Given the chance I think I would now have designed it differently to make it smaller and combined more functions in to more modern processor chips.

Brian.

Thanks for the encouraging Words.

I'll do work on it and make a successful robot..after integrating so many things on it.

Now I am going for 6 months training...so may reply in weekend from home or daily from cybercafe .


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

Good luck with your training!

Remember I am here if you have difficulties in the future, I'm always willing to help.

Brian.

OK!!

Thanks you very much


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

ohhhhhhhhhhhhhhhhhh u ppl hv discussed a lot about this simple topic..

jsut connect TX end of the microcontroller to the RF transmitter "data" pin and at the other end connect the rx input of the other microcontroler to the "data" pin of the reciver..

SIMPLY THEN SEND A SERIAL STREAM OF DATA SAME AS IN RS232 COMMUNICATION as per the required baud rate..

and thts all..!!

i hope this simple but straight forward answer helped..

-- Rony

Oh dear.... I think we have been here before.

Sending without encoding will only work with AM or if the modules already encode and decode the date for transmission.

The modules in question are FM and do not process the data. It isn't a failing of the modules that makes it unreliable, it is basic electronic theory that states you can't decode FSK data if you don't know what frequency you are shifting to and from. The encoding is to allow the frequency half way between '0' and '1' frequencies to be found so the instantaneous frequency can be compared with it. In essence, it allows the receiver to track the transmitter frequency, even if it isn't exactly known.

Ask yourself the question: "If I send a long string of zeroes, and the receiver relayed them correctly, in what way would the RF have to change to make it see a '1'"?

The answer is anything other than the signal seen as being zeroes. It could be below or above frequency or it could be random noise. Without the center reference frequency being known it is impossible to tell if a frequency is above or below it. The encoding is to allow the center to be established by averaging the '0' frequency and '1' frequency. To be sure the average really is mid way between them, there has to be a balanced number of 0s and 1s in the data. That's what the encoding is there to do. The method described earlier and the Manchester method are two ways of achieving this.

Brian.

hi Brian,

I hope this not too late to ask this matter to you trough this forum>
My question is:

this decoding scheme (using uart) is very sensitive(tight tolerance) to the clock accuracy for both pair receiver and transmiter compare with true manchester encoding/decoding ,is it right?

since manchester decoding usually measure the bit length in the start of decoding scheme, and use the value for reference in the decoding process.

it is seems much easier to using uart , but if the transmiter were battery powered (like car remote control), and for cost efficient we use internal RC oscillator instead of crystal oscillator , do you think the uart scheme will still work ?
( i think the rc oscilator is voltage & temperature dependence)

best regard

davids

I would never recommend using an RC oscillator as a timing reference for exactly the reasons you mention. Many micros including the 16F628A I used have built-in oscillators which although not crystal controlled, are laser trimmed for accuracy and are temperature compensated. I have had no trouble at all with these and all my modules are battery powered, in fact they run on CR2032 coil cells.

UARTs are actually quite robust, they normally use majority sampling which gives good resistance against drift. I think the limit for 16F PICs is about 3% before errors occur.

Brian.

dear Brian,

thanks for your candid response,

it's what I mean, internal RC oscilator, ( im using atmel avr series)
the thing that i have to do is to make a trial how much error and chip to chip variation on using internal RC oscilator? since I will do mass production in remote control for motorcycle,
in simplicity in software , i would rather using uart instead of real Manchester , but I'm doubt, there may be chip to chip variation on using it's internal oscillator , and because of battery operated, since rc oscilator may drift while the voltage drop because of battery in used.
as far as I now ( from reading somewhere, the hardware uart can tolerate max 3% of baud rate difference between the pair, because uart synchronization occur only on every start bit ( for 8 bit long) ,
but manchester decoding scheme can accept +-25% baut rate error between pair,

over sampling( majority vote) metode are used in both scheme,

according to your experience, you have no problem with it?
would you advise me, are you doing this for hobby or production ( so it already many chips in used)? this will give me an idea about chip to chip variation

what are the bautrate you are using?


thanks you so much for sharing this experience, it's very helpfull for me
since i have decided which decoding scheme i have used on this project.
at least you have encourage me to do uart model experiment, because yesterday i will let it go because of my doubt

best tregard

davids

I run at an unusual baud rate to make it less likely that other equipment will be decoded by accident although other security measures are taken as well. The speed is in the 17K baud region.

Using PICs I did power tests over a range of 50 metres starting with a 3 Volt supply and left it running until it stopped working. With no errors, it kept working until the batteries reached 2V but the main failure was reduced radio range rather than data errors. When the transmitter was brought closer to the receiver, it started working again. To be fair, the PIC is rated to work down to 2V but the transmitter module was only rated to 2.5V so the failure was as expected.

I don't know how the AVR compares with the PIC regarding internal oscillator stability but I would guess they are similar. Unless you have to keep costs very low, you could consider using a ceramic resonator which is cheaper than a quartz crystal or alternatively, using a higher supply voltage and a low current voltage regulator to keep the supply constant. If you are designing the transmitter and receiver ends, don't forget you can pick your own baud rate so you can use cheaper resonators than the standard microprocessor frequencies. As long as the same speed is used at both ends, the actual rate doesn't matter.

You are right that true Manchester coding is more adaptable because you can measure the frequency during the pre-amble stage and be sure it is correct when the data arrives. Your mileage may vary but I had no problem using the UART in many units.

Brian.

Dear Brian,

thanks a lot for sharing your experience , it's very helpfull

i want to try as soon as I'm home town

may be I have to try to send serial data stream to pc first, and trying it for some chips, of course with uart ,manchester like format '
if it's work for many chips, than I will try it for tranmiter & reciever end

i fill can not wait any longger to go home


best regard

davids

hi brian,

I have try serial transmision using avr2313 with it's internal rc oscilator, it's seems work very well, to pc's rs232

when i want to try further, actualy i still can't understand your discription about preamble and how the reciever do the syncronising scheme,

at a real word the reciever are recieveing spike noises stream all the time until the transmiter emit the serial preamble byte let's say 20byte of 0xA6 byte stream,
and there is unknown time when is the reciever uart start to recieved a valid start bit in each frame,
let's say if because of noise the uart see there is a start bit and after 2 bit time the real preamble stream coming, it would than an framing error, but the uart always recieved <s 8bit st> , which allways 10 bit all, and when the uart starting to search another start bit after that, it seems it will start on the same part of reapeating preamble stream,
so, how is the uart will get the correct frame?
would you pls help me to understand this scheme?

i'm sorry for my bad English


best regard

davids

Added after 51 minutes:

hi Brian,

when ever there is a frame error detection in preamble, do i have to wait 1 bit time than reset the uart?, so every time there is frame error, i will skip 1 bit , than the uart will search another 1 to 0 transition as a new start bit?,
and if there are finally the uart find at least three consecutive preamble byte, than the next different bit is the first data bit? Am I right?

best regard

davids

hi Brian,

learning what you have explain in your prev post,
i found this is intersting to me:

betwixt said:

In my design, I send 20 bytes of 66h as preamble, this is to allow time for the receiver AGC to settle and the data slicer to adapt, then I send one byte of A6h to sync the data stream.

My receive code, which is called every time the UART receives a byte is:

Code:

;PrePhase condition. Three bytes of 0x66 should be received consecutively from
;the preamble data before assuming it is safe to move to SyncPhase. Byte in error
;will be 0x69 or 0x99 so if these are found, reset the USART and try again.
RxFraming
    sublw   0x66                ;set Z flag if correct phase
...............
...........

Brian.[/quote]


to reset the uart is very fast  only a few machine cycle, it's to fast compare with the bit time (let's say at 9,6Kb), so if i don't put extra delay on it, i believe that after uart reset rutine, the uart find the new start bit right after an error byte (0x69 or 0x99) and than the uart will recieved the same error byte as previous byte

do i have add some delay (1 bit time) before reseting the uart?

sorry i submmited many post, while I'm learning and thinking , :D

best regard

davids

Click to expand...