Sincronising in comunication

[Thunderchild]

I am just starting to get interested in PIC as i see that they can do as much and more that a very complex digital circuit. i have always had a common problem though that is in asyncronos communication. say i created a remote control system for example a remote control for a model airplane. i send digital information to the plane to tell it what to do with the various aparatus like flaps, rudder and throttle. i have no way of telling the receiving PIC how to reconise the signal like for example when it starts. i think maybe a "handshaking protocol" would be required but then what about syncronisation. the clocks of the transmitter and receiver are seperate so the signals can be out of phase and sometimes information lost. now i cannot rephase the two clocks as we are taliking about miroseconds. so i need an idea how do these systems work ?

 

[Nigel Goodwin]

I am just starting to get interested in PIC as i see that they can do as much and more that a very complex digital circuit. i have always had a common problem though that is in asyncronos communication. say i created a remote control system for example a remote control for a model airplane. i send digital information to the plane to tell it what to do with the various aparatus like flaps, rudder and throttle. i have no way of telling the receiving PIC how to reconise the signal like for example when it starts. i think maybe a "handshaking protocol" would be required but then what about syncronisation. the clocks of the transmitter and receiver are seperate so the signals can be out of phase and sometimes information lost. now i cannot rephase the two clocks as we are taliking about miroseconds. so i need an idea how do these systems work ?

Any asyncronous protocol requires a 'start signal', to signify the start of data - check my RS232 and IR tutorials for two different ways of doing it!.

 

[Thunderchild]

ok so thats my first q answered but thats not too much of a problem what is is this:
say i have two pics as described before, they are both running away on their indipendant clock signals. the transmitter's clock pulse starts just as the receivers one is ending so there is like a coincidence of perhaps 5 % where both clocks are active and a risk of loosing the information. the receiver may or may not pick this up or worse sometimes will and sometimes won't. but in the mean time they are both ticking away and it's not like i can say ok i'll turn them on both in the same instant as we are talking about like 1 us. this is my main concern so how do i address it transmit the clock signal as well ?

 

[Nigel Goodwin]

ok so thats my first q answered but thats not too much of a problem what is is this:
say i have two pics as described before, they are both running away on their indipendant clock signals. the transmitter's clock pulse starts just as the receivers one is ending so there is like a coincidence of perhaps 5 % where both clocks are active and a risk of loosing the information. the receiver may or may not pick this up or worse sometimes will and sometimes won't. but in the mean time they are both ticking away and it's not like i can say ok i'll turn them on both in the same instant as we are talking about like 1 us. this is my main concern so how do i address it transmit the clock signal as well ?

You appear to be rather confused about asyncronous serial comms?, try reading my RS232 tutorial which explains how it works at .

 

[mstechca]

Treat it like a keyboard interface.

What you will need to transmit is a clock pulse, and at the same time, data.

Have a certain code start the data stream, and a certain code to stop the data stream. The code consists of a fixed (any number) amount of data bits coming from the transmitter.

Since the clock pulse is constant, The clock is synchronizing the data. This method requires transmitting data on two frequencies at the same time.

The only other way to so it without sending a clock signal at the same time is to set both internal clocks (in both units) at the same frequency, and have both clocks start at the same time.This can be hard to do.

 

[Thunderchild]

that was my point. i thought perhaps a certain code can be used to start the clock of the receiver so that is in sync but i am not sure would this instantly start making it realy in sync or would i be back to square one. well i'll go look at the RS232 to start with.
thanks Nigel

 

[Nigel Goodwin]

that was my point. i thought perhaps a certain code can be used to start the clock of the receiver so that is in sync but i am not sure would this instantly start making it realy in sync or would i be back to square one. well i'll go look at the RS232 to start with.
thanks Nigel

You don't use syncronous comms over a wireless link, it would be extremely silly!.

RS232 asyncronous comms is VERY, VERY easy to do, and easy to understand, easier than syncronous comms really.

I'll try for a third time - READ MY TUTORIAL - it explains how it works, and even have diagrams!.

