Conversion of WSPR decoder to FT8

[azwirko]

Hi again Pavel, the following is a continuation of a post I made awhile back

#629

Thanks for your advice, which I followed and I was able to successfully compile the latest WSJT-X 1.8 branch - https://sourceforge.net/projects/wsjt/files/wsjtx-1.8.0/ on the Redpitaya. I was then able to run the "jt9" command line tool with the "-8" option to decode a pre-recorded FT8 transmission (.wav file) - https://sourceforge.net/projects/wsjt/files/samples/FT8/ . The decode took ~1 second on Redpitaya.

My long term goal is to learn Vivado and FPGA, as well as use your WSPR code as a basis to create a multi-band FT8 decoder only, no transmit. Since FT8 seems more popular and there exists a propagation, mapping server called PSKreporter - https://pskreporter.info/pskmap.html , similar to WSPRnet.org , I am hoping to create a receiver to feed into this propagation reporting system.

So, if there is any chance you could answer some questions or point me in the right direction, or provide ideas, I'd much appreciate it, thanks! If this is too much, I completely understand as I'm just a beginner when it comes to DSP on FPGA.

Questions

1. Is using your WSPR multi-band decoder as a basis for my idea a good starting point, or do you recommend one of your others? As a starting point I would reset the multiple HF frequencies from WSPR to FT8 frequencies - http://www.qsl.net/sv1grb/psk31.htm

2. Would it be feasible and what would I need to change such that I could capture ~2500-3000 hz of bandwidth above a given FT8 base frequency, instead of the narrow band 375 hz that you are currently capturing for WSPR?

3. The above stated question implies a ~8x rate increase over your current operation. Do you think buffer sizes and write speeds will be exceeded with this requirement? See next question for buffer changes.

4. Can the buffer capture length / time be changed easily? The needed capture time at the above rate is only 13 seconds of data, instead of ~110 seconds for WSPR. I see you use system clock and cron to kick off process every 2 minutes. I would need to start capture at 0, 15, 30 and 45 seconds after the minute. Or to state differently, write a file at 13, 28, 43 and 58 seconds after the minute. So cron would not be usable, unless I start every minute and run 4 sequential decodes (15 seconds each). See next question for another issue regarding the file data format.

5. The wsprd decoder expects a complex .c2 data file. Do you think it would be possible in the FPGA to create a WAV file of the USB pass band? "jt9 -8" expects an FT8 audio file not a c2 complex file. It looks like you have an embedded transceiver, so does any of that project produce straight audio? I see there is a CSDR DSP library - https://github.com/simonyiszk/csdr that converts IQ to SSB (RTL example) so I guess I could do that conversion on the CPU, but was wondering what could be done on the FPGA. Are there any existing blocks/code?

Even if the Redpitaya could only decode 4 or 5 bands, I think that would still be useful tool for the community.

As far as the call sign, spot upload feature, WSJT-X already has the routines to send to PSKreporter, so that code I could reuse as is, once I extracted the data from the jt9 decoder.

I've enjoyed looking over your various project notes online and hope I can create something as useful for the ham radio community.

73

andyz - K1RA

[pavel-demin]

Hi Andy,

It's great that you've managed to build and to run the FT8 decoder. With the 1 second decoding time, it could be still possible to simultaneously decode several bands.

If I'm not mistaken, the FT8 decoder requires 12000 samples per second. I've just checked the code in ft8_decode.f90 and it looks like sync8 reads the samples at 12000 samples per second.

Since 12 kSPS can be obtained from 125 MSPS as 125e6/25/125/(5/3)/2, the parameters of the CIC and FIR filters in the multiband WSPR transceiver should be modified accordingly.

I've put together a make file that builds ft8d without building the entire wsjtx package but when I run ft8d it crashes because of a segmentation fault. It's a known problem:
https://sourceforge.net/p/wsjt/mailman/message/35940168/

So, looks like the FPGA configuration can be built based on the multiband WSPR transceiver project. It would be nice to find a working FT8 decoder that doesn't require building the entire wsjtx package.

Best regards,

Pavel

[pavel-demin]

I've just added a FPGA configuration with all the required modifications:
https://github.com/pavel-demin/red-pitaya-notes/tree/develop/projects/sdr_transceiver_ft8

[azwirko]

Pavel,

