SMiRF / MAX232, 50% Data Loss

Wireless & IoT
1

I’m trying to use a SMiRF with a MAX232 to transmit serial data across a short distance. Unfortunately, I’m running into quite a bit of data loss in the process, easily over 50%.

The data coming into this configuration from the remote end is standard RS-232. I’m translating the RS-232 logic levels into TTL with the MAX232, which then feeds the data over to the SMiRF’s remote end. This data is GPS information, so there are four one-line sentences transmitted every second at 9600.

I’ve used close to the same configuration, minus the SMiRF, to test the system out and rule out other problems–it works fine (without the SMiRF). I connected my GPS receiver (RS-232 output) to a MAX232, that MAX232 was connected to another MAX232, which was in turn translating to RS-232 for direct connection to a PC serial port. Using this setup, the information was transmitted through the system with no obvious data loss.

I added the SMiRF to the configuration (replacing one of the MAX232’s, of course) and I get tons of data loss (close to 50%).

I’ve tried changing channels (and unplugging my 802.11b WAP, of course), adjusting output power, etc, with no help.

Any ideas? I’ll try to post transmitted vs. received data soon, but am not sure when I’ll be able to. Trust me though–it’s not a bit-shifting problem. There are entire sentences of data missing at times, or chunks of data missing within a sentence.

Thanks in advance,

Pete

2

nixdorf:
I’m trying to use a SMiRF with a MAX232 to transmit serial data across a short distance. Unfortunately, I’m running into quite a bit of data loss in the process, easily over 50%.

Minor update: swapped the MAX232 out with a MAX232A and am getting the same result. The MAX232A offers a higher data rate. Didn’t think it’d make much of a difference, but figured I’d try anyway.

Pete

3

you will always get dataloss due to backgound noise. But usually the smirf units will send till they get a ack from the tx.

SO, i would guess you are sending data too fast, what data loss do you get with a simple hyperterminal to hypertermial through smirf?

If 100% getting through then perhaps try using a PIC or something to strip the GPS output into a smaller packet and send that, or send less data.

You dont mention how many packets per second you are expecting to send…

4

pittuck:
you will always get dataloss due to backgound noise. But usually the smirf units will send till they get a ack from the tx.

I’ve attempted various things to rule out background noise, including shortening the distance between the two units to inches while increasing the output power. Doing this made no difference (good or bad) to the problem.

pittuck:
SO, i would guess you are sending data too fast, what data loss do you get with a simple hyperterminal to hypertermial through smirf?

That was an idea I had, too. I get great data transmission when sending text slowly through the SMiRF (i.e. pressing and holding a key), but get lousy transmission when using copy/paste to send a sentence (as in english sentence, copied from any old web site) through the link. If using copy/paste, I usually get the first part of the sentence with no loss, then a few words cut from the mid section of the sentence, then the tail end with no problems. Maybe I’m filling a buffer?

pittuck:
If 100% getting through then perhaps try using a PIC or something to strip the GPS output into a smaller packet and send that, or send less data.

You dont mention how many packets per second you are expecting to send…

I hadn’t thought of the PIC, but had thought of how I could force the GPS receiver to cut-down on the transmitted sentences I’m not worried about, and focus on sending the items I am interested in.

To be honest with you, I’m not certain what you mean by packets (when I hear that, I think of TCP/IP style packets) or how to determine how many packets I’m sending.

The GPS receiver sends 4-5 sentences, with 3 at around 30-40 characters and 1-2 at close to 80 characters. The fifth sentence (80 char wide) is only transmitted once per minute. The 4 other sentences (3 at 30-40 char, 1 at 80 char) are transmitted once every second at 9600 with very little delay. There is far more delay after the last sentence and before the first than during any other time (in english, it spits out all the sentences it has, then waits, spits them out, waits, etc).

I’ll look through the configuration for the GPS receiver, but I don’t think I’d be able to cut down on the amount of data. How would I go about doing the same thing with a PIC? Any ideas?

Thanks!

Pete

5

well, erm.

If you are using smirf v2 then i would have thought it would be able to handle the data input @ 9600

what happens is the smirf will collect and send only a small number of bytes (8 for instance) it will then send these and make sure that no data is lost. Then it will send the next batch.

What i think is happening is that too much data is being sent, and perhaps you have a large amount of background RF (power lines, mobile phone masts, mobile phones, microwaves, solar flares etc. etc. etc.). Together these could cause problems and so the internal buffer would get full then it would float with allowing data in and being too full.

This is conjecture as i do now know the smirf firmware too well. But SPARKY should know :wink: calling sparky!

6

Right right - it’s been a hell of a week…

The SMiRF v2 can handle up to 80 characters before the buffers over run. With a length of ~300 characters with your GPS data, you are getting corrupted data. 3ft is about the same as 30ft when it comes to RF. Closer doesn’t always mean better. I would recommend parsing your GPS data with and intermediary PIC and clipping off all the data you don’t need.

-Nathan

7

ok,

or taking less samples if possible, i am not sure how they work but i would guess you initiate the data transfer? in which case initiate is 1/3 as many times and budading u with have pretty much the same result as before…

8

Fixed the problem.

The GPS receiver I’m using allows you to enable/disable the sentences. I shut off all but two that I need, and am getting no errors. In fact, errors don’t creep in until I get around 200 ft from the base, and even then it’s only one error (usually just an obviously wrong character) every now and then.

Thanks for the help.

9

That’s what we like to hear.

What was the length of your final transmission sentence?

-Nathan

10

sparky:
What was the length of your final transmission sentence?

The final (maximum) length is 155 characters.

11

We have finished up a new revision of the SMiRF firmware (v2.5) that will allow much higher datarates and throughputs. More info soon.

-Nathan