However, if you're doing it via radio, you need to take special precautions, because radio links are normally NOT DC coupled, this can cause problems with RS232 type comms!. To overcome this, usually Manchester coding (or similar) is used, which removes any DC problems from the link. You can buy radio modules with this in-built, and it will make life MUCH easier for you.

 

[Thunderchild]

yes i understnd i am reading the RS232 tutorial but am mainly interested in the wireless method and as you say RS232 is no good there.
i think i may have misworded my initial question. what i suppose i should have said is how do i syncronise two different clocks without actually sending another signal or is this the only method ? i find this of interest also in wired comunications to allow comunications with just two wires and a minimum transceiving circuitry that would otherwise have to code/decode the clock as well from the received signal

 

[Thunderchild]

ok i've read it. now one question. u mention 4MHz in your example. is this the speed of the pic or the speed the in/outputs are being "sampled
" at ? if i get this straight the varrious signals work on smaller time units than the actual data meaning that it is easier to catch bits else another attemped is made at sending as the bit is 104 us long and the pic can work with like 10 us it can delay to the oportune moment so that as i call it the signals are syncronised or are enough for stable comunication

 

[Nigel Goodwin]

ok i've read it. now one question. u mention 4MHz in your example. is this the speed of the pic or the speed the in/outputs are being "sampled
" at ? if i get this straight the varrious signals work on smaller time units than the actual data meaning that it is easier to catch bits else another attemped is made at sending as the bit is 104 us long and the pic can work with like 10 us it can delay to the oportune moment so that as i call it the signals are syncronised or are enough for stable comunication

Yes, the PIC uses a 4MHz clock, there's no other 'clock' involved with asyncronuous comms.

It's very simple to understand.

1) Wait for a start bit.

2) Delay half the bit time (52uS at 9600baud), so you're now in the centre of the bit, check to confirm you're still in the bit!.

3) Delay one full bit time (104uS at 9600baud), and read the bit (high or low).

4) repeat 3) seven more times for the rest of the bits.

Although there's no way the receiver will be running exactly at the same speed as the transmitter, it doesn't matter, you syncronise to the start bit on every byte - so it's only got to be near enough to hit each bit (with 104uS to aim for), for 9 bits - then it gets re-syncronised for the next byte.

You don't need any 'clock' signal, because both ends of the link know what their speed is supposed to be - if it's a syncronous serial link, then the clock speed is unknown, and irrelevent - and can change as it likes, even within the same byte.

 

[Thunderchild]

hm think i've got it. but in the event of a missed reception what happens then is a delay of say 20-50 us made to try and get syncronised ? like the receiver sends and aknowledge else the transmission is repeated ?

 

[Oznog]

Say, this is a dumb question but I never figured it out- given a stream of serial bytes and the receiver powers up in the middle of it, how does it pick out a START bit from all the 1's and 0's in the data?

 

[Electrix]

Could someone clarify as to when does the RCIF Flag Bit Set in the PIR1 register. I tried shutting off my receiver and I notice that even then the RCIF gets set and the receiver assumes zero (?) i/p inside the RCREG. How can I control this setting of the RCIF

 

[Electrix]

And does the reception (filling up of RCREG) begin as soon as the RCEN bit in the RCSTA Reg. is set ?

 

[Nigel Goodwin]

Say, this is a dumb question but I never figured it out- given a stream of serial bytes and the receiver powers up in the middle of it, how does it pick out a START bit from all the 1's and 0's in the data?

It doesn't! - it won't syncronise correctly until it hits a long enough period without any data, THEN it can correctly identify a start bit.

Syncronous is no different!.

Unless you have some form of handshaking, which is impossible with a one way radio link, you need to add some form of error detection, and if possible, correction!.

 

[Thunderchild]

yes in the radio case two transceivers are needed. the only other way is for the receiver to continiously repeat the transmission with a 10 us delay longer each time intil a whole cycle is covered in this way it is certain that the message arrives. this would be bandwidth wastefull (for the transmitter and the PIC) but would save two transceivers and just use a TX and RX

 

[Oznog]

Well look at your task. You wouldn't send a signal with just the change in control settings. Even if you had something with an up/down button on the controller you would want the controller to be responsible for determining the absolute value/state of that register and keep sending that value whether it's changed or not. Any invalid pkt which can be detected should just be ignored until the next valid pkt.

