Issue #20（P4: VRSC＋DG-PRO1RWS RTK移動体技術検証）の判断記録。VRSC（Drogger VRSC、CLAS対応の仮想基準局製品）への依存を保留し、ArduSimple AS-RTK2B-F9P-L1L2-NH（u-blox ZED-F9P）による自前RTK基地局構成へ方針転換する。関連するTrack/Issue（#22〜#28、#30）はすべて方針変更理由でクローズ済み。
VRSCを基準局として使う構成は保留する。ArduSimple simpleRTK2B（u-blox ZED-F9P、base/rover両対応）を用いた自前RTK基地局を構築し、DG-PRO1RWSのRTK Fix到達性を検証する方向へ進める。
Issue #30でDG-PRO1RWSのNAV-TIMEGPS受動復号を検証・実機観測した結果、DG-PRO1RWSはNAV-TIMEGPS（GPS時刻）とRXM-SFRBX（暦）をBluetooth SPP経由で継続的に出力することを確認した。一方、NAV-PVT（位置・速度等の航法解）は、CFG-VALGETでUART1のMSGOUT rateが1と確認できているにもかかわらず、Bluetooth SPP上に一度も出現しなかった（単発pollもTimeout）。
正APK（jp.bizstation.drgps）の静的解析（Issue #28）により、DG-PRO1RWS内部のBluetoothブリッジが、u-bloxチップのMSGOUT rate設定とは独立に、特定のmessage ID（NMEA GGA/RMC、RXM-SFRBX、NAV-TIMEGPS）のみを通す固定的なフィルタを持っている可能性が浮上した。この仮説を検証するため、以下の実機実験を行ったが、いずれもNAV-PVTを出現させることはできなかった。
rate=1書き込みは確定したが出力されず）これにより「class 0x01(NAV)系だけが塞がれ、class 0x02(RXM)系は有効化すれば通る」という仮説も否定された。この時点での結論は「DG-PRO1RWSのBluetoothブリッジは特定message IDのみを通す」という技術的事実であり、これ自体は今も正しいと考えられる。
ユーザーからの指摘（「推測でなくRTKLIB等のOSSツールが実際に何をしているかソースを見て確認すべき」）を受け、https://github.com/tomojitakasu/RTKLIBを実際にcloneしてソースを確認した。
src/rtksvr.c（rtkrcvが使う本体）とsrc/streamsvr.c（str2str/strsvrが使う本体）には、RTCM受信と同一のNTRIP接続上でGGA文を定期送信するnmeacycle/nmeareq機構がある（strsendnmea()、src/stream.c）。これは標準的なNTRIP VRS（仮想基準局）のGGAアップリンク機構であり、Bluetooth等の別経路で受信機から観測データを送り返す仕組みではない。src/rcv/ublox.cのinput_ubx()はストリームから来たバイトを解釈するだけの受動的パーサであり、RTKLIBには受信機へ生データを出させる特別な仕組みは一切ない。これにより、「独自AndroidクライアントがBluetooth経由でNAV-PVTをVRSCへ中継する」という、Issue #26で追いかけていた前提自体が、そもそも標準的なNTRIP/VRSの仕組みとは異なる可能性が浮上した。
ユーザーから「ゴールはDG-PRO1RWSのRTK化であり、Android独自クライアントやRTKLIB導入自体が目的ではない」という指摘があり、調査の焦点を「VRSCが実際に何を要求しているか」の一次情報確認に切り替えた。
VRSC自身のNTRIP source table（GET / HTTP/1.0で取得、Android端末を直接VRSCのWi-Fiへ接続しncで読み取り専用取得）に、以下の記載があった。
STR;VRSC;VRSC;RTCM 3.2;1005(1),1074(1),1094(1),1114(1);2;GPS+QZS+GAL;VRSC;JPN;0.00;0.00;0;1;VRSC;none;N;N;0;Client must send rxm-sfrbx,nav-pvt(0.2hz)
STR;RAW_L6D;RAW_L6D;UBX RAW;QZSSL6(1);2;GPS+QZS+GAL;VRSC;JPN;0.00;0.00;0;1;VRSC;none;N;N;0;Client must send rxm-sfrbx
STR;RAW_L6E;RAW_L6E;UBX RAW;QZSSL6(1);2;GPS+QZS+GAL;VRSC;JPN;0.00;0.00;0;1;VRSC;none;N;N;0;Client must send rxm-sfrbx
さらにVRSC公式テクニカルガイド（https://drogger.hatenadiary.jp/entry/VRSC_TECH）に、以下の記載があることを確認した。
u-blox RXM-SFRBX メッセージをVRSCに送信する（GPS, QZSS Galileoのもののみ）
5秒おきにu-blox NAV-PVTメッセージをVRSCに送信する。（5秒間隔以外はサポート外）
DG-PRO1RW(S)から送信された位置情報の位置を仮想基準点として
Ntrip Clientにて192.168.4.1:2101へアクセスする（マウントポイント VRSC、ユーザー名、パスワードは空）
Bluetoothは設定とRAWデータの出力に使用
これにより以下が確定した。
VRSCはRTCM 1005（基準局座標）だけでなく1074/1094/1114（GPS/Galileo/QZSSのMSM4観測メッセージ）も配信する仕様だが、それには移動局からのアップロードが前提になっている。上記の理解を踏まえ、「DG-PRO1RWS本体が、自身のWi-Fi NTRIP接続の中でRXM-SFRBX/NAV-PVTを正しくアップロードできているか」を確認するため、VRSC本体のBluetooth診断（jp.bizstation.dvrsc、RTCM time表示）と公式Drogger-GPSアプリでの接続試験を繰り返した。その結果、VRSC本体のNTRIPキャスターが以下のような不安定な挙動を示すことを確認した。
ICY 200 OKを返した直後、GGA送信の有無に関わらずソケットが閉じるNtrip IOException Socket closedエラーが出るDG-PRO1RWS・VRSC双方の電源を再投入しても改善しなかった。この時点で、DG-PRO1RWS側の実装の当否を検証する前提条件（VRSC側が安定してNTRIPセッションを維持できること）が満たせない状態と判断した。
ユーザーから「DG-PRO1RWSをもう一台用意して、ちゃんとした基準局を作った方が確実」との提案があり、以下を確認のうえ方針転換した。
AS-RTK2B-F9P-L1L2-NH（u-blox ZED-F9P、L1/L2/E5b対応）は、base/rover両方の動作を公式にサポートしている（ardusimple.com）。ntrip1.bizstation.jp:2101/NEAR-FIXEDというインターネット上のNTRIPホストへの接続実績が既に登録されていた。ホスト/ポート/マウントポイント/ユーザー名/パスワードを自由入力できる新規追加フォームもあり、任意のNTRIPソースへ接続できる汎用クライアントであることが確認できた。これらから、新方針（自前RTK基地局＋既存中継インフラ流用）の実現可能性は高いと判断し、VRSC関連の全Track/Issue（#22〜#28、#30）を方針変更理由でクローズした。
Client must send rxm-sfrbx,nav-pvt(0.2hz)、公式テクニカルガイドの記載）は、将来VRSCへ回帰する場合に再調査不要な一次情報として残す。nmea.bin)を直接解析した結果、標準NMEAはGGA/RMCに限らずVTG・GLL・GSA・GSV(GP/GL/GA/GB全系統)まで広く継続的に届いていることを確認した（Track #45参照、docs/development/p6-ui-spec.md）。ブリッジの制限はUBXバイナリの特定class/idに限定されると理解を改める。