Re: [wsjt-devel] Response to CQ ignored
> On Jan 30, 2024, at 04:45, Uwe, DG2YCB via wsjt-devel > wrote: > > At the moment, I have no explanation why it doesn't work with the "231202" i+ > version. What I can say is that it definitely works well with the current > "240106" code, as well as with the new "240202" version that will be released > on Friday this week. I recommend that you download this version on Friday and > then see whether the error persists or not. This version will also bring a > few nice new features, which I'll explain in the following video: > https://www.youtube.com/watch?v=1CqyIGRjbvs > > 73 de DG2YCB, > Uwe Hi Uwe, I haven’t taken a lot of time to gather surrounding data, but can say I’ve run into this many times. It is usually following an operation where I changed bands or modes. It would ignore replies to my first CQ. My “cure” is to double click the response and work the guy. Immediate followup CQs are answered as they are supposed to and it works for a long time after. I’m using 24/01/06. I cannot repeat the problem, as it seems random under the mentioned conditions. Since it only holds me up a few seconds, I haven’t dig deeper. I’m not sure whether it did similar in other recent versions or not. Will also update Friday when it comes out. Love the software! 73, Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Error with Watchdog Timer in FT8 Mode
> On Dec 3, 2023, at 09:22, Tim Goeppinger via wsjt-devel > wrote: > > In the band activity window "3B8CW N6GP DM13" was highlighted in red.When > I hit the "Enable Tx" button, my rig would not go into transmit mode. Had to > restart WJST-x to try again. Sounds normal. The timer has timed out, so you need to reinitiate. To call that station, just double click that line where he is calling you. This happens regularly when someone calls after you’ve run out of time. Gary - - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] FT8 on 160m with Beverage antenna
> On Nov 13, 2023, at 14:38, Dennis W1UE via wsjt-devel > wrote: > > beverage antenna will often produce weaker signals than, say, an inverted L. > However, it will decrease the noise on the signal, and make it easier to > copy, which > should make it easier to decode. Going a step further, it should also increase the signal to noise ratio due to the gain of that antenna in the desired direction and the loss of noise signal in the other directions. Remember, signal strength is not what WSJT-X is reporting. It is the strength of the decoded signal over the overall noise. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] CQ Hound mode
> On Nov 5, 2023, at 13:08, Pino Zollo via wsjt-devel > wrote: > > Just an idea: > > When in Hound mode the DX station should call as: > > CQH DX0CALL GRID > > or > > CH DX0CALL GRID But why? He should only be hound if he is on his published frequency (which you can determine yourself), and he should never be in hound mode if he is in the normal FT frequency segment. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] No 73 allowed after RR73?
> On Oct 21, 2023, at 16:04, Andrew Neumeier via wsjt-devel > wrote: > > If I am working a very weak station, and that station chooses to use RR73 > instead of 73, there > is a good chance that I have not received it, especially if I am waiting for > a qsb peak on the signal. And that’s why RR73 isn’t supposed to be used on weak signal work. Specifically, RR73 is for use when a repeat transmission will not be called for. QSB should obviously negate that thought. That said, I sometimes send RR73 when I don’t mean to because I moved off of a stable band to one that is questionable and don’t realize it (not think to check it). It only happens once, as I noticed it immediately and make the change before the next contact. 73, Gary ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib 4.5.2 test #hamlib
Sorry for the omission, Mike. Same version as previous. Running RC5 since it came out. > On Dec 20, 2022, at 21:23, Black Michael via wsjt-devel > wrote: > > What version of WSJT-X do you have? I'm running 2.6.0-rc5 and can switch > from FT8 to FT4 and back without a problem. > > Hamlib is not involved in decoding at all. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Hamlib 4.5.2 test #hamlib
> On Dec 20, 2022, at 17:13, Dennis Younker NE6I via wsjt-devel > wrote: > > Hamlib 4.5.2 is due to be released this week. > All known bugs have been fixed. I don’t remember if this was Hamlib problem, or something else, but the decode problem has risen its head again on my system. I comment on it before when the search expanded not long ago. If i switch from FT8 to /FT4 using the front panel buttons, decode stops. Audio shows on waterfall and incoming audio “meter” graph on the left, but no decode. It is NOT happening every time, but frequently in the last few days. Win 10 on an I7 older machine with lots of ram. As before, closing X and reopening, cures the problem. Reloads operating just fine. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RC4 crashes
> On Nov 23, 2022, at 21:58, Black Michael via wsjt-devel > wrote: > > Would that switch to FT4 be occurring while decodes are still appearing on > the screen? Probably while or before decodes are happening, since they come so fast with heavy activity. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] RC4 crashes
> On Nov 23, 2022, at 13:54, Michael Black via wsjt-devel > wrote: > > Known bug if you are using max dust or call first. It’s fixed for RC5. > Mike W9MDB One more confirmation from my station, Mike. As previously stated, it is very repeatable. Go up on 17, 12, or 10 meters (probably any other band too, but this is where I’ve tested). Let it monitor the FT8 segment for a period of time, say several sequences. The. hit the quick button to go to FT4. The blue decode button lights and stays lit (stuck). from that time on, there are no decodes on the screen. Waterfall looks great, just no decoding. Of course, we’re assuming the band is open, as it has been, and there’s lots of traffic. To recover, hit the corner X and close the program. Open it right back up and go to FT4. All is well again. Note, I have NOT tested by changing modes using the menu. That’s on my list of things to do. Any idea when RC5 will break loose? Thank you, Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Program crash
> On Oct 24, 2022, at 11:46, Tony ZL3HAM via wsjt-devel > wrote: > >> I'm running Ver 2.6.0-rc4 on Windows 11 Pro and the program has just crashed >> for the second time and it needed a PC reboot to restore. At the time I was >> on 20m FT4 after having a few QSO's and it crashed whilst in listening mode. I caught this post and was about to make one similar, so I’ll jump into the thread. Two times in one week, I had what seemed to be a repeatable crash. I’ve only done it twice, so can’t guarantee duplication at this time. Running RC4 since it came out. Except during poor weather conditions, where I might expect lightning, I leave the rig running 24/7 and almost always monitoring an active band. During the day, it is on 10 meters, since it is open daily now, and at night, it monitors 17 meters because it has activity on it almost all night. There are exceptions, of course. Between those times, I may have it on 15 (seldom) or 12 meters. In both of the recent cases, I had gotten up in the morning and monitored the mentioned upper bands and gotten on the air about mid-morning. I’ve been doing around 1-2 contacts per minute lately (FT4), and have fun keeping it going with no breaks. Sometime after maybe 10am (after a few hours of on air operation), the program just closed unceremoniously. In both cases, I was running a string of rapid contacts. Computer is an I7 with 24gig of memory, Win 10. Two browser copies open, with 5 or 6 tabs open in each. RF is not an issue. Logging software is RumLog, running separately on a Mac. Prior to this period, I had never had this sort of un-commanded shutdown, even in RC1, 2, or 3. I had to use task manager to get rid of jt9.exe. Restarting WSJT-X after that brought things back to normal again as far as I know. WSJT-X is restarted now and then when things settle down, just on principle. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Possible RC4 issue
> On Sep 18, 2022, at 22:32, Reino Talarmo via wsjt-devel > wrote: > > This may be irrelevant, but how you returned from FT4 to FT8 to work the > single station? Reino, Sorry, I forgot to respond to this. I was only doing the mode change with the new mode buttons, not the mode drop down. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Possible RC4 issue
> On Sep 18, 2022, at 22:32, Reino Talarmo via wsjt-devel > wrote: > > This may be irrelevant, but how you returned from FT4 to FT8 to work the > single station? > >> When I tried to restart WSJT-X, it failed, giving me the following error: > Sub Process Error > Failed to close orphaned jt9 process > > The failure reason is solely due to the orphaned jt9 (jt8.exe) process that > is the main engine for decoding within wsjt-x, I think. You could have also > kill the process (jt8.exe) using Windows Task Manager. Normally that is > enough and no need to reboot the total system. Will try to remember that, but I will be surprised if it happens again. ;-) Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Possible RC4 issue
> On Sep 18, 2022, at 21:25, Black Michael via wsjt-devel > wrote: > > About how long were you running when this happened? If by “running” you mean the program was loaded and running, it runs 24/hrs a day. Since we are in lightning storm season, it was probably shut down and restarted the night before. As for actually working people, probably no more than 10 minutes when I walked into the shack. Before that, it was just monitoring the band. By the way, it has again run trouble free since last night, so still may be a one-off deal. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
[wsjt-devel] Possible RC4 issue
I seldom report problems that I might have because I don’t usually have enough notes on all the details, but this one seemed serious enough that I’ll tell you what I know about it. Can I duplicate? Of course not, yet. I’ve been using RC4 since it came out, so it's likely a one-off event. I’ve not had previous problems. I was on 17M FT8, made a few contacts with no problem. After the last one logged, I hit the FT4 button and jumped up the band as I frequently do when things are busy. I worked one station on FT8 and logged it. After it logged, the program simply closed itself - gone. When I tried to restart WSJT-X, it failed, giving me the following error: Sub Process Error Failed to close orphaned jt9 process I am very familiar with the jt9 task error, and haven’t had one for a long time, but I think this is the first time I’ve had the process error. WXJT-X did not load. When I clicked on the error to close it, it was replaced by a second one that said simply: Fatal error Sub-process error Acknowledging that one closed the error message & it went away. Any time I tried to repeat the reloading of WSJT-X, the same errors popped up. In order to get it back up and running, I had to reboot the system entirely. It seems to be running smoothly since then, as it had before. I suspect everything is fine and this was just a glitch. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Linux alert woes
> On Sep 7, 2022, at 13:29, Jody Barefoot via wsjt-devel > wrote: > > So I was wondering if the developers of WSJT-X would consider incorporating > the same kind of simple beep alerts that JTDX has. Sorry, brain didn’t register the Linux comment. I’ll crawl back in the hole. Apologies. Gary ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Linux alert woes
> On Sep 7, 2022, at 13:29, Jody Barefoot via wsjt-devel > wrote: > > So I was wondering if the developers of WSJT-X would consider incorporating > the same kind of simple beep alerts that JTDX has. That way we can add more beeps and boops to the Windows garbage that people are spewing out on the band when they don’t know how to properly configure their audio. Sorry, I think the program should remain quiet, as should all of them when running digital modes. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Watchdog timer for F/H?
> On Jul 28, 2022, at 14:04, Richard V Zwirko via wsjt-devel > wrote: > > Comments? You’re talking about defeating the timer, which is there for a reason. If you aren’t getting a response from the other station, give it a break and let someone else have a bit of a chance before you “reset” the timer. In early documentation on the subject, it was explained. 73, Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] SUGGESTION
> On Mar 6, 2022, at 02:56, Alan via wsjt-devel > wrote: > > it's an important feature because many XCVR's do not offer this function in > a simple manner. Put the radio in CW mode and lock the key. Simple. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] SUGGESTION
> On Mar 5, 2022, at 21:19, Gavin ZL3GAV via wsjt-devel > wrote: > > With the TUNE button, can this be limited to timeout at 10 seconds maximum > please? > > From experience, we all make silly mistakes, whilst tuning my FT-991A I got > distracted, with the result, I nuked the radio (since fixed)running on full > power on TUNE. It is not a pleasant experience the acrid smell of burning > electronic components! A much simpler way to get around it is to be sure you always have MONITOR turned on. You should be monitoring your output audio quality anyway. It will give you immediate notification when it is either locked on or forgotten. It doesn’t need to be loud, but if you can hear it, it will let you know it is still on. Also, most radios these days have a timeout timer that you can set for maximum transmit time. Set that to save the transmitter from destroying itself, or QRMing the rest of the people on the band. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] QSO 15 meters FT8 F/H not logged!
> On Feb 19, 2022, at 14:51, Grant VK5GR via wsjt-devel > wrote: > > As for how to ID exactly what mode they are running…. Let’s be clear. You’re not talking about MODEs here. Logged mode is till FT8. You’re talking about protocol or format. The mode is still FT8. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Question FT8
> On Oct 4, 2021, at 13:09, Andrew Neumeier via wsjt-devel > wrote: > > This is a different situation than working strong signals on HF, where I > rarely operate FT8, so my experience is different. So, when another station > sends 73, and my station does not automatically respond, I'll just have to do > that manually. And this is the problem, Andy…. All of these modes were started on VHF. After FT8 had been on the air a short time, some people decided to try it out on HF. By the way, there wasn’t a bunch of whining about too many sequences on HF wen it started. People were happy to run it as it was, and it worked quite well. The more people got into it, the more there started to be this strange desire to make things go faster. Contests, etc., just made it worse. I would guess that the majority of the people on these modes now don’t know a thing about using them on six or two meters. All you hear now is faster, faster, FASTER! Good grief! As I posted months ago, why not just get the phone out and see how fast you can call your ham buddies and log contacts. What’s happened to ham radio? What is the hurry? I know - unpopular opinion right now, but I know I’m not the only one. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Question, FT8
> On Oct 4, 2021, at 07:18, Neil Zampella via wsjt-devel > wrote: > > When you send RR73, when the Tx Enable turns off, the operator has the OPTION > to click it back on, select the Tx5 message, and have it go out. > > See ... already implemented. Just takes TWO clicks. Yep, takes probably a half a sequence to figure out those steps and get it done. By then, it won’t decode and you have to wait until the next cycle. Ridiculous waste of time. Just default it to send. It takes ONE click to kill it if it isn’t needed! Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Possible feature request, time skew notification?
> On Jul 18, 2021, at 09:26, Carey Fisher via wsjt-devel > wrote: > > If you simply look at the waterfall, it's clearly obvious whether your clock > is off or not. You and George are correct. Simply looking at the waterfall will get you within the two seconds required. After that, the df will give you all you need over a couple minutes time of monitoring. If you run your waterfall so narrow that you can’t tell, you merely need to expand it for a few minutes. I’ve seen some postings that show some people run their waterfall so narrow (vertically) that they can’t tell a thing about the timing or quality of incoming signals. That’s the cost of setting up that way. Use the tools within the program itself. Gary - AG0N ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
