SparkFun Forums 

Where electronics enthusiasts find answers.

Have questions about a SparkFun product or board? This is the place to be.
By fll-freak
#132350
I have a problem that is now officially driving me nuts. For several years I have been working on building a lightning detector to shutdown my computer network during a storm when I am away from home. I learned a lot and have a pretty neat system. A few days ago, I went to solve what I figured was going to be a simple logic problem in the micro that runs the detector. The micro is an MSP430F2012. It does not have a UART, so I have been bit banging the output using TimerA. On my scope the timing for the serial train is dead nuts at 9600 baud. The level conversion from 3.3V is being done by either of the following Sparkfun products:
http://www.sparkfun.com/products/133
http://www.sparkfun.com/products/449

When I connect my detector to a laptop with a USB to RS-232 adapter without any extra cabling, the detector works fine. A Python program on the PC logs all the bytes sent and they all match what they should be.

If I add in 30 feet of cable it still works fine.

If I connect it to a much faster desktop PC running Fedora Core 12, running the same Python program using the exact same (30') cabling, most 0x05 bytes get logged as 0x00. Many other bytes seem to get logged just fine. The results are the same if I use the USB-RS232 converter or a native RS-232 port on the PC.

So what was going to be a simple fix has turned into a three day marathon of making cables, moving computer, and a gazillion other tests. I am now at a loss.

At first I figured that the cabling I had to the desktop must have been poor or running past an EMI source. I have discounted that by using the same cables in the same path.

I figured that the baud rate was off a bit and would work on one machine but not the other. But this seems very unlikely as the same USB-RS232 converter (that would be sensitive to a baud rate problem) on different machines behaves differently. The problem is following the Linux PC not the Windows laptop.

I also figured that perhaps the Sparkfun level converters did not have enough drive for a long-ish cable. But the system works with the same 30 feet on the laptop.

So I am down the a problem on the Linux box. A quick search on the web for RS-232 issues on Linux Fedora Core 12 has drawn a blank. This same box drives a DVD burning robot over RS-232 at the same baud rate and I have never had a hipcup from it.

Edit: Tried a third computer (desktop Windows with same converter as the other computers) and it demonstrated the 0x5 bytes converted to 0x00. So what is magical about my old beater laptop? What is magical about 0x05 other than alternating bits? Tomorrow I will bring home an RS-232 serial protocol analyzer that may shed some light on this. I had hoped to solve this tonight as tomorrow we are due for a line of thunderstorms I could have finalized my testing on.

Any ideas for further tests?
By esklar81
#132357
Skye,

For you, old friend, I'll fire up the "Hell, might as well try changing anything. If the performance improves or worsens, you'll learn something" test generator.

How about:
  1. trying different data rates, preferably not just multiples of the 9600.
  2. filtering the data cable
  3. shielding the data cable
  4. switching the ends of the data cable
  5. seeing how the two's complement of 0x05=00000101 (11111010 =0xFA, I think) gets through
  6. comparing the scope image of 0x05 to a few values that transmit well to see if the waveform quality differs.
  7. trying TimerB, if there is such a thing
  8. trying some other bitbanged transmitter
  9. trying some transmitter that isn't bit banged (one of the computers, for example) Come to think of it, you have three computers and the wire has two ends, so you can test a half-dozen (A>B, A>C, B>A, B>C, C>A, C>B) pairs.


Happy Hunting,
Eric
By colinb
#132361
Very weird problem since it works with the same USB-RS232 converter on another machine.

I recommend you try a direct USB-UART converter like the SparkFun FTDI FT232R breakout. The RS-232 to UART level shifter circuits are really ugly kludges that I do not trust for any sort of reliability.
By fll-freak
#132372
colinb wrote:Very weird problem since it works with the same USB-RS232 converter on another machine.

I recommend you try a direct USB-UART converter like the SparkFun FTDI FT232R breakout. The RS-232 to UART level shifter circuits are really ugly kludges that I do not trust for any sort of reliability.
Not sure I understand. One end of the communication cable is my lightning detector that bit bangs a serial stream that gets converted by a level converter. This micro does not have a UART let alone a USB port. An FTDI on that end is not possible.

One the other end of the cable is a PC using either a native UART or a USB to RS-232 converter. Native UART does not work on Linux box, and the converter does not work on Linux box or two other Windows machines. Since a converter is nothing more than a FTDI chip in a consumer package, I do not see the benefit of an FTDI board on this end either.

Am I missing something?
By fll-freak
#132377
Eric,

Your post was very kind and deserves a well thought out response, but due to time constraints you will get just the following!

Different data rates may be possible but at significant SW redesign. Will reserve as a last ditch.

Cables I am using as fully shielded. I had to cut one open (long story) and found a foil wrap as well as a wire overwrap and both were connected to the D-Shell. These are top notch cables. The D-Shell on the detector is grounded, I can only assume it is as well on the PC side.

Not sure how to filter the cable. Too much filtering and I could remove the signal! Watching the transmit side with a scope shows ZERO indications of a malformed signal. Bit times are accurate to the 0.05%. Edges are sharp and square. Voltages are in range. No glitches to be seen. I will try the receive end tonight.

Switching cable ends seems like a silly test, but I have been surprised by such tests before. To do so, I will have to introduce to gender benders.

Some nagging feeling is telling me that 0x05 has a special meaning. If is not XON or XOFF. ASCII table suggests it is used for "Enquiry". One test I plan to run is to jury rig the detector to send the entire 0-255 sequence one at a time and see what makes it and what does not. It may be that other high bit change values (0x5, 0xA) may get nuked.

No such thing as timerB, but it was a good idea. I suppose I could try a time delay loop type implementation, but with interrupts running I would assume the timing would be worst.

Running a computer to computer test, is a GREAT idea. That will be number one on my test plan for tonight.

I will also be borrowing a serial protocol analyzer from work. Great tool that has saved my but many times in the past. It is like a scope for serial data. Time tags each byte in both directions to the nanosecond, decodes data according to your defined protocol, and flags special events like breaks, parity errors, or framing errors. This may shed some light on the problem.
Last edited by fll-freak on Thu Aug 25, 2011 11:38 am, edited 1 time in total.
User avatar
By viskr
#132380
The level converter you are using steals power from the RS-232 TX line to generate 1 signals (low on RS-232). Add that to 30 feet of cable and I'll bet the RXD at the PC end is pretty marginal.

Did you probe at the PC end or the micro end?

If your laptop is real old it could have a very different RS232 receiver. Most newer ones and most desktops all use an integrated IO chip so have very similar specs. And most likely the transistor drive of the level shifter is probably outside those specs. I've seen similar things happen with BASIC stamps.

We use a similar circuit for RS232 on our Stamp clone, but would never try to run it that fast over 30' of cable. Over 6' it works well at 19Kb. A quick fix might be to slow the baud rate down.

A better setup would be to use a differential driver, at your micro end. If your application requires bidirectional communication, then you'd need to buffer both.
By UhClem
#132383
One feature common to both of those RS-232 converters is that they are absolutely dependent on the computer end providing a good negative voltage on its RS-232 output. Because of the inversion inherent in RS-232 drivers, a logic high output (1) results in a negative voltage. Normally a RS-232 line will idle in the high state which is good.

If you look at the schematics you will see a diode connected to the RS-232 input. This is used to charge a 10uF capacitor to a negative voltage so that the TX driver can swing both positive and negative. You complain of 1's being received as 0's and that is consistent with a problem driving the line negative.

I suspect that the thing your old beater PC has is RS-232 that has drivers with a better negative supply. Or, since you don't seem to have any need for data going the other way, if you built a cable and left out that connection...

The solution is to provide the negative supply voltage to the drivers locally. A MAX3232 is a suitable device for 3.3V systems if you don't have a negative supply handy.

RS-232 is more than timing.
By fll-freak
#132384
Viskr,

I have not yet probed the PC end with a scope. I ran out of time (and patience) last night. That is on tonight's test plan.

Baud rate is 9,600 baud and should be fine at 30 feet. I could slow it down, but then I slow down my overall sampling rate of the detector. If anything I would like to go up in baud. But it is worth the test if push comes to shove.

I was aware that the the level converter steals power to generate the signal. Since it worked on talking to one computer, I assumed it should work on others as well. The proof will be in the scope traces I will collect.

But the strange thing is the EXACT same RS-232 converter with the EXACT same cabling and nearly identical routing but on different computers behaves differently! The only difference in the old laptop setup (that works) that I (suddenly at this very moment) became aware of, is that the laptop is USB 1.0 and the other computers are USB 2.0. The business end of the converter is the same and should have the same margin when sampling the incoming signal. Could the USB power supplies be different enough on the old laptop to make it work? Testing tonight will confirm or deny.
A better setup would be to use a differential driver, at your micro end.
Yes indeed. When I first saw this problem I immediately looked for a RS-422 transceiver chip on Sparkfun. I did not see any. B&B has 232-422 converters, but the price was more than I could stomach. I do not want to spend much money on this solution as it will only be temporary. My overall goal will be to go wireless with Xbee modules as I plan to place the detector in my attic and the computers I am protecting are in the basement and routing that much RS-232 cable would be difficult (and stupid).
By fll-freak
#132386
UhClem wrote:RS-232 is more than timing.
That will get posted to my "wall of knowledge".

The negative rail may very well be an issue. It would seem if too many back to back 0 to 1 transitions occur that the '1s' get changed to zeros. That may not be root cause, but it does seem to fit the data I have collected so far.

Your reasoning is sound, but it does not explain why the exact same cabling and the exact same USB to RS-232 converter on different computers behaves differently. I am beginning to suspect this is a Red Herring and I should ignore this "fact" and just do the data collections and analyze the results.
By esklar81
#132390
Skye,

With your "n + first" hand/eyeball :wink: , you might want to monitor the nominal +5V on the various computer USB ports while you test. IIRC, the computer on which things work properly is USB 1, and that may have a more rugged power supply than the newer machines.

Another way to test the notion of USB power is scare up one of the cables that pulls power from more than one USB port for a single peripheral and see if using that (with some power source other than the computer you are using to acquire data) makes a difference.

Happy Hunting,
Eric
User avatar
By viskr
#132391
30' and a real RS-232 driver would be fine

But that's not what you have, and if you throw a scope on it, you'll see a pretty ugly signal at the PC end. And as for a noisy signal working in one setup and not another, that's what noise is.

For quick and dirty, either slow it down, or run the TTL signal the 30' and put the converter closer to the PC.
By fll-freak
#132392
Head Slap. I was thinking RS-422 but RS-458 is also differential (although only single direction at a time). Sparkfun sells an RS-485 to USB converter as well as RS-485 to logic level converter! Since my application is single direction, this might be the perfect temporary solution till I get up to speed on Xbee.

But I still have enough self dicipline to see this problem through.

@Eric: I think I have a USB breakout board I can use to probe power. I also have a non powered hub. Hope it does not come to that, but its yet another experiment to run. Still have hundreds of tests to run before I break Edison's record.

@viskr: Good points. can't wait to get home and look at the signal on the PC end of the cable.
By esklar81
#132397
Skye,

I, too, was thinking RS-485, mostly because I've seen it perform better as a sensor interface in industrial (that is, rather EM noisy) environments that RS-232 does. As usual, however, YMMV.

Eric
By dschlic1
#132404
I think perhaps the problem lies in the USB to RS232 converter and the drivers used in the computer. Some USB to RS232 converters do not use a UART chip in them, instead "bit bang" the USB lines. Try a different converter. I have had very good luck with the Keyspan USA-19HS.

I am a systems integrator, and this unfortunately is a very common problem now days. Most PLCs require initial setup using a serial port, and unfortunately most PLC programming software is very picky about its serial ports.