SK Pang electronics - PiCAN-M - NEMA 2k and 0183 hat for Raspberry Pi 3 and 4
408 views
Skip to first unread message
Brian Scally
May 13, 2021, 6:39:14 PM5/13/21
to Signal K
All
I recently became aware of and got my hands on a SK Pang PiCAN-M board ( and their metal case.)
I have added them in to the testing inventory, and I though I would write out my observations.
Summary
Initial testing was positive.
The instructions are clear and I found them logical and well laid out, the device did what it was supposed to.
The SignalK server seemed to have no problem sending and receiving from either the 0183 or N2k ports.
However other devices on the N2K network did not recognize the device out of the box.
This lead to interesting behavior:
-The Navico plotters did take temperature and pressure data, but did not take wind data.
-The Raymarine plotter took nothing.
The Pi4 did thermally throttle at ambient above 26C probably due in part to the blocking of airflow to the device heatsinks. This represents a reduction of throttling point of about 5 degrees. This is inline with other full hats.
26C in a closed cabinet is not that unknow on a summer day.
Thermal throttling may lead to slower responses, but in extreme cases data may be lost.
There was no change in the CM4 platform thermal performance.
Brian
I recently became aware of and got my hands on a SK Pang PiCAN-M board ( and their metal case.)
I have added them in to the testing inventory, and I though I would write out my observations.
Summary
1) The device worked as advertised. The simplification of connection and wiring is attractive for a Pi based navigation platform.
2) Using the available metal box provides a neat mountable solution for indoor cabin spaces. Modification for a fan would help thermals.
3) The N2K port is not officially certified by NMEA, which means that it doesn't not have an official ID.
This means that though receive works out of the box individual mileage for sending packets to N2K will vary.
4) Be careful of power on higher load N2K networks.
Case
The metal case was of the quality expected at the price, and provided a good mounting solution for the Pi4 and hat in an protected marine environment. My sample did not include active cooling, but this could be added.
Testing
I tested with:
- A Pi3B+ running the Raspberry 32 bit OS and Ubuntu on a 32GB Sandisk Ultra SSD
- A Pi4B 8G RAM running the 32bit and beta 64bit OS on a 32GB Sandisk Ultra SSD
- A Pi CM4 8G RAM running on 32bit Raspberry OS running form the 32GB CM4 flash.
2) Using the available metal box provides a neat mountable solution for indoor cabin spaces. Modification for a fan would help thermals.
3) The N2K port is not officially certified by NMEA, which means that it doesn't not have an official ID.
This means that though receive works out of the box individual mileage for sending packets to N2K will vary.
4) Be careful of power on higher load N2K networks.
Case
The metal case was of the quality expected at the price, and provided a good mounting solution for the Pi4 and hat in an protected marine environment. My sample did not include active cooling, but this could be added.
Testing
I tested with:
- A Pi3B+ running the Raspberry 32 bit OS and Ubuntu on a 32GB Sandisk Ultra SSD
- A Pi4B 8G RAM running the 32bit and beta 64bit OS on a 32GB Sandisk Ultra SSD
- A Pi CM4 8G RAM running on 32bit Raspberry OS running form the 32GB CM4 flash.
Initial testing was positive.
The instructions are clear and I found them logical and well laid out, the device did what it was supposed to.
The SignalK server seemed to have no problem sending and receiving from either the 0183 or N2k ports.
However other devices on the N2K network did not recognize the device out of the box.
This lead to interesting behavior:
-The Navico plotters did take temperature and pressure data, but did not take wind data.
-The Raymarine plotter took nothing.
-The Fusion stereo took volume change commands but through an error on screen when I asked it to change source.
-The Airmar DST800ndepth sounder took offset commands.
-The Maretron SSC300 compass would not take configuration commands.
Using somewhat dubious configuration work arounds I did get it to work for all my test devices. This does not mean it will talk to all devices.
BUT this is indication that the problem is the closed nature of the N2K infrastructure, not the electrical signals or the SW driving them.
Using somewhat dubious configuration work arounds I did get it to work for all my test devices. This does not mean it will talk to all devices.
BUT this is indication that the problem is the closed nature of the N2K infrastructure, not the electrical signals or the SW driving them.
Sending information to the chart plotters through 0183 worked fine.
Stress testing.
0183
My default testing is with a 7m run of Belden 9891 and a 10M capable PCIe RS422 card with the Pi in loopback and a 10^13 BER pattern.
This ran well at all 'normal' data rates. However as I pushed the speeds up to the default Pi limit of 921600 the waveforms got slightly rounded with 5% under and overshoot.
Changing to use the high speed UART options my receiver had no problem decoding comms till 2.5M, at this rates the error rate dropped below what I would consider acceptable limits ( 1e-10 ).
I tried alternate PSU arrangements and only got a slight improvement.
Shortening the cables to a 1m test loop did improve the situation indicating that high speed serial could be made to work in special cases.
N2K
No problem observed, I took the buss to 85% load - where NMEA2k falls apart any way.
I saw no problem related to the CAN electrical interface.
Pi3 had minimum change in thermal performance ( may be 0.5 deg. But that is at the testing resolution )
Stress testing.
0183
My default testing is with a 7m run of Belden 9891 and a 10M capable PCIe RS422 card with the Pi in loopback and a 10^13 BER pattern.
This ran well at all 'normal' data rates. However as I pushed the speeds up to the default Pi limit of 921600 the waveforms got slightly rounded with 5% under and overshoot.
Changing to use the high speed UART options my receiver had no problem decoding comms till 2.5M, at this rates the error rate dropped below what I would consider acceptable limits ( 1e-10 ).
I tried alternate PSU arrangements and only got a slight improvement.
Shortening the cables to a 1m test loop did improve the situation indicating that high speed serial could be made to work in special cases.
N2K
No problem observed, I took the buss to 85% load - where NMEA2k falls apart any way.
I saw no problem related to the CAN electrical interface.
J1939
Because of the similarities to N2K - no problems observed.
I2C
I tested to 400kHz, the device was solidly within the I2C specifications.
Power
Because of the similarities to N2K - no problems observed.
I2C
I tested to 400kHz, the device was solidly within the I2C specifications.
Power
The device really did get to 15W. It's transient response was tolerable but not good at these levels.
At 15W this equates to a N2K power load of ~31LEN. The N2K bus is specked for a maximum of 60LEN - So over half the power on the N2K bus.
The Pi4 Compute module managed to exceed the 15W limit and caused a system reboot.
Here in lies one of my concerns.
As the power draw of the Pi is partially related to the SW load a new patch or adding another service could generate hard to debug power issues on the N2K bus.
Though devices are supposed to work down to 9V they are more or less tolerant of power bus transients.
Because the Pi can generate comparatively instant loads on the N2K power bus compared to normal N2K devices it is possible to produce some eye brow raising voltage swings on the N2k power bus. Adding some additional bulk capacitance on the N2K power lines would not be a bad idea.
If you were to use this hat I would Assume a LEN of 31 and plan the N2K wiring accordingly.
Thermal
The Pi4 Compute module managed to exceed the 15W limit and caused a system reboot.
Here in lies one of my concerns.
As the power draw of the Pi is partially related to the SW load a new patch or adding another service could generate hard to debug power issues on the N2K bus.
Though devices are supposed to work down to 9V they are more or less tolerant of power bus transients.
Because the Pi can generate comparatively instant loads on the N2K power bus compared to normal N2K devices it is possible to produce some eye brow raising voltage swings on the N2k power bus. Adding some additional bulk capacitance on the N2K power lines would not be a bad idea.
If you were to use this hat I would Assume a LEN of 31 and plan the N2K wiring accordingly.
Thermal
- I only test the high side temperature and too the ambient to 35C. My usual test is looing for the CPU thermal throttling point at a 33% loaded CPU. I use a synthetic load app that does a non DMA copy from flash to mem through the encryption block.
Pi3 had minimum change in thermal performance ( may be 0.5 deg. But that is at the testing resolution )
The Pi4 did thermally throttle at ambient above 26C probably due in part to the blocking of airflow to the device heatsinks. This represents a reduction of throttling point of about 5 degrees. This is inline with other full hats.
26C in a closed cabinet is not that unknow on a summer day.
Thermal throttling may lead to slower responses, but in extreme cases data may be lost.
There was no change in the CM4 platform thermal performance.
Brian
Matti Airas
May 14, 2021, 10:34:35 AM5/14/21
to Signal K
Hi Brian,
I don't think it's a great idea to power newer Raspberry Pi directly from the NMEA 2000 bus. According to the spec, no single device can draw more than 1A from the bus., and the current peaks of the Raspberry Pi could interfere with other devices on the bus. Also, as per the NMEA 2000 spec, all devices should have galvanic isolation. Ground loops will introduce a lot of radiated and conducted noise.
Thanks for the report.
As an alternative, may I suggest the Sailor Hat for Raspberry Pi instead? SH-RPi is a power management add-on HAT for the Raspberry Pi that uses an intermediate supercapacitor as a power bank, guaranteeing that the device never pulls more than about 0.8 A from the power source. This means that it can be safely powered via an NMEA 2000 bus without interfering with other devices (although the connection should be made close to the power supply point to avoid unnecessary voltage losses). It also has proper noise filtering at the power supply, meeting the relevant European and maritime electromagnetic compliance standards. And the onboard NMEA 2000 interface is fully isolated and compliant with the NMEA 2000 spec. And lots of other features as well. :-D
For more details, see:
Best,
Matti Airas
Brian Scally
May 14, 2021, 2:46:27 PM5/14/21
to Signal K
An added note about LEN or Load Equivalence Number - May be you all know this already but..
I measured the device in in LEN, which in N2K is 1LEN = 50ma @12.7V.
I measured the device in in LEN, which in N2K is 1LEN = 50ma @12.7V.
The LEN is ALWAYS rounded up to the next whole number, and fractional LEN no not exist.
One can argue that there is no 0LEN as well.
As Matti says the maximum one should draw to a single device is 20LEN according to the N2K specification.
As Matti says the maximum one should draw to a single device is 20LEN according to the N2K specification.
But really one should apply some tolerancing to this and a common rule of thumb is a 20% derating.
So 16LEN is a practical aim point for maximum draw for a nominal device. Thus this is is 0.8A from the N2K power bus.
So 16LEN is a practical aim point for maximum draw for a nominal device. Thus this is is 0.8A from the N2K power bus.
Haa another device to test! The
SH-RRPi is now on my test list and I ordered it today.
Your comment on Galvanic isolation -are spot on it is something I should have included. Thankyou!
But the aim of the original message was to give a hopefully honest set of feedback about a piece of hardware and add it to the list of pieces that have been seriously looked at.
The device will work, and for some it will achieve what they are looking for.
BUT I feel as a community we should share our concerns and views of device limitations - I hope I did that.
( If others disagree that is a different personal email thread.)
Your comment on Galvanic isolation -are spot on it is something I should have included. Thankyou!
The SH-RRPi is a more elegant solution.
But - as it's site comments notes - the load of a Pi4 and disk and screen is more than N2K was ever meant to support.
Especially if you cool the Pi to reduce thermal throttling. ( Keel cooler compute is the way to go ;- )
But it does have a convenient secondary power connector...
Personally I use fully isolated PoE for my low speed devices not on the N2K networks.
The high speed stuff like the HD cameras and network switches I use harsh environment fiber.
But - as it's site comments notes - the load of a Pi4 and disk and screen is more than N2K was ever meant to support.
Especially if you cool the Pi to reduce thermal throttling. ( Keel cooler compute is the way to go ;- )
But it does have a convenient secondary power connector...
Personally I use fully isolated PoE for my low speed devices not on the N2K networks.
The high speed stuff like the HD cameras and network switches I use harsh environment fiber.
But the aim of the original message was to give a hopefully honest set of feedback about a piece of hardware and add it to the list of pieces that have been seriously looked at.
The device will work, and for some it will achieve what they are looking for.
BUT I feel as a community we should share our concerns and views of device limitations - I hope I did that.
( If others disagree that is a different personal email thread.)
It is for the user to select their own balance of 'implementation' and better understanding of risks comes from a place of knowledge.
And just like the chain or chain and rode anchor debate there is no one correct answer.
And just like the chain or chain and rode anchor debate there is no one correct answer.
Brian
Reply all
Reply to author
Forward
0 new messages