Decode/Call/Logging display format

[Rafltdcpa]

(I posted these comments elsewhere on this site but thought they may be best addressed here with some edits)

I noticed that prior to FT8CN ver 0.89 the decoded signals in the decode/call screens displayed as "band 1m" band 2m" etc. and frequency as "155.XXXXXX" for example, as opposed to the traditional ham band format descriptors (17m, 20m, etc,) and frequency (14.074mHz, 18,100mHz, etc.) The QSO log reflected this non-traditional format which required that I edit the exported adi file to comform to other logging programs.

After updating to ver 0.89 I noticed that the decode/call screens were displaying the band and frequency in the traditional ham band format (20m,14-074mHz) which was also displayed in the QSO log after one contact.. Suddenly after initiating a second call I noticed that the decode/call screens would revert back to the non-traditional format upon the second 15 second transmit cycle and remain that way until the frequency (band) was changed. Then the reversion process would repeat itself. As i mentioned there was one initial QSO that logged the contact in the traditional ham format. Those that followed reverted back to the non-traditional format,

Is the FT8CN app decode/call screens supposed to display the traditional ham band logging format (ie 17m, 18.100mHz)? And if so, should that tradutional format carry over to the QSO log?

Thanks.

[N0BOY]

Can you post some screenshots showing what the issue?

[Rafltdcpa]

Notice that after the first call cycle to KA9WAR on frequency 18.100mHz the displayed frequency reverted to 255.121mHz. I notice that while this frequency is in the settings frequency list it has no "*" which I assume indicates that it is not a generally used FT8 in areas of the world other than the CCP. The QSO log also reflects the reverted frequency.

Thank you for your efforts in developing this great program.

[N0BOY]

This is an interesting bug. What radio are you using?

Some early radios, e.g., Yaesu 817, don't validate CAT data, and those CAT commands could be corrupted under RF interference over USB. In such case, the FT8CN app will read and display the incorrect data.

[Rafltdcpa]

The radio is a Xiegu G90. I have both the usb CAT cable and the USB sound card (Sabrent) inserted into a hub which is then inserted into a Samsung Tab A7 tablet. The hub was the only way I could achieve both CAT and audio in/out without the use of VOX. If RF is the issue I can add some toroids to the cables. Also I assume removing the non-standard frequencies from the list is not the answer if RF interference is the issue.

Once again thank you for responding and for your dedication to this project.

Bob K1FRA

[Rafltdcpa]

Update:
I installed toroids on the CAT cable but the problem persists.

[N0BOY]

G90 uses ICOM's CAT protocol and should have data validation. When this problem occurred, do you notice any change on your radio, like displayed VFO, etc?

In your screenshot, I notice the freq change after the first TX, not sure if it's due to RFI or just a coincidence.

Have you tried using this G90 with other FT8 software like Wsjt-x on Windows? How does it work?

Feel free to email me (n0boy@arrl.net) to further discuss this bug.

[Rafltdcpa]

Email sent.

[bg7yoz]

这个问题其他使用G90S的ham也有反映遇到过，发射后，频率值发生变化，但是目前还不清楚是什么原因造成的。根据N0BOY提供的信息，以及与其他ham讨论的结果，推测应该是天线不平衡，在发射时干扰了G90S，您仅仅是在usb线增加磁环应该无法解决问题，被干扰的部分在电台的内部，而不是usb部分，您应该试试在天线端增加巴伦，解决天线的平衡问题。

[Rafltdcpa]

Thank you for responding to this issue and for the development of this excellent program. Yes, the radio is fed using ordinary 50 ohm coax (LMR400) which is unbalanced. I'll try installing an RF choke balun behind the radio to see if that solves the problem. I do find it odd that if RFI in the radio is instigating the frequency change at the android device that the radio itself doesn't react in some way. I'll report back on this and thank you again.

[Rafltdcpa]

To BG7YOZ:

