Multiband FT8 Decoder

[Todd Baumgartner]

Hi, 

I am enjoying playing with a board I just picked up from Aliexpress. Things have been working well with the standard gateware and SparkSDR. For fun, I've been trying to run the 8 receiver 4k gateware -radioberry_cl025_4000 with the (Radioberry-2.x/tree/master/SBC/rpi-4/decoders/ft8) code base.

I've had good results showing up on PSKreporter, but after a few minutes I start getting flagged as reporting Bad QRGs. 

Upon looking, I'm seeing a number of the ft8_x_xxxxx files created by the recording-ft8 code are not decoding anything with ft8d. 

The other curiosity, is in I appear to be seeing say 40M calls in the 20M file:

# ./recordings/ft8_2_14075500_220126_1844.c2

220126 184400  13.4  -1  1.16 14074599 K4JMG
220126 184400   9.8  -5 -0.08 14075919 KO4IBY        EM85
220126 184400 232.8  10  1.06 14075997 KN4WGE        EM66
220126 184415  27.8   2  1.22 14074598 N4DKN
220126 184415   5.6  -9  1.10 14074899 AC9HP
220126 184415  17.8  -2  1.13 14075137 KA9VRX
220126 184415   9.7   4  1.16 14075630 K3UA
220126 184430 142.0   9  1.14 14074840 K4NDN         FM08
220126 184430  11.2  -5 -0.08 14075919 KO4IBY        EM85
220126 184430  73.1   3  1.06 14075997 KN4WGE        EM66
220126 184445  15.8  -2  1.22 14074598 N4DKN
220126 184445   8.9  -8  1.10 14074900 AC9HP
220126 184445  11.5  -2  1.13 14075137 KA9VRX
220126 184445   7.5   2  1.16 14075630 K3UA

I'm wondering if anyone has seen similar before, or if there are some ideas on how to troubleshoot?

[pa3gsb]

i think an update of the gateware is necessary for the 4K versions

Op woensdag 26 januari 2022 om 19:52:12 UTC+1 schreef todd.bau...@gmail.com:

[Yado-san]

Hi

I looked at Pskrepoter.info this morning and there were no indication of your bad QRG or unknown bands. FB!?
...Two "Radioberry FT8 Decoder" users  were shown.

I have had bad QRGs before when I changed GW and firmware to 73.2 to check PTT works and then changed it back.
I guess it was because I forgot to change the firmware (or GW?) back.

 > I have been running 'Radioberry FT8-Decoder' all day since last summer.
 > ft8-skimming 5 bands with my radioberry-2.(cl016: 6rx with 4kGW:72.5)

 Therefore I hadn't updated GW, I updated to the latest version to see how the FT8 skimmer works.
 > install: cl016_4kGW:73.2, Drv:0.93, Firmware:2022.01.24

 The result is no problem with decoding, no bad QRGs in Pskrepoter.info.

 However, there is still the problem that rx1 is not decoded that posted last year.
 I'd like to improve my skills and solve this.
 cf.  https://groups.google.com/g/radioberry/c/G9MKUa_IDOc

73.
Yado-san, jg1twp

2022年1月27日木曜日 18:03:30 UTC+9 pa3gsb:

[Todd Baumgartner]

Thanks everyone for the replies. I compiled the gateware cl025_4000 version 73-3  and installed it yesterday.  I'm not currently sending the data to PSKreporter as decodes are not consistently in the recording files expected. I'm going to take a look at the notes you put together from before as I've been trying to understand the send_control commands better.  
Your results sound promising, I guess the biggest difference is I'm on cl025 and you're on cl016 hardware.

Thanks,

Todd

[Todd Baumgartner]

I'm on gateware cl025_4000 73-3, Firmware 2022.01.24, driver version 93.  Running recording-ft8.c with the 8 frequencies and NRX set to 8. I'm getting decodes in ft8_0 - 7, but it's not consistent.  The 20m file may actually have reports from 40m.    As an experiment, I was transmitting FT8 on 14.074 with another rig, and my decodes showed up in the radioberry decode logs, but they were across multiple bands:

I'm the WV8U entries in the log: 

rpi4:/tmp# more report_220130_1558.txt  

# ./recordings/ft8_0_1841500_220130_1556.c2

# ./recordings/ft8_1_3574500_220130_1556.c2

