1
\$\begingroup\$

This was previously posted in the Stack Exchange forum and I was referred here.

I'm currently trying to connect a Honeywell DRM4000L to a GPS module. The DRM is a dead-reckoning device which takes a GPS input and outputs the location by serial. Currently, I have a GS407 GPS module connected to the DRM. Every time I try the GPS pass-through function on the DRM, I get gibberish output.

I also have an FTDI cable connected to the GPS and I'm getting the correct NMEA data. The data coming in from the GPS is all formatted correctly when connected directly to the computer. The DRM data is also coming in correctly, but it doesn't see an NMEA data stream and thus does not initialize with the GPS data. It only has track information based off of the inertial sensors (INS).

The GPS is set to 9600 baud and the DRM host port is set to 9600, so the DRM should be seeing all the correct GPS data. The baud rate from the DRM to the computer is also 9600.

Is anyone seeing anything that I'm not seeing? Thanks!

\$\endgroup\$
9
  • \$\begingroup\$ Welcome to EE.SE! Please provide a link to the specifications for the hardware in question because most of us will not be familiar with it. Also, please don't use words like "gibberish", tell us exactly what you see. \$\endgroup\$
    – Joe Hass
    Commented Jan 2, 2014 at 2:18
  • \$\begingroup\$ @Joe Hass - Okay; thanks for the welcome and thanks for the reply. The link for the datasheet is: www51.honeywell.com/aero/common/documents/… \$\endgroup\$
    – KK6FSL
    Commented Jan 2, 2014 at 2:44
  • \$\begingroup\$ @Joe Hass - What it appears that I am getting is q_qgg............c.............Q...........}.w.....} which appears to be inverted serial data. I am expecting standard NMEA code looking something like $GPGGA,024542.00,3417.37510,N,11834.07255,W,2,10,1.16,449.6,M,-32.6,M,,0000*61 but somehow when it passes through the Dead Reckoning Module, it becomes inverted. \$\endgroup\$
    – KK6FSL
    Commented Jan 2, 2014 at 2:46
  • \$\begingroup\$ I'm thinking now that it could be that there needs to be a serial inverter, but not a level converter between the GPS and the DRM. Could someone verify if this is the case and whether or not I might be able to get a different GPS to solve this problem? The GPS I'm using now is the GS407 from Sparkfun.com \$\endgroup\$
    – KK6FSL
    Commented Jan 2, 2014 at 3:15
  • 1
    \$\begingroup\$ How are you connecting the GPS to the DRM? Your GPS specifies a TTL logic-level interface while the DRM specifies an RS-232 interface. In addition to different signal levels, a logic-level serial interface is inverted, compared to an RS-232 signal. Standard RS232 level converters, such as the MAX232, automatically invert the signals. \$\endgroup\$
    – DoxyLover
    Commented Jan 2, 2014 at 4:54

1 Answer 1

2
\$\begingroup\$

It seems the solution has pretty much been found in the comments but I'll restate it here for posterity.

The issue is that one of the devices is a TTL voltage-level serial device and the other is an RS-232 voltage-level serial device. TTL voltage levels are (essentially) 0V for a '0' and 5V for a '1'. This is straightforward for most people to understand - low is low and high is high.

RS-232 voltage levels are different. Where TTL has '0' and '1', RS-232 has (respectively) 'space' and 'mark'. 'Mark' is defined as a voltage between +3V and +15V and 'space' is defined as a voltage between -3V and -15V. You'll note that these are the inverse of the TTL levels - a '1' or True signal is a negative voltage and the '0' or False signal is a positive voltage.

KK6FSL noted (correctly) that the serial data he was receiving seemed to be an inversion of the proper serial data. Given the discrepancy of the two voltage levels it's surprising that this would be the case - the voltage levels shouldn't be very compatible at all! Strictly-speaking this would be true, but in the real world there is a surprising amount of compatibility in the voltage levels between TTL and RS-232.

For example, if a TTL-level chip is trying to read an RS-232 signal then the voltage levels work out pretty well (other than the fact that the levels are inverted from what TTL expects). Assuming that the TTL input is protected so that it can't go higher than 5V and no lower than 0V (which may not always be the case! The TTL chip may be in some danger!) a 'Mark' will be 0V and a 'Space' will be 5V. These are perfectly valid TTL levels and the chip will be able to interpret them - but it won't reproduce the original data!

For the reverse case, an RS-232 receiver reading TTL-level signals, a '1' would be 5V which is above the +3V threshold for a 'Space' which would register as a logical '0'. A 0V signal shouldn't register as anything at all because it's outside of the valid RS-232 range: it's not above +3V or below -3V. It's undefined according to the standard and shouldn't be anything at all. Sadly, many RS-232 voltage-level devices are very forgiving of out-of-range voltages and will gladly assume that 0V is a valid value. I believe one past reason for this was that you can save money by directly interface a TTL serial transmit line to an RS-232 receive line without a special chip in between. A bunch of lazy cheap engineers thought it sounded like a good idea and kept it going, so now we have RS-232 'standard' interface chips that don't actually implement the standard.

There's yet another wrinkle here that is confusing. In RS-232 when nothing is happening the state of the line is called Idle. RS-232 defines Idle as a 'Space' - this is a positive voltage. When a message starts, the start bit is a 'Mark' which is a negative voltage - thus, a falling transition occurs and this is used to identify when a message begins. One would assume that since the voltage levels are inverted for TTL-level serial messages, the line would Idle at 0V and the Start bit would be 5V. That would be consistent and would make sense so of course it isn't done that way. TTL-level serial also (generally) idles at 5V and the start bit is a '0' which is 0V. Thus, you have the same falling edge transition to mark the start of the message and then all the data bits are properly inverted. If Idle for TTL was simply inverted from RS-232 then the data wouldn't simply be inverted but also delayed by one bit or more (since the first falling edge transition would be some time after the Start bit). Thanks to this wrinkle, there is a simple inversion between RS-232 level and TTL-level serial that makes perfect sense at first, less sense after a bit and then you just give up and accept it.

Don't assume though, that the previous paragraph is definitive. Serial protocols are like opinions - every has one and no one really agrees. There are devices out there that will have Idle at logical '0' instead of '1'. The design-related reasons for this are lost to the ages, but in the end the reason is the same: to make your job harder.

\$\endgroup\$
2
  • \$\begingroup\$ TTL and CMOS are differing standards for what voltages digital I/O are supposed to be. interfacebus.com/voltage_threshold.html does a good job of explaining what the important characteristics are and listing them for several different standards. \$\endgroup\$
    – AngryEE
    Commented Jan 2, 2014 at 19:08
  • \$\begingroup\$ Thanks! I was going to put some closure in on the post, but I didn't know that so many people monitored the posts so I was just waiting to confirm with the manufacturer on the CMOS and TTL differences. For reference, the module defaults at RS-232 and CMOS can be switched to by changing jumpers. Since the GPS and Arduino are TTL, I'm just using a RS-232 to TTL converter (MAX3232). Thanks for all the help guys! \$\endgroup\$
    – KK6FSL
    Commented Jan 2, 2014 at 19:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.