NMEA 2000 Shield

[pkeiramo]

Yes - now it compiles. Thanks!

My target is to get my old Raymarine RC435 plotter connected to NMEA2000 network. We'll see, how story continues...

[timolappalainen]

Do you need both direction communication? I had problem with due Serial - with lot of traffic both direction it stopped communication time to time. That was before there was availableForWrite. I do not know about other Serials.

Keep me updated - I may have unpublished code/ideas.

[pkeiramo]

I think that there is no need to send any messages to plotter. It can receive only WPL and RTE messages and I don't see much use for sending them to plotter from network.


But you'll never know - maybe appetite grows during coding. I'll keep you updated.

[Rinkelein]

Dear Timo,

On August 2nd I indicated that we would purchase the MCP2551 in order to be able to send PGN´s to the backbone. In the meantime the chip has arrived an we were able to make it work as the photo´s will prove.

Many thanks and for those who can read Dutch, please visit my website. Apart from being able to read and write to the backbone I also managed to convert the PGN´s into NMEA0183 and send them over WiFi and use if with OpenCPN.

http://rinkelein.000webhostapp.com/NMEA2000.html

[Heikkif]

Thank you Timo for great work on this,

I was able to read data from NMEA 2000 bus to Arduino Due but sending data to bus so that it could be seen on Garmin GNX 20 does not seem to work. I have connected both with MCP2562 as the drawing here shows:https://github.com/ttlappalainen/NMEA2000/blob/master/Documents/ArduinoDUE_CAN_with_MCP2562.pdf and also with this: http://copperhilltech.com/can-bus-mini-breakout-board. This test arrangement for hardware works http://copperhilltech.com/blog/app-note-testing-arduino-due-with-2-can-bus-breakout-boards/. I have uploaded sketches temp monitor and wind monitor as they are in examples folder but no wind data nor temp data when eco/temp sensor is not present can be seen on display. Only data source visible is the eco/temp sensor when it is connected. Actisense reader sees transmission when requested lines are commented/uncommented for testing. Library is of latest version.

Any advice how to debug this futher?

[timolappalainen]

I just tested few days ago TemperatureMonitor example with due and it works as it should. Some things:
- Remember to use at least one terminator resistor on bus even with short test bus wires.
- Check that you use due_can from my repository: https://github.com/ttlappalainen/due_can . Others does not compile or possibly does not work right.

Have you checked that you see any data e.g. with example ActisenseListener?

[Heikkif]

Hi again Timo,

Made sure the due_can is the correct one from your repository. There is a termination resistor on the bus but only at the other end when using MCP2562. When uncommenting
 Serial.begin(115200);
 NMEA2000.SetForwardStream(&Serial);
and commenting //NMEA2000.EnableForward(false); Actisense NMEA Reader shows the data being sent
but nothing can be seen on display. Log shows some timeouts on updating operating mode, product info, configuration info. There is one unknown line on data view PGN 126993 and ISO address Claim seems to come when reset is pushed.

[timolappalainen]

Uncomment also NMEA2000.SetForwardType(tNMEA2000::fwdt_Text); and look due output with serial monitor in. In text mode it shows possible internal errors in clear text. I expect you would get "Send failed" text.

When you read messages from sender USB, it shows messages, which it has tried to send to the bus. It does not mean that they have gone out to the bus from the lower level library. So in text mode you will see if libray buffers start to over run dues to sending proboem.

It is still unclear for mee, which side you read ISO address claim and 126993. Do you have other board connected to the bus or just due and you read its USB?

126993 is heartbeat PGN and old NMEA Reader does not know it.

[Heikkif]

Here is what is seen on serial monitor:

Initialize buffers
CAN device ready
Start address claim for device 0
202 : Pri:6 PGN:60928 Source:22 Dest:255 Len:8 Data:69,B6,1,FF,0,82,96,C0
2703 : Pri:6 PGN:130312 Source:22 Dest:255 Len:8 Data:1,1,4,7D,73,FF,FF,FF
2703 : Pri:6 PGN:130311 Source:22 Dest:255 Len:8 Data:1,44,7D,73,FF,7F,FF,FF
2705 : Pri:6 PGN:130310 Source:22 Dest:255 Len:8 Data:1,C1,70,FF,FF,FF,FF,FF

that goes on until

45220 : Pri:6 PGN:130311 Source:22 Dest:255 Len:8 Data:1,44,7D,73,FF,7F,FF,FF
PGN 130310 send failed
45224 : Pri:6 PGN:130310 Source:22 Dest:255 Len:8 Data:1,C1,70,FF,FF,FF,FF,FF
PGN 130312 send failed
47721 : Pri:6 PGN:130312 Source:22 Dest:255 Len:8 Data:1,1,4,7D,73,FF,FF,FF
PGN 130311 send failed
47721 : Pri:6 PGN:130311 Source:22 Dest:255 Len:8 Data:1,44,7D,73,FF,7F,FF,FF
PGN 130310 send failed
47729 : Pri:6 PGN:130310 Source:22 Dest:255 Len:8 Data:1,C1,70,FF,FF,FF,FF,FF