# ./recordings/ft8_2_5358500_220130_1556.c2

# ./recordings/ft8_3_7075500_220130_1556.c2

220130 155600  14.0   9  1.45  7076267 WV8U          EM79

220130 155615  12.3  -1  1.24  7075302 KB3MXK            

220130 155630   3.1 -12  1.45  7076121 WV8U          EM79

220130 155630   3.0 -10  1.45  7076157 WV8U          EM79

220130 155630   4.4  -7  1.45  7076194 WV8U          EM79

220130 155630  14.6  11  1.45  7076267 WV8U          EM79

220130 155645  13.9   0  1.25  7075302 KB3MXK            

# ./recordings/ft8_4_10137500_220130_1556.c2

220130 155600  36.2  25  1.45 10137771 WV8U          EM79

220130 155615  20.5  -6  1.09 10136859 K8EB          EL97

220130 155615  10.3  -4  1.37 10138234 KG4ASZ        EL98

220130 155630  35.9  26  1.45 10137770 WV8U          EM79

220130 155645  27.9  -2  1.09 10136859 K8EB          EL97

220130 155645  15.2  -2  1.18 10138093 KG4ASZ        EL98

# ./recordings/ft8_5_14075500_220130_1556.c2

220130 155600  71.8   6  1.45 14075790 WV8U          EM79

220130 155615  28.9  -3  0.50 14074735 ND6H          CM97

220130 155615  55.3   0  1.11 14075175 K8TE              

220130 155630   6.6 -10  1.07 14074403 WX2K              

220130 155630   3.4 -17  1.45 14074490 WV8U          EM79

220130 155630  62.8  10  1.45 14075790 WV8U          EM79

220130 155645  54.3   0  0.50 14074735 ND6H          CM97

220130 155645  19.2   1  1.12 14075097 K8TE          DM65

# ./recordings/ft8_6_18101500_220130_1556.c2

220130 155600  22.6  -6  1.45 18100275 WV8U          EM79

220130 155615  15.0   3  1.12 18100969 EI8GS             

220130 155615   3.5 -12  1.39 18101232 IK2SAR        JN55

220130 155615   1.7 -12  1.01 18101323 HB9TKS            

220130 155615   3.2 -10  1.39 18101362 M7JMJ         IO92

220130 155615  10.4  -4  1.06 18102404 CO6ABP            

220130 155630  23.3  -2  1.45 18100275 WV8U          EM79

220130 155645   2.7 -13  1.02 18100646 HI3A              

220130 155645   9.2  -4  2.23 18100736 F6DZU             

220130 155645  38.7   0  1.22 18100969 EI8GS         IO51

220130 155645   3.3 -13  1.27 18101593 CO8LY         FL20

220130 155645   2.4 -14  1.38 18101679 IK6HRB        JN63

220130 155645  37.1   2  1.10 18102310 G0DBE             

220130 155645   3.7  -8  1.07 18102404 CO6ABP            

220130 155645   4.7 -12  1.11 18102592 IK4MTK            

# ./recordings/ft8_7_21075500_220130_1556.c2

I've been trying to wrap my head around what's going on, as everything seems to work great running 4 spotters with the standard gateware into SparkSDR. 

73, 

Todd WV8U

[Yado-san]

Hi  Todd,

I checked the log at 15:56UTC with PSKrepoter.
The results show a shift between the actual received frequency and the frequency in the file name.
Another WV8U is decoded except on 20m, did you use a dummy load with minimum transmit power?

# ./recordings/ft8_3_7075500_220130_1556.c2　
220130 155600  14.0   9  1.45  7076267 WV8U          EM79        30m Sprius?
220130 155615  12.3  -1  1.24  7075302 KB3MXK                        30m

# ./recordings/ft8_4_10137500_220130_1556.c2
220130 155600  36.2  25  1.45 10137771 WV8U          EM79        20m Real!
220130 155615  20.5  -6  1.09 10136859 K8EB          EL97         20m
220130 155615  10.3  -4  1.37 10138234 KG4ASZ        EL98        20m

# ./recordings/ft8_5_14075500_220130_1556.c2
220130 155615  20.5  -6  1.09 10136859 K8EB          EL97         20m
220130 155615  10.3  -4  1.37 10138234 KG4ASZ        EL98        20m

