Re: [wsjt-devel] FT4 gain adjustment
Jim, exactly! -Original Message- From: Jim Brown [mailto:k...@audiosystemsgroup.com] Sent: Friday, April 26, 2019 2:29 PM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] FT4 gain adjustment On 4/26/2019 1:30 PM, Deisher, Michael wrote: > BTW, in my experience wsjtx does not work half-bad with acoustic > coupling. YES! By that I mean, and I think you mean, the computer mic picking up the sound from the speaker in the radio and, by Windoze accident, feeding that to WSJT-X. So I hope folks will forgive my interchanging of the words > “acoustic” and “audio”. No forgiveness needed -- just trying to keep words straight. It's the retired teacher in me. :) 73, Jim K9YC ___ 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
Re: [wsjt-devel] The FT4 Protocol for Digital Contesting
Ria and Brian, Good points and I was unaware of the SOTA QRP activity. The clash then is how to fit it in. My expectation is that it will need a channel bandwidth of at least 4kHz - and in a fully fledged contest I would expect it to spill wider than that at least on the primary bands of 40 and 20m and maybe 15m. The intent behind suggesting frequencies on say 14.062 was to avoid it creeping into the PSK segments above .070-.074 (the WSJT and PSK communities have already had enough conflict). At the same time there is no value in interfering with the CW community either. Looking more closely I also see that there is a CW QRP centre of activity on 3560kHz so I presume the comments about 20m may at some level even apply to that allocation on 80m? Therefore an alternative frequency set could be: 3.565, 7.065, 14.065, 21.065 and 28.065 - ie 5kHz below the PSK segment. This meets the following criteria: 1. provides some separation between RTTY and FT4 contesters when they are running simultaneously 2. limits impact on known CW centres of activity 3. avoids impact on the PSK community on .070-.074 (and they are still there - I still make intercontinental PSK contacts in that segment especially on 20m to Europe from VK) 4. avoids pushing digital modes far into the voice segment of the bands particularly on 80/40/20m (hence moving lower rather than higher than the digital segments). The problems then are collisions with 80m F/H FT8 mode activity on 3567 - but that isn’t insurmountable (and again all IARU regions need to re-look at the 80m band to further work on common activity harmonisation, particularly given the band limit restrictions present across region 3 with this band). Finally, the comments about FT4 being used outside contests concern me, particularly on the WARC bands. While I accept it will probably happen, encouraging it on 30/17/12m will be very much frowned upon. 30m in particular being only 50kHz wide and a secondary service is not a band that too many more "dedicated" channels can be allocated against and it is often quite busy already with CW in the lower 30kHz and digital in the top 20kHz. There are a small number of countries that do also allow SSB on 30m (VK being one of them) and that puts even more pressure on the use of the band. Associating anything related to contesting on the WRC bands will result in a sharp backlash I am sure. I know as DXpeditioner that we welcome the refuge the WARC bands bring when running an expedition that clashes with a major contest. Further thoughts? Regards, Grant VK5GR -Original Message- From: rjai...@gmail.com [mailto:rjai...@gmail.com] Sent: Saturday, 27 April 2019 8:59 AM To: WSJT software development Subject: Re: [wsjt-devel] The FT4 Protocol for Digital Contesting I'm not sure a WARC ban (not band, but ban) is necessary. This is touted as a contest mode but people will use it for regular DX contacts if it saves them time versus FT8. I can even see some DXpeditions using it to replace or supplement RTTY contacts. Does it have or support Fox and Hound mode? If it does, that reason alone is good to keep it on WARC. Ultimately contest sponsors will give zero points for WARC QSOs anyway so it's essentially a non-issue. 73 Ria, N2RJ On Fri, 26 Apr 2019 at 19:22, Brian Dickman wrote: > > Grant, I'd respectfully discourage any lower than about .065 for 20/15/10m. > .060 is the standard CW QRP activity frequency for each of those bands, and > .061 to .064 are the standard calling frequencies for CW SOTA activations in > most if not all IARU regions. The majority of the activity centers on 062. > Many dedicated chasers monitor 062 throughout the day for mountaintop > portable QRP signals. > > 73, > Brian AF7MD > > On Fri, Apr 26, 2019 at 4:19 AM Grant VK5GR wrote: >> >> Joe et al, >> >> A word if I may about frequency choices. Some of those proposed for FT4 >> probably leave a bit to be desired. Here are some thoughts to consider: >> >> 80m 3.595 - PROPOSE 3562kHz - 3595 is completely out of band for JA >> completely and into the phone part of the band outside of Region 2. My >> suggestion based on occupancy and proximity to existing digital sub-bands is >> something around 3562kHz (at least keeping away from 3560 which is sometimes >> a CW QRP frequency). While the IARU band plans currently have digital as >> 3570-3590kHz a case can be made for expanding that - and given other >> restrictions in some countries on 80m, expanding digital down at least 8kHz >> to 3562kHz makes some sense. A case to be made for the IARU - but you can >> "help" their decision by starting to use it anyway. BTW 3600kHz is the >> centre frequency for IARU R3 80m disaster comms - LSB - so FT4 on 3595 USB >> will badly clash with that - another reason not to use 3595. >> >> 40m 7.090 - PROPOSE 7052kHz (inside the digital sub-band) or 7062kHz (just >> above the digital sub-band noting it is heavily used for SSB at least in >>
Re: [wsjt-devel] The FT4 Protocol for Digital Contesting
I'm not sure a WARC ban (not band, but ban) is necessary. This is touted as a contest mode but people will use it for regular DX contacts if it saves them time versus FT8. I can even see some DXpeditions using it to replace or supplement RTTY contacts. Does it have or support Fox and Hound mode? If it does, that reason alone is good to keep it on WARC. Ultimately contest sponsors will give zero points for WARC QSOs anyway so it's essentially a non-issue. 73 Ria, N2RJ On Fri, 26 Apr 2019 at 19:22, Brian Dickman wrote: > > Grant, I'd respectfully discourage any lower than about .065 for 20/15/10m. > .060 is the standard CW QRP activity frequency for each of those bands, and > .061 to .064 are the standard calling frequencies for CW SOTA activations in > most if not all IARU regions. The majority of the activity centers on 062. > Many dedicated chasers monitor 062 throughout the day for mountaintop > portable QRP signals. > > 73, > Brian AF7MD > > On Fri, Apr 26, 2019 at 4:19 AM Grant VK5GR wrote: >> >> Joe et al, >> >> A word if I may about frequency choices. Some of those proposed for FT4 >> probably leave a bit to be desired. Here are some thoughts to consider: >> >> 80m 3.595 - PROPOSE 3562kHz - 3595 is completely out of band for JA >> completely and into the phone part of the band outside of Region 2. My >> suggestion based on occupancy and proximity to existing digital sub-bands is >> something around 3562kHz (at least keeping away from 3560 which is sometimes >> a CW QRP frequency). While the IARU band plans currently have digital as >> 3570-3590kHz a case can be made for expanding that - and given other >> restrictions in some countries on 80m, expanding digital down at least 8kHz >> to 3562kHz makes some sense. A case to be made for the IARU - but you can >> "help" their decision by starting to use it anyway. BTW 3600kHz is the >> centre frequency for IARU R3 80m disaster comms - LSB - so FT4 on 3595 USB >> will badly clash with that - another reason not to use 3595. >> >> 40m 7.090 - PROPOSE 7052kHz (inside the digital sub-band) or 7062kHz (just >> above the digital sub-band noting it is heavily used for SSB at least in >> region 3) - 7090 only makes sense in the USA! Many other countries have this >> as SSB voice use. The IARU digital segment is (depending on region) >> 7040-7060 or 7040-7060. With 7056 already being used for FT8 F/H mode on a >> fairly regular basis it would make sense to use say 7050 or 7052kHz instead. >> Note that 7090 is the designated SSB QRP frequency. I would promote 7050 for >> FT4. The only reason not to is that the RTTY guys if FT4 and RTTY are in the >> same contest might object - but during the contests the RTTY guys spread out >> and use anything from 7030 to 7120 anyway in complete disregard of the band >> plans. If they are going to be that unruly then putting FT4 down there >> doesn't seem all that bad. >> >> * 30m / 17m / 12m - should NOT have FT4 allocations at all. FT4 is a >> CONTESTING mode and CONTESTING is by global agreement excluded from those >> WRC79 bands!!! * >> >> 20m 14.140 - PROPOSE 14062kHz - the original proposed use of 14140KHz again >> is well outside the digital segments where FT4 belongs. If anything, >> creeping down into 14060-14070 might be considered acceptable despite not >> being in the band plan if the aim was to separate RTTY and FT4 users in the >> same contest. Going high above 14.112 (the acknowledged edge of the global >> 20m digital band plan segment) will be frowned upon. Take a leaf from 80m >> and use 14062kHz - again at least that keeps it away from the CW QRP Centre >> of activity and meets the objective of separating it from RTTY. >> >> 15m 21.140 - PROPOSE 21062kHz - follow 20m and choose 21062kHz - although >> 21140kHz is the first proposed FT4 frequency that fell inside a digital >> subband... >> >> 10m 28.180 - POROPOSE 28062kHz - again follow 20m >> >> 6m 50.318 - PROPOSE somewhere below 50.313 not above. Moving above is just >> moving further into several countries beacon segments. Not likely to get a >> lot of airplay as a international contesting band for FT8 so not as critical >> - but my suggestion would be look below 50.313 not above. >> >> For discussion folks. >> >> Regards, >> Grant VK5GR >> WIA Appointee to the IARU Region 3 Band Plan committee >> >> >> >> >> -Original Message- >> From: Joe Taylor [mailto:j...@princeton.edu] >> Sent: Tuesday, 23 April 2019 1:04 AM >> To: WSJT software development >> Subject: [wsjt-devel] The FT4 Protocol for Digital Contesting >> >> To: WSJT-X users interested in testing FT4 >> From: K1JT, K9AN, and G4WJS >> >> Soon after the "FT8 Roundup" held on December 1-2, 2018, we started >> serious work on a faster, more contest-friendly digital mode that can >> compete with RTTY-contesting QSO rates while preserving many of the >> benefits of FT8. The result is FT4 -- a new digital mode specifically >> designed for radio contesting. >> >> Over
Re: [wsjt-devel] The FT4 Protocol for Digital Contesting
Grant, I'd respectfully discourage any lower than about .065 for 20/15/10m. .060 is the standard CW QRP activity frequency for each of those bands, and .061 to .064 are the standard calling frequencies for CW SOTA activations in most if not all IARU regions. The majority of the activity centers on 062. Many dedicated chasers monitor 062 throughout the day for mountaintop portable QRP signals. 73, Brian AF7MD On Fri, Apr 26, 2019 at 4:19 AM Grant VK5GR wrote: > Joe et al, > > A word if I may about frequency choices. Some of those proposed for FT4 > probably leave a bit to be desired. Here are some thoughts to consider: > > 80m 3.595 - PROPOSE 3562kHz - 3595 is completely out of band for JA > completely and into the phone part of the band outside of Region 2. My > suggestion based on occupancy and proximity to existing digital sub-bands > is > something around 3562kHz (at least keeping away from 3560 which is > sometimes > a CW QRP frequency). While the IARU band plans currently have digital as > 3570-3590kHz a case can be made for expanding that - and given other > restrictions in some countries on 80m, expanding digital down at least 8kHz > to 3562kHz makes some sense. A case to be made for the IARU - but you can > "help" their decision by starting to use it anyway. BTW 3600kHz is the > centre frequency for IARU R3 80m disaster comms - LSB - so FT4 on 3595 USB > will badly clash with that - another reason not to use 3595. > > 40m 7.090 - PROPOSE 7052kHz (inside the digital sub-band) or 7062kHz (just > above the digital sub-band noting it is heavily used for SSB at least in > region 3) - 7090 only makes sense in the USA! Many other countries have > this > as SSB voice use. The IARU digital segment is (depending on region) > 7040-7060 or 7040-7060. With 7056 already being used for FT8 F/H mode on a > fairly regular basis it would make sense to use say 7050 or 7052kHz > instead. > Note that 7090 is the designated SSB QRP frequency. I would promote 7050 > for > FT4. The only reason not to is that the RTTY guys if FT4 and RTTY are in > the > same contest might object - but during the contests the RTTY guys spread > out > and use anything from 7030 to 7120 anyway in complete disregard of the band > plans. If they are going to be that unruly then putting FT4 down there > doesn't seem all that bad. > > * 30m / 17m / 12m - should NOT have FT4 allocations at all. FT4 is > a > CONTESTING mode and CONTESTING is by global agreement excluded from those > WRC79 bands!!! * > > 20m 14.140 - PROPOSE 14062kHz - the original proposed use of 14140KHz again > is well outside the digital segments where FT4 belongs. If anything, > creeping down into 14060-14070 might be considered acceptable despite not > being in the band plan if the aim was to separate RTTY and FT4 users in the > same contest. Going high above 14.112 (the acknowledged edge of the global > 20m digital band plan segment) will be frowned upon. Take a leaf from 80m > and use 14062kHz - again at least that keeps it away from the CW QRP Centre > of activity and meets the objective of separating it from RTTY. > > 15m 21.140 - PROPOSE 21062kHz - follow 20m and choose 21062kHz - although > 21140kHz is the first proposed FT4 frequency that fell inside a digital > subband... > > 10m 28.180 - POROPOSE 28062kHz - again follow 20m > > 6m 50.318 - PROPOSE somewhere below 50.313 not above. Moving above is just > moving further into several countries beacon segments. Not likely to get a > lot of airplay as a international contesting band for FT8 so not as > critical > - but my suggestion would be look below 50.313 not above. > > For discussion folks. > > Regards, > Grant VK5GR > WIA Appointee to the IARU Region 3 Band Plan committee > > > > > -Original Message- > From: Joe Taylor [mailto:j...@princeton.edu] > Sent: Tuesday, 23 April 2019 1:04 AM > To: WSJT software development > Subject: [wsjt-devel] The FT4 Protocol for Digital Contesting > > To: WSJT-X users interested in testing FT4 > From: K1JT, K9AN, and G4WJS > > Soon after the "FT8 Roundup" held on December 1-2, 2018, we started > serious work on a faster, more contest-friendly digital mode that can > compete with RTTY-contesting QSO rates while preserving many of the > benefits of FT8. The result is FT4 -- a new digital mode specifically > designed for radio contesting. > > Over the past month a small group of volunteers have been conducting > on-the-air tests of FT4. The early tests were very successful and > helped us to make a number of important design decisions. We believe > FT4 has considerable promise for its intended purpose. > > We'll soon be ready for testing by a larger group. If you might be > interested in participating and offering your considered feedback, > please read the descriptive document "The FT4 Protocol for Digital > Contesting", posted here: > http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf > > We plan to post downloadable installation packages
Re: [wsjt-devel] FT4 gain adjustment
On 4/26/2019 1:30 PM, Deisher, Michael wrote: BTW, in my experience wsjtx does not work half-bad with acoustic coupling. YES! By that I mean, and I think you mean, the computer mic picking up the sound from the speaker in the radio and, by Windoze accident, feeding that to WSJT-X. So I hope folks will forgive my interchanging of the words “acoustic” and “audio”. No forgiveness needed -- just trying to keep words straight. It's the retired teacher in me. :) 73, Jim K9YC ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FT4 gain adjustment
Thanks, Bill. My intuition came from thinking of power as the integral of the magnitude squared of the signal over the time-frequency extent. I reasoned that doubling the bandwidth should double the power, all else being the same. But all else is not the same as you pointed out. BTW, in my experience wsjtx does not work half-bad with acoustic coupling. So I hope folks will forgive my interchanging of the words “acoustic” and “audio”. ☺ --Mike ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FT4 gain adjustment
Hi Mike, you are mixing concepts that should not be mixed there. The ~90 Hz bandwidth figure is real, it results from the tone spacing and the symbol rate. Your should really try and think of it as a continuum rather than individual tones when talking about bandwidth. The decoder extracts signal energy from every part of the 90 Hz bandwidth. The candidate received signal is sliced into bins each of width equal to the tone spacing. PCM is a digital concept, it is a series of equally time-spaced instantaneous voltage measurements (discrete-time signal) representation of a continuous-time signal, usually sampled across a capacitor that has been charged by the audio source signal for a short period of time. PCM streams are just a series of numbers that when converted to voltages at the inherent sample rate, and filtered with a suitable low-pass filter, will recreate faithfully the originally sampled audio signal. The only constraint is that the maximum bandwidth that can be represented is half the sample rate (see the Nyquist-Shannon Sampling Theorem for details). PCM is just a convenient model for analysing or transforming signals in the digital domain, i.e. Digital Signal Processing. Whatever way you look at it the maximum audio amplitude, which is essentially constant and the same for all WSJT-X modes (1), should not exceed the saturation point of the rig's SSB modulator. Other than that levels are pretty much irrelevant other than their effect on the output power of the transmitter. Note this is not the case for modulations methods like voice SSB or PSK31 where audio levels can be below the saturation level of a rig's SSB modulator but still cause signal distorting IMD products along with the intended RF output that increase the transmitted bandwidth beyond the optimal minimum, colloquially referred to as splatter. These are due to non-linearities in the transmitter such as PA saturation and ALC action. Note these effects do not apply to signals like FT8 or FT4 where linear amplification is not a requirement(1). (1) Except for DXpedition Fox mode when using multiple concurrent signal slots. MSK144 is not constant amplitude either but only because it is filtered by the rig's SSB transmit filter. 73 Bill G4WJS. On 26/04/2019 19:14, Deisher, Michael wrote: Hi Bill, I realized that just after pressing send. The 90Hz bandwidth (I call it acoustic bandwidth since it is encoded as a PCM audio signal) is occupied by a spectrally narrow tone at any given point in time so my concern is not valid. The concern would be valid for other modulation techniques that fully utilize the 90Hz at all times during transmission. Never mind... Thanks and 73, Mike KK7ER -Original Message- From: Bill Somerville [mailto:g4...@classdesign.com] Sent: Friday, April 26, 2019 11:06 AM To:wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] FT4 gain adjustment On 26/04/2019 18:51, Deisher, Michael wrote: FT4 acoustic bandwidth is nearly twice that of FT8. Hi Mike, that is not correct. The FT4 signal is one-tone GFSK. At any point in time there is only one tone with constant amplitude. In this respect the difference between FT8 and FT4 is that FT8 uses 8 different frequencies to encode symbols and FT4 uses just 4 different frequencies to encode symbols. I am not sure how "acoustic bandwidth" is relevant, whatever that is. The baseband signal is used to modulate an RF carrier so the resulting signal is not acoustic. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Acoustic vs. Audio Frequency
OK. I used the word incorrectly. Thanks for pointing that out. 73, Mike KK7ER -Original Message- From: Jim Brown [mailto:k...@audiosystemsgroup.com] Sent: Friday, April 26, 2019 11:33 AM To: wsjt-devel@lists.sourceforge.net Subject: [wsjt-devel] Acoustic vs. Audio Frequency On 4/26/2019 11:14 AM, Deisher, Michael wrote: > I realized that just after pressing send. The 90Hz bandwidth (I call > it acoustic bandwidth since it is encoded as a PCM audio signal) You're confusing the vibration of air with an electrical signal at audio frequencies. The word "acoustic" and the science of acoustics apply to the pressure waves in air or some other medium (like water), NOT in an electrical circuit. The signal generated and decoded by WSJT-X, and other software, is an audio frequency signal. It takes a loudspeaker or earphones to convert that electrical signal to pressure waves that we can hear. Humans can hear these pressure waves vibrating at frequencies between about 20 Hz and 20 kHz. 73, Jim K9YC ___ 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
[wsjt-devel] Acoustic vs. Audio Frequency
On 4/26/2019 11:14 AM, Deisher, Michael wrote: I realized that just after pressing send. The 90Hz bandwidth (I call it acoustic bandwidth since it is encoded as a PCM audio signal) You're confusing the vibration of air with an electrical signal at audio frequencies. The word "acoustic" and the science of acoustics apply to the pressure waves in air or some other medium (like water), NOT in an electrical circuit. The signal generated and decoded by WSJT-X, and other software, is an audio frequency signal. It takes a loudspeaker or earphones to convert that electrical signal to pressure waves that we can hear. Humans can hear these pressure waves vibrating at frequencies between about 20 Hz and 20 kHz. 73, Jim K9YC ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FT4 gain adjustment
Hi Bill, I realized that just after pressing send. The 90Hz bandwidth (I call it acoustic bandwidth since it is encoded as a PCM audio signal) is occupied by a spectrally narrow tone at any given point in time so my concern is not valid. The concern would be valid for other modulation techniques that fully utilize the 90Hz at all times during transmission. Never mind... Thanks and 73, Mike KK7ER -Original Message- From: Bill Somerville [mailto:g4...@classdesign.com] Sent: Friday, April 26, 2019 11:06 AM To: wsjt-devel@lists.sourceforge.net Subject: Re: [wsjt-devel] FT4 gain adjustment On 26/04/2019 18:51, Deisher, Michael wrote: > FT4 acoustic bandwidth is nearly twice that of FT8. Hi Mike, that is not correct. The FT4 signal is one-tone GFSK. At any point in time there is only one tone with constant amplitude. In this respect the difference between FT8 and FT4 is that FT8 uses 8 different frequencies to encode symbols and FT4 uses just 4 different frequencies to encode symbols. I am not sure how "acoustic bandwidth" is relevant, whatever that is. The baseband signal is used to modulate an RF carrier so the resulting signal is not acoustic. 73 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
Re: [wsjt-devel] FT4 gain adjustment
On 26/04/2019 18:51, Deisher, Michael wrote: FT4 acoustic bandwidth is nearly twice that of FT8. Hi Mike, that is not correct. The FT4 signal is one-tone GFSK. At any point in time there is only one tone with constant amplitude. In this respect the difference between FT8 and FT4 is that FT8 uses 8 different frequencies to encode symbols and FT4 uses just 4 different frequencies to encode symbols. I am not sure how "acoustic bandwidth" is relevant, whatever that is. The baseband signal is used to modulate an RF carrier so the resulting signal is not acoustic. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] FT4 gain adjustment
I asked this question in response to the message on the Facebook group but perhaps that is the wrong venue. FT4 acoustic bandwidth is nearly twice that of FT8. With audio gain unchanged when switching from FT8 to FT4, I would expect power out to almost double (or to saturate, etc.). This seems like a potential for operator error. How will it work? Will wsjtx normalize audio output power for the two modes (so that operators can leave sound card gain unchanged when switching back and forth)? Will wsjtx remember its own gain settings per mode? Thanks! 73, Mike KK7ER ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] False Decodes
I have all of that checked as in clearing the cq field after each call already. The only issue I see is when I just cut the software on and/or change bands sometimes that's when a lot of these false codes come up even before I transmit anything. Sometimes the software is just sitting there and these codes just appear. Again I just wanted to make sure I didn't have something set incorrectly or maybe my software was corrupted somehow. You say these are rare but I see these almost daily and some days multiple false decodes in one day. Again that's why I am asking this question. Thanks for the input and replies. Mike KE4BKL On Fri, Apr 26, 2019, 12:02 PM Bill Somerville wrote: > Hi Mike, > > as others have suggested, AP decoding will raise the probability of false > decodes a little. One thing you can do to reduce the false decode > probability is to ensure the DX Call filed is cleared when you are not > working or attempting to work another station. You can check the option in > "Settings->Reporting" to clear it automatically after logging a QSO, for > abandoned QSOs you can use the F4 or ESC shortcut keys to clear the DX > Call, DX Grid and generated messages. The reason that clearing the DX Call > filed helps is that AP decoding is context sensitive and with a DX Call > field populated the decoder will hypothesis that messages that cannot be > decoded with FEC alone contain that DX Call. When the DX Call field is > cleared only CQ is hypothesised which will reduce he probability of false > decodes. > > False decodes are rare but always possible because of the stochastic > nature of the decoders and the requirement to decode the weakest signals > possible. You also have the option to disable AP decoding, and reducing the > decoding depth which will also reduce the false decode probability with > some lose of sensitivity. > > 73 > Bill > G4WJS. > > On 26/04/2019 16:46, Mike Oakley wrote: > > FT8 and all bands. It just pops up. > > On Fri, Apr 26, 2019 at 11:28 AM Bill Somerville > wrote: > >> On 26/04/2019 16:04, Mike Oakley wrote: >> > I continue to get false decodes everyday even when I am not >> > transmitting, for example today I cut my rig on and loaded the >> > software and then I got a false decode before anything even popped on >> > my screen. Can someone tell me why I am getting these and how do I >> > stop them? >> >> Mike, >> >> which mode are you monitoring and on which band? >> >> 73 >> 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
Re: [wsjt-devel] False Decodes
Hi Mike, as others have suggested, AP decoding will raise the probability of false decodes a little. One thing you can do to reduce the false decode probability is to ensure the DX Call filed is cleared when you are not working or attempting to work another station. You can check the option in "Settings->Reporting" to clear it automatically after logging a QSO, for abandoned QSOs you can use the F4 or ESC shortcut keys to clear the DX Call, DX Grid and generated messages. The reason that clearing the DX Call filed helps is that AP decoding is context sensitive and with a DX Call field populated the decoder will hypothesis that messages that cannot be decoded with FEC alone contain that DX Call. When the DX Call field is cleared only CQ is hypothesised which will reduce he probability of false decodes. False decodes are rare but always possible because of the stochastic nature of the decoders and the requirement to decode the weakest signals possible. You also have the option to disable AP decoding, and reducing the decoding depth which will also reduce the false decode probability with some lose of sensitivity. 73 Bill G4WJS. On 26/04/2019 16:46, Mike Oakley wrote: FT8 and all bands. It just pops up. On Fri, Apr 26, 2019 at 11:28 AM Bill Somerville mailto:g4...@classdesign.com>> wrote: On 26/04/2019 16:04, Mike Oakley wrote: > I continue to get false decodes everyday even when I am not > transmitting, for example today I cut my rig on and loaded the > software and then I got a false decode before anything even popped on > my screen. Can someone tell me why I am getting these and how do I > stop them? Mike, which mode are you monitoring and on which band? 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] False Decodes
FT8 and all bands. It just pops up. On Fri, Apr 26, 2019 at 11:28 AM Bill Somerville wrote: > On 26/04/2019 16:04, Mike Oakley wrote: > > I continue to get false decodes everyday even when I am not > > transmitting, for example today I cut my rig on and loaded the > > software and then I got a false decode before anything even popped on > > my screen. Can someone tell me why I am getting these and how do I > > stop them? > > Mike, > > which mode are you monitoring and on which band? > > 73 > 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
[wsjt-devel] FT4 Decodes / #2, UDP
Hi! Perhaps I'm bit early (could not wait few days..) but compiled 2.1.0 from source and generated few audio files with ft4sim. When playing with them I did see only UDP messages #0 (heartbeat), #1 (status) and #5 (log) when pressed "log" Message that I was after was #2 (decode). Did I do something wrong or is it so that rc5 does not send #2 at all? (that is needed for external WB4/DXCC status program) -- Saku OH1KH ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] False Decodes
And thanks for the reply as well. On Fri, Apr 26, 2019, 11:24 AM Mike Oakley wrote: > From what I gather the false decodes always end with the ?a2 so far but > some from what I am getting do not have that. I just didn't know if it was > something I was doing wrong that's all. No I don't want to cut those out so > I guess I can ignore them as long as I know what they are. > > On Fri, Apr 26, 2019, 11:13 AM James Shaver wrote: > >> You can turn off AP decoding but, of course, you no longer have the >> advantage of AP decoding (whether that’s a loss is up to you). >> >> Or, you could ignore them since you’re aware they’re false decodes >> random patterns in the static can make the program spit out a false decode >> and it is just something that happens. >> >> 73, >> >> Jim S. >> N2ADV (ex KD2BIP) >> >> > On Apr 26, 2019, at 11:04 AM, Mike Oakley >> wrote: >> > >> > I continue to get false decodes everyday even when I am not >> transmitting, for example today I cut my rig on and loaded the software and >> then I got a false decode before anything even popped on my screen. Can >> someone tell me why I am getting these and how do I stop them? >> > ___ >> > 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 >> > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] False Decodes
>From what I gather the false decodes always end with the ?a2 so far but some from what I am getting do not have that. I just didn't know if it was something I was doing wrong that's all. No I don't want to cut those out so I guess I can ignore them as long as I know what they are. On Fri, Apr 26, 2019, 11:13 AM James Shaver wrote: > You can turn off AP decoding but, of course, you no longer have the > advantage of AP decoding (whether that’s a loss is up to you). > > Or, you could ignore them since you’re aware they’re false decodes > random patterns in the static can make the program spit out a false decode > and it is just something that happens. > > 73, > > Jim S. > N2ADV (ex KD2BIP) > > > On Apr 26, 2019, at 11:04 AM, Mike Oakley wrote: > > > > I continue to get false decodes everyday even when I am not > transmitting, for example today I cut my rig on and loaded the software and > then I got a false decode before anything even popped on my screen. Can > someone tell me why I am getting these and how do I stop them? > > ___ > > 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 > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] False Decodes
On 26/04/2019 16:04, Mike Oakley wrote: I continue to get false decodes everyday even when I am not transmitting, for example today I cut my rig on and loaded the software and then I got a false decode before anything even popped on my screen. Can someone tell me why I am getting these and how do I stop them? Mike, which mode are you monitoring and on which band? 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] False Decodes
You can turn off AP decoding but, of course, you no longer have the advantage of AP decoding (whether that’s a loss is up to you). Or, you could ignore them since you’re aware they’re false decodes random patterns in the static can make the program spit out a false decode and it is just something that happens. 73, Jim S. N2ADV (ex KD2BIP) > On Apr 26, 2019, at 11:04 AM, Mike Oakley wrote: > > I continue to get false decodes everyday even when I am not transmitting, for > example today I cut my rig on and loaded the software and then I got a false > decode before anything even popped on my screen. Can someone tell me why I am > getting these and how do I stop them? > ___ > 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
[wsjt-devel] False Decodes
I continue to get false decodes everyday even when I am not transmitting, for example today I cut my rig on and loaded the software and then I got a false decode before anything even popped on my screen. Can someone tell me why I am getting these and how do I stop them? ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] The FT4 Protocol for Digital Contesting
Grant's suggested frequencies make sense to me. I would support his recommendations. Don AA5AU On Friday, April 26, 2019, 6:18:08 AM CDT, Grant VK5GR wrote: Joe et al, A word if I may about frequency choices. Some of those proposed for FT4 probably leave a bit to be desired. Here are some thoughts to consider: 80m 3.595 - PROPOSE 3562kHz - 3595 is completely out of band for JA completely and into the phone part of the band outside of Region 2. My suggestion based on occupancy and proximity to existing digital sub-bands is something around 3562kHz (at least keeping away from 3560 which is sometimes a CW QRP frequency). While the IARU band plans currently have digital as 3570-3590kHz a case can be made for expanding that - and given other restrictions in some countries on 80m, expanding digital down at least 8kHz to 3562kHz makes some sense. A case to be made for the IARU - but you can "help" their decision by starting to use it anyway. BTW 3600kHz is the centre frequency for IARU R3 80m disaster comms - LSB - so FT4 on 3595 USB will badly clash with that - another reason not to use 3595. 40m 7.090 - PROPOSE 7052kHz (inside the digital sub-band) or 7062kHz (just above the digital sub-band noting it is heavily used for SSB at least in region 3) - 7090 only makes sense in the USA! Many other countries have this as SSB voice use. The IARU digital segment is (depending on region) 7040-7060 or 7040-7060. With 7056 already being used for FT8 F/H mode on a fairly regular basis it would make sense to use say 7050 or 7052kHz instead. Note that 7090 is the designated SSB QRP frequency. I would promote 7050 for FT4. The only reason not to is that the RTTY guys if FT4 and RTTY are in the same contest might object - but during the contests the RTTY guys spread out and use anything from 7030 to 7120 anyway in complete disregard of the band plans. If they are going to be that unruly then putting FT4 down there doesn't seem all that bad. * 30m / 17m / 12m - should NOT have FT4 allocations at all. FT4 is a CONTESTING mode and CONTESTING is by global agreement excluded from those WRC79 bands!!! * 20m 14.140 - PROPOSE 14062kHz - the original proposed use of 14140KHz again is well outside the digital segments where FT4 belongs. If anything, creeping down into 14060-14070 might be considered acceptable despite not being in the band plan if the aim was to separate RTTY and FT4 users in the same contest. Going high above 14.112 (the acknowledged edge of the global 20m digital band plan segment) will be frowned upon. Take a leaf from 80m and use 14062kHz - again at least that keeps it away from the CW QRP Centre of activity and meets the objective of separating it from RTTY. 15m 21.140 - PROPOSE 21062kHz - follow 20m and choose 21062kHz - although 21140kHz is the first proposed FT4 frequency that fell inside a digital subband... 10m 28.180 - POROPOSE 28062kHz - again follow 20m 6m 50.318 - PROPOSE somewhere below 50.313 not above. Moving above is just moving further into several countries beacon segments. Not likely to get a lot of airplay as a international contesting band for FT8 so not as critical - but my suggestion would be look below 50.313 not above. For discussion folks. Regards, Grant VK5GR WIA Appointee to the IARU Region 3 Band Plan committee -Original Message- From: Joe Taylor [mailto:j...@princeton.edu] Sent: Tuesday, 23 April 2019 1:04 AM To: WSJT software development Subject: [wsjt-devel] The FT4 Protocol for Digital Contesting To: WSJT-X users interested in testing FT4 From: K1JT, K9AN, and G4WJS Soon after the "FT8 Roundup" held on December 1-2, 2018, we started serious work on a faster, more contest-friendly digital mode that can compete with RTTY-contesting QSO rates while preserving many of the benefits of FT8. The result is FT4 -- a new digital mode specifically designed for radio contesting. Over the past month a small group of volunteers have been conducting on-the-air tests of FT4. The early tests were very successful and helped us to make a number of important design decisions. We believe FT4 has considerable promise for its intended purpose. We'll soon be ready for testing by a larger group. If you might be interested in participating and offering your considered feedback, please read the descriptive document "The FT4 Protocol for Digital Contesting", posted here: http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf We plan to post downloadable installation packages for WSJT-X 2.1.0-rc5 on April 29, one week from today. The document linked above includes - Instructions for installing WSJT-X 2.1.0-rc5 and FT4 configuration - Operating instructions for FT4 - Basic description of the FT4 protocol, modulation, and waveform - Detailed sensitivity measurements for FT4 under a wide variety of simulated propagation conditions - Schedule for upcoming test sessions Please consider helping us to make FT4 a
Re: [wsjt-devel] The FT4 Protocol for Digital Contesting
Köszi! Nekem is jönnek ezek a levelek! On Fri, Apr 26, 2019 at 11:19 AM Grant VK5GR wrote: > Joe et al, > > A word if I may about frequency choices. Some of those proposed for FT4 > probably leave a bit to be desired. Here are some thoughts to consider: > > 80m 3.595 - PROPOSE 3562kHz - 3595 is completely out of band for JA > completely and into the phone part of the band outside of Region 2. My > suggestion based on occupancy and proximity to existing digital sub-bands > is > something around 3562kHz (at least keeping away from 3560 which is > sometimes > a CW QRP frequency). While the IARU band plans currently have digital as > 3570-3590kHz a case can be made for expanding that - and given other > restrictions in some countries on 80m, expanding digital down at least 8kHz > to 3562kHz makes some sense. A case to be made for the IARU - but you can > "help" their decision by starting to use it anyway. BTW 3600kHz is the > centre frequency for IARU R3 80m disaster comms - LSB - so FT4 on 3595 USB > will badly clash with that - another reason not to use 3595. > > 40m 7.090 - PROPOSE 7052kHz (inside the digital sub-band) or 7062kHz (just > above the digital sub-band noting it is heavily used for SSB at least in > region 3) - 7090 only makes sense in the USA! Many other countries have > this > as SSB voice use. The IARU digital segment is (depending on region) > 7040-7060 or 7040-7060. With 7056 already being used for FT8 F/H mode on a > fairly regular basis it would make sense to use say 7050 or 7052kHz > instead. > Note that 7090 is the designated SSB QRP frequency. I would promote 7050 > for > FT4. The only reason not to is that the RTTY guys if FT4 and RTTY are in > the > same contest might object - but during the contests the RTTY guys spread > out > and use anything from 7030 to 7120 anyway in complete disregard of the band > plans. If they are going to be that unruly then putting FT4 down there > doesn't seem all that bad. > > * 30m / 17m / 12m - should NOT have FT4 allocations at all. FT4 is > a > CONTESTING mode and CONTESTING is by global agreement excluded from those > WRC79 bands!!! * > > 20m 14.140 - PROPOSE 14062kHz - the original proposed use of 14140KHz again > is well outside the digital segments where FT4 belongs. If anything, > creeping down into 14060-14070 might be considered acceptable despite not > being in the band plan if the aim was to separate RTTY and FT4 users in the > same contest. Going high above 14.112 (the acknowledged edge of the global > 20m digital band plan segment) will be frowned upon. Take a leaf from 80m > and use 14062kHz - again at least that keeps it away from the CW QRP Centre > of activity and meets the objective of separating it from RTTY. > > 15m 21.140 - PROPOSE 21062kHz - follow 20m and choose 21062kHz - although > 21140kHz is the first proposed FT4 frequency that fell inside a digital > subband... > > 10m 28.180 - POROPOSE 28062kHz - again follow 20m > > 6m 50.318 - PROPOSE somewhere below 50.313 not above. Moving above is just > moving further into several countries beacon segments. Not likely to get a > lot of airplay as a international contesting band for FT8 so not as > critical > - but my suggestion would be look below 50.313 not above. > > For discussion folks. > > Regards, > Grant VK5GR > WIA Appointee to the IARU Region 3 Band Plan committee > > > > > -Original Message- > From: Joe Taylor [mailto:j...@princeton.edu] > Sent: Tuesday, 23 April 2019 1:04 AM > To: WSJT software development > Subject: [wsjt-devel] The FT4 Protocol for Digital Contesting > > To: WSJT-X users interested in testing FT4 > From: K1JT, K9AN, and G4WJS > > Soon after the "FT8 Roundup" held on December 1-2, 2018, we started > serious work on a faster, more contest-friendly digital mode that can > compete with RTTY-contesting QSO rates while preserving many of the > benefits of FT8. The result is FT4 -- a new digital mode specifically > designed for radio contesting. > > Over the past month a small group of volunteers have been conducting > on-the-air tests of FT4. The early tests were very successful and > helped us to make a number of important design decisions. We believe > FT4 has considerable promise for its intended purpose. > > We'll soon be ready for testing by a larger group. If you might be > interested in participating and offering your considered feedback, > please read the descriptive document "The FT4 Protocol for Digital > Contesting", posted here: > http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf > > We plan to post downloadable installation packages for WSJT-X 2.1.0-rc5 > on April 29, one week from today. The document linked above includes > > - Instructions for installing WSJT-X 2.1.0-rc5 and FT4 configuration > > - Operating instructions for FT4 > > - Basic description of the FT4 protocol, modulation, and waveform > > - Detailed sensitivity measurements for FT4 under a wide variety of > simulated
Re: [wsjt-devel] The FT4 Protocol for Digital Contesting
Joe et al, A word if I may about frequency choices. Some of those proposed for FT4 probably leave a bit to be desired. Here are some thoughts to consider: 80m 3.595 - PROPOSE 3562kHz - 3595 is completely out of band for JA completely and into the phone part of the band outside of Region 2. My suggestion based on occupancy and proximity to existing digital sub-bands is something around 3562kHz (at least keeping away from 3560 which is sometimes a CW QRP frequency). While the IARU band plans currently have digital as 3570-3590kHz a case can be made for expanding that - and given other restrictions in some countries on 80m, expanding digital down at least 8kHz to 3562kHz makes some sense. A case to be made for the IARU - but you can "help" their decision by starting to use it anyway. BTW 3600kHz is the centre frequency for IARU R3 80m disaster comms - LSB - so FT4 on 3595 USB will badly clash with that - another reason not to use 3595. 40m 7.090 - PROPOSE 7052kHz (inside the digital sub-band) or 7062kHz (just above the digital sub-band noting it is heavily used for SSB at least in region 3) - 7090 only makes sense in the USA! Many other countries have this as SSB voice use. The IARU digital segment is (depending on region) 7040-7060 or 7040-7060. With 7056 already being used for FT8 F/H mode on a fairly regular basis it would make sense to use say 7050 or 7052kHz instead. Note that 7090 is the designated SSB QRP frequency. I would promote 7050 for FT4. The only reason not to is that the RTTY guys if FT4 and RTTY are in the same contest might object - but during the contests the RTTY guys spread out and use anything from 7030 to 7120 anyway in complete disregard of the band plans. If they are going to be that unruly then putting FT4 down there doesn't seem all that bad. * 30m / 17m / 12m - should NOT have FT4 allocations at all. FT4 is a CONTESTING mode and CONTESTING is by global agreement excluded from those WRC79 bands!!! * 20m 14.140 - PROPOSE 14062kHz - the original proposed use of 14140KHz again is well outside the digital segments where FT4 belongs. If anything, creeping down into 14060-14070 might be considered acceptable despite not being in the band plan if the aim was to separate RTTY and FT4 users in the same contest. Going high above 14.112 (the acknowledged edge of the global 20m digital band plan segment) will be frowned upon. Take a leaf from 80m and use 14062kHz - again at least that keeps it away from the CW QRP Centre of activity and meets the objective of separating it from RTTY. 15m 21.140 - PROPOSE 21062kHz - follow 20m and choose 21062kHz - although 21140kHz is the first proposed FT4 frequency that fell inside a digital subband... 10m 28.180 - POROPOSE 28062kHz - again follow 20m 6m 50.318 - PROPOSE somewhere below 50.313 not above. Moving above is just moving further into several countries beacon segments. Not likely to get a lot of airplay as a international contesting band for FT8 so not as critical - but my suggestion would be look below 50.313 not above. For discussion folks. Regards, Grant VK5GR WIA Appointee to the IARU Region 3 Band Plan committee -Original Message- From: Joe Taylor [mailto:j...@princeton.edu] Sent: Tuesday, 23 April 2019 1:04 AM To: WSJT software development Subject: [wsjt-devel] The FT4 Protocol for Digital Contesting To: WSJT-X users interested in testing FT4 From: K1JT, K9AN, and G4WJS Soon after the "FT8 Roundup" held on December 1-2, 2018, we started serious work on a faster, more contest-friendly digital mode that can compete with RTTY-contesting QSO rates while preserving many of the benefits of FT8. The result is FT4 -- a new digital mode specifically designed for radio contesting. Over the past month a small group of volunteers have been conducting on-the-air tests of FT4. The early tests were very successful and helped us to make a number of important design decisions. We believe FT4 has considerable promise for its intended purpose. We'll soon be ready for testing by a larger group. If you might be interested in participating and offering your considered feedback, please read the descriptive document "The FT4 Protocol for Digital Contesting", posted here: http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf We plan to post downloadable installation packages for WSJT-X 2.1.0-rc5 on April 29, one week from today. The document linked above includes - Instructions for installing WSJT-X 2.1.0-rc5 and FT4 configuration - Operating instructions for FT4 - Basic description of the FT4 protocol, modulation, and waveform - Detailed sensitivity measurements for FT4 under a wide variety of simulated propagation conditions - Schedule for upcoming test sessions Please consider helping us to make FT4 a successful mode for digital contesting With best wishes and 73, -- Joe (K1JT), Steve (K9AN), and Bill (G4WJS) ___
Re: [wsjt-devel] Suggestion for Additional Checkbox
On 25 Apr 2019 at 14:30, Bill Somerville wrote: > Frank, > > WSJT-X tries to prevent *Fox* FT8 DXpedition mode stations from > operating on the "usual" FT8 frequencies. Clearly we cannot stop use of > Fox mode if the DX does not use CAT control. Other programs like MSHV > allow a mode similar to Fox mode on normal FT8 frequencies but AFAIK you > do not need to select WSJT-X Hound mode to work DX using that > application. This causes considerable confusion and when the so-called > multi-threaded mode on MSHV is enabled on normal FT8 frequencies it > causes QRM to other users by using more bandwidth than other stations, > but TBH that's what happens with DXpeditions anyway. WSJT-X Fox & Hound > DXpedition mode was designed to facilitate the larger DXpeditions, i.e. > in the top 100 most wanted lists and able to operate 24/7 for most of > the DXpedition operation. This warrants using a separate pre-published > frequency schedule and there using multiple QSOs in parallel is quite > acceptable for maximum throughput, thereby allowing as many users as > possible to get in the DXpedition log without having to use high gain > aerials and high power levels. Hello Bill, thanks for your email above which has certainly helped me, and hopefully others, understand a bit better the operating-frequency constraints of FT8's (and presumably FT4's) Fox & Hound DXpedition mode. I don't know if others, like me, had gained the impression from various postings to this email list and on the Yahoo group that the WSJT-X s/ware was intended to prevent any station operating in *either* Fox *or* Hound mode from transmitting in the standard FT8 band segments, but your email certainly seems to indicate that it's only a Fox that's so-constrained; if my interpretation is correct then it begs the question of whether Hounds should also be prevented from Tx'ing in the standard segments. Perhaps the software could apply a Hound-mode stop-band around each of the standard FT8 frequencies; for example if Hound mode is enabled and the rig is tuned to anywhere within say 14070 to 14078kHz then transmission would be prevented. Of course this would only function if the rig was being CAT-controlled so that the dial frequency was known to the software; it wouldn't prevent a Hound station not using CAT from Tx'ing in the standard segments. The desirability or otherwise of using CAT is open to ongoing discussion... :-) In your email you mention stations using the MSHV software; I (and I expect many others) can confirm that it's not necessary to use Hound mode to work such stations - the standard FT8 mode works just fine in such scenarios. As you've pointed out, the use of the MSHV multi-threaded mode in the standard band segments can be (and probably is) a cause of significant confusion, and no doubt the desirability of such multi-threaded operating in the standard segments will continue to be a topic for sometimes heated debate... -- 73, Martin G0HDB --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
