FT8 Operations

205 views
Skip to first unread message

Thomas Beiderwieden

unread,
Jun 18, 2021, 6:48:59 AM6/18/21
to SparkSDR
Hi Group,
when looking at the SparkSDR manual re FT8, it reads "Clicking a received CQ message will fill in the reply macros and start the transmission." My experience is, that when you do this, the transmission does not start instantly, but in the next 15s slot. This then will crash with the called station.

What am I doing wrong?

vy 73 de Thomas, DL3EL

ahop...@googlemail.com

unread,
Jun 19, 2021, 3:23:29 AM6/19/21
to SparkSDR
Hi Thomas,
Improving the ft8 experience is next on my list, it was really written for JT9 where everything happens at a more gentle pace.
What maybe happening in this case is that if you are more than three seconds into the 15s it waits for the next slot.  
I have a few ideas to make it better.
73 Alan M0NNB

Thomas Beiderwieden

unread,
Jun 20, 2021, 11:39:26 AM6/20/21
to SparkSDR
Hi Alan,
thanks a lot. Happy to beta test, when available. Did a small donation :-)

vy 73 de Thomas, DL3EL

Brock Nanson

unread,
Jun 21, 2021, 1:02:51 PM6/21/21
to SparkSDR
I'm glad I happened across this exchange... I thought I was doing something wrong, but there isn't much to configure for FT8! ;-)

I set this up literally yesterday while playing around with different SDR applications and found the same issue as Thomas.  I also found that once I clicked on that CQ, every time increment of decodes would be inserted above the highlighted CQ and there was no apparent way to have the window automatically scroll to follow the new decodes.  In other words, I would see the CQ highlighted, dead center, with all the new decodes out of view above.  I can scroll up to see them, but unless I click another (and trigger a transmit cycle), the window simply refreshes back to the original highlighted CQ and all the new ones are again out of view.

I'm wondering if there's something I need to set in Spark, or within WSJT-X, or it's just a bug?

73,

Brock
VA7AV

ahop...@googlemail.com

unread,
Jun 23, 2021, 8:34:39 AM6/23/21
to SparkSDR
Hi Group,
there is a very early beta here https://www.sparksdr.com/download/sparksdr2_0_7_5_win64.zip with a changed ft8 gui.
There is now a history display (the old layout) and an operating display.
In the operating display spots should appear sooner and are written down the screen so they do not move about as new ones are added, only spots for the last slot are shown.  To the right of it the current QSO is shown. It should behave better in transmitting in the correct slot if you are either early or late.
I shall add auto sequencing as described in the QEX article but it is not ready yet.

There is quite a lot of code change in this as I refactored out a lot of code to share between FT8,FT4,FST4,JT9 and JT65 so may well have broken stuff.

I'm pondering logging and things like filtering the spots by things like already QSO'd, country not yet logged etc.

I guess the serious contester is likely to use WSJT-X so my aim is to make it just fun and easy in Spark.

All thoughts welcomed

73 Alan M0NNB

Thomas Beiderwieden

unread,
Jun 23, 2021, 11:38:36 AM6/23/21
to SparkSDR
Hi Alan,
just a quick update on the first tests with 2.0.7-5. After executing the program initially, I instantly had a qso on 15m, that worked perfekt. 
The timing to catch the correct slot, when answering a cq-call seems to be ok. Then I switched to FT4. Nothing was decoded. Data was visible in the waterfall, 
but no decode. A quick switch (only "power down" the HL2) back to 2.0.7-4 on my raspberry showed, that the visible signals were FT4 stations. 

Then back to FT8 I did not manage to complete a single qso. I answered a cq, station came back with snr and I replied with snr. Then station again send RST. My snr was between -04 und +02 
on the other side. So I assume something with the decoding. However, as I see some odds on my trx signal, would it be possible to compile a raspberry version? Reason is, the HL2 together with the RPI4 is sitting in the attic, connected to the same network switch. The PC I am using in my shack is in a network, connected via Wifi to the attic. I just want to exclude network effects here. 

There is another thing. When you first click on the CQ, the right table is filled with qso data. When during qso, the snr changes, the table is not updated. When you than click again on the received data, the snr is not updated, but the left table is filled. (see screenshot). Is that intended?

vy 73 de Thomas, DL3EL


ft8.jpg

ahop...@googlemail.com

unread,
Jun 23, 2021, 2:10:47 PM6/23/21
to SparkSDR
Hi Thomas,
thanks for the report, FT4 was broken, fixed for the next beta.  The snr on the macros is only filled in when you click a signal which should only be once per qso i.e. either a cq or a reply to your cq, perhaps I could update it but it made sense it was the snr for the signal you started replying to.

Perhaps the lines in the qso list should not be clickable.

Not sure about the failed qso, I'll do a rpi build once the auto seq is done.

73 Alan M0NNB

Mike Brown

unread,
Jun 23, 2021, 6:31:51 PM6/23/21
to spar...@googlegroups.com
Resending this to the Group, as accidentally sent direct to Alan:

Hi Alan

I think the reason for the failed qso may be a missing + in Thomas's response to 9A2KS, which should have been R+14, not R14.

Although I downloaded the Beta I haven't had time to have a play with it myself much. I'll try to have a go with it in the morning.

I'm successfully using WSJT-X via a couple of virtual audio cables (which was far easier to set up with Spark than PowerSDR). it would be great to be able to have QSOs just with SparkSDR though, if only for /P use. A few comments from what I've seen so far:

I like the flags but TBH I'd prefer country names as I don't recognise many flags!
A realtime UTC clock would be really useful, to minimise the risk of clicking on an 'out-of-date' CQ call.

Other 'wants':
Auto-sequence of course
Call 1st
Wider TX bandwidth if possible. The older version 3dB bandwidth appeared to be 300Hz-2850Hz in DigiU mode. DX hides below and above those frequencies!

Obviously a few of us have made donations but I can't imagine it will have added up to more than an hour or two of your time. It is great that you're so responsive but don't forget the day job!

Best regards

Mike
G4RAA

--
You received this message because you are subscribed to the Google Groups "SparkSDR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sparksdr+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sparksdr/b5c6cbc0-158f-40c3-ad13-e057f80f47bdn%40googlegroups.com.

J P Watters

unread,
Jun 24, 2021, 12:30:27 AM6/24/21
to SparkSDR
Alan,

Reading the sparksdr updates, it appears that 2.0.7.5 has been released for testing. And an update to that version has already been made. 

Can you release a version for OSX for testing when you release the next beta for testing. ie 2.0.7.6??

..jpw J P Watters
KC9KKO
Morris, IL USA

ahop...@googlemail.com

unread,
Jun 24, 2021, 2:44:19 AM6/24/21
to SparkSDR
Hi Mike,
good spot on the +,  my encoder should still encode it correctly but maybe not, I'll change the macro to be correct.
In the new view there should not be out of date signals to click.
For info the flags are derived from the callsign rather than the locator. My thought was to keep this bit of display as simple as possible as you have such a short time to select things, I did play with graphical displays for snr and distance. I am wondering about an option to only show CQs and responses to your CQs.

A tidy up of the digiu/l modes is on the list, probably with control of the tx filter, a tx signal level meter and maybe a tx filter disable option.
73 Alan M0NNB

ahop...@googlemail.com

unread,
Jun 24, 2021, 2:49:24 AM6/24/21
to SparkSDR
Hi jpw,
this was a very early beta with lots untested and broken, once I'm happy the basics are ok I'll build for the other platforms.
73 Alan M0NNB

Brian VK4BAP

unread,
Jun 24, 2021, 5:37:32 AM6/24/21
to SparkSDR
Hi Alan,
If you are looking at digiu, I don't know about the tx filter - I didn't know there was one but why is the rx filter not flat.
To receive 300 to 3000 Hz band, I always set the filter to be 0 to 3300 Hz otherwise the edges 300-600 and 2700-3000 show a lot of noise.
Perhaps the default should just be 0 to 3300.
73 Brian.

Mike Brown

unread,
Jun 24, 2021, 6:04:22 AM6/24/21
to spar...@googlegroups.com
Sounds great Alan.

The 'only CQs' option would be very useful but I see it as something you might switch in and out fairly frequently as a DX station might not call CQ very frequently if at all. I find myself looking for 73 as much as CQ!

I forgot to add to my wishlist 'worked before' status (same mode/band). It would need to be optional I think, as it might introduce unwanted latency depending on platform.

73

Mike



ahop...@googlemail.com

unread,
Jun 24, 2021, 6:32:23 AM6/24/21
to SparkSDR
Hi Mike,
just trying to get a feeling for how people operate, what do you do when you see a 73, I guess I could trigger a cq if you clicked on a 73.

73 Alan

ahop...@googlemail.com

unread,
Jun 24, 2021, 6:59:15 AM6/24/21
to SparkSDR
Hi beta testers
https://www.sparksdr.com/download/sparksdr2_0_7_6_win64.zip has ft4 fixed and the + sign in the response that I think was causing an issue. Again just a quick test release.
73 Alan M0NNB

Mike Brown