# ./recordings/ft8_6_18101500_220130_1556.c2
220130 155615  28.9  -3  0.50 14074735 ND6H          CM97        17m
220130 155615  55.3   0  1.11 14075175 K8TE                              17m

# ./recordings/ft8_6_18101500_220130_1556.c2
220130 155615  15.0   3  1.12 18100969 EI8GS                             15m
220130 155615   1.7 -12  1.01 18101323 HB9TKS                            15m

I don't know why the receiving frequency is shifted.
What happens if  try to receive only one or two bands?

Edit:  recording-ft8.c
24 // NRX defines the number of channels. CL025 users can select 8 and CL016 can select 4 channels
25 #define NRX 2   // 2bands (1 to 8)                        
26
27 // FT8 Frequencies
28 u_int32_t freqArray[8] = {14075500, 21075500 };  //  Set Active bands first

Are you using Buster for RaspbianOS?

I tried it on the latest OS: Bullseye (R11:2021-10-30) and it did not work.
displayed:

      :
RB-Command = 01 Command = 00  command_data = 00000028
FT8-recording process...
FT8 recording timer started.
...........................................................　　<-- This line normally takes 59 seconds, but only 1.3 seconds (may be 192kHz sampling)
FT8 recording done, now writing to c2 files....
FT8 recordings written to c2 files. Ready for decoding.

$ lsb_release -a
No LSB modules are available.
Distributor ID:        Raspbian
Description:        Raspbian GNU/Linux 10 (buster)
Release:        10
Codename:        buster

: Newer OS:  Bullseye（R11）  2021-10-30

Yado-san, jg1twp

2022年1月31日月曜日 2:33:45 UTC+9 todd.bau...@gmail.com:

[Todd Baumgartner]

The transmit test I did was to an outside antenna from my Icom. At the same time, I'm running the Radioberry off of an indoor antenna just to have something for it to be able to receive.  I have been running on Bullseye, but just did a fresh install of Buster this morning to test some more.  I haven't seen the issue you had on Bullseye with the recording completing in seconds instead of 59.  I've been tweaking with running less than 8 NRX since then.  With 4 bands configured, I appear to be getting decodes in 3 of them, which line up with reports on PSKreporter., though the ft8_0 for RX1 isn't showing anything.  I'm going to continue testing. 

Thanks,

Todd

[Yado-san]

Hi Todd,

Looks like it's working well! now 8band ?   
> Radioberry 4k-Gateware does not seem to load correctly on Bullseye-OS.

Tnx.

Yado-san, jg1twp

2022年2月1日火曜日 3:15:41 UTC+9 todd.bau...@gmail.com:

[Todd Baumgartner]

Making progress, but still strange results when using NRX = 8, still getting results for the incorrect bands.  I've been running NRX = 6 for the last 12+ hours with decent results, but still some oddities.  I've modified the recording-ft8 code to shift the frequencyArray and initialize the radioberry to monitor different frequencies.  I've added some logging to get better statistics to help understand what is going on, so hopefully can analyze the data today, 

Thanks,

Todd  

--
You received this message because you are subscribed to a topic in the Google Groups "Radioberry" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/radioberry/nFEEvxCSzxY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to radioberry+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/radioberry/0b9083ad-ab56-4023-bdaa-cf3b33c58c74n%40googlegroups.com.

[Yado-san]

Hi,

I saw Rick/N1GP's 10RX solution (FB!) and tried a multiband FT8 decoder.
: https://groups.google.com/g/radioberry/c/uHp1jbpNQZQ 2022/02/02

I applied "receiver_ciconly.v" to a variant of radioberry_cl016 and compiled it.
: 6rx 0tx... Total number of logical elements 10,384 / 15,408 ( 67 % )
: 8rx 0tx... Total number of logic elements 13,414 / 15,408 ( 87 % )

installed SparkSDR on my RPi4B and checked the operation of 6rx_GW.
: It can decode up to 2RX.  (192kHz sampling fix)  Pict1
: 6RX did not receive at all with RPi4. Pict2

To make a small and simple multiband FT8 decoder, It seems to be better to use "receiver_4000.v".
ps. I guess it is a problem of firmware that rx1 can't decode, but I haven't analyzed it yet.

Yado-san, jg1twp

2022年2月1日火曜日 23:43:44 UTC+9 todd.bau...@gmail.com: