[wsjt-devel] FT8 Freqs
I guess it was deliberate to include the JT9 frequencies in the FT8 frequency
list for 20M and 40M?
{14074000, Modes::FT8, IARURegions::ALL}, {14076000, Modes::JT65,
IARURegions::ALL}, {14078000, Modes::FT8, IARURegions::ALL},
{14078000, Modes::JT9, IARURegions::ALL},
{7038600, Modes::WSPR, IARURegions::ALL}, {7074000, Modes::FT8,
IARURegions::ALL}, {7076000, Modes::JT65, IARURegions::ALL},
{7078000, Modes::FT8, IARURegions::ALL}, {7078000, Modes::JT9,
IARURegions::ALL},
de Mike W9MDB___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Audio dropouts confirmed and resolved
Here's a patch which adds audio debug to the Band Activity window.I would also add a patch to the Settings/Audio tab for a checkbox to enable this but since I don't have access to current source code it's a waste of my time to submit a patch for that. Perhaps one of the team with code access might do that. https://www.dropbox.com/s/28zd89oo0cty7d3/audiodebug.patch?dl=1 It's quite verbose and looks like this where the 1st sound packet will have the largest dT value and the rest are 280-290ms with 3456 byte packet sizes.If audio dropouts occur you'll see larger dT values. If the packet after that is not faster than 280ms than an audio dropout has occurred and you won't see the counter get to 50. I also think the WAV save decision should be based on time and not the packet count since decoding with less than 50 packets can work. 15.287 dataSink1 1/50, k=3456, dT=370ms 15.575 dataSink1 2/50, k=6912, dT=288ms 15.865 dataSink1 3/50, k=10368, dT=290ms 16.155 dataSink1 4/50, k=13824, dT=290ms 16.435 dataSink1 5/50, k=17280, dT=280ms 16.725 dataSink1 6/50, k=20736, dT=290ms 17.015 dataSink1 7/50, k=24192, dT=290ms 17.305 dataSink1 8/50, k=27648, dT=290ms 17.595 dataSink1 9/50, k=31104, dT=290ms 17.878 dataSink1 10/50, k=34560, dT=283ms 18.165 dataSink1 11/50, k=38016, dT=287ms 18.455 dataSink1 12/50, k=41472, dT=290ms 18.744 dataSink1 13/50, k=44928, dT=289ms 19.035 dataSink1 14/50, k=48384, dT=291ms 19.315 dataSink1 15/50, k=51840, dT=280ms 19.605 dataSink1 16/50, k=55296, dT=290ms 19.895 dataSink1 17/50, k=58752, dT=290ms 20.185 dataSink1 18/50, k=62208, dT=290ms 20.475 dataSink1 19/50, k=65664, dT=290ms 20.756 dataSink1 20/50, k=69120, dT=281ms 21.045 dataSink1 21/50, k=72576, dT=289ms 21.334 dataSink1 22/50, k=76032, dT=289ms 21.625 dataSink1 23/50, k=79488, dT=291ms 21.915 dataSink1 24/50, k=82944, dT=290ms 22.195 dataSink1 25/50, k=86400, dT=280ms 22.487 dataSink1 26/50, k=89856, dT=292ms 22.775 dataSink1 27/50, k=93312, dT=288ms 23.065 dataSink1 28/50, k=96768, dT=290ms 23.354 dataSink1 29/50, k=100224, dT=289ms 23.637 dataSink1 30/50, k=103680, dT=283ms 23.925 dataSink1 31/50, k=107136, dT=288ms 24.215 dataSink1 32/50, k=110592, dT=290ms 24.505 dataSink1 33/50, k=114048, dT=290ms 24.795 dataSink1 34/50, k=117504, dT=290ms 25.075 dataSink1 35/50, k=120960, dT=280ms 25.365 dataSink1 36/50, k=124416, dT=290ms 25.655 dataSink1 37/50, k=127872, dT=290ms 25.945 dataSink1 38/50, k=131328, dT=290ms 26.235 dataSink1 39/50, k=134784, dT=290ms 26.517 dataSink1 40/50, k=138240, dT=282ms 26.805 dataSink1 41/50, k=141696, dT=288ms 27.095 dataSink1 42/50, k=145152, dT=290ms 27.385 dataSink1 43/50, k=148608, dT=290ms 27.675 dataSink1 44/50, k=152064, dT=290ms 27.955 dataSink1 45/50, k=155520, dT=280ms 28.245 dataSink1 46/50, k=158976, dT=290ms 28.535 dataSink1 47/50, k=162432, dT=290ms 28.826 dataSink1 48/50, k=165888, dT=291ms 29.115 dataSink1 49/50, k=169344, dT=289ms 29.396 dataSink1 50/50, k=172800, dT=281ms 051115 -15 0.4 700 ~ CQ MT K7MDL EL87 29.688 dataSink1 51/50, k=176256, dT=292ms 051115 -17 0.5 1452 ~ 4Z5ML N2VOA R-14 29.975 dataSink1 52/50, k=179712, dT=287ms 30.287 dataSink1 1/50, k=3456, dT=312ms 30.575 dataSink1 2/50, k=6912, dT=288ms 051115 -12 0.4 2186 ~ PJ4P WB6UZZ DM13 30.865 dataSink1 3/50, k=10368, dT=290ms 31.156 dataSink1 4/50, k=13824, dT=291ms 31.436 dataSink1 5/50, k=17280, dT=280ms 31.725 dataSink1 6/50, k=20736, dT=289ms 32.015 dataSink1 7/50, k=24192, dT=290ms 32.305 dataSink1 8/50, k=27648, dT=290ms 32.595 dataSink1 9/50, k=31104, dT=290ms 32.876 dataSink1 10/50, k=34560, dT=281ms 33.165 dataSink1 11/50, k=38016, dT=289ms 33.455 dataSink1 12/50, k=41472, dT=290ms 33.746 dataSink1 13/50, k=44928, dT=291ms 34.035 dataSink1 14/50, k=48384, dT=289ms 34.315 dataSink1 15/50, k=51840, dT=280ms 34.605 dataSink1 16/50, k=55296, dT=290ms 34.895 dataSink1 17/50, k=58752, dT=290ms 35.185 dataSink1 18/50, k=62208, dT=290ms 35.476 dataSink1 19/50, k=65664, dT=291ms 35.756 dataSink1 20/50, k=69120, dT=280ms 36.045 dataSink1 21/50, k=72576, dT=289ms 36.335 dataSink1 22/50, k=76032, dT=290ms 36.625 dataSink1 23/50, k=79488, dT=290ms 36.915 dataSink1 24/50, k=82944, dT=290ms 37.195 dataSink1 25/50, k=86400, dT=280ms 37.485 dataSink1 26/50, k=89856, dT=290ms 37.775 dataSink1 27/50, k=93312, dT=290ms 38.065 dataSink1 28/50, k=96768, dT=290ms 38.355 dataSink1 29/50, k=100224, dT=290ms 38.636 dataSink1 30/50, k=103680, dT=281ms 38.926 dataSink1 31/50, k=107136, dT=290ms 39.215 dataSink1 32/50, k=110592, dT=289ms 39.504 dataSink1 33/50, k=114048, dT=289ms 39.796 dataSink1 34/50, k=117504, dT=292ms 40.075 dataSink1 35/50, k=120960, dT=279ms 40.365 dataSink1 36/50, k=124416, dT=290ms 40.656 dataSink1 37/50, k=127872, dT=291ms 40.946 dataSink1 38/50, k=131328, dT=290ms 41.235 dataSink1 39/50, k=134784, dT=289ms 41.517 dataSink1 40/50, k=138240, dT=282ms 41.805 dataSink1 41/50, k=141696, dT=288ms 42.095
Re: [wsjt-devel] Audio dropouts confirmed and resolved
I built a special version with some added debug to make seeing the dropouts easier and observe the behavior. Might be useful to include this in WSJT-X as a checkbox in the Audio tab. We determined the audio was buffering OK at startup...several fast events catching up on the audio buffer. But then large delta times would occur without an associated fast interval to follow up indicating audio was dropping on the floor. de Mike W9MDB On Tuesday, January 29, 2019, 5:47:46 PM CST, Bill Barrett wrote: Hello MIke & Mike- "Each sample from the audio buffer (50/per 15 seconds for FT8) should take roughly 280uS. I start seeing several samples in each group of 50 take between 400-700uS. As a result not all 50 required audio samples are collected in the time allowed and the period is skipped and the .WAV file (if turned on) is not written out. If you turn on Save ALL and you see missing .WAV files in the directory, this is another symptom. " Interesting information; I would be interested in the debugging tool used to display the buffer timing.Thanks;Bill W2PKY On Tue, Jan 29, 2019 at 12:58 AM Mike Lewis wrote: You have probably seen my earlier posts tracking down the cause of lost decode cycles, or more often, decoding just completely stops on a new HP laptop when CPU utilization is < 10%. Above that all is fine. This is on a new 8th gen Core i5 8265U, Intel UHD620 GPU, 8GB RAM, 256GB SSD, and 1366x720 display. USB audio and internal Realtek sound devices. Laptop lid open or closed, no matter. The final solution here was to set the Display timeout to Never. I normally only RDP to this machine and the lid is always closed, so the display would normally shut off for that reason. Never thought a timer setting would still matter, but it does. After many long hours (over 5 weeks’ worth) of testing and experimenting with every setting and program combination you could imagine, debug builds, changing C states, latency analysis, I noticed a loose correlation with decoding usually working the first several minutes after a reboot before coming to an end and a display setting. The “Turn Off Display after XX minutes” option in the Advanced Power Options menu. I am thinking that the display (and external graphics HDMI connector) is always forced on after a reboot, or attempts to at least. Setting it to “Never” did the trick after a reboot. To repro the failure, turn it to 10 minutes and wait, decoding will start seeing audio delays. No reboot required to force the failure. Each sample from the audio buffer (50/per 15 seconds for FT8) should take roughly 280uS. I start seeing several samples in each group of 50 take between 400-700uS. As a result not all 50 required audio samples are collected in the time allowed and the period is skipped and the .WAV file (if turned on) is not written out. If you turn on Save ALL and you see missing .WAV files in the directory, this is another symptom. LatencyMon will show all is good. Changing C states and Turbo Boost and any available such tweaks had no effect. Slide a random window around with the mouse fast for 10- 15 seconds to raise CPU above 10% for a decode period, or simply run any program that eats enough CPU cycles to get above 10%, all is good. I had resorted to running a Speedtest modern app and just letting it sit open on the desktop, tucked out of the way. Minimizing it dropped the CPU% too much. Its animated GO button was just enough to get me to 12%. I tried to repro this on a similar model HP laptop but with a Core i3 and 1080p display, otherwise same packaging, 4GB RAM and 128GB SSD, same Intel UHD620 GPU but it worked fine below 10%. Looked at its setting and it was 10 minutes, so this issue seems to be very particular. Here is the Advanced Power Options screen snapshot: I would like to thank Mike W9MDB for his many hours of assistance during this exercise, we now have the means/knowledge to easily spot such effects. Understanding the reason for them is still an art and likely case by case. - Mike K7MDL ___ 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] Audio dropouts confirmed and resolved
Hello MIke & Mike- "Each sample from the audio buffer (50/per 15 seconds for FT8) should take roughly 280uS. I start seeing several samples in each group of 50 take between 400-700uS. As a result not all 50 required audio samples are collected in the time allowed and the period is skipped and the .WAV file (if turned on) is not written out. If you turn on Save ALL and you see missing .WAV files in the directory, this is another symptom. " Interesting information; I would be interested in the debugging tool used to display the buffer timing. Thanks; Bill W2PKY On Tue, Jan 29, 2019 at 12:58 AM Mike Lewis wrote: > You have probably seen my earlier posts tracking down the cause of lost > decode cycles, or more often, decoding just completely stops on a new HP > laptop when CPU utilization is < 10%. Above that all is fine. This is on > a new 8th gen Core i5 8265U, Intel UHD620 GPU, 8GB RAM, 256GB SSD, and > 1366x720 display. USB audio and internal Realtek sound devices. Laptop > lid open or closed, no matter. > > > > The final solution here was to set the Display timeout to Never. I > normally only RDP to this machine and the lid is always closed, so the > display would normally shut off for that reason. Never thought a timer > setting would still matter, but it does. > > > > After many long hours (over 5 weeks’ worth) of testing and experimenting > with every setting and program combination you could imagine, debug builds, > changing C states, latency analysis, I noticed a loose correlation with > decoding usually working the first several minutes after a reboot before > coming to an end and a display setting. The “Turn Off Display after XX > minutes” option in the Advanced Power Options menu. I am thinking that the > display (and external graphics HDMI connector) is always forced on after a > reboot, or attempts to at least. Setting it to “Never” did the trick after > a reboot. To repro the failure, turn it to 10 minutes and wait, decoding > will start seeing audio delays. No reboot required to force the failure. > > > > Each sample from the audio buffer (50/per 15 seconds for FT8) should take > roughly 280uS. I start seeing several samples in each group of 50 take > between 400-700uS. As a result not all 50 required audio samples are > collected in the time allowed and the period is skipped and the .WAV file > (if turned on) is not written out. If you turn on Save ALL and you see > missing .WAV files in the directory, this is another symptom. > > > > LatencyMon will show all is good. Changing C states and Turbo Boost and > any available such tweaks had no effect. Slide a random window around with > the mouse fast for 10- 15 seconds to raise CPU above 10% for a decode > period, or simply run any program that eats enough CPU cycles to get above > 10%, all is good. I had resorted to running a Speedtest modern app and > just letting it sit open on the desktop, tucked out of the way. Minimizing > it dropped the CPU% too much. Its animated GO button was just enough to > get me to 12%. > > > > I tried to repro this on a similar model HP laptop but with a Core i3 and > 1080p display, otherwise same packaging, 4GB RAM and 128GB SSD, same Intel > UHD620 GPU but it worked fine below 10%. Looked at its setting and it was > 10 minutes, so this issue seems to be very particular. > > > > Here is the Advanced Power Options screen snapshot: > > > > I would like to thank Mike W9MDB for his many hours of assistance during > this exercise, we now have the means/knowledge to easily spot such > effects. Understanding the reason for them is still an art and likely case > by case. > > > >- Mike K7MDL > > > > > > > ___ > 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] Decode lite up - no decode
Hi Joe- I run multiple instances all the time. A problem I have observed is when cancelling all instances, using the windows tray and right clicking on the WSJT-X ICON in the tray and cancelling all instances there is usually several zombie instances of WSJT-X left in the Task Manager. Not a big issues, but thought I would mention it. Thanks & 73; Bill W2PKY On Tue, Jan 29, 2019 at 4:40 PM Joe Taylor wrote: > Hi Tom, > > > Pretty daft to kill processes that may be needed on an assumption. > > It's not daft, at all. Probably 99% of WSJT-X users run only one > instance. In the rare but not unheard-of case where something caused a > program crash, jt9.exe may be left running. When WSJT-X is re-started, > that zombie jt9.exe must be killed. > > Surely it's easy enough for you to start your instances in the proper > order? The ~1% of users running multiple instances have been doing that > for years, with no issues. > > -- 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
Re: [wsjt-devel] Change Suggestion: Retry audio source if interrupted
https://xkcd.com/1172/ On Tue, Jan 29, 2019 at 4:41 PM Mike Lewis wrote: > Use Case: The audio input source is interrupted causing the waterfall and > decoding to stop. Program gives no indication otherwise something happened. > >1. Currently it required restarting the program (and lose all screen >history) or toggling the audio input source (preserve screen history, like >QSO in progress) or its left/right/mono setting to restart decoding. >2. This is guaranteed to happen if you lose a RDP session, even >momentarily (internet hiccup, can be as fast a 2 seconds). I believe there >are hooks into the audio chain for possible audio redirection that I assume >are touched on session start and end, even if I am not redirecting audio. >3. Loss for other reason like a bumped connector. > > > > Suggestions: Re-initialize the last known good audio source. > >1. Suggest a graduated timer approach. Retry immediately and then if >unsuccessful set gradually increasing retry interval until and ultimate >timeout. >2. Print to screen and file reason why (text or icon, flashing monitor >in red perhaps). >3. File text would include timestamps for later troubleshooting. > > > > Tnx! > > > > Mike K7MDL > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- Carey Fisher careyfis...@gmail.com ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Decode lite up - no decode
Hi All Yes work around is to have all instances use the —rig-name=xxx option Joe - there are times I don’t want to run wsjtx on 6m (the instance with no —rig-name option) - I could be using jt6, FSK411 for MS (a lot of UK contests still don’t support FT8/MSK) which wsjtx does not support - so I just start HF to check conditions —rig-name=HF instance - work away. Finish with MSHV and switch back to wsjtx to use MSK/FT8 - that would kill the HF screen. I have been running all night here with —rig-name=HF and —rig-name=VHF and all is 100% no mater what order I use. I’m pretty sure the software could check for running wsjtx processes (jtalert does it well) and if there are none, other that the one just started, then kill the jt9 exe - if there are existing wsjtx processes don’t kill - that would deal with the rogue process and handle the —rig-name option. 73’s Tom GM8MJV (IO85) On 29 Jan 2019, at 21:40, Joe Taylor wrote: > Hi Tom, > >> Pretty daft to kill processes that may be needed on an assumption. > > It's not daft, at all. Probably 99% of WSJT-X users run only one instance. > In the rare but not unheard-of case where something caused a program crash, > jt9.exe may be left running. When WSJT-X is re-started, that zombie jt9.exe > must be killed. > > Surely it's easy enough for you to start your instances in the proper order? > The ~1% of users running multiple instances have been doing that for years, > with no issues. > > -- Joe, K1JT > ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Decode lite up - no decode
Hi Tom, Pretty daft to kill processes that may be needed on an assumption. It's not daft, at all. Probably 99% of WSJT-X users run only one instance. In the rare but not unheard-of case where something caused a program crash, jt9.exe may be left running. When WSJT-X is re-started, that zombie jt9.exe must be killed. Surely it's easy enough for you to start your instances in the proper order? The ~1% of users running multiple instances have been doing that for years, with no issues. -- Joe, K1JT ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Change Suggestion: Retry audio source if interrupted
Use Case: The audio input source is interrupted causing the waterfall and decoding to stop. Program gives no indication otherwise something happened. 1. Currently it required restarting the program (and lose all screen history) or toggling the audio input source (preserve screen history, like QSO in progress) or its left/right/mono setting to restart decoding. 2. This is guaranteed to happen if you lose a RDP session, even momentarily (internet hiccup, can be as fast a 2 seconds). I believe there are hooks into the audio chain for possible audio redirection that I assume are touched on session start and end, even if I am not redirecting audio. 3. Loss for other reason like a bumped connector. Suggestions: Re-initialize the last known good audio source. 1. Suggest a graduated timer approach. Retry immediately and then if unsuccessful set gradually increasing retry interval until and ultimate timeout. 2. Print to screen and file reason why (text or icon, flashing monitor in red perhaps). 3. File text would include timestamps for later troubleshooting. Tnx! Mike K7MDL ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Change Suggestion: Print to Activity Window and a file if nothing decoded
Use Case : A decode cycle is missed due to any number of reasons. Print out info to that effect to better inform the user what is going on. 1. In my case I had buffer delays at low CPU. Very hard to tell except that I saw activity in the waterfall and ran a second laptop off the same feed and verified it should have decoded. 2. No signals or no usable signals present - dead band, different protocols, full capture but nothing decodable 3. "Monitor" enabled in the middle of a cycle - need enough audio captured in a cycle to process successfully. At program startup if enabled and when a user hits the button. Suggestion: Write out to screen and/or file that nothing happened and why 1. If print blank lines is enabled, print the blank line every cycle, not just when there was activity decode. * If there was nothing to decode and no problem detected, print the equivalent blank line text to a file (like ALL.txt). Add "Nothing to decode" or similar text. 2. If there was an incomplete audio capture, print to the Activity Window and a file (like ALL.txt) that a problem exists and append the reason why (incomplete audio capture for example). * I see this in JTDX at times like startup. * Print out the number of buffer requests achieved (such as "Frames 47 of 50" for the values of m_ihsym and m_hsymStop variables. Provides instant tell of audio dropout issue going on. Tnx! Mike K7MDL ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Decode lite up - no decode
Thanks Mike So that means you MUST start the single instance first no matter what. That does agree with what I am seeing - nothing in the docs to say there is a ‘start up’ order. As a work around I will try to set all my wsjtx instances to use a —rig-name option and see if that will help keep things running. Pretty daft to kill processes that may be needed on an assumption. -- 73’s Tom GM8MJV (IO85) On 29 Jan 2019, at 17:54, Black Michael via wsjt-devel wrote: > It is coded that way. When you start with --rig-name it knows to expect > multiple instances. Without --rig-name it assumes you're running only one > and kills the jt9 process...but doesn't kill the wsjtx process...which seems > wrong. > > I suppose it's possible to make that check a bit better to allow either > sequence > > de Mike W9MDB > > > > > On Monday, January 28, 2019, 4:36:51 PM CST, Tom Melvin > wrote: > > > > Good day all > > Posted over in general wsjtx list not much joy - Been playing and need some > advice > > One PC, multiple Audio connections to two separate transceivers - wsjtx v2.0.0 > > Start one wsjtx —rig-name=test wsjt starts up and runs fine > > Start another instance but no —rig-name - wsjtx starts up and runs fine but > the original instance has stopped decoding, icon on all the time. > > This only happens if you start the —rig-name=xx instance BEFORE the plain > one. If you start the main instance first, then the —rig-name=xx and don’t > restart or change config both will work 100% ok. As soon as you restart or > change config on the ‘main’ instance the —rig-name instance will lock up. > > Looking at task manager the jt9 process no longer exists on the 1st one. > > Have tried this with main ham setup on windows 7, as a test loaded wsjtx on a > stand alone Windows 10 laptop and same problem. > > Compiled from source, on windows 10 laptop and same problem. > > I can reproduce this 100% on two different PC’s with different versions of > windows. > > Is the a way I can see in a little more details what was happening that would > cause the jt9 process to die? > > > 73’s > > Tom > GM8MJV (IO85) > > > > > ___ > 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] Decode lite up - no decode
It is coded that way. When you start with --rig-name it knows to expect multiple instances. Without --rig-name it assumes you're running only one and kills the jt9 process...but doesn't kill the wsjtx process...which seems wrong. I suppose it's possible to make that check a bit better to allow either sequence de Mike W9MDB On Monday, January 28, 2019, 4:36:51 PM CST, Tom Melvin wrote: Good day all Posted over in general wsjtx list not much joy - Been playing and need some advice One PC, multiple Audio connections to two separate transceivers - wsjtx v2.0.0 Start one wsjtx —rig-name=test wsjt starts up and runs fine Start another instance but no —rig-name - wsjtx starts up and runs fine but the original instance has stopped decoding, icon on all the time. This only happens if you start the —rig-name=xx instance BEFORE the plain one. If you start the main instance first, then the —rig-name=xx and don’t restart or change config both will work 100% ok. As soon as you restart or change config on the ‘main’ instance the —rig-name instance will lock up. Looking at task manager the jt9 process no longer exists on the 1st one. Have tried this with main ham setup on windows 7, as a test loaded wsjtx on a stand alone Windows 10 laptop and same problem. Compiled from source, on windows 10 laptop and same problem. I can reproduce this 100% on two different PC’s with different versions of windows. Is the a way I can see in a little more details what was happening that would cause the jt9 process to die? 73’s TomGM8MJV (IO85) ___ 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] Audio dropouts confirmed and resolved
Good info! Thanks! I'm doing something similar and although It didn't affect WSJT-X it did cause issues with my loggin software trying to do lookups. On Tue, Jan 29, 2019 at 1:04 AM Mike Lewis wrote: > You have probably seen my earlier posts tracking down the cause of lost > decode cycles, or more often, decoding just completely stops on a new HP > laptop when CPU utilization is < 10%. Above that all is fine. This is on > a new 8th gen Core i5 8265U, Intel UHD620 GPU, 8GB RAM, 256GB SSD, and > 1366x720 display. USB audio and internal Realtek sound devices. Laptop > lid open or closed, no matter. > > > > The final solution here was to set the Display timeout to Never. I > normally only RDP to this machine and the lid is always closed, so the > display would normally shut off for that reason. Never thought a timer > setting would still matter, but it does. > > > > After many long hours (over 5 weeks’ worth) of testing and experimenting > with every setting and program combination you could imagine, debug builds, > changing C states, latency analysis, I noticed a loose correlation with > decoding usually working the first several minutes after a reboot before > coming to an end and a display setting. The “Turn Off Display after XX > minutes” option in the Advanced Power Options menu. I am thinking that the > display (and external graphics HDMI connector) is always forced on after a > reboot, or attempts to at least. Setting it to “Never” did the trick after > a reboot. To repro the failure, turn it to 10 minutes and wait, decoding > will start seeing audio delays. No reboot required to force the failure. > > > > Each sample from the audio buffer (50/per 15 seconds for FT8) should take > roughly 280uS. I start seeing several samples in each group of 50 take > between 400-700uS. As a result not all 50 required audio samples are > collected in the time allowed and the period is skipped and the .WAV file > (if turned on) is not written out. If you turn on Save ALL and you see > missing .WAV files in the directory, this is another symptom. > > > > LatencyMon will show all is good. Changing C states and Turbo Boost and > any available such tweaks had no effect. Slide a random window around with > the mouse fast for 10- 15 seconds to raise CPU above 10% for a decode > period, or simply run any program that eats enough CPU cycles to get above > 10%, all is good. I had resorted to running a Speedtest modern app and > just letting it sit open on the desktop, tucked out of the way. Minimizing > it dropped the CPU% too much. Its animated GO button was just enough to > get me to 12%. > > > > I tried to repro this on a similar model HP laptop but with a Core i3 and > 1080p display, otherwise same packaging, 4GB RAM and 128GB SSD, same Intel > UHD620 GPU but it worked fine below 10%. Looked at its setting and it was > 10 minutes, so this issue seems to be very particular. > > > > Here is the Advanced Power Options screen snapshot: > > > > I would like to thank Mike W9MDB for his many hours of assistance during > this exercise, we now have the means/knowledge to easily spot such > effects. Understanding the reason for them is still an art and likely case > by case. > > > >- Mike K7MDL > > > > > > > ___ > 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] Where can I find a web page with the wsjtx stable release versions listed?
Not sure if this helps but you can use release-monitoring.org... https://release-monitoring.org/project/16118/ It also has HTTP and Python APIs... https://release-monitoring.org/static/docs/api.html Thanks, Richard ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Where can I find a web page with the wsjtx stable release versions listed?
On 29/01/2019 09:33, Barry Jackson wrote: On 28/01/2019 23:45, Bill Somerville wrote: On 28/01/2019 22:40, Barry Jackson wrote: Hi Barry, the best I can think of is this: https://sourceforge.net/projects/wsjt/files/ .. Hi Bill, That will do nicely, I don't know how I failed to find that page! [baz@leno ~]$ lynx --dump https://sourceforge.net/projects/wsjt/files/|grep "/files/wsjtx-"|head -n1|cut -d- -f2|cut -d/ -f1 2.0.0 It's obviously not bomb proof but it will suffice for my purpose :) Many thanks, 73 Barry G4MKT Hi Barry, you asked for a web page. If you want a more reliable list of releases, that isn't prone to SourceForge changing the format of that web page, you should clone the git repo and use the following two commands to get an up to date list of GA releases: git fetch ; git tag --sort=version:refname -l 'wsjtx-*' | grep -v 'rc' or if you want it with the newest first: git fetch ; git tag --sort=-version:refname -l 'wsjtx-*' | grep -v 'rc' 73 Bill G4WJS. ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Where can I find a web page with the wsjtx stable release versions listed?
On 29/01/2019 00:01, G8DQX (WSJT developers on SF) wrote: Barry, or this might be what you are after: https://sourceforge.net/p/wsjt/wsjtx/ci/master/tree/Versions.cmake. The Mark I eyeball may also be what you are after, since there is no obvious (to me, at least) reliably parsable version information file to be seen. Bill's suggestion and mine are both opportunistic rather than cleanly, reliably & consistently structured, such as an XML tag. Robin, I have used the Versions.cmake for some other packages and it's worked well however Bill's suggestion will do for now, as it's simpler :) I don't know what 'Mark I eyeball' means :\ It would be nice if there was a reliable structured file in all upstream projects as it's difficult to extract this info in many cases, and of course they are all different. Thanks for taking the time to reply, 73 Barry G4MKT ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Where can I find a web page with the wsjtx stable release versions listed?
On 28/01/2019 23:45, Bill Somerville wrote: On 28/01/2019 22:40, Barry Jackson wrote: Hi Barry, the best I can think of is this: https://sourceforge.net/projects/wsjt/files/ .. Hi Bill, That will do nicely, I don't know how I failed to find that page! [baz@leno ~]$ lynx --dump https://sourceforge.net/projects/wsjt/files/|grep "/files/wsjtx-"|head -n1|cut -d- -f2|cut -d/ -f1 2.0.0 It's obviously not bomb proof but it will suffice for my purpose :) Many thanks, 73 Barry G4MKT ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