Thanks for the quick response and all the information and modifications. I believe the "jt9" binary is the executable we need to run for decoding FT8, I don't think the "ft8d" is up to date or supported. Here is a copy of the help output for "jt9" as run on my Redpitaya command line

https://docs.google.com/document/d/1FVfpCKlMhSnXaePuC9wQM8OY__xB7V4y-MRuvWZ9om4/edit?usp=sharing

As you can see the "-8" or "--ft8" options force decoding of FT8 mode WAV files using this 422K executable (see below). There are several other modes this can do as well "-6" JT65, "-4" JT4, "-9" JT9, etc.

Since I already built WSJT-X on my Redpitaya and installed in /usr/local, today I tar/gzip it up, which only includes just the WSJT-X files from the bin, include, lib and shared folders. I've made available for download if you wish to try running "jt9" on your system.

https://drive.google.com/open?id=1kKnrWl7XFr2fJ_uC3HLeuyrdAsUJn4zK

Then just do:

cp wsjt-x-usr-local.tgz /usr/local
cd /usr/local
tar zxvf wsjt-x-usr-local.tgz

And hopefully you will have all the needed binary files to try for yourself.

Thanks again!

andyz - K1RA

[pavel-demin]

Thank you for sharing the pre-built WSJT-X binaries. However, my point is to have a FT8 decoder that is easy to build and to modify. The examples of such decoders are wsprd by Steven Franke, K9AN and weakmon by Robert Morris, AB1HL.

BTW, the FT8 decoder by Robert Morris, AB1HL supports two sample rates 12 kSPS and 6 kSPS. It would be interesting to do some tests and to compare the performance of the decoder with different sample rates.

[pavel-demin]

I don't think the "ft8d" is up to date or supported.

You're right ft8d crashes because it's not up to date. I've just updated it based on the code from ft8_decode.f90 that is the code used by jt9.f90.

Now, I can build and run ft8d. Here is the repository with a minimal set of files required to build the FT8 decoder:
https://github.com/pavel-demin/ft8d

[pavel-demin]

I've tested the FT8 decoder with the .wav file from this links. There are 7 .wav files and 71 decodes. The decoding time is 32-33 seconds when the decoder runs on one CPU.

So, if the receiver works with 8 bands and the FT8 decoder runs on two CPUs, then the decoding time is around 20 seconds. Looks like the CPU isn't fast enough to decode 8 bands every 15 seconds. A solution could be to run it every 30 seconds.

[pavel-demin]

Do you think it would be possible in the FPGA to create a WAV file of the USB pass band? "jt9 -8" expects an FT8 audio file not a c2 complex file. It looks like you have an embedded transceiver, so does any of that project produce straight audio?

I think that this problem could be solved by slightly modifying the four2a calls in sync8.f90 and in ft8_downsample.f90. It should be enough to set the last argument to 1. The lines 27 and 56 in subtractft8.f90 should be also modified to work with the complex input samples. With these modifications, the FT8 decoder should work with the complex samples at 6 kSPS.

[azwirko]

I haven't compiled your ft8d decoder yet, but did download the zip file of WAVs you used and copied to the RP. I re-ran my earlier timing test, this round using the earlier "jt9" binary I sent and the command "time jt9 -8 170711*.wav" which represents all seven, 15 second decode sequences and got 65 decodes with the following time:

real 0m9.010s
user 0m8.870s
sys 0m0.090s

Full output here

https://docs.google.com/document/d/1VUiG6j6-yWv6NqbwLnl8rx0VrmNUnKbfOogdAR50fdU/edit?usp=sharing

I also ran just a single 15 second decode sequence WAV file and got

root@rp-f01e82:~# time jt9 -8 170711_215815.wav
215815 -12 0.6 630 ~ KC3DGM ON3MK -16
215815 -1 0.9 775 ~ MJ0LEL IK3FUS R+00
215815 -17 1.2 950 ~ CX1RK NS9I EN64
215815 -5 1.1 1011 ~ EA1AHY K1HTV -15
215815 -8 1.0 1062 ~ VK4WTN DF9OX R-11
215815 -20 1.1 1155 ~ EK6RSC G1GIL R-04
215815 -6 0.6 1371 ~ YO2NAA K8YAH EN80
215815 -9 0.6 1421 ~ CQ IV3DXW JN65
215815 -7 1.2 1785 ~ CQ YI3WHR LM22
215815 1 0.2 2018 ~ CQ ON3BZ JO20
215815 -12 1.1 2094 ~ KB6IBB W4AS 73
0 11

