Questions about UART communication

[max_torch]

I have a few questions about what I have observed using UART to communicate between two microcontrollers in the lab a few hours ago.
For those who dont know, UART is a form of serial communication and that is asynchronous.

1.) When the whole thing was powered by a single power supply and data was being transferred from one microcontroller to the other via UART through a single copper wire the data was properly received (indicated by a bunch of LEDs). When I supplied each microcontroller with its own power and ground with the only thing connecting the two was the wire for the UART transmission data was no longer being properly received. Is this something that you would naturally expect to happen? So is there really a rule that a wired communication between the two would only work if they shared the same ground?

2.) I have a half duplex FSK data transceiver operating at 433MHz that can handle UART transmission. If I used this for the data transmission to replace the physical cable, would I then be able to separate the ground and power of the two sides?

3.) According to the website I bought the transceiver from, it has a transmit to receive latency of 20-30 ms. Also it operates at 9600 bps. Naturally I have set my microcontroller's UART peripheral to shift out bits at 9600bps. But what about the 20-30 ms, do I also have to consider it in my code?

 

[dorke]

1.The receiving end gets the voltage between the wire and it's own ground,
if both grounds are not related the voltage "seen" by the receiver is obviously not correct.
to fix that you need to run 2 wires(signal+gnd),that will only work for very short distances.
2. Yes,the FSK receiver will create a voltage related to the receiver ground (needs to be connected)
3.Yes, you need to wait for the last received data(i.e you need to have a protocol) before you can reverse the transmit/receive roll (Half Duplex).

 

[Harald Kapp]

UOTE="max_torch, post: 1673716, member: 34345"]with the only thing connecting the two was the wire for the UART transmission data was no longer being properly received[/QUOTE]
You need to connect the two grounds, even if you use separate supplies. The current from the driver (TxD) enters the receiver (RxD) and needs to return to the source. This is not specific to communication but a basic law of electricity.

2.) I have a half duplex FSK data transceiver operating at 433MHz that can handle UART transmission. If I used this for the data transmission to replace the physical cable, would I then be able to separate the ground and power of the two sides?

Practically speaking yes. This is how e.g. a transistor radio operates - you don't want to have a mile long wire to return to the sender.
However, strictly speaking you have an energy flow from the sender to the receiver and you need a return path, otherwise the energy would accumulate on the receiving end. The return path when using radio transmission is generally earth, even if only loosely coupled via the unavoidable capacitances present everywhere. Times ago radios used to have a separate earth connection to improve this return path for better reception.

But what about the 20-30 ms, do I also have to consider it in my code?

That depends on what you intend to do with the data. Latency means that the data will be sent out (or arrive) with a delay of 20-30 ms after the UART on the sending side has started transmission, but the data still arrrives at 9600 bd on the receiving end - only delayed. There's no way around this except using another transmitter/receiver combination with less delay. If your data is time criticalm you may add a timestamp to each packet of data that tells the receiver the exact time the data was sent by the transmitter. This way the receiver can reconstruct a faithfull timing sequence even with varying delays. The time stamp is simply another few bytes of data encoding the time on the sender's side and accompanying the real data as part of the byte stream.

 

[GPG]

What UART? Transmission mode? ie FSK, RSxxx TTL?

 

[Minder]

If this is standard RS232 then the common on TX & RX is connected.
Only if the communication is differential is the commons not connected.
M.

 

[max_torch]

If this is standard RS232 then the common on TX & RX is connected.
Only if the communication is differential is the commons not connected.
M.

The datasheet doesnt say what standard it is.
Datasheet says its also called SCI or serial communications interface
Structure is just [start bit + 8 data bits + stop bit]
This uart is just using the built in peripheral inside the microcontroller.
I don't think im following any RS protocol, im just transferring data between microcontrollers. Im not putting it through any line drivers.
The exact implementation inside the microcontroller is through the use of shift registers and FIFOs.
It says in datasheet that there are only two voltage levels it outputs from the pins.
I hope that clarifies some things.

I dont know what differential communication is, but i know what differential manchester is. In diff comm, you dont need commons connected because it is not monitoring what the actual voltage levels are but rather only if it falls or rises, correct?

 

[dorke]

