Reported in the attached raw text,
issue-request-raw.txt
the issue here is that the NMEA-0183 logger, if it receives a bad character on the serial line while expecting the leading "$" of a NMEA sentence, writes a message to the special syslog file. This was originally something done for debugging, but in practice it now means that there is a potentially significant delay on every bad character; on a noisy receiver line where bad characters are common, this could stall the firmware's run-loop sufficiently to cause knock-on effects (induced latency in logging, missing HTTP requests, etc.) And that's bad.
The suggested solution is to count the number of bad start characters, and only report the number if a sufficient amount of time has passed. This would be less useful for debugging, but would make sure that the fact of bad input was recorded somewhere to be diagnostic when the data is transferred to the outside world.
So:
- Add a counter for the number of bad characters and increment on each event.
- Report the count at a fixed interval (once every 5-10 seconds is probably fine), and reset the count.
- Ensure that syslog messages are only issued if debugging is turned on (currently happens if there is a logManager available)
- Consider rationalising the things that are recorded into the syslog by the system: it's intended for important events that we want to preserve for the longer term, but is currently only used for a very limited number of messages. It would be better, for example, to include upload errors, when files are transferred and removed, etc.
(Note in passing: the raw request appears to have been generated with an agentic coding assistant's analysis of the problem. It appears to have had context for only the code, and therefore doesn't recognise that the RS-422 of NMEA-0183 is externally converted to unipolar serial by the rest of the hardware; that the SD is connected by high-speed SDMMC rather than SPI; and it doesn't realise that flushing the output buffers after every syslog write is intentional in a system where the power could go off at any time. So the analysis isn't quite correct, but the solution is still useful as a precaution, an interesting result.)
Reported in the attached raw text,
issue-request-raw.txt
the issue here is that the NMEA-0183 logger, if it receives a bad character on the serial line while expecting the leading "$" of a NMEA sentence, writes a message to the special syslog file. This was originally something done for debugging, but in practice it now means that there is a potentially significant delay on every bad character; on a noisy receiver line where bad characters are common, this could stall the firmware's run-loop sufficiently to cause knock-on effects (induced latency in logging, missing HTTP requests, etc.) And that's bad.
The suggested solution is to count the number of bad start characters, and only report the number if a sufficient amount of time has passed. This would be less useful for debugging, but would make sure that the fact of bad input was recorded somewhere to be diagnostic when the data is transferred to the outside world.
So:
(Note in passing: the raw request appears to have been generated with an agentic coding assistant's analysis of the problem. It appears to have had context for only the code, and therefore doesn't recognise that the RS-422 of NMEA-0183 is externally converted to unipolar serial by the rest of the hardware; that the SD is connected by high-speed SDMMC rather than SPI; and it doesn't realise that flushing the output buffers after every syslog write is intentional in a system where the power could go off at any time. So the analysis isn't quite correct, but the solution is still useful as a precaution, an interesting result.)