real 0m1.353s
user 0m1.300s
sys 0m0.050s

I'm not sure why yours is taking so much longer, but will compile and re-run tests to validate here.

Thanks for all your help and work to get this system closer to operational.

[pavel-demin]

Thanks for checking the timings. I've just found that I can reproduce your result if I set the ndepth parameter to 1. If I set it to 2, then the decoding takes much longer:

ndepth	decodes	time
1	65	8
2	71	38

[pavel-demin]

Since we now have a standalone FT8 decoder and the timings are OK, I think that the next steps are

• modify the FPGA configuration to output the complex samples at 6 kSPS (easy),
• modify the FT8 decoder to work with the complex samples at 6 kSPS (hard).

[azwirko]

Pavel,
Thanks for the next steps. I will look at the FT8 decoder first, and the WSPR decoder which used complex samples. Hopefully I can use that as a basis to figure out how to make the FT8 work the same way.

andyz

[pavel-demin]

Hi Andy,

I tried to modify the FT8 decoder but it turned out to be less trivial than I thought while I was writing my previous comment. The structure of the code isn't very uniform and some parts of the code are parameterized differently than some other parts. Some parameters are centrally defined in ft8_params.f90, some parameters are hardcoded in ft8_downsample.f90 and in subtractft8.f90. After several unsuccessful attempts, I put it on hold for a while.

Best regards,

Pavel

[azwirko]

Pavel,

OK, understand and appreciate your efforts on attempting to convert the FT8 decoder. Would the FPGA code still be able to generate 6000 sps and write to the memory buffer space similar to WSPR? If so, I would like to at least be able to read that into Linux space and then play with CSDR library to convert to USB and then WAV to attempt using with the existing jt9 executable.

If not, then I guess it'll have to wait until I become more fluent in Vivado, FPGA and able to take it on myself.

Take care

andyz

[pavel-demin]

Just noticed that I wrote too many zeros in some of my previous comments. It's fixed now.

Would the FPGA code still be able to generate 6000 sps and write to the memory buffer space similar to WSPR?

I don't think that the existing jt9 executable requires the 6000 SPS sample rate. The current version of the FPGA configuration outputs the complex samples at 12 kSPS. The unmodified FT8 decoder works with the real samples at 12 kSPS. So, the sample rates are OK.

If so, I would like to at least be able to read that into Linux space and then play with CSDR library to convert to USB and then WAV to attempt using with the existing jt9 executable.

I'd say that using CSDR for converting complex samples to real samples is an overkill. Just take every other sample and that's it. It can be done either in the program that reads the samples from the FPGA or in the FT8 decoder.

If not, then I guess it'll have to wait until I become more fluent in Vivado, FPGA and able to take it on myself.

Maybe it wasn't clear from one of my previous comments but the FPGA configuration is ready:
https://github.com/pavel-demin/red-pitaya-notes/tree/develop/projects/sdr_transceiver_ft8

What is needed is some C or Fortran code to efficiently decode the FT8 signals. Would you be interested to do some coding for this project or do you expect me to write all the code?

[pavel-demin]

I've just tested the FPGA configuration with the FT8 decoder and they seem to work well together. I can see many decodes. Here is a link to the SD card image that I'm using:
https://www.dropbox.com/sh/5fy49wae6xwxa8a/AACLW3qmAFX7mIUsNZxiiVJOa/sdr/red-pitaya-alpine-3.6-armhf-20180331-ft8.zip?dl=1

The application starts automatically at boot. The decodes can be seen in /dev/shm/decode-ft8.log. Since it's just the very first working prototype, some functionality is still missing. Pull requests with improvements are welcome.

In this version, the FPGA configuration outputs the real samples at 12 kSPS and the FT8 decoder reads them at 12 kSPS. However, I still think that it would be better to switch to the complex samples at 6 kSPS.

[pavel-demin]

Here is a new version:
https://www.dropbox.com/sh/5fy49wae6xwxa8a/AABWCGvJtMydxGMYqpII7VcHa/sdr/red-pitaya-alpine-3.6-armhf-20180401-ft8.zip?dl=1

In this version, the FPGA configuration and the FT8 decoder both work with complex samples at 12 kSPS. The number of decodes doubled.

[pavel-demin]

