The critical-shutdown path in bwm_lowbatt_check() was reached whenever the
AW32001 System Status "power good" bit was clear. On this hardware that bit reads
"power fail" even while the board is USB-powered under HF load (hw status shows
power fail + ~400 mA discharge on PC USB), so a low pack could trip the latched
power-off - Gpio_ARM_Power_ON_Low() + while(1) - while USB keeps the MCU alive,
leaving it spinning.
Confirm the cable really is out via the dedicated VUSB sense pin (Gpio_VUSB_Read,
the same source WITH_PM5_AUTOOFF uses) before powering off; if USB is present,
clear the streak and keep running. Also print a reason before cut-off, and fix a
brace/formatting glitch on the trigger condition.
The idle-loop low-battery poll bwm_lowbatt_check() reads the BWM charger/gauge
over the bit-banged I2C, which busy-waits on the TMR5 free-running counter via
WaitUS()/WaitTicks(). A command handler that runs just before the poll can leave
TMR5 stopped through StopTicks() - notably the LEGIC probe in `hf search`
(LegicRfInfo() ends with switch_off(); StopTicks()). WaitTicks() then spins in
`while (GetTicks() < ticks)` forever and the device appears to hang, needing a
manual power-cycle, because WDT_HIT() is a no-op on AT32.
This became reachable by default at d35ddce2 (PM5 gained -DWITH_BWM_LOWBATT_BEEP).
The previous idle-loop I2C user, the power LED, was unaffected because RgbLedSet()
calls StartTicks() first. Do the same in the poll.
Both psk3 entries run the same demodulation as the psk2 entry beside them and
differ only in the constant given to test(). test() accepts a word only when
that word's own modulation field matches the constant, so the psk3 entry needs
a recovered word whose field reads 3.
Field 3 is 00011, so it needs two adjacent 1's. What this demodulation recovers
is the data's rising edges, and a rising edge needs a 0 before the 1, so no two
of them are ever adjacent. The words it produces can never carry field 3, and so
the psk3 entries can never match the case they were written for.
What they can do, however, is match on a demodulation error, and then detect
names psk3 and a block 0 word the tag does not hold.
psk3 is still reached, by ruling psk2 out from the broadcast period rather
than by demodulating for it - see t55xx_psk3_resolve().
Tags that only these branches matched now read as psk2, or as undetected
where no offset yields a plausible psk2 word, on the basis that a wrong
answer is worse than none if nothing about it tells you it is wrong.
Edited by a human.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The client demodulates psk2 and psk3 the same way, and against a psk3 tag
that demodulation keeps only the leading bit of every run of ones. A psk3
config word therefore always reads back as its psk2 neighbour, one bit out,
and detect structurally cannot tell the two apart from the waveform alone.
It said psk2 anyway. Worse, the data-block probe meant to settle it
confidently answered psk3 even for a freshly wiped psk2 tag, where a page
of zeroes has no adjacent ones under either modulation.
Report what is actually known:
- print "PSK2 or PSK3 ( ambiguous )" when the read fits both
- list the words block 0 could be, rather than printing one and relegating
the rest to a note
- weight the probe's evidence, so empty blocks settle nothing
- narrow that list with things the tag cannot hide - the subcarrier it
transmits on, and how many blocks it broadcasts, which constrains MAXBLK and
also rules out the sequence terminator
Where that leaves one word, block 0 reports it. Where it does not, detect
says so rather than choosing.
Edited by a human.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
9303 Part 4, positions 29 to 42: "Any special characters, including spaces,
in the personal identification number ... shall be replaced by the filler
character (<). The number shall be followed by the filler character (<)
repeated up to position 42."
So the field holds two different kinds of filler. The trailing run is
padding, which was already stripped, but a filler inside the number stands
for a space or special character substituted on the way in, and those were
printed as they came - a US passport showed its personal number with a '<'
in the middle of it.
Strip the padding, then put a space back for what remains. It is the
closest recovery available: the original could have been a hyphen, and the
MRZ does not keep which.
optional_data itself stays a faithful copy of the field. Nothing else
reads it, and it is the personal number that is being rendered here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ICAO spills a document number longer than nine characters into the
optional-data field: positions 1 to 9 hold the first nine, position 10 a
filler in place of the check digit, and the optional field opens with the
rest of the number and the check digit for the whole of it.
_extended_document_number() already puts that back together and returns
the optional field with the overflow removed. _parse_td3() bound that
fourth value and then ignored it, re-slicing l2[28:42] raw, so the tail of
the document number stayed in the optional field. From there it was
reported as the holder's personal number, which falls back to the MRZ
optional-data field when DG11 carries none - a 12-character number showed
its last three digits and a check digit as a personal number.
Use the value the function already returns. The check digit still answers
for the field as transmitted, overflow included, since that is what the
MRZ actually carries.
_parse_td1() has always used the return value, which is where the intended
shape comes from. _parse_td2() does not call the helper at all, so TD2
carries no support for long numbers; that is a gap rather than this bug and
is left alone.
Found while checking the decoder against ICAO 9303 Part 4. Nothing else
came out of that: the composite check digit covers lower-line positions
1-10, 14-20 and 22-43 as the spec requires, verified by mutating all 43 and
confirming that nationality and sex are ignored and every other position is
caught; the 7-3-1 digits agree with an independent implementation across
four real TD3 documents.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The tab headers carried their file names as fixed text - "Additional
personal details · EF_DG11" - so a Polish passport, which ships DG13 and
no DG11, was told its details came from a file it does not carry. The
ISSUER header claimed EF_DG12 on the same document, and SECURITY listed
EF_DG15 whether or not it was there.
personal_files, document_files and security_files report what each tab drew
from, and the pages compose their header from those. They sit on the
record rather than in the widgets so they can be tested without a display,
which is how the rest of the suite is built.
PERSONAL names EF_DG1 when the personal number came from the MRZ, that
being the file which supplied it, rather than crediting DG11 for a value
DG11 did not provide. With nothing read the header stays the bare
description: the record is an empty PassportRecord at startup rather than
None, and reporting an absence on a chip nobody read reads as a fault.
"none present" rather than "nothing on this chip", since the app opens
offline dumps too.
The same document showed the other half of this: "Personal number (from
DG13)" renders 203px against a dp(190) caption column, so it wrapped and
left the source on a line of its own. Without the "from" it is 167px.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"Personal number (from DG13)" renders 203px wide and the caption column is
dp(190), so it wrapped and left the source sitting on a line of its own.
Without the "from" it comes to 167px and fits, with room to spare over the
140px of the longest caption already in that tab.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Kivy's stock disabled button texture is pale at the edges and dark in the
middle. Stretched across a wide button the edges stay put and the middle
grows, so it reads as three vertical bands with the label sitting on the
dark one and disappearing - "Delete dump" is unreadable at startup, where
it is disabled because no dump is loaded yet.
Keep the normal background for the disabled state and let the dimmed label
carry it instead. The text goes to 45% rather than Kivy's 30%, which is
faint on that grey.
Applied as a Button rule because nine buttons across the app bind
disabled: Export, Open folder, the camera button, Samples, the bin button
and the rest all band the same way. The one button that sets its own
transparent background stays transparent, since background_color
multiplies the texture.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A Polish passport carries EF_DG13 and no EF_DG11, so the PERSONAL tab had
nothing to show and the data page fell back to "not on chip", even though
the document does carry a personal number.
DG13 is optional details and ICAO assigns it no meaning, so parse_dg13()
reads it as tagged values and names none of them. The 5C tag list is
skipped: it enumerates what follows rather than being a field itself.
Poland is the one case worth naming. It puts the PESEL, its national
identity number, in tag 5F70, and is_pesel() checks the length and the
check digit - DG13 being issuer-defined, the checksum is what separates a
PESEL from eleven digits that happen to share a tag. That is applied only
when the MRZ nationality is POL, so the same tag on another state's
document is carried but not claimed as a personal number.
It slots in behind the two sources personal_number already had, which its
docstring anticipated: DG11, then the MRZ optional-data field, then this.
personal_number_source reports DG13 so the PERSONAL tab and the data page
can say where the value came from rather than implying DG11.
Confirmed against a Polish passport: the 11 digits validate as a PESEL,
their first six match the MRZ date of birth under PESEL's century-offset
month encoding, and the gender digit agrees with the MRZ sex field. The
two US documents to hand are unaffected - they keep taking the number from
the MRZ - and a document with none of the three shows no row, as before.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Niel Nielsen