Arduino Due sending to Canbus (N2000) - help needed

[skyflyer]

I suspect it might be something to do with how "fussy' the receiving device is, as clearly Timo runs it as it is written on his own hardware - i don't know which MFD he has though.

(I'm having problems getting ANY dat to the N2K bus; I can get it to the serial output and from there to the Actsense NMEAReader soft are on my PC, where it is evident that the correct PGNs etc are being output, but zilch on my N2K bus - but i think I may have hardware issues.)

There would seem to be some other code related to the device ID etc as otherwise you should be able to pretend its a device from an approved manufacturer by setting their manufacture code and class and function codes accordingly? The fact that doing that produces no improvement indicates to me that there are other fields possibly that are needed?

Quite where you find them is another question!

At the moment I haven't been getting any responses from Timo either, maybe he is away. However i suspect that he will simply say "can't advise on other MFDs" as that what he has written in his documentation already! I'll give it a try though!

What we need to find is someone who has already achieved what we are trying to do.

 

[adwuk]

I've been messing around with this for a while and here are a number of observations:
- the 126996 PGN packet (product information) is built correctly on the arduino and then sent to the network
- what is received (I have an Actisense NGT-1 connected as well) is messed up, the packet is the correct length (134 bytes of data) but the contents have been scrambled.
No idea yet what is causing it. I am using the Teensy 3.2 board with MCP2551 transceiver.

 

[skyflyer]

I wonder if it might be more productive emailing this guy, who seems to be the brains behind the Canboat project

https://github.com/canboat

 

[vas]

I suspect it might be something to do with how "fussy' the receiving device is, as clearly Timo runs it as it is written on his own hardware - i don't know which MFD he has though.

(I'm having problems getting ANY dat to the N2K bus; I can get it to the serial output and from there to the Actsense NMEAReader soft are on my PC, where it is evident that the correct PGNs etc are being output, but zilch on my N2K bus - but i think I may have hardware issues.)

SF, from our email communication, your case is a bit more complicated as you state you're using it on an Seatalk NG A/P which I guess is not the simple thing of pumping data to a "easy" device as I'm doing with the Garmin GMI10

There would seem to be some other code related to the device ID etc as otherwise you should be able to pretend its a device from an approved manufacturer by setting their manufacture code and class and function codes accordingly? The fact that doing that produces no improvement indicates to me that there are other fields possibly that are needed?

Quite where you find them is another question!

At the moment I haven't been getting any responses from Timo either, maybe he is away. However i suspect that he will simply say "can't advise on other MFDs" as that what he has written in his documentation already! I'll give it a try though!

What we need to find is someone who has already achieved what we are trying to do.

From his writings, seems that Timo is using a GMI20 (glass bridge version of my older GMI10). That may explain why it works on his and why my GMI10 shows all data you pump to it, but he also explicitly states that the simple temp monitor declares itself as such on the N2K bus - which is not the case on mine with just the GMI10 and the Due on the bus (and proper termination and power of course). I'm sure we'll get to the bottom of it eventually, just cannot see how we can achieve it without someone's help!

cheers

V.

 

[adwuk]

I doubt if the same problem is affecting the Due that you are using, but I found a bug in the Teensy driver library which was corrupting the data frames. The Teensy is now correctly identifying itself on the network and the string data is being received properly by my Triton display.

 

[vas]

I doubt if the same problem is affecting the Due that you are using, but I found a bug in the Teensy driver library which was corrupting the data frames. The Teensy is now correctly identifying itself on the network and the string data is being received properly by my Triton display.

well done!
So now everything works and hopefully other MFDs see the data and their "owner" correct?
Could you please describe the bug and explain your actions as it may also be the case with the Due and Mega?
Curious how a bug may be corrupting only that data and leave all other pass unaffected!

cheers

V.

 

[adwuk]

Yes, the Teensy is sending the software version, serial number etc correctly, which is bring picked up by the Triton display and listed correctly. The issue was in the Teensy NMEA2000 driver code where a frame buffer was being copied incorrectly before passing on to the Canbus (Flexcan) library. I found the bug by simply going down through the layers of code and doing a Serial.println() of the buffer contents. As it was the first byte in the frame it meant that single frame packets (8 bytes or less) would be sent through with only the first byte corrupted - not too bad - but multi frame packets like the product info wouldnt be sent at all, or badly messed up, as the first byte identifies the frame sequence ID.

The NMEA examples created by Timo work fine unmodified, so I assume that any issues you are having are with either the wiring or the underlying libraries. I will write up my setup tomorrow at some stage in case others want to have a go.

 

[adwuk]

Here is a photo of the working setup.



Teensy 3.2 is being powered by USB, although I have a 12V to micro USB converter which can be used on the boat. The CAN bus transceiver is the Microchip MCP2551. There is a 100nF capacitor across VDD/VSS and a 10K resistor between Rs and GND (slope control). From the various articles I have read, these help with noise control on the data lines (which is what I believed the original problem was, until I found the bug mentioned before). I may remove them if they are not really needed.

I am using Arduino v1.6.7 and the latest NMEA2000, NMEA2000_teensy (with bug fix) and FlexCAN libraries.

As you can see, the Teensy thinks it is somewhere much warmer than here!

 

[vas]

Here is a photo of the working setup.

View attachment 56147

Teensy 3.2 is being powered by USB, although I have a 12V to micro USB converter which can be used on the boat. The CAN bus transceiver is the Microchip MCP2551. There is a 100nF capacitor across VDD/VSS and a 10K resistor between Rs and GND (slope control). From the various articles I have read, these help with noise control on the data lines (which is what I believed the original problem was, until I found the bug mentioned before). I may remove them if they are not really needed.

I am using Arduino v1.6.7 and the latest NMEA2000, NMEA2000_teensy (with bug fix) and FlexCAN libraries.

As you can see, the Teensy thinks it is somewhere much warmer than here!

22C down here today, uncomfortably hot for end of Feb, so rather worrying...

since you'll eventually put the this tiny board on a box and hook it up to the N2K network, it would make sense to have the two pins from the N2K cable carrying 12V drive the board, no? That's what i'm doing on mine (once the programming sessions stop and I have a solid system!) No need for separate power supply and extra cabling.

I may buy a couple of these chips in DIP form and try them out. I'm wondering if the slower clock 8MHz compared to the proposed 16MHz could be causing issues on mine. OTOH, your setup doesn't seem to employ a crystal, all these things are too confusing...

I just checked another shield I've got apparently a genuine (?) CAN SHIELD V1 and it also features an MCP2515 and a tiny TJA1040 and again an 8MHz crystal!
The one I'm using now is a MCP2515 and TJA1050 combo (8MHz).
I also have two more tiny boards with single chips and a few resistors on each one being a straight TJA1050 and the other a VP230, god knows why I bought them, doubt they are any use as they are!

cheers

V.

 

[nigelmercier]

Do "---o" boards need a crystal to run then?

 

[vas]

Do "---o" boards need a crystal to run then?

if "---o" implies all sort of arduino or compatible boards, then the answer is maybe

adwuk setup doesn't seem to have a crystal.
Both my cards do have a crystal.
Skyflyer I think also doesn't use a crystal, but his setup doesn't work yet.

ymmv


@adwuk mind explaining what this flexCAN lib is, not seen/used it!

cheers

V.

 

[Anthony]

if "---o" implies all sort of arduino or compatible boards, then the answer is maybe

adwuk setup doesn't seem to have a crystal.
Both my cards do have a crystal.
V.

Arduino type board can use a crystal or a resonator for the microprocessor clock timing, theroetically a crystal is more accurate and more expensive, it also has a hight component count as to use a crystal you also use two additional capacitors where as a resonator is a single device and lower component cost.

That said a good quality resonator may work better than a crystal with low quality capacitors, and for most purposes a resonantor will work fine. If you are making a clock and you want it to be accurate to the second over a long period of time then the higher accuracy of a good crystal (and caps) over a good resonator would become apparent but for most scenarios a good resonator is fine.

Crystals also tend to be a little more stable over a heat range but more physically fragile, but again we are talking about somthing running at 8 or 16MHz, not a high end microprocessor connected to external high speed buses where timing is more critical.

Whilst I would not rule it out 100% I would be very surprised if the CPU timing is critical in taling to a canbus, espically as there is a dedicated canbus comms chip doing the interfacing so I pam presuming the Arduino is just creating the data packets and the other chip is loading them onto the network (I say that as someone who is just starting to look at this N2k Arduino project so am happy to be corrected on that).

Anthony

 

[adwuk]

No crystal in my setup, no. As Anthony describes, the job of the Teensy/Arduino is to create and send the data to the CAN bus transceiver (MCP2551) and then leave it take care of transmission onto the network. This transmission is done 8 bytes at a time so the NMEA2000 library also breaks large (over 8 byte) messages into a series of sequenced frames. In my case, as I am using the Teensy board, the frames are then handled by the NMEA2000_teensy library (https://github.com/sarfata/NMEA2000_teensy), which acts as an interface between NMEA2000 and the underlying FlexCAN library (https://github.com/teachop/FlexCAN_Library). FlexCAN transmits the final individual data frames from the Teensy to the CAN bus transceiver (i.e. MCP2551), is specific to the Teensy and is used for any CAN bus transmissions (not just NMEA2000).

 

[adwuk]

since you'll eventually put the this tiny board on a box and hook it up to the N2K network, it would make sense to have the two pins from the N2K cable carrying 12V drive the board, no? That's what i'm doing on mine (once the programming sessions stop and I have a solid system!) No need for separate power supply and extra cabling.

That's the plan. I have a 12V to 5V converter which has a micro USB output. It will connect to the network terminal block and then straight into the Teensy to provide power.

 

[vas]

Thanks for the info guys, didn't help sorting out the identification problem though

BTW, took me most of the evening to figure out why I was getting a fair amount of garbage on the serial monitor whilst trying to debug...


NEVER FCKING EVER comment out the line:

NMEA2000.EnableForward(false);

I somewhere read that this is an option that may help on something and I commented it (and then I forgot...) Was debuging NASA NMEA0183 wind instrument shuffling through all the carp, nice!

Happy to report that the minute TTL-RS232 board featuring a MAX3232 that I received today works fine for the 12V NASA instrument.
I now have Wind direction (relative) and speed displayed in the GMI10!
Apparently there's also a temp sensor on the NASA Wind thing (pumping out the YXXDR sentence) and through that I also got outside temp displayed on the GMI. For some reason there's a delay before it first displays the temp (maybe 20sec) but I can live with that no problems. Also compensated for the 2C more that it usually displays (as recommended by NASA)

Tank level monitors are next to go but can only do the pressure sensor one as I'm still waiting for the ultrasound sensors.

May buy a couple of teensies in order to built small dedicated N2K devices (like for the black water tank) avoiding massive runs of signal cables (especially analogue ones!)

Also ordered 5 MCP2551 DIP chips to try with my DUE in case they solve the problem with the identification of the board as a valid N2K device.
Always open to ideas to test on that.

BTW, worked through the night yesterday, trying to figure out why the new NMEA2000_mcp-master .h file wont compile with the Due. Turns out that Timo used on this library some calls specific for the AVR platform that are incompatible with the ARM of the Due. So if someone gets error messages on:

SREG and
int()

drop me a note, I've got a corrected .cpp file for it.

GPSMAP4008 finally shows wind speed and direction as well as air temp, and on the fuel page the fuel tank level. All these are from N2K signals. I need to check the manual as I vaguely recall having a function that presents tank levels on more than one tanks but cannot find it on the Garmin screen now

cheers

V.

 

[vas]

That's the plan. I have a 12V to 5V converter which has a micro USB output. It will connect to the network terminal block and then straight into the Teensy to provide power.

Reviving the thread asking a Q that's bugging me for some time:

When I have built and finished a due + 2551 or whatever CANBUS and got various sensors all working fine, I'll have it getting it's current from the bus, so the two cables will be soldered straight on the 12V in of the board.
That's fine, except when I want to re-program, change/edit something in the code. In that case, I'll have the microUSB connected which also gives 5V to the board to run.

Q time:

Is the arduino clever enough to handle two power sources at the same time? Does it automatically block the one and use the other only, and out of curiosity which one?

cheers

V.

PS fwiw, all NMEA2K sentences programmed are presented on both the GPSMAP4008 and the GMI10 without any problems. None of the devices know where these messages are coming from (i.e. don't recognize any N2K devices in the bus other than themselves) but are happy to display them. So maybe this identification issue is not that important after all.

 

[adwuk]

Is the arduino clever enough to handle two power sources at the same time? Does it automatically block the one and use the other only, and out of curiosity which one?

Nope, it isn't. It might be possible to cut the power track from the USB so that you can run from your external source but still connect the USB. I don't know if that is possible on the Due, but you can do it on the Teensy. I suggest that you use either one, or the other, but never both!

 

[GHA]

It might be possible to cut the power track from the USB so that you can run from your external source but still connect the USB.

Yep, that works. I cut open the usb cable & used the black & red wires which attach to a separate dc buck power supply. The arduino still talks to a raspberry pi over usb but doesn't take any power from it. That's on a mega. You can also power with 5v straight into the Vin pin, but with no voltage regulation so you'd need to be sure of your power supply.

 

[rgarside]

Yep, that works. I cut open the usb cable & used the black & red wires which attach to a separate dc buck power supply. The arduino still talks to a raspberry pi over usb but doesn't take any power from it. That's on a mega. You can also power with 5v straight into the Vin pin, but with no voltage regulation so you'd need to be sure of your power supply.

I put an on/off switch on my Mega, so I have to remember to only plug it into the USB when the switch is turned off - not too much of a problem as the box is easily removable and I usually do any re-loading of programs at home.

 

[vas]

I put an on/off switch on my Mega, so I have to remember to only plug it into the USB when the switch is turned off - not too much of a problem as the box is easily removable and I usually do any re-loading of programs at home.

I'm very worried that I'll burn the lot after a year when I'd forgotten all about what I've done back in time...

cutting the microusb V+ line is probably the best way of doing it.

thanks for all replies!

cheers

V.