NMEA Depth Sensor Help?

Matt LeBlanc · 2009-05-20 19:09

Hi all,

There are a few of us at my school currently attempting to make a summer project - a boat which will navigate down a canal on its own, using a depth sensor to keep it in the middle (deepest) part of the channel. We're having an incredibly difficult time getting any kind of sensible output from the depth sensor itself; however, so hopefully someone will be able to help us out with that...

This is what we know so far: the device is a garmin intelliducer nmea0183 depth sensor, and we're using an OWL datalogger which runs on a BS2pe. Apparently, the sensor should output some sort of string along the lines of this:

$SDDBT,x.x,f,x.x,M

We're using a SERIN command on the stamp to get this data in, but unfortunately all that we're able to get is the same repeating string of nonsensical numbers. We've tried using a WAIT("DBT,") command, but every time we put that in the program never collects anything. Right now, we've been using the SPSTR command to read the entire string to scratchpad RAM, but when we print that out to debug we still get the same sequence of repeating numbers, which as far as we can tell doesn't correspond to the above in any straightforward (hex, ascii codes, etc) fashion. The numbers don't even change if we move the depth sensor!

Any help you can give us would be greatly appriciated, no one here is a real stamp wizard but we've used it for a couple of small projects in the past. Thanks again!

Phil Pilgrim (PhiPi) · 2009-05-20 19:15

Are you using the correct baudrate and polarity? NMEA typically uses 4800 baud.

-Phil

Matt LeBlanc · 2009-05-20 19:16

We're using 4800 baud.

Polarity?

stamptrol · 2009-05-20 19:24

You're on the right track, using the WAIT and SPSTR. From the Garmin, if you capture it as a string then send it to a display as a string, it will be readable as long as the baudrate, etc are right.

To make sure the Garmin is putting out something useful, feed the serial line into a PC running Hyperterminal, or even open a DEBUG screen and watch the data. This will confirm your baudrate, etc.

A minor point, the transducer may not give you a good number if the face of the transducer is not immersed in the water.

Cheers,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tom Sisk

http://www.siskconsult.com
·

Matt LeBlanc · 2009-05-20 19:36

The transducer face is in a pail of water... as far as we can tell, the baudrate is 4800bps, that's what was in the documentation and that's what we have in the code. If we include a WAIT command, nothing ever happens - period. Right now, we're making it display the output in a debug terminal, which gives us this...

2531452092411761452092162162521452412412452081771532551452092411761452092162162521452410
2092411761452092162162521452412412452081771532551452092411761452092162162521452412412450
2092411761452092162162521452412412452081771532551452092411761452092162162521452412412450

What other things should we be using in the serin command? Right now it's just SERIN rx_a, baud,[noparse][[/noparse]SPSTR 30]. This is all we've read to do so far...

Thank you for the prompt replies. We're hoping it's just something minor we've missed.

Tracy Allen · 2009-05-20 21:51

The baud parameter has either "true" or "inverted" polarity. For 4800 baud, it would be either $bc for true, or $40bc for inverted. Furthermore the NMEA device is RS485 and has two data wires, one that transmits true and the other inverted. You can use either wire, but whichever one you use has to be matched to the logical polarity of the baud parameter.

I see from a glance at the manual that there are two versions of this device, the NMEA 0183 and NMEA 2000. You have the NMEA 0183 version, right? Does this sensor transmit repeatedly at a fixed interval? If these are meant to be part of a network, the network master needs some means to coordinate access. The NMEA 2000 standard is considerably more sophisticated, multiple master, carrier detect, collision avoidance. In NMEA 0183 I think networking is more of a hack, ascii command to individually addressed devices, or via a universal command and time slots assigned to individual devices.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Matt LeBlanc · 2009-05-20 21:59

Alright, I'll look into the inverted baud settings. But shouldn't it still come through as the $SDDBT...etc string, instead of a bunch of numbers?

And yes, we're using the 0183.

Tracy Allen · 2009-05-20 22:50

Yes, it is strange about the numbers, as it looks like a real ascii string. Usually the result is a bizarre mix of garbage when the baud is wrong.

The suggestion to feed the data directly from the depth sensor into a PC program like hyperterminal is a good one. Just to see what is going on. Use the tx- signal to pin 2 of a DB9 into the PC.

I don't see anything in the manual I downloaded from Garmin about the nmea sentence format. Did you find this documented somewhere?
$SDDBT,x.x,f,x.x,M

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Chet · 2009-05-20 23:14