Of course, being an aircraft you want to accomodate the situation where you lose signal for a second, possibly in a radical maneuver which are somewhat more likely to cause it. It may not be ideal to retain the last control settings received for a prolonged period but rather return to some settings which would be the best guess for neutral flight until the link is restored. Yet you would not want to do this with just a single pkt lost.

You've got the channel and no one else can use it, so there's no sense of "bandwidth hogging".

 

[Oznog]

It doesn't! - it won't syncronise correctly until it hits a long enough period without any data, THEN it can correctly identify a start bit.

Those gaps aren't required anywhere by the protocol, are they?
If someone uses a PIC for example and made it so the UART transmitter gets a new byte immediately after the last byte, can a receiver which did not start with the data correctly framed ever recover?

What causes a framing error? I guess not receiving a Stop bit at the expected time would do it. Are there visible irregularities in the Start bit too? Any 0->1->0 transition could potentially be a Start bit, right? The timing might be irregular, but I guess that may be up to the specific receiver hardware implementation to figure out if it is an error or not?

 

[Nigel Goodwin]

It doesn't! - it won't syncronise correctly until it hits a long enough period without any data, THEN it can correctly identify a start bit.

Those gaps aren't required anywhere by the protocol, are they?
If someone uses a PIC for example and made it so the UART transmitter gets a new byte immediately after the last byte, can a receiver which did not start with the data correctly framed ever recover?

You need to bear in mind that RS232 is designed to be a cabled connection, so (hopefully!) you won't be losing bits, as you would via a radio connection.

If the link is out of sync, and it sends permanent continuous data, I don't see any way it could ever guarantee to get back in sync?.

Again though, RS232 is a 'cabled' system, and should have a return path, so it can request the data be resent if it's faulty. This, by definition, means that the transmitted data isn't continuous. Even when downloading a file, it's usually done in 'packets', where a collection of bytes is sent as a packet, and it then awaits confirmation from the receiver - this system is used by radio amateurs as well, and it's called 'packet radio'.

What causes a framing error? I guess not receiving a Stop bit at the expected time would do it. Are there visible irregularities in the Start bit too? Any 0->1->0 transition could potentially be a Start bit, right? The timing might be irregular, but I guess that may be up to the specific receiver hardware implementation to figure out if it is an error or not?

Yes, but once it's found an error, if the data stream is continuous, the chances of finding a correct start bit are fairly low - obviously depending on the exact composition of the bits in the data stream. And it's go no way of knowing that the data is correct or not, if you happen to come across a particular sequence of data bytes it could quite easily syncronise part way through, so get completely the wrong data.

 

[Nigel Goodwin]

Of course, being an aircraft you want to accomodate the situation where you lose signal for a second, possibly in a radical maneuver which are somewhat more likely to cause it. It may not be ideal to retain the last control settings received for a prolonged period but rather return to some settings which would be the best guess for neutral flight until the link is restored. Yet you would not want to do this with just a single pkt lost.

I hadn't notice this was for an aircraft?.

Have you considered the legal implications?, as far as I'm aware you require a specific type of equipment, on a specific frequency band, for aircraft remote control - obviously country dependent, but the UK is very strict over this (for obvious safety reasons).

But as far as the actual control goes (ignoring legal questions), the amount of data required is fairly small. Have you considered how a normal radio control system functions?, you could even duplicate that quite simply - it just sends varying width pulses.

Or if you want a proper digital system, send the data in packets (which again is similar to how normal radio control works). For example, you could send a four byte packet, rudder, throttle, ailerons, flaps, THEN a largish gap (to allow syncronisation). You then repeatedly send the same information - if your controls change, then the data changes, but regardless the transmitter sends the four bytes, followed by a gap, continually.

You might also send a fifth 'checksum' byte for error correction, this can be checked at the receiver, and the data rejected if incorrect - you could implement a scheme where if a certain number of errors occur in a row (say ten?) the aircraft enters a 'safety mode', throttle down and controls set for a slow circle and descent. The same should happen if the signal is lost completely - if you miss a certain number of packets in a row completely, again enter 'safety mode'.