NMEA 2000 Shield

[Rossp]

Quick question about the monitor (Sender) examples,  each source reports a PGN of 126993 which shows up as Unknown every 60 seconds or so on the bus in the Actisense Nmea reader software.  Is this expected or is there a problem requiring a fix ?

Any ideas upon how to avoid having to do a manual reset after connecting to an active bus ?

[timolappalainen]

PGN 126993 is heartbeat message generated automatically in every 60 sec by library. It is mandatory in new devices. Library will also take care of some other system PGN responses automatically.

It is a bit strange. NMEA2000.CANOpen(); resets the mcp_2515 and does chip initialization on Open. Either I have noticed that problem with Mega. Also reset button should only effect to ESP chip not to MCP 2515, since there is no reset wire to that.

Does Wemos do anything or is it blocked? You could put library to text mode and add to your loop some every second beacon Serial.println("Still running); to see does it send even that. If not try to find where it stops.

[Rossp]

I retested the Mega2560 /mcp2515 hardware with the Actisense Listener Sender example and it appears to work correctly upon powering up on to an active N2K bus, there's no need to do any reset according to Actisense Nmea Reader, it just works.

WemosD1Mini problem still remains, changed serial out to plain text mode (still 115200 baud) and nothing appears on the serial monitor at power up with or without an active N2K bus.

Upon manual reset the following appears at 74880 baud

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16

tail 8

chksum 0x2d

csum 0x2d

v09f0c112

~ld

##)äÒ²P›NÎ.    This jiberish can be displayed at 115200 baud as "CAN device ready", before the plain text PGN details appear.

Not sure if these details are any help

Thanks

[timolappalainen]

No. The first is som ESP build in thing, then it goes to position, where you set baudrate to 115200 and continues program. As I said, you have to add some prints to code see, where it goes.

[Rossp]

I tried even the simpler example Actisense Listener but again the same results at power up.

Using this example I inserted Serial.println("this is xyz"); statements in the main loop and each of the Void sections so you can see the results below.


Working well with active bus data applied after power up

this is loop
this is loop
this is loop
this is loop
this is loop
this is loop
8871 : Pri:6 PGN:60928 Source:13 Dest:255 Len:8 Data:FF,FF,BF,FF,0,91,78,C0
this is HandleNMEA2000Msg
this is LedON
8882 : Pri:6 PGN:126996 Source:13 Dest:255 Len:134 Data:14,5,9A,2,4E,4D,45,41,32,30,30,30,20,73,69,6D,75,6C,61,74,6F,72,20,47,50,53,0,0,0,0,0,0,0,0,0,0,31,2E,32,2E,30,2E,31,30,39,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,31,2E,32,2E,30,2E,30,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,32,30,39,37,31,35,31,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1
this is HandleNMEA2000Msg
this is LedON
this is loop
8919 : Pri:6 PGN:60928 Source:14 Dest:255 Len:8 Data:FE,FF,BF,FF,0,87,78,C0
this is HandleNMEA2000Msg
this is LedON
8929 : Pri:6 PGN:126996 Source:14 Dest:255 Len:134 Data:14,5,9A,2,4E,4D,45,41,32,30,30,30,20,73,69,6D,75,6C,61,74,6F,72,20,4C,6F,67,0,0,0,0,0,0,0,0,0,0,31,2E,32,2E,30,2E,31,30,39,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,31,2E,32,2E,30,2E,30,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,32,30,39,37,31,35,30,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1
this is HandleNMEA2000Msg
this is LedON
this is loop




Powerup onto active N2K bus failure results

this is loop
this is loop
this is LedON
this is loop
this is loop

this is loop
this is loop
this is Update LED State
this is loop
this is loop

this is loop
this is loop
this is LedON
this is loop
this is loop

this is loop
this is loop
this is Update LED State
this is loop
this is loop

Thanks
Ross

[timolappalainen]

Could you to disable interrupt. Then it will be totally poll based. You should have on the beginning
#define N2k_CAN_INT_PIN xx
Comment that so it will set interrupt as default to disabled. This is not solution, but gives a bit more information.

[Rossp]

I use pin D1/gpio5 for the interrupt function.

Did as suggested and commented out this #Define int pin 5 line and to my surprise is works now powering up onto an active bus with a few N2K messages.
Also the built-in led no longer flashes slowly as before, it's mostly always on


Thanks
Ross

[timolappalainen]

Try next.

Enable interrupt back. Then modify NMEA2000_mcp.cpp from line 152 or where you find line

Code: [Select]

if (IsOpen && UseInterrupt() ) {

Code: [Select]

    if (IsOpen && UseInterrupt() ) {
      cli();
      N2kCAN.enableTxInterrupt();
      attachInterrupt(digitalPinToInterrupt(N2k_CAN_int_pin), Can1Interrupt, FALLING);
      InterruptHandler(); // read out possible data to clear isr bit.
      sei();
    }

The problem has something to do with enabling interrupt on wemos. So my quess here is that when there is already data on mcp, wemos does not generate interrupt on attachInterrupt, since pin is down and so does not fall.

[Rossp]

Good news to report, tested both Actisense Listener & Listener/Sender examples and both work well starting up onto an active N2K bus or an inactive N2K bus. Works well as a Listener for Serial.printing in both plain text as well as Actisense format. Still need to test as a Sender but I suspect that it will work well as before.

I wonder if these new library changes have affected the performance for the Mega2560/Mcp2515 hardware, I can test later this week. Are you planning to release an official revision to the existing NMEA2000_MCP library which is compatible with multiple platforms or something ESP8266 (WemosD1Mini) specific ?

Many thanks Timo
Ross

[timolappalainen]

It should not. The last fix is only for start. It has been lucky that it has been working with other chips. Using SREG instead of cli()/sei() just prevent problem in case of concurrent calls. If you would have in your code:

Code: [Select]

cli();
NMEA2000.ParseMessages();
// do something with data shared with interrupts here
sei();

You would be in trouble, since ParseMessages() goes to check buffers and does cli() and sei() too. So when it returns, interrupts has been already enabled and the next data handling could not be done safely. If the same will be done by using SREG, library will not turn interrupts on, since it returns state of interrupts within call and that was disabled before by your cli() call.

Yes, I'll publish this and change use of SREG with define so that mega will have it. But even use cli/sei for all will only cause problem with stacked calls of cli/sei as I describe above. I think it is rather rare case.

[Rossp]

Let me know if you would like me to do more tests

Thanks

[Pim57]

First of all, thanks Timo for a great job with this NMEA2000 work. I am succesfull with building a datalogger for a B&G Vulcan 7, that writes data every 5 minutes to a SD card on a Teensy 3.6. Works great!!

Now my question on sending data on the N2K bus. I tried the examples WindMonitor and MessageSender, but they don't send any data. I enabled monitoring and see after a while that the PGN's report error. Looks to me like it takes some time to fill up a buffer?
Next i tried the ActisenseListenerSender with the NMEA_Simulator. And also here no data on the bus. When i disble the Simulator and reconnect the NMEAReader i notice a slow down. Messages like PositionRapidUpdate are no longer updated every 0.10 secs, but take much longer. Same for other messages that normale come every second.

Next i compared the ActisenseListener with the ActisenseListenerSender.
When i use ActisenseListener with NMEAReader all messages keep appearing fast and never slow down. (See attached)
When i use ActisenseListenerSender with NMEAReader all messages start slowing down after half a minute or so. (see attached)

I suspected hardware and bought a new Teensy 3.6 and new MCP2562 (and yes pin8 is connected to ground to enable transmit data)

Any ideas what might cause the slowing down? And second why the Teensy won't transmit data?

[timolappalainen]

- Missing termination resistors. This causes funny problems.
- Tranceiver not enabled. Check seventh time that pin 8 is really connected to ground.
- TxD pin 1 and CANTX Teensy pin 3 wire broken, not connected or connected to wrong pin. Note that you must use pin 3 on Teensy. If you use alternative pin, it requires some modifications.

[Pim57]

Thx for your prompt response.

- measured 60 ohms on the CAN bus
- dubble checked ground on pin 8 of MCP2562
- replaced wire between Teensy pin 3 (CAN0TX) and pin1 on MCP2562

Still same problem. I am running out of ideas.

Maybe try CAN1TX and CAN1RX on pin 33 and 34? But that would require some code changes, where and what?

[timolappalainen]

MessageSender or WindMonitor should send data for sure. I use those for testing time to time. I normally use ActisenseListenerSender only for sending and ActisenseListener with NMEA Reader. Note that if you use NMEA Simulator, you mus be aware of addresses. Currently Simulator does not do address claiming, so devices with same address may get crazy.

I just build up MessageSender  with library code and tested on Teensy 35 and there is no problem. Did you took FlexCan from my Git and deleted one which comes with Teesyduino? Check that you do not have FlexCan under C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries