due_can fork does not work with my Arduino Due

[erik-rosen]

Hi,

First of all, thank you for all of the hard work you've put into the NMEA2000 library!

I'm having issues with your due_can fork: https://github.com/ttlappalainen/due_can/ not working on my Arduino Due. I couldn't get the example TemperatureMonitor to work (running it kept yielding 'PGN xxx send failed'). I now believe I've ruled out any hardware issues and narrowed down the problem to the due_can fork through the following observations:

Running the example CAN_EchoTest on the due_can fork with two transceivers on CAN1 and CAN0 hooked up to the same bus, does not return the expected output (i get some random, but consistent reply):

Type CAN message to send
Sent value= 0
Initialize buffers
Initialize buffers
CAN message received= 101010180163
End of test

Running the same example off the tip of the trunk: https://github.com/collin80/due_can, it yields the expected output:

Type CAN message to send
Sent value= 0
Initialize buffers
Initialize buffers
CAN message received= 055AAEE22
End of test

I've also tested the attached CAN-CAN bridge example with success: CAN_CAN_Bridge.zip

I'd use the trunk due_can library if I could, but trying to compile the TemperatureMonitor example with the trunk due_can library instead of the fork leads to the following error:

/Users/erosen/Documents/Arduino/libraries/NMEA2000_due-master/NMEA2000_due.cpp: In member function 'virtual bool tNMEA2000_due::CANOpen()':
/Users/erosen/Documents/Arduino/libraries/NMEA2000_due-master/NMEA2000_due.cpp:83:36: error: 'class CANRaw' has no member named 'getNumRxBoxes'
   for (mailbox = 0; mailbox < Can0.getNumRxBoxes()-1; mailbox++) {
                                    ^
/Users/erosen/Documents/Arduino/libraries/NMEA2000_due-master/NMEA2000_due.cpp:87:25: error: 'class CANRaw' has no member named 'getNumRxBoxes'
   for (; mailbox < Can0.getNumRxBoxes(); mailbox++) {
                         ^
exit status 1
Error compiling for board Arduino Due (Programming Port).

Potentially relevant metadata: I'm running Arduino IDE version: 1.8.13

I'll try to dig into the differences in the fork, but would appreciate any support to make the NMEA examples run on my Due.

[erik-rosen]

Installing the can_common library fixed the compilation error, but even with the unforked due_can library running, the TemperatureMonitor example yields only: PGN xxx send failed. So essentially:

• The forked due_can library examples do not seem to work properly on my due, while the examples work with the unforked version
• With both the forked and unforked library, the NMEA2000 example TemperatureMonitor fails to send frames.

[ttlappalainen]

There has been no changes to my fork of due_can for long time and I have been using it. Just few days ago I rebuild some tests to check that main library works right on DUE and MEGA after some critical updates.

Just as hint I prefer to move to Teensy series or ESP32, which are most robust since I know it has been used on some commercial products with my library.

To compile NMEA2000 library right with due you have to remove other due_can libraries. Library will not work right or even compile with otehr forks. Problem is that they did not accept my pull long time ago so I gave up. I should have actually build in it totally to NMEA2000_due.

"PGN send failed" comes, if CAN controller can not send messages. Most common problem in that case has been:

• you do not have termination resistor on bus.
• your tranceiver is not outputting anything , check disable pin.
• your tranceiver is broken
• controller Tx/Rx lines has been crossed or not connected (cold junction).
• your tranceiver does not have power

You wrote that you do not get right response on echo test. If it is echo test, you should get back same what you are sending - not any random.

[erik-rosen]

Hi Timo,

Thanks for the reply.

Just to clarify that the can bus works as expected on my hardware with the unforked library: 055AAEE is the expected output when entering 0 as the test appends 0x55AAEE to whatever input you send it. With that I’m fairly certain the issue is not with the hardware or bus setup.

I’m curious what specific hardware setup you would recommend with teensy and esp32? Which specific boards and CAN controller/transceiver would you use to maximize the likelihood of a successful implementation?

[ttlappalainen]

I'll check the TemperatureMonitor example with due on monday.

Tranceiver depends on your hw purpose. If you will have your board isolated from outside, you can use MCP2562 and power your device totally from bus.

If your board connects to ground on other side, you have to use some isolated tranceiver like ISO1050. Then you power tranceiver from bus side and board from other side.

[erik-rosen]

Some context: I’m building an attitude/heading sensor (using an MPU9250) for use with a Raymarine Axiom via the SeatalkNG bus.

I was planning on using the power from the SeaTalk NG cable to power the device, so MCP2562 and a voltage regulator to step down the 12V to whatever the teensy/esp32 board needs should work, right? (The due can handle up to 16V input, which was nice).

Any particular Teensy/ESP32 board you would recommend for the above? I do not have any particular form factor requirements or preferences, just aiming for painless/problem free tinkering :)

On 25 Jul 2020, at 16:18, Timo Lappalainen notifications@github.com wrote:

 I'll check the TemperatureMonitor example with due on monday.

Tranceiver depends on your hw purpose. If you will have your board isolated from outside, you can use MCP2562 and power your device totally from bus.

If your board connects to ground on other side, you have to use some isolated tranceiver like ISO1050. Then you power tranceiver from bus side and board from other side.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ttlappalainen]

