Hi everybody,
I have a Raymarine ST70 and a tri function DST800 (depth, speed, water temp). In fact it is a Airmar DST200 transducer. All is working fine, I have the speed, depth and temp on ST70 screen (in a laboratory, not on a boat)..
With my students I work on CAN bus and I have plugged a logic analyzer on the Seatalk NG network. The project is to build a gateway from NMEA 2000 to a web server.
I see the data on the bus with the following PGN (second part) : 637-66339, 1407-67363, 893-68387 and 1661-70435 (decimal). These PGN doesn't exist in the Airmar doc ! On this doc I find PGN 128259 for speed (water reference) for example..
Do you think that Airmar build a transducer especially configured for Raymarine so unusable with a standard NMEA 2000 display ?
Have you infos on structure of data (8 bytes for each PGN) ?
Looking forward to reading you.
Bernard
The Panbo Forum
Return to Panbo Forum main page »
I don't have direct knowledge of the PGN's, but I write about N2K here on Panbo, use the ST70, and would bet all the money in my pocket the sensor output of that Raymarine/Airmar transducer is exactly standard N2K to the ST70. The output of the ST70 to configure the sensor might also be, I think I would bet money on that too.
I would not bet money the documentation is correct.
Next place you could look for some insight into what else could be your problem is this N2K blog by Kees described as "Analyze the N2K protocol and other marine electronics stuff"
http://yachtelectronics.blogspot.com/
On Panbo there is an open source project that Panbo readers, including Kees are contributing too:
https://www.panbo.com/forum/2010/09/nmea-open-source-project.html
Also, there is the Raymarine Community Forum link too ask for current documentation on which PGN's are involved with the sensor you purchased:
http://raymarine.ning.com/
Bernard,
The DST800 uses standard PGNs.
What you are seeing iare values for the CAN Arbitration and control fields, this needs to be decoded. You need to read up on ISO 11783. I suggest that you read my blog and then go to the open source version at http://www.canboat.com
You can find my ISO11783 decoder in https://github.com/canboat/canboat/blob/master/analyzer/analyzer.c lines 460 to 555.
If you write a small program that produces one line per packet the canboat analyzer program will do all the PGN decoding into separate fields for you.
I Dan and Kees
Thank you for your answers.
As I read you I think that I have not understood how PGN works.
When I read the CAN frame on my analyzer I have :
SOF
Basic ID 637 (decimal)
SRR = 1
IDE = 1
Extended ID 66339 (decimal)
RTR = 0
RB1 = 0
RB0 = 0
DLC = 8
8 bytes of data. I think the first byte is an identifier for the transducer. the second and third for the depth and the others at 0xff
CRC
ACK
END
I have simulate this with a MCP2515+2551 and I have the good depth on the ST70 (Airmar transducer unplugged :-))
Can you explain me how can I extract the PGN from this frame ? I have read Kees's code but it's a little complicated for me.
Looking forward to reading you
Best regards.
Bernard
Hi
I think I have found parts of my mistakes.
PGN is 18 bits long beginning at the fourth bit. With this I get PGN=128259 for speed : OK :-) !
Now how the source is fixed ? In my case of study the source is the last byte (22th to 29th) so 35. From where does it come from ?
Finally hos is fixed the priority field (3 first bits), in may case 010 (binary)?
Looking forward to reading you
Best regards.
Bernard
My getISO11783BitsFromCanId() function takes the 29 bit CAN ID and produces priority, source, destination and PGN from that ID. The bit field extractions that it does are based on what the CAN ID bits mean in ISO11783, so the intermediary variables created in that function are named after those fields (PF, PS, DP).
The PGN length (in bits) is not fixed; if the PGN has a destination address there are fewer bits available for the PGN.
If you can't understand the code you haven't played with the bits enough. Read the documentation for that function again. Bit numbers of the CAN ID are in big endian, whereas the bit stream you are referring to is little endian. This is why the bit numbers in the source documentation go up where the CAN ID bit numbers go down. The C code is supposed to be given the CAN ID.
N2K addressing work by all devices claiming an address on the network. If nobody else objects (by sending a no-you-cant-have-that-address message) the device takes the address until further notice. All devices are required to respond to renew-your-address and other management PGNs (such as tell-me-who-you-are). Source addresses are semi-permanent so that they stay the same once the system doesn't change.
Most of the N2K logs that I have also show address 35 for an Airmar depth sensor -- it looks as if that is the default address for Airmar depth sensors.
Thank you Kees for your explanations. I come back to the bit analysis :-)
Have good cruises
Bernard.
I bought a B&G «DST800 Speed/Depth/Temperature sensor».
The box reads Part No. 44-127-3-01. The Airmar site indicates that this is the Simrad part number for a DST 800.
Nonetheless, the B&G Zeus MFD reports that what's plugged on the network is a DST 200.
I can't seem to find a DST 200 on the Airmar website itself.
So it goes.
Hi Xavier,
It's the same thing with this product on Raymarine : a DST200. If you google "Airmar DST200" you will find poor docs. I think that this is approx the same thing with Maretron DST100/110.
Good cruising
Bernard on Fiou-5 Tyrrhenian sea
Admittedly, Airmar has confusing (re)naming policies, and a website that takes more digging than most, but once you find the actual documentation it is, in my opinion, the best documentation on NMEA devices anywhere.
Have you read this:
http://www.airmartechnology.com/uploads/installguide/DST200UserlManual.pdf