Finally, I have a version that works with the complex samples at 4 kSPS. With this sample rate, the FPGA configuration contains only one FIR filter:

I've started to put together some notes about this project:
http://pavel-demin.github.io/red-pitaya-notes/sdr-transceiver-ft8

[azwirko]

Pavel,
First, happy Easter. I'm just returning from a long weekend with the family and visiting in-laws. Let me say - Wow! And thanks again for the work and documents. I did not expect you to do any of this. I do expect to work on some level of coding, but as I mentioned its a long term project for me to better understand FPGA, Vivado, etc. I grew up learning FORTRAN in high school and college and also have worked with C earlier in my professional care, but I'm an systems engineer at heart and mostly enjoy the hardware aspect of systems. When I usually write code its for my eyes only,, but I hope to be able to write at a level to share with the wider community. That means I need to learn to document better :) Again this is all a goal of mine. Family, work then radio...

Best regards,

andyz - K1RA

[pavel-demin]

I've modified write-c2-files.c to record 236000 complex samples at 4000 samples per second. This way, it records the four 15s transmission periods every minute and can be started by cron once a minute. With this new version, I see more than 200 decodes per minute and more than 10k decodes per hour.

If you want to give this new version a try, here is a link to the new version of the SD card image:
https://www.dropbox.com/sh/5fy49wae6xwxa8a/AABFgDgTsFkDqAZnRc3g8iAFa/sdr/red-pitaya-alpine-3.6-armhf-20180403-ft8.zip?dl=1

Looks like the only missing part is an uploader to a remote database.

[ZL3IO]

Great job again, Pavel! Thanks.

This is from the skimmertalk reflector:
The Reverse Beacon Network (RBN) is starting to incorporate FT8 spots. According to a post by Pete, N4ZR, "We have three Skimmers running an experimental Aggregator that receives UDP messages from WSJT-X and forwards FT8 spots to the RBN...many rare DX stations never explicitly repeat (their) CQs. To get around this, Dick, W3OA, has programmed the Aggregator to respond to a unique standard FT8 message format that is always associated with stations being called, rather than those calling them. We label these as CQ spots, though we're aware it's a misnomer."

May be that does already what you need to upload spots.
Cheers Holger, ZL3IO

[pavel-demin]

Hello Holger,

I've looked at the WSJT-X's UDP protocol description at

https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/NetworkMessage.hpp

and at the Qt serialization algorithm at

https://github.com/qt/qtbase/blob/5.11/src/corelib/serialization/qdatastream.cpp

Looks like this protocol is quite easy to implement. I'll try to add it to the FT8 receiver application for Red Pitaya.

Best regards,

Pavel

[azwirko]

For comparison, or as an alternative, PSKreporter at https://pskreporter.info/pskmap.html uses a format that can be found as implemented in

https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/psk_reporter.cpp

and

https://sourceforge.net/p/wsjt/wsjt/HEAD/tree/branches/wsjtx/psk_reporter.h

which is discussed in detail here

https://www.pskreporter.info/pskdev.html

andyz - K1RA

[azwirko]

Pavel,
Downloaded and running your image and I'm also seeing ~200 decodes per minute - WOW! I've been running since 0000 GMT and decoding signals on all 8 bands from 160m through 15m - NICE!

andyz

[azwirko]

For those who want a single, local network, CW Skimmer-like, DXcluster accessible stream for the FT8 decoder, for use with programs like RXClus by HB9BZA http://www.hb9bza.net/rxclus-overview - I've got a simple awk script that can be used with the Redpitaya's onboard 'tail' and 'nc' commands to provide a TCP listener which you can Telnet too, or point your favorite DXcluster client at. It can be downloaded here

https://drive.google.com/open?id=15wYQwUah1JFLNotUkglsY_2mUNiuFbcR

Once you SCP to the RP set execute permissions

rp-f01e82:~# chmod 755 ./ft8-skimmer.awk

Then start by using following command line

rp-f01e82:~# tail -f /dev/shm/decode-ft8.log | ./ft8-skimmer.awk | nc -lk -p 7373

Then from your favorite PC client either get the redpitaya IP address and

telnet redpitaya 7373

or put redpitaya:7373 in your DXcluster client app

And you should start seeing CQ only spots like this

