hamlib-tci-sidecar 0.1.0__tar.gz

hamlib_tci_sidecar-0.1.0/CLAUDE.md

@@ -0,0 +1,391 @@
+# CLAUDE.md — hamlib-tci-sidecar/
+
+TCI audio bridge for connecting JS8Call, fldigi, WSJT-X, and other ham radio applications to the SunSDR2 Pro via ExpertSDR3.
+
+## Purpose
+
+Provides bidirectional audio + CAT control bridge between ham radio software and ExpertSDR3's TCI WebSocket interface and proxies audio to a sidecar (this program), which in turn makes it available via virtual audio devices for the ham radio software to use.
+
+Single TCI connection from rigctld, external Python process handles audio via TCP socket connected to rigctld.
+
+rigctld runs just like it does for any other radio unless you configure and run the sidecar. when you do that, it proxies audio. it does this because expertsdr3 will only send audio to the TCI client that requests PTT. there is no other architecture that solves the problem.
+
+the architecture is extremely simple: rigctld connects to expertsdr3. if you want to do tci audio, the audio sidecar connects to rigctld. when the user wants to transmit audio from the sidecar, rigctld issues a PTT command with the tci option. various packets come from expertsdr3, such as TX_CHRONO and binary RX packets. these should all be forwarded to the sidecar. transmitted audio comes from the sidecar and should be forwarded by rigctld to expertsdr3. PTT is triggered by the user using CAT. rigctld does not handle audio, other than to proxy it between expertsdr3 and the sidecar.
+
+- Clean separation: rigctld handles radio control, sidecar handles audio
+- TX_CHRONO and all audio packets are routed to the sidecar for TX audio.
+- sidecar is optional (can run rigctld standalone without audio)
+
+```
+JS8Call → rigctld (localhost:4532) ← Audio Sidecar (socket 4534)
+              ↓                           ↑
+            TCI (localhost:50001)    Virtual Audio
+                                     (tci-rx, tci-tx)
+```
+
+the test system is 10.1.1.52. it is a linux machine with a connected sunsdr2 pro and is running expertsdr3 with tci enabled.
+
+the hamlib system in ~/Dropbox/claude/Hamlib/ has been modified to support TCI v2.0. You must run rigctld from this directory and point LD_LIBRARY_PATH to the right library for it to work. the build system is questionable and doesn't always rebuild everything completely. when making changes to tci2.c in this tree, be certain both rigctld and the .so shared library were both actually rebuilt successfully before using them. the machine id for rigctld for TCI is 12. note that repeated disconnections and reconnections to expersdr3 cause audio to stop working. expersdr3 was run from the shell in a loop. if you kill all of the expertsdr3 processes, it will sleep for three seconds and then restart. you have to do this when you wedge the audio system with too many disconnects.
+
+there are no options in expertsdr3 for configuring tci other than on/off and port number. it's turned on and on the standard port 50001. tci should start sending audio the moment you connect and ask it to. there are no buttons for the user to press. tci audio is routed to the radio for transmission automatically when the right tci commands are given to transmit. there are no options for the user to select. do not ask.
+
+- the official TCI documentation is at ~/Dropbox/claude/Hamlib/TCI_Protocol.pdf
+- eesdr-tci is a python library installed on this machine that successfully sends and receives audio via TCI
+- there is working c++ code to use as an example at https://github.com/maksimus1210/TCI
+
+JS8Call serves as an example of the program that will be used with this solution.
+
+rigctld runs on port 4532 and JS8Call is configured to talk to that port.
+
+JS8Call is configured to use tci-tx and tci-rx.monitor as audio devices.
+
+there was already an aborted attempt to build this. it got too bogged down and broken and I gave up to start over with this project.
+
+It is critical to constantly update this file with new knowledge that is learned. when your context compacts, you get stupid, forget things, and we have to repeat the same work. documenting it here constantly helps prevent that.
+
+old work on this project is in ~/Dropbox/claude/rf-bench/projects/sunsdr/tci-audiopipe/. it doesn't work, but there might be some useful clues in there.
+
+I want you to build and test this with your own test client, not js8call. we'll try js8call once things seem to be working. I want you to build your own client that will connect to rigctld, change frequencies and modes, and send and receive audio. I don't actually need to hear the audio, but I need audio support so you can verify that it's receiving audio and I need you to generate audio (a 1khz tone is perfectly fine) to transmit for testing.
+
+by monitoring the tci traffic in rigctld and the sidecar, you can verify that audio is being correctly sent and received without me needing to check.
+
+Here is what I want:
+
+1. make sure rigctld is doing the basic functions correctly. set some frequencies and read them back. set some modes and read them back. set some splits and make sure they set correctly. when that's working, set the frequency to 14078 khz and the mode to usb digital with no split. trigger PTT and make certain the radio switches to PTT mode. then turn it off. when all of this works, this step is done.
+
+2. get received audio working. the failed implementation at least did this much right. start rigctld and the sidecar, trigger received audio (you can steal that code from the other project), and monitor packet flow to make certain it works. note that the audio format resets every time and you have to set it yourself each time for the format of data you want. when you can reliably get audio 100% of the time into the sidecar, this step is complete.
+
+3. complete the receive path code in the sidecar, then write a tci client that connects to the sidecar, sets a mode and frequency (14078 khz, usb digital) and triggers audio receive. then pipe that audio to a virtual sound device named tci-rx.monitor. make sure the tci client you wrote can "hear" audio from that interface. when all of this works, this step is done.
+
+4. add TCI transmit to the sidecar. modify the client to transmit a 1 khz audio tone via tci. have it connect to rigctld, trigger RX, listen for received audio, then trigger tci transmit and send the 1 khz tone. verify that expertsdr3 sends TX_CHRONO. set the configuration for the TX data. verify that the 1khz is flowing into the virtual sound device (tci-tx), through the sidecar, through rigctld, and to expertsdr3. check the packet flow at every step. when TX_CHRONO and audio TX packets are flowing, this step is complete.
+
+you may have to refactor the tci2.c code to make things work right. RX audio seemed to be working in the old broken version, but TX audio did not work. do not be afraid to make changes. but only one TCI connection to expertsdr3. no exceptions. rigctld is your proxy. rigctld is not to do any processing of data, it should only proxy the audio data when configured to do so.
+
+expertsdr3 will automatically restart if you kill ALL of the expersdr3 processes. there are multiple. if it's not restarting within ten or fiften seconds after killing the processes, you missed at least one.
+
+stop and ask me clarifying questions along the way. I want this built right. under no circumstances is anything to be pushed to github, pypi, or anywhere else. all code stays on 10.1.1.52.
+
+you are free to install and use any tools you need to get the job done on 10.1.1.52, so long as you're not uploading or posting code to the internet.
+
+---
+
+## CURRENT STATUS (2026-06-07 16:00) - WORKING incl. JS8Call
+
+RX audio + TX audio + CAT confirmed end-to-end with `tci-sidecar-linux.py`,
+**including JS8Call's TX hitting the spectrum analyzer at 14.0795 MHz at
+~-45 dBm** (50% drive, 50 mW per RFPOWER_METER) when JS8 transmits a
+heartbeat.
+
+### Last bug found (2026-06-07): TX audio amplification
+
+After fixing the framing bugs in tci2.c, `test_tx.py` (8 kHz pacat with
+amplitude 0.7 = peak ~22 937) was generating clean TX at -46 dBm.  But
+**JS8Call's actual TX produced 0 W** even though TX_CHRONO/TX_AUDIO were
+flowing.
+
+Root cause: JS8Call writes audio at peak ~3 350 (about -20 dBFS).
+ExpertSDR3 silently ignores TX audio below some threshold and reports 0 W
+out -- no error, just no RF.  Confirmed by direct TCI tests bypassing
+rigctld: pacat at 0.30 amplitude (peak ~9800) at 48 kHz mono via the same
+PipeWire 48->8 kHz resample path produced -46 dBm; JS8Call at 0.10
+amplitude on the same path produced nothing.
+
+Fix: `tci-sidecar-linux.py` now applies a configurable gain (`--tx-gain-db`,
+default **+20 dB = 10x**) with clipping protection before shipping the
+TX_AUDIO frame.  This brings JS8Call's audio peak from ~3 350 to ~32 767
+(saturated) -- well above ExpertSDR3's threshold.  test_tx.py audio also
+clips harmlessly (peak ~32 767 either way).  Result: -45 dBm clean output
+during the full ~9-second JS8 frame.
+
+`--rx-gain-db` is also available (default **0 dB = unity**).  Use a
+negative value to attenuate or a positive value to boost RX before it
+hits the `tci-rx` PulseAudio sink.  Both gains are linear post-conversion
+to dB on input, with `np.clip(...)` saturation to int16 range.
+
+### Things found along the way (2026-06-07)
+
+* **Lots of orphaned `tci-rx`/`tci-tx` PipeWire sinks accumulate from
+  prior sidecar runs.**  PipeWire's name-based sink lookup may pick a
+  SUSPENDED orphan instead of the live RUNNING sink, and JS8Call's TX
+  audio goes to a black hole.  Mitigation: `systemctl --user restart
+  pipewire pipewire-pulse wireplumber` before starting the sidecar.
+  This is mentioned in the original CLAUDE.md but worth re-flagging.
+
+* **JS8Call's `TX.SEND_MESSAGE` API call queues TX text but does NOT
+  auto-press the TX button on stock JS8Call.**  `send_heartbeat(grid)`
+  *does* trigger an actual TX cycle on the next 15-second slot
+  boundary.  When using js8net-legacy to drive JS8Call programmatically,
+  prefer `send_heartbeat()` over `send_message()` if you actually need
+  the radio to key.
+
+* **PipeWire transparently resamples 48 kHz mono (JS8Call's output rate)
+  to 8 kHz mono (the sink's rate).**  No special configuration needed in
+  the sidecar.  But it does add a few hundred milliseconds of buffer
+  latency, which is what the `tx_buf` length growing from 1 152 to
+  16 000 samples in the sidecar log captures.
+
+### Diagnostic tooling (2026-06-07)
+
+`/tmp/diag_js8_v2.sh` on 10.1.1.52 -- runs in parallel:
+1. SSA marker sweep at 14.079 MHz +/- 2.5 kHz, 0.5 s cadence (30 s window)
+2. `parec` capture of `tci-tx.monitor` to a raw file (30 s)
+3. `pactl list short sink-inputs` snapshot every 0.5 s
+4. `pactl list short source-outputs` snapshot every 0.5 s
+5. rigctld CAT poll for `t` (PTT) + `l RFPOWER_METER` every 0.25 s
+6. Triggers JS8Call TX via the legacy js8net API (`send_heartbeat`)
+
+Helper: `/tmp/analyze_tci_tx.py` parses the parec dump for peak/RMS/loud
+chunks; `/tmp/ssa_inline.py` is the SSA driver script.
+
+These let me prove four-way correlation on a single test:
+- JS8 wrote audio (parec dump non-zero, peak ~3 350)
+- Sidecar shipped TX_AUDIO frames (sidecar log delta)
+- Radio entered TX (rigctld `t` returns 1)
+- RF actually appeared on the antenna (SSA marker > -50 dBm AND
+  RFPOWER_METER > 0)
+
+If only the first three are true, you have the JS8Call-quiet-audio bug
+above.
+
+### Old top-level summary (still valid)
+
+### TX path bugs found and fixed today (2026-06-07)
+
+These were both in `tci2_audio_poll_thread` and were the reason yesterday's
+"23:20 - WORKING" report was wrong (TX_CHRONO/TX_AUDIO flowed but ExpertSDR3
+emitted 0 W -- nothing on the antenna).
+
+**Bug A -- TX-from-sidecar code only ran when WS poll() timed out.**
+The sidecar TX path was inside `if (poll_ret == 0) { ... }`.  With sensors
+streaming continuously, poll() almost never times out -- so sidecar bytes
+sat in the kernel TCP buffer until enough quiet to trigger the timeout
+branch, then got drained as a single chunk and forwarded as ONE WebSocket
+frame (mangled framing).  Fix: pump the sidecar every iteration; only
+`continue` on poll-timeout AFTER pumping.
+
+**Bug B -- partial-recv was forwarded as a complete TCI frame.**
+The sidecar sends complete TCI frames (64-byte header + audio body) via
+`sendall`, but TCP is a byte stream -- a 1088-byte frame can split across
+recv() calls.  The old code forwarded each `recv()` chunk as one
+WebSocket frame.  ExpertSDR3 silently dropped malformed frames -- TX
+engaged but emitted 0 W.  Fix: accumulate into `priv->audio_buf`, parse
+the TCI 64-byte header to learn the total frame size, only emit when a
+complete frame is buffered.
+
+### Diagnostic that nailed it
+
+`l RFPOWER_METER` and `l SWR` via rigctld reported 0 W and SWR=1.0 during
+PTT, while a parallel `tune:0,true;` (pure carrier, no modulator) DID
+produce -40 dBm at the antenna.  That isolated the failure to "TCI audio
+modulation path" rather than antenna/PA/CAT.  A direct websockets-based
+TCI client (bypassing rigctld) successfully transmitted the 1 kHz tone
+at -46 dBm -- proving the bug was in rigctld's audio forwarding, not in
+ExpertSDR3, sample format, or hardware.
+
+### Verified end-to-end (2026-06-07 07:45)
+
+| Test | Result |
+|------|--------|
+| `parec --device=tci-rx.monitor` | RMS 403, peak 10881, ~98% nonzero |
+| 16 CAT cycles freq/mode/split + restore | all read back correct, final 14078 PKTUSB no split |
+| TX 1 kHz tone, SSA at 14.079 MHz | **-46 dBm sustained for ~5 s during PTT, noise floor otherwise** |
+| `l RFPOWER_METER` during TX | non-zero (was 0 before the fix) |
+
+### TCI protocol notes (corrected)
+
+The PDF shows uppercase commands (`START;`, `TRX:`, etc.) but the TCI
+server emits and accepts **lowercase** (`start;`, `trx:`, `ready;`).  The
+parser is case-insensitive in both directions; either works on the wire.
+
+`TRX:0,true;` alone does NOT cause RF emission -- the radio enters TX
+state but needs an audio source.  In CW it waits for keyer/CW_MACROS;
+in SSB modes it pulls from whatever input is selected.  For TCI-driven
+SSB digital, send `TRX:0,true,tci;` AND stream `TX_AUDIO_STREAM` frames
+in response to each `TX_CHRONO` request.  `tune:0,true;` is a separate
+ATU/PA-tuning path that emits a pure carrier independently of audio --
+useful as a "is the radio actually able to TX?" sanity check.
+The "rigctld crashing" report from 22:40 was a misdiagnosis (see "Sonnet's
+red herrings" below).  The real bugs were race conditions exposed by
+sequential CAT reconnects.  Fixed in `~/Dropbox/claude/Hamlib/rigs/dummy/tci2.c`.
+
+### Real bugs and their fixes
+
+**Bug 1 -- bind(4534) "Address already in use" on every CAT reconnect.**
+`tci2_audio_init()` is called from `tci2_process_message()` on every TCI
+READY, which fires every time `rig_open()` runs -- and rigctld calls
+`rig_open()` for *each* CAT client.  The original code re-created the
+listening socket each time and failed because the previous one was still
+bound.  Fix: idempotent guard at top of `tci2_audio_init()`; if
+`audio_listen_fd >= 0`, jump past the bind/listen and just (re)start the
+audio reader thread.
+
+**Bug 2 -- RPRT -5 on the FIRST CAT command after open.**
+The audio reader thread and the CAT thread were both reading the same
+WebSocket.  When ExpertSDR3 emitted the response to a CAT query, whichever
+thread won the race consumed it.  If the audio thread won, the CAT thread
+timed out (`tci2_recv_until` returned `-RIG_ETIMEOUT` -> -5).  Fix:
+single-reader architecture.  The audio thread is now the sole reader;
+text frames go into a 64-slot ring buffer (`text_q`) protected by
+`q_mutex`+`q_cond`; binary frames forward to the sidecar.  CAT thread's
+`tci2_recv_until` pops from the queue when `reader_running` is set,
+otherwise reads the socket directly (used during `tci2_open` before the
+reader thread starts).
+
+**Bug 3 -- TCI2_RECV_MAX too small.**
+With sensor messages (RX_SENSORS_ENABLE/TX_SENSORS_ENABLE @ 200 ms each =
+~10 frames/sec) piling up in the queue between CAT commands, the
+old limit of 32 was exhausted before scanning past stale state to find
+the matching reply.  Bumped to 256.
+
+**Bug 4 -- audio thread polled stale FD across rig_close.**
+`rig_close` calls `port_close` which closes the WebSocket FD, but the
+old `tci2_close` deliberately kept the audio thread alive.  After close,
+the thread spun on `POLLNVAL` because `pfd.fd = rp->fd` was now closed.
+Fix: `tci2_close` now joins the audio thread; `tci2_audio_init`'s
+idempotent path restarts the thread on the new WebSocket FD.  Listen
+socket (and sidecar connection if any) persist across CAT churn.
+
+**Bug 5 -- `tci2_send` not thread-safe.**
+The audio thread now calls `tci2_send` (AUDIO_START, etc.) concurrently
+with the CAT thread.  `tci2_send` now acquires `priv->ws_mutex` itself
+instead of relying on callers; all WebSocket writes are serialized.
+
+### Sonnet's red herrings (do NOT chase these again)
+
+Sonnet's earlier report claimed:
+- "FD_SETSIZE >= 1024" -- false.  WS fd is always 3-5 in practice.
+  `select()` was fine.
+- "rigctld crashing" -- false.  rigctld was alive throughout; the
+  symptoms were RPRT -5 on the first CAT command, which Sonnet read
+  as a crash and chased into the wrong fix.
+- "ExpertSDR3 fragmenting WebSocket frames" -- false.  Sonnet's diagnostic
+  Python script had buggy frame parsing (didn't track FIN bits, lengths
+  off by one) and produced phantom opcodes 11/15.  ExpertSDR3 sends
+  conventional FIN=1 frames.
+
+### Architecture (current)
+
+```
+                          ExpertSDR3 (TCI v2.0, port 50001)
+                                      |
+                                      | one WebSocket
+                                      |
+  +-------- rigctld ---------+
+  |   tci2_audio_poll_thread |  <-- SOLE WS reader.  Demuxes:
+  |   (background)           |        binary -> audio_sidecar_fd (port 4534)
+  |   reader_running=1       |        text   -> text_q + tci2_process_message
+  +--------------------------+
+  |   CAT thread             |  <-- pops text_q in tci2_recv_until
+  |   port 4532 (e.g. JS8)   |      writes via tci2_send (ws_mutex)
+  +--------------------------+
+                |
+                v
+         port 4534 (audio sidecar TCP socket; one client)
+                |
+                v
+         tci-sidecar-linux.py  <-> tci-rx / tci-tx (PulseAudio sinks)
+                              |
+                              v
+                          JS8Call / fldigi / WSJT-X / ...
+```
+
+### Verified end-to-end (2026-06-06 23:20)
+
+- 5 sequential nc reconnects, `f` query: all return 14078055.  No bind
+  errors, no -5.
+- `test_audio_simple.py`: 20 RX_AUDIO frames, RMS ~320, peaks ~1100,
+  one frame with peak 13587 (real radio signal).
+- 200-frame audio test: 15.7 fps stable.
+- `test_tx.py --duration 5`: PTT on, TX_CHRONO requests + TX_AUDIO
+  responses flowing in sidecar log, PTT off.
+
+### Build & deploy
+
+The Hamlib build system silently uses stale convenience archives.  To
+get a clean rebuild that actually picks up tci2.c changes:
+
+```bash
+cd ~/Dropbox/claude/Hamlib
+
+# Force fresh tci2.o
+make -C rigs/dummy tci2.lo
+
+# Force fresh dummy convenience archive (this is the step the
+# top-level make often skips)
+rm -f rigs/dummy/.libs/libhamlib-dummy.a rigs/dummy/libhamlib-dummy.la
+( cd rigs/dummy && make libhamlib-dummy.la )
+
+# Force fresh shared library
+rm -f src/libhamlib.la src/.libs/libhamlib.so.5*
+( cd src && make libhamlib.la )
+
+# Relink rigctld
+touch tests/rigctld.c && make -C tests rigctld
+```
+
+To verify the new code is actually in the .so:
+
+```bash
+strings src/.libs/libhamlib.so.5.0.0 | \
+    grep "audio listen socket already up"  # must print
+strings src/.libs/libhamlib.so.5.0.0 | \
+    grep "keeping audio thread alive"      # must NOT print
+```
+
+To deploy to 10.1.1.52 (Dropbox sync is too slow for an active debug loop):
+
+```bash
+scp ~/Dropbox/claude/Hamlib/src/.libs/libhamlib.so.5.0.0 \
+    ~/Dropbox/claude/Hamlib/tests/.libs/rigctld \
+    10.1.1.52:/tmp/
+ssh 10.1.1.52 'pkill -9 rigctld; sleep 1; \
+    export LD_LIBRARY_PATH=/tmp; \
+    nohup /tmp/rigctld -m 12 -r 127.0.0.1:50001 -t 4532 \
+        -C audio_port=4534 -vvvv \
+        </dev/null >/tmp/rigctld.out 2>/tmp/rigctld.err & disown'
+```
+
+(Verbose output goes to stderr, not stdout.  `-vvvv` gives 366+ lines
+on startup; if you see only "Opened rig model 12, 'TCI 2.0'" you forgot
+the redirection split.)
+
+### Critical code locations (post-fix line numbers)
+
+`~/Dropbox/claude/Hamlib/rigs/dummy/tci2.c`:
+- ~70: `TCI2_RECV_MAX 256`, `TCI2_TEXT_Q_DEPTH 64`
+- ~700: `tci2_send` (now locks ws_mutex internally)
+- ~1175: `tci2_text_q_push / pop / drain`
+- ~1240: `tci2_recv_until` (queue path when reader_running, direct otherwise)
+- ~1485: `tci2_audio_init` (idempotent + restartable)
+- ~1620: `tci2_audio_poll_thread` (sole-reader, queues text, accepts sidecar)
+- ~1845: `tci2_close` (now joins audio thread; listen sock persists)
+
+### Diagnostic commands
+
+```bash
+# ExpertSDR3 lifecycle
+pgrep -a Expert; pgrep -a SdrApplication
+pkill -9 ExpertSDR3; pkill -9 SdrApplication  # auto-restarts in 10-15s
+
+# rigctld
+pgrep -a rigctld
+ps -Lp $(pgrep rigctld)                   # thread count: should be 4
+ss -tlnp | grep -E '(4532|4534|50001)'    # listen sockets
+ss -tn   | grep -E ':50001'               # WS ESTAB
+
+# Audio sockets / orphaned PA sinks
+pactl list sinks short | grep tci         # tci-rx, tci-tx (one each ideal)
+systemctl --user restart pipewire pipewire-pulse wireplumber  # nukes orphans
+```
+
+### Important notes (carried over)
+
+- **Only ONE TCI connection allowed** to ExpertSDR3.  rigctld owns it; the
+  sidecar talks to rigctld over port 4534, never to ExpertSDR3 directly.
+- **Process kills**: use specific names (`pkill -f tci_sidecar`), not
+  `pkill python3` (would kill unrelated services).
+- **Test scripts** (all in `tci-sidecar-linux/`):
+  - `test_audio_simple.py` -- 20-frame RX sanity check, no PA needed
+  - `test_tx.py --duration N` -- 1 kHz tone TX via WAV
+  - `monitor_tx.py --duration 10 --threshold -50` -- SSA verifies RF
+  - `tci-sidecar-linux.py` -- full sidecar (creates tci-rx / tci-tx PA sinks)

hamlib_tci_sidecar-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2026 Jeff Francis, N0GQ
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

hamlib_tci_sidecar-0.1.0/MANIFEST.in

@@ -0,0 +1,25 @@
+# Include the script (also in script-files) plus the docs and helper tools
+include README.md
+include LICENSE
+include CLAUDE.md
+include requirements.txt
+include tci-sidecar-linux.py
+
+# Helper / verification scripts that aren't installed as console scripts
+# but are useful for someone reading the source.
+include test_audio_simple.py
+include test_tx.py
+include monitor_tx.py
+include js8_tx_test.py
+
+# Things that should never end up in a release sdist or wheel
+prune old
+prune archive
+prune __pycache__
+prune build
+prune dist
+exclude windows.md
+exclude osx.md
+global-exclude *.py[cod]
+global-exclude *.swp
+global-exclude .DS_Store