1ad123a6f84ef87dba3de338c051303009d89124
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Ashin Walpola
|
1ad123a6f8 |
Make the event detector a CAM rate input, not a ride-stats readout
The detector's only live consumer is the CAM transmit-rate policy: every emitted event calls CamTransmitLoop.onDetectedEvent, raising the beacon rate from 1 Hz to the elevated rate for five seconds so nearby stations get denser updates through a manoeuvre. Counting one's own braking events is not a goal of this project, so the display is gone and the detector stays: the live per-type counters and their notification text, the event pins and detail sheet on the trip review map, and the event chip on the history card. Events are still persisted and exported to CSV, which is the only route to the tuning measurement section 11.3 says is missing. Fix two defects found while documenting the detector. TripRecordingService overrode nine of DetectionConfig's twelve parameters in its constructor, so the tests validated the Phase A defaults while the phone ran something materially less sensitive. The tuned values are now the defaults and the override is deleted; the numbers moved location, not value, so detector sensitivity is unchanged. EventDetectorTest now sets only windowSize and the sustained-frame counts and inherits every signal threshold, which cannot drift again. That was not a free change and makes the same point from the other side: at the real thresholds the old stimuli triggered nothing. Accel alternating 3.5/0.5 gives a std dev of 1.5 and never clears 1.8, and the moderate-braking case used a 0.8 m/s drop that never clears 1.0. Those stimuli are re-derived against the real values. brakingHighConfidenceRate was documented as a rate but has always been compared against the peak cumulative drop from the onset speed, which grows with episode length, so HIGH was assigned more readily than the name implied. Renamed to brakingHighConfidencePeakDrop rather than changing the comparison: "lost more than 1.5 m/s in one episode" is coherent, whereas a rate off a 1 Hz speed signal sampled at 50 Hz spikes on a near-zero divisor early in an episode. Output is unchanged, so the existing confidence assertions stay evidence instead of being re-baselined. Docs 11.3/11.4 updated in place, including the correction of a claim that detected events do not reach the V2X side; the rate-bump path already existed when that was written. 55 tests, 0 failures. |
||
|
Ashin Walpola
|
312f094909 |
Save the Word-edited copies of both documents
Both files were opened and edited in Word and are re-saved here as the
authoritative versions. They supersede the generated originals from
|
||
|
Ashin Walpola
|
16998bf478 |
Add the user guide and technical documentation as Word documents
Two documents, wiki-style so they import cleanly: short titled sections, tables over prose where the content is comparative, and cross-references between sections rather than a narrative that has to be read start to end. MicrOBU-User-Guide.docx is for riders. Features, setup for both hardware paths, what each screen shows, what the five alerts mean in plain language, troubleshooting. No ASN.1, no BTP ports, no bit widths anywhere in it. The alert descriptions and the link states are taken from values/strings.xml so the guide and the interface use the same words. MicrOBU-Technical-Documentation.docx is for supervisors and stakeholders. Architecture, the message path end to end, the serial protocol, the codecs and how they are verified, the full requirements matrix, the bench results, and the decisions. Section 15 is fourteen decisions written as chosen / alternative / reasoning / cost accepted, because the alternative is the part a supervisor asks about and it was previously recorded only in commit messages. Nothing is re-derived. Every measurement is cited from 05-obu-bench-test-2026-08-25.md, 04-transmit-setup.md, asn1/README.md or the commit history. Where a claim has no evidence it is marked as unverified rather than asserted: - 11.6 Phase A success criteria is stated as not met, in its own subsection. The bench proves reception; it cannot prove the use case with two moving stations because nothing on the bench moves. This is the central claim of the project and it needs a real ride. - The tx_custom.c bypass is described as the least defensible component in the system and load bearing, with the reverse-engineered struct layouts and the skipped sanity checking spelled out. - The 5900 MHz transmit story is marked a mitigation for a hypothesis, not a diagnosis, and the isolation test that would settle it is named as not run. - The detection thresholds are presented as untuned engineering estimates in both documents, since presenting them as validated is the easiest and most damaging overstatement available here. Twenty image placeholders, none of them filled. Each is a shaded block carrying a caption and a "Must show" line. For the three screenshots that exist the line names the bench session and section they came from; for the four diagrams that do not exist yet it is a full drawing spec, so the two hardware paths, the message path, the frame layout and the verification loop can be drawn from the document without re-reading the source. references.bib collects the standards as BibTeX for a later publication: EN 302 637-2/3, TS 103 301, SAE J2735, TS 102 894-2, EN 302 636-4-1 and -5-1, TS 103 248, TS 103 097, IEEE 802.11 OCB, plus the C2C-CC white paper and the vendored parser provenance. Also tracks two documents the new ones cite that had never been committed: docs/01-requirements-traceability.md and 04-transmit-setup.md. Section 18.3 lists them as repository sources, which would have been a dangling reference otherwise. Not included, deliberately: the two consider it PDFs cited in section 18.2. They are third-party vendor documentation and redistributing them is a licensing decision, not a documentation one. Still missing: the German user guide. values-de/strings.xml already fixes the terminology for it. |