Have questions about FT8Call? These are questions I have found on other sites about FT8Call and answered by KN4CRD himself. They’re provided here with a link to the source of the question and link to the source of the answer.
Q: How does this differ from FT8? Are you using more bandwidth? Are you time concatenating? What is the tradeoff? (src)
A: FT8Call is a derivative of the WSJT-X application, restructured and redesigned for keyboard-to-keyboard message passing, similar to PSK/FSQ/Olivia/etc. It uses FT8 modulation as the transport. But, it does not use FT8 encoding for the delivery of the text. That part is original. It is a variable encoding and packing scheme to allow greater than 13 characters per transmission cycle (up to 23 actually). It touts the same benefits of FT8, but with greater flexibility for long-form message passing. (src)
Q: What’s the sell for this over, say, FSQ? (src)
A: It’s heavily inspired by FSQ. But, It’s built on FT8 modulation and carries the same benefits, decoding signals down to -24dB below the noise. It does this while allowing a 10-15WPM keyboard-to-keyboard transmission.
Many ops are saying this works when other modes won’t, including FSQ, because it’s said sensitivity. (src)
A: Everybody has a VFO. You can place your signal anywhere you’d like, simliar to if you were operating PSK w/ Fldigi. The app does have default starter frequencies above or below the FT8 sub-band. (src)
A: Suggested frequencies are 4-6kHz away from FT8 within the digital sub-band allocations. (src)
Q: What is the general Words Per Minute capability of FT8Call?
A: The variable character encoding brings it somewhere between 10 & 15 WPM depending on the composition of the sentence (each character takes a different amount of “time” to send). 12WPM is about average. What you get for that speed is theoretical sensitivity down to 24dB below the noise floor in only 50Hz bandwidth. It may “work” when other modes won’t.
But, if you have a good, noise “free” propagation path, you should likely be using a mode with a higher throughput (FSQ 3 is about 30WPM at -16dB, Olivia 4/500 is about 40WPM at -10dB). (src)
Q: It appears that FT8Call uses certain symbols to transmit commonly used sentences (signal report, hello phrases, etc). I am wondering if you took that in account to reach the 12wpm average, or if you were basing the 12wpm speed on just the paragraph-long test phrase you used?
If you didn’t take the macros-type phrases into account, then we’re really looking at a speed faster than 12wpm, for typical comms, aren’t we? (src)
A: There are examples in the documentation. It depends on the type of transmission. Most directed commands can be sent in one tx cycle (frame).
Once you send a free text message, it depends on the sentence structure. Here’s an example:
“WE HOLD THESE TRUTHS TO BE SELF-EVIDENT THAT ALL MEN ARE CREATED EQUAL THAT THEY ARE ENDOWED BY THEIR CREATOR WITH CERTAIN UNALIENABLE RIGHTS THAT AMONG THESE ARE LIFE LIBERTY AND THE PURSUIT OF HAPPINESS.”
Would transmit in 13-frames, for ~11WPM.
“A SUCCESSFUL MAN IS ONE WHO CAN LAY A FIRM FOUNDATION WITH THE BRICKS OTHERS HAVE THROWN AT HIM”
Would transmit in 6-frames, for ~12.66WPM
CW has a neat way of calculating WPM, timing how long it takes to transmit the word PARIS. In FT8Call, PARIS is encoded into 24 bits (4.8 bits/character). Each transmission cycle can pack up to 69 character bits. That equates to about 11.5 WPM. (69/24=2.875 words / 15 seconds * 4) (src)
Q: I wonder how long it will be until the various logging organizations (QRZ, LoTW, eQSL, ClubLog, etc.) adopt this as an official mode? How long does that typically take I wonder? (src)
A: A bit of time, but not an eternity. We have to petition ADIF.org to have it included in the ADIF Tables. Most of those logging orgs use those tables as the source of truth for their logs.
In the meantime, logging as FT8 w/ FT8CALL as a sub-mode, or as DATA should work fine. (src)
Q: Anyone guide me as to why my station sends 2 frames on Beacon instead of one? (src)
A: This is intentional. Beacons are randomly offset by +/- 15 seconds from the scheduled duration and are 30 seconds long so there’s more of a chance for two stations to hear each other when they start beaconing at the same time. (src)
Q: Does FT8Call rely on a properly-timed internet clock? Is FT8Call different in that I could be in a shack “off the grid” with no internet, and pick it up after several days of non-use, and it would just work? Or does it rely on outside internet information (such as timing, etc) to work properly? (src)
A: I’m working on a signal detector for timing recovery without the need for an accurate timing reference. However, currently you need an accurate clock. But, that accurate clock doesn’t need to be internet connected. A GPS dongle would work well (a number of portable ops are using this today). A manual sync like this http://vtenn.com/Blog/?p=1319 would also work. (src)