have you tried it in "open"'water. maybe the size of the bucket is generating multiple echoes.

good luck

Chet

Phil Pilgrim (PhiPi) · 2009-05-20 23:32

It looks like you're inputting in binary and outputting in decimal. Be sure to use the DEC modifier in your SERIN statement as well.

-Phil

Matt LeBlanc · 2009-05-21 00:08

Tracy - yes, we found the DBT standard on another website. But it should be the same for all NMEA standard devices? Also, if you convert that string of numbers into ASCII characters, it's a huge load of rubbish... but we'll try inverting it next.

Phil - whenever we use a WAIT command, or a DEC modifier, or both, nothing ever happens. The only time we can even get the nonsense is by using neither.

Tracy Allen · 2009-05-21 03:40

Should be standard, but until it works and you see the expected result, any line of troubleshooting is open. The hookup of the sensor data directly to hyperterminal or directly to the DEBUG windowis a good place to start, to build confidence that the sensor behaves as expected. The PC has a serial buffer, while the Stamp does not. Some intelligent sensors have multiple interface options, user or factory programmable, and it is too easy to end up on the wrong page. An oscilloscope can be a valuable tool here too. A digital 'scope can capture the start of the waveform and with a trained eye (or a $$$$ 'scope that has protocol sensing built in) you can tell a lot about the serial string.

Can you post the simple program you are using? How about the hardare? Which wires are connected to the OWL2pe?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Phil Pilgrim (PhiPi) · 2009-05-21 07:06

Matt,

Please show us the exact SERIN statement you used that includes both the WAIT and DEC modifiers, along with the DEBUG statement that produced those numbers.

-Phil

Matt LeBlanc · 2009-05-21 12:40

Okay... this is the program we've been using that has been giving us output (the nonsense numbers above.) It's the only way we can get anything out of it. When this is run, we have the gray wire from the sensor connected to the OWL2pe on pin 0. The SPSTR argument could be any number, as long as it's less than the total number of bytes in the input, we just chose 15 so that we'd know we were below it.

' {$STAMP BS2pe}
' {$PBASIC 2.5}


'***********PINS*************
rx_a          PIN   0
rx_b          PIN   1

'**********CONSTANTS**********

baud        CON   4800
'**********VARIABLES********

x                VAR  Byte
temp             VAR Byte

'*******MAIN PROGRAM**************

DO

SERIN rx_a, baud,[noparse][[/noparse]SPSTR 30]


FOR temp = 1 TO 30

  GET temp, x
  DEBUG DEC x

NEXT

DEBUG CR


LOOP

This is a picture of the oscilloscope while that's going:

This is a picture of the oscilloscope with the same program working, but with the redwhite wire connected instead of the gray one:

For Phil, now, these are some of the SERIN commands we've tried which haven't given us anything...

'SERIN rx_a, baud, [noparse][[/noparse]WAIT("DBT,"),SKIP 10, DEC depth_feet]

'SERIN rx_a, baud, [noparse][[/noparse]WAIT("DBT"), depth_feet, feet_variable, depth_meters, meters_variable]

'SERIN rx_a, baud, [noparse][[/noparse]wait("DBT"), DEC depth_feet, feet_variable, DEC depth_meters, meters_variable]

Post Edited (Matt LeBlanc) : 5/21/2009 12:55:38 PM GMT

Bean · 2009-05-21 13:15

Matt,
· The baud value is NOT 4800 for 4800 baud.
· For the BS2pe it needs to be either 188 (for TRUE) or 16572 (for INVERTED).

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There is a fine line between arrogance and confidence. Make sure you don't cross it...

·

Matt LeBlanc · 2009-05-21 13:39

Bean (Hitt Consulting) said...
Matt,
The baud value is NOT 4800 for 4800 baud.
For the BS2pe it needs to be either 188 (for TRUE) or 16572 (for INVERTED).

Bean.

That's giving us our output... thanks so much!

One thing we're all wondering... why is it 188 instead of 4800? 4800 is the only number we could find in the manual.

Tracy Allen · 2009-05-21 15:04

Look in the Parallax BASIC Stamp manual under the SERIN and SEROUT commands, and you will find the baud rate parameters in a table. There is also a formula that you can use to calculate it even for non-standard values. The parameter is a delay constant used by the PBASIC interpreter, not the baud rate itself.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

NMEA Depth Sensor Help?

Comments