Problem
CHIRP import/export shipped in #103 and model-only round-trip landed in #110. CTCSS tones round-trip via Tone / TSQL + rToneFreq / cToneFreq → internal Channel.rxTone / Channel.txTone.
DCS is not wired through the boundary. Today:
| CHIRP column |
Import |
Export |
DtcsCode |
ignored |
constant 023 |
DtcsPolarity |
ignored |
constant NN |
RxDtcsCode |
ignored |
constant 023 |
CrossMode |
ignored |
constant Tone->Tone |
parseChirpTones() only handles Tone and TSQL CTCSS modes. formatChirpToneFreq() maps DCS-shaped internal values (D023N, …) back to the CTCSS default 88.5 on export.
Committed test-data/chirp/ fixtures use CTCSS only — no DCS regression coverage.
The internal model already supports DCS (ChannelTone = CTCSS Hz or D023N-style codes; see src/lib/channelFields/tones.ts, OpenGD77 RX Tone / TX Tone mapping). The gap is CHIRP wire encoding, not a new model field.
Intended outcome
Map CHIRP DCS / cross-mode columns ↔ rxTone / txTone at the import/export boundary (no wire stash — same rules as #110).
Import
- Extend
parseChirpTones() (or sibling helpers) to read Tone, DtcsCode, DtcsPolarity, RxDtcsCode, and CrossMode per CHIRP semantics.
- Map to internal
ChannelTone values (e.g. D023N).
- Document supported CHIRP tone modes and lossy edges in
docs/reference/chirp/channels.md.
Export
- Derive
Tone, rToneFreq, cToneFreq, DtcsCode, DtcsPolarity, RxDtcsCode, CrossMode from rxTone / txTone (inverse of import).
- Replace hard-coded constants in
src/lib/export/chirp/channelWire.ts.
- When tones are
none, continue emitting the same constant defaults as today’s CTCSS-only fixtures (023 / NN / Tone->Tone).
Tests
- Add at least one
test-data/chirp/ fixture row (or minimal bundle) exercising DCS and/or cross-mode.
- Unit tests for wire ↔ model mappers; extend round-trip compare if fixture is committed.
References
Out of scope
- New internal model fields (use existing
rxTone / txTone).
wireColumns or other provenance stash for round-trip.
- DMR columns (
URCALL, RPT1CALL, …).
Manual verify
- Import a CHIRP CSV with DCS-encoded channel(s) → RX/TX tone fields show DCS in channel detail/list.
- Export with same profile →
DtcsCode / CrossMode / polarity columns match source.
- Edit DCS tone in CRUD → export reflects change on wire.
Problem
CHIRP import/export shipped in #103 and model-only round-trip landed in #110. CTCSS tones round-trip via
Tone/TSQL+rToneFreq/cToneFreq→ internalChannel.rxTone/Channel.txTone.DCS is not wired through the boundary. Today:
DtcsCode023DtcsPolarityNNRxDtcsCode023CrossModeTone->ToneparseChirpTones()only handlesToneandTSQLCTCSS modes.formatChirpToneFreq()maps DCS-shaped internal values (D023N, …) back to the CTCSS default88.5on export.Committed
test-data/chirp/fixtures use CTCSS only — no DCS regression coverage.The internal model already supports DCS (
ChannelTone= CTCSS Hz orD023N-style codes; seesrc/lib/channelFields/tones.ts, OpenGD77RX Tone/TX Tonemapping). The gap is CHIRP wire encoding, not a new model field.Intended outcome
Map CHIRP DCS / cross-mode columns ↔
rxTone/txToneat the import/export boundary (no wire stash — same rules as #110).Import
parseChirpTones()(or sibling helpers) to readTone,DtcsCode,DtcsPolarity,RxDtcsCode, andCrossModeper CHIRP semantics.ChannelTonevalues (e.g.D023N).docs/reference/chirp/channels.md.Export
Tone,rToneFreq,cToneFreq,DtcsCode,DtcsPolarity,RxDtcsCode,CrossModefromrxTone/txTone(inverse of import).src/lib/export/chirp/channelWire.ts.none, continue emitting the same constant defaults as today’s CTCSS-only fixtures (023/NN/Tone->Tone).Tests
test-data/chirp/fixture row (or minimal bundle) exercising DCS and/or cross-mode.References
docs/reference/chirp/channels.mdsrc/lib/import/chirp/channelWire.tssrc/lib/export/chirp/channelWire.tsdocs/features/import-export/chirp/chirp-outstanding.mdOut of scope
rxTone/txTone).wireColumnsor other provenance stash for round-trip.URCALL,RPT1CALL, …).Manual verify
DtcsCode/CrossMode/ polarity columns match source.