Just when you think you understand everything, life gives you a left hook.After some serious testing, I had traced my communication problem to very poor voltage levels on the RS-232 serial bus due to a “voltage stealing” logic to RS-232 converter. I even have the scope trace that proves it. Voltage should swing at least 5 volts around zero to give you a +-5 volt signal. I was never even seeing the signal go negative.
Signal from detector using "voltage stealing" converter
So I ordered two sets of parts. The first was an RS-485 solution including a logic level to 485 converter and a USB transceiver. RS-485 is a differential signal and can go at fast speeds or long noisy cables. Just what I need.
The second solution was to by a real logic level to RS-232 converter. These device (from Polulo) does not steal voltage but must be powered externally.
But both orders got put in late in the week. Too late to expect them to arrive before the Hurricane Irene hits New England on Sunday. So I needed a plan-B to collect data.
A Sparkfun Forum poster suggested an optocoupler to switch the plus and minus 5 volts I have on the detector board. Just happens that I have some in my stash. Unfortunately they did not seem to work for me. The diode needed 25 ma to make the switching time short enough to satisfy the RS-232 requirements. And an MSP430 can generate that amount of current from an IO pin.
So it was off to Plan-C. Use a comparator. After a false start with a comparator whose pinout was very confusing (needed +, – and ground?) I dropped in a good old LM339 quad comparator from back in the days that Radio Shack actually sold them. A wired the comparator’s power to my +- 5volts, the signal to one input and the other to a potentiometer to set the trigger point at about 1.5V (3.3/2).
That seemed to work like a charm… till I noticed that 0x05 was still not being recorded properly by my Linux box but not the laptop! What??? Well two hours of experiments later, I found that I had a compound problem. The version of the Python script that was recording the data on the laptop and on the Linux box were slightly different. In the case of the Linux box, I was setting any input less than 5 to zero as a part of the thresholding of my algorithm. On the laptop the threshold was commented out.
This likely means that the whole com thing was working the whole time even with the awful signal. Go figure.