Menu
▾
▴
wsjt-devel
|
From: Josh R. <jos...@gm...> - 2025-05-23 16:17:06
|
I see similar behavior about every 72 hours or so on Fedora Core 41, 64-bit. Restarting wsjtx seems to cure it for another 72 hours .. Josh Rovero KK1D On Fri, May 23, 2025, 08:57 <wsj...@li...> wrote: > Send wsjt-devel mailing list submissions to > wsj...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > or, via email, send a message with subject or body 'help' to > wsj...@li... > > You can reach the person managing the list at > wsj...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wsjt-devel digest..." > > > Today's Topics: > > 1. wsjtx wspr#dt error (Paul Simon) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 22 May 2025 15:31:13 -0700 > From: Paul Simon <ps...@so...> > To: wsj...@li... > Subject: [wsjt-devel] wsjtx wspr#dt error > Message-ID: <100o8jh$ju5$1...@ci...> > Content-Type: text/plain; charset=UTF-8; format=flowed > > I have been running wspr 24/7 using the linux version of wsjtx. After > about two days, dt seems to increase by 6 seconds, in a single jump, not > gradually. This does not happen on Windows. > > 1. The same happens on two different machines running Ubuntu and > Mageia,v 2.61 and v 2.7.0-rc8. > > 2. Computer clock is correct: checked vs. time.is, NIST controlled > clock, etc. Time measured manually is within one second. > > 3. Closing and reopening wsjtx immediately results in correct dt. > > 4. Running wsjtx under WINE gives same result. > > 5. Waterfall timing is correct and can see the six second early start of > sequence. > > 6. Only happens if transmit box is ticked. > > Could someone please confirm and/or suggest possible solutions? > > Paul W6EXT > > > > > ------------------------------ > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > ------------------------------ > > End of wsjt-devel Digest, Vol 135, Issue 32 > ******************************************* > |
|
From: Paul S. <ps...@so...> - 2025-05-24 21:32:32
|
On 5/23/2025 9:16 AM, Josh Rovero via wsjt-devel wrote: > I see similar behavior about every 72 hours or so on Fedora Core 41, 64-bit. > > Restarting wsjtx seems to cure it for another 72 hours .. > > Josh Rovero > KK1D > ------------------------------------------ > > I have been running wspr 24/7 using the linux version of wsjtx. After > about two days, dt seems to increase by 6 seconds, in a single jump, > not > gradually. This does not happen on Windows. > > 1. The same happens on two different machines running Ubuntu and > Mageia,v 2.61 and v 2.7.0-rc8. > > 2. Computer clock is correct: checked vs. time.is <http://time.is>, > NIST controlled > clock, etc. Time measured manually is within one second. > > 3. Closing and reopening wsjtx immediately results in correct dt. > > 4. Running wsjtx under WINE gives same result. > > 5. Waterfall timing is correct and can see the six second early > start of > sequence. > > 6. Only happens if transmit box is ticked. > > Could someone please confirm and/or suggest possible solutions? > > Paul W6EXT > --------------- Well, good luck Josh. No response from anyone else. No developers either. Some of the links on the SourceForge pages are dead. One of the SourceForge pages states that WSPR is of historical interest. "So Long, and Thanks for All the Fish" Paul, W6...@ar... |
|
From: <al...@al...> - 2025-05-25 10:54:01
|
I don't at the moment use Linux but there's quite a number of search results on "linux time jump" that seem to indicate this might perhaps be something to do with the way Linux uses time? Maybe you need to write some kind of script to restart WSJT-X at regular intervals? Alan G0TLK On 24/05/2025 22:26, Paul Simon via wsjt-devel wrote: > On 5/23/2025 9:16 AM, Josh Rovero via wsjt-devel wrote: >> I see similar behavior about every 72 hours or so on Fedora Core 41, >> 64-bit. >> >> Restarting wsjtx seems to cure it for another 72 hours .. >> >> Josh Rovero >> KK1D >> > > ------------------------------------------ >> >> I have been running wspr 24/7 using the linux version of wsjtx. >> After >> about two days, dt seems to increase by 6 seconds, in a single jump, >> not >> gradually. This does not happen on Windows. >> >> 1. The same happens on two different machines running Ubuntu and >> Mageia,v 2.61 and v 2.7.0-rc8. >> >> 2. Computer clock is correct: checked vs. time.is <http://time.is>, >> NIST controlled >> clock, etc. Time measured manually is within one second. >> >> 3. Closing and reopening wsjtx immediately results in correct dt. >> >> 4. Running wsjtx under WINE gives same result. >> >> 5. Waterfall timing is correct and can see the six second early >> start of >> sequence. >> >> 6. Only happens if transmit box is ticked. >> >> Could someone please confirm and/or suggest possible solutions? >> >> Paul W6EXT >> > > --------------- > Well, good luck Josh. No response from anyone else. No developers > either. Some of the links on the SourceForge pages are dead. One of > the SourceForge pages states that WSPR is of historical interest. > > > "So Long, and Thanks for All the Fish" > > Paul, W6...@ar... > > > > > > > > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel |
|
From: Glenn W. <af...@al...> - 2025-05-25 16:57:29
|
Evidence: 1 Linux time is always correct and advances monotonically. 2 Restarting WSJT-X for WSPR fixes the problem. 3 No one has mentioned this about WSJT-X running, for example, FT8. (?) 4 But does this happen on machines that run different motherboards and or processors (i.e. Intel vs AMD vs ARM)? At least we know that it happens with different flavors of Linux. Conclusions: 1 Inside the WSPR code there is a (let's call it) "register" that has been informed of Linux time at the start of WSJT-X execution. 2 Guess: Perhaps the register does not contain enough bits for holding Linux time and when the register reaches maximum count it overflows and resets to 000000... (But time jumping ahead does not agree with this prediction because a reset would be backwards.) 3 The delta of 6 seconds is a clue to how many counts are missed at the least significant bits end of the register. 4 In the code someone left out a CONST declaration. Etc. 5 It's a fixable bug. 6 WSPR code was at least partially written by someone different from the other code(s) so that declarations of variables are different. 7 Or it's caused by some other "bug". A family tree of possible bugs is larger than what I am imagining. See 5. 8 I am probably be wrong again. :) I could subscribe to the Digest. But maybe I don't want that much email. --Glenn, AF8C On 5/24/2025 5:26 PM, Paul Simon via wsjt-devel wrote: > On 5/23/2025 9:16 AM, Josh Rovero via wsjt-devel wrote: >> I see similar behavior about every 72 hours or so on Fedora Core 41, >> 64-bit. >> >> Restarting wsjtx seems to cure it for another 72 hours .. >> >> Josh Rovero >> KK1D >> > > ------------------------------------------ >> >> I have been running wspr 24/7 using the linux version of wsjtx. >> After >> about two days, dt seems to increase by 6 seconds, in a single jump, >> not >> gradually. This does not happen on Windows. >> >> 1. The same happens on two different machines running Ubuntu and >> Mageia,v 2.61 and v 2.7.0-rc8. >> >> 2. Computer clock is correct: checked vs. time.is <http://time.is>, >> NIST controlled >> clock, etc. Time measured manually is within one second. >> >> 3. Closing and reopening wsjtx immediately results in correct dt. >> >> 4. Running wsjtx under WINE gives same result. >> >> 5. Waterfall timing is correct and can see the six second early >> start of >> sequence. >> >> 6. Only happens if transmit box is ticked. >> >> Could someone please confirm and/or suggest possible solutions? >> >> Paul W6EXT >> > > --------------- > Well, good luck Josh. No response from anyone else. No developers > either. Some of the links on the SourceForge pages are dead. One of the > SourceForge pages states that WSPR is of historical interest. > > > "So Long, and Thanks for All the Fish" > > Paul, W6...@ar... > > > > > > > > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- This email has been checked for viruses by Avast antivirus software. www.avast.com |
|
From: Nic S. <nic...@ta...> - 2025-05-25 18:56:22
|
<div dir='auto'>Could it be a memory leak type of problem? <div dir="auto"><br></div><div dir="auto">Nic G3YEG - ex comms programmer/ debug specialist</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 May 2025 13:23, Glenn Williams via wsjt-devel <wsj...@li...> wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Evidence:<br> 1 Linux time is always correct and advances monotonically.<br> 2 Restarting WSJT-X for WSPR fixes the problem.<br> 3 No one has mentioned this about WSJT-X running, for example, FT8. (?)<br> 4 But does this happen on machines that run different motherboards and<br> or processors (i.e. Intel vs AMD vs ARM)? At least we know that it <br> happens with different flavors of Linux.</p> <p dir="ltr">Conclusions:<br> 1 Inside the WSPR code there is a (let's call it) "register" that has<br> been informed of Linux time at the start of WSJT-X execution.<br> 2 Guess: Perhaps the register does not contain enough bits for holding <br> Linux time and when the register reaches maximum count it overflows and<br> resets to 000000... (But time jumping ahead does not agree with<br> this prediction because a reset would be backwards.)<br> 3 The delta of 6 seconds is a clue to how many counts are missed at the<br> least significant bits end of the register.<br> 4 In the code someone left out a CONST declaration. Etc.<br> 5 It's a fixable bug.<br> 6 WSPR code was at least partially written by someone different from the<br> other code(s) so that declarations of variables are different.<br> 7 Or it's caused by some other "bug". A family tree of possible bugs<br> is larger than what I am imagining. See 5.<br> 8 I am probably be wrong again. :)</p> <p dir="ltr">I could subscribe to the Digest. But maybe I don't want that much email.</p> <p dir="ltr">--Glenn, AF8C</p> <p dir="ltr">On 5/24/2025 5:26 PM, Paul Simon via wsjt-devel wrote:<br> > On 5/23/2025 9:16 AM, Josh Rovero via wsjt-devel wrote:<br> >> I see similar behavior about every 72 hours or so on Fedora Core 41, <br> >> 64-bit.<br> >><br> >> Restarting wsjtx seems to cure it for another 72 hours ..<br> >><br> >> Josh Rovero<br> >> KK1D<br> >><br> > <br> > ------------------------------------------<br> >><br> >>     I have been running wspr 24/7 using the linux version of wsjtx. <br> >> After<br> >>     about two days, dt seems to increase by 6 seconds, in a single jump,<br> >>     not<br> >>     gradually.  This does not happen on Windows.<br> >><br> >>     1. The same happens on two different machines running Ubuntu and<br> >>     Mageia,v 2.61 and v 2.7.0-rc8.<br> >><br> >>     2. Computer clock is correct: checked vs. time.is <http://time.is>,<br> >>     NIST controlled<br> >>     clock, etc.  Time measured manually is within one second.<br> >><br> >>     3. Closing and reopening wsjtx immediately results in correct dt.<br> >><br> >>     4. Running wsjtx under WINE gives same result.<br> >><br> >>     5. Waterfall timing is correct and can see the six second early<br> >>     start of<br> >>     sequence.<br> >><br> >>     6. Only happens if transmit box is ticked.<br> >><br> >>     Could someone please confirm and/or suggest possible solutions?<br> >><br> >>     Paul W6EXT<br> >><br> > <br> > ---------------<br> > Well, good luck Josh.  No response from anyone else. No developers <br> > either. Some of the links on the SourceForge pages are dead.  One of the <br> > SourceForge pages states that WSPR is of historical interest.<br> > <br> > <br> > "So Long, and Thanks for All the Fish"<br> > <br> > Paul, W6...@ar...<br> > <br> > <br> > <br> > <br> > <br> > <br> > <br> > <br> > _______________________________________________<br> > wsjt-devel mailing list<br> > wsj...@li...<br> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel<br></p> <p dir="ltr">-- <br> This email has been checked for viruses by Avast antivirus software.<br> www.avast.com<br></p> <p dir="ltr">_______________________________________________<br> wsjt-devel mailing list<br> wsj...@li...<br> https://lists.sourceforge.net/lists/listinfo/wsjt-devel<br> </p> </blockquote></div><br></div> |
|
From: Doug B. Sr. <dou...@gm...> - 2025-05-25 21:41:16
|
Not sure if this is a red herring but maybe another piece of data for you guys: I was just running Linux Mint and the latest Wsjtx and after my phone died, which had a hotspot the laptop was using, my Rx seemed to get really bad. I couldn't see many signals and couldn't make any more QSOs. Then an operator from Arizona wrote to me and said my clock was off by 2 seconds (or more?). Never had that happen before, at least, no one has ever told me my clock was off. Note, it was an old laptop, and an old ICOM 706, and the battery was almost dead on the laptop also. Probably just one of those battery related issues or something, but the clock being off seemed atypical, empirically speaking. HTH, 73 Doug KC1UUH On Sun, May 25, 2025, 3:01 PM Nic Sears via wsjt-devel < wsj...@li...> wrote: > Could it be a memory leak type of problem? > > Nic G3YEG - ex comms programmer/ debug specialist > > On 25 May 2025 13:23, Glenn Williams via wsjt-devel < > wsj...@li...> wrote: > > Evidence: > 1 Linux time is always correct and advances monotonically. > 2 Restarting WSJT-X for WSPR fixes the problem. > 3 No one has mentioned this about WSJT-X running, for example, FT8. (?) > 4 But does this happen on machines that run different motherboards and > or processors (i.e. Intel vs AMD vs ARM)? At least we know that it > happens with different flavors of Linux. > > Conclusions: > 1 Inside the WSPR code there is a (let's call it) "register" that has > been informed of Linux time at the start of WSJT-X execution. > 2 Guess: Perhaps the register does not contain enough bits for holding > Linux time and when the register reaches maximum count it overflows and > resets to 000000... (But time jumping ahead does not agree with > this prediction because a reset would be backwards.) > 3 The delta of 6 seconds is a clue to how many counts are missed at the > least significant bits end of the register. > 4 In the code someone left out a CONST declaration. Etc. > 5 It's a fixable bug. > 6 WSPR code was at least partially written by someone different from the > other code(s) so that declarations of variables are different. > 7 Or it's caused by some other "bug". A family tree of possible bugs > is larger than what I am imagining. See 5. > 8 I am probably be wrong again. :) > > I could subscribe to the Digest. But maybe I don't want that much email. > > --Glenn, AF8C > > On 5/24/2025 5:26 PM, Paul Simon via wsjt-devel wrote: > > On 5/23/2025 9:16 AM, Josh Rovero via wsjt-devel wrote: > >> I see similar behavior about every 72 hours or so on Fedora Core 41, > >> 64-bit. > >> > >> Restarting wsjtx seems to cure it for another 72 hours .. > >> > >> Josh Rovero > >> KK1D > >> > > > > ------------------------------------------ > >> > >> I have been running wspr 24/7 using the linux version of wsjtx. > >> After > >> about two days, dt seems to increase by 6 seconds, in a single jump, > >> not > >> gradually. This does not happen on Windows. > >> > >> 1. The same happens on two different machines running Ubuntu and > >> Mageia,v 2.61 and v 2.7.0-rc8. > >> > >> 2. Computer clock is correct: checked vs. time.is <http://time.is>, > >> NIST controlled > >> clock, etc. Time measured manually is within one second. > >> > >> 3. Closing and reopening wsjtx immediately results in correct dt. > >> > >> 4. Running wsjtx under WINE gives same result. > >> > >> 5. Waterfall timing is correct and can see the six second early > >> start of > >> sequence. > >> > >> 6. Only happens if transmit box is ticked. > >> > >> Could someone please confirm and/or suggest possible solutions? > >> > >> Paul W6EXT > >> > > > > --------------- > > Well, good luck Josh. No response from anyone else. No developers > > either. Some of the links on the SourceForge pages are dead. One of the > > SourceForge pages states that WSPR is of historical interest. > > > > > > "So Long, and Thanks for All the Fish" > > > > Paul, W6...@ar... > > > > > > > > > > > > > > > > > > _______________________________________________ > > wsjt-devel mailing list > > wsj...@li... > > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > -- > This email has been checked for viruses by Avast antivirus software. > www.avast.com > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > |
|
From: Reino T. <rei...@ko...> - 2025-05-26 05:46:49
|
Welcome Nic to the discussion. The program is an open source one and all information is available for you to study it to the bottom. As far as I have noted it is a Linux related problem. At least: “Message: 1 Date: Thu, 22 May 2025 15:31:13 -0700 From: Paul Simon <mailto:ps...@so...> To: mailto:wsj...@li... Subject: [wsjt-devel] wsjtx wspr#dt error Message-ID: <100o8jh$ju5$mailto:1...@ci...> Content-Type: text/plain; charset=UTF-8; format=flowed I have been running wspr 24/7 using the linux version of wsjtx. After about two days, dt seems to increase by 6 seconds, in a single jump, not gradually. This does not happen on Windows." States so. I have not seen any details how WSPR is set for transmission, see user guide (10.) WSPR Mode. E.g. is the transmission continuous or is there also reception periods, and is a Band Hopping used or just a single band? With your expertise it would nice, if you could spend some time for a study session about the "memory leak" assumption. 73, Reino OH3mA |
|
From: Paul S. <ps...@so...> - 2025-05-26 19:38:47
|
Gentlemen, Thank you all for your responses. To move this along, my responses: Alan G0TLK Linux time jumps: From what I have Googled, the magnitudes are very large and seem to be reversible. Also, the system time stays correct, and the horizontal line separating two minute sequences is always at the correct time. Restarting WSPR periodically might work except that ticking the transmit button turns off at the second sequence after startup. Another bug. I think finding the bug is more important and your suggestion would work if the above bug were also solved. Comment 3. Has problem arisen running FT8? Not as far as I know. I got one response from Josh, KK1D, who wrote that he observed similar behavior every 72 hours on Fedora Core 41, 64 bit. Restarting runs another 72 hours. Comment 4. Does this happen on machines with different motherboards and/or different processors? Yes, it does. Josh’s comment as well as I have run it with a HP laptop and my own, Intel Core i7-8700, ASUS Z370 mb and 16 Gb memory. Glen, AF8C Yes, I agree. I think there is a register/variable that overflows at some point. Perhaps the six seconds, is the +/- limit for decoding and at some cumulative point it does a six second shift. If this is the case, the register should reset at some point and not continue to accumulate and “overflow” so to speak. Nic, G3YEG Memory leak problem? See above. It could be but the bug would have to found before we could make that conclusion. Reino, OH3MA Yes, as far I have tested, it is a Linux only problem. It does not appear on my windows laptop. The transmission is not continuous, about 30 per cent. I can only tell on receive as that is the only place I can see DT. Perhaps someone could check me at their QTH. WSPR is currently running on windows, so no error. The error occurs with band hopping as well as on one band only. I hope our suggestions can lead to a solution. There is another minor bug that I have found but we can discuss it another time. WSPR seems to be the orphan of WSJTX. Paul, W6EXT |
|
From: Reino T. <rei...@ko...> - 2025-05-27 08:40:59
|
Paul, Thanks for detailed answers to the questions. May I ask further clarification what's happening. You said earlier: "5. Waterfall timing is correct and can see the six second early start of sequence." Do you mean early start of the transmission sequence? Can you still decode other transmissions after that instance? I try to figure out whether only the transmission timing is starting too early or both transmission and reception. Do you see your transmissions on wspr.live? I am not used it myself and could not spot W6EXT at all but may be my fault. You could use it to monitor your transmissions. "6. Only happens if transmit box is ticked." That may be an answer, but are also receptions stepped six seconds? I assume not as you say that the waterfall timing is correct. I mean also after the instance. By the way FST4W beacon mode is more advanced than WSPR providing 1.8 dB better performance in 120 s sub-mode. It also can send all information in a single message. For some reason on some bands WSPR is still used more than FST4W. Perhaps the reason is a bit more complex waveform of the 4-GFSK with smooth frequency transitions requiring a bit more complex frequency controls of frequency synthesizers. 73, Reino OH3mA |
|
From: Glenn W. <af...@al...> - 2025-05-31 03:15:48
|
I was inspired to "get with the program" (pun intended) to ask for opinions on the 6-second jump problem. The way I did that was to ask https://grok.com/ (Artificial Intelligence) some questions about system time and WSJT-X. In one of the requests I accidentally hit the Enter key too soon but what Grok came back with was many pages of good critique. Not bad by itself. All three critiques are in https://hamfaqs.com/wsjtx/ to prevent having that much email here. Non-programmers will be happy about that. -Glenn, AF8C On 5/25/2025 8:23 AM, Glenn Williams via wsjt-devel wrote: > Evidence: > 1 Linux time is always correct and advances monotonically. > 2 Restarting WSJT-X for WSPR fixes the problem. > 3 No one has mentioned this about WSJT-X running, for example, FT8. (?) > 4 But does this happen on machines that run different motherboards and > or processors (i.e. Intel vs AMD vs ARM)? At least we know that it > happens with different flavors of Linux. > > Conclusions: > 1 Inside the WSPR code there is a (let's call it) "register" that has > been informed of Linux time at the start of WSJT-X execution. > 2 Guess: Perhaps the register does not contain enough bits for holding > Linux time and when the register reaches maximum count it overflows and > resets to 000000... (But time jumping ahead does not agree with > this prediction because a reset would be backwards.) > 3 The delta of 6 seconds is a clue to how many counts are missed at the > least significant bits end of the register. > 4 In the code someone left out a CONST declaration. Etc. > 5 It's a fixable bug. > 6 WSPR code was at least partially written by someone different from the > other code(s) so that declarations of variables are different. > 7 Or it's caused by some other "bug". A family tree of possible bugs > is larger than what I am imagining. See 5. > 8 I am probably be wrong again. :) > > I could subscribe to the Digest. But maybe I don't want that much email. > > --Glenn, AF8C > > On 5/24/2025 5:26 PM, Paul Simon via wsjt-devel wrote: >> On 5/23/2025 9:16 AM, Josh Rovero via wsjt-devel wrote: >>> I see similar behavior about every 72 hours or so on Fedora Core 41, >>> 64-bit. >>> >>> Restarting wsjtx seems to cure it for another 72 hours .. >>> >>> Josh Rovero >>> KK1D >>> >> >> ------------------------------------------ >>> >>> I have been running wspr 24/7 using the linux version of wsjtx. >>> After >>> about two days, dt seems to increase by 6 seconds, in a single jump, >>> not >>> gradually. This does not happen on Windows. >>> >>> 1. The same happens on two different machines running Ubuntu and >>> Mageia,v 2.61 and v 2.7.0-rc8. >>> >>> 2. Computer clock is correct: checked vs. time.is <http://time.is>, >>> NIST controlled >>> clock, etc. Time measured manually is within one second. >>> >>> 3. Closing and reopening wsjtx immediately results in correct dt. >>> >>> 4. Running wsjtx under WINE gives same result. >>> >>> 5. Waterfall timing is correct and can see the six second early >>> start of >>> sequence. >>> >>> 6. Only happens if transmit box is ticked. >>> >>> Could someone please confirm and/or suggest possible solutions? >>> >>> Paul W6EXT >>> >> >> --------------- >> Well, good luck Josh. No response from anyone else. No developers >> either. Some of the links on the SourceForge pages are dead. One of >> the SourceForge pages states that WSPR is of historical interest. >> >> >> "So Long, and Thanks for All the Fish" >> >> Paul, W6...@ar... >> >> >> >> >> >> >> >> >> _______________________________________________ >> wsjt-devel mailing list >> wsj...@li... >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > -- This email has been checked for viruses by Avast antivirus software. www.avast.com |
|
From: Paul S. <ps...@so...> - 2025-05-29 19:59:00
|
Hello Reino, Thanks very much following up. I will do my best to answer your questions. Feel free to ask for more clarification as needed. Number 5. I am not sure whether or not I saw both rx and tx early on the waterfall. I will have to wait and look again. I do know that the 6 second early dt shows up in the station received list. I have seen the delay but not sure if it was one or the other or both rx and tx. I took a look at wspr.live and could not really figure out how to use to check my own transmitted signal. I’m very familiar with using databases and did some consulting after I retired, but the whole interface to wspr.live is not clear to me. The advantage would be I could see the dt received by other stations. I don’t know how they get it as it is not sent to wspr.net. I was hoping that someone else would hear my signal and be able to report the dt to me. I don’t know if you can hear me on wspr. I run only 500 mw but could easily raise it. The xmit power is quite accurate I believe as I am using an LP-100a to set it. Number 6. I’m not quite sure I understand you question. I can only record dt on received signals and it is not on wspr.net. There are horizontal lines on the waterfall on the even minutes with the band displayed at the left. Those lines are timed correctly with respect to the system clock, but the sequences I receive (and transmit?) are not. Again, I don’t know if it is only rx or tx but the early start is clearly visible on the waterfall. I don’t know much about FST4W. Is it rx only from particular beacons? I still would need to get dt from both tx and rx. Finally, I am pretty sure this is a software bug. It is as if there is a variable/register that accumulates dt offsets and at six seconds adds a shift of six seconds to the received dt. I would not be surprised if it added another six seconds after another two days. I’m not that good a programmer to dig into wsjtx, besides I am 86 and would rather spend the time doing other things. Thanks again and 73 Paul |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X