[wsjt-devel] Feedback v1.4.0-rc4
Spent a lot of air time with this release candidate after many hours of v1.5.0-devel on-air testing. Above all, v1.4.0-rc4 lives up to being a rock solid candidate as advertised. Couldn't even get a hiccup from it when intentionally prodding it to misbehave. While some may have issues with CAT compatibilities, I had none - having it control DX Commander which, in turn, controls the rig. I am spoiled, however, by v1.5.0-devel's much faster decoding and ability to handle signals in the -25 dB region. Those are lacking in v11.4.0-rc4. Decoding - especially when both JT65 and JT9 signals are being decoded - is just not that fast. Too, I've lost JT9 QSOs when my QSO partner's signal dropped below -22 dB (QRN is a small problem at this QTH). Now, I look forward to v1.5.0-devel reaching the rock solid operation of V1.4.0-rc4, and itself becoming a release candidate. 73 de Paul DU2/WA8UGN -- 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
[wsjt-devel] Feedback v1.5.0-devel r5007
Hi all - Have spent the weekend giving this build as much "air time" as I could stay awake to provide. Here's some comments with regard to its operation. OVERALL: An excellent build. Pluses outweigh a meager few minuses. It's a good candidate for release. The Plus side: - Outstanding improvement to both speed and depth of decoding. Even with the decode option set at "deepest" and using the JT9+JT65 mode for the entire weekend, decoding is almost immediate following a JT9 transmission, and a little quicker when that longer signal is not present. Too, much weaker signals are now being decoded as opposed to "SIG WEAK AGN?" and "SRI NO DECODE" situations with prior builds. - I've experienced the first occasion of the 14 call sign windows displayed by my JTAlert-X being populated, with the Band Activity window on the WSJT-X front panel displaying even more decodes. - A great feature is having signal reports populate the Log QSO window when it pops up at "73" time. Only need to insert a name, hit "OK" and it's off to the logger. - The addition of selectable standard message generation for type 2 compound call sign holders is quite welcome as well. Choices are three: Full call in Tx1; Full call in Tx3; and Full call in Tx5 only. Neat options to help the "distant end" recognize your full call prior to signing 73. The Minus side: - More of a matter of unfamiliarity and confusion on the "distant end," the use of the above reported new selection for standard message generation resulted in more broken QSOs and much longer QSOs. Of course, if you don't sign a type 2 compound call sign, most of these minuses are invisible. - Out of 57 QSOs, 8 were complete without problems, 38 required repeating the signal report a second (or third) time usingXX YY R-09 instead of the initial DE YYY/YY R-09 report. The other 11 QSOs ended after sending the signal report and the "distant end" vanishing without a trace. - Additionally, responding to an incoming call with DE YYY/YY -12 appears to leave the "distant end" wondering who it is, among the pile-up of callers, that received the "-12," necessitating retransmission with the "old style" message. - The only software "tick" discovered was that when "Full call on Tx5 only" is selected for standard message generation, the signal report that you send to the "distant end" via "R+dB" doesn't populate the Log QSO pop- up window. Wanting more solid QSOs, I stuck with "Tx5 only" after the 57 test QSOs. Messages generated are as before, but the other benefits that are available will soothe the spirit. A hearty "Well done!" and a heartfelt "Thank you" to all of the developers who put this build together and offered it up for testing. I wonder what next could top it? Best 73 from the Philippines, Paul DU2/WA8UGN -- 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
Bill Somerville writes: > > On 06/03/2015 11:15, John Nelson wrote: > > Hi Bill, > Hi John, Hi Bill and John - > > > > I have noticed a similar problem raised by Paul.As Paul points out the "DX" is used by the dictionary as a > DXCC entry. > > > > CQ DX !Phillipines > > > > In my case, double-clicking on does not generate a standard message at all. This is not the same result > as seen by Paul who sees an incorrect Gen Msg being produced. Thank you, John. I was beginning to think that the "senior moments" were getting more frequent until you confirmed what I see. > I can confirm there are defects around the processing of a "CQ DX" > message. The good news is that it can be fixed since the problems are at > the receiving station only. The protocol does encode and decode the > special form "CQ DX " correctly. Everything was as you said when I invoked jt9code.exe and jt65code.exe with several different call sign types. Yet, for some reason, decodes appearing in my Band Activity window still display just as John pointed out. I'm not too concerned about my inability to send CQ DX -- everything heard at this QTH is DX, so my calling CQ is, in effect, calling CQ DX ;) > > I will add repairs for this into this enhancement as they are closely > related. Thanks, Bill, for your work and your patience. btw, the changes to the standard messages providing "dB" and "R+dB" in v1.5.0-devel r5007 will be getting a good workout this weekend. Thanks, again. > > > > --- John G4KLA > 73 > Bill > G4WJS. 73 DE PAUL DU2/WA8UGN -- 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
Bill Somerville writes:
>
>
Hi Bill and all -
> 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.
When decoded here, the messageCQ DX XX is identified as a
Philippine station ("DX") and double-clicking on the call sign XX
results in standard messages being generated with DX being the intended
QSO partner. E.g., DX WA8UGN PK08DX WAUUGN -15DX WA8UGN RRR
Same thing happens whenever anything follows "CQ " (that is C-Q-).
I believe that the standard message form may be "CQDX" (without the space).
> 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. On 03/05/2015 04:04 PM, Guy wrote:
73 DE PAUL DU2/WA8UGN
--
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] WSJT-X: Generated messages /w compound calls
Bill Somerville writes: > > On 03/03/2015 17:22, Paul DU2/WA8UGN wrote: > > Hi again, Bill - > Hi Paul, > Hi Bill - > (snip, snip) > > Well my aim is to try and make the standard generated messages work for > everyone, > (snip, snip) > > DE DU2/WA8UGN R-10 > > would be an excellent solution to this issue. > -- see my laments to John TI4/N0URE. > 73 > Bill > G4WJS. > 73 de PAUL DU2/WA8UGN -- 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] WSJT-X: Generated messages /w compound calls
John Clark writes: > > Paul DU2/WA8UGN > Hi John - > I have had just the inverse experience. > I have used the CQ TI4/N0URE EK70 and DE TI4/N0URE EK70 > as my starting messages for 3 years and have not seen much confusion. > When operating split I will use WA8UGN N0URE -04 to draw you over to my frequency and set off your alarms. > These have paterns have worked well I have WAS & DXCC with TI4/N0URE.73 > How I wish they worked as effectively on this side of the globe! I started out a few years ago and followed protocol precisely as Joe K1JT outlines in his user info files, and like you use. I achieve rates of "acceptance/non-issue" of about 90%-93%. Those rates dropped off over time, with more hams coming on the air, particularly using some versions of JT65-HF that don't handle compound call signs very well. After it got to the point where every attempt to answer a CQ would require two calls DE DU2/WA8UGN PK08 as first go, then XX WA8UGN PK08 the second time around before I'd establish QSO (and receive reports better than a -15, telling me that they heard me - also displayed on HamSpots.com). I'm beginning to believe that the only way to satisfy everyone is for the character set of messages be increased by 8 characters, so that I can call you using TI4/N0URE DU2/WA8UGN PK08 ;) > John > TI4/N0URE > Best 73 from the Philippines, Paul DU2/WA8UGN -- 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] WSJT-X: Generated messages /w compound calls
Bill Somerville writes: > > On 03/03/2015 09:21, Paul DU2/WA8UGN wrote: > > Bill Somerville ...> writes: > > > >> Hi All, > >> > > Hi Bill > Hi Paul, Hi again, Bill - > > > >> OK, take 2:- here's a new test version: > >> > >> https://dl.dropboxusercontent.com/u/4192709/wsjtx-1.4.0-rc3-win32- r4996- > > genmsg.exe > >> I would like some testing by someone with a type 1 compound call and > >> especially by someone with a type 2 compound call. If you can work each > >> other; better still ;) > >> > >> This includes much better decode highlighting, processing and logging > >> for those with compound call signs. > >> > >> (snip, snip) > >> > >> As before testing, comments and, suggestions most welcome. > >> > > Sorry, but I got as far as making unsuccessful calls to 5 different > > stations calling CQ (average dB -9) before I killed this version and > > reverted back to another that I'm testing (r4978). > > > > Sending outDE DU2/WA8UGN PK08had the same effect on all five. > > > > They obviously thought that they were calling CQ on an occupied frequency > > and politely QSY'ed away from me. Attempts to follow one station resulted > > in a wild goose chase up and down the band, where "gentlemanly courtesy" > > won out every time over the "persistent DX-Chaser." > OK, that is a really useful data point. Thanks for trying it out. > > > > So, it's thanks, but no thanks from the Philippines, Bill. I'll stick with > > chasing CQ's with the old XX WA8UGN PK08, have my 4-5 minutes > > of QSO glory, then sign DE DU2/WA8UGN until something better comes > > along. > OK, frankly I am not too surprised but I was keen to try and improve the > likelihood of correct logging by your QSO partners but that is > completely pointless if you can't even start the QSOs :( > > What are your feelings about the original proposal given that sending a > second message (when replying to a CQ) like: > > DE DU2/WA8UGN R-10 > > will not automatically capture the -10 report in your QSO partners log? > > As discussed above I will change WSJT-X to capture that information but > existing versions do not do so. I don't know the position with with the > various JT65-HF versions. > I've had a bit of time to think it over, and do a little more testing, but it seems as if the more that (what I believe to be surefire) improvements are tried, the more confusion it causes on the airwaves. Case in point: Last tests were plagued with QSO partners who relied more on the Free Msg generator than on the "canned" messages to respond to my call sign. To top it off, calling CQ DU2/WA8UGN PK08 netted me one poor soul whose call sign I only partly received because he'd send his call via Free msg and would end up on my screen as DU2/WA8UGN JH . To help fend this off, I have a macro that sends USE ID WA8UGN which seems to work. > > > >> 73 > >> Bill > >> G4WJS. > >> > > Best 73, > > Paul DU2/WA8UGN > 73 > Bill > G4WJS. > > Again, best 73 from the islands Paul DU2/WA8UGN -- 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] WSJT-X: Generated messages /w compound calls
Bill Somerville writes: > > Hi All, > Hi Bill > OK, take 2:- here's a new test version: > > https://dl.dropboxusercontent.com/u/4192709/wsjtx-1.4.0-rc3-win32-r4996- genmsg.exe > > I would like some testing by someone with a type 1 compound call and > especially by someone with a type 2 compound call. If you can work each > other; better still ;) > > This includes much better decode highlighting, processing and logging > for those with compound call signs. > > (snip, snip) > > As before testing, comments and, suggestions most welcome. > Sorry, but I got as far as making unsuccessful calls to 5 different stations calling CQ (average dB -9) before I killed this version and reverted back to another that I'm testing (r4978). Sending outDE DU2/WA8UGN PK08had the same effect on all five. They obviously thought that they were calling CQ on an occupied frequency and politely QSY'ed away from me. Attempts to follow one station resulted in a wild goose chase up and down the band, where "gentlemanly courtesy" won out every time over the "persistent DX-Chaser." So, it's thanks, but no thanks from the Philippines, Bill. I'll stick with chasing CQ's with the old XX WA8UGN PK08, have my 4-5 minutes of QSO glory, then sign DE DU2/WA8UGN until something better comes along. > 73 > Bill > G4WJS. > Best 73, Paul DU2/WA8UGN > -- > 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/ > -- 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] WSJT-X: Generated messages /w compound calls
Bill Somerville writes: > > Hi All, > Hi Bill - > some time back the message generation was changed to help those with > type 2 compound call signs. Details are here: > > (snip) > > Summarizing for a caller with a type 2 compound call sign: > > CQ TI4/N0URE EK70 > N0URE G4WJS IO91 > G4WJS N0URE -05 > N0URE G4WJS R-15 > G4WJS N0URE RRR > N0URE G4WJS 73 (Also see below) > DE TI4/N0URE 73 > > and for an answerer with a type 2 compound call sign: > > CQ G4WJS IO91 > N0URE G4WJS EK70 > N0URE G4WJS -15 > DE TI4/N0URE R-05 This is very intriguing. I'm sure that this form for the R+dB message would help the "distant end" realize that his QSO partner has a compound call sign. > N0URE G4WJS RRR > DE TI4/N0URE 73 > N0URE G4WJS 73 (Also see below) > > with both ends having type 2 compound call signs: > > CQ TI4/N0URE EK70 >N0URE W9XYZ FN75 > W9XYZ N0URE +05 >DE W9XYZ/VE1 R+02 > W9XYZ N0URE RRR >DE W9XYZ/VE1 73 > DE TI4/N0URE 73 > > (snip) > > I would appreciate comments and testing please. Mac and Linux versions > on request. > Having and signing a type 2 compound call sign, I can say that this is a step forward. Too often, QSO partners get a big surprise if and when they pay attention to the "73" response. Other than that, most don't have a clue about the call sign. Hopefully, this "upgrade" to procedure will lessen the number of stray eQSL cards and other QSL/LotW requests that are directed to my call sign without the type 2 compound attributes. Have to reject them and ask them to resubmit directly to my compound call sign. Some do, some don't, some are happy, some are. Now, if we can get those about to answer the CQ of a station with a type 2 compound call sign to just double-click on the call sign and let the software do the work, instead of trying to answer the CQ with a hashed up 13 character free message that won't load properly into the CQ caller's software upon double-click (requiring the CQ caller to either respond with a free message himself or use some ingenuity to work around the problem). > 73 > Bill > G4WJS. > Thanks, Bill Paul DU2/WA8UGN > -- > 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/ > -- 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] WSJT-X v1.5.0-devel r4955 Anomaly
With egg on face, Paul DU2/WA8UGN writes: Paul DU2/WA8UGN writes: > > Murray Curtis ...> writes: > > > > > Hi Paul > > > Hi Murray > > > Thanks for spotting this. Do you recall if the station was using the > > 'standard' CQ call? Currently the use of "CQ DX " will cause this > > type of error. > > Yes, each station was using the "standard" CQ call. The use of "CQ DX > " causes more problems than this - double-clicking on the caller will > set WSJT-X to use "DX" as the station calling "CQ" as well as set up > JTAlertX for using "DX" as the call sign for all of its functions. > > In each case, the tilde (~) appeared in front of the calling station's > country as well, e.g.: 1530 -13 0.2 1145 # CQ XX GD00 ~Timbuktu > > > > > I have good intentions to address that and a couple of other minor > > quirks. I'll get to that soon I hope. > > Thanks! Looking forward to your success! > > > > > Cheers > > Murray > > VK3ACF > > > > Best 73 de Paul DU2/WA8UGN Found what I believe to be the culprit - and he looks like me. On a hunch, I checked my log files, suspecting this is where info is checked by WSJT-X for previously worked stations. Found that my logs didn't go back as far as they should have. There only went back to the date that I changed to the new version that stored logs to the AppData folder. The missing info was in the old log file, sitting idly in an old wsjtx folder. After merging the logs, the problem goes away. While there are some stations appearing as worked before in WSJT-X but as "New QSO" in JTAlertX, that's to be expected. WSJT-X does not do a band-by-band breakout of prior QSOs. I am happy to note, however, that the opposite situation - a station marked as "new call" by WSJT-X but marked as "-B4" in JTAlertX - no longer happens. Makes me happy enough. So, moral of the story is: make sure to merge old log data with new logs if a version upgrade moves the location of the log files. Best 73 from the Philippines, Paul DU2?WA8UGN -- 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] WSJT-X v1.5.0-devel r4955 Anomaly
Murray Curtis writes: > > Hi Paul > Hi Murray > Thanks for spotting this. Do you recall if the station was using the > 'standard' CQ call? Currently the use of "CQ DX " will cause this > type of error. Yes, each station was using the "standard" CQ call. The use of "CQ DX " causes more problems than this - double-clicking on the caller will set WSJT-X to use "DX" as the station calling "CQ" as well as set up JTAlertX for using "DX" as the call sign for all of its functions. In each case, the tilde (~) appeared in front of the calling station's country as well, e.g.: 1530 -13 0.2 1145 # CQ XX GD00 ~Timbuktu > > I have good intentions to address that and a couple of other minor > quirks. I'll get to that soon I hope. Thanks! Looking forward to your success! > > Cheers > Murray > VK3ACF > Best 73 de Paul DU2/WA8UGN -- 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] WSJT-X v1.5.0-devel r4964 Trouble Report
Michael Black writes: > Hi Mike - > > The new version does an FFT wisdom analysis when first run. > You need to let it complete and it may take several minutes depending on > your machine speed. But it should only happen once. And it will miss > decodes while this is going on. > I'll confirm your information - I've not had a single similar episode since the first run was allowed to complete. I admit that I was quick on the trigger to shut WSJT-X down when the "Decode" button stayed illuminated for longer than 10 seconds. The first five stop-start cycles of WSJT-X were just that - I didn't allow enough time for the run to complete. There's chatter regarding what to do in order that a new user won't panic when this occurs at first post-installation start-up. I'd suggest that, if possible, have the analysis occur prior to the first decode being displayed, making it appear as though some process that is part of the application's start-up is still running. Thanks for your "words of wisdom," Mike! > Mike W9MDB > 73 de Paul DU2/WA8UGN -- 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
[wsjt-devel] WSJT-X v1.5.0-devel r4964 Trouble Report
WSJT-Suite-1.0.15-Win32.exe successfully uninstalled using uninstall tool. WSJT-Suite-1.0.16-Win32.exe successfully installed with no problems. Trouble: Temporary lock-up of decoding for 1st 4 decode cycles at start of application, then exceptional operation save for missing 2nd to 4th decode cycle information from view or logs. When WSJT-X v1.5.0-devel r4964 is started and after receiving first 47 seconds of on-air signals, "Decode" button illuminates blue and stays illuminated. No decodes appear in either the "Band Activity" or "Rx Frequency" windows. No decodes are passed to JTAlertX for display or logging. After 4 minutes of being "locked up," the first 47 second decodes appear in the "Band Activity" window immediately followed by the fifth 47 second decodes. Missing are the second through fourth decoding cycles. Once application begins decoding, everything appears to work extremely well, with all displays and logs correctly from that point on. Example when decoding begins in earnest: 1626 1626 - < Missing 4 minutes 1630 1630 - 1631 1631 1631 - 1632 - 1633 1633 Shut down WSJT-X and restarted it, only to observe the same behavior. 5 separate down/up attempts = 5 similar instances of lock-up, then proper operation with the 2nd through 4th decoding cycle information missing from "Band Activity" window and from all logs. Mode: JT9+JT65 Decode: Deepest Radio Rig: DXLab Suite Commander Poll Interval: 1s Ancillary Applications: JTAlertX v2.5.6 DXLab Commander v 11.2.3 Best 73 Paul DU2/WA8UGN -- 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
[wsjt-devel] WSJT-X v1.5.0-devel r4955 Anomaly
Mode: JT9+JT Decode: Deepest Band: 10.138000 Time: 1932 02-12-2105 Anomaly: Decoding of station calling CQ as being "New DXCC" but have QSO'ed same station on 10.138000 three times prior. JTAlertX verified station worked B4, and log check shows 3 out of 5 QSOs with this station being on 10.138000. New user-set color scheme works great - it brought my attention to this anomaly quite quickly. Decodes super fast, but three instances of thirteen garbled characters received an displayed, so far. 73 from Philippines Paul DU2/WA8UGN -- 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] WSJT-X - Wide Graph: Spectral Display Enhancement Request
Michael Black writes: Hi Mike: > > Doesn't the "Flatten" box do that for you? No. "Flatten" further distorts the spectrum display rather than smoothing the baseline. > > I'm looking here right now at a JT9 signal with side lobes that has an 11dB > peak and -25dB on the side lobes which I can see on the Cumulative graph. > So that's a 36dB difference visible and it has all the appearance of being > clamped. In my case - in a signal rich environment - a JT65 signal at -01 will not only "shoot up" from the baseline, but will depress the baseline down making weak signals not appear in the waterfall, though they will appear as pips on the spectrum display's trace. > > Are you looking for more amplitude on the low level signals? So doing > another non-linear scaling would amplify the lower signal levels? > I'm looking to see the weak signals appear on the waterfall display. They appear on the spectrum display, but a very strong signal will depress the entire spectrum display trace to a level below the threshold for appearing on the waterfall. As is, the spectrum display provides a faithful representation of the audio bandpass from the sound card. I'd rather have an indicator of the presence of weak signals on both the spectrum and waterfall displays. > Mike W9MDB > 73 de Paul DU2/WA8UGN -- 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
[wsjt-devel] WSJT-X - Wide Graph: Spectral Display Enhancement Request
Hello Developers: If not already on the "To Do" list, would you consider the following suggested "improvement" for the spectral display in Wide Graph? The waterfall is excellent - I only hope that this suggestion doesn't have to impair the waterfall display in any way just to enhance the spectral display. The version of WSJT-X that I am currently using (v1.5.0-devel r4848) allows for three selections of data for the spectral display: "Current," "Cumulative," and "Linear Avg." Of the three, "Linear Avg" is the only selection to have the baseline trace clamped at a specific level, where it remains regardless of input signal levels, 60-second resets, and the like. It's a nice solid line across the spectrum with signal representations being the only variations. The other two selections are not clamped, but are free to venture up and down the vertical graduals. The trace's movement can be caused by most anything - noise, signal, setting of volume-related controls, etc. Most disconcerting is the downward movement of the trace that occurs when a very strong signal is present - with the trace sometimes leaving the display at the bottom of the graph. This also causes the waterfall to "go dark" for those portions of the spectrum close to the very strong signal. Having two such signals at either end of the spectrum often results in only those two signals appearing on the waterfall with the rest of the graphic display blanked out (other weak to medium-strong signals are blanked out). MY REQUEST: For the "Current" and "Cumulative" selections, is it possible to have the spectrum display's baseline trace appear clamped to a specific level on the display? Having the baseline appear clamped for these two selections, similar to the "Linear Avg" selection, would produce a cleaner representation of the spectrum and could eliminate the blanking of other signals on the waterfall when accompanied by a very strong signal. I ask this so as to obtain the best information from the Wide Graph display that I can. I know that the bandpass of the filtered audio input doesn't change with the introduction of a very strong signal - it's a constant, more or less. Plus, I already know the effects that a very strong signal will have on weaker signals within the bandpass - my ears let me know. Thanks for your consideration (and, hopefully, implementation). Best 73 de Paul DU2/WA8UGN -- 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] Possible Detection/Fix for KV Decoder Errors w/Windows OS - SUCCESS
Paul DU2/WA8UGN writes: > > SUCCESS AT LAST! > . . . > 17+ hours of continuous running and decoding with WSJT-X v1.5.0-devel > r4848 have passed, and not one single error, temporary or complete > lock-up, pop-up error window, or any other complaint. My decoding, > between 2014-Dec-23 14:43 and 2014-Dec-24 07:18, has been flawless, > as recorded in my ALL.txt file. > . . . FOLLOW-UP: Decoding between 2014-Dec-24 14:43 and 2014-Dec-24 17:20 still flawless, as recorded in my ALL.txt file. It certainly looks like my problem is solved. Best Christmas Present Ever! Merry Christmas to all from the Philippines. 73 de Paul DU2/WA8UGN SK -- 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] Possible Detection/Fix for KV Decoder Errors w/Windows OS - SUCCESS
richard stanley writes: > FOLLOW-UP (FINAL) Hello Richard and All - > > I have run most revisions since r6373 and at the moment am running r4848 > and never had a crash while decoding yet. > . . . > I'm wondering if the issues are hardware/software rather than just > software?, not saying that there is a problem with your hardware but > there are so many pc configurations it could be something totally > random causing these issues. > > Regards Richard m0clz SUCCESS AT LAST! Through the extreme kindness of Richard, M0CZL, who provided me with a copy of his WSJT-X v1.5.0-devel-win32 install build, and the continued encouragement of Julian, VK4CMV, who shares the "KV decoder error" problem and similarly seeks resolution, I believe we have resolution. 17+ hours of continuous running and decoding with WSJT-X v1.5.0-devel r4848 have passed, and not one single error, temporary or complete lock-up, pop- up error window, or any other complaint. My decoding, between 2014-Dec-23 14:43 and 2014-Dec-24 07:18, has been flawless, as recorded in my ALL.txt file. All uninstalled Windows Updates have been re-installed, and now all "recommended" and "important" updates are present in my OS. The only difference noted is the kvasd.exe application. Version 1.5.0-devel r4848 installs a 48KB kvasd.exe file whereas those in earlier versions were 181KB in size. Other than that, I'm too tired from testing to do much more exploring this week. > > -Original Message- > From: Paul DU2/WA8UGN > Sent: Tuesday, December 23, 2014 6:16 AM > . . . > Final confirmation of WSJT-X - Windows interaction having some > relationship to the errors observed came when each Windows update was > . . . > The "offending" Windows Updates are: > > KB3025390 - major "offender" > KB2952664 - minor "offender" > > . . . > -- Best 73 from the Philippines, Paul DU2/WA8UGN -- 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] Possible Detection/Fix for KV Decoder Errors w/Windows OS
richard stanley writes: Hi Richard: > > I have run most revisions since r6373 and at the moment am running r4848 and > never > had a crash while decoding yet. Same here - never had any problems at all with any of the 3 versions I've used, until last week. Then all "went south" on me. I'd like to try r4848 if I can find it. > > I have windows 7 with all updates installed. It is a six core amd unit with > 8GB ram. > > WSJTX is set for decode deepest and the waterfall to bins/pixels 3 and the > default > jt65 2500 jt9 Configuration wise, we are similar save for Bins/Pixels 4 here - to get entire audio bandwidth displayed on the waterfall. > > Using split mode on my ic-7000 I can operate anywhere displayed on the > waterfall with no issues. Using Kenwood TS-570D but PTT with VOX - no CAT. (Not that it makes much of a difference.) > > The system is left on most of the time, with random downtimes to allow the > missus to run her > version or to see if there are any issues with the latest builds. > > Your 1st update is for explorer which I don't use anyway (I use firefox and > chrome) though as explorer > is integral to windows I would think I have the update. Yes, it's to fix some problems that appeared in IE11 operation after an update installed about a week before it. It also has a few other "tricks." > > The 2nd update seems to be causing issues for some and nothing for others > regardless of if they use > wsjtx or any ham related software. That is a probability that I have thought as well. One of the effects, though, is slower decoding on WSJT-X (at least here at this QTH). > > I'm wondering if the issues are hardware/software rather than just software > ?, not saying that there is > a problem with your hardware but there are so many pc configurations it > could be something totally > random causing these issues. I'm open to any suggestions. I don't like the idea of running Windows without important updates (like the 1st one). Still, what I see is what I get: With those two updates uninstalled, WSJT-X operation returns to what was considered normal. I let the auto- update routine re-install both updates, and the errors and issues started right back up again. So, all I can do now it throw it out to the forum and see if any others have been through this and/or know what provides the relief sought. Cheers. > > Regards Richard m0clz Best 73, Paul DU2/WA8UGN > > -Original Message- > From: Paul DU2/WA8UGN > Sent: Tuesday, December 23, 2014 6:16 AM > To: wsjt-devel@... > Subject: [wsjt-devel] Possible Detection/Fix for KV Decoder Errors w/Windows > OS > > After extensive testing, and with the aid of Julian, VK4CMV, who confirmed > the existence of the exact same errors occurring with his WSJT-X > operations, I come to the conclusion that changes to Microsoft Windows via > periodic Windows updates, may be a major player in error activity. > > Testing was done on 3 different versions of WSJT-X (r3673, r4400, & r4633) > in total isolation from the world, save "on-air" signal input. Almost > every permutation of disabling software, option settings, etc. were > employed in a very large number of tests. Each test was performed after a > complete scrubbing of my laptop's hard drive, memory, and drivers. No > positive effects were observed during the tests. > > I finally uninstalled every Windows update placed into service in Dec 2014, > and re-tested. Results were most encouraging, with long runs of each > WSJT-X version before a hiccup. Hiccups were cured by restarting WSJT-X > (not the optimum resolution, but much better than others found to date). > > Final confirmation of WSJT-X - Windows interaction having some relationship > to the errors observed came when each Windows update was individually re- > installed. No change to the much improved operation of WSJT-X versions was > observed until two different updates were installed. Each caused a slow- > down of decoding, increased errors, and frequent Decode lock-ups. > > The "offending" Windows Updates are: > > KB3025390 - major "offender" > KB2952664 - minor "offender" > > With these two Windows updates uninstalled, and everything but the kitchen > sink attached to the laptop and every bit of software normally used in weak > signal operations here running, the results of testing were impressive. > Fast decoding (I use "Deepest" decoding), and a noteworthy improvement in > mean time between errors. Best, only one decoder lock-up over 6+ hours of > testing. If a KV error occurs,
[wsjt-devel] Possible Detection/Fix for KV Decoder Errors w/ Windows OS
After extensive testing, and with the aid of Julian, VK4CMV, who confirmed the existence of the exact same errors occurring with his WSJT-X operations, I come to the conclusion that changes to Microsoft Windows via periodic Windows updates, may be a major player in error activity. Testing was done on 3 different versions of WSJT-X (r3673, r4400, & r4633) in total isolation from the world, save "on-air" signal input. Almost every permutation of disabling software, option settings, etc. were employed in a very large number of tests. Each test was performed after a complete scrubbing of my laptop's hard drive, memory, and drivers. No positive effects were observed during the tests. I finally uninstalled every Windows update placed into service in Dec 2014, and re-tested. Results were most encouraging, with long runs of each WSJT-X version before a hiccup. Hiccups were cured by restarting WSJT-X (not the optimum resolution, but much better than others found to date). Final confirmation of WSJT-X - Windows interaction having some relationship to the errors observed came when each Windows update was individually re- installed. No change to the much improved operation of WSJT-X versions was observed until two different updates were installed. Each caused a slow- down of decoding, increased errors, and frequent Decode lock-ups. The "offending" Windows Updates are: KB3025390 - major "offender" KB2952664 - minor "offender" With these two Windows updates uninstalled, and everything but the kitchen sink attached to the laptop and every bit of software normally used in weak signal operations here running, the results of testing were impressive. Fast decoding (I use "Deepest" decoding), and a noteworthy improvement in mean time between errors. Best, only one decoder lock-up over 6+ hours of testing. If a KV error occurs, with or without the pop-up error window, normal operation continues. The pop-up error window can be closed when it appears - no observable deterioration in normal operations occur when that pop-up appears, nor when it is manually closed. Any thoughts about this line of testing and its results? Best 73, Paul DU2/WA8UGN -- 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] Error in KV decider, or no KV decoder present.
Paul DU2/WA8UGN writes: > > I have started to receive errors today with WSJT-X v1.4.0-rc3 r4633. > > SETUP: > Kenwood TS-570D - VOX PTT; no CAT, DTR or RTS > SignaLink USB sound card > Sony VAIO (VPCCB) laptop w/ Windows 7 (64b) Home Premium > WSTJ-X v1.4-rc3 r4633 > Operating Freq: 24.917000 MHz > Operating Mode: JT9+JT65 (currently set for JT65 #) > Decode: Deepest > JTAlertX v2.5.5 > Applications Auto-Start: C:\WSTJ\wstjx\bin\wstjx.exe (Start & Close) > Logging: DXLab DXKeeper v12.6.3 [PF] > Library: DXLab Pathfinder v5.0.1 > > ERRORS: > 1) A pop-up error window exclaims: "The process cannot access the file > because it is being used by another process." > > 2) Simultaneously,the following is displayed in the Band Activity window: > "Error in KV decoder, or no KV decoder present." > > I have restarted the software a few times, as well as the laptop, but > errors still occur randomly. Closing the pop-up window allows operator > intervention with the software - the software continues to download and > decode signals after errors are reported. > > Will continue observations, including those with various software disabled. > FOLLOW-UP: I thought I had traced the problem to the "kvasd.exe" program that was installed at: C:\WSJT\wsjtx\bin\kvasd.exe Trying to open it as admin, I received an error saying that the program was not registered. Hmmm. That's funny. I then took steps to register it, and received a new error saying that the application was corrupt. That was all I needed to see. I backed up my important WSJT-X files, then re-installed WSJT-X v1.4.0-rc3 r4633 from scratch on top of the old install (didn't bother to uninstall). All ran exceptionally well for over 24 hours. Then, while on 24.917, things happened again. This time I observed that the error message in the Band Activity window occurred while WSJT-X was attempting to decode and extremely strong JT65 signal (-01 is the limit, but the Wide Graph display showed that if there was no limit, the signal would have been + double digits). The error message also changed a little. It now read: "Error in KV decoder, or no KV decoder present. -107" Additionally, decoding came to a halt about 4 minute-cycles later, with the "Decode" button constantly illuminated. No combination of "points & clicks" would bring WSJT-X out of its coma, save shutting it down and restarting it. Once restarted, decoding returned to normal, except when the huge -01 signal was present. Then a single decode would have two error messages generated, the decoded message, then four more error messages displayed. These error messages did not have the "-107" but now the pop-up window exclaiming: "The process cannot access the file because it is being used by another process." returned. Will try complete reinstall after complete uninstall. Onward and upward, 73 Paul DU2/WA8UGN -- 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=164703151&iu=/4140/ostg.clktrk ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Error in KV decider, or no KV decoder present.
Bill Somerville writes: Hi Bill, > > On 17/12/2014 10:55, Paul DU2/WA8UGN wrote: > Hi Paul, > > I have started to receive errors today with WSJT-X v1.4.0-rc3 r4633. > > > > SETUP: > > Kenwood TS-570D - VOX PTT; no CAT, DTR or RTS > > SignaLink USB sound card > > Sony VAIO (VPCCB) laptop w/ Windows 7 (64b) Home Premium > > WSTJ-X v1.4-rc3 r4633 > >Operating Freq: 24.917000 MHz > >Operating Mode: JT9+JT65 (currently set for JT65 #) > >Decode: Deepest > > JTAlertX v2.5.5 > >Applications Auto-Start: C:\WSTJ\wstjx\bin\wstjx.exe (Start & Close) > >Logging: DXLab DXKeeper v12.6.3 [PF] > >Library: DXLab Pathfinder v5.0.1 > > > > ERRORS: > > 1) A pop-up error window exclaims: "The process cannot access the file > > because it is being used by another process." > > > > 2) Simultaneously,the following is displayed in the Band Activity window: > > "Error in KV decoder, or no KV decoder present." > The build of WSJT-X has changed to separate KVASD from the Open Source > parts of the application, this is so that we are compliant with the > copyrights and licences we have to comply with. > > You have three choices: > > 1) Build a debug version, the debug build continues to install kvasd, > 2) Build an installer and use that to install the application, the > installer deals with KVASD installation, > 3) Set the CMake option WSJT_INCLUDE_KVASD=ON. > > Option (1) is probably best for those making changes to the application > but has some other complications related to environment setup, > option (2) is best if you rarely build the application from source or > want to test the installer, > Option (3) is probably optimal for those building for their own use on a > regular basis. Thanks for the info and the options. I must admit that I'm not a developer but an "unofficial" tester of sorts - I'll take the latest version that is available and put it through its jumps. I approached this issue from a different route - running WSJT-X with other software disabled or idle. My first tests revolved around "what's new or what have I changed lately?" and started disabling programs. The first was a new installation of antivirus software. To make it quiet, I completely uninstalled it, cleaned the registry, and took other steps to remove any signs of it. When running WSJT-X and the rest of the software minus the antivirus software (turned on Microsoft Security Essentials for protection, though), the errors disappeared. Why? I haven't a clue. I did remember having a slight problem getting that antivirus software installed the first time, so I made sure I was clean of the first install, downloaded the software from the manufacturer again, and re-installed it. So far, so good. May have been a funny glitch caused by that initial install. > > > > I have restarted the software a few times, as well as the laptop, but > > errors still occur randomly. Closing the pop-up window allows operator > > intervention with the software - the software continues to download and > > decode signals after errors are reported. > > > > Will continue observations, including those with various software disabled. > > > > 73 > > > > Paul DU2/WA8UGN > 73 > Bill > G4WJS. > 73 es TNX AGN Paul DU2/WA8UGN > -- > 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=164703151&iu=/4140/ostg.clktrk > -- 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=164703151&iu=/4140/ostg.clktrk ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Error in KV decider, or no KV decoder present.
I have started to receive errors today with WSJT-X v1.4.0-rc3 r4633. SETUP: Kenwood TS-570D - VOX PTT; no CAT, DTR or RTS SignaLink USB sound card Sony VAIO (VPCCB) laptop w/ Windows 7 (64b) Home Premium WSTJ-X v1.4-rc3 r4633 Operating Freq: 24.917000 MHz Operating Mode: JT9+JT65 (currently set for JT65 #) Decode: Deepest JTAlertX v2.5.5 Applications Auto-Start: C:\WSTJ\wstjx\bin\wstjx.exe (Start & Close) Logging: DXLab DXKeeper v12.6.3 [PF] Library: DXLab Pathfinder v5.0.1 ERRORS: 1) A pop-up error window exclaims: "The process cannot access the file because it is being used by another process." 2) Simultaneously,the following is displayed in the Band Activity window: "Error in KV decoder, or no KV decoder present." I have restarted the software a few times, as well as the laptop, but errors still occur randomly. Closing the pop-up window allows operator intervention with the software - the software continues to download and decode signals after errors are reported. Will continue observations, including those with various software disabled. 73 Paul DU2/WA8UGN -- 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=164703151&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 v1.4.0-rc2 Error Report
Paul DU2/WA8UGN writes: > > I use JTAlertX with WSTJ-X. Believe there may be an interaction issue > between WSJT-X and the latest version of JTAlertX or with its associated > application JTMacrosX. > > Installed JTAlertX update 11/15/2014; now using JTAlertX 2.5.1. > FOLLOW-UP: Tested combo JTAlertX / WSTJ-X using numerous permutations. Error continues to occur. Error appears to be WSTJ-X trying to write to file decoded.txt while JTAlertX has the file open to read. There has been a coding change in the updated JTAlertX program concerning the timing of that read function, I believe. Fix: For now, completely uninstall JTAlertX 2.5.1 and reinstall JTAlert-X 2.4.18. 73 de Paul DU2/WA8UGN -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] WSJT-X v1.4.0-rc2 Error Report
I use JTAlertX with WSTJ-X. Believe there may be an interaction issue between WSJT-X and the latest version of JTAlertX or with its associated application JTMacrosX. Installed JTAlertX update 11/15/2014; now using JTAlertX 2.5.1. Settings involving WSJT-X interface with JTAlertX include: * Auto-Start/Close of wsjtx.exe; * Auto-Start/Close of JTMacrosX 2.5.1; * Auto-clear JTAlert callsigns when WSTJ-X decodes cleared; and * Waterfall follow WSJT-X minimize and restore. WSJT-X has, on occasion, displays an error pop-up window during Decode, citing: "Fortran runtime error. Cannot write to file opened for READ" Waterfall display is unaffected; Decode button stays illuminated (blue) and all activity in both Band Activity and Rx Frequency windows is halted. No other symptoms are apparent. Closing and re-starting programs clears error and returns operation back to normal. I have not experienced this error situation using prior versions of JTAlertX. I am running additional on-air tests, using different permutations of the JTAlertX settings, the use of JTMacros, and the use of JTAlertX itself. Initial testing with JTAlertX closed (off) results in continuous, error-free operation; pointing towards an interaction issue. WSTJ-X settings employed are: * Mode:JT9+JT65 * Decode: Deepest * Tx: TxJT65 #; Tx odd; Lock Tx=Rx I have attempted registration in and am awaiting entrance to the "HamApps by VK33AMA" Yahoo Group to make similar report. There appears to be conversation about similar and other issues experienced by others who upgraded to JTAlertX 2.5.1. Cannot, as of yet, post my error report to that group. Best 73, Paul DU2/WA8UGN -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Experiments on ALL.TXT
Hi Sandro and all: Alessandro Gorobey writes: > > Il 14/11/2014 19:06, Claude Frantz ha scritto: > > On 11/14/2014 06:39 PM, Alessandro Gorobey wrote: > > > >> Now time problem. The NTP protocol can maintain synchronized the clock > >> with a reference, but normally on a good quality laptop have a very poor > >> quality clock. Looking at the results of NTP I can see drift of 100mS in > >> 12 hours from shutdown and startup. > > I think that NTP is a good solution if a server is running on your > > laptop. If an Internet connection is available, you can use some NTP > > servers available in this network. If not, you can use a GPS mouse > > and/or a receiver for standard time signals. > > > > Best 88 de Claude > Perfect agree Claude > I have the server running on my laptop. > If I turnoff the computer for 12 or 24 hours, the internal clock is too > poor to maintain the time. > So an error of 100 mS is normal and will be corrected in short time but > will never be perfect. > Few and rare machines that I tested for experiment has an internal clock > that avoid this initials errors and a lot of drift. > The common chip-sets are not capable to maintain a few mS in all > condictions. > > Best 88 de Sandro IW3RAB You can synchronize your laptop's internal clock with NTP by creating a Time Synchronization Task in the Task Scheduler of your W7/64 laptop. For ease of description and to save space here, please follow this link to learn how to do it. http://www.pretentiousname.com/timesync/index.html Also, you should change your laptop's Internet Time server to an NTP Internet Time Server that is more accurate than time.windows.com and is physically closer to your QTH. Best 73 de Paul DU2/WA8UGN -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Lower frequency limit
Hi Nick, Bill, & All - Bill Somerville writes: > > On 08/11/2014 11:35, nick wrote:of BFO > > Hi Nick & All, > > I like the empirical approach Paul! Thanks, Nick! > > > > Your results pretty much correspond with my observations. > > > > The softrock and sdr-core combination goes all the way down to 0Hz. I > > run the softrock LO with a 12kHz offset to get away from DC and the LF > > limit of the Delta 44 sound card. > > > > I will start logging at < 250Hz and see what happens. > You might try tuning up to ..078.5 (e.g. 14.0785 MHz) and running JT9 > for these tests. I suggest it due to the bandwidth of the signal being a > much smaller proportion of the audio frequency range you want to test. > That way you will get a much better indication of the lower limit. > Having said that, in both cases (JT65 & JT9) the sync tone is at the LF > end of the signal and detection of that is fundamental to decoding. > > Joe K1JT will have a definitive answer, but I wonder if the DF is in any > way proportional to the resolving capability of the WSJT-X decoders. If > not then there is no theoretical lower limit and any limiting effects > would be down to secondary factors like roll off in SSB demodulator and > any audio circuits and of course the obvious filtering of the BFO. Have performed a little off-the-air testing, using recorded JT-65 signals synthesized down in frequency via another app, and employing just the laptop and the SignaLink USB Sound Card. Results were reproducible; was able to decode down into the single digit region, as far as the app could differentiate the audio freq. So, I guess "no theoretical lower limit" is holding its own. I agree with Bill that limiting appears to be chiefly resulting from secondary factors, to which one must add atmospheric and man-made noise when decoding live on-air. Best to tune away. > There is another issue to consider, if you transmit very near your Rx DF > zero you may get a reply below your DF zero which you will not decode so > working near DF zero is not necessarily a good idea. Via on-air monitoring, users noted transmitting very near their DF zero (not tuning away) often generate phantom/spurious signals in addition to the intended signal. This includes both an image mirroring the intended signal to which others respond in vain, and an image that is "double- spaced" in bandwidth. Chats via JTAlert-X text messaging confirmed the practice employed by some. (Users employing speech processing generate a whole different set of QMR!). > > > > 73 > > > > Nick G3VNC > 73 > Bill > G4WJS. > > > > On 08/11/14 07:36, Paul DU2/WA8UGN wrote: > >> Paul DU2/WA8UGN ...> writes: > >>> I have had WSJT-X v1.4.0-rc2 (beta) decode a JT-65 signal at 183Hz on Nov > >>> 7, 2014: > >>> > >>> 1607 -23 -0.5 183 # UK8OAR DG5SAY R-20 > >>> > >>> 1609 -22 -0.5 183 # UK8OAR DG5SAY 73 > >>> > >>> 73 > >>> > >>> Paul DU2/WA8UGN > >>> > >>> -- > >> > >> Follow-up information: > >> > >> Date/Time: 11/7/2014 1607-1609 UTC > >> Frequency:14.076183MHz > >> Low-end audio cutoff (-3dB): ~300Hz > >> Low-end audio cutoff (total: ~120Hz > >> Equipment:Kenwood TS-570D > >> SignaLink USB Sound Card > >> Sony VAIO VPCCB laptop > >> > >> Cheers & 73, > >> > >> Paul DU2/WA8UGN (formerly G5BNV) > > > > -- > > ___ > > wsjt-devel mailing list > > wsjt-devel@... > > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > -- > Best 73 Paul DU2/WA8UGN -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Lower frequency limit
Paul DU2/WA8UGN writes: > > nick ...> writes: > > > > > What is the lowest baseband frequency that wsjt-x will decode down to? > > > > I have seen instances on the wide graph where signals fail to decode at > > < 250Hz. > > > > 73 > > > > Nick G3VNC > > > > -- > > > > > Nick - > > I have had WSJT-X v1.4.0-rc2 (beta) decode a JT-65 signal at 183Hz on Nov > 7, 2014: > > 1607 -23 -0.5 183 # UK8OAR DG5SAY R-20 > > 1609 -22 -0.5 183 # UK8OAR DG5SAY 73 > > 73 > > Paul DU2/WA8UGN > > -- > Follow-up information: Date/Time:11/7/2014 1607-1609 UTC Frequency:14.076183MHz Low-end audio cutoff (-3dB): ~300Hz Low-end audio cutoff (total: ~120Hz Equipment:Kenwood TS-570D SignaLink USB Sound Card Sony VAIO VPCCB laptop Cheers & 73, Paul DU2/WA8UGN (formerly G5BNV) -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Lower frequency limit
nick writes: > > What is the lowest baseband frequency that wsjt-x will decode down to? > > I have seen instances on the wide graph where signals fail to decode at > < 250Hz. > > 73 > > Nick G3VNC > > -- > Nick - I have had WSJT-X v1.4.0-rc2 (beta) decode a JT-65 signal at 183Hz on Nov 7, 2014: 1607 -23 -0.5 183 # UK8OAR DG5SAY R-20 1609 -22 -0.5 183 # UK8OAR DG5SAY 73 73 Paul DU2/WA8UGN -- ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
