Help with RS-422 communication problems

Hello everyone,

I'm trying to connect a Garmin GPS25-LVC [1] over an RS-422 connection to a VersaLogic Bobcat [2] PC/104 running Debian GNU/Linux. I'm using a MAX491 [3] between the two devices.

[1]
formatting link
[2]
formatting link
[3]
formatting link

The GPS outputs an ASCII-encoded NMEA string on its TTL-level serial output once a second. That signal is fed into the MAX491, which provides RS-422 outputs that are then fed into the Bobcat's serial port. I've connected an oscilloscope at the point where the signal enters the Bobcat, and everything looks perfect: two balanced signals with 5V ranges being sent once every ten seconds.

The problem is that the computer receives data only once every ten seconds, and it gets only a few bytes (even though the oscope shows that the data is being sent once every *1* second, not once every 10). The data that it receives is fragments of valid NMEA-encoded data. Since the computer is getting correct data (albeit only infrequent fragments), I suspect that it may be a software problem.

I've used both Minicom and a small Python program to read data. I get the same result in both. I've included a dump of some of the output of my Python program below.

Any ideas on what may be causing this or how to get things working?

Thanks,

--Bruce

Data dump (one byte per line):

Time (seconds) Dec Hex Binary ASCII

1142618264.18863 36 0x24 100100 '$' 1142618264.19199 0 0x0 0 '\x00' 1142618264.19399 71 0x47 1000111 'G' 1142618264.19756 80 0x50 1010000 'P' 1142618264.20121 82 0x52 1010010 'R' 1142618264.20477 77 0x4d 1001101 'M' 1142618264.20840 67 0x43 1000011 'C' 1142618264.21197 44 0x2c 101100 ',' 1142618264.21533 49 0x31 110001 '1' 1142618264.21874 56 0x38 111000 '8' 1142618264.22209 49 0x31 110001 '1' 1142618264.22544 57 0x39 111001 '9' 1142618264.23108 51 0x33 110011 '3' 1142618264.23594 53 0x35 110101 '5' 1142618264.24089 44 0x2c 101100 ',' 1142618264.24552 65 0x41 1000001 'A' 1142618264.25039 44 0x2c 101100 ','

1142618274.18862 36 0x24 100100 '$'

1142618274.19350 0 0x0 0 '\x00' 1142618274.19703 71 0x47 1000111 'G' 1142618274.20223 80 0x50 1010000 'P' 1142618274.20706 82 0x52 1010010 'R' 1142618274.21199 77 0x4d 1001101 'M' 1142618274.21681 67 0x43 1000011 'C' 1142618274.22171 44 0x2c 101100 ',' 1142618274.22632 49 0x31 110001 '1' 1142618274.23104 56 0x38 111000 '8' 1142618274.23563 49 0x31 110001 '1' 1142618274.24028 57 0x39 111001 '9' 1142618274.24489 52 0x34 110100 '4' 1142618274.24955 53 0x35 110101 '5' 1142618274.25415 44 0x2c 101100 ',' 1142618274.25882 65 0x41 1000001 'A' 1142618274.26364 44 0x2c 101100 ','

1142618284.18863 44 0x2c 101100 ','

1142618284.19350 0 0x0 0 '\x00' 1142618284.19701 50 0x32 110010 '2' 1142618284.20198 48 0x30 110000 '0' 1142618284.20658 55 0x37 110111 '7' 1142618284.21128 44 0x2c 101100 ',' 1142618284.21589 42 0x2a 101010 '*' 1142618284.22056 55 0x37 110111 '7' 1142618284.22516 48 0x30 110000 '0' 1142618284.22983 13 0xd 1101 '\r' 1142618284.23398 10 0xa 1010 '\n' 1142618284.23823 36 0x24 100100 '$' 1142618284.24284 71 0x47 1000111 'G' 1142618284.24766 80 0x50 1010000 'P' 1142618284.25254 71 0x47 1000111 'G' 1142618284.25736 83 0x53 1010011 'S' 1142618284.26227 86 0x56 1010110 'V'

1142618294.18862 36 0x24 100100 '$'

1142618294.19350 0 0x0 0 '\x00' 1142618294.19701 71 0x47 1000111 'G' 1142618294.20220 80 0x50 1010000 'P' 1142618294.20703 82 0x52 1010010 'R' 1142618294.21195 77 0x4d 1001101 'M' 1142618294.21678 67 0x43 1000011 'C' 1142618294.22168 44 0x2c 101100 ',' 1142618294.22628 49 0x31 110001 '1' 1142618294.23101 56 0x38 111000 '8' 1142618294.23560 50 0x32 110010 '2' 1142618294.24026 48 0x30 110000 '0' 1142618294.24486 48 0x30 110000 '0' 1142618294.24952 53 0x35 110101 '5' 1142618294.25412 44 0x2c 101100 ',' 1142618294.25879 65 0x41 1000001 'A' 1142618294.26360 44 0x2c 101100 ','

