Capture request help

[s-car-go]

I saw this "Lifting the PRO rate properly will require a wire capture from a willing tester comparing EESDR3 PRO at 39062.5 vs higher rates so we can decode the actual rate-code byte the radio expects. Until that capture exists, the PRO stays at 39062.5 native."

I have everything that is needed (I think) to provide what I believe you are looking for. I am willing to give it a try with your guidance.

Let me know if you want my help.

Dave.... WB5QFZ

[jfrancis42]

Dave, WB5QFZ — before you spend time on this, I think the capture you're offering to make has already turned up the answer, so hopefully this saves you the trouble (or at least gives you something concrete to confirm against).

I've got a SunSDR2 PRO on the bench and captured EESDR3 stepping it through all four rates. The rate is set by a uint16 index in the STATE_SYNC (0x01) packet at bytes 56/58 — 0/1/2/3 = 39062.5/78125/156250/312500 Hz. The eight 0x14 rate-code words that v2.1.7 tried to change to 0x32 are not the selector on the PRO; they stay fixed at every rate, which is why changing them broke RX instead of lifting the rate.

Full write-up with how I verified it is over on #47: #47 (comment)

That said — a second independent confirmation from your PRO would be worth a lot, since I'm one radio and one capture. If you want to sanity-check it: capture the control socket (UDP port 50001) while you change the sample rate in EESDR3, and watch bytes 56/58 of the 0x01 packets. They should track 0→1→2→3 as you step the rate. Happy to compare notes / hex dumps if you grab one — I can tell you exactly what I'm seeing on mine.

73, Jeff N0GQ