DX de K1RA-#:    18101.4 N7MDW      FT8  -9 dB CN94 CQ    1805z
DX de K1RA-#:    18101.9 WJ6T       FT8  -7 dB DM05 CQ    1805z
DX de K1RA-#:     7075.2 N9YBK      FT8  -4 dB EN61 CQ    1806z
DX de K1RA-#:     7075.2 N9YBK      FT8  -3 dB EN61 CQ    1806z
DX de K1RA-#:    10137.0 KF6NFW     FT8 -15 dB EN12 CQ    1806z
DX de K1RA-#:    10136.8 K1LOL      FT8  -1 dB FN34 CQ    1806z

This method currently only supports a single TCP inbound connection.

73

andyz - K1RA

[F1EYG]

Very nice job
I testing the last version xxxxx403
verticale antenna directly connected to IN1 without any adaptation
120 spots decoded for 1mn interval recording :-))
73
Sylvain F1EYG

[azwirko]

I'm no programmer, but I've recently written a few other scripts (in PERL) that parse the /dev/shm/decode-ft8.log file. One script creates a WSJT-X UDP compatible stream that will feed GridTracker - https://tagloomis.com/ and the other will post to PSKReporter - you can see what my Redpitaya is copying over the last 15 minutes here:

https://pskreporter.info/pskmap.html?preset&callsign=k1ra&txrx=rx&timerange=900

You can change the time frame to see more.

If anyone is interested in playing with these scripts let me know. I hope to convert over to C at some point, but if you can get PERL loaded on your RP, I'd be happy to share and let you give it a try. I've been running the decoder and scripts on my RP running Ubuntu 16.04.3 LTS Red Pitaya GNU/Linux Ecosystem V0.98 Build 617

andyz - K1RA

[kng]

@azwirko
I would love to try the perl script for pskreporter, I was thinking of cobbling together something of my own (.pl/.py) but doing it directly in C would take quite some time...
Support for pskreporter directly in this project would be absolutely fantastic.

[pavel-demin]

Hi Andy,

Have you managed to implement the following requirements listed at https://pskreporter.info/pskdev.html?

• Ideally, a callsign should be reported only once per hour if it has not 'changed'.
• The datagrams should be sent at a rate of no more than one every five minutes (unless the packet becomes full).
• Timed sends of packets must not be synchronized to the system clock.

Best regards,

Pavel

[azwirko]

Pavel,
I've managed to get call sign deduplication implemented within a single minute and was otherwise just happy to get the datagram in the right format and implemented such that PSKReporter was accepting my packets. There sometimes is a need for more than one datagram with the raw number of unique call signs. I still have some work to do as this is surely just a prototype. I will hold off publicly posting a link to what I'm currently using so the PSK server doesn't become overburdened.

I can easily buffer 5 minutes worth of data before I send it and will work on that next. Randomizing the post timing with some sort of delay shouldn't be too hard to add as well. More to follow.

Regards

andyz

[F1EYG]

Tks again Pavel and Andy for your investment in these project :-)) Andy i am not a specialist in programmation, but i am ready to testing the pskreporter upload script, i running the standalone Alpine version of Pavel software. 73 Sylvain F1EYG

[waterwin]

Suggest to start a separate Issue for this 77-bit conversation, as I just did ;-)

PE3ES / Erwin

[pavel-demin]

Thanks for the .c2 files. They'll help me to test the new version of the FT8 decoder.

[pavel-demin]

I've updated the FT8 decoder. It now works with the new 77-bit message protocol. Here is a link to a pre-release version of the SD card image:
https://www.dropbox.com/sh/5fy49wae6xwxa8a/AABengS13sFNTOft2c0vnk33a/red-pitaya-alpine-3.8-armhf-20181215.zip?dl=1

[azwirko]

Running the new image and it appears to be working. Here are my decodes of 2.0 packets for the last hour:

https://pskreporter.info/pskmap.html?preset&callsign=k1ra&txrx=rx&mode=FT8&timerange=3600&hideunrec=1

I may attempt to run the old decoder as well in an effort to catch WSJT-X users who haven't converted over to the new version. Not sure there is enough horse power on the ARM for this though.

[waterwin]

You could always modify the ft8.cron to run the new decoder even minutes and the old one the uneven or any other timing combination. I have a cron that switches between the antennas every 15 minutes and changes Day frequencies to Night frequencies and vice versa. I have 2 upload.sh to differentiate the results on PSKReporter as well. See F/PE3ES-1 and -2 Erwin de PE3ES

[waterwin]