It makes no difference if arduino is connected to bus with display or not. So far I have tried only with one arduno. I have two arduinos and available so I could add another to the bus and see what it sees an the bus. Would Actisense listener be the sketch to download to the other arduino? So far I only have tested hardware with one arduino with this test program:
 http://copperhilltech.com/blog/app-note-testing-arduino-due-with-2-can-bus-breakout-boards/
 and it works and also have been able to read depth sounder from the bus.

[timolappalainen]

That was I expected. When it comes to situation that send fails continuously, internal buffers are full and so it gives error. This means that no message goes out. This is normally caused, when there is no connection to the bus. Most common error has been that CAN-L and CAN-H has been crossed or chip (MCP2562) STBY signal is not connected to GND. Also missin terminal resistor is common reason, but that you already checked.

I just made a test with due. When it is connected to the bus, but there is no other devices on, it start to give error. Immediately, when I turn on any other device, it start to send normally.

[Heikkif]

With the same connection I can read depth sounder info from the bus so the connection could be ok. Also that two channel test shows the connection should be ok.  Could it be that GNX 20 is "refusing" to communicate with non genuine NMEA 2000 device? Would it be interesting to know if the other arduino with actisense listener sketch is reading what the other with temperature monitor is sending? Would two arduinos one sending  and one recieving see each other as devices on the bus?

[timolappalainen]

N2k bus devices does not normally care who is sending data. They can show e.g. speed data even knowing anything about sender device. This of coarse may denpend of MFD, but e.g. my Garmin GMI 20 does not care. It just shows on devices "unknown device"

Two Arduinos communicate also well. There are examples MessageSender and DataDisplay2, which I have used to test different messages. They does not act as like normal N2k bus device. TemperatureMonitor is the most closes of certified device. So by connecting two TemperatureMonitor to the bus, they do all handshaking and sees each other, but since they are just sending data, they does not listen each other messages. If you change mode to N2k_ListenAndNode and enable message forwarding, then they will forward others messages.

I have to do some more tests. If you have some device sending on bus, then everything works fine, when you connect device. If I start due first and then connect my MFD, it start to work right. If I have due and then connect other TemperatureMonitor, it may get totally blocked.

So you could try cnnecting your MFD, depth sounder and due to the bus and then start due.

[Heikkif]

I was testing Wind Monitor with eco and display last autumn but no wind info showed up on the display. It was then when I was able to read depth from the bus. Now depth sounder is at the boat and arduino and display are at home.
 When testing two arduinos in the bus should they be connected with separate T-connections or is it ok to connect them at the same branch?
 Can the send failed caused by failing hand shake? I will test two arduinos this weekend. The other could be loaded with TemperatureMonitor but which sketch to load to the other?

[timolappalainen]

For test bed it is enough to connect CAN-L/CAN-H with wires. I personally do not use M12 connectors at all, since they require so much space. Instead I use pluggable board connectors (see e.g. farnell codes 1717013 and 1717025 Connector order is shown on my drawing https://github.com/ttlappalainen/NMEA2000/blob/master/Examples/TeensyActisenseListenerSender/Documents/Teensy_Actisense_listener_sender_schematics.pdf). With those you can make CAN bus divider for 5 connectors to 100x55x40 mm box with about 20 €.

Due should work with just display connected. You could also use ActisenseListener example on due and when you turn on display, it should send ISO Address (PGN 60928) claim at the beginning. It is strange, if you do not receive anything from display.

There is actually no handshaking betwee N2k devices. They just do address claiming, which means they ask "I would like to use address 20". If other devices on the bus are happy for that, thats it. If there is other device using address 20, it compares its "name" to other and then either responces "I have address 20" or "I would like to use address 21" depending of priority of "name". All this will be done just using ISO address claim PGN.

The block I caused on my test was because of having two TemperatureMonitor with same "name" on the bus. This should never happen, since as I have documented for SetDeviceInformation: "Each device from same manufacturer should have unique number.". So if you have two TemperatureMonitor, you have to compile one with e.g. Unique number=112233 and other with Unique number=112234

[Heikkif]

Played with two dues and display connected as a bus. Both dues can see display info trough actisense listener as it is turned on. When the other due has Temperature monitor loaded it can't be seen on the other board with actisense listener. Also send failed appears after a while as previously.