Incomplete N2K PGN 126996
Hello,
The HW/SW is
- SignalK 2.11.0 (N2K addess 0x64)
- RPI 5 8Gb + SDD + PICAN-M
- Garmin MFD (N2K address 0x00)
- Own RPI Pico develoment (N2K address 0x77)
When the garmin ask for PGN 0x1F014 or 126996, the Signalk server send an incomplete message.
Should I increase a buffer ??
Details:
The garmin request produt information
can0 18EA6400 [3] 14 F0 01
The SignalK server reply with:
can0 0DF01464 [8] 40 86 20 D6 9B 02 53 69
can0 0DF01464 [8] 41 67 6E 61 6C 20 4B FF
.....
can0 0DF01464 [8] 4A 61 6E 62 6F 61 74 6A
can0 0DF01464 [8] 4B 73 FF FF FF FF FF FF
As you can see, the message suppose to be 134bytes long but in reality is 77bytes long.
If I compare with other devices the message is 134bytes and understood by the garmin
can0 19F01477 [8] 40 86 35 08 9A 02 44 75
can0 19F01477 [8] 41 76 69 76 69 65 72 20
...
can0 19F01477 [8] 52 FF FF FF FF FF FF FF
can0 19F01477 [8] 53 00 01 FF FF FF FF FF
42 Replies
The length of that is not always going to be the same
hmm. I may be wrong about that...
You are correct, it should 134
I've been trying to figure why Garmin devices are having issues recognizing sk, this could be it!!!
canboatj is encoding 134 bytes
Can you give me the complete message you are seeing?
`
can0 18EA6400 [3] 14 F0 01
can0 0DF01464 [8] 40 86 20 D6 9B 02 53 69
can0 0DF01464 [8] 41 67 6E 61 6C 20 4B FF
can0 0DF01464 [8] 42 FF FF FF FF FF FF FF
can0 0DF01464 [8] 43 FF FF FF FF FF FF FF
can0 0DF01464 [8] 44 FF FF FF FF FF FF FF
can0 0DF01464 [8] 45 FF FF 32 2E 31 30 2E
can0 0DF01464 [8] 46 30 FF FF FF FF FF FF
can0 0DF01464 [8] 47 FF FF FF FF FF FF FF
can0 0DF01464 [8] 48 FF FF FF FF FF FF FF
can0 0DF01464 [8] 49 FF FF FF FF FF FF 63
can0 0DF01464 [8] 4A 61 6E 62 6F 61 74 6A
can0 0DF01464 [8] 4B 73 FF FF FF FF FF FF
Like if it stop after 4B...
To compare here is what I see from other devices
can0 19F01477 [8] 40 86 35 08 9A 02 44 75
can0 19F01477 [8] 41 76 69 76 69 65 72 20
can0 19F01477 [8] 42 4D 61 72 69 6E 65 20
can0 19F01477 [8] 43 2D 20 54 61 6E 6B 20
can0 19F01477 [8] 44 73 65 6E 73 6F 72 FF
can0 19F01477 [8] 45 FF FF 70 79 74 68 6F
can0 19F01477 [8] 46 6E 20 30 2E 31 61 FF
can0 19F01477 [8] 47 FF FF FF FF FF FF FF
can0 19F01477 [8] 48 FF FF FF FF FF FF FF
can0 19F01477 [8] 49 FF FF FF FF FF FF 74
can0 19F01477 [8] 4A 65 73 74 20 30 2E 31
can0 19F01477 [8] 4B 61 FF FF FF FF FF FF
can0 19F01477 [8] 4C FF FF FF FF FF FF FF
can0 19F01477 [8] 4D FF FF FF FF FF FF FF
can0 19F01477 [8] 4E FF FF FF 30 30 30 30
can0 19F01477 [8] 4F 30 30 30 31 FF FF FF
can0 19F01477 [8] 50 FF FF FF FF FF FF FF
can0 19F01477 [8] 51 FF FF FF FF FF FF FF
can0 19F01477 [8] 52 FF FF FF FF FF FF FF
can0 19F01477 [8] 53 00 01 FF FF FF FF FF
In data 53, the 2 last bytes are end of message
and you are sure you are getting all the messages from the log? they can be mixed with other messages
make sure you grep for
0DF01464Yes, used candump and a YD, I find the same issue
I filter on the PGN as well
When remove signalk from the canbus, the garmin requests slowing down for 1F014.. Sounds like they keep pooling for but at slow speed.
yeah, I see the same thing here in my lab with the garmin
it seems to work fine with Raymarine and B&G
I'm getting setup now to look at this here...
Ok, I my lab I have a Garmin, in the boat mostly Raymarine, RPI, and home made N2K sensors.
I didn't test with Mc Athur Hat (I got one unpacked), still using PICAN-M
I wonder what I am missing, I don't even see the garmin requesting 126996 now
and Signal K shows up in the device list on the garmin
Ok
does it not show in the list for you
No
I'm not actually sending any data out right now, let me turn that on...
for 1 second I can see unknown devices and then nothing
on the garmin
you have the latest sk server running?
The garmin send the request with : can0 18EA6400 [3] 14 F0 01
2.11.0
ok, now that I am sending data, it asked for it
and it looks good
do you see heartbeat comming from signalk?
126993
I will to check, but I don't remind i
I don't remind seing this pgn
that was a new addition
but a while a go
can you check your canboatjs version
Let me dig a little bit more, it's my lab (not the boat) and I have few RPI 4 with PICAN-M and could test on another one
how I do it ??
I am definitely not seeing that it keeps requesting 126996, and I used to. I don't think I checked after adding heartbeat
wtf. I have an old canboatjs!
hold the horses!
I can go up to /usr/lib/node_modules/
you might be in /usr/local
I can't see /usr/lib/node_modules/
/usr/local/lib/node_modules ?
no
I'm searching
are you using nvm?
I found it
ps auwx | grep node
Version 2.10.0
shoot, I gave the wrong command to get the version
that was the global install
I check inside the file package.json using cat
the version mentionned is 2.10.0
that's the latest
Ok
I could test it on another RPI.. to see if I have HW issue (I don't think so, but we never known)
I have definitely see odd stuff from bad hardware
Is yours sending out any data? does it look ok?
Yes
very strange!
I will check with another long pgn and test if this is trunk as well
and on another HW too
Will take time, will send update when complete 😉
thanks for your quick help
welcome
there was an issue in github on this, was that you?
No
I open a case on openmarine... but left a message that I'm handling it with you now
BTW I'm networking engineer and boat owner.. this is intersting products
Thanks for the team work
It's fixed...
I initially follow the PICAN-M install guide and add the config like recommended. This is the version that wasn't working.
I remove it and configure it using the CAN application from open plotter and now it's working.
The long PGN is not trunked anymore and recognize in the Garmin MFD 😉
cool, can you show me the config that didn't work?
https://cdn.shopify.com/s/files/1/0563/2029/5107/files/pican-m_UGB_30.pdf.zip?v=1694784602
I followed the suggested config in attached document
that's?
do you know exactly which part of there suggested config was the issue?
(I want to make sure the is recorded well somewhere incase someone else has the isssue)
I remove dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=25
I tried on a second RPI with same PICAN-M hat... same problem and same solution... This is consistent 😉