Periodic Signal K sensor freeze

[Spark]

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.

[Spark]

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.

[kevin@stlaurent.us]

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.

[kevin@stlaurent.us]

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:

1. The repeating 55s / 35s pypilot freeze cycle.
   
2. 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:

1. A Signal K / Pypilot freeze issue (workaround available via watchdog).
   
2. A separate I²C stability issue on Raspberry Pi 5 where the entire I²C bus eventually becomes inaccessible.
   
3. Repeated kernel "lost arbitration" errors precede or accompany the I²C failure.
   
4. 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.