Hi Ron, the two things I’d like to see in the final release of FT8 are actually two removals. Removal of the option on screen to make tx and rx the same frequency and the double click action on a station calling CQ should be changed to work the same as alt+ double-click (i.e. again don’t move your Tx frequency). In this mode, it is the “norm” to work split, working on the same frequency as the station you are calling - albeit in the opposite time slot, creates problems for other calling stations and the station being called. The software scans the complete waterfall frequency range for a reply, so you don’t need to call on the CQing stations frequency.
I do not agree that split frequency working should be “the norm” on FT8. It actually causes more problems than it solves.
It means that each QSO occupies two frequencies on an already-crowded band.
Worse, stations who reply to a DX station using “split” will call on a random frequency, giving no consideration to QSOs already in progress. I have frequently lost contact with a station I am already working because someone else suddenly starts calling “split” for a DX station right on the frequency of my QSO. Sometimes, the band becomes full of people all calling on different frequencies for the same “rare” station. It is selfish and counter-productive.
In my opinion, it would be a much preferable solution to improve the software to enhance its performance in picking out callers from a pile-up on the same frequency. This has already been done to some extent with Ver. …rc2, which now has two-pass decoding. The Russian JTDX program has gone farther on JT65, with multiple pass decoding which permits the separation of up to four callers all on the same frequency.
Yes, I agree this needs to be looked at. I do not like the feature that causes your TX frequency to jump to the caller’s frequency when someone replies “split” to your CQ call. This is particularly hazardous on the 5 MHz band, where the UK frequency allocation is different from that of the rest of Europe. If you are not very careful, someone will respond “out of band” to your CQ call, and you finish up being pulled on to his frequency before you realise it!
I know this feature can be disabled on the screen, but it is rather unreliable and you have to be extremely careful.
5 MHz is a special case, where split frequency operation is sometimes unavoidable due to the varying frequency allocations in different countries.
Hi walt,
I am going by guidance given on some FT-8 forums.
The tick box causing ones frequency to jump around the bandscope on each qso, I think you are saying you agree with but the split frequency not. I was of the same opinion until reading the official notes on the FT8 download page - guidance notes.
In any case my attempts at FT-8 today from a local summit did not get any responses from SOTA chasers although the psk reporter site spotted me from many countries around Europe. I also had problems with the Windows tablet, as regards visibility in the sunshine but more so with finding the mouse, whether I was using an actual mouse or the touchpad on the keyboard (both Bluetooth attached to the tablet). The touch screen is an absolute no, no with my big fingers. So I think I will need to look into this before my next attempt. The software and connections to the FT-817 worked withut problems receiving and decoding FT-8 signals.
The fun was finally stopped when the farmer came and asked me to move as he wanted to mow the field I was in to make hay. He was very nice and offered another field (also still on this flat summit), but I decided that it would be better to pack up and leave.
I got everything set up nicely, sheltering from the rain within my bothy bag (but the condensation dripping on the screen still caused trouble).
I got some decodes at first and nearly completed a QSO. But then, with no decodes for 20 minutes I realized it wasn’t getting any audio through the cable - just through the microphone. I checked this previously on my first Linx 820 tablet (this is my 3rd) and it was working. Something’s up with this one. Sorry folks.
At least I got plenty of S2S switching to traditional modes.
Hi Simon, I had that problem on my ACER Windows tablet and it turned out to be the resistance of the audio feed from the rig. In my case the link was around 50K resistance - which is fine for an Android phone but I had to bring it down to 13K (parallel resistor across the interface output) and now the tablet recognises that it has an external microphone plugged in and mutes the built in microphone.
Yes, I suspect it is that. The value I’m using was fine with my first Linx though. Perhaps actually it was just marginal. I will have to investigate.
I am a poor whistler. So I wonder if any passing walkers were taken aback by the strange person inside the storm shelter blowing raspberries! Mind you, everybody does that to Windows sometimes.
As there is a way of avoiding the problem - untick box, ALT double click - I’d be happier with the features as is. Someone else has also pointed to the problem of people calling on random frequencies all over the band thereby making the band occupancy greater than it need be.
It seemed like a good idea at the time. And it is standard DX procedure - “listening up 2”. With FT8 you are not going to be drowning out the DX station but you may be buried under the pile up in his listening slot so getting a clear frequency is good, but there can be collateral damage.
I’m sot sure how far from the nominal frequency you need to go to get independent decodes, maybe 25 Hz? After a period of chaos some form of operating procedure or multimultipass decoding will evolve. In the meantime we need to be patient.
Remember it is a DX mode so expect some selfish behaviour.
Because it is easy to use in basic form don’t expect the other guy to read the all notes and user guides.
My current gripe is the bloke who has all the knobs wound fully clockwise and is still 250 Hz plus wide with all attenuators switched in in my rx chain. Doesn’t understand that winding the boxes back by only 2 dB will actually increase his signal and leave more usable band for the rest of us.
You will sort out the viewing problem etc after a bit more experimentation.
I have found the following page. It is an “unofficial” users’ guide, but it does include some very good advice and it relates entirely to Ver. …rc2. I don’t agree with everything he recommends, but most of it makes good sense. (I am still not keen on his insistence on using split frequency as the default!)
BTW, there is another disadvantage to replying to CQ calls “off frequency”. If the CQ caller has his “Call 1st” box checked - as the vast majority of people do! - the software will always reply to a caller on the CQ-er’s own frequency as the first choice, and ignore callers who are off frequency. Only if there is nothing intelligible on his own frequency will it reply to an off-frequency caller. Now that there is multi-pass decoding active, there is a much greater chance that the software will be able to pick out a readable signal through the pile-up.
The mode is still classed as experimental and subject to changes. When it is a stable version then a manual can be written. In the meantime “unsanctioned” operators guides will appear.
My preference is to call and work on the CQ frequency and move 50 Hz + (if clear) when calls fail or decoding fails after a couple of attempts if I really am keen to make the QSO.
Some ops or their computers get spooked by variations in procedure. I worked a Chinese station this morning on 18 MHz and then later on 14 MHz and after receiving RRR sent “TX2B VK3AFW 73” whereupon the other station reverted to signal reports.
Hi walt,
That was the site I found a while ago and then couldn’t find again (as we said info spread about) - I’ve now bookmarked it - for other ops, the most useful thing is the small table in the article:
That table appears if you hit F5. F3 gives you keyboard shortcuts.
Later versions of the software (that you have to build yourself) have removed the Tx=Rx option. Instead you can fix your Tx frequency so that double clicking only moves the Rx frequency. The functionality is quite fluid at the moment so it will probably change some more before RC3 appears. But it seems split operation is the intention.
I have been busy with FT8 on HF from home. I almost always answer CQs split as it makes it much easier for the far end to decode multiple calls. It doesn’t necessarily increase the crowding since there are two timeslots and the software is pretty good at decoding overlapping signals. I’m hardly DX but my CQs are often answered by more than one station at a time. If they are on different frequencies I’m much more likely to get a decode. It’s very frustrating when you can see a signal coming in response to your CQ but it doesn’t decode because it’s actually two signals on the same frequency.
Hi,
With the latest revision I have on several occasions decoded two signals on the same frequency answering my CQ. Rather than run the risk of confusing the auto function or the other op I proceed down the list of responses and the call the second station with a report after concluding with the first. One could send two reports with part calls in one transmission but that really upsets the other persons auto sequencer.
If a station is calling CQ without result I’ll call him on his frequency.
If a rare one is calling CQ and getting many takers I’ll call him on another nearby frequency. I could use the linear but I’d have to turn it on.
I’m still making enough clicking errors to warrant sticking with the auto sequence at least to message 5.
In spite of running a massive 75 W these days I still get reports of 20 dB less than what I give out. DX mode yes, QRP mode no.
There seems to be a bug in V…r2 that causes an occasional mad report eg 83 dB. Pretty obvious but still eye catching.
Domestics and weather have prevented me venturing out to a summit again.
For those particularly interested in the WSJT-X GUI behavior, it’s a good idea to subscribe to the wsjt-devel mailing list. Changes are still the works for what will become rc3 or 1.8.0 proper. Joe’s latest commit message (not yet released, but you can pull the code and build it yourself):
Another try at optimizing the GUI for simplex and split behavior. Details below:
Checkbox “Double-click on call sets Tx and Rx freqs” has been removed
from the Settings → General tab.
Checkbox “Lock Tx Freq” on main window is relabled “Hold Tx Freq”.
Behavior now defaults to the “simplex” behavior in use up to code
revision r8123. In particular, double-clicking on decoded mesages
that do not contain your own call moves both Rx and Tx frequencies.
If the first callsign is your own call, only Rx freq moves.
If “Hold Tx Freq” is checked, double-clicking on decoded messages
moves the Rx frequency; Tx frequency is moved only if CTRL was held
down.
Clicking on the waterfall moves Rx and Tx frequencies as before:
Rx only on a simple click, Tx only on SHIFT-click, and both on
CTRL-click. This happens even if “Hold Tx Freq” is checked (which
is why this box is no longer labeled “Lock Tx Freq”).