Just tested due with TemperatureMonitor.ino. Works fine. Other devices can see it and also its messages 130310-130312. Make a tripple check for your hw. You must have termination resistor on bus, otherwise you will most probably get "Send failed".

If your device is only connected to N2k bus, then you can use MCP2562.

Yes DUE can handle up to 16V, but you can easily get DC-DC converter, which can hadle up to 36V. Just heard about boat, where someone feeded 24V to N2k bus - all devices were gone.

For your project Teensy 3.2 is enough. It is also smaller, more powerfull and draws less current than DUE. If you need SD card, you can use 3.5 or 3.6. For Teensy 4 driver is not yet ready.

But why to hassle with something someone has already done? Simrad Precision 9 is reasonable priced very good compass. I bought Hemishpere Vector H220 GPS compass board and antennas with about 1000 € and have <1 degree heading accuracy and <2 m position accuracy all the time.

[mrbubble62]

I tried to build a heading compass with MPU9250 + Teensy (https://github.com/mrbubble62/GyroCompass) drift was bad. Then BNO055 (https://github.com/mrbubble62/BNO055-Gyro-Compass) again compass drift was not good enough. Ended up buying Simrad Precision 9.

[erik-rosen]

Thanks for checking Timo. I’ll try reinstalling the IDE and all of the libraries to see if I can get it working. FWIW, I’ve got termination resistors on both ends and am measuring 60 Ohms across CANL and CANH.

Thanks for the pointer to the SIMRAD compass - I’m more interested in the challenge of building something myself and getting my feet wet in microcontrollers and figured this was an interesting first project.

Sent from my iPhone

On 26 Jul 2020, at 18:42, mrbubble62 notifications@github.com wrote:

 I tried to build a heading compass with MPU9250 + Teensy (https://github.com/mrbubble62/GyroCompass) drift was bad. Then BNO055 (https://github.com/mrbubble62/BNO055-Gyro-Compass) again compass drift was not good enough. Ended up buying Simrad Precision 9.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[mrbubble62]

Agreed it's an interesting project, just be sure its working in the boat without having to "rotate around all axis" before going sailing.

[ttlappalainen]

Challences are nice, but should have some idea how to make it better than others who had used some years for developing it. It would be different if Precision 9 would cost 2000.

[erik-rosen]

I bought a Teensy 3.2 and tried running the TemperatureMonitor.ino example - still kept getting errors "PGN XXX send failed".

I wanted to check whether anything was being sent to the bus (maybe these were just spurious errors), so I repurposed my Due to run the ActisenseListener.ino example and connected the Due and the Teensy to the same bus, and voila - it worked! The temperature messages from the Teensy got picked up by the Due and output to the serial monitor.

Even the "PGN XXX send failed" messages went away even though the only thing that changed on the bus was having the Due run the ActisenseListener. I don't know that much about the CAN/NMEA2k protocol - does it require other listening devices on the bus to "successfully" send a message?

I'll try to switch he Teensy and Due around to see whether the issues are still around on the Due.

@mrbubble62 would love to talk about your drift experiences off-thread if you don't mind!

[JohnMacrae]

Its good to see active discussion here. In order not to abuse the 'issues' section and to permit more open discussion, I've created a channel on my Discord here: https://discord.gg/FucqtR. Please feel free to delete this message if its considered inappropriate.

[ttlappalainen]

Devices should not require any listener. But it seems that there must be an other active device on bus.

1. If I have Teensy+Temperature monitor and Arduino Mega with MCP2515+dummy program -> it works

2. If I have Teensy+Temperature monitor and Arduino Due+dummy program -> Send failed

3. If I have Arduino Due+Temperature monitor and Teensy+dummy program -> Send failed

4. If I have Arduino Due+Temperature monitor and Teensy+Temperature monitor -> it works

5. works, since MCP2515 starts on hw level.

6. and 3. fails, since Teensy or Due internal CAN has not been initialized and started.

That was new for me.

[ttlappalainen]

JohnMacrae I do not see any problem having issues. But there is better channel for open discussion on https://forum.arduino.cc/index.php?topic=50893.new#new

[JohnMacrae]

Thanks Timo. BTW - have you documented your testing environment anywhere? I'll need to set up something similar soon.

[erik-rosen]

@ttlappalainen - thanks for looking into this!

I think we can attribute the "Send failed" errors was seeing to simply not having other active devices on the bus. My guess is that a lot of people developing applications for NMEA2000 devices will not have access to other NMEA2000 devices where they do their development (the harbour where I moor my boat is an hour's drive away) and as such simply plugs in their devices to an empty bus to test their code. To save the hair of the next guy, I suggest adding the following:

• Add potential reasons for send failure to the error message ("Send failed: Is the device connected to the bus? Are there other active devices connected to the bus? Is the bus correctly terminated with 120 Ohm resistors at either end?")
• Add a "common issues" section to the read-me where we add this scenario (and the other cases you posted)

Happy to contribute with a PR on this if you are supportive @ttlappalainen.

A side note: I got my compass to talk to my Axiom plotter yesterday:

Thanks for the work you've put in on this library - I would not have been able to achieve the above without it (or at least it would have taken me a lot more time!).