Initial support (tr)uSDX CAT

[d3m3vilurr]

WARN: this PR is unstable / not finished.

(tr)uSDX's newer experimental firmware is supported voice over CAT feature. And a driver(?) was also released.

Simple explain packets;

• when the connected rig, an app have to send UA1(unmute device sound) or UA2(mute device sound)
  • after that, device will send RX audio which starts with US
  • this data is mono PCM8 sound + 7825Hz sampling
  • if device send another packet; for example return the data of the FA command, send the ; for finish the streaming then send return the packet of the request, then restart streaming (also it starts with US)
• when an app transmit the FT8 packet, an app have to send TX0 (not TX1)
  • after that, an app can send the audio packet like RX case, but in this case we don't need to send US
  • this data have to be mono PCM8 sound + 11520Hz sampling
  • we can't send ; (0x3B) value because rig consider that this value is finish of the TX streaming. so we have to replace this value to 0x3A or 0x3C
  • when we send ; and RX command, rig will resume the RX streaming
  • sometimes, rig return the E; and dosn't finish the TX mode. it could be related with sleep timing for processing, or be related with sending too big packets to the serial port. in this pr, we just sent RX packet multiple times.

After the PR, we can use FT8 QSO without audio cable.

• Receiving RX audio looks stable.
• Transmitting TX audio is wrong. IDK reason, generated audio packet is broken; when I monitoring on the another rig, TX signal was generated in the multiple points. I think this packet makes hazard to another FT8 hams, we can't use this before fixing. I tried to fix multiple times, but I couldn't find solution yet. (maybe it related (tr)uSDX device or downsampling codeset
• So, my patch is just POC. And I'm sorry, it could be unmatched project code styles.

Related #42

[d3m3vilurr]

Transmitting TX audio is wrong

it might be related my to PCM8/PCM16 code. ft8_lib was added 0.5. I don't believe that it is a shot. but I'll test it on this friday. (sorry i don't have rig now.)

[d3m3vilurr]

lightly tested, the processing looks good to me w/o any extra patches. just remain problem is higher freq(>= 2000hz of my rigs) occrus problem. lower freq could be good. (it still shows a spurious signal, but the power could be pretty small. so it wouldn't be a problem)

I'll recheck more encode/decode test result tonight.

[N0BOY]

Thanks for adding the (tr)uSDX CAT support.

I messed up the dev branch. Closing this PR now. Please resubmit to the Dev branch based on the v0.90 release.

[bg7yoz]

@d3m3vilurr 很抱歉，在收到你的提交之前，相对于发布的0.90，我已经对FT8CN做了大量的修改，所以目前不方便把您提交的代码合并进来。我会认真阅读您提交的代码，尽量把uSDX CAT支持加入进来。

最好的办法：建议您耐心等待一段时间，等0.91发布后，您再提交一次。

bg7yoz

[d3m3vilurr]

@bg7yoz this patch was changed to #67 and i think you are already changed your source code for 0.91 branch.

so it's ok.

just concern. (tr)uSDX and uSDX doesn't share thier source code. (base was same but now, feature and main code is different)

for example current firmware of uSDX has RX streaming part, but doesn't have TX streaming part. also some CAT command is not implemented which are already implemented to (tr)uSDX

and I can make the patch to my fork if you release source code :) TX/RX streaming of the (tr)uSDX is beta firmware feature. so many users don't care about it.

TU & 73 DE DS1UFX