To see propagation of the new 2.0 version of WSJT-x https://pskreporter.info/cgi-bin/pskstats.pl End of the page, General. General The following software was used over the last seven days. Many older versions still being used as well. de PE3ESErwin

[SM6FMB]

I know very little about writing Linux commands/files. I am a Windows man!

Some help would be appreciated with:

1. Modify the ft8.cron to run the new decoder even minutes and the old one the uneven or any other timing combination.

2. Cron that switches between antennas, time and day of the week. RP has only 2 antenna input! Could it be arranged with external device to handle 6 antennas in the same way?

3. I am little worried about temperature. Is there a way to have a temperature on-line/live monitor in Windows?

[azwirko]

waterwin - I've actually got both decoders running off the same set of .c2 files every minute. I had to modify decode-ft8.sh to handle running the older v1.x decoder. You can see my modified script here:

https://www.dropbox.com/s/wxupfhdpp9ucqms/decode-ft8-v2-1.sh?dl=0

It doubles the decode time from ~15 secs. to ~30 secs. Note I also made some other modifications and comments in that script to support several PERL scripts I'd written for the older v1.x decoder and converted for use with the new v2.0 decoder.

I've update my dxc.pl (DXCluster server) and jtudp.pl (JTUDP packet broadcast) PERL scripts to handle the new .txt file structure Pavel uses for saving date/time and calls/grids. These new PERL scripts are here

JTUDP - https://github.com/azwirko/perl-jtudp-v2
DXCluster - https://github.com/azwirko/perl-dxc-v2

Along with having to install PERL on the RP, you also have to use my modified decode-ft8.sh script above. This prints a few extra lines in /dev/shm/decode-ft8.log so I know when the .txt decode files have been completely written.

Note if you use GridTracker https://tagloomis.com/grid-tracker/ with my JTUDP script, unfortunately the map no longer shows different color grids since Pavel new log format no longer saves the actual decoded FT8 message copied off the air. It now only saves a call and/or grid of the transmitting station. It still makes for a nice real-time, local mapping system without need for waiting for PSKreporter.

[F1EYG]

Hello all
Tks for these new version :-) i think be again on air today with the new script from Andy
waterwin could you share or mail your script ?
Tks 73 from F1EYG

[pavel-demin]

There is now a release that includes the updated FT8 decoder:
https://github.com/pavel-demin/red-pitaya-notes/releases/tag/20181218

[F1EYG]

Hello Pavel What is difference with 20181215 ? Tks

[pavel-demin]

What is difference with 20181215 ?

The FT8 application is the same in both versions.

I've just updated the Linux kernel and some links in the vna and mcpha applications.

[F1EYG]

Tks :-)

[F1EYG]

Hello i testing your version with double decoding 1&2, all working but the decode_xxxxx .txt is strange at the end i have i lot of records with an incorrect time like these : ... 0_1812 1_1400 45.6 0 0.27 3574371 OZ2LP JO55 0_1812 1_1415 3.9 -15 -0.16 3573849 RA4FEQ LO13 0_1812 1_1415 13.0 -7 -1.45 3573940 RA2FCL KO04 0_1812 1_1430 27.9 -4 0.29 3574371 OZ2LP JO55 0_1812 1_1445 5.0 -14 -0.16 3573849 RA4FEQ LO13 ... all other records arent correct : ... 181221 143945 17.2 21 -0.19 14075095 SP7TF KO01 181221 143945 26.4 0 0.00 14075365 K3WW 181221 143945 25.2 2 -0.11 14075660 RX4CD LO22 181221 143945 68.8 1 -0.94 14075797 SP1JQJ 181221 143945 44.8 13 -0.05 14075875 RK4FD LO22 181221 143945 2.7 -12 0.06 14076072 W9DUB ... the stations corresponding arent not reported on psk and when i test the call, these station using 1.xx version of FT8 have you the same probleme ? Best regards ans 73 F1EYG

[pavel-demin]

Looks like the old decoder is too old and it's incompatible with the current filename format.

I'd suggest to use the old FT8 decoder from the 20181022 release.

[F1EYG]

Sorry...........................;-( Forget my last post i using a wrong version of old FT8 decoder (20181020) i change for 20181022 and all records arent correct ;-)) System running with day/night band selection and decoding V1&2 I stay like this for 24 hours :-)) and look the result on psk PS i see the numbers of pitayauser growing from 8 to 26 ! Best regards F1EYG

