Skip to content

v1.6.16 — PTT 応答未確認で送信が約 5 秒で切れる問題の修正 / Fix TX cut after ~5 s on "PTT not confirmed"

Choose a tag to compare

View all tags
@pepefrog1234 pepefrog1234 released this 06 Sep 06:29
· 16 commits to main since this release
v1.6.16
f3f8c7d

v1.6.16 — PTT 応答未確認で送信が約 5 秒で切れる問題の修正 / Fix TX cut after ~5 s on "PTT not confirmed"

v1.6.15 のフィールドレポート（Motorola / Android 15）：送信が約 5 秒で切れ、「PTT の応答を確認できません — 自動で再試行しています」が表示され、その後送信できない。インストールは app-debug.apk をご利用ください。

日本語

原因

v1.6.14 で CAT の PTT 応答判定を厳格化しました（set_ptt: 1;RPRT 0 の形式で、しかも 1 秒以内に返った場合だけ成功）。CAT の応答が遅いリグ（Xiegu G90 など）や、USB シリアル／Wi-Fi 経由で応答が 1 通失われた場合、rigctld は自身のタイムアウト後に RPRT -5 を返すか、1 秒を過ぎてから正常応答を返します。無線機は実際には切り替わっているのに、アプリはこれを「PTT 失敗」と判定し：

  1. キーオンを 3 回やり直したあと（≈ 4 秒）「送信開始失敗」として送信を強制停止 → 送信が約 5 秒で切れる。
  2. 解除側も同じ理由で「未確認」となり、v1.6.15 で追加した恒久的な解除再試行が終わらず、バナーが出たまま次の送信が拒否される。

修正

  • PTT の応答待ちを 1 秒 → 2.5 秒に延長（PTT と読み返しのみ。他のポーリングは従来通り）。
  • 応答が得られないときは無線機の PTT 状態を読み返して判断します（t コマンド）。キーオン後に無線機が「送信中」と答えれば成功扱い、解除後に「受信中」と答えれば解除完了扱いにして、バナーも消えます。
  • 無線機が明確に「受信中」と答えた場合だけ送信を中断します。応答が取れないだけの場合は送信を継続し（無線機の表示で確認できます）、バナーで注意喚起します。QSO を 5 秒で切ることはなくなりました。
  • 解除の即時再試行は 3 回（各回で読み返し）にし、その後の自動再試行でも毎回読み返して、実際に解除されていれば即座に通常状態に戻ります。
  • バナー文言を具体的に：「CAT の PTT 応答を確認できません。無線機の送受信表示を確認してください。切り替わっていればそのまま運用できます。送信のまま戻らない場合は Stop を押してください。」

確認のお願い

  • 同じ操作（送信 → 数秒 → 受信）を行い、送信が切れないこと、バナーが消えることを確認してください。
  • それでも表示される場合は、送信直後に 設定 → 診断 → Capture CAT log を取得してお送りください。setPtt(true) response: … acknowledged=false elapsedMs=… と readPtt → … の行で、応答の内容と所要時間が分かります。あわせて無線機の型番と接続方法（USB / Bluetooth / Wi-Fi）をお知らせください。

English

Field report on v1.6.15 (Motorola, Android 15): TX stops after about 5 s, the banner "PTT was not confirmed — retrying automatically" appears, and further TX is refused.

Cause. v1.6.14 made the CAT PTT acknowledgement strict: only a set_ptt: 1;RPRT 0 reply within 1 s counts. Rigs with slow CAT replies (Xiegu G90 and friends), or a single reply lost on USB-serial/Wi-Fi, make rigctld answer RPRT -5 after its own timeout or reply after more than 1 s — although the rig did switch. The app then treated key-on as failed (3 retries ≈ 4 s, then "TX start failed" → teardown: the ~5 s cut) and unkey as failed, so v1.6.15's persistent unkey never finished and the banner blocked the next over.

Fixes. PTT commands now wait up to 2.5 s (polling keeps its 1 s). When no usable reply arrives the app reads the rig's PTT state back (t): "on" after key-on counts as keyed, "off" after unkey counts as unkeyed, and the banner clears. Only a rig that explicitly reports PTT off aborts the over; with no reply at all TX continues and the banner just asks the operator to glance at the rig. The quick unkey retries are 3 with readback each, and the background retry reads back too, so a rig that has in fact unkeyed returns the app to normal at once. The banner text now says what to check.

Please test TX → a few seconds → RX. If the banner still appears, capture Settings → Diagnostics → CAT log right after an over (setPtt(...) response: … elapsedMs=… and readPtt → … lines) and tell us the rig model and connection type.

繁體中文

v1.6.15 回報（Motorola / Android 15）：發射約 5 秒即中斷，出現「PTT 未確認」橫幅，之後無法再發射。原因是 v1.6.14 把 CAT 的 PTT 回應判定收得太嚴（須在 1 秒內收到 set_ptt: 1;RPRT 0），CAT 較慢或掉一則回應的電台會被誤判為失敗，即使電台其實已切換。修正：PTT 等待延長到 2.5 秒；收不到回應時改讀回電台的 PTT 狀態判斷；只有電台明確回報「未發射」才中止發射；解除流程每次都讀回狀態，實際已解除就立即恢復正常；橫幅文字改為具體的檢查步驟。

Validation

  • ./gradlew testDebugUnitTest assembleDebug --offline: BUILD SUCCESSFUL; 46 unit tests pass. Debug APK versionCode 10616, 1.6.16-ptt-ack-readback.
  • Not verified on radio hardware; the readback uses the same t query the Rig tab already polls every second.

Full Changelog: v1.6.15...v1.6.16

Assets 4
Loading