A NEW FT8 with QSO and Rag Chew capabilities called FT8CALL

I saw that. I mean.the frequencies and geographic region... since it seems to be as popular as PSK31 but I've never seen it. Google seems to indicate I should look right above psk31 for it. I'll do that and see

 

I used PSK reporter as only a relative measurement. I am sure there more analysis we can do. But for sure FT8CALL is getting popular.

 

Excited to see adoption of the idea of time snyc to the leading edge of the transmission cycle. It might be a big improvement over manual setting the PC clock to any standard.

Because, correct me if wrong, what is really important is not sync to any particular universal clock reference, like WWV or a GPS, but sync between the PC clocks of the two stations involved in any QSO.

Without having an auto leading edge sync, to that end it might be helpful for FT8CALL to display the DT as does WSJT-X, so that adjustments of clock needed for any particular received signal can be determined. Which could then be accomplished with something like the small utility created W9MDB called "Time Fudge", if perhaps also built into FT8CALL .

 

It would be nice if FT8Call did not need to be tied to the clock requirement. Being a more free text mode, there's really no need to be tied to a clock. I'm still OK with the 15 second intervals for transmissions (stacked back to back, as needed, depending on message length).

 

Was thinking about camping (portable) operation when there is no internet no cell phone service etc have had good success with the "hockey puck" small GPS usb receivers but would be nice to be free of any time dependency .

 

The main reason most FT8 / FT8CALL operations are limited now to a just one wide SSB sized channel is because of the prevalence of such rigs today.

I would bet the creators of SDR software / skimmers, like Flex Radio, Apache Labs, all the open-sources, are already working on incorporating FT8 / FT8CALL schemes as an alternate mode that would allow detection of an FT8/ FT8CALL signal ANYWHERE across a monitored SDR spectrum slice, potentially across an entire amateur band.

That would free everyone with an SDR, including those integrated with a legacy non-SDR rig, from having to just sit at the controversial "watering-hole" SSB channels or worry too much about where they are placed. They could become more like "calling" only frequencies, and the polite operating protocol would be to reply and then QSY outside of them. Or just call CQ anywhere within the legal digi allocation knowing those with such skimmimg SDR's may find your signal and respond simplex.

Of course that flexibility may scare some about intruding on existing "band plans" for other modes, but IMO it makes sense to make those "dynamic", variable in size, or shareable (as now done in contests ) as actual demand dictates.

Amateur band allocation - use it or lose it ...

 

Folks, if you see a CQ, that's somebody looking to chat There are no automated CQs.

 

How are you going to power the "Cray" (or Intel i7 multicore computer) necessary to go through all permutations in the sound sample while at a campground? I mean, significant computing horsepower is going to be needed to look for a *possible* 80 Hz wide signal 24 dB down across a 2400 Hz BW and then begin to take that 'data' in for a 15 second frame ...

It isn't like there is going to be an obvious 'mark' then 'space' on a serial transmission to denote an incoming signal when the sigs are literally buried 24 dB below the noise ...

 

Most campsites I use have AC power many have no internet or cell phone service hope that answers your question.

 

Have you ever heard the famous movie line "I think you're going to need a bigger boat"? The point is, and I think it was missed, a dual core ARM architecture based Android prolly won't work in the mode (untimed/unsynchronized) that you desire in FT8Call ...

 

Sorry guess I am missing your point when I camp use on old ASUS 7 inch computer for FT-8 and as indicated the time accuracy is determined by a usb GPS receiver. I own nothing that is based on android. At the moment here in the shack using an older Dell laptop for FT-8CALL with Windows 7 Pro and a GPS receiver for time sync and all is working just fine. Thanks for your concern .

 

Efficiency
I believe the efficiency is much better than 56 slots per 2,700 Hz. FT8CALL, FT8, JT65 and the other WSJT-X modes decode and work very well even if many signals share parts of the same slot, to the extent that I have seen decodes of 4-5 callers responding to my CQ within a couple of Hz, i.e. a massive overlap of signals. AK9S' calculation assumes no overlap, i.e. that everyone has his/her slot just to him/herself, and that seems too conservative. I wouldn't be hard pressed to believe that every 48-50 Hz slot could accomodate decodable signals from 4-5 stations, at least if none use excessive power, drowning their band neighbours. Even in practical circumstances, where some will be tempted to unnecessary QRO, I guess hundreds of signals can fit within 2700 Hz, if needed. So, it is not like the weak signal modes steal a lot of bandwith form other digital modes.

No reason to trespass
We all know that bandplans are recommendations only, and that no ham has ownership to any frequency. However, I believe in orderly ways to share common resources, and I very much agree with Mike NO2Y, that there is no reason for a new mode to actively "trespass" into well established frequencies for other digital modes, even if they may have passed their heyday or are currently being overshadowed by FT8. FT8 was a further development based on JT65/JT9, successfully sacrificing decoding SNR for time. FT8 moved its activity down typically to ##,074 kHz (#,#73 kHz in 80 m, due to limitations on 3,574 kHz in Japan), below the established JT65 frequencies at ##,076 kHz, while JT9 was located 2,000 Hz above JT65 at ##,078 kHz. Since long, PSK has typically been at ##,070 and RTTY at ##,080. Including the audio frequencies the activity typically spread 2-2,5 kHz above the referred frequencies, depending on activity (contests not included). This means that in several bands, 070 - 082 is in use, so we should probably look below PSK and above RTTY. And before anybody bother to comment on the specific frequencies mentioned here, I am perfectly aware that the frequencies in several bands are not 070, 074, 076, 078, 080, but I trust that you understand my line of thinking that we need to look at the referred dial frequencies and then pay attention to the fact that there are audio signals on thop of that filling the gaps.

