Periodic Signal K sensor freeze

Periodic Signal K sensor freeze - Printable Version

+- OpenMarine (https://forum.openmarine.net)
+-- Forum: OpenPlotter (https://forum.openmarine.net/forumdisplay.php?fid=1)
+--- Forum: Bug Reports (https://forum.openmarine.net/forumdisplay.php?fid=4)
+--- Thread: Periodic Signal K sensor freeze (/showthread.php?tid=6913)

Periodic Signal K sensor freeze - Spark - 2026-05-12

I reinstalled the entire system from scratch to solve a periodic freeze issue that previously affected both BME280 and ICM-20948 data streams.
However, the issue is still present even on a completely minimal setup.

System:

Raspberry Pi 4
Latest OpenPlotter (Bookworm based)
Signal K server
Node.js v22.22.2
Only I2C, serial port and serial console enabled
Only one sensor configured: BME280
No pypilot installed/configured
No external integrations running
No additional Signal K plugins enabled (default plugins only)

I also completely disabled the Signal K set-system-time plugin because in the past it caused periodic spikes/problems on ICM-20948 sensor data.

The BME280 data periodically freezes for ~30 seconds and then resumes automatically.
The freeze repeats continuously with a very regular pattern.
During the freeze:

Signal K timestamps and values stop updating
Data resumes automatically after ~30 seconds
No crashes or visible errors appear in Signal K logs

Since this also happens on a completely fresh minimal installation with only a single BME280 sensor, the issue does not appear related to plugins, integrations or previous configuration state.

I enabled debug mode, opened a terminal and manually started `openplotter-i2c-read`.
But it crashes with an `IndexError` because it expects `sys.argv[1]`. Tried running openplotter-i2c-read 0 - no output.

Any suggestion or help would be greatly appreciated.

RE: Periodic Signal K sensor freeze - Spark - 2026-05-13

Update on the periodic Signal K / openplotter-i2c freeze issue.

After many tests on a minimal clean installation (only BME280 enabled), I found a reproducible workaround with the help of ChatGPT analysis.
This below is the analysis prepared by ChatGPT
----
Symptoms:

periodic freezes (~30s)
BME timestamps stop updating during freeze
Broken pipe errors from openplotter-i2c-read
Signal K logs remain clean
ss -tpn showed growing Recv-Q on the websocket connection between openplotter-i2c-read and Signal K

Important finding:
openplotter-i2c-read opens a websocket to Signal K and continuously sends updates, but never reads from the websocket (recv() is never called).

The hypothesis was:

Signal K still sends websocket frames/keepalive data
the client never drains incoming data
Recv-Q grows
websocket eventually breaks (Broken pipe)
publishing loop freezes temporarily

Workaround:
after each ws.send(...), drain pending websocket frames with a short non-blocking recv() loop.

Patched file:
/usr/lib/python3/dist-packages/openplotterI2c/openplotterI2cRead.py

Added immediately after ws.send(...):

try:
ws.settimeout(0.01)
while True:
ws.recv()
except Exception:
pass
finally:
try:
ws.settimeout(None)
except Exception:
pass

Results so far:

freezes disappeared
no more Broken pipe
websocket Recv-Q stays stable

----
I do not fully understand the internal websocket logic, so this may not be the cleanest fix, but the workaround appears effective and reproducible.

I hope this may help someone else investigating similar random freezes/issues.

RE: Periodic Signal K sensor freeze - kevin@stlaurent.us - 2026-06-05

I am also having issues with the periodic Freeze.
Working with Chat GPT, here is as summary of what was found:

OpenPlotter / pypilot Attitude Data Freezing Every ~90 Seconds
System
• Raspberry Pi 5 8GB
• OpenPlotter 5.14.1
• openplotter-pypilot 4.0.11-beta
• pypilot 0.56
• Signal K running locally on port 3000
• BMP280 I2C sensor installed
• Simrad GO9 and NMEA2000 network connected
Problem
The vessel attitude data (roll, pitch, yaw/heading) would update normally for approximately 55 seconds and then freeze for approximately 35 seconds. This cycle repeated consistently.
Symptoms included:
• Signal K dashboards freezing.
• KIP dashboards freezing.
• Course-up displays becoming unusable due to periodic attitude loss.
• Signal K attitude timestamps stopping during the freeze.
• Data would resume immediately after restarting the OpenPlotter pypilot bridge service.
Findings
pypilot IMU continued running normally
During the freeze, pypilot_client continued to show live updates:
• Heading changing normally.
• Roll and pitch changing normally.
• IMU frequency remained around 20 Hz.
• No IMU warnings or errors.
This indicates the IMU and pypilot itself were not freezing.
Signal K attitude timestamps froze
During the freeze:
curl -s localhost:3000/signalk/v1/api/vessels/self/navigation/attitude
returned the same timestamp repeatedly.
Example:
{
"$source":"pypilot",
"timestamp":"2026-06-04T15:40:05.268Z"
}
Repeated queries during the freeze returned the identical timestamp.
This showed that Signal K was no longer receiving fresh updates from the pypilot bridge.
Restarting the bridge immediately fixed the problem
Running:
sudo systemctl restart openplotter-pypilot-read
immediately restored live attitude updates.
No restart of Signal K, pypilot, or the Raspberry Pi was required.
Signal K itself remained healthy
GPS and other Signal K services continued operating during the freeze.
The issue appeared isolated to the data path between pypilot and Signal K.
Conclusion
The evidence suggests that the openplotter-pypilot-read bridge process enters a stalled state where it stops forwarding updates from pypilot to Signal K.
The IMU continues operating, pypilot continues operating, and Signal K remains running, but attitude updates stop until the bridge service is restarted.
Temporary Workaround
A watchdog script was implemented to monitor:
/signalk/v1/api/vessels/self/navigation/attitude
and automatically restart:
sudo systemctl restart openplotter-pypilot-read
whenever the attitude timestamp stops advancing.
The watchdog runs every 2 seconds and restores updates automatically, preventing long freezes while underway.
Additional Notes
An unrelated issue was also discovered where openplotter-i2c-read had entered a restart loop due to a Python syntax error introduced during troubleshooting. That issue was separate from the pypilot attitude freeze and did not appear to be the root cause of the attitude-data problem.
I am posting this in case other users of OpenPlotter 5.14.1, openplotter-pypilot 4.0.11-beta, and pypilot 0.56 observe similar periodic attitude freezes.

RE: Periodic Signal K sensor freeze - kevin@stlaurent.us - 2026-06-07

Update – Additional Findings
After further troubleshooting, I believe there are actually two separate issues involved.
Issue #1 – Pypilot data freeze (still present)
The original problem remains:

Code:
openplotter-pypilot-read
runs normally for approximately 55 seconds
Data then freezes for approximately 35 seconds
Cycle repeats consistently
Signal K timestamps freeze during the outage
Running:

Code:
sudo systemctl restart openplotter-pypilot-read

immediately restores data
As a temporary workaround I implemented a watchdog that automatically restarts the service when the freeze is detected.
Issue #2 – I2C/BMP280 sensor stopped working
While troubleshooting, I discovered the BMP280 sensor was no longer publishing data to Signal K.
Initial symptoms:

BMP280 configured in OpenPlotter
Sensor visible on I2C address

Code:
0x76
No temperature or pressure data appearing in Signal K
Code:
openplotter-i2c-read
repeatedly exiting and restarting

I eventually found:

Code:
python3

import board

import adafruit_bmp280

failed with:

Code:
AttributeError:

module 'adafruit_platformdetect.constants.chips'

has no attribute 'RP2350'

The system is:

Code:
Raspberry Pi 5 Model B Rev 1.0

Linux 6.12.87+rpt-rpi-2712

OpenPlotter 4

The installed Adafruit libraries appear to be inconsistent:

Code:
Adafruit-Blinka 9.1.0

Adafruit-PlatformDetect 3.81.0

but the PlatformDetect package did not contain the

Code:
RP2350

definition expected by the newer code.
After repairing the Adafruit packages:

Code:
hasattr(chips, "RP2350")

changed from:

Code:
False

to:

Code:
True

and direct BMP280 testing now works:

Code:
OK INIT

T: 28.7 C

P: 989.4 hPa

Current status

BMP280 hardware is confirmed functional.
I2C bus is confirmed functional.
Direct Python access to the BMP280 works.
Signal K still does not show BMP280 data.
Code:
openplotter-i2c-read
still appears not to register itself as a Signal K source.

This may indicate an OpenPlotter I2C service issue on Raspberry Pi 5 / current Bookworm packages.
System information

Code:
Raspberry Pi 5 Model B Rev 1.0

OpenPlotter 4

Kernel:

6.12.87+rpt-rpi-2712

openplotter-pypilot 4.0.11-beta

openplotter-i2c 4.2.0-stable

pypilot 0.56

At this point I am looking for guidance from the developers regarding:

The repeating 55s / 35s pypilot freeze cycle.
Why

Code:
openplotter-i2c-read
is not publishing BMP280 data to Signal K despite the sensor working correctly in Python.

That update is concise, factual, includes the Pi 5 information (which is important), and clearly separates the pypilot freeze from the BMP280 problem so developers don't chase the wrong issue.

Update – Additional Findings (Raspberry Pi 5 / OpenPlotter 4)
I've done some additional troubleshooting and have isolated two separate issues:
1. Signal K / Pypilot Data Freeze
The original symptom remains:

Signal K navigation data freezes after approximately 55 seconds of operation.
Freeze lasts roughly 35 seconds.
During the freeze, Signal K timestamps stop advancing.
OpenCPN course-up display becomes unusable because heading updates stop.
A watchdog script monitoring Signal K data successfully restores operation by restarting the affected process when a freeze is detected.

This workaround has been reliable.

2. I²C Bus Failure After Several Hours
A separate issue appears to affect the Raspberry Pi 5 I²C subsystem.
System:

Raspberry Pi 5 Model B Rev 1.0
OpenPlotter 4
BMP280 at address 0x76
IMU at address 0x68

After a cold boot:

Code:
sudo i2cdetect -y 1

shows:

Code:
68

76

and both sensors function normally.
After several hours of operation:

Code:
sudo i2cdetect -y 1

shows no devices at all.
Direct reads fail:

Code:
sudo i2cget -y 1 0x68 0x75

Error: Read failed

sudo i2cget -y 1 0x76 0xD0

Error: Read failed

Kernel log repeatedly reports:

Code:
i2c_designware 1f00074000.i2c:

i2c_dw_handle_tx_abort: lost arbitration

Recovery Attempts Tested
None of the following restore the sensors:

Code:
systemctl restart openplotter-i2c-read

Code:
modprobe -r i2c_dev

modprobe i2c_dev

Code:
rmmod i2c_designware_platform

modprobe i2c_designware_platform

After these actions:

Code:
i2cdetect -y 1

still shows no devices.

GPIO State During Failure
During the failure:

Code:
pinctrl get 2

GPIO2 = SDA1 = hi

pinctrl get 3

GPIO3 = SCL1 = hi

Both lines remain high, suggesting the bus is not being physically held low by a device.

Only Recovery Found
The only successful recovery method is a complete cold power cycle of the Raspberry Pi.
After a cold power cycle:

Code:
sudo i2cdetect -y 1

again shows:

Code:
68

76

and sensor communication returns.

Additional Notes
The BMP280 hardware itself appears functional:

Code:
import board

import adafruit_bmp280

i2c = board.I2C()

bmp = adafruit_bmp280.Adafruit_BMP280_I2C(i2c,address=0x76)

print(bmp.temperature)

print(bmp.pressure)

returns valid readings.
The BMP280 was also temporarily affected by an Adafruit Blinka / PlatformDetect incompatibility on the Pi 5, which was corrected by updating the Adafruit packages.

Current Conclusion
At this point the evidence suggests:

A Signal K / Pypilot freeze issue (workaround available via watchdog).
A separate I²C stability issue on Raspberry Pi 5 where the entire I²C bus eventually becomes inaccessible.
Repeated kernel "lost arbitration" errors precede or accompany the I²C failure.
Only a full power cycle restores the bus.

I'm interested to know if other Raspberry Pi 5 OpenPlotter users have seen similar I²C behavior, especially with BMP280 and IMU devices connected to bus 1.