- Split RX registries into more plugins: AM, AM VAG, FM, FM F4, and FM Honda1
- Add per-protocol TX plugins so emulation loads only the selected encoder
- Sub Decode (enabled by default) and Timing Tuner as plugins
- Max history increased to 20 signals
- Fix Sub Decode and simplified UI
- Add Check Saved setting ported from dexter_pester PR !
- Fix Fiat V1 decoder and add HITAG2 key TX support
- Add Renault V0, Fiat V2, Honda V2, Ford V3 (& US variant) Thanks Ash
Sorry this is a lot at once x)
KIA V2 uses Manchester encoding and was historically decoded successfully
under ASK presets. The recent AM/FM plugin split placed it in the FM
registry based on its flag, but real-world KIA V2 fobs operate on ASK.
Changes:
- protocols/kia_v2.c: SubGhzProtocolFlag_FM -> SubGhzProtocolFlag_AM
- protopirate_fm_plugin.c: remove kia_v2 include and registry entry
- protopirate_am_plugin.c: add kia_v2 include and registry entry
- application.fam: move kia_v2.c source from FM plugin to AM plugin
Fix KIA V5 encoder and KIA V3/4 encoder (CRC bruteforce...)
Add support for Ford V1 different fobs (no decryption yet) (Jaguar, Landrover, Range Rover 2018)
Add Ford V3 decoder (no decryption yet) (Ford Focus/Ranger 2020)
Thanks to Ash for thoses last two :)
More shared helpers in protocols_commons
Storage and history improvements
Add Chrysler V0, Ford V2 (simple replay encoder), Land Rover V0
Fix Fiat V0, Subaru & Kia V5
- Defer radio init until first use
- Add shared radio helpers
- Reduce PROTOPIRATE_HISTORY_MAX to 10
- Lazy allocate scenes/widgets/receiver on enter
- Lint & format
- prune protocol registry based on user selected preset
- add OOM guard for history with RAM! low-memory state
- free TX on stop
- add long press right to delete signal in history
This removes the hacky code that fixed the Panic, and Sets the Button Codes to what they would actually be to Ford.
No button code should equal zero, that would mean NO button! It also fixes the overflow problem on the counter, so I think this is a better reference implementation.
The CRC is only wrong on valid captures because the high bit is sometimes not needing be be XORed with 0x80
This fix is technically not correct, but good for real world use.
We could still have a BAD CRC listed as OK, but this would be very unlikely to happen in the wild for a valid capture, amd only happen for 1/255 possible CRCs
I have made it so we only check the lower 7 bits of CRC, and return OK if they are all correct.
0mega