Hi David,
I am not sure of the exact FCC regulations. Here I believe sending a
callsign at the start and end of a QSO may be sufficient.
The callsign is effectively spread throughout the message, the nature of
the FEC parity bits is that each contributes to a set of received bits
that *may* be used to extract the message, those received bits may or
may not include the originally source encoded callsign. It is incorrect
to state that the parity bits are a repetition of any part of the
original message, at least not as any form of direct copy. this is the
nature of parity bits when there are more than one of them. As single
parity bit can only be used to detect certain types of errors like
single bit errors, with more than one parity bit greater than single bit
errors can be detected, and missing (erased) bits can be reconstructed.
All the standard messages contain the transmitting station callsign or a
hash code of it that can be mapped back to the callsign if it has been
recently received in full. Think of that like me identifying as WJS for
brevity in an ongoing QSO, a not uncommon practice which may or may not
be construed as proper identification.
For reference the relevant condition of the UK licence is this:
13 Identification
13(1) The Licensee, or, if this Licence is a Full Licence, then any other
authorised person
who uses the Radio Equipment, shall ensure that:
(a) the station is clearly identifiable at all times;
(b) the Callsign is transmitted as frequently as is practicable during
transmissions, unless
the specific requirements of Note (g) to the Notes to Schedule 1 of this
Licence apply;
and
(c) the Callsign is given in voice or other appropriate format consistent
with the mode of
operation.
The reference to Note (g) refers to this text which only applies when
using the 5MHz band:
(vii) Where the Licensee intends to operate within a “net” (a network), the
Licensee shall observe the following requirements in relation to the
transmission of his or her Callsign:
(a) The Licensee shall transmit the station Callsign when he
first joins the net and on leaving it;
(b) subject to sub-clause (c) below, whilst participating in the
net, the Licensee shall not be required to transmit the
station Callsign when making contact with other
participants;
(c) where the Licensee’s transmissions have been other than
in speech mode for at least fifteen minutes, the Licensee
shall transmit his call sign when next he transmits speech.
73
Bill
G4WJS.
On 28/09/2020 14:41, David Tiller wrote:
Thanks, Joe, K1JT, Steve, K9AN, and Bill, G4WJS for all your hard work and
these new modes.
I don't want to be a stick in the mud and I am not trying to stir the pot, but is
there any issue with modes that transmit for >= 10 minutes and the US
requirement to ID at least every 10 minutes?
I don't think part 97.119 addresses IDs that take longer than 10 minutes.
I admit I don't fully understand all of the details of the transmitted data in
FT4/FST4, so if I'm off-base, please forgive me (and kindly correct me!). If
the FEC employed spreads the callsign bits out over the message, then my
analysis is incorrect from the git-go.
For FST4, if the message bits are symbol-encoded and transmitted in the order
as shown in the QEX Article on FT4 [See QEX 2020 Jul/Aug, page 7] and assuming
the sender's callsign is sent as the second c28 call, it looks like in most
cases the sending callsign is within the first 57 bits of the 77 bit raw
message. That means that 57/77 = 74% of the raw message has to be transmitted
before the sender's callsign is transmitted. That means the longest
transmission that gets the sender's call in at/under 10 minutes is about 13.5
minutes or 810 seconds.
If I have the callsigns backwards, then the sender's call is sent first in most
cases. That makes the longest transmission more like 27.5 minutes, but then the
last 17.5 minutes of the transmission are unidentified (barring FEC repetition
of the callsign bits). That means the longest tx in this case would be 20
minutes - The first 10 are identified in the message and the last 10 would be
identified by an explicit ID by the operator.
I know this won't be a popular idea, but adding a low power CW ident at a
standard (low, perhaps sub 100 Hz) frequency in addition to the transmitted
signal every 10 minutes would unquestionably address this. Remember that the
requirement is for each station to ID, not to ensure that the ID doesn't clash
with other ID transmissions. If every FST4 signal over 10 minutes id'ed via CW
on VFO + 50 Hz, say, that would be sufficient to satisfy 97.119.
Ideas/comments?
Again, I'm just asking the question, please don't shoot the messenger.
On Sep 27, 2020, at 4:23 PM, Joe Taylor<j...@princeton.edu> wrote:
The first public candidate release of WSJT-X 2.3.0 is now available for
download and use by beta testers. This release is your first chance to
try two new modes designed especially for use on the LF and MF bands, and to
provide feedback to the WSJT Development Team. The new modes are:
- FST4, for 2-way QSOs. Options for sequence lengths from 15 seconds
to 30 minutes, with threshold sensitivities from -20.7 to -43.2 dB in
a 2500 Hz reference bandwidth.
- FST4W, for WSPR-like transmissions. Sequence lengths from 2 minutes
to 30 minutes, threshold sensitivities from -32.8 to -44.8 dB.
FST4-60 is about 1.7 dB more sensitive than JT9, largely because it uses
multi-symbol block detection where appropriate. With AP decoding in FST4 the
advantage can be as much as 4.7 dB. Additional sensitivity details with respect
to path Doppler spread are illustrated in the following graph comparing JT9 and
FST4-60:
https://physics.princeton.edu/pulsar/k1jt/jt9_vs_fst4.pdf
FST4W-120 is about 1.4 dB more sensitive than WSPR, and FST4W submodes with
longer transmissions have proportionally better sensitivity. Decoding
probabilities are plotted as a function of SNR on the additive white Gaussian
noise (AWGN) channel for WSPR and all FST4W submodes
here:https://physics.princeton.edu/pulsar/k1jt/wspr_vs_fst4w.pdf
Tests over the past several months have shown FST4 and FST4W frequently spanning
intercontinental distances on the 2200 m and 630 m bands. Further details and operating
hints can be found in the "Quick-Start Guide to FST4 and FST4W":
https://physics.princeton.edu/pulsar/k1jt/FST4_Quick_Start.pdf
We strongly recommend that users of JT9 and WSPR on the LF and MF bands should
migrate to the more sensitive modes FST4 and FST4W.
Links to installation packages for Windows, Linux, and Macintosh are available
here:
http://physics.princeton.edu/pulsar/k1jt/wsjtx.html
Scroll down to find "Candidate release: WSJT-X 2.3.0-rc1".
You can also download the packages from our SourceForge site:
https://sourceforge.net/projects/wsjt/files/
It may take a short time for the SourceForge site to be updated.
WSJT-X is licensed under the terms of Version 3 of the GNU General Public
License (GPL). Development of this software is a cooperative project to which
many amateur radio operators have contributed. If you use our code, please
have the courtesy to let us know about it. If you find bugs or make
improvements to the code, please report them to us in a timely fashion.
We hope you will enjoy using this beta release of WSJT-X 2.3.0. Please report
bugs by following instructions found here in the User Guide:
http://www.physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.3.0-rc1.html#_bug_reports
-- 73 from Joe, K1JT, Steve, K9AN, and Bill, G4WJS
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
