11-12-2024, 09:21 PM
Whenever I hear of "No temperature sensor" or comms issues, my immediate suspicion is EMI from some other device.
Cheap Chinese battery chargers are notorious for having their mains input input EMI suppression components deliberately left out, replaced with wire links.
These components are meant to stop switching hash from the switch-mode supply's action re-emerging on the mains wiring, from where it can radiate widespread.
The EMI permeates the digital communications to the DS18B20, or ECU, leading to corrupted data and CRC errors.
So, it's "been off for a while", but has anything new been added otherwise, unrelated to the Afterburner is my first question...?
The issue of syslog has been brought up in the past, but sadly such things rely on lots of things working correctly in the first instance.
Even the web logging is "mickey mouse" as to record to a file relies upon the browser being enabled with an experimental flag to allow local file system writing.
Web pages normally do run in a sandbox, with no access to the host's file system for write access (outside of usual HTTP file GET).
Telnet can be used to gather logs, but things like system errors from IDF kernel code may not appear.
Arduino libraries can, via a Serial redirect I devised to allow that to happen.
The most reliable method is a direct serial debug connection to the debug port. All possible debug information appears that way.
The only reason why the web page logging was added was a side effect of providing debug menu access via the web page.
But as mentioned the available logging is not that fantastic, and telnet is still better for achieving that.
The other gremlin with time is connections oxidising, and causing higher resistance connections than normal.
This normally manifests as a constant boot loop, as voltage drops when wifi is started trigger a brownout reboot.
Usually the act of unplugging/re-plugging every connection a couple of time on the heater's controller leg is sufficient to scrape clean metal back.
ie JST plug at AB, 3 pin OEM controller plug, main ECU 9 pin plug.
Cheap Chinese battery chargers are notorious for having their mains input input EMI suppression components deliberately left out, replaced with wire links.
These components are meant to stop switching hash from the switch-mode supply's action re-emerging on the mains wiring, from where it can radiate widespread.
The EMI permeates the digital communications to the DS18B20, or ECU, leading to corrupted data and CRC errors.
So, it's "been off for a while", but has anything new been added otherwise, unrelated to the Afterburner is my first question...?
The issue of syslog has been brought up in the past, but sadly such things rely on lots of things working correctly in the first instance.
Even the web logging is "mickey mouse" as to record to a file relies upon the browser being enabled with an experimental flag to allow local file system writing.
Web pages normally do run in a sandbox, with no access to the host's file system for write access (outside of usual HTTP file GET).
Telnet can be used to gather logs, but things like system errors from IDF kernel code may not appear.
Arduino libraries can, via a Serial redirect I devised to allow that to happen.
The most reliable method is a direct serial debug connection to the debug port. All possible debug information appears that way.
The only reason why the web page logging was added was a side effect of providing debug menu access via the web page.
But as mentioned the available logging is not that fantastic, and telnet is still better for achieving that.
The other gremlin with time is connections oxidising, and causing higher resistance connections than normal.
This normally manifests as a constant boot loop, as voltage drops when wifi is started trigger a brownout reboot.
Usually the act of unplugging/re-plugging every connection a couple of time on the heater's controller leg is sufficient to scrape clean metal back.
ie JST plug at AB, 3 pin OEM controller plug, main ECU 9 pin plug.