Max,
It was clear from the beginning you connecedt 2 μC (most likely on 2 different boards) with Uarts, in a very short distance (same table?).
As I said above (#2 reply),
you need to connect the grounds of the 2 boards for it to work
(and preferably run at the same voltage value).

In differential comm. there are 2 wires related to each other(i.e floating) that the receiver (differential as well) is getting.
That is much better than what you have right now (not floating) ,

But,
with the 433Mhz RF Tr/Rc you don't have the problem.

 

[Minder]

Differential is using two lines that are 180° apart so each logic common is not, or need not, be connected.
I have used the UART in Picmicro but usually RS232 TX/RX.
M.

 

[Harald Kapp]

so each logic common is not, or need not, be connected

This is a common misconception. It will, surprisingly, work in quite some configurations, but it is not reliable. Even with dfferential signalling a common return is advisable. Differential signalling increases signal to noise ration by effectively doubling th esignal amplitude and it makes the communication much less sensitive to common mode noise, both factors are typically not relevant for short distance communication between two µCs.

What UART? Transmission mode? ie FSK, RSxxx TTL?

Presumably TTL for short distances. FSK would require a modem, RSxxx would require the correspondent transceivers. I don't know the op's setup, but I doubt he has been using anything but plain TTL.

 

[Minder]

This is a common misconception. It will, surprisingly, work in quite some configurations, but it is not reliable

It is not a practice I adhere to, I usually use a common, I was just quoting the instructions with many devices and systems come with.
M.

 

[max_torch]

Thanks guys. Actually only now am i going to try that fsk transceiver i mentioned in the op. ill say here later if it worked well or not.

 

[GPG]

How about some links to the devices you are using?

 

[max_torch]

How about some links to the devices you are using?

This is the FSK transceiver - http://www.e-gizmo.com/KIT/UHFII.htm
The microcontrollers im using are PIC16F877A and PIC16F628A.


Remember in the OP that I got the transmission via wire and common to work properly..
Well I finally got the wireless UART transmission over the two FSK transceivers to work 95%...

Any value of data I send works... except if I try to slowly one by one toggle each bit of the data to low, whichever was the last bit remaining, when I toggle it off the receiver still shows it as high (I am transferring the value of the data to an output PORT so that I can see it on LEDs). If I toggle to high a different bit, the previous bit (that didn't go to low when it should have) goes low and the newly toggled bit goes high. So I can move around this single high bit in this fashion. But I can never turn it all off. Other than that it works totally fine for values where more than one bit is high.

Also note that the moment I change the data transmission medium back to the wire, without turning off the setup, it starts to work properly.

Also if initially what is being sent over the wireless is zero, all the outputs are indeed off, but the moment I send data with even just one of the bits high I can't get it to show zero again and turn everything off.

Any idea what I should check? What's wrong? Perhaps there is a parameter I overlooked? Or perhaps I have to do some kind of workaround... I would highly appreciate all feedback

 

[GPG]

rar file

 

[max_torch]

rar file

Also just now I tried putting 0.1 second delay between transmissions but still same result

 

[dorke]

Max,
how many total switches do you activate?
.
The Uart is transmitting 8 bits a time .
When you say the "last bit" what do you mean exactly

 

[max_torch]

There are eight switches each assigned for bit 0 to bit 7 of the data to be sent.
When I say the "last bit" what I mean is the only bit that's still high, the last remaining to be toggled low before the data becomes b'00000000', regardless of its position in the data.
I am transmitting over UART the state of the switches.
Say I did this:
Say I turn on the setup and all the switches (S0 - S7) at the transmitter are open, which means all the LEDs (L0 - L7) at the receiver are off. Then I close S0. L0 will turn on. Then I close S5. L5 will turn on. Then I close S6. L6 will turn on. Then I open S5. L5 will turn off. Then I open S0. L0 will turn off. Then I open S6. L6 DOES NOT turn off even though it should, it remains on. Then I close S6 then open it again. L6 just remains on. Then I open S6 then close S7. L6 will turn off and L7 will turn on. And I can do this again, I can open S7 then close S4. L7 will not turn off when I open S7 but it will turn off when L4 goes on when the moment I close S4.
The problem is that it does not let me go back to the b'00000000' state ever again. It lets me output any other binary combination (of the switches) from hex 01 to hex FF but not 00. It's like I'm left with only 255 out of the 256 discrete states I should have with 8 bits...

I find it extremely odd because the moment I change the medium of the data transfer to a wire and disconnect the transceiver without even removing power from the setup and repeat the previous actions the behavior of the output is perfectly fine.. I can go back to b'00000000' where all the LEDs go off when I toggle open all the switches. Therefore I am at a loss to diagnose this... I don't want to give up though.

 

[dorke]

It is strange as you describe it.
It sounds like with the FSK the receiving side dose not get the b'00000000' data.

To check this do this:

1. At the receiver start on power-up with all LEDs set to "on"
b'11111111' (both the LEDS and a variable if you use one).
2. Now send from the transmitter b'00000000', what do you get?
LEDs and variable

 

[max_torch]

Okay ill try that after sleepng its 1am local

 

[max_torch]

It is strange as you describe it.
It sounds like with the FSK the receiving side dose not get the b'00000000' data.

To check this do this:

1.At the receiver start on power-up with all LEDs set to "on"
b'11111111' (both the LEDS and a variable if you use one).
2.Now send from the transmitter b'00000000',what do you get?
LEDs and variable

Okay I have done what you said.
When I send the b'00000000' all the LEDs still remain b'11111111'.
I also tried setting the LEDs and variable to b'10101010' then suddenly sending to the receiver b'00000000' and it still just remained b'10101010'. It only changes if i send a value other than b'00000000'.

I also discovered another pressing problem. The FSK transceiver module I bought (datasheet included in previous post) says that it has a range of up to 500m yet at half a meter my receiver stops getting the signal from the transmitter, what could be the reason for this?