Periodic Signal K sensor freeze

[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.