9699a6cd04ce724a70f52aaddce3767cd62bb504
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Ashin Walpola
|
5ec3619cbe |
Stop retaining detected manoeuvres; the CAM rate bump is their only consumer
The detector runs to raise the CAM transmit rate through a manoeuvre. Nothing else read its output once the UI was removed, so keeping the rows was storing data with no reader on the chance it would one day be analysed. Drops the detected_events table in schema v5, deletes DetectedEventEntity and the DAO and repository methods behind it, removes the insertEvent call from the recording service, and removes the per-event rows and their five columns (event_type, confidence, peak_accel, peak_gyro, duration_ms) from the trip CSV along with the events parameter threaded through buildTripCsv and shareTripCsv. A detected manoeuvre now lives for the length of one onDetectedEvent call. MIGRATION_1_2 still creates the table: a v1 install upgrades 1-2-3-4-5 and so creates it before v5 drops it. Removing it from the earlier migration would break that path for anyone who has not upgraded yet. trips.eventCount is kept. Dropping a SQLite column means recreating the table and copying every recorded ride across, which is real risk for one unused integer; the service still writes an accurate count and the CSV header still reports it. It is the only thing left about detected manoeuvres. This closes off the route to the false-positive measurement that 11.3 flags as missing, so 11.3 now says that outright rather than pointing at an export that no longer carries the data. Docs 11.3/11.4, the user guide, the README and the traceability matrix updated to match. 55 tests, 0 failures. |
||
|
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
|
83ccf335bb |
Document the event detector's specification and trigger conditions
Section 11 described how the detector works and the test-design finding from
2026-08-25, but carried no threshold values, no trigger conditions and no
emission semantics. That was inconsistent with section 10.4, which tabulates
all nineteen UseCaseDetectionConfig parameters for the V2X side. Adds 11.3 and
11.4 to close the gap.
11.3 tabulates all twelve DetectionConfig parameters in three columns, because
three different configurations exist and they do not agree. DetectionConfig's
KDoc says its defaults match the Phase A specification; TripRecordingService
overrides nine of the twelve when it constructs the detector, every one of them
in the direction of lower sensitivity. The shipping detector is not the
specified detector, and that was recorded nowhere outside a constructor.
11.4 gives the input rates, the qualifying condition for each of the three
event types, when each emits, and how confidence is assigned. It also explains
why braking compares against a reference speed latched at onset rather than a
per-frame delta: GNSS updates at 1 Hz against a 50 Hz detector, so a per-frame
delta is non-zero on one frame in fifty and could never coincide with a
25-frame sustain requirement. That is the same sampling lag that made four
tests unsatisfiable, seen from the implementation side.
Two discrepancies found while writing this are recorded rather than fixed,
since fixing either changes behaviour and belongs in its own change:
- EventDetectorTest states it keeps production thresholds for all signal
values. The values it keeps are the DetectionConfig defaults, not the ones
TripRecordingService runs. All 18 tests validate a configuration that never
executes on a phone. The logic under test is shared, so they remain valid
logic tests; they are not evidence about the shipped system.
- brakingHighConfidenceRate is documented as a rate in m/s per GNSS update but
is compared against the peak cumulative drop from the onset reference, which
is not a rate and grows with episode length. HIGH confidence is therefore
assigned more readily than the name implies.
Also notes the emission asymmetry: turning and stopping emit once per episode,
braking re-arms and re-fires roughly every half second at the shipping values.
Edited in place through the existing package rather than regenerated, so Word's
own parts and the manual edits from
|
||
|
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. |