Re: [wsjt-devel] Decoded Text Font
Interesting seems like *any* (not exhaustively tested) Bold font works... hadn't really tried any bold styling previously as I generally don't care for all bold text. Using Monospace 8 Bold now; I'll continue to use it until a more universal fix is coded for all styling. 73 Eric NO3M On 09/17/2014 02:25 PM, Joe Taylor wrote: > Once more, on the ugly font rendering in (Ubuntu 14.04) Linux, in the > decoded text windows. On my system, at least, the vertical alignment of > text is too low with "regular" fonts. I tried Courier, Courier New, and > Ubuntu Mono -- they all lose the descending tail on "Q". However, the > *Bold* versions of all three fonts look OK. > > Please try selecting, e.g., "Courier 11 Bold". > > -- 73, Joe, K1JT > > -- Slashdot TV. Video for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X 1.5-Dev r4966 Font Issues ( Linux)
If the issue originally reported last year was not directly addressed, then perhaps by selection of font, descender characters have been rendering correctly here. I have Monospace Bold 8 set as the Decoded text font and Sans Regular 8 as the program font. This is with 1.5.0-devel r 4964 on Archlinux. It has been a long time since I adjusted fonts, and therefore don't remember if this rendering problem was fixed by way of font selection or by some code revision along the way 73 Eric NO3M >> On 17/02/2015 00:53, Joe Taylor wrote: >> >> Hi Joe, >>> We dealt with this issue (at least I thought we did) about a year ago. >>> See the message to wsjt-devel dated February 15, 2014, from NO3M -- >>> copied below. >> -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Enhancement request
I ran into a similar situation with the following message: CQ NO3M DX to keep stateside callers from answering. I had assumed the "CQ" would have been picked up and TX Enable persist after each invocation. However, that was not the case. I saw other DX stations at the time using the same format of message and wonder how they are doing so without re-enabling the Enable TX each time; perhaps something JT-Alert does for them? Of course, JT-Alert is not able to run on *nix, so that's not an option here. It would be nice to be able to send a "recognized" CQ that will keep the locals from dampening a DX "run". 73 Eric NO3M On 03/05/2015 04:04 PM, Guy wrote: I am not a programmer at all, but I do follow this list and find what I read fascinating even though I don't understand it. I currently use the 1.3 release and it has a behaviour that I find annoying and I wonder if it has been addressed in either 1.4 or 1.5. When sending a custom CQ call, the 'enable tx' goes off after the first call and one has to continually press i carry on sending the custom CQ. I'm like it to stay on as it does for the standard CQ call. Thanks. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Enhancement request
Excellent... will try it later when 160 wakes up. Thanks for the info! 73 Eric NO3M On 03/05/2015 07:30 PM, Bill Somerville wrote: On 06/03/2015 00:09, Eric NO3M wrote: Hi Eric, I ran into a similar situation with the following message: CQ NO3M DX CQ DX NO3M is the correct form and is a standard message form, you can add your locator as well just like a normal CQ call. Note that this only works with "CQ" "CQ DX" "QRZ" or "DE" on the front of the message. to keep stateside callers from answering. I had assumed the "CQ" would have been picked up and TX Enable persist after each invocation. However, that was not the case. I saw other DX stations at the time using the same format of message and wonder how they are doing so without re-enabling the Enable TX each time; perhaps something JT-Alert does for them? Of course, JT-Alert is not able to run on *nix, so that's not an option here. It would be nice to be able to send a "recognized" CQ that will keep the locals from dampening a DX "run". 73 Eric NO3M 73 Bill G4WJS. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSPR mode in WSJT-X v1.6.1
Joe I have been running WSJT-X 1.6.x in WSPR mode on 630M (WG2XJM) for the past couple of nights, and seems to work fine, nothing particularly unexpected, just not many guys to decode as most are off the air due to storms in the mid-west, etc. I did capture WH2XGP (W7IUV) in WA last night. I also had the software monitoring 20M WSPR during the day while an instance of WSPR4 was running, both processing audio from the same soundcard. The C decoder seemed to decode more stations on average than the WSPR4 decoder, with only a few not decoded that WSPR4 picked up. I did notice some odd SNR results though. During a particular cycle, all station SNRs in WSJT-X would be consistently 9-11 dB higher than WSPR4, but the following cycles be within a dB or so. Seems this behavior was near the first full cycle after startup or thereabouts. I don't recall if any later cycles produced that same abnormal SNRs. 73 Eric NO3M / WG2XJM On 05/11/2015 04:20 PM, Joe Taylor wrote: > Hi all, > > Just a brief note to let you know that WSPR mode is now alive and well > in WSJT-X v1.6.1. > > If you have been building recent experimental versions of WSJT-X for > yourself, please give WSPR mode a try. It does not (yet) support "band > hopping" or a few other advanced features of standard WSPR or WSPR-X, > but for normal single-band use it is essentially complete. Some > feedback on its use will be useful and appreciated. > > -- 73, Joe, K1JT > > -- > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FW: 1.6.1 transmit start time
Notice when the program finally goes into transmit (clicking Enable TX), it never goes back to Monitor unless Halt Tx is clicked. If the program doesn't happen to go into transmit when Enable Tx is clicked, Tx Next is broke, just stays highlighted indefinitely and never goes into transmit. 73 Eric NO3M On 05/24/2015 11:14 AM, Guy G4DWV/4X1LT wrote: > I hope this gets fixed, very annoying as not working at present. > > > -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] 1.6.1 transmit start time
Tried using WSJT-X 1.6.1 devel for WSPR2 on 630M last night... clicking Enable TX shot off one TX cycle but the program never transmitted again afterward. Tx Pct was 20%. 73 Eric NO3M -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSPR2 TX problem
Appears the problem is stemming from mainwindow.cpp, start line +1849
(MainWindow::guiUpdate()):
if((m_auto and (m_pctx>0) and (m_txNext or ((m_nrx<=0) and
(m_ntr!=-1 or ((m_auto and (m_pctx==100 {
some condition is failing to satisfy the above, so a TX cycle is never
entered. m_nrx is continuously decrementing (Status bar showing
"Receiving -2586" after a while). Since:
m_auto and (m_pctx==100)
look to be grouped exclusive of the rest of the conditional, perhaps
m_auto is perpetually false, because m_pctx has been set to 100 in my
running instance and a TX cycle still never fires off. Haven't traced
out all the instances of m_auto to see where it is being set true/false yet.
BTW, this is with the latest SVN on the main dev branch since the _exp
branch was merged per Bills' post.
73 Eric NO3M
--
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSPR2 TX problem
Ran a test now with WSJT-X.ini removed prior to invoking the program still not transmitting after 4 RX cycles and TX Pct = 50% Configuration should be rather standard. Only set the callsign and grid, rest is default per having removed WSJT-X.ini: Call: WG2XJM (Part 5 exp call) Grid: EN91 Band: 630M Mode: WSPR-2 Tx Pct = 50% (even 100% was not triggering TX) Enable TX = true (GUI button highlighted Red) Tx = 1500 Hz Band Hopping = false Program info: Relative URL: ^/branches/wsjtx Revision: 5427 Still running and the Status indicates "Receiving -278" now. Eric NO3M On 05/27/2015 05:15 PM, Joe Taylor wrote: > Hi Eric, > > I have not answered your queries about failure to transmit in WSPR mode > because so far I have not been able to reproduce the problem. > > As reported here a number of times, I (and a number of others) have been > happily WSPRing with WSJT-X v1.6 for about two weeks. I've observed no > reluctance of the program to transmit. > > Can you provide details on exactly what you are doing, and how you are > configured? > -- Joe, K1JT > > -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSPR2 TX problem
Thanks for the info wrt band hopping; glad you were at least able to reproduce/confirm the issue. I'll try the temp workaround when going QRV on 630M later. Yes, there are a number of stations currently running WSPR-15. In fact, a station in AK (WE2XPQ / KL7L) has been running it for the past several nights and there are also various stations in EU that have run it recently. It would be a welcomed addition to WSJT-X - WSPR (or considering WSJT-X is absorbing WSPR-X, a retained mode). Eric NO3M / WG2XJM On 05/27/2015 08:28 PM, Joe Taylor wrote: > Hi Eric (NO3M) and all, > > Another question for you, regarding WSPR on the MF and LF bands. Is > there currently much use of WSPR-15? > > -- Joe, K1JT > > -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSPR2 TX problem
Enabling band hopping gets Tx rolling, but as someone pointed out in another message to the list, even with a low percentage Tx probability (in my case 20% tested), up to 4 consecutive Tx cycles before I killed it. On 05/27/2015 08:20 PM, Joe Taylor wrote: > Hi Eric, > > It seems that my implementation of band-hopping has caused a side effect > of improper behavior when band-hopping is NOT selected. > > As a temporary work-around, please try checking the "Band Hopping" box. >On Tab 4, you enter "630" (your one desired band) alone in the > Sunrise, Day, Sunset, and Night fields. > > -- 73, Joe, K1JT > > -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wspr hopping
Testing this evening with Tx Pct 50%, band hopping = false, got 2 consecutive transmissions, but nothing further afterward. After switching to Band hopping = true, Tx Pct still at 50%, and only "630" in the Sunrise, Day, et.al., fields, Tx was triggered once and no further after at least 10 minutes. 73 Eric NO3M / WG2XJM On 05/31/2015 04:25 PM, Steven Franke wrote: >> What are you using for the grayline bands and duration? > Joe - > Right now I have it set up as follows: > Sunrise: 80 40 30 20 17 15 12 10 > Day: 30 20 17 15 12 10 > Sunset: 40 30 20 17 15 10 > Night: 160 80 40 30 20 > Gray Time: 120 > > On a couple of occasions I’ve felt like the grayline duration was not working > quite right - but I haven’t tried to sort it out yet. > > Re the hopping schedule - it still needs sanity checks for cases where the > user requests an impossible set of parameters (e.g. TX percentage > 67% > doesn’t make sense if max # of consecutive transmissions is 2…). It might be > simpler to give the user just a few “sane” options for max # of transmissions > and overal TX percentage… > > Steve k9an > > > > -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wspr hopping
Bill OK, only following suggestion from Joe per a previous message: > As a temporary work-around, please try checking the "Band Hopping" box. >On Tab 4, you enter "630" (your one desired band) alone in the > Sunrise, Day, Sunset, and Night fields. I never use band-hopping in normal operation, only run WSPR on 630M, so unfamiliar w/ the band-hopping caveats (yes, RTFM... ). Think I'll just step back and let the guys hammer out the TX decision issues. 73 Eric NO3M On 06/01/2015 05:45 AM, Bill Somerville wrote: > On 01/06/2015 04:34, Eric NO3M wrote: > > Hi Eric, >> Testing this evening with Tx Pct 50%, band hopping = false, got 2 >> consecutive transmissions, but nothing further afterward. After >> switching to Band hopping = true, Tx Pct still at 50%, and only "630" in >> the Sunrise, Day, et.al., fields, Tx was triggered once and no further >> after at least 10 minutes. > Currently WSJT-X only supports coordinated band hopping as specified in > the WSPR manual: > > http://physics.princeton.edu/pulsar/K1JT/doc/wspr/wspr-main.html#BANDHOPPING > > so only the 10 bands that are globally coordinated are candidates for > band hopping. >> 73 Eric NO3M / WG2XJM > 73 > Bill > G4WJS. >> -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wspr hopping
This was sent before other replies by Joe, Steven, et.al. My Emails to the list seem to be experiencing gross delays. At any rate, testing with r5485 now and seems to meet the Tx Pct criteria (non band-hopping), though there are a several cases with consecutive Tx cycles. I usually re-compile against the latest SVN updates before firing up each night. The previous report on behavior was using r5482 if I recall. In reply to Joe's response about algorithm's, it seems that the Tx decision making in WSPR4 works quite well. That's what I have been running exclusively until WSPR was added to WSJT-X / exp. I don't recall having ever seen consecutive TX cycles using WSPR4 (not that it probably never happened). However, I don't know whether or not it conforms to the set Tx Pct statistically over time as tightly as WSJT-X/wspr seems to be doing now. Consecutive TX cycles are probably not a big deal, but not having consecutive cycles made it easier on the linear :) It also seems that WSJT-X/wspr is acting in a more random manner, which in the big picture is probably more desirable. 73 Eric NO3M / WG2XJM On 06/01/2015 01:08 PM, Eric NO3M wrote: > Bill > > OK, only following suggestion from Joe per a previous message: > >> As a temporary work-around, please try checking the "Band Hopping" box. >> On Tab 4, you enter "630" (your one desired band) alone in the >> Sunrise, Day, Sunset, and Night fields. > I never use band-hopping in normal operation, only run WSPR on 630M, so > unfamiliar w/ the band-hopping caveats (yes, RTFM... ). > > Think I'll just step back and let the guys hammer out the TX decision > issues. > > 73 Eric NO3M > > -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] New WSPR scheduler
Having problems with WSPR2 TX here. WSJTX 1.6.0-devel r5578 (same problems with r5567 also before doing SVN update/re-compile) Band: 630m Tx 1575 Hz Tx Pct 33% Upload Spots = true Band Hopping = false As soon as I click Tx Enable, regardless of how far into a 2-minute period it is clicked, WSJTX immediately starts transmitting the WSPR message. After the current 2-minute period is over (odd-minute:52), audio ceases but the status on the lower left of the main window remains "Tx: WG2XJM EN91 37" indefinitely and the program never goes back to "Monitor" nor produces any further real transmissions (ie. audio). 73 Eric NO3M -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] New WSPR scheduler
An additional note... Clicking "Tx Enable" from an off (false) state will start a WSPR2 transmission at any point in time during the current 2-minute cycle (per status bar "Tx: ."), but only audio is produced if the Tx Enable is clicked prior to ODD_MIN:30 (ie. 30 seconds into the odd minute). The program even goes into transmission (again, per status bar message in lower left), but with no audio, between odd:52 and odd:59 and stays stuck in limbo forever (never goes back to Monitor nor produces a real transmission)!! Again, just tested w/ r5578 73 Eric NO3M On 06/10/2015 06:49 PM, Eric NO3M wrote: > Having problems with WSPR2 TX here. > > WSJTX 1.6.0-devel r5578 (same problems with r5567 also before doing SVN > update/re-compile) > Band: 630m > Tx 1575 Hz > Tx Pct 33% > Upload Spots = true > Band Hopping = false > > As soon as I click Tx Enable, regardless of how far into a 2-minute > period it is clicked, WSJTX immediately starts transmitting the WSPR > message. After the current 2-minute period is over (odd-minute:52), > audio ceases but the status on the lower left of the main window remains > "Tx: WG2XJM EN91 37" indefinitely and the program never goes back to > "Monitor" nor produces any further real transmissions (ie. audio). > -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] New WSPR scheduler
Joe, Steve, et.al. Yes, I was engaging Tune prior to clicking "Tx Enable", generally to make sure the match on my 630M antenna is alright (very narrow bandwidth) and that output power is correct for 5W EIRP. It is such a habit that apparently I do it everytime I start WSJT-X! I restarted WSJT-X and did NOT engage Tune prior to clicking "Tx Enable". Behavior appears to be normal, a TX cycle with audio fired off on the next even minute and returned to Monitor on the following 2-minute period, after a couple cycles of RX, another TX cycle started (with tones), then back to RX. Exactly the expected behavior. 73 Eric On 06/10/2015 09:31 PM, Joe Taylor wrote: > (Fair warning: I may not be fully awake ...) > > I have now reproduced essentially what Eric reported by doing the > following steps: > > 1. Start WSJT-X in WSPR mode > 2. Run a short Tune cycle (click Tune twice) > 3. Click Tx Enable > > If Step 2 is omitted, I do NOT see what Eric reported. The program > behaves as expected. > > Eric, are you always running a Tune cycle? Please try it without using > Tune. > > We'll figure out what's going on... > > -- Joe, K1JT > > > On 6/10/2015 9:10 PM, Joe Taylor wrote: >> Hi Eric, >> >> On 6/10/2015 6:49 PM, Eric NO3M wrote: >>> Having problems with WSPR2 TX here. >>> >>> WSJTX 1.6.0-devel r5578 (same problems with r5567 also before doing SVN >>> update/re-compile) >>> Band: 630m >>> Tx 1575 Hz >>> Tx Pct 33% >>> Upload Spots = true >>> Band Hopping = false >>> >>> As soon as I click Tx Enable, regardless of how far into a 2-minute >>> period it is clicked, WSJTX immediately starts transmitting the WSPR >>> message. >> Try as I will, I cannot reproduce the behavior you describe. >> >> When I start WSJT-X in WSPR-2 mode and click Tx Enable, the program >> politely waits for the start of an even-numbered minute. It then begins >> a normal cycle. This cycle ends at the normally expected time, 54 >> seconds into an odd-numbered minute. >> >> If I start the program, toggle Tx Next to ON, and then click Tx Enable, >> the behavior is the same except that the first full 2-minute sequence is >> Tx rather than Rx. >> >> I am presently baffled by your report. >> >> -- 73, Joe, K1JT >> >> -- >> ___ >> 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] wspr two-pass decoder status and .c2 file problem
Interesting results with with "decoder #5" on 20M this evening: 2015-06-30 22:52 PA0MLC 14.097121 -4 0 JO31aw 5 NO3M EN91 6335 297 2015-06-30 22:52 G6KIZ 14.097121 -16 4 JO02fu 0.2 NO3M EN91 5949 293 2015-07-01 01:16 HB9CZF 14.097071 -1 4 JN47ch 1 NO3M EN91 6719 301 2015-07-01 01:16 KB1MVX 14.097071 -12 -1 EM73 1 NO3M EN91 957 20 In each case, same offset and 11-12 dB SNR difference... slick. There may have been others, but these are ones I caught. Of course, numerous instances of only a Hz or three separation. 73 Eric NO3M (WG2XJM 630M/2200M) On 06/30/2015 06:18 PM, Steven Franke wrote: > For those testing wspr mode in wsjt-x ver 1.6, I’ve just committed r5644 > which makes decoder #5 from Joe’s table, below, the default decoder in wsjt-x > ver 1.6. It is no longer necessary to separately compile wsprd_exp to get the > benefits of two-pass decoding. > Steve k9an > > -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] TX Next cutoff time
Re: WSPR mode "Tx Next" does not seem to trigger a TX period on the upcoming 2-min cycle when clicked "close" to the 2-min crossover. I cannot answer exactly when the cutoff point (ie. time to next 2-min crossover) seems to happen, as this has only been a casual observation while preparing for a transmit session and wanting to get a quick first TX period off. Is there an intentional cutoff or is this a bug? 73 Eric NO3M / WG2XJM -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] QT 5.5 compile error
I recently upgraded to QT 5.5.0 from 5.4.2 (distro Archlinux). After the Qt upgrade, I am getting the following compilation error: wsjtx-build-err.log: Path: /home/eric/src-build/wsjtx-superbuild/build/wsjtx/wsjtx-prefix/src/wsjtx Working Copy Root Path: /home/eric/src-build/wsjtx-superbuild/build/wsjtx/wsjtx-prefix/src/wsjtx URL: svn://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx Relative URL: ^/branches/wsjtx Repository Root: svn://svn.code.sf.net/p/wsjt/wsjt Repository UUID: ab8295b8-cf94-4d9e-aec4-7959e3be5d79 Revision: 5723 Node Kind: directory Schedule: normal Last Changed Author: k9an Last Changed Rev: 5723 Last Changed Date: 2015-07-26 10:09:25 -0400 (Sun, 26 Jul 2015) In file included from /home/eric/src-build/wsjtx-superbuild/build/wsjtx/wsjtx-prefix/src/wsjtx/WFPalette.cpp:1:0: /home/eric/src-build/wsjtx-superbuild/build/wsjtx/wsjtx-prefix/src/wsjtx/WFPalette.hpp:53:40: error: expected constructor, destructor, or type conversion before ‘;’ token Q_DECLARE_METATYPE (WFPalette::Colours); ^ make[5]: *** [CMakeFiles/wsjt_qt.dir/WFPalette.cpp.o] Error 1 make[4]: *** [CMakeFiles/wsjt_qt.dir/all] Error 2 make[3]: *** [all] Error 2 -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X: Qt 5.5
Bill v 1.6.0-devel r5727 compiles fine w/ Qt 5.5 here. Thanks for also addressing the RX signal meter rendering issue. 73 Eric NO3M / WG2XJM On 07/27/2015 02:16 PM, Bill Somerville wrote: > Hi All, > > I have updated the sources to work with Qt v5.5. The changes were > trivial but I would appreciate any reports of other issues from anyone > building with Qt 5.5 on any platform. > > I will start working through my production VMs upgrading to Qt 5.5 but > that will take a while. > > 73 > Bill > G4WJS. > > -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] TX Next cutoff time
Joe After your update to my original post on the mailing list, I had run through a set of tests with a freshly started instance of WSJT-X, but also could not reproduce the problem, each invocation of 'Tx Next' triggered a transmit cycle on the upcoming 2-min period. However, I have run into the issue several times since then, including this evening when queuing up on 630M. I'll have to perform more tests to try and isolate what conditions may be causing this problem, but it definitely exists. When I clicked 'Tx Enable' followed by 'Tx Next' this evening, around odd-min:30s, the upcoming 2-min period was an RX cycle and the following a TX cycle. 73 Eric NO3M On 07/23/2015 11:38 AM, Joe Taylor wrote: > Hi Eric, > > There is no intentional cutoff time for requesting "Tx Next". > > I have not been able to confirm that activating "Tx Next" close to the > end of a 2-minute period fails to trigger a TX period on the next > 2-minute cycle. I tried t=55s, t=57s, and t=59s in the "odd" minute of > reception, and in all cases a transmission started at t=00s. > > For these tests I set TxPct=1%, set "Monitor" and "Enable TX" active. I > then clicked "Tx Next" at the stated times, right up to t=59s. > > (I did not check to see what happens if decoding is still underway past > t=00s. Should be OK, but? ...) > > -- 73, Joe, K1JT > > On 7/14/2015 10:57 PM, Eric NO3M wrote: >> Re: WSPR mode >> >> "Tx Next" does not seem to trigger a TX period on the upcoming 2-min >> cycle when clicked "close" to the 2-min crossover. I cannot answer >> exactly when the cutoff point (ie. time to next 2-min crossover) seems >> to happen, as this has only been a casual observation while preparing >> for a transmit session and wanting to get a quick first TX period off. >> Is there an intentional cutoff or is this a bug? >> >> 73 Eric NO3M / WG2XJM >> >> >> -- >> Don't Limit Your Business. Reach for the Cloud. >> GigeNET's Cloud Solutions provide you with the tools and support that >> you need to offload your IT needs and focus on growing your business. >> Configured For All Businesses. Start Your Cloud Today. >> https://www.gigenetcloud.com/ >> ___ >> 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
[wsjt-devel] JT9 decode time
Running WSJT-X 1.7.0-devel r6133 In most cases, initial decodes are not displayed until :57, the majority between :58-:59, and even some as late as :12 into what should be my transmit cycle. This is really wreaking havoc on the ability to have an actual QSO. Settings Mode: JT9 only Decode: Normal Settings->Advanced Random erasure pattern = 6 (default) Two pass decoding = OFF All experience-based decoding = OFF Aggressive decoding = 0 PC is Intel Core2 Quad 2.5 GHz, 8GB RAM. An insight appreciated. 73 Eric NO3M -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] JT9 decode time
Strange... after restarting the app, decodes seem to be coming in faster. Will run a while and see... 73 Eric NO3M On 11/27/2015 03:34 PM, Eric NO3M wrote: > Running WSJT-X 1.7.0-devel r6133 > > In most cases, initial decodes are not displayed until :57, the majority > between :58-:59, and even some as late as :12 into what should be my > transmit cycle. This is really wreaking havoc on the ability to have an > actual QSO. > > Settings > > Mode: JT9 only > Decode: Normal > Settings->Advanced > Random erasure pattern = 6 (default) > Two pass decoding = OFF > All experience-based decoding = OFF > Aggressive decoding = 0 > > PC is Intel Core2 Quad 2.5 GHz, 8GB RAM. > > An insight appreciated. > > 73 Eric NO3M > -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X lock file
What's the default location / filename of the WSJT-X lock file? Found it in the past, but no luck at the moment. 73 Eric NO3M -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X lock file
Program was locked up and needed forcefully killed. Restarting it brought up the "lock file" warning window, but answering the prompt to remove the lock file apparently did not do so. 73 Eric NO3M On 01/07/2016 07:24 PM, Bill Somerville wrote: > Hi Eric, it's %TEMP%\WSJT-X.lock on Windows /tmp/WSJT-X.lock on Linux > and $TMPDIR/WSJT-X.lock on OS X, why do you need to find it? 73 Bill > G4WJS. -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSPR reporting bug / multiple spots
Not sure if this has been brought up previously... Only the first of several WSPR decodes are being reported, see data below: WSJT-X v1.7.0-devel r6447: 2304 -2 -0.20.4756100 WG2XIQEM12 37 1122 23047 -1.00.4757220 WG2XKAFN33 30386 2306 -1 -0.90.4756390 WH2XZOEM85 33455 2306 -14 -0.10.4757371 WD2XSH/15 33 2308 -1 -0.30.4756100 WG2XIQEM12 37 1122 2310 -16 -0.20.4757380 EM34RT 33825 2312 -0 -0.20.4756100 WG2XIQEM12 37 1122 23126 -0.80.4756390 WH2XZOEM85 33455 23161 -0.30.4756100 WG2XIQEM12 37 1122 2316 10 -1.00.4757220 WG2XKAFN33 30386 2316 -18 -0.20.4757370 WD2XSH/15 33 wsprnet.org: 2016-02-01 23:16 WG2XIQ 0.475610 +1 0 EM12mp 5 WG2XJM EN91wr 1796 51 2016-02-01 23:16 WG2XKA 0.475722 +10 0 FN33lq 1 WG2XJM EN91wr 618 252 2016-02-01 23:12 WG2XIQ 0.475610 0 0 EM12mp 5 WG2XJM EN91wr 1796 51 2016-02-01 23:10 WD2XSH/15 0.475738 -16 0 EM34rt 2 WG2XJM EN91wr 1327 51 2016-02-01 23:08 WG2XIQ 0.475610 -1 0 EM12mp 5 WG2XJM EN91wr 1796 51 2016-02-01 23:06 WH2XZO 0.475639 -1 0 EM85wb 2 WG2XJM EN91wr 761 13 2016-02-01 23:04 WG2XIQ 0.475610 -2 0 EM12mp 5 WG2XJM EN91wr 1796 51 Sniffing the traffic sent to wsprnet.org using tcpdump confirms that only one spot is sent during a cycle (or in the case of 2316z, two made it out). 73 Eric NO3M -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSPR reporting bug / multiple spots
Just a heads up. Not sure how reproduce-able it will be; last hour or so multiple spots are going through fine. I originally thought it may have been an issue on wsprnet's side due to all the recent problems there, but decided to run tcpdump and saw that not all the spots where getting sent. Thanks. 73 Eric NO3M On 02/01/2016 07:26 PM, Bill Somerville wrote: > > Hi Eric, > > thanks for the report. I will look into it tomorrow when I can get some > time in the shack. There have been some minor changes to the WSPR > spotting code. > > 73 > Bill > G4WJS. > > -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT To Do list
Not sure what changes where made to the audio area of WSJT-X in the recent past, but it resolved a previous issue of being unable to transmit. Prior to whatever changes were made, I would get buffer underruns and segfaults. I seem to remember having seen some reference to things having been moved away from Portaudio to QT-related audio toolkit? I wonder if the same could be slated for WSPR-X? I am able to use WSPR-2.12 in WINE, but much prefer using WSPR-X with the realtime waterfall, etc. WSPR-X exhibits the same buffer underruns and segfaulting as WSJT-X did previously. 73 Eric NO3M -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] r3958 compile error
gfortran -O2 -fbounds-check -Wall -Wno-conversion -fno-second-underscore -fPIE -DUNIX -c decoder.f90 decoder.f90:5.6: use prog_args 1 Fatal Error: Can't open module file 'prog_args.mod' for reading at (1): No such file or directory Makefile.linux:21: recipe for target 'decoder.o' failed make: *** [decoder.o] Error 1 OS: Archlinux 64-bit Eric NO3M -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] r3958 compile error
Built, installed, running. Missed the whole Cmake thread. Thanks. On 03/29/2014 03:40 PM, Joe Taylor wrote: > It's not clear what the purpose of your message is. Are you asking for > help? Are you trying to build WSJT-X for Linux without using CMake? If > so, why? > > Are you trying to tell us that the present Makefile is insufficient to > build the program? If so, thanks -- we know that. It's not currently > our preferred build method. > > O -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] r3958 compile error
=== Part of default distro install: core/glibc 2.19-3 provides: libc.so.6 libm.so.6 core/gcc-libs 4.8.2-8 provides: libgcc_s.so.1 libquadmath.so.0 libgfortran.so.3 core/gcc 4.8.2-8 === Additional packages: core/gcc-fortran 4.8.2-8 extra/cmake 2.8.12.2-2 extra/qt5-base 5.2.1-1 extra/qt5-multimedia 5.2.1-1 extra/fftw 3.3.3-2 extra/libpulse 5.0-1 aur/hamlib 1.2.15.3-1 extra/pulseaudio 5.0-1 extra/subversion 1.8.8-1 === One line package install: pacman -S gcc-fortran cmake qt5-base qt5-multimedia fftw libpulse pulseaudio subversion Hamlib must be acquired via AUR (https://aur.archlinux.org/packages/hamlib/) and package unarchived, built, installed per standard AUR procedure: https://wiki.archlinux.org/index.php/Arch_User_Repository Alternatively, if 'yaourt' is installed, then hamlib can be installed with: yaourt -S hamlib Hopefully I didn't miss anything. 73 Eric NO3M On 03/29/2014 08:57 PM, Greg Beam wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Eric, > > Glad you have it sorted :-) > > I'm compiling a list of pgk dependencies for popular *Nix distro's, > and Arch has a big ?? beside it at the moment. > > Could you send us a list of packages you had to install in order for > things to build properly? > > I realize Arch and Gentoo are variable from the base, but a short list > of critical deps would be good if you have some spare time. > > Thanks > > 73's > Greg, KI7MT > > > > -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJTX 1.4.0
Greg Add to Archlinux list: community/asciidoc 73 Eric NO3M On 04/20/2014 10:14 PM, KI7MT wrote: Hi Chuck, Bill, G4WJS, sent out instructions (to wsjt-devel list) on how to compile Hamlib 3, then build WSJT-X using CMake just a few days ago. Cmake doesn't much care that your Linux is Fedora, and the other guys is using Mint or whatever, only that the dependencies are met, FFTW, Hamlib3, pulaudio, Qt5. i386 stuff for kvasd, etc, etc. I built WSJT-X on Fedora-20 about 3 weeks or so ago, so I know it works, but I don't have the package list on hand to give you. I will do in the next few days. The Package Matrix in the SVN dev-guide is pretty accurate. You could check out docs, build devg and go at it that way if you like. I'm sorry I don't have the FD-20 list handy, but I will in a few days. 73's Greg, KI7MT -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSJT-X Building from source on Ubuntu 14.04 LTS.
Greg Just for reference as you're looking into asciidoc package deps on other distros, as far as the Archlinux packaging, dblatex is optional. Per the asciidoc package info: Repository : community Name : asciidoc Version: 8.6.9-1 Description: Text document format for short documents, articles, books and UNIX man pages. Architecture : any URL: http://www.methods.co.nz/asciidoc/ Licenses : GPL Groups : None Provides : None Depends On : python2 libxslt docbook-xsl Optional Deps : lilypond: music-filter imagemagick: music-filter (used in conjunction with lilypond) source-highlight: source-highlight-filter dblatex: pdf generation fop: alternative pdf generation lynx: text generation w3m: text generation (alternative to lynx) Conflicts With : None Replaces : None 73 Eric NO3M On 04/20/2014 11:56 PM, KI7MT wrote: > Hi David, > > Be careful when installing Asciidoc --with-recommends, as this pulls in > dblatex, which on it's own is not an issue, but it depends on LaTex, > which is huge!. > > I'd have to go look and if a2x requires LaTex for Man pages, if so, we > should definitely look at alternative solutions for Man Page generation. > > 73's > Greg, KI7MT > > > -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Remote Control
Peter Perhaps another mode worth trying is WSQ by ZL1BPU: http://www.qsl.net/zl1bpu/SOFT/WSQ.htm It is intended for LF/MF, so doppler effects on higher frequencies may present issues. I've tested this mode on 630m with copy still good down to -24 to -25 dB. 73 Eric NO3M On 04/23/2014 10:10 AM, Peter R. Burri wrote: Hi Edson Thanks for your answer. Yes I have already considered and even tested other digimodes (I am into digimodes for years and do nearly nothing else in ham radio, hi hi). I agree with you in that Olivia is by far the strongest and most reliable **ragchew mode** available today working with relatively weak signals. Therefore Olivia is my favourite digimode for most applications. Nevertheless when it comes to **really** weak signals, longest distances or low power equipnent/low performance antennas it lies behind JT65 by magnitudes. I have tested both modes with just a few minutes difference in time last week between HB and ZL and JT65 worked with 100% decoding while Oliva decoded only a fragment of text from time to time resulting in unreadable information. The station in ZL (a colleague of mine) engaged a simple 5 meter wire (14 MHz) held up by a fishing rod and a KX3 running on internal batteries outdoors near Auckland. We used the protocol mentioned for message transmission (every fragment confirmed by an RRR with repetition if the RRR could not be received back). Perfect copy down to 100 mW of power with just a few repetitions. I guess we won't be able find another mode (except QRSS which is somewhat uncomfortable) performing this way down to S/N of -23 dB or less. So (at least to me) it seems worth some effort to realize something like an "SMS-Sender" for hams with an underlying JT65 transport layer even if the transmission of such an "SMS" takes half an hour (I can lean back and eat a donut while transmission is in progress J)... And going there (to ZL) would take a lot more of time and money J. 73, Peter HB9JAQ -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] WSPR Source Tree Updates - (builds, docs, hamlib, fmt, wspr0 etc)
Greg
The default 600m freq. should be 0.474200. There are a few experimental
stations active down there almost every night, including myself.
73 Eric NO3M (WG2XJM experimental license)
On 05/02/2014 09:31 AM, ki7mt wrote:
Hello All,
I started cleaning up the WSPR source tree yesterday. The following is
a summary things I've done, and things in need of assistance. If
anyone is looking for things "To-Do", there is plenty here:
**Overall Status**
- WSPR-4.0:. Builds and Runs nicely (Win32 & Linux)
- FMT:.. Builds and Runs nicely (Win32 & LInux)
- WSPR0:. Fails To Build
- WSPR_NoGui.py: .. Fails To Build
**Created Folders**
- wspr/archive (for obsolete items, on hold, unknown status etc)
- wspr/hamlib (for all the Win32/64 dlls / exe and rig list files)
- wspr/doc/{man1} (for docs, and manpages)
- hamlib_rig_numbers needs to stay in /wspr for (*nix), else you wont
get your pick list
- Added README files to the sub-folders, need one fer the main /wspr
folder for build instruction.
**Updated**
- Makefile.in, configure.ac ( for Python3 and F2PY3 )
- Updated WSPR.iss for new hamlib location wspr/hamlib
- You should run autoconf before ./configure
- In configure, list out Python and F2PY, for example (x86_64 Ubuntu
type system):
cd src/wspr
autoconf &&
./configure --with-portaudio-lib-dir=/usr/lib/x86_64-linux-gnu \
--with-portaudio-include-dir=/usr/include \
PYTHON=/usr/bin/python3 \
F2PY=/usr/local/bin/f2py3
**Things Needing Attention**
** Lib File(s): (*.f90, fftw3, portaudio ) Needs verification
- Need to check libwspr.a include files against WSJT and other apps
for latest versions
** Autotools Build Ssystem
- The autotools build chain (Makefile.am, configure.ac *.m4) needs to
be updated
** WSPR0
- Fails to build, PA_undefined errors and a few others
- Looks like a useful tool, just needs a bit of attention
- Maybe we move this to it's own sub-folder && own Makefile.in
** WSPR_NOGUI_PY
- Fails to build, needs updating to Python3 syntax (lots of them)
- I tested it after fixing Syntax, it's not decoding at all.
- Maybe we move this to it's own sub-folder Makefile.in ?
**Documentation* - Lots of To-Do Here*
WSPR_4.0_User_Guide.txt (needs updating / converting to AsciiDoc Format)
WSPR0_Instructions.txt (needs verifying and coversion to AsciiDoc format)
WSPR_4.0_User.docx (needs verifying and/or moved to wspr/archive )
WSPR_Announcement.TXT (Needs added to WSPR Doc Tree and Preserve
Announcement)
WSPR_Howto_MacOSX (needs updating and addec to WSPR AsciiDoc Files)
WSPR_nogui.txt (needs updaing, converted to AsciiDoc formation and
added to WSPR docs)
WSPR_QuickStart.txt (Needs updating, converted to AsciiDoc Format and
added to WSPR docs).
As docs are converted over to AsciiDoc format, we can probably remove
them, or stick them in /wspr/archive until we're sure nobody is using
them.
That's all fer Now,
73's
Greg, KI7MT
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Tx Audio Glitches (NOT)
I can confirm that that change resolved TX audio issues I had with WSJT-X in Linux (Arch). Works perfectly well now. WSPR 4.0 is also running nicely natively, hadn't tried it before yesterday, but was using WSPR 2.12 under Wine prior. My hope is that WSPR-X will also benefit from a similar audio migration, would love to try some WSPR-15 on 630M. However, it currently suffers from the same audio buffer underruns that I experienced with WSJT-X originally. Either way, very happy to have WSPR 4.0 and WSJT-X running nicely! Thanks Bill and team. As an off-topic inquiry to Joe. Have you ever considered implementing some kind of diversity reception decoding? Stereo diversity is often used on the lowbands (80m and below) to enhance readability, but as far as I know, there are no digital programs that implement the ability to utilize stereo diversity channels. Based on my own experience using it on 80, 160, 600m, it can really make a difference in CW and SSB, so I imagine there could be some benefit for digital reception. Just throwing an idea in the jar. 73 Eric NO3M On 05/03/2014 03:11 PM, Joe Taylor wrote: > Hi all, > > I'm happy to report that I haven't heard a Tx audio glitch from WSJT-X > for some time. Bill probably knows exactly when (and why, at least > approximately) this stopped happening. As far as I can see, the Tx > audio is now as rock-solid as it is in WSJT and WSPR -- and as it was in > WSJT-X before we switched from PortAudio to QtMultiMedia. > > Well done, Bill! > > -- Joe, K1JT > > -- "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Decoded Text Font
What font are folks using to prevent the "Q" tail from being cut off in the decoded text window? Have tried numerous, but none seem to resolve the problem, and more often than not, the font doesn't get updated in the decoded text area, only the field headings. Thanks for any insight. 73 Eric NO3M -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce. Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Decoded Text Font
Yes, 1.4.0 r 4314 On 09/17/2014 06:01 AM, Bill Somerville wrote: > > Are you using v1.4 with the new font chooser for the decoded text in the > Settings? > -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Decoded Text Font
Window geometry doesn't have any effect. Screenshot here: http://no3m.net/uploads/images/wsjt-x.png On 09/17/2014 05:29 AM, Murray Curtis wrote: > Hi Eric > > Is the "Q" partially there, just not completely rendered, or is it > missing (truncated) completely? > What happens if you make the window wider - does that reveal the missing > parts? > It would be very helpful if you could post a screen shot of the effect - > to my email is OK if there is no where online to post it. > > I don't have a dev system at the moment (long story...) but should have > in the next few days and I'll take a look at this. > > The font for the text windows is fixed both in pitch and user > selection. That may get addressed in the future too. > > Cheers > Murray VK3ACF > > > -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Decoded Text Font
Don't have MS Shell Dlg on this box (Archlinux). Seems even Sans 8pt still has truncated 'Q' tails after trying more fonts. On 09/16/2014 01:15 PM, Michael Black wrote: > I don't see Q tails being cut off. Mine is the default of MS Shell Dlg > 2/Normal/8 > > If you got to a higher height than 8 it might cut them off. > > Mike W9MDB > > -- Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] FST4 Rx Freq change BUG?
In FST4 mode, if the Rx Freq is changed (ie. click on wide graph) while transmitting, the TX audio is momentarily interrupted. - Eric NO3M ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Callsign hashing issue FST4
Possibly a bug in callsign hashing (FST4), see QSO messages below from two different instances of WSJT-X (one pulled from ALL.TXT): 0449 32 0.1 1241 ` NO3M -26 0450 -24 0.1 1223 ` NO3M R-18 0451 33 0.1 1241 ` W0SD/0 RR73 0452 -22 0.1 1224 ` W0SD/0 73 210513_044900 0.474 Tx FST4 0 0.0 1241 NO3M -26 210513_045000 0.474 Rx FST4 -24 0.1 1223 NO3M R-18 210513_045100 0.474 Tx FST4 0 0.0 1241 W0SD/0 RR73 <-- interestingly, this one resolved 210513_045200 0.474 Rx FST4 -22 0.1 1224 <8Q3BGF/R> W0SD/0 73 N9RU also reported seeing this behavior, with his callsign being hashed and unrecognizable from his own running instance of WSJT-X: 0924 -21 0.1 1223 ` <3RXMO/OOL40> W0SD/0 73 but his call resolved fine on my running instances: 0924 -15 0.0 1224 ` W0SD/0 73 My assumption was that only the compound call is hashed, but on any '73' or 'RR73' message, the "other" (ie. non-compound call) is being hashed, unresolvable to instances where the hashed call is the same as the station callsign setting but resolvable in other instances where the station call is not that of the hashed callsign. - Eric NO3M ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Callsign hashing issue FST4
Hi Steve I'll see if I can reproduce it and capture in a WAV. WSJT-X v2.3.0 On 5/13/21 8:57 AM, Steven Franke via wsjt-devel wrote: Eric, Thanks for the report. What version of WSJT-X are you running? Here, using the latest development code I tried creating a .wav file containing a single signal with the message “ NO3M/3 RR73”. I decoded this with “NO3M/3” in the Dx Call box and with My Call set to K9AN. No problem with the hashing in that instance. Can you give me a sequence of steps that will reproduce the issue using a saved .wav file? 73 Steve k9an ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Build error r7427
[ 7%] Building Fortran object CMakeFiles/wsjt_fort_omp.dir/lib/decoder.f90.o /home/eric/src-build/wsjtx-superbuild/build/wsjtx/wsjtx-prefix/src/wsjtx/lib/decoder.f90:124:51: ntrials,params%naggressive,params%ndepth,params%emedelay, & 1 Error: Type mismatch in argument ‘clearave’ at (1); passed REAL(4) to LOGICAL(4) /home/eric/src-build/wsjtx-superbuild/build/wsjtx/wsjtx-prefix/src/wsjtx/lib/decoder.f90:149:54: ntrials,params%naggressive,params%ndepth,params%emedelay, & 1 Error: Type mismatch in argument ‘clearave’ at (1); passed REAL(4) to LOGICAL(4) make[5]: *** [CMakeFiles/wsjt_fort_omp.dir/build.make:687: CMakeFiles/wsjt_fort_omp.dir/lib/decoder.f90.o] Error 1 make[4]: *** [CMakeFiles/Makefile2:483: CMakeFiles/wsjt_fort_omp.dir/all] Error 2 make[3]: *** [Makefile:150: all] Error 2 make[2]: *** [CMakeFiles/wsjtx-build.dir/build.make:61: wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2 make[1]: *** [CMakeFiles/Makefile2:293: CMakeFiles/wsjtx-build.dir/all] Error 2 make: *** [Makefile:84: all] Error 2 Relevant build environment output: Updated to revision 7427. [ 69%] Performing configure step for 'wsjtx' -- The C compiler identification is GNU 6.2.1 -- The CXX compiler identification is GNU 6.2.1 -- The Fortran compiler identification is GNU 6.2.1 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Check for working Fortran compiler: /usr/bin/gfortran -- Check for working Fortran compiler: /usr/bin/gfortran -- works -- Detecting Fortran compiler ABI info -- Detecting Fortran compiler ABI info - done -- Checking whether /usr/bin/gfortran supports Fortran 90 -- Checking whether /usr/bin/gfortran supports Fortran 90 -- yes -- Building wsjtx-1.7.1-devel -- ** -- Building for for: Linux-x86_64 -- ****** 73 Eric NO3M -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Build error r7427
Thanks Steve. That worked and compilation completed. Now a binary problem: $ /usr/local/bin/wsjtx No protocol specified 16-12-28T17:14:01.729Z: QXcbConnection: Could not connect to display :0.0 Aborted (core dumped) Hopefully not caused by something else I missed recently. 73 Eric NO3M On 12/27/2016 11:40 PM, Steven Franke wrote: > Eric, This question came up last week. Here is K1JT's response from 12/22: > >> Josh -- >> >> You man need to -clean-first (or remove) your build tree before compiling. >> >> -- Joe, K1JT > Steve k9an > > -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Build error r7427
Nevermind think it had to do with a hostname change I had to temporarily make in order to appease some silly message generated by git on the hamlib repo related to stashing changes. wsjtx running now. 73 Eric NO3M On 12/28/2016 12:14 PM, Eric NO3M wrote: > Thanks Steve. That worked and compilation completed. > > Now a binary problem: > > $ /usr/local/bin/wsjtx > No protocol specified > 16-12-28T17:14:01.729Z: QXcbConnection: Could not connect to display :0.0 > Aborted (core dumped) > > Hopefully not caused by something else I missed recently. > > 73 Eric NO3M > > On 12/27/2016 11:40 PM, Steven Franke wrote: >> Eric, This question came up last week. Here is K1JT's response from 12/22: >> >>> Josh -- >>> >>> You man need to -clean-first (or remove) your build tree before compiling. >>> >>> -- Joe, K1JT >> Steve k9an >> >> > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] JT9 AP request
630M opened up to some US Amateurs this past weekend. FT8 may have
killed JT65 / JT9 for the most part on HF, but down on 630 JT9 is still
king. We need to dig deep for weak (5W EIRP) signals amidst harsh
noise, etc. I'd like to request that AP ("a priori") be integrated into
JT9 for additional sensitivity.
Thanks for considering.
73 Eric NO3M
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] JT9 AP request
Joe Thanks for the information and consideration. A few more dB would certainly go a long way, whatever that may end up being. I've already attempted a QSO with W7IUV in WA that was just past the edge of JT9's current capabilities. We'll eventually make it with some patience on the right morning. There has probably been an equal amount of FT8 and JT9 activity on the band to date. Hope to hear and work you on the band soon. GL DX. 73 Eric NO3M On 10/16/2017 05:04 PM, Joe Taylor wrote: AP decoding capability is not likely to be added to JT9. The whole concept is not well matched to convolutional codes like the one used in JT9. A much better prospect for use at MF and LF would be a "slow FT8" mode with longer transmissions -- say one minute, like JT9. This is eminently feasible and might be implemented at some point. Such a mode could be interesting for EME, as well -- where people need every possible dB of sensitivity but are not always in such a hurry. We have not forgotten about WSPR-LF, either. Or, maybe, a QSO mode that uses OQPSK and coherent demodulation. I hope to have a signal of my own on 472 kHz, before too long! -- Joe, K1JT -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] 2.0.1 ALL.TXT bug
Searched the list and could not find prior reports of this, hopefully not a duplicate. There appears to be a bug with the message content being dumped to ALL.TXT where the first two characters are being truncated. I have only tested this with JT9. Following are a few examples: ALL.TXT: 190321_095600 0.474 Rx JT9 0 0.1 1088 @ K9SLQ EN70 Real message: 0956 0 0.1 1088 @ CQ K9SLQ EN70 ALL.TXT: 190321_100500 0.474 Rx JT9 22 0.1 1088 @ SLQ NO3M EN91 Real message: 1005 22 0.1 1088 @ K9SLQ NO3M EN91 ALL.TXT: 190321_101100 0.474 Rx JT9 21 0.1 1088 @ CDEFGHIJKLM Real message: 1011 21 0.1 1088 @ ABCDEFGHIJKLM 73 Eric NO3M ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsprnet abandoned
This kind of ignorant response is frankly infuriating and in itself shows why wsprnet.org is going to hell to put it kindly I am very active in the LF/MF community and WSPR is heavily used for propagation studies, realtime band opening indication, etc. Ask anyone in at least the US and VK LF/MF community what they think of wsprnet.org... There are definitely spots that never make their way to the database, numerous in fact. The poor system performance is a recurring topic in the LF/MF chat group. Almost nightly someone complains about slow response or that the database part of the site just simply will not load. You can't definitively say all spots are being imported into the database... from the site's vantage point there is no way of knowing what is missed due to the site being unreachable when those lost spots are coming in. The "database" part of the site is very often extremely slow to load or never loads at all. Eventually, without fail, on a daily basis, the page will fail to load when left open in a browser tab when it attempts to auto refresh. I understand you are not part of the technical team, but perhaps the ones responsible can be given the message loud and clear and not continue to assume all is fine. The site (specifically the database infrastructure) needs serious intervention. The folks that are responsible for maintaining the site's functional integrity have failed miserably. Time to step up or pass the responsibility on to a competent team. 73 Eric NO3M On 10/14/19 3:45 PM, Erwin Serle via wsjt-devel wrote: Not sure why you come to these conclusions, the website is not slow, it is not abandoned and the spots enter the database nicely. The map issue is explained in the wsprnet org forum with the appropriate solution as well. Users are managed steadily albeit sometimes slowly as I am probably the only user admin doing any work on it at all most of the time. The other admins focus on keeping the site itself up and running and solving the more technical issues. Happy to give more insight if needed: Erwin, PE3ES/F4VTQ On Thu, Oct 10, 2019 at 4:59 AM Benjamin Bänziger mailto:helios.sola...@gmx.ch>> wrote: Hi, This is probably not the right place for this issue, but all other options didn't get attention unfortunately. Over the past months and years, wsprnet got continuously slower, as more and more people used the service. Since a few months, wsprnet got unreachable for minutes multiple times a day. It is common that database requests time out. wsprnet does also regularly lose wspr spots, because it is overloaded. Since a week now, the map on wsprnet.org <http://wsprnet.org> doesnt work anymore. The official wsprnet e-mail is refusing e-mails since at least one year(!) Over the past months, there have been countless complaints in the wsprnet forum. And also countless offers to help to resolve this issue, also offers for donations. Yet nobody seems to take action. I ask you to please find somebody who takes care of wsprnet.org <http://wsprnet.org>. WSPR is the best mode I've seen in ham radio for exploring propagation. It would be very sad to see it go down like this. wsprnet is a very important part of the WSPR mode. Thanks. 73 ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] wsprnet abandoned
Onno My frustration is specifically with the seeming unwillingness of the admin team to recognize the serious system issues that have plagued the site for the last two years (at least). If this assumption is inaccurate, then my apologies, as it is based on the comments made by the admin that posted to this list and taken as the position of the rest of the admin staff. Countless offers for help have been made by individuals, either in expertise/time or monetary. It seems at this point a fresh perspective and solution is warranted, as the status quo and temporary band-aides that have been performed in recent times only alleviates the issues for a short period of time. The rest of my Email just stated observational facts. At the end of the day, I could care less if the site works or not, I still have my own spots in the locally running WSJTx to utilize as needed. But other folks use the mass collected data for many purposes and it's become more difficult to interact with and acquire that data and parts of the site. Also, this has nothing to do with the map 73 Eric On 10/14/19 10:39 PM, Onno Benschop wrote: Eric, the frustration in your email is visceral and leads me to one question: When did you last pay for an SLA in relation to wsprnet? -- finger painting on glass is an inexact art - apologies for any errors in this scra^Hibble ()/)/)() ..ASCII for Onno.. On Tue., 15 Oct. 2019, 08:37 Eric NO3M, <mailto:n...@no3m.net>> wrote: This kind of ignorant response is frankly infuriating and in itself shows why wsprnet.org <http://wsprnet.org> is going to hell to put it kindly I am very active in the LF/MF community and WSPR is heavily used for propagation studies, realtime band opening indication, etc. Ask anyone in at least the US and VK LF/MF community what they think of wsprnet.org... There are definitely spots that never make their way to the database, numerous in fact. The poor system performance is a recurring topic in the LF/MF chat group. Almost nightly someone complains about slow response or that the database part of the site just simply will not load. You can't definitively say all spots are being imported into the database... from the site's vantage point there is no way of knowing what is missed due to the site being unreachable when those lost spots are coming in. The "database" part of the site is very often extremely slow to load or never loads at all. Eventually, without fail, on a daily basis, the page will fail to load when left open in a browser tab when it attempts to auto refresh. I understand you are not part of the technical team, but perhaps the ones responsible can be given the message loud and clear and not continue to assume all is fine. The site (specifically the database infrastructure) needs serious intervention. The folks that are responsible for maintaining the site's functional integrity have failed miserably. Time to step up or pass the responsibility on to a competent team. 73 Eric NO3M On 10/14/19 3:45 PM, Erwin Serle via wsjt-devel wrote: Not sure why you come to these conclusions, the website is not slow, it is not abandoned and the spots enter the database nicely. The map issue is explained in the wsprnet org forum with the appropriate solution as well. Users are managed steadily albeit sometimes slowly as I am probably the only user admin doing any work on it at all most of the time. The other admins focus on keeping the site itself up and running and solving the more technical issues. Happy to give more insight if needed: Erwin, PE3ES/F4VTQ On Thu, Oct 10, 2019 at 4:59 AM Benjamin Bänziger mailto:helios.sola...@gmx.ch>> wrote: Hi, This is probably not the right place for this issue, but all other options didn't get attention unfortunately. Over the past months and years, wsprnet got continuously slower, as more and more people used the service. Since a few months, wsprnet got unreachable for minutes multiple times a day. It is common that database requests time out. wsprnet does also regularly lose wspr spots, because it is overloaded. Since a week now, the map on wsprnet.org <http://wsprnet.org> doesnt work anymore. The official wsprnet e-mail is refusing e-mails since at least one year(!) Over the past months, there have been countless complaints in the wsprnet forum. And also countless offers to help to resolve this issue, also offers for donations. Yet nobody seems to take action. I ask you to please find somebody who takes care of wsprnet.org <http://wsprnet.org>
Re: [wsjt-devel] About wsprnet losing spots
http://wsprnet.org/drupal/wsprnet/spots Error The website encountered an unexpected error. Please try again later. Error message /PDOException/: SQLSTATE[HY000] [1040] Too many connections in /lock_may_be_available()/ (line /167/ of //var/www/drupal-7.67/includes/lock.inc/). ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FT4/FT8 Diversity patch
200203_204130 1.840 Rx FT8 -15 0.4 965 OD5VB OM3EY JN98 200203_204130 1.840 Rx FT8 -17 0.1 1497 3W1T OK1NI JO70 t 200203_204130 1.840 Rx FT8 -18 -0.3 710 3W1T UZ5ZV KN56 f 200203_204130 1.840 Rx FT8 -16 0.2 1303 JA0CRI SP6EQZ -14 f 200203_204130 1.840 Rx FT8 -19 0.1 1914 YB2DX G4XEE -18 f 200203_204130 1.840 Rx FT8 -17 0.2 2182 9G2HO G3OIL -08 f 200203_204130 1.840 Rx FT8 -15 0.2 2449 9G2HO EI8IU IO63 f 200203_204130 1.840 Rx FT8 -16 0.1 2457 CQ JA DK1CO JO63 f 200203_204130 1.840 Rx FT8 -21 0.1 2550 YB2DX M0BCT JO02 f 200203_204145 1.840 Rx FT8 -9 0.1 500 3W1T F4GTB -14 200203_204145 1.840 Rx FT8 -10 0.1 602 3W1T F8DBF -16 200203_204145 1.840 Rx FT8 -11 0.4 965 OD5VB OM3EY R-03 200203_204145 1.840 Rx FT8 -15 0.4 996 3W1T DL7AU -15 200203_204145 1.840 Rx FT8 -18 0.2 1057 CQ JA SP90PZK 200203_204200 1.840 Rx FT8 -14 0.2 1303 JA0CRI SP6EQZ -14 200203_204200 1.840 Rx FT8 -6 0.2 1656 3W1T ON4GPE -07 200203_204200 1.840 Rx FT8 -18 0.1 1913 YB2DX G4XEE -18 200203_204200 1.840 Rx FT8 -13 0.2 1994 YB2DX DL8YHR -11 200203_204200 1.840 Rx FT8 -19 0.1 2550 YB2DX M0BCT JO02 200203_204200 1.840 Rx FT8 -19 0.1 2457 CQ JA DK1CO JO63 t 200203_204200 1.840 Rx FT8 -17 0.1 1497 3W1T OK1NI JO70 t 200203_204200 1.840 Rx FT8 -19 0.2 709 3W1T UZ5ZV KN56 f 200203_204200 1.840 Rx FT8 -16 0.2 2449 9G2HO EI8IU IO63 f 200203_204200 1.840 Rx FT8 -17 0.1 1026 OD5VB DK2LO -12 s 200203_204200 1.840 Rx FT8 -17 0.3 1751 SV5DKL DL7UM JO33 s 200203_204200 1.840 Rx FT8 -17 0.1 1850 9G2HO IK2OHG JN45 s 200203_204215 1.840 Rx FT8 -8 0.1 602 3W1T F8DBF -16 200203_204215 1.840 Rx FT8 -17 0.1 767 OD5VB OZ1HX -09 200203_204215 1.840 Rx FT8 -21 0.4 965 OD5VB OM3EY R-04 200203_204215 1.840 Rx FT8 -17 0.2 1057 CQ JA SP90PZK 200203_204215 1.840 Rx FT8 -19 0.2 1303 JA0CRI SP6EQZ RRR 200203_204230 1.840 Rx FT8 -15 0.1 1497 3W1T OK1NI JO70 200203_204230 1.840 Rx FT8 -8 0.2 1656 3W1T ON4GPE -07 200203_204230 1.840 Rx FT8 -6 0.2 1683 UT1HV EI9IB -16 200203_204230 1.840 Rx FT8 -10 0.1 1994 YB2DX DL8YHR -11 200203_204230 1.840 Rx FT8 -21 1.2 2253 OD5VB OE5RLM -07 200203_204230 1.840 Rx FT8 -17 0.1 514 3W1T IK4DRY -15 f 200203_204230 1.840 Rx FT8 -17 0.1 1234 OD5VB S53F -21 f 200203_204230 1.840 Rx FT8 -16 0.0 1854 OD5VB IK1TAZ JN44 s 200203_204245 1.840 Rx FT8 -11 0.1 442 3W1T F4GTB -12 200203_204245 1.840 Rx FT8 -13 0.1 601 3W1T F8DBF -16 200203_204245 1.840 Rx FT8 -12 0.1 1683 UT1HV EI9IB -16 200203_204245 1.840 Rx FT8 -18 0.6 1905 CQ 908 DO5OT 200203_204300 1.840 Rx FT8 -11 0.1 1994 YB2DX DL8YHR RR73 200203_204300 1.840 Rx FT8 -21 0.2 1057 CQ JA SP90PZK f 200203_204300 1.840 Rx FT8 -18 0.2 1303 JA0CRI SP6EQZ 73 f 200203_204300 1.840 Rx FT8 -16 0.2 1656 3W1T ON4GPE -07 s 200203_204300 1.840 Rx FT8 -19 1.2 2253 OD5VB OE5RLM -07 s 200203_204300 1.840 Rx FT8 -19 0.1 1234 OD5VB S53F -21 s 200203_204315 1.840 Rx FT8 -16 0.1 602 3W1T F8DBF -16 200203_204315 1.840 Rx FT8 -14 0.1 912 OD5VB DK2LO -06 200203_204315 1.840 Rx FT8 -18 0.3 965 OD5VB OM3EY R+03 200203_204315 1.840 Rx FT8 -19 0.2 1057 CQ JA SP90PZK 200203_204330 1.840 Rx FT8 -15 0.2 1303 CQ JA SP6EQZ JO90 200203_204330 1.840 Rx FT8 -15 0.2 1656 3W1T ON4GPE -07 200203_204330 1.840 Rx FT8 -17 0.1 1850 9G2HO IK2OHG JN45 200203_204330 1.840 Rx FT8 -4 0.2 1994 YB2DX DL8YHR 73 200203_204330 1.840 Rx FT8 -14 0.1 514 3W1T IK4DRY -15 f 200203_204330 1.840 Rx FT8 -19 0.1 767 OD5VB OZ1HX -09 f 200203_204330 1.840 Rx FT8 -19 0.1 2404 EB3A EI9IB -01 f 200203_204330 1.840 Rx FT8 -19 0.1 1404 DM5BB DK5IR 73 s 200203_204330 1.840 Rx FT8 -17 0.6 1905 CQ 908 DO5OT s 200203_204330 1.840 Rx FT8 -18 0.1 814 3W1T UZ5ZV KN56 s Eric NO3M On 1/24/20 11:55 AM, Iztok Saje wrote: Hello friends! Diversity patch for WSJTX 2.1.2 is ready for further testing. On http://lea.hamradio.si/~s52d/ft8div are three files: zip file with sources, sample configuration