unread,
Jun 24, 2021, 7:14:53 AM6/24/21
to spar...@googlegroups.com
Hi Alan

In that situation. I'd be calling the station that said 73. Usually working split, so no problem for him to see a 73 from the other station as well as my call. 

BTW the preference would be to go into TX (in the correct cycle of course), even if clicking very late on a CQ call. Sometimes he'll decode it anyway. Other times, especially on a quiet band when I'd use simplex, he'll at least know there's someone trying to come back to his call.

Sorry, another want. There has to be a way of stopping TX. I'm not certain that feature was present in the earlier version.

I'm tied up most of the day but will try to have a look at the latest beta tonight.

73

Mike


Thomas Beiderwieden

unread,
Jun 24, 2021, 7:40:45 AM6/24/21
to SparkSDR
Hi Alan,
quick feedback: FT8 works now, qso completed. FT4 RX does not decode, having tested every decode depth. For an FT4 TX, I  have got a pin in pskreprter.

vy 73 de Thomas, DL3EL

ahop...@googlemail.com

unread,
Jun 24, 2021, 10:46:50 AM6/24/21
to SparkSDR
Hi Mike,
so what would your first message be on seeing a 73?  It is on the list to check what the cancel button does.
Alan

ahop...@googlemail.com

unread,
Jun 24, 2021, 11:00:57 AM6/24/21
to SparkSDR
Hi Thomas,
good to hear qso's work, ft4 problem is odd, I'm running it now and you can probably see my FT4 spots on 20m on pskreporter, is there anything in the error logs?
73 Alan M0NNB

Thomas Beiderwieden

unread,
Jun 24, 2021, 7:04:20 PM6/24/21
to SparkSDR
Hi Alan,
I think my answer earlier tonight was lost. FT4 problem solved, my fault. Clock on PC was not correct. After adjustment, FT4 works.

vy 73 de Thomas, DL3EL

Mike Brown

unread,
Jun 24, 2021, 7:07:22 PM6/24/21
to spar...@googlegroups.com
Hi Alan

I had a little time to play with 2.0.7.6 tonight. The great news is that I managed to complete a 40m FT8 QSO. Perhaps unsurprisingly I have a few comments:

1 Clicking Tune radiated a carrier on 7.074 dead, rather than my selected transmit frequency. Maybe that isn't a bad idea but just might be a problem for someone trying to tune up a very narrowband antenna like a magnetic loop.
2 I couldn't see all the text in the QSO sequence boxes (eg SP2EWQ G4RAA RP). Possibly related to my default Windows fonts? (See screenshot)
3 The WSJT-X manual may be a bit misleading. Most operators either send R73 or RRR plus another TX sequence with 73 in it (the RRR/73 sequence seems to be more common with US operators). I think the manual may suggest the CQ'ing party ends with RRR but I don't think that is common practice anywhere.
4 Not having a clock, or time in the operating view window, makes it difficult to make sure you press the right TX button at the right time!
5 Calling CQ - this should stay activated until either a) I make a contact, b) I cancel TX or c) a (5 min?) watchdog cuts it off.
6 When trying FT4 I was stymied a lack of activity but I did notice the blue 'progress bar' was going at the same speed as for FT8 ie 12.64 sec (+ processing time = 15 sec). It should be 4.48 sec (+ processing time = 6 sec).
6 Running 3.8W on my HL2 while calling CQ, I got a +5 report from the east coast of the States on PSKReporter. This is clearly the SparkSDR effect, where signals are conveyed losslessly to their destination. Keep up the good work!

All IMHO. Others may have their own thoughts.

Best 73

Mike
G4RAA

2021-06-24.png

ahop...@googlemail.com

unread,
Jun 25, 2021, 3:50:41 AM6/25/21
to SparkSDR
Hi Mike,
thanks for all the feedback, all very useful. I shall turn myself into a FT8 operator over the next few days:)  
The tune thing is true for all modes, I'm surprised no one has mentioned it before, it was near the bottom of the list as a todo if needed.
The cut off text is due to swapping the Avalonia theme a while ago, there are a few other cut off bits around to tidy up.
I think I'll make the macros editable, we can then agree the defaults.
Adding a clock is not a problem, I had been pondering some sort of odd/even indicator.
The blue progress bar goes the correct speed for me so I need to look at that.
A long term plan is to make the map better, that could include clicking on spots on the map to qso.

73 Alan M0NNB

ahop...@googlemail.com

unread,
Jun 25, 2021, 3:52:25 AM6/25/21
to SparkSDR
Hi Thomas,
thanks, good to know.
73 Alan M0NNB

Reply all
Reply to author
Forward
0 new messages