Sending large data over serial wirelessly or wired is a nightmare

[mik3ca]

I don't get it.

In the past, I had it where in my project I send out 7 bytes of data from my computer to my circuit at 38 Kbps over a radio link. Then my circuit sends a response (also 7 bytes of data) using the same radio module and link and speed. Sometimes I send out the same data twice (no more) for the remote to receive it.

Now I'm trying the same thing again but this time with 16 bytes because my application demands much more data to be transferred in a shorter period of time, however the reliability is significantly worse.

After experimentation, it seems that one byte is always missing from the 16 bytes I send, and I'm not sure if its because my computer is acting funny or if the radio link itself is the problem.

As for the device I'm sending data to, I ran the code in a simulator to verify that the same 16-byte packet I'm sending out is recognized as valid by the device.

This is where things get crazier. In the past I did a simple serial connection test by hooking up two PC's together (yes processor is at least 1Ghz) with a serial port and ran terminals on both and configured both to run at the exact same speed, and characters were also lost in the terminal as well.

If I recall, I think the PC chokes the serial operations after sending or receiving 14 bytes because its internal buffer is full and not flushed? and If I recall, the device I'm dealing with (yes an 8051) has a 1-byte buffer. so I'm not sure if this could be the reason why data isn't being sent properly?

Anyone have any ideas how I can solve this?

 

[Pommie]

How many times do people have to tell you that you can't use rs232 over radio, you need manchester encoding.

Mike.

 

[mik3ca]

This is different. I'm talking any data here. Let's picture the old-fashioned internet. I'm using HM-TRP radio modules specifically designed to transmit and receive uart data wirelessly.

 

[Pommie]

Those modules use ttl level rs232. Do you have a max232 on each end?

Mike.

 

[mik3ca]

Hmm.. I'm gonna do the max232 at the PC end for sure because I did test with a cheap max232 equivalent circuit of transistors and resistors and a capacitor and diode, but I think I read somewhere that sending a lot of 0's or 1's (which I did) will cause invalid characters to go down the line.

At the end with the microcontroller, everything is 5V so I don't think a max232 will be needed there.

 

[Pommie]

You'll need a MAX232 on the PC end but not on the μC end. Try just reading the uart on the μC and sending it straight back. Once you get an echo working from Pc to μC then start to introduce a fifo or other kind of buffer on the μC end. A good test would use a 64 byte buffer then only transmits back when crlf is received. Write a 50 character sentence on the PC, press return and see if it comes back.

Mike.

 

[rjenkinsgb]

you need manchester encoding

... Or send each character true then inverse, to cancel any DC offsets..

 

[OlPhart]

IBM solved the DC neutral issue decades ago = NRZI.
See if your UART / SIO supports it.

Also, recent RF modules (<5 YO) can pass 128+ KBPS.

 

[popper]

PC shouldn't be the problem and buffer size can be increased. RS232 needs time between packets to resolve stop bit. RF modulation PSK or FSK?