1142618304.18862 36 0x24 100100 '$'

1142618304.19350 0 0x0 0 '\x00' 1142618304.19701 71 0x47 1000111 'G' 1142618304.20222 80 0x50 1010000 'P' 1142618304.20705 82 0x52 1010010 'R' 1142618304.21198 77 0x4d 1001101 'M' 1142618304.21681 67 0x43 1000011 'C' 1142618304.22171 44 0x2c 101100 ',' 1142618304.22632 49 0x31 110001 '1' 1142618304.23104 56 0x38 111000 '8' 1142618304.23564 50 0x32 110010 '2' 1142618304.24029 48 0x30 110000 '0' 1142618304.24489 49 0x31 110001 '1' 1142618304.24955 53 0x35 110101 '5' 1142618304.25414 44 0x2c 101100 ',' 1142618304.25881 65 0x41 1000001 'A' 1142618304.26362 44 0x2c 101100 ','

1142618314.18863 56 0x38 111000 '8'

1142618314.19351 0 0x0 0 '\x00' 1142618314.19702 48 0x30 110000 '0' 1142618314.20199 51 0x33 110011 '3' 1142618314.20660 48 0x30 110000 '0' 1142618314.21129 54 0x36 110110 '6' 1142618314.21590 44 0x2c 101100 ',' 1142618314.22057 48 0x30 110000 '0' 1142618314.22516 49 0x31 110001 '1' 1142618314.22983 51 0x33 110011 '3' 1142618314.23443 46 0x2e 101110 '.' 1142618314.23909 53 0x35 110101 '5' 1142618314.24370 44 0x2c 101100 ',' 1142618314.24840 69 0x45 1000101 'E' 1142618314.25401 42 0x2a 101010 '*' 1142618314.25896 54 0x36 110110 '6' 1142618314.26382 53 0x35 110101 '5'

1142618324.18862 52 0x34 110100 '4'

1142618324.19350 0 0x0 0 '\x00' 1142618324.19701 48 0x30 110000 '0' 1142618324.20198 49 0x31 110001 '1' 1142618324.20659 52 0x34 110100 '4' 1142618324.21129 46 0x2e 101110 '.' 1142618324.21590 56 0x38 111000 '8' 1142618324.22138 50 0x32 110010 '2' 1142618324.22625 50 0x32 110010 '2' 1142618324.23120 49 0x31 110001 '1' 1142618324.23582 44 0x2c 101100 ',' 1142618324.24053 78 0x4e 1001110 'N' 1142618324.24535 44 0x2c 101100 ',' 1142618324.25001 49 0x31 110001 '1' 1142618324.25460 49 0x31 110001 '1' 1142618324.25927 49 0x31 110001 '1' 1142618324.26387 51 0x33 110011 '3'
Reply to
bruckie
Loading thread data ...

devices.behaviorttp://rocket.et.byu.edu/wiki/Avionics/Subsystems/GPS

@bruckie,

yes looks like a SW problem. To be 100% sure, you should check the signal on the TTL-side (output of your MAX491). To test the serial interface make a loopback connection and check with minicom for instant echo. Flawed and delayed behavior of the serial I/F could be caused by interrupts not coming through. Do a cat/proc/interrupts to check wether the interrupts for the serial are counting up. Problems could also be caused by floating handshake lines.

Good luck

Thomas

Reply to
Thomas Gallenkamp

This looks like interrupts from the UART not getting through:

- Data are collected in the FIFO but no interrupt is triggered.

- Once the FIFO is full, additional incoming data are lost.

- The FIFO is flushed by a timeout every ten seconds.

So that would explain the behaviur. Check /proc/interrupts to see wether the serial port's counter is incrementing.

I noticed that the board has four serial interfaces whereas standard PC's usually have at most two. I'd guess that the standard serial driver does not work out of the box with this configuration, it may need some tinkering.

HTH

Rob

--
Robert Kaiser                     email: rkaiser AT sysgo DOT com
SYSGO AG                          http://www.elinos.com
 Click to see the full signature
Reply to
Robert Kaiser

Thanks for the responses. It turns out that it was a problem with interrrupts. I had configured the interrupts for the serial ports correctly in the BIOS, but I forgot to tell Linux about what I had done. setserial showed this:

ares:/home/ares/pyserial-2.2# setserial /dev/ttyS0 /dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4 ares:/home/ares/pyserial-2.2# setserial /dev/ttyS1 /dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3 ares:/home/ares/pyserial-2.2# setserial /dev/ttyS2 /dev/ttyS2, UART: 16550A, Port: 0x03e8, IRQ: 4 ares:/home/ares/pyserial-2.2# setserial /dev/ttyS3 /dev/ttyS3, UART: 16550A, Port: 0x02e8, IRQ: 3

After running "setserial /dev/ttyS2 irq 5" (setting the IRQ to match the hardware settings) everything worked perfectly.

Again, thanks for the help.

--Bruce

Reply to
bruckie

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.