Chit Chat - Simarine Panel+NMEA 2000

Print Page | Close Window

Simarine Panel+NMEA 2000

Printed From: myHanse.com
Category: General
Forum Name: Chit Chat
Forum Description: Talk about anything to do with your boat
URL: https://www.myhanse.com/forum_posts.asp?TID=13881
Printed Date: 26 March 2026 at 23:37
Software Version: Web Wiz Forums 12.06 - https://www.webwizforums.com

Topic: Simarine Panel+NMEA 2000

Posted By: Riemannh
Subject: Simarine Panel+NMEA 2000
Date Posted: 25 February 2023 at 17:36

Hi all - new member; thanks in advance for any help.

My boat came with the newer "Simarine SPC220H Hanse Yachts Control Panel with integrated Pico battery and tank monitoring system." This device replaces the Wurth panel, but still uses digital shunts without manual override switching (ugh...). Generally, this device has performed OK and has been stably connected to my Sentinel boat monitor via a CAN connection without problems. My question follows.

This past week, I've attempted to connect this device to my NMEA 2000 backbone (power isolated), and while this works fine mostly, as soon as I boot up my B&G Zeus3 chart plotters, the Simarine device will begin experiencing unpredictable reboots (including closing all power shunts). Because the Simarine device controls the house bank, this means everything controlled and/or powered by the house battery will shut down... fun while soloing and maneuvering under AP control. Does anyone know (or can anyone guess) why the Zeus 3 might be conflicting or communicating with the Simarine device and causing power cycling?

(If it matters, my boat is a Dehler 38 SQ... hopefully you don't boot me from the community for it not being a Hanse branded boat!)

Again, thanks in advance for any help. I did spend some time searching this forum, and found that folks has installed aftermarket Pico devices, but I didn't see anyone discussing the power panel or issues with network integration.

Replies:

Posted By: Riemannh
Date Posted: 02 March 2023 at 21:43

Replying to my own thread with a possible solution in case anyone runs into this in the future:

Through pure chance, I noticed that the crash was often (possibly not always) happening about the same time the panel dropped into sleep mode. I've disabled sleep mode in the settings via the device's iPhone app and not had a failure since.

I'll follow-up if anything changes, but (hopefully) case closed.

Posted By: Riemannh
Date Posted: 14 March 2026 at 16:01

Resurecting a very old thread of mine (and cross-posting from SA), I know, but I've seen this asked about elsewhere and wanted to document some additional information.

First some relevant topology:

I have a NMEA 2000 backbone with a SPC220H (Simarine panel/PICO) attached without power isolation.
I have many B&G (or B&G licensed) devices attached to the backbone with about 40% bus load (DST 810, WS310, Precision-9, AP goodies, 2 x Zeus3s, etc.).
I also have a Raspberry Pi connected to the bus for debugging and logging (using a PICAN-M).

Additional information (mostly what console commands I performed on my RPi to torture the SPC220H into crashing):

The sleep mode fix suggested in my prior message did not work. Neither have other simple fixes like rebooting, firmware updates (up-to-date as of today), etc.
I noticed the address registration of the Simarine device appears incorrect (invalid name and manufacturer info - the hex address might be different for you):
0x11 00 00 00 00 61 AA A0 C0

I tortured the network using the Pi a couple of ways:

Introducing a bunch of extra traffic by looping reconnection at a frequency of 2 Hz some dozens of times:
Code:
```
sudo ip link set can0 down
 sudo ip link set can0 up type can bitrate 250000 restart-ms 200
```

Adding some errors to the network by looping this (much more slowly):

Code:

sudo ip link set can0 down
 sudo ip link set can0 up type can bitrate 125000 restart-ms 200
 cansend can0 000#DEADBEEF
 sleep 2
 sudo ip link set can0 down
 sudo ip link set can0 up type can bitrate 250000 restart-ms 200

I was able to relatively reliably get crashes by spamming the above items in (3-1) and (3-2), but wasn't able to narrow down a pattern of commands or a minimal set to get failure. So, because of the registration issue noted in (2), I decided to try pushing the SPC220H around the address range since it's broken registration has a very low priorty. I.e., I ran:
for addr in 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F; do
cansend can0 18EEFF${addr}#FF000000000050C0
sleep 2
done

This didn't result in a crash, so I kept pushing it up (now its at 0x34, a relatively quiet spot of the address range)... and running for 24 hours without a crash.

TLDR
I still don't know why this device is crashing, but it seems network spam/error related and address registration related (and the device has a firmware bug in its address registration that may or may not be related). Pushing the device onto a quiet part of the address range seems to protect it from crashes... but I have limited data to support that. I'll see how long my sensors run before a SPC220H crash and will report back later.

Edit: I submitted a ticket to Simarine.