You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RP2040-LORA-HF device is ignoring request to set INA219 as main battery device.
Continuously reports as PWD status at 0.0V despite being configured to read INA.
Occurring on 2.5.7 and 2.5.8 (downgraded back to 2.5.7 so I could increase cadence of power metrics transmit while testing.)
INA is being correctly recognised at 0x40 address on boot:
INFO | ??:??:?? 3 Scanning for i2c devices...
DEBUG | ??:??:?? 3 Scanning for I2C devices on port 1
DEBUG | ??:??:?? 3 I2C device found at address 0x40
DEBUG | ??:??:?? 3 Wire.available() = 2
DEBUG | ??:??:?? 3 Register MFG_UID: 0x2000
INFO | ??:??:?? 3 INA219 sensor found at address 0x40
DEBUG | ??:??:?? 3 I2C device found at address 0x76
DEBUG | ??:??:?? 3 Wire.available() = 1
DEBUG | ??:??:?? 3 Wire.available() = 1
INFO | ??:??:?? 3 BMP-280 sensor found at address 0x76
INFO | ??:??:?? 3 2 I2C devices found
DEBUG | ??:??:?? 3 acc_info = 0
DEBUG | ??:??:?? 3 found i2c sensor meshtastic_TelemetrySensorType_BMP280
DEBUG | ??:??:?? 3 found i2c sensor meshtastic_TelemetrySensorType_INA219
INFO | ??:??:?? 3 S:B:30,2.5.7.f77c87d
INFO | ??:??:?? 3 Build timestamp: 1729118132
However, the telemetry/update module is still reporting:
When a remote request is placed from another node the same results occur:
meshtastic -s com11 --dest [redacted] --request-telemetry
Connected to radio
Sending device_metrics telemetry request to [redacted] on channelIndex:0 (this could take a while)
Telemetry received:
Battery level: 101.00%
Voltage: 0.00 V
Total channel utilization: 10.90%
Transmit air utilization: 0.06%
Uptime: 5 s
When power stats are explicitly requested, the correct data returns:
meshtastic -s com11 --dest [redacted] --request-telemetry
Connected to radio
Sending device_metrics telemetry request to [redacted] on channelIndex:0 (this could take a while)
Telemetry received:
Battery level: 101.00%
Voltage: 0.00 V
Total channel utilization: 17.88%
Transmit air utilization: 0.99%
Uptime: 769 s
meshtastic -s com11 --dest [redacted] --request-telemetry power
Connected to radio
Sending power_metrics telemetry request to [redacted] on channelIndex:0 (this could take a while)
Telemetry received:
powerMetrics:
ch3Voltage: 4.772
ch3Current: -0.4
However I have noticed that there appears to be a bug in the INA read - it is marking the single channel device as returning data on channel 3, I do not know if this is relevant or a red herring:
I'm using multiples rp2040 with ina219. In order to have the ina reading as battery state, I have to define BATTERY_PIN (I put 26 even if I do not use it) and BATTERY_SENSE_RESOLUTION_BITS 12. in the variant header and compile.
These defines enable portions of code for battery monitoring, and the use of INA219 instead if present.
I think it should be possible to use ina219 without this trick, but I did not want to change too much code for that. To consider maybe ?
P.S. the channel 3 is not a problem at all. It will use the first valid value, so channel 3 it is. It works fine.
Category
Other
Hardware
Other
Firmware Version
2.5.7.f77c87d
Description
RP2040-LORA-HF device is ignoring request to set INA219 as main battery device.
Continuously reports as PWD status at 0.0V despite being configured to read INA.
Occurring on 2.5.7 and 2.5.8 (downgraded back to 2.5.7 so I could increase cadence of power metrics transmit while testing.)
INA is being correctly recognised at 0x40 address on boot:
However, the telemetry/update module is still reporting:
When a remote request is placed from another node the same results occur:
When power stats are explicitly requested, the correct data returns:
However I have noticed that there appears to be a bug in the INA read - it is marking the single channel device as returning data on channel 3, I do not know if this is relevant or a red herring:
Power configuration is correctly set (I think?) to INA address of 64 (or 0x40):
Relevant log output
No response
The text was updated successfully, but these errors were encountered: