Flush above-threshold event buffer early instead of waiting out the interval - #16
Merged
Merged
Conversation
4 tasks
kaklik
changed the base branch from
kaklik-firmware_documentation
to
AIRDOS03B
September 6, 2026 09:54
…nterval A check-source or high-altitude burst can fill the 300-slot event buffer well before the 10 s DataOut() tick, after which every above-threshold event for the rest of the interval was silently discarded while channels below THRESHOLD kept being recorded — producing a step discontinuity in the spectrum exactly at the histogram/event boundary (channel 63/64). - Raise MAX_EVENTS 300 -> 1000: sized against the ATmega1284P's 16 KB SRAM (measured 30.5%/31.9% RAM usage after the change), extending the loss-free rate from 30 Hz to 100 Hz sustained per 10 s interval. - Extract the interval-flush logic into a shared static inline flushDataOut(), called both on the normal 10 s tick and immediately from loop() once events_counter reaches MAX_EVENTS, so a full buffer starts a fresh (shorter) interval instead of sitting idle dropping events for the remainder of the old one. inline keeps this on the hot loop() path without added call overhead/dead time. The resulting variable interval length is recoverable downstream: $STOP carries both the GNSS-synced absolute timestamp (tm.tm_s100) and the raw TCNT1 tick pair (captStart/stopSystime), either of which gives the exact duration of that specific interval. dosview has been updated separately to use this and to warn when it detects buffer truncation.
kaklik
force-pushed
the
feature/event-buffer-overflow-handling
branch
from
September 6, 2026 11:01
2bfe14c to
abd51b8
Compare
Upload commands were missing -e TFUNIPAYLOAD01_uart, causing PlatformIO to also touch the ISP environment. The CTS-reset comment was also misleading: verified via strace that avrdude's arduino protocol toggles DTR/RTS on the host serial port, not CTS directly — the TFUSBSERIAL01 adapter wires its RTS output to the board's CTS pin, which is what triggers the bootloader reset.
ustbot
added a commit
that referenced
this pull request
Sep 6, 2026
…vent-buffer-overflow-handling, extended build
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #15
Summary
MAX_EVENTS300 -> 1000 in both firmware variants (AIRDOS03_USTDFF, AIRDOS03_MAVLink), sized against the ATmega1284P's 16 KB SRAM (verified 30.5%/31.9% RAM usage after the change).static inline flushDataOut(), called both on the normal 10 s tick and immediately fromloop()onceevents_counterreachesMAX_EVENTS, so a full above-threshold event buffer starts a fresh (shorter) interval instead of silently discarding events for the remainder of the old one.This fixes the spectrum discontinuity at channel 64 reported in #15 (observed live in dosview, tested with an Am241 source): under high count rate, the 300-event cap was reached well before the 10 s
DataOut()tick, after which every above-threshold event for the rest of the interval was dropped while channels below THRESHOLD kept being recorded — producing the "spectrum doesn't connect at channel 64" artifact.The resulting variable interval length is recoverable downstream from either the GNSS-synced
$STOPtimestamp or the raw TCNT1 tick pair (captStart/stopSystime) already present in every record. dosview has been updated separately in UniversalScientificTechnologies/dosview#17 to use this and to warn when it detects buffer truncation.Test plan
pio runbuilds clean for bothAIRDOS03_USTDFF(TFUNIPAYLOAD01_uart) andAIRDOS03_MAVLink(TFUNIPAYLOAD01_isp) environments.pio run -t size.