In most HF bands the bandplans allocate 10 - 30 (even 50) kHz to digital modes, so there is no need to fight over specific frequencies. And for that matter, most HF bandplans have ample allocations for "all modes", so we may also look at what is generally seen as the "phone band", although in some countries this may exclude some license classes that often have access to the typical digimode frequencies.

Proposal for FT8CALL frequencies
I believe FT8CALL will become a success in use and replace a good part of the current FT8 traffic. Frequencies will be needed, and I think it will be smart to make some decisions sooner rather than later in order to have some sort of control over the expected growth in FT8CALL activity. Jordan KN4CRD, who has made a great job in development, is soliciting suggestions, so here goes:

I am no band plan expert, but I made a quick check through the band plans for IARU Regions 1, 2 & 3 to see what was available for narrowband digimodes. The bandplans for Region 1 & 2 are fairly specific, while the Region 3 bandplan is a little less detailed. I have certainly not digged into all details of which frequencies are in use for which modes, so ther may certainluy be some collisions, but at least we have somewhere to start from. My line is to located FT8CALL generally 10 kHz above FT8, with adjustments (marked in italics) where "+10 kHz" wouldn't fit. It is not complete, but it goes like this:

1,8## suggestions welcome, there is hardly any space in the digimodes bandplan
3,558 in CW portion of bandplan, below bandplan for digimodes, but gives room for Japan in 80 m
5,3## (60m needs special attention, as the frequency availability is still very different between countries)
7,044 in bandplan for digimodes (Reg 1 & 3: narrow band); 7,084 kHz is outside the digimodes bandplan, but so are the PSK, FT8, JT65, JT9 and RTTY frequencies
10,146 in bandplan for digimodes (Reg 1 & 3: narrow band)
14,084 in bandplan for digimodes (Reg 1 & 3: narrow band)
18,106 in bandplan for digimodes (Reg 1, 2 & 3: narrow band; Reg 1 & 2: unattended); 18,110 kHz is allocated to beacons
21,084 in bandplan for digimodes (Reg 1 & 3: narrow band)
24,922 in bandplan for digimodes (Reg 1, 2 & 3: narrow band); RTTY is on 24,925 kHz, PSK is on 24,920 kHz)
28,084 in bandplan for digimodes (Reg 1 & 3: narrow band)
50,318 in Europe (part of Region 1) 50,323 kHz has this year developed into an alternative DX frequency for FT8, particularly for working Region 2)

Please, consider it. Indifference and inertia move us nowhere, so fire the guns to shoot it down, the fireworks to support, or make other suggestions.

73 Frode LA6VQ

 

All good points. Gave me an idea (that may turn out to be nonsense, but here goes

I don't have a solution, just a discourse:

I think there's an underlying problem with the way we "band plan". If you look at a typical PSK Reporter output there's about 20 different Digital modes listed along with CW. These are all sharing the same band space. Some are related to each other so are not really incompatible (e.g. PSK31 & PSK63, etc) so could share space reasonably well. So let's for the sake of argument say there are 12 digital modes (or groups of compatible digital modes) that each "need" their own "window".

If we go about bandplanning in the customary way; i.e. identify a fixed 3 kHz window for each digital mode. We'd need 36 kHz to give each mode it's own window. That's quite a lot of turf and does not account for some modes being very popular, to the point of stuffing their windows; and others modes appearing only rarely so it's essentially vacant space almost all the time. And then along comes a contest and it all goes out the window. And on top of that, along comes a new mode periodically that upsets the whole system.

So this static band-planning model does not seem like a very efficient way to use the spectrum. But this is the way it's always been done, and is the basis for the ARRL's "Considerate Operators Frequency Guide".

What's needed is some sort of dynamic band-planning. Some algorithm in the software that tells you what your VFO frequency should be, in real-time.

So for example, the home window for your favorite mode fills up, the software (somehow - not clear to me how) in real-time searches for unused 3 kHz blocks in the band and tells you what your VFO frequency should be. It may not always be the same frequency, but listening to the bands there's almost always a 3 kHz block that is empty, somewhere, that you could use without peeving anyone off. .

Or, suppose you are a user of one of the less popular modes, and you fire up the rig and discover that your home window has been taken over by another mode. So you click the "Find New Mode Window" button, the software connects to PSKReporter to find the present Mode-QSO density in the band and identify a 3 kHz empty space, or finds a window where other people using your mode are, and tells you that you can use that the (temporary) window for your mode is at xxx.xxx frequency.

There would have to be an internet site that collects world-wide mode-frequency density information, so that anyone else who wants to work your mode, also knows where to go to find you. Again, not knowing if it's feasible, just a wild idea, but what I am envisioning is something like PSKReporter that also outputs a plot of "QSO Density" versus frequency across a whole band, so that everyone can see where there's little or no activity.

The upside is that there would be some common, systematic way to spread out when needed, minimizing the damage done to other mode's home windows, and providing an easy alternative way to find modes.

The downsides are that people might have to actually think about where they transmit instead of just selecting from a drop-down menu. (Unless this algorithm could be implemented in software - I don't know enough about that to know if it's possible). People might actually have to turn the big knob once in awhile.

Or not .... Just a harebrained thought.

And you can choose to turn this feature off if you prefer to stay with the customary static bandplan method, with all of its faults.

 

I went through this thread and compiled a list of questions/answers that have been asked and posted them here: http://ft8call.com/questions-answers/

Source to the questions/answers linked back to the post(s) in this thread. I've talked to KN4CRD and he's okay with me running the site as long as I make it clear I'm not associated with the project, which I'm not. It's simply just a fan page, more or less, and collection of information/resources that is easier to locate.

 

Excellent!