[F1EYG]

Yes Is allready done ! system working Tks 73 F1EYG Le ven. 21 déc. 2018 à 16:19, Pavel Demin <notifications@github.com> a écrit :

…

Looks like the old decoder is too old and it's incompatible with the current filename format. I'd suggest to use the old FT8 decoder from the 20181022 <https://github.com/pavel-demin/red-pitaya-notes/releases/tag/20181022> release. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#689 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APItdymTJqylBFI1MNpTRjaKfTUuNkZaks5u7PwFgaJpZM4S5LTA> .

[ZL3IO]

Hi Pavel & all
HNY 2019. I installed the last SD card image and tried to get it running. Where can I see if the software actually does anything? I assumed there would be some report file written but I'm unable to identify any.
Thanks in advance
Holger, ZL3IO

[azwirko]

Once you remote access the Redpitaya using SSH and default username and password of root and changeme , you should change directory to /dev/shm by doing a "cd /dev/shm" and then after a few minutes look for files being created there once a minute. You can use "ls" to list new files. You will being to see date/time stamped .txt files which should hold decoded call signs. Use the "more filename.txt" command to view the contents.

73 & HNY
andyz - K1RA

[pjsg]

I looked at the pskreporter logs, and it turns out that there are bunch of "<...>" callsigns being reported. There isn't much point in sending these....

[waterwin]

Can you post one of the files that is doing this please. The scripts do not start sending spots if there is no callsign in the script. The callsign doing the reporting is important. Might help in debugging. Also for instance the "antenna descriptor" or the system "using" it comes from. My own callsigns by the way F/PE3ES-1 and -2 reported almost 50.000 spots to your wonderful website and I have as antenna descriptor "test for 77 bit". The report itself could contain composite callsigns or other specials.

But these are normally reported well:

190121 093830 12.7 -5 0.20 10137499 SM5DAJ JO89
190121 093830 32.9 16 0.08 10136866 SM7CAD
190121 093830 10.0 1 -0.41 10136992 LY2FN
190121 093830 16.7 -4 0.29 10137290 IT9/DJ0OP/P
190121 093830 67.0 13 -0.73 10137669 EA1HK
190121 093830 10.2 -1 0.08 10137777 OH2BMH KP20
190121 093830 5.3 -10 -0.06 10137917 R1CW KO49

But I also found this:
190121 093300 55.0 17 0.06 14075182 UR5RGS KO51
190121 093300 18.0 9 -0.01 14075286 ER1PB
190121 093300 6.3 -10 0.35 14075928
190121 093300 16.0 -4 -0.46 14075977 JA1PFP PM95
190121 093300 6.9 -10 -0.03 14076106 RU6YJ
190121 093300 2.3 -14 0.81 14076157 US0MS
190121 093300 18.7 -9 0.82 14076203 UA1QDZ KO99

73 de Erwin
PE3ES

[pavel-demin]

I've checked the .c2 files (ft8-c2-3573.tgz) provided by Andy and found some decodes with the <...> callsign.

Here are some examples:

ft8_1_3574500_181213_0324.c2
181213 032415  45.4  -1  0.07  3573338 <...>
181213 032445   9.1  -5  0.08  3573338 <...>

ft8_1_3574500_181213_0325.c2
181213 032515  61.5   1  0.06  3573338 <...>
181213 032545  22.9  -5  0.06  3573338 <...>

ft8_1_3574500_181213_0326.c2
181213 032615  16.1  -2  0.04  3573338 <...>
181213 032645  11.7  -5  0.06  3573338 <...>

ft8_1_3574500_181213_0331.c2
181213 033115   3.3  -5  0.05  3573338 <...>
181213 033145   3.4  -5  0.02  3573338 <...>

[pavel-demin]

Here is how the FT8 message with the <...> callsign look like:

4Z4DX <...> R-24

[pavel-demin]

I think that it should be enough to filter out all the callsigns starting with <.

Here is a link to the corresponding commit:
pavel-demin/ft8d@6117fb2

[pavel-demin]

But I also found this:
190121 093300 6.3 -10 0.35 14075928

The empty callsigns are filtered out now:
pavel-demin/ft8d@53f062c

[pavel-demin]

There is now a release with the updated FT8 decoder that filters out empty and <...> callsigns:
https://github.com/pavel-demin/red-pitaya-notes/releases/tag/20190215