I noticed that when the FT8CN app is not connected to the radio the FT8CN frequency list does not contain the phantom frequencies (see screen shot #1). Once there have been one or more transmit cycles the phantom frequencies appear one at a time, changing at random.(see screen shot #2).

The 0.83 manual indicates that the frequency list is prefabricated and that if a frequency is not "in the preset list, FT8CN will save the frequency band to the list."

If RFI is indeed causing FT8CN to record spurious or otherwise phantom frequencies in the preset list then would it be possible to lock the preset list of frequencies or otherwise keep it from being altered unless acknowledged directly by the user and not the radio?

Thanks,
Bob K1FRA

[bg7yoz]

Hi，Bob

造成FT8CN记录下错误频率（255.132，173.122，573.121...等等）的原因是G90被射频干扰（RFI）而产生了错误数据，错误的根源在电台，而非APP本身，所以还是要在天线部分想办法。

关于FT8CN预设频率的问题，当电台频率变化后，FT8CN应当随着电台的频率变化而更新频率数据，这样做到的好处是FT8CN不限定用户使用不在预设列表中的频率。锁定频率并不是一个好的想法，我认为电台的优先级应该高于FT8CN会更好。

对于您遇到的这个问题，刚好是FT8CN不知道是电台被干扰，认为是用户操作电台频率改变了，对于这个bug，我会反应给XIEGU，看看他们会不会修正这个问题。

73!
bg7yoz

[Rafltdcpa]

Once again, thank you for your quick response. I have ordered 31 mix snap on toroids to install on the coax at the radio connection. I that fails I'll order a 1:1 rf choke balun. I'll report back to you on this.

Thanks again,

Bob K1FRA

[Rafltdcpa]

Unfortunately the toroids didn't solve the problem.

[bg7yoz]

Hi，Bob

关于此问题，我问了XIEGU的工程师，他怀疑是RFI干扰，造成串口数据出错，由于CI-V指令的格式很简单，抗干扰性很差，所以频率数据出错了。他的建议是处理好天馈系统，做好单极天线的接地和RFI处理。

73!
bg7yoz

[Rafltdcpa]

Thanks for the update and for contacting Xiegu about this issue. FYI, the antenna in use here is a full wave 80m delta loop with a 4:1 balun and rf choke at the antenna feed point. My next step will be to run the FT8CN app using another radio (ie my IC756PRO III) with the same antenna to see if the problem occurs. If it does not then that would indicate to me that there is something inherent in the G90 SDR platform that allows RFI to infiltrate and disrupt the CI-V data stream. I'll report back with my findings.

Once again, thank you for your advice and attention to this issue.

73

[Rafltdcpa]

As promised I teamed up the FT8CN app with another radio, in this case a Yaesu 897D (its cabling was the easiest to reconfigure) using the same antenna and an FTDI usb serial converter CAT cable and a Signalink instead of the Sabrent sound card used with the G90. Both CAT and Signalink cables were inserted into the powered usb hub then into my Samsung phone. There were no added toriods. As seen in the attached screenshot I made 5 contacts on 5 different bands with no phantom frequency changes using 100 watts. All QSOs involved multiple transmit cycles and all band and frequency information recorded correctly with no changes.

Opinion:
As I'v previously stated I'm not all that tech savvy when it comes to all things ham radio. That said I glean from this experiment the following:
That the issue is most likely with the G90 SDR platform and that RFI generated within the radio itself (and not from the incoming antenna feed) is corrupting the CI-V data stream to the software. No amount of radio grounding, toroids on the G90 CAT cable or the incoming antenna feed solved the problem.

Perhaps this information will aid Xiegu engineering in planning future design revisions to the G90.

Thanks again.

Bob K1FRA

[bg7yoz]

Hi, Bob
我已经把您测试的信息反馈给Xiegu，Xiegu已经接收到信息，希望会有好的结果。

73!
bg7yoz

[Rafltdcpa]

Thank you!

73!