Bill, Thanks for the thoughtful and informative reply.
In the US, the regs https://www.law.cornell.edu/cfr/text/47/97.119 <https://www.law.cornell.edu/cfr/text/47/97.119> state (** emphasis added **): § 97.119 Station identification. (a) Each amateur station, except a space station or telecommand station, must transmit its assigned call sign on its transmitting channel at the end of each communication, ** and at least every 10 minutes during a communication**, for the purpose of clearly making the source of the transmissions from the station known to those receiving the transmissions. No station may transmit unidentified communications or signals, or transmit as the station call sign, any call sign not authorized to the station. (b) The call sign must be transmitted with an emission authorized for the transmitting channel in one of the following ways: (1) By a CW emission. When keyed by an automatic device used only for identification, the speed must not exceed 20 words per minute; (2) By a phone emission in the English language. Use of a phonetic alphabet as an aid for correct station identification is encouraged; (3) By a RTTY emission using a specified digital code when all or part of the communications are transmitted by a RTTY or data emission; (4) By an image emission conforming to the applicable transmission standards, either color or monochrome, of § 73.682(a) of the FCC Rules when all or part of the communications are transmitted in the same image emission b(1) is what I suggested. b(3) is applicable, but naturally you'd have to use some 'specified digital code' in addition to the signal you're trying to ID. RTTY would be way too wide - maybe a faster narrowband mode? It would be funny to ID a slow FST4 transmission with a simultaneous fast FST4 transmission down-band. b(2) and b(4) are not applicable unless you want an unholy mess. > On Sep 28, 2020, at 10:24 AM, Bill Somerville <g4...@classdesign.com> wrote: > > 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> >>> <mailto: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 >>> <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 >>> <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 >>> <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 >>> <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/ >>> <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 >>> >>> <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
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
