Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Ensuring Wireless Serial Communication

Status
Not open for further replies.

Jay_

Member level 3
Joined
Aug 23, 2010
Messages
56
Helped
1
Reputation
2
Reaction score
2
Trophy points
1,288
Activity points
1,779
Hi,

How do we ensure that when we are communicating serially, we don't lose any of the data (say the start bit) in between? And if we do, by what means does the receiver actually 'know' this has happened?

Let's assume I have an asynchronous communication and I am sending some data:

Data : 3DE2 (Hex)
Start sequence : ASCII '@' (viz. Hex 40)
End sequence : ASCII '%' (viz. Hex 25)

So I would code to send :

0x403DE225. But what happens if one bit is lost in the transmission? So the receiver wouldn't know it got a end sequence and it would count the next part as continuing data. What if one bit of the data was lost?

By what logic is the receiver supposed to be coded so that it recognizes these errors? I recently worked with Arduino sending data through XBees and encountered these problems.
 

  1. UARTS are supposed to have 16 byte buffers to prevent framing errors when handshaking is used.
  2. Handshaking can be hardware controlled with 5 wire ports by RTS CTS or software controlled with 3 wire ports with Xon Xoff
  3. When no handshaking is used if you are too slow in reading data, an overflow can cause a FRAMING ERROR in the status register.
  4. MISSING BITS do not occur, but corrupt bits can occur if the start bit is too short or EMI interferes with the data.
  5. Adding ODD parity bit provides a level of redundancy to check for single bit errors.
  6. If you are missing only 1 bit , that would be strange and would depend if it is chopped off at the beginning or middle or end, perhaps due to coding error of not waiting for byte to be sent before loading next.
  7. UARTS may be setup to be polled or an IRQ when data is in the buffer to be read for more efficient code.
  8. Some CPU UARTS support FIFO control for Empty, Full and Almost Empty, Almost Full, but simple ones are 1 BYTE only or just Full or Empty.
  9. Some CPU's suport DMA for transfer of high speed data from UART to RAM
  10. Using all of the above makes communication more robust with some variations from standard implementation.
 

So in the case of my above data, imagine you had to send this from one wireless transceiver to another wireless transceiver. How would you send the data?

How can you be sure that a missing bit wouldn't occur?
 

So in the case of my above data, imagine you had to send this from one wireless transceiver to another wireless transceiver. How would you send the data?

How can you be sure that a missing bit wouldn't occur?

In a wireless data channel, one bit may miss due to two reasons:
1. poor signal-to-noise-ratio Make sure it is higher than 16-20 dB all the time
2. Interference by multipath : make sure there is no multipath, use directional antennas and line-of-view-propagation between antennas.

- - - Updated - - -

I did not mention other type of interference like from other wireless sources. Then no above provisions would work and your communication cannot continue. You will have to redesign the system including channel frequency, and more
 

I guess the best way is to ensure that the data reaches by sufficient power to the signal and the design of the antenna then?
 

This is the basic rule in a system design, to achieve a high S/N ratio. But the interference should be considered, too.
 

Recently, I used Arduino along with XBee and the temperature sensor MLX90614 to wirelessly send temperature data to my laptop being read in the COM port. The data seemed to read fine when the set up was in room temperature and not moving. But under other circumstances, it became a problem getting the sampled data.

In hindsight, MLX90614 was probably not the best sensor for this use - a contact sensor could have given me more accurate data, and I could have used XBees with a higher power.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top