Thanks for the insight, Bill. Is there a writeup of the protocol anywhere
for deeper understanding?
One idea I had after playing around with PSK & FSQ these past few days is
to leverage an extra bit to allow for a QSO centered around freeform
messaging on HF. Specifically, one of those bits to be used as a
"continuation bit" to signal (when true) that the message is split between
multiple transmission blocks. An example:
CQ KN4CRD EM73 (continuation)
WAS CT DE PA (continuation)
WAS NY RI MA (continuation)
CQ KN4CRD EM73 (stop)
or
G4WJS KN4CRD -10 (continuation)
DT -0.5 QSB (continuation)
NAME JORDAN (continuation)
5W INDR MLOOP (continuation)
G4WJS KN4CRD K (stop)
The nice thing is that with the FT8 transmissions, you'd see those
incremental messages come in every 15 seconds. So, it would be a middle
ground between real-time PSK decoding and the one minute delay of JT65.
Transmissions would still be synchronized to the time interval, so there
shouldn't be too much dead air between responses (15 seconds of dead air is
way easier to stomach than 60+).
The other thing that I've been noticing is that with the pace of the FT8
transmissions, repeat messages are coming in frequently because there is a
miss to engage the calling CQ station, or perhaps autoseq was disabled, or
there was some band fading that caused the decoder to missfire. The
continuation bit could be used to synchronize on a 30 second interval with
doubling of every message to ensure delivery:
CQ KN4CRD EM73 (continuation)
CQ KN4CRD EM73 (stop)
or
KN4CRD G4WJS -18 (continuation)
KN4CRD G4WJS -18 (stop)
As above, if you had a reliable signal you would see the first interval
come in (with a continuation indicator, maybe an ellipsis ... in the ui or
something next to the message). That would give the responding station 15
more seconds to write their reply while the second (duplicated)
transmission came in (which would be really useful in freeform text).
I have some other ideas regarding the other bits, but I'd like to dig into
the protocol as it is today before suggesting anything else.
Curious on what y'all think about something like this?
Best,
Jordan
KN4CRD
On Thu, Jul 6, 2017 at 9:47 AM, Bill Somerville <g4...@classdesign.com>
wrote:
> On 06/07/2017 14:26, James Lemley wrote:
>
>> After discarding the idea of encoding eight humorous messages, and
>> without studying the rest of the protocol to see if these are already
>> implemented, here are my suggestions for the three extra bits with a
>> transmit frame:
>>
>
> HI James,
>
> adding extra ad hoc messages can be easily done by using some of the
> unused existing message space. For example the directional CQ messages were
> inserted by using the unused callsign series E9xx. These sort of things
> require no extra bits, just global agreement.
>
> With respect to your other suggestions, in the protocols as they stand
> every standard message except the 73 one expects acknowledgement. The 73
> and free text messages do not expect acknowledgement although some free
> text messages can be constructed to imply acknowledgement is expected,
> "REPORT PSE?" for example. When acknowledgement is not received then simply
> repeating the last message until acknowledgement is received is all that is
> needed. It is unfortunate that many users wish to shorten the QSO sequences
> without regard for the above. There are some cases for dropping messages
> like the initial grid reply to a CQ when propagation is unstable.
>
> I believe you are not thinking far enough outside the box with how an
> extra bit may be used. For example the current protocol is partitioned into
> two by a single bit. One half encompasses every standard message and the
> other half encompasses all the free text messages. A single extra bit opens
> up the possibility of a whole new protocol with a message space as large as
> the existing protocol. Using one or more extra bits to add value to the
> existing protcol would be missing a huge opportunity.
>
> 73
> Bill
> G4WJS.
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
