Re: [wsjt-devel] RC3 Issues
Update. If I stay in tab 1 when I click on someone to call, it will sequence. If I start CQ with TX6 then it sequences. I have generally stayed in tab 2 in RC2 and prior with no issues. Switching back to tab 2 sequences fine after that. Exiting the program and starting CQ from tab 2 works fine now too. Not sure what happened here but it appears to be working now. Perhaps something got changed when I had a successful QSO using tab 1? Smh Sorry for cluttering your mailboxes. Rob - KW2E ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Reminder: Mock "FT8 Roundup" Contest is tomorrow
A one-hour "practice contest" will be held tomorrow (Wednesday evening,
NA time) using the FT8 mode and the ARRL RTTY Roundup rules.
Date and time: Thursday, 25 October 0200-0300 UTC
Dial frequency 7.078 (and higher, in 2 kHz increments, if too much QRM).
Everyone works everyone.
To participate you must use WSJT-X 2.0.0-rc3. Installation packages for
Windows, Linux, and macOS can be found near the bottom of this web page:
https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
Note that this Release Candidate 3 ("RC3") is a beta-test version. A
full release of WSJT-X 2.0 is targeted for release on December 10, 2018.
A revised Quick-Start Guide to WSJT-X 2.0 for RC3 is posted here:
https://physics.princeton.edu/pulsar/k1jt/Quick_Start_WSJT-X_2.0.pdf
Be sure to read this entire document before using WSJT-X 2.0. Changes
in RC3 relative to RC2 are described starting on page 7.
If you have not already used RC3, and especially if you will use Linux
of macOS, be sure to read this message containing work-arounds for known
issues:
https://sourceforge.net/p/wsjt/mailman/wsjt-devel/thread/ca07c870-e48d-1a7d-9183-0c40afb2ebf9%40princeton.edu/#msg36444674
IMPORTANT FOR THE MOCK CONTEST:
1. On the *Settings | Advanced* tab, be sure to check the boxes
*Always generate 77-bit messages*, *Decode only 77-bit messages*, and
*ARRL RTTY Roundup*. In the field labeled "Exch" enter the 2- or
3-letter abbreviation for your state or province (US/Canadian stations)
or DX if you are not in the US or Canada.
2. Be sure that 7.078 appears in your drop-down frequency list for FT8
mode. You might need to do a *Reset* on the *Settings | Frequencies*
tab. If the sub-band starting at 7.078 becomes over-crowded we suggest
moving to higher dial frequencies in 2 kHz increments: 7.080, 7.082,
etc. Type Ctrl+Shift+F12 to move up by 2 kHz, Ctrl+Shift+F11 to move
down by 2 kHz.
3. Do not use a compound or nonstandard callsign in this event.
Note that planning is underway for one or more dedicated FT8 contests to
be held in the next few months. The ARRL RTTY Roundup, January 5-6 2018,
is explicitly encouraging FT8 as well as RTTY participation.
If you are not already subscribed, you may wish to join the email list
wsjt-devel:
https://sourceforge.net/p/wsjt/mailman/?source=navbar
That list is the best way to communicate directly with the WSJT
Development Group.
Post results and comments here so we can all learn from an actual FT8
contest-like experience.
-- 73, Joe, K1JT
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RC3 & Strong Signals
Definitely 77-bit. I had only checked and could eventually hear responding stations. Just strange, imho. Lots of variables. I currently chalk it up to over-driving the transmit audio, but just curious if there was anything else I may have missed. Best, Jotrdan On Tue, Oct 23, 2018 at 12:16 PM WB5JJJ wrote: > The other option was perhaps it was a true FT8 signal, but running the > legacy mode, maybe overmodulated or excessive hum on their transmission. > Try unchecking the receive ONLY 77bit and see if you can decode it then. > If you can, don't forget to uncheck the ALWAYS transmit 77bit to work > them. > > On Tue, Oct 23, 2018 at 11:05 AM Jordan Sherer > wrote: > >> Interesting. Could be, but I don't think this instance was exactly this. >> FT8Call (JS8Call now) doesn't use an every other tx cycle when calling CQ, >> so it seems that this was indeed an FT8 signal. They called every other >> cycle for about 2 minutes on the same frequency until I was able to decode >> the responding station to their CQs (which I couldn't decode). >> >> Any other thoughts? Any other reason for a really strong station to fail >> decoding? >> >> Best, >> Jordan >> >> On Tue, Oct 23, 2018 at 11:50 AM WB5JJJ wrote: >> >>> If you are on the 77bit frequencies on 40 or 20, then the most likely >>> culprit is you are seeing the non-conforming FT8Call (now JS8Call) >>> signals. They are totally incompatible with the standard FT8 either old >>> school or RC3 77bit. I see these all the time and are usually very strong >>> when compared to the rest of the real FT8 signals. Also, the decode you >>> were able to see was probably a real FT8 encoded signal at about the same >>> frequency. >>> >>> Most likely there is nothing wrong with your setup, it's just rogue >>> signals that "look" like FT8. In reality, there are very few 77bit signals >>> right now as the bulk of the testing has already been carried out some >>> weeks back. Exception is MSK144, which is only 77bit in RC3, I still see >>> some users there early in the morning on 6m. And remember the DXPeditions >>> are still using v1.9.1 as RC3 is a beta and not in wide usage as of yet. >>> >>> On Tue, Oct 23, 2018 at 10:12 AM Jordan Sherer >>> wrote: >>> Hi Folks, Testing out RC3 today and 77-bit FT8 I found some very strong signals in the band that were troublesome to decode. Now, I'm fairly fluent in FT8 and I keep my Elecraft station configured properly. NTP for time synchronization (ony a few ms divergence), AGC Off, RF gain/ATTN set so the in-app audio meter sits at ~30dB. Most signals are perfect. But this one today eluded me. It decoded once at +10dB with a time delta less than 0.3. Then, subsequent cycles did not decode. It seems like the decoder might have been getting a bad sync. Curious if this might just be a case of that station over-driving their transmit audio or if something else might be afoul? Perhaps there's drift involved here too? I've seen this happen with strong signals on 1.9 as well, so I know its not entirely related to RC3, but do know that 2.0 changed the synchronization scheme so am curious to dig in deeper. I know y'all are busy so what's likely the best way to diagnose this myself to help y'all out? Best, Jordan ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel >>> >>> >>> -- >>> George Cotton, WB5JJJ >>> PO Box 1025 >>> Russellville, AR 72811 >>> >>> 479.968.7737 Home >>> 479.857.7737 Cell >>> >>> DMR K5CS (Local Repeater) - 310515, CC1, TS2 >>> DMR Arkansas - 3105 >>> >>> 4 >>> ___ >>> 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 >> > > > -- > George Cotton, WB5JJJ > PO Box 1025 > Russellville, AR 72811 > > 479.968.7737 Home > 479.857.7737 Cell > > DMR K5CS (Local Repeater) - 310515, CC1, TS2 > DMR Arkansas - 3105 > > 4 > ___ > 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] RC3 & Strong Signals
The other option was perhaps it was a true FT8 signal, but running the legacy mode, maybe overmodulated or excessive hum on their transmission. Try unchecking the receive ONLY 77bit and see if you can decode it then. If you can, don't forget to uncheck the ALWAYS transmit 77bit to work them. On Tue, Oct 23, 2018 at 11:05 AM Jordan Sherer wrote: > Interesting. Could be, but I don't think this instance was exactly this. > FT8Call (JS8Call now) doesn't use an every other tx cycle when calling CQ, > so it seems that this was indeed an FT8 signal. They called every other > cycle for about 2 minutes on the same frequency until I was able to decode > the responding station to their CQs (which I couldn't decode). > > Any other thoughts? Any other reason for a really strong station to fail > decoding? > > Best, > Jordan > > On Tue, Oct 23, 2018 at 11:50 AM WB5JJJ wrote: > >> If you are on the 77bit frequencies on 40 or 20, then the most likely >> culprit is you are seeing the non-conforming FT8Call (now JS8Call) >> signals. They are totally incompatible with the standard FT8 either old >> school or RC3 77bit. I see these all the time and are usually very strong >> when compared to the rest of the real FT8 signals. Also, the decode you >> were able to see was probably a real FT8 encoded signal at about the same >> frequency. >> >> Most likely there is nothing wrong with your setup, it's just rogue >> signals that "look" like FT8. In reality, there are very few 77bit signals >> right now as the bulk of the testing has already been carried out some >> weeks back. Exception is MSK144, which is only 77bit in RC3, I still see >> some users there early in the morning on 6m. And remember the DXPeditions >> are still using v1.9.1 as RC3 is a beta and not in wide usage as of yet. >> >> On Tue, Oct 23, 2018 at 10:12 AM Jordan Sherer >> wrote: >> >>> Hi Folks, >>> >>> Testing out RC3 today and 77-bit FT8 I found some very strong signals in >>> the band that were troublesome to decode. >>> >>> Now, I'm fairly fluent in FT8 and I keep my Elecraft station configured >>> properly. NTP for time synchronization (ony a few ms divergence), AGC Off, >>> RF gain/ATTN set so the in-app audio meter sits at ~30dB. >>> >>> Most signals are perfect. But this one today eluded me. It decoded once >>> at +10dB with a time delta less than 0.3. Then, subsequent cycles did not >>> decode. >>> >>> It seems like the decoder might have been getting a bad sync. Curious if >>> this might just be a case of that station over-driving their transmit audio >>> or if something else might be afoul? Perhaps there's drift involved here >>> too? I've seen this happen with strong signals on 1.9 as well, so I know >>> its not entirely related to RC3, but do know that 2.0 changed the >>> synchronization scheme so am curious to dig in deeper. >>> >>> I know y'all are busy so what's likely the best way to diagnose this >>> myself to help y'all out? >>> >>> Best, >>> Jordan >>> ___ >>> wsjt-devel mailing list >>> wsjt-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >>> >> >> >> -- >> George Cotton, WB5JJJ >> PO Box 1025 >> Russellville, AR 72811 >> >> 479.968.7737 Home >> 479.857.7737 Cell >> >> DMR K5CS (Local Repeater) - 310515, CC1, TS2 >> DMR Arkansas - 3105 >> >> 4 >> ___ >> 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 > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RC3 & Strong Signals
Interesting. Could be, but I don't think this instance was exactly this. FT8Call (JS8Call now) doesn't use an every other tx cycle when calling CQ, so it seems that this was indeed an FT8 signal. They called every other cycle for about 2 minutes on the same frequency until I was able to decode the responding station to their CQs (which I couldn't decode). Any other thoughts? Any other reason for a really strong station to fail decoding? Best, Jordan On Tue, Oct 23, 2018 at 11:50 AM WB5JJJ wrote: > If you are on the 77bit frequencies on 40 or 20, then the most likely > culprit is you are seeing the non-conforming FT8Call (now JS8Call) > signals. They are totally incompatible with the standard FT8 either old > school or RC3 77bit. I see these all the time and are usually very strong > when compared to the rest of the real FT8 signals. Also, the decode you > were able to see was probably a real FT8 encoded signal at about the same > frequency. > > Most likely there is nothing wrong with your setup, it's just rogue > signals that "look" like FT8. In reality, there are very few 77bit signals > right now as the bulk of the testing has already been carried out some > weeks back. Exception is MSK144, which is only 77bit in RC3, I still see > some users there early in the morning on 6m. And remember the DXPeditions > are still using v1.9.1 as RC3 is a beta and not in wide usage as of yet. > > On Tue, Oct 23, 2018 at 10:12 AM Jordan Sherer > wrote: > >> Hi Folks, >> >> Testing out RC3 today and 77-bit FT8 I found some very strong signals in >> the band that were troublesome to decode. >> >> Now, I'm fairly fluent in FT8 and I keep my Elecraft station configured >> properly. NTP for time synchronization (ony a few ms divergence), AGC Off, >> RF gain/ATTN set so the in-app audio meter sits at ~30dB. >> >> Most signals are perfect. But this one today eluded me. It decoded once >> at +10dB with a time delta less than 0.3. Then, subsequent cycles did not >> decode. >> >> It seems like the decoder might have been getting a bad sync. Curious if >> this might just be a case of that station over-driving their transmit audio >> or if something else might be afoul? Perhaps there's drift involved here >> too? I've seen this happen with strong signals on 1.9 as well, so I know >> its not entirely related to RC3, but do know that 2.0 changed the >> synchronization scheme so am curious to dig in deeper. >> >> I know y'all are busy so what's likely the best way to diagnose this >> myself to help y'all out? >> >> Best, >> Jordan >> ___ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> > > > -- > George Cotton, WB5JJJ > PO Box 1025 > Russellville, AR 72811 > > 479.968.7737 Home > 479.857.7737 Cell > > DMR K5CS (Local Repeater) - 310515, CC1, TS2 > DMR Arkansas - 3105 > > 4 > ___ > 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] wsjt-devel Digest, Vol 56, Issue 152
Joe has to be wondering why he released FT8. RTF manual people! [I have to admit I missed the 77-bit only F note - but I did read the rest] On Tue, Oct 23, 2018 at 9:46 AM wrote: > Send wsjt-devel mailing list submissions to > wsjt-devel@lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > or, via email, send a message with subject or body 'help' to > wsjt-devel-requ...@lists.sourceforge.net > > You can reach the person managing the list at > wsjt-devel-ow...@lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wsjt-devel digest..." > Today's Topics: > >1. Re: No decode rc3 in FH on x64 Ubuntu 18.10 (WB5JJJ) >2. Re: No decode rc3 in FH on x64 Ubuntu 18.10 (David Spoelstra) >3. RC3 & Strong Signals (Jordan Sherer) >4. Re: RC3 & Strong Signals (WB5JJJ) > > > > -- Forwarded message -- > From: WB5JJJ > To: wsjt-devel@lists.sourceforge.net > Cc: > Bcc: > Date: Tue, 23 Oct 2018 08:15:45 -0500 > Subject: Re: [wsjt-devel] No decode rc3 in FH on x64 Ubuntu 18.10 > As stated by Joe Taylor, RC3 is NOT designed for DXP until the full > release. It uses 77 bit and none of the DXP are using that mode since it > is still in beta. VP6D specifically stated NOT to use RC3 and use v1.9.1 > for this exact reason. > > On Tue, Oct 23, 2018 at 4:39 AM David Spoelstra > wrote: > >> Ubuntu 18.10 >> WSJT-X V2.0.0-rc3 >> >> In normal mode everything decodes ok. Switch to FH mode and there is no >> decode even though waterfall shows strong signals. Switch back to normal >> mode and everything decodes. >> >> Switch back to 1.9.1 and both modes decode ok. >> >> Switch back to rc3 and same decode problem in FH mode. >> >> ___ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> > > > -- > George Cotton, WB5JJJ > PO Box 1025 > Russellville, AR 72811 > > 479.968.7737 Home > 479.857.7737 Cell > > DMR K5CS (Local Repeater) - 310515, CC1, TS2 > DMR Arkansas - 3105 > > 4 > > > > -- Forwarded message -- > From: David Spoelstra > To: WSJT software development > Cc: > Bcc: > Date: Tue, 23 Oct 2018 10:12:39 -0400 > Subject: Re: [wsjt-devel] No decode rc3 in FH on x64 Ubuntu 18.10 > Sorry. Trying to give it a good test. I got fooled because I worked > several others FH with that version ok. > > On Tue, Oct 23, 2018 at 9:16 AM WB5JJJ wrote: > >> As stated by Joe Taylor, RC3 is NOT designed for DXP until the full >> release. It uses 77 bit and none of the DXP are using that mode since it >> is still in beta. VP6D specifically stated NOT to use RC3 and use v1.9.1 >> for this exact reason. >> >> On Tue, Oct 23, 2018 at 4:39 AM David Spoelstra >> wrote: >> >>> Ubuntu 18.10 >>> WSJT-X V2.0.0-rc3 >>> >>> In normal mode everything decodes ok. Switch to FH mode and there is no >>> decode even though waterfall shows strong signals. Switch back to normal >>> mode and everything decodes. >>> >>> Switch back to 1.9.1 and both modes decode ok. >>> >>> Switch back to rc3 and same decode problem in FH mode. >>> >>> ___ >>> wsjt-devel mailing list >>> wsjt-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >>> >> >> >> -- >> George Cotton, WB5JJJ >> PO Box 1025 >> Russellville, AR 72811 >> >> 479.968.7737 <(479)%20968-7737> Home >> 479.857.7737 <(479)%20857-7737> Cell >> >> DMR K5CS (Local Repeater) - 310515, CC1, TS2 >> DMR Arkansas - 3105 >> >> 4 >> ___ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> > > > > -- Forwarded message -- > From: Jordan Sherer > To: WSJT software development > Cc: > Bcc: > Date: Tue, 23 Oct 2018 11:04:01 -0400 > Subject: [wsjt-devel] RC3 & Strong Signals > Hi Folks, > > Testing out RC3 today and 77-bit FT8 I found some very strong signals in > the band that were troublesome to decode. > > Now, I'm fairly fluent in FT8 and I keep my Elecraft station configured > properly. NTP for time synchronization (ony a few ms divergence), AGC Off, > RF gain/ATTN set so the in-app audio meter sits at ~30dB. > > Most signals are perfect. But this one today eluded me. It decoded once > at +10dB with a time delta less than 0.3. Then, subsequent cycles did not > decode. > > It seems like the decoder might have been getting a bad sync. Curious if > this might just be a case of that station over-driving their transmit audio > or if something else might be afoul? Perhaps there's drift involved here > too? I've seen this happen with strong signals on 1.9 as well, so I know > its not entirely related to RC3, but do know that 2.0 changed the > synchronization scheme so am
Re: [wsjt-devel] RC3 & Strong Signals
If you are on the 77bit frequencies on 40 or 20, then the most likely culprit is you are seeing the non-conforming FT8Call (now JS8Call) signals. They are totally incompatible with the standard FT8 either old school or RC3 77bit. I see these all the time and are usually very strong when compared to the rest of the real FT8 signals. Also, the decode you were able to see was probably a real FT8 encoded signal at about the same frequency. Most likely there is nothing wrong with your setup, it's just rogue signals that "look" like FT8. In reality, there are very few 77bit signals right now as the bulk of the testing has already been carried out some weeks back. Exception is MSK144, which is only 77bit in RC3, I still see some users there early in the morning on 6m. And remember the DXPeditions are still using v1.9.1 as RC3 is a beta and not in wide usage as of yet. On Tue, Oct 23, 2018 at 10:12 AM Jordan Sherer wrote: > Hi Folks, > > Testing out RC3 today and 77-bit FT8 I found some very strong signals in > the band that were troublesome to decode. > > Now, I'm fairly fluent in FT8 and I keep my Elecraft station configured > properly. NTP for time synchronization (ony a few ms divergence), AGC Off, > RF gain/ATTN set so the in-app audio meter sits at ~30dB. > > Most signals are perfect. But this one today eluded me. It decoded once > at +10dB with a time delta less than 0.3. Then, subsequent cycles did not > decode. > > It seems like the decoder might have been getting a bad sync. Curious if > this might just be a case of that station over-driving their transmit audio > or if something else might be afoul? Perhaps there's drift involved here > too? I've seen this happen with strong signals on 1.9 as well, so I know > its not entirely related to RC3, but do know that 2.0 changed the > synchronization scheme so am curious to dig in deeper. > > I know y'all are busy so what's likely the best way to diagnose this > myself to help y'all out? > > Best, > Jordan > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] RC3 & Strong Signals
Hi Folks, Testing out RC3 today and 77-bit FT8 I found some very strong signals in the band that were troublesome to decode. Now, I'm fairly fluent in FT8 and I keep my Elecraft station configured properly. NTP for time synchronization (ony a few ms divergence), AGC Off, RF gain/ATTN set so the in-app audio meter sits at ~30dB. Most signals are perfect. But this one today eluded me. It decoded once at +10dB with a time delta less than 0.3. Then, subsequent cycles did not decode. It seems like the decoder might have been getting a bad sync. Curious if this might just be a case of that station over-driving their transmit audio or if something else might be afoul? Perhaps there's drift involved here too? I've seen this happen with strong signals on 1.9 as well, so I know its not entirely related to RC3, but do know that 2.0 changed the synchronization scheme so am curious to dig in deeper. I know y'all are busy so what's likely the best way to diagnose this myself to help y'all out? Best, Jordan ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] No decode rc3 in FH on x64 Ubuntu 18.10
Sorry. Trying to give it a good test. I got fooled because I worked several others FH with that version ok. On Tue, Oct 23, 2018 at 9:16 AM WB5JJJ wrote: > As stated by Joe Taylor, RC3 is NOT designed for DXP until the full > release. It uses 77 bit and none of the DXP are using that mode since it > is still in beta. VP6D specifically stated NOT to use RC3 and use v1.9.1 > for this exact reason. > > On Tue, Oct 23, 2018 at 4:39 AM David Spoelstra > wrote: > >> Ubuntu 18.10 >> WSJT-X V2.0.0-rc3 >> >> In normal mode everything decodes ok. Switch to FH mode and there is no >> decode even though waterfall shows strong signals. Switch back to normal >> mode and everything decodes. >> >> Switch back to 1.9.1 and both modes decode ok. >> >> Switch back to rc3 and same decode problem in FH mode. >> >> ___ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> > > > -- > George Cotton, WB5JJJ > PO Box 1025 > Russellville, AR 72811 > > 479.968.7737 <(479)%20968-7737> Home > 479.857.7737 <(479)%20857-7737> Cell > > DMR K5CS (Local Repeater) - 310515, CC1, TS2 > DMR Arkansas - 3105 > > 4 > ___ > 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] No decode rc3 in FH on x64 Ubuntu 18.10
As stated by Joe Taylor, RC3 is NOT designed for DXP until the full release. It uses 77 bit and none of the DXP are using that mode since it is still in beta. VP6D specifically stated NOT to use RC3 and use v1.9.1 for this exact reason. On Tue, Oct 23, 2018 at 4:39 AM David Spoelstra wrote: > Ubuntu 18.10 > WSJT-X V2.0.0-rc3 > > In normal mode everything decodes ok. Switch to FH mode and there is no > decode even though waterfall shows strong signals. Switch back to normal > mode and everything decodes. > > Switch back to 1.9.1 and both modes decode ok. > > Switch back to rc3 and same decode problem in FH mode. > > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- George Cotton, WB5JJJ PO Box 1025 Russellville, AR 72811 479.968.7737 Home 479.857.7737 Cell DMR K5CS (Local Repeater) - 310515, CC1, TS2 DMR Arkansas - 3105 4 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X & JTSDK future?
*Foreword:* /Would like to know if the list maintainer wish we respond top or bottom.// //I'm an opensuse mailing list member and there we use to respond bottom the text of the OP, otherwise we went blamed!/ Il 22/10/18 17:31, Adam Schaible ha scritto: > Buonasera Marco, Ciao Adam! > > OpenSUSE Tumbleweed you say? Sure I can handle that. Here is a tested and > working script to build WSJT-X 2.0.0 RC3 on that distro. > > First, disclaimers/notes and then, the script: > > 1) I am NOT a WSJT-X developer, I am just a regular ham radio operator who > loves Linux. (I did meet K1JT once a few years ago at a speech he gave, it > was fun!) So if you run my script below and it breaks your computer don't > blame the wonderful WSJT-X devs, blame only me. By the way I have never tried > Tumbleweed before today and I am very impressed, enough so that I may even > use it to make a few contacts in WSJT-X :) Despite the word "Tumbleweed", the stability of this distro is amazing! I have a sort of reverential respect for all devs in general and in particular for K1JT, who was able to develop such a wonderful software as the WSJT-X > > 2) You do know there is an .rpm binary download of WSJT-X 2.0.0 RC3 available > right? So we don't actually "need" to do any of this except for "educational" > purposes. Yes I know this and I'm using it, I get latest rpm from the following repository: http://download.opensuse.org/repositories/home:/jfrede:/hamradio/openSUSE_Tumbleweed/ > > 3) The WSJT-X 2.0.0 RC3 build script below is tested and working on a 6 hours > old bare metal install of OpenSUSE Tumbleweed (KDE) on my Lenovo ThinkPad > T440. For purpose of comparison I also built it on OpenSUSE Leap 15 running > in a VM (AWS t2.micro), process was almost identical with just a few small > differences that keep it from being able to run as a non-interactive script > on Leap (repo update and devel-basis install both need command-line > interventions, and Leap compilers are g++-7/gfortran-7), but it still builds > fine. Given these positive results, without any further knowledge I can only > guess your previous build issues were caused by (as usual) missing > dependencies. > > GL es 73 de Adam KB3ZUV > > > #!/bin/bash > #-wsjtx2rc3-opensuseTW-build-script.sh--- > #--RUN ME WITH SUDO- > # > #first the obligatory OS patching > #since this is Tumbleweed we do full distro upgrade > zypper ref && zypper dup -y > #add user to dialout group allowing rig CAT control on next login > #(if you use VOX you don't actually need this) > usermod -a -G dialout $SUDO_USER > #install a whole bunch of dependencies to compile WSJT-X > #g++, git, and automake are all in devel_basis > zypper in -y --type pattern devel_basis && zypper in -y fftw3-devel \ > fftw3-threads-devel gcc-fortran cmake libqt5-qtbase-devel \ > libqt5-qtmultimedia-devel libqt5-qtconnectivity-devel \ > libqt5-qtserialport-devel libusb-1_0-devel asciidoc hamlib-devel \ > ruby2.5-rubygem-asciidoctor libpulse-devel libudev-devel > #create some directories for WSJT-X > sudo -u $SUDO_USER mkdir /home/$SUDO_USER/jtsource > sudo -u $SUDO_USER mkdir /home/$SUDO_USER/.wsjtx > #grab and unzip the source code from Princeton > wget --no-check-certificate \ > https://physics.princeton.edu/pulsar/k1jt/wsjtx-2.0.0-rc3.tgz > sudo -u $SUDO_USER tar -xzvf wsjtx-2.0.0-rc3.tgz \ > -C /home/$SUDO_USER/jtsource > cd /home/$SUDO_USER/jtsource/wsjtx-2.0.0-rc3 > #set build options > sudo -u $SUDO_USER cmake -D CMAKE_CXX_COMPILER="/usr/bin/g++-8" \ > -D CMAKE_Fortran_COMPILER="/usr/bin/gfortran-8" \ > -D CMAKE_INSTALL_PREFIX=/home/$SUDO_USER/.wsjtx . > #build WSJT-X on OpenSUSE > sudo -u $SUDO_USER cmake --build . --target install > #after build, to run wsjtx2 RC3 type: ~/.wsjtx/bin/wsjtx > #-EOF--- > Thanks a lot for your script, I will try it on my Linux box; I'll let you know the outcomes. 73! -- Marco Calistri PY1ZRJ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Italian translation of the DXpedition Mode User Guide?
I could do it if you send me guidelines. I'm Italian (former IK5BCU) Regards, PY1ZRJ Ottieni Outlook per Android On Tue, Oct 23, 2018 at 5:13 AM -0300, "DG2YCB, Uwe" wrote: Can someone translate the DXpedition Mode User Guide into Italian? Seems to be really necessary … 73 de Uwe, DG2YCB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] No decode rc3 in FH on x64 Ubuntu 18.10
On 23/10/2018 10:04, David Spoelstra wrote: Ubuntu 18.10 WSJT-X V2.0.0-rc3 In normal mode everything decodes ok. Switch to FH mode and there is no decode even though waterfall shows strong signals. Switch back to normal mode and everything decodes. Switch back to 1.9.1 and both modes decode ok. Switch back to rc3 and same decode problem in FH mode. David, have you read the WSJT-X v2.0 guide? It would seem not. https://physics.princeton.edu/pulsar/k1jt/Quick_Start_WSJT-X_2.0.pdf 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Recurring problem with WSJT-X v2.0.0-rc3
On 23/10/2018 01:42, RC wrote: Also another problem is LOTW fails with Rc3. Downgraded and now all works well. /**/ Rod, when testing beta quality WSJT-X releases you must at least make some effort to follow the discussions here where other testers are feeding back issues and the development team are providing workarounds or solutions. E.g. if you reviewed the last few days of posts here it would be clear to you how to address any errors with WSJT-X trying to download the LotW users data file from the ARRL. 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] No decode rc3 in FH on x64 Ubuntu 18.10
Ubuntu 18.10 WSJT-X V2.0.0-rc3 In normal mode everything decodes ok. Switch to FH mode and there is no decode even though waterfall shows strong signals. Switch back to normal mode and everything decodes. Switch back to 1.9.1 and both modes decode ok. Switch back to rc3 and same decode problem in FH mode. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Italian translation of the DXpedition Mode User Guide?
Can someone translate the DXpedition Mode User Guide into Italian? Seems to be really necessary . 73 de Uwe, DG2YCB ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
