wsjt-x-improved-community Mailing List for wsjt-x_improved
Brought to you by:
dg2ycb
Menu
▾
▴
wsjt-x-improved-community — Support & Discussion
You can subscribe to this list here.
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
(12) |
Dec
(31) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2023 |
Jan
(35) |
Feb
(8) |
Mar
(12) |
Apr
(14) |
May
(81) |
Jun
(34) |
Jul
(70) |
Aug
(91) |
Sep
(38) |
Oct
(76) |
Nov
(43) |
Dec
(39) |
| 2024 |
Jan
(20) |
Feb
(67) |
Mar
(57) |
Apr
(44) |
May
(61) |
Jun
(6) |
Jul
(224) |
Aug
(229) |
Sep
(136) |
Oct
(93) |
Nov
|
Dec
|
|
From: Chris R. <chr...@ch...> - 2024-10-19 14:35:39
|
On 18/10/2024 23:23, Black Michael wrote: > If your rig was set to 24.915 you could not have decoded anything at 24.911 (4KHz below -- that's impossible). Yes of course. WSJT-X has put the incorrect Rx frequency in ALL.TXT and reported it incorrectly to PSKReporter. > > There were some recent changes to try and prevent this when people start twiddling knobs but not sure it covers your situation. I'd downloaded and installed the latest version about 10 minutes before. It is reported in PSKReporter, hopefully correctly. If you don't believe me, try it. It isn't difficult to reproduce. Chris, G5CTH > > Mike W9MDB > > > > > > > > > > > On Friday, October 18, 2024 at 10:58:03 AM CDT, Chris Rowland<chr...@ch...> wrote: > > > > > > > Here's an example of what my ALL.TXT shows: > > > > > // The rig is set to 24.911 and receiving PX0FF using that frequency. WSJT-X was set to 24.915 > > > 241018_154200 24.915 Rx FT8 9 0.1 524 CQ PX0FF HI36 > > // I call PX0FF on 24.911.806 > > > 241018_154215 24.911 Tx FT8 0 0.0 806 PX0FF G5CTH IO91 > 241018_154230 24.915 Rx FT8 11 0.1 524 G5CTH PX0FF +10 // actually 24.911.524 > 241018_154245 24.911 Tx FT8 0 0.0 806 PX0FF G5CTH R+11 > 241018_154300 24.915 Rx FT8 5 0.1 524 G5CTH PX0FF RR73 // they are pretty good at responding > 241018_154300 24.915 Rx FT8 5 0.1 584 F8FUA PX0FF +30 > 241018_154315 24.911 Tx FT8 0 0.0 806 PX0FF G5CTH 73 > 241018_154330 24.915 Rx FT8 10 0.1 524 F8FUA PX0FF RR73 > 241018_154400 24.915 Rx FT8 6 0.1 524 CQ PX0FF HI36 > > // I set WSJT-X to 24.911 using the frequency table. > > > 241018_154415 24.911 Rx FT8 -4 0.2 1953 PX0FF SV8DAW KM27 > 241018_154415 24.911 Rx FT8 -9 0.6 745 PX0FF DL1JCI JO60 > 241018_154430 24.911 Rx FT8 3 0.1 524 DL1JCI PX0FF +13 > 241018_154430 24.911 Rx FT8 3 0.1 584 SV8DAW PX0FF +17 > 241018_154445 24.911 Rx FT8 -5 0.2 1953 PX0FF SV8DAW R-01 > 241018_154500 24.911 Rx FT8 6 0.1 524 DL1JCI PX0FF RR73 > > > > > It looks as if the rig frequency isn't reported for Rx but is for Tx. There should be enough clues here to help fix it. > > > > > Chris, G5CTH > > > > > > > > > On 18/10/2024 16:19, Chris Rowland wrote: > > >> > On 18/10/2024 15:45, WB5JJJ wrote: > > >> >> own on the standard frequencies when the DXP is actually running F/H or SF/SH on a non-standard frequency. Looks like some guys might not have their radio connected to a computer for CAT controls. >> > This is not the case. The example I showed was a report by me (G5CTH). My 7300 is under CAT control and WSJT-X was showing the correct frequency. Is WSJT-X reporting the correct frequency to PSKReporter? > > A couple of things: > > ALL.TXT has the wrong frequency, 28.074, not what I was using and was displayed on the display of the rig and WSJT-X - 28.078. > > I set 28.078 by tuning using the control on my IC-7300, not through WSJT-X. WSJT-X read the frequency I set and displayed it correctly. > > Perhaps that helps, I think WSJT-X should be consistent. If it's going to ignore the frequency set on the radio it shouldn't display it. > > Chris, G5CTH > > > > > > > > _______________________________________________ > Wsjt-x-improved-community mailing list > Wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community > > > > > _______________________________________________ > Wsjt-x-improved-community mailing list > Wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community |
|
From: Uwe, D. <dg...@gm...> - 2024-10-19 11:34:03
|
Hi Jürgen, You can/must do this yourself. Please follow this link: https://sourceforge.net/projects/wsjt-x-improved/lists/wsjt-x-improved-community/unsubscribe 73 de DG2YCB, Uwe ________________________________________ German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: dg...@gm... Info: www.qrz.com/db/DG2YCB Am 19.10.2024 um 13:27 schrieb dh1bbh--- via Wsjt-x-improved-community: > Please remove the address “dh...@ic... > <https://mailto:dh...@ic...>” from the mailing list. I get all > the information twice because I am also registered via “dh...@da... > <https://mailto:dh...@da...>” > > vy73 Jürgen, DH1BBH > > > _______________________________________________ > Wsjt-x-improved-community mailing list > Wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community |
|
From: <dh...@ic...> - 2024-10-19 11:28:25
|
Please remove the address “dh...@ic...” from the mailing list. I get all the information twice because I am also registered via “dh...@da...” vy73 Jürgen, DH1BBH |
|
From: Black M. <mdb...@ya...> - 2024-10-19 03:10:21
|
Are you using Hound or Super Hound? Hound mode should work but not Super.
On Friday, October 18, 2024 at 08:41:10 PM CDT, Dennis Younker <si...@ho...> wrote:
Chasing PX0FF the past couple of days, I noticed that if I have F/H Hound turned on, whether RX All Freqs is checked or not, I decode PX0FF and see him in the Band Activity window but not the RX Frequency window. Yes, the RX offset is set dead on to where I see him in the Band Activity window. Turning off Hound, all works normally in both windows. I am on v2.7.1-devel 241014-RC7-widescreen. I tried the previous version and had the same result. This seems to be something new for me as I didn't previously experience this problem. What am I doing wrong?
--Dennis NE6I_______________________________________________
Wsjt-x-improved-community mailing list
Wsj...@li...
https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community
|
|
From: Dennis Y. <si...@ho...> - 2024-10-19 01:38:06
|
Chasing PX0FF the past couple of days, I noticed that if I have F/H Hound turned on, whether RX All Freqs is checked or not, I decode PX0FF and see him in the Band Activity window but not the RX Frequency window. Yes, the RX offset is set dead on to where I see him in the Band Activity window. Turning off Hound, all works normally in both windows. I am on v2.7.1-devel 241014-RC7-widescreen. I tried the previous version and had the same result. This seems to be something new for me as I didn't previously experience this problem. What am I doing wrong? --Dennis NE6I |
|
From: Black M. <mdb...@ya...> - 2024-10-18 22:23:54
|
If your rig was set to 24.915 you could not have decoded anything at 24.911 (4KHz below -- that's impossible). There were some recent changes to try and prevent this when people start twiddling knobs but not sure it covers your situation. Mike W9MDB On Friday, October 18, 2024 at 10:58:03 AM CDT, Chris Rowland <chr...@ch...> wrote: Here's an example of what my ALL.TXT shows: // The rig is set to 24.911 and receiving PX0FF using that frequency. WSJT-X was set to 24.915 241018_154200 24.915 Rx FT8 9 0.1 524 CQ PX0FF HI36 // I call PX0FF on 24.911.806 241018_154215 24.911 Tx FT8 0 0.0 806 PX0FF G5CTH IO91 241018_154230 24.915 Rx FT8 11 0.1 524 G5CTH PX0FF +10 // actually 24.911.524 241018_154245 24.911 Tx FT8 0 0.0 806 PX0FF G5CTH R+11 241018_154300 24.915 Rx FT8 5 0.1 524 G5CTH PX0FF RR73 // they are pretty good at responding 241018_154300 24.915 Rx FT8 5 0.1 584 F8FUA PX0FF +30 241018_154315 24.911 Tx FT8 0 0.0 806 PX0FF G5CTH 73 241018_154330 24.915 Rx FT8 10 0.1 524 F8FUA PX0FF RR73 241018_154400 24.915 Rx FT8 6 0.1 524 CQ PX0FF HI36 // I set WSJT-X to 24.911 using the frequency table. 241018_154415 24.911 Rx FT8 -4 0.2 1953 PX0FF SV8DAW KM27 241018_154415 24.911 Rx FT8 -9 0.6 745 PX0FF DL1JCI JO60 241018_154430 24.911 Rx FT8 3 0.1 524 DL1JCI PX0FF +13 241018_154430 24.911 Rx FT8 3 0.1 584 SV8DAW PX0FF +17 241018_154445 24.911 Rx FT8 -5 0.2 1953 PX0FF SV8DAW R-01 241018_154500 24.911 Rx FT8 6 0.1 524 DL1JCI PX0FF RR73 It looks as if the rig frequency isn't reported for Rx but is for Tx. There should be enough clues here to help fix it. Chris, G5CTH On 18/10/2024 16:19, Chris Rowland wrote: > On 18/10/2024 15:45, WB5JJJ wrote: > > own on the standard frequencies when the DXP is actually running F/H or SF/SH on a non-standard frequency. Looks like some guys might not have their radio connected to a computer for CAT controls. > This is not the case. The example I showed was a report by me (G5CTH). My 7300 is under CAT control and WSJT-X was showing the correct frequency. Is WSJT-X reporting the correct frequency to PSKReporter? A couple of things: ALL.TXT has the wrong frequency, 28.074, not what I was using and was displayed on the display of the rig and WSJT-X - 28.078. I set 28.078 by tuning using the control on my IC-7300, not through WSJT-X. WSJT-X read the frequency I set and displayed it correctly. Perhaps that helps, I think WSJT-X should be consistent. If it's going to ignore the frequency set on the radio it shouldn't display it. Chris, G5CTH _______________________________________________ Wsjt-x-improved-community mailing list Wsj...@li... https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community _______________________________________________ Wsjt-x-improved-community mailing list Wsj...@li... https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community |
|
From: Chris R. <chr...@ch...> - 2024-10-18 15:56:26
|
Here's an example of what my ALL.TXT shows: // The rig is set to 24.911 and receiving PX0FF using that frequency. WSJT-X was set to 24.915 241018_154200 24.915 Rx FT8 9 0.1 524 CQ PX0FF HI36 // I call PX0FF on 24.911.806 241018_154215 24.911 Tx FT8 0 0.0 806 PX0FF G5CTH IO91 241018_154230 24.915 Rx FT8 11 0.1 524 G5CTH PX0FF +10 // actually 24.911.524 241018_154245 24.911 Tx FT8 0 0.0 806 PX0FF G5CTH R+11 241018_154300 24.915 Rx FT8 5 0.1 524 G5CTH PX0FF RR73 // they are pretty good at responding 241018_154300 24.915 Rx FT8 5 0.1 584 F8FUA PX0FF +30 241018_154315 24.911 Tx FT8 0 0.0 806 PX0FF G5CTH 73 241018_154330 24.915 Rx FT8 10 0.1 524 F8FUA PX0FF RR73 241018_154400 24.915 Rx FT8 6 0.1 524 CQ PX0FF HI36 // I set WSJT-X to 24.911 using the frequency table. 241018_154415 24.911 Rx FT8 -4 0.2 1953 PX0FF SV8DAW KM27 241018_154415 24.911 Rx FT8 -9 0.6 745 PX0FF DL1JCI JO60 241018_154430 24.911 Rx FT8 3 0.1 524 DL1JCI PX0FF +13 241018_154430 24.911 Rx FT8 3 0.1 584 SV8DAW PX0FF +17 241018_154445 24.911 Rx FT8 -5 0.2 1953 PX0FF SV8DAW R-01 241018_154500 24.911 Rx FT8 6 0.1 524 DL1JCI PX0FF RR73 It looks as if the rig frequency isn't reported for Rx but is for Tx. There should be enough clues here to help fix it. Chris, G5CTH On 18/10/2024 16:19, Chris Rowland wrote: > On 18/10/2024 15:45, WB5JJJ wrote: >> own on the standard frequencies when the DXP is actually running F/H >> or SF/SH on a non-standard frequency. Looks like some guys might not >> have their radio connected to a computer for CAT controls. > > This is not the case. The example I showed was a report by me > (G5CTH). My 7300 is under CAT control and WSJT-X was showing the > correct frequency. Is WSJT-X reporting the correct frequency to > PSKReporter? > > A couple of things: > > ALL.TXT has the wrong frequency, 28.074, not what I was using and was > displayed on the display of the rig and WSJT-X - 28.078. > > I set 28.078 by tuning using the control on my IC-7300, not through > WSJT-X. WSJT-X read the frequency I set and displayed it correctly. > > Perhaps that helps, I think WSJT-X should be consistent. If it's > going to ignore the frequency set on the radio it shouldn't display it. > > Chris, G5CTH > > > > _______________________________________________ > Wsjt-x-improved-community mailing list > Wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community |
|
From: Chris R. <chr...@ch...> - 2024-10-18 15:19:25
|
On 18/10/2024 15:45, WB5JJJ wrote: > own on the standard frequencies when the DXP is actually running F/H > or SF/SH on a non-standard frequency. Looks like some guys might not > have their radio connected to a computer for CAT controls. This is not the case. The example I showed was a report by me (G5CTH). My 7300 is under CAT control and WSJT-X was showing the correct frequency. Is WSJT-X reporting the correct frequency to PSKReporter? A couple of things: ALL.TXT has the wrong frequency, 28.074, not what I was using and was displayed on the display of the rig and WSJT-X - 28.078. I set 28.078 by tuning using the control on my IC-7300, not through WSJT-X. WSJT-X read the frequency I set and displayed it correctly. Perhaps that helps, I think WSJT-X should be consistent. If it's going to ignore the frequency set on the radio it shouldn't display it. Chris, G5CTH |
|
From: WB5JJJ <wb...@gm...> - 2024-10-18 14:45:56
|
I've also noticed that some DXP spots are shown on the standard frequencies when the DXP is actually running F/H or SF/SH on a non-standard frequency. Looks like some guys might not have their radio connected to a computer for CAT controls. 73's George - WB5JJJ HoIP - 100105 On Fri, Oct 18, 2024 at 8:30 AM Chris Rowland < chr...@ch...> wrote: > Something I've noticed is that some of the frequency reports in > PSKReporter seem to be incorrect. Sometimes the report has the standard > frequency while others have the actual frequency. I've now got a concrete > example of this: > > I've been chasing C91BV which is transmitting on 28.078.675. That's the > frequency I'm getting their signal. PSKReporter reports this as > "28.074.675". It's reporting the software as "WSJT-X v2.7.1-devel ial+". > > Other reports are correct, e.g "28.078.671 ... Using JTDX v2.2.160-rc7 > 8a3efc" so I don't think this is a PSKReporter issue. > > It Would Be Nice if the frequency was reported correctly. > > Chris, G5CTH > _______________________________________________ > Wsjt-x-improved-community mailing list > Wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community > |
|
From: Chris R. <chr...@ch...> - 2024-10-18 13:26:40
|
Something I've noticed is that some of the frequency reports in PSKReporter seem to be incorrect. Sometimes the report has the standard frequency while others have the actual frequency. I've now got a concrete example of this: I've been chasing C91BV which is transmitting on 28.078.675. That's the frequency I'm getting their signal. PSKReporter reports this as "28.074.675". It's reporting the software as "WSJT-X v2.7.1-devel ial+". Other reports are correct, e.g "28.078.671 ... Using JTDX v2.2.160-rc7 8a3efc" so I don't think this is a PSKReporter issue. It Would Be Nice if the frequency was reported correctly. Chris, G5CTH |
|
From: Hasan N. <hba...@gm...> - 2024-10-18 00:54:08
|
-12 is actually stronger than -15 SNR. On Thu, Oct 17, 2024, 7:48 PM WB5JJJ <wb...@gm...> wrote: > Today, I was using v1014 RC7 and playing around with YJ0VV on 10m as they > were occasionally in and mostly out, all afternoon. I went into this with > the mindset of previously some operators unhappy with the new procedure to > work the DXP. Some upset operators said they had their TX Timeout set to > 99 minutes so they could call for extended times in hopes of a miracle > connection while they were at Wal-Mart or dozing in their recliner. Of > course this potentially creates QRM the DXP SF station unnecessarily by not > listening first before calling. > > Of course, when I did copy YJ0VV, I could click on any of the reporting > lines (not the last two; OTP or verified) and DX Call was populated and I > was able to call them. Since I had worked them a couple days ago, I > immediately halted the TX, even though I had my power out turned down to > zero. > > When I did not see them for several minutes, I was still able to Enable TX > and begin calling them in the blind even though they had not displayed for > some time. As long as their call was still in the DX Call box, I was able > to do this even when I tried some 30 minutes later. An astute operator > could just click on Enable TX after the SH times out and effectively keep > calling blind forever, with minimal hands on effort on their part. > > To further avoid this blind calling, might the DX Call box be cleared when > the Super Hound icon goes from Green to Red, thus disabling the Enable TX > until the SF is again decoded, the icon turns green. Then clicking the DXP > callsign populates the DX Call box and allowing the Enable TX to function > once again? > > BTW, last night I was able to copy YJ0VV down to -12. Before I had been > limited to no less than -15. > > 73's > George - WB5JJJ > HoIP - 100105 > _______________________________________________ > Wsjt-x-improved-community mailing list > Wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community > |
|
From: WB5JJJ <wb...@gm...> - 2024-10-18 00:45:10
|
Today, I was using v1014 RC7 and playing around with YJ0VV on 10m as they were occasionally in and mostly out, all afternoon. I went into this with the mindset of previously some operators unhappy with the new procedure to work the DXP. Some upset operators said they had their TX Timeout set to 99 minutes so they could call for extended times in hopes of a miracle connection while they were at Wal-Mart or dozing in their recliner. Of course this potentially creates QRM the DXP SF station unnecessarily by not listening first before calling. Of course, when I did copy YJ0VV, I could click on any of the reporting lines (not the last two; OTP or verified) and DX Call was populated and I was able to call them. Since I had worked them a couple days ago, I immediately halted the TX, even though I had my power out turned down to zero. When I did not see them for several minutes, I was still able to Enable TX and begin calling them in the blind even though they had not displayed for some time. As long as their call was still in the DX Call box, I was able to do this even when I tried some 30 minutes later. An astute operator could just click on Enable TX after the SH times out and effectively keep calling blind forever, with minimal hands on effort on their part. To further avoid this blind calling, might the DX Call box be cleared when the Super Hound icon goes from Green to Red, thus disabling the Enable TX until the SF is again decoded, the icon turns green. Then clicking the DXP callsign populates the DX Call box and allowing the Enable TX to function once again? BTW, last night I was able to copy YJ0VV down to -12. Before I had been limited to no less than -15. 73's George - WB5JJJ HoIP - 100105 |
|
From: Hasan N. <hba...@gm...> - 2024-10-17 09:59:40
|
Jarmo, To the best of our knowledge, the specific program variant being used by YJ0VV is not known. Furthermore, there have been no "verified" reports emerging from a station running RC7. Therefore, it's prudent not to leap to conclusions. All accounts I've encountered regarding YJ0VV have indicated that when utilizing RC7, qsos with YJ0VV are not verified. There are many possibilities, but the least likely, according to your report, is that YJ0VV is using MSHV in conjunction with SuperFox, which results in a "verified" message when a station contacts him through RC7. (Unless the key granted by NCDXF works for MSHV as well.) It's highly improbable for a station running RC7 and communicating with YJ0VV, who is using MSHV and running RC7, to receive a 'verified' message from the server. It's more likely a misunderstanding of the message $VERIFY$... which is not an actual verification but rather a component of the verification process. Unless 'verified' appears as the final line in the sequence, it has not been verified, or your station has not configured RC7 correctly to display the 'verified' message. So, it is unknown what YJ0VV is really doing as what program they are running. They are definitely working people, those people are in the log. What software they are running remains unknown, it is not mentioned on their QRZ page. Also I find it strange that they would request a SuperFox key from NCDXF, be granted a key, and then run a rogue version of WSJT-X SuperFox that is actually generating 'verified' SF qsos. It is possible, I guess, that they are using the granted key inside MSHV, and it is not working right, or something else is amiss. ...but these days, anything is possible. 73, N0AN Hasan On Thu, Oct 17, 2024 at 1:55 AM jarmo <oh...@ni...> wrote: > Author of the MSHV have made new version > of the program. > It consists nw also SuperFox... Yj0vv running > it and qso confirmation seems quite intresting. > Again possibilty doing pirate qsos and with > robot mode. > > Jarmo, oh1mrr > > > _______________________________________________ > Wsjt-x-improved-community mailing list > Wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community > |
|
From: jarmo <oh...@ni...> - 2024-10-17 06:51:14
|
Author of the MSHV have made new version of the program. It consists nw also SuperFox... Yj0vv running it and qso confirmation seems quite intresting. Again possibilty doing pirate qsos and with robot mode. Jarmo, oh1mrr |
|
From: Uwe, D. <dg...@gm...> - 2024-10-16 19:59:12
|
Hi all, I have just carried out a few comparisons between SuperFox and old-style F/H with 2 instances of wsjt-x_improved 2.7.1-devel 241014-RC7 AL. Take a look at this, it really confirms the good performance of the SuperFox mode. First I adjusted the noise floor in a way that SNR -16 dB resulted for SF. Results: All transmissions could be decoded! Then I switched to old-style F/H mode (under the same conditions). Results: With NSlots=1 the old-style Fox signal could be decoded, of course, but was barely visible on the waterfall. So even the “visible” difference was less than expected. But already with NSlots=2, only approx. 30 to 50% of the transmissions could be decoded. And with NSlots=3, 4 or 5 there was no chance to decode anything! 73 de DG2YCB, Uwe ________________________________________ German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: dg...@gm... Info: www.qrz.com/db/DG2YCB |
|
From: Uwe, D. <dg...@gm...> - 2024-10-15 11:43:22
|
Hi all, Short information: Microsoft has just confirmed that the wsjt-x_improved installer does *not* meet any criteria for malware or potentially unwanted applications. *The false-positive detection has been removed.* Microsoft recommends following the steps below to clear cached detections and obtain the latest malware definitions: 1. Open command prompt as administrator and change directory to c:\Program Files\Windows Defender 2. Run “MpCmdRun.exe -removedefinitions -dynamicsignatures” 3. Run "MpCmdRun.exe -SignatureUpdate" This gives hope that the problem will resolve itself in the next few days. But we must not give in to any illusions. Next time false-positive alerts can occur again. And if it's not Microsoft, then someone else. Therefore, once again: In case of such virus alerts, please *contact the provider of your antivirus solution and upload the allegedly virus-infected file for analysis.* This is the only way we can get rid of these annoying false positives. 73 de DG2YCB, Uwe ________________________________________ German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: dg...@gm... Info: www.qrz.com/db/DG2YCB Am 15.10.2024 um 12:50 schrieb Uwe, DG2YCB via Wsjt-x-improved-community: > Carlos, > > Contact Microsoft anyway and give them the download URL. The problem > seems to be specific to Windows 11, by the way. > > 73 de DG2YCB, > Uwe > ________________________________________ > German Amateur Radio Station DG2YCB > Dr. Uwe Risse > eMail: dg...@gm... > Info: www.qrz.com/db/DG2YCB > > > Am 15.10.2024 um 12:48 schrieb C C: >> Virus detected, download blocked. >> Unable to send file to Microsoft. >> (Windows 11 - Microsoft Defender) >> >> Carlos >> ------------------------------------------------------------------------ >> *De:* Uwe, DG2YCB via Wsjt-x-improved-community >> <wsj...@li...> >> *Enviado:* segunda-feira, 14 de outubro de 2024 12:13 >> *Para:* Wsjt Improved <wsj...@li...> >> *Assunto:* [Wsjt-x-improved-community] False-positive virus warnings >> To all those who are confronted with messages that the downloaded >> installer file allegedly contains a virus: >> Please do me (and all of us) a favor, *contact the provider of your >> antivirus solution and upload the allegedly virus-infected file for >> analysis.* Every provider has a page for this. This is the only way >> we can get rid of these annoying false positives. >> As always, my installers do not contain any viruses. I even checked >> this again this morning. And SorceForge also scans all hosted files >> again for viruses. Unless you have fallen victim to an extremely rare >> man-in-the-middle attack, you can therefore assume with a probability >> bordering on certainty that the downloaded files are virus-free. >> >> 73 de DG2YCB, >> Uwe >> ________________________________________ >> German Amateur Radio Station DG2YCB >> Dr. Uwe Risse >> eMail: dg...@gm... <mailto:dg...@gm...> >> Info: www.qrz.com/db/DG2YCB <http://www.qrz.com/db/DG2YCB> >> >> > > > > _______________________________________________ > Wsjt-x-improved-community mailing list > Wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community |
|
From: Uwe, D. <dg...@gm...> - 2024-10-15 10:51:14
|
Carlos, Contact Microsoft anyway and give them the download URL. The problem seems to be specific to Windows 11, by the way. 73 de DG2YCB, Uwe ________________________________________ German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: dg...@gm... Info: www.qrz.com/db/DG2YCB Am 15.10.2024 um 12:48 schrieb C C: > Virus detected, download blocked. > Unable to send file to Microsoft. > (Windows 11 - Microsoft Defender) > > Carlos > ------------------------------------------------------------------------ > *De:* Uwe, DG2YCB via Wsjt-x-improved-community > <wsj...@li...> > *Enviado:* segunda-feira, 14 de outubro de 2024 12:13 > *Para:* Wsjt Improved <wsj...@li...> > *Assunto:* [Wsjt-x-improved-community] False-positive virus warnings > To all those who are confronted with messages that the downloaded > installer file allegedly contains a virus: > Please do me (and all of us) a favor, *contact the provider of your > antivirus solution and upload the allegedly virus-infected file for > analysis.* Every provider has a page for this. This is the only way we > can get rid of these annoying false positives. > As always, my installers do not contain any viruses. I even checked > this again this morning. And SorceForge also scans all hosted files > again for viruses. Unless you have fallen victim to an extremely rare > man-in-the-middle attack, you can therefore assume with a probability > bordering on certainty that the downloaded files are virus-free. > > 73 de DG2YCB, > Uwe > ________________________________________ > German Amateur Radio Station DG2YCB > Dr. Uwe Risse > eMail: dg...@gm... <mailto:dg...@gm...> > Info: www.qrz.com/db/DG2YCB <http://www.qrz.com/db/DG2YCB> > > |
|
From: C C <py...@ou...> - 2024-10-15 10:48:45
|
Virus detected, download blocked. Unable to send file to Microsoft. (Windows 11 - Microsoft Defender) Carlos ________________________________ De: Uwe, DG2YCB via Wsjt-x-improved-community <wsj...@li...> Enviado: segunda-feira, 14 de outubro de 2024 12:13 Para: Wsjt Improved <wsj...@li...> Assunto: [Wsjt-x-improved-community] False-positive virus warnings To all those who are confronted with messages that the downloaded installer file allegedly contains a virus: Please do me (and all of us) a favor, contact the provider of your antivirus solution and upload the allegedly virus-infected file for analysis. Every provider has a page for this. This is the only way we can get rid of these annoying false positives. As always, my installers do not contain any viruses. I even checked this again this morning. And SorceForge also scans all hosted files again for viruses. Unless you have fallen victim to an extremely rare man-in-the-middle attack, you can therefore assume with a probability bordering on certainty that the downloaded files are virus-free. 73 de DG2YCB, Uwe ________________________________________ German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: dg...@gm...<mailto:dg...@gm...> Info: www.qrz.com/db/DG2YCB<http://www.qrz.com/db/DG2YCB> |
|
From: Uwe, D. <dg...@gm...> - 2024-10-14 15:13:50
|
To all those who are confronted with messages that the downloaded installer file allegedly contains a virus: Please do me (and all of us) a favor, *contact the provider of your antivirus solution and upload the allegedly virus-infected file for analysis.* Every provider has a page for this. This is the only way we can get rid of these annoying false positives. As always, my installers do not contain any viruses. I even checked this again this morning. And SorceForge also scans all hosted files again for viruses. Unless you have fallen victim to an extremely rare man-in-the-middle attack, you can therefore assume with a probability bordering on certainty that the downloaded files are virus-free. 73 de DG2YCB, Uwe ________________________________________ German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: dg...@gm... Info: www.qrz.com/db/DG2YCB |
|
From: Uwe, D. <dg...@gm...> - 2024-10-14 13:31:18
|
I have now also created the following pdf documents, where you can read
everything about Rig Control errors again (in English and German):
* *How to deal with rig control errors?
<https://sourceforge.net/projects/wsjt-x-improved/files/How_to_deal_with_rig_control_errors.pdf/download>*
(in English)
* *Was tun bei Rig Control Fehlern?
<https://sourceforge.net/projects/wsjt-x-improved/files/Was_tun_bei_Rig_Control_Fehlern.pdf/download>***
(in German / Deutsch)
73 de DG2YCB,
Uwe
________________________________________
German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg...@gm...
Info: www.qrz.com/db/DG2YCB
Am 14.10.2024 um 14:33 schrieb Uwe, DG2YCB via Wsjt-x-improved-community:
> Hi all,
>
> As there are repeated questions about this, I would like to point out
> once again what to do if a rig control errors occurs.
>
> First of all, you need to distinguish whether you have connected your
> radio via Hamlib or not. *Hamlib* is used if you have selected one of
> the drivers named for your rig model in Settings/Radio/Rig (e.g. Yaesu
> “FT-991“ or “Icom IC-7300“). However, if you have selected *OmniRig*
> or*FLRig* or *Ham Radio Deluxe* or *DX Lab Suite Commander*, a
> different system is used. In such cases, please contact the developers
> of this software.
>
> *Hamlib* is constantly being developed further, as new rig models are
> being added and so on. It can also happen that new firmware versions
> require adjustments to Hamlib. The main developer is Mike W9MDB.
>
> In some cases it may happen that a Hamlib update does not (yet) work
> properly with your rig. Then *please always proceed as follows*:
>
> 1. *Make sure that your radio, your computer and the connection
> between the two are working properly. *
> 2. Also, *make sure that the unwanted effect is not caused by RFI* by
> reducing the transmission power to almost zero. Bear in mind that
> USB connections and computers in general are very sensitive to RFI!
> 3. *Update Hamlib to the latest version* via Settings/Radio/“Update
> Hamlib”. Check whether the error persists or not. If this fixes
> the error, you do not need to do anything else.
> 4. *If the error persists, click**in the Save menu**on Diagnostic
> mode and follow the instructions*: Restart the program, reproduce
> the error for some seconds, and close the program again. A new
> “logs” folder containing 2 files has now been created on the
> desktop of your computer. Email both files (particularly the file
> “WSJT-X_RigControl.log“) to Mike W9MDB for further analysis.
> 5. *If you are working on Windows**, Hamlib is located in a single
> DLL called “libhamlib-4.dll”,* which is located in the bin
> subfolder of your program installation path (usually
> c:\WSJT\wsjtx\bin\libhamlib-4.dll). You can replace this file
> yourself at any time (if the program is not running). *Just
> **replace it with an older one that you know has worked with your
> radio.* This way you can restore the functionality immediately.
> Very simple!
>
> Once again: Yes, *please report Hamlib errors!* This is the only way
> they can be fixed. However, there is no need to keep reinventing the
> wheel by turning every hamlib issue into a huge problem. Just follow
> the steps described above. Thank you for your understanding!
>
> 73 de DG2YCB,
> Uwe
> ________________________________________
> German Amateur Radio Station DG2YCB
> Dr. Uwe Risse
> eMail: dg...@gm...
> Info: www.qrz.com/db/DG2YCB
>
>
>
>
> _______________________________________________
> Wsjt-x-improved-community mailing list
> Wsj...@li...
> https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community
|
|
From: Black M. <mdb...@ya...> - 2024-10-14 13:01:17
|
FYI...FLRig is in Hamlib too. Fortunately the debug info is available for all rigs. There's no way for a user to distinguish between them and they really don't care. Mike W9MDB On Monday, October 14, 2024 at 07:35:46 AM CDT, Uwe, DG2YCB via Wsjt-x-improved-community <wsj...@li...> wrote: Hi all, As there are repeated questions about this, I would like to point out once again what to do if a rig control errors occurs. First of all, you need to distinguish whether you have connected your radio via Hamlib or not. Hamlib is used if you have selected one of the drivers named for your rig model in Settings/Radio/Rig (e.g. Yaesu “FT-991“ or “Icom IC-7300“). However, if you have selected OmniRig or FLRig or Ham Radio Deluxe or DX Lab Suite Commander, a different system is used. In such cases, please contact the developers of this software. Hamlib is constantly being developed further, as new rig models are being added and so on. It can also happen that new firmware versions require adjustments to Hamlib. The main developer is Mike W9MDB. In some cases it may happen that a Hamlib update does not (yet) work properly with your rig. Then please always proceed as follows: 1. Make sure that your radio, your computer and the connection between the two are working properly. 2. Also, make sure that the unwanted effect is not caused by RFI by reducing the transmission power to almost zero. Bear in mind that USB connections and computers in general are very sensitive to RFI! 3. Update Hamlib to the latest version via Settings/Radio/“Update Hamlib”. Check whether the error persists or not. If this fixes the error, you do not need to do anything else. 4. If the error persists, click in the Save menu on Diagnostic mode and follow the instructions: Restart the program, reproduce the error for some seconds, and close the program again. A new “logs” folder containing 2 files has now been created on the desktop of your computer. Email both files (particularly the file “WSJT-X_RigControl.log“) to Mike W9MDB for further analysis. 5. If you are working on Windows, Hamlib is located in a single DLL called “libhamlib-4.dll”, which is located in the bin subfolder of your program installation path (usually c:\WSJT\wsjtx\bin\libhamlib-4.dll). You can replace this file yourself at any time (if the program is not running). Just replace it with an older one that you know has worked with your radio. This way you can restore the functionality immediately. Very simple! Once again: Yes, please report Hamlib errors! This is the only way they can be fixed. However, there is no need to keep reinventing the wheel by turning every hamlib issue into a huge problem. Just follow the steps described above. Thank you for your understanding! 73 de DG2YCB, Uwe ________________________________________ German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: dg...@gm... Info: www.qrz.com/db/DG2YCB _______________________________________________ Wsjt-x-improved-community mailing list Wsj...@li... https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community |
|
From: Uwe, D. <dg...@gm...> - 2024-10-14 12:33:33
|
Hi all,
As there are repeated questions about this, I would like to point out
once again what to do if a rig control errors occurs.
First of all, you need to distinguish whether you have connected your
radio via Hamlib or not. *Hamlib* is used if you have selected one of
the drivers named for your rig model in Settings/Radio/Rig (e.g. Yaesu
“FT-991“ or “Icom IC-7300“). However, if you have selected *OmniRig*
or*FLRig* or *Ham Radio Deluxe* or *DX Lab Suite Commander*, a different
system is used. In such cases, please contact the developers of this
software.
*Hamlib* is constantly being developed further, as new rig models are
being added and so on. It can also happen that new firmware versions
require adjustments to Hamlib. The main developer is Mike W9MDB.
In some cases it may happen that a Hamlib update does not (yet) work
properly with your rig. Then *please always proceed as follows*:
1. *Make sure that your radio, your computer and the connection between
the two are working properly. *
2. Also, *make sure that the unwanted effect is not caused by RFI* by
reducing the transmission power to almost zero. Bear in mind that
USB connections and computers in general are very sensitive to RFI!
3. *Update Hamlib to the latest version* via Settings/Radio/“Update
Hamlib”. Check whether the error persists or not. If this fixes the
error, you do not need to do anything else.
4. *If the error persists, click**in the Save menu**on Diagnostic mode
and follow the instructions*: Restart the program, reproduce the
error for some seconds, and close the program again. A new “logs”
folder containing 2 files has now been created on the desktop of
your computer. Email both files (particularly the file
“WSJT-X_RigControl.log“) to Mike W9MDB for further analysis.
5. *If you are working on Windows**, Hamlib is located in a single DLL
called “libhamlib-4.dll”,* which is located in the bin subfolder of
your program installation path (usually
c:\WSJT\wsjtx\bin\libhamlib-4.dll). You can replace this file
yourself at any time (if the program is not running). *Just
**replace it with an older one that you know has worked with your
radio.* This way you can restore the functionality immediately. Very
simple!
Once again: Yes, *please report Hamlib errors!* This is the only way
they can be fixed. However, there is no need to keep reinventing the
wheel by turning every hamlib issue into a huge problem. Just follow the
steps described above. Thank you for your understanding!
73 de DG2YCB,
Uwe
________________________________________
German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg...@gm...
Info: www.qrz.com/db/DG2YCB
|
|
From: Uwe, D. <dg...@gm...> - 2024-10-14 05:51:06
|
Dear WSJT-X_IMPROVED Users,
For those who want the latest code: A new *241014-RC7* version of
wsjt-x_improved 2.7.1-devel is available for download. It brings the
following enhancements:
* Fixed the bug that "Enable Tx" was no longer stopped after
double-clicking on a message if TxFreq=RxFreq and the other station
replied to someone else.
* The GUI now prevents an incorrect Tx frequency from being set or
displayed in SuperFox mode when clicking on the waterfall or Tx Freq
spin box.
* Fixed an inconsistency that "Enable Tx" could not be activated in
some cases when SuperHound mode was previously set.
* Better compatibility with certain MSHV multi-stream messages when
your own callsign is a compound call.
* You can now use the Tab key on your keyboard to scroll through the
various fields in Settings/Filters.
* Fixed a bug that caused the displayed names of Territories 1 to 4 to
be retained until the program was restarted, even if they had been
deleted in Settings/Filters.
* The status of the "CQ only" checkbox is now saved and restored.
* Updated tooltip for the "BP" checkbox.
Of course, it also contains the corrections introduced with 241005 some
days ago:
* Fixed an inconsistency when using "Rig" as your method for Split
Operation. This mainly affected some Elecraft rigs.
* The program now prevents users in SuperHound mode from inadvertently
setting parameters that can lead to a subprocess error in the SF
decoder. (For those of you who don't want to update, don't set FTol
greater than 100 and stay away from the upper or lower limits of the
waterfall with the Rx frequency. Such settings make no sense in SF
mode anyway.)
* The text color of the “H” button is now white instead of red, which
improves readability when this button is activated.
* When in SuperHound mode and "Special operating activity to comments"
is checked, "SF/H mode" is now logged.
* Another attempt to solve the audio issues with some macOS versions.
This means that with *241014-RC7* all the minor inconsistencies in our
otherwise very well-functioning Release Candidate 7 should now be fixed.
The direct links for the 64-bit Windows installers are as follows:
* *wsjtx-2.7.1-devel-win64_improved_PLUS_241014-RC7.exe
<https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.1/wsjtx-2.7.1-devel-win64_improved_PLUS_241014-RC7.exe/download>*
(version with our good old WSJT-X GUI)
* *wsjtx-2.7.1-devel-win64_improved_AL_PLUS_241014-RC7.exe
<https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.1/wsjtx-2.7.1-devel-win64_improved_AL_PLUS_241014-RC7.exe/download>*
(AL version)
* *wsjtx-2.7.1-devel-win64_improved_widescreen_PLUS_241014-RC7.exe
<https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.1/wsjtx-2.7.1-devel-win64_improved_widescreen_PLUS_241014-RC7.exe/download>*
(widescreen version)
As usual, you can find tarballs with the source code as well as packages
for 32-bit Windows, Linux, etc. *on my SourceForge page
<https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.1/>*.
Enjoy the new version!
73 de DG2YCB,
Uwe
________________________________________
German Amateur Radio Station DG2YCB
Dr. Uwe Risse
eMail: dg...@gm...
Info: www.qrz.com/db/DG2YCB
|
|
From: Uwe, D. <dg...@gm...> - 2024-10-12 11:20:55
|
Hi Charlie, Nevertheless, all such things should be impossible. I'm going to program a couple of changes to make it more user-friendly and less susceptible to operator errors. 73 de DG2YCB, Uwe ________________________________________ German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: dg...@gm... Info: www.qrz.com/db/DG2YCB Am 12.10.2024 um 13:03 schrieb Charles Suckling: > Hi Uwe > > Having trouble reproducing this with a simple loop back test. > > I can demonstrate the effect where the TX frequency goal post bar > moves if you uncheck Hold TX, but SF still actually transmits with > sync at 750Hz when the goal post moves. > > 73 > > Charlie > > > > On Sat, 12 Oct 2024 at 12:40, Uwe, DG2YCB via > Wsjt-x-improved-community > <wsj...@li...> wrote: > > Hi Franco, > > I can confirm it is something else. In Fox or SuperFox mode, "Hold > Tx Freq" must be checked. Otherwise, a certain function is > activated which, however, does not make sense here. > > I'm going to discuss this internally with the other members of or > WSJT Dev Team, whether we shouldn't make it more “foolproof”, > because obviously far too many people are playing around with > settings that they don't have the slightest idea what they do, hi. > > 73 de DG2YCB, > Uwe > ________________________________________ > German Amateur Radio Station DG2YCB > Dr. Uwe Risse > eMail: dg...@gm... > Info: www.qrz.com/db/DG2YCB <http://www.qrz.com/db/DG2YCB> > > > Am 12.10.2024 um 12:09 schrieb Franco Borsa [HB9oab]: >> HI Uwe >> I think it's just not the same problem. >> Yes I tried with last _241005-RC7_001_ on all bands and without >> activating the "lock TX frequency" check, in SuperFox even >> without clicking on the WF or on the RX list, even by pressing >> only the TUNE or simply going to TX "ENABLE", when it switches to >> TX the red bar it moves, it does it with all my radios and it >> does not stay fixed where I put it. >> I have to remember to select only the "LOCK TX FREQ". >> Is this a correct behavior or am I doing something wrong? >> >> --- >> Franco >> *From:* Franco [HB9oab] >> *Sent:* Saturday, October 12, 2024 12:37 AM >> *To:* DG2YCB ; Wsjt Improved >> *Subject:* Re: [Wsjt-x-improved-community] grid square 4 or 6 >> HI Uwe, thanks >> Tomorrow I'll try to download it, but I think it's not the same >> problem. >> I can still update report for the "problem" that maybe isn't a >> problem. >> I correct that It also does it on the FTDX101 and on any band, so >> with the three radios I have it does it on all of them: >> I hadn't noticed and I don't know if it's this, however I still >> checked that if it "fixes the transmission" with the check in the >> "lock the TX frequency" window then it stays where I put it. >> In fact the one on the FTDX101 was with the check and the one on >> the 847 wasn't. >> I don't know now if I forgot the CHECK on " or if it's normal >> that it moves in superfox without the check on "fixes the >> transmission". >> So I think it should be left checked? But I don't understand why >> the red line moves if I don't select it also with TUNE. >> Sorry maybe it's just the oversight on the "FIX TX check box" >> 73 >> --- >> Franco HB9oab >> *From:* DG2YCB >> *Sent:* Friday, October 11, 2024 10:49 PM >> *Subject:* Re: [Wsjt-x-improved-community] grid square 4 or 6 >> Hi Franco, >> See if this unwanted effect is gone with the following test version: >> https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.1/Test%20versions/wsjtx-2.7.1-devel-win64_improved_PLUS_241005-RC7_001.exe/download >> There was an issue with SuperFox mode when Rig was selected as >> your method for Split Operation and operating on VHF or UHF >> bands. The _001 version has already the fix kindly provided by >> Matt KA1R. >> 73 de DG2YCB, >> Uwe >> _________________________________________ >> German Amateur Radio Station DG2YCB >> Dr. Uwe Risse >> eMail: DG...@gm... >> Info: www.qrz.com/db/DG2YCB <http://www.qrz.com/db/DG2YCB> >> >> Am 11. Oktober 2024 22:27:48 schrieb "Franco [HB9oab]" >> <hb...@ti...> <mailto:hb...@ti...>: >> >>> HI >>> A strange thing. >>> It only happens on the YAESU FT847 (which I also use for V/U SAT >>> EME), while on the FTDX101MP it does not happen: >>> I was playing with the latest improved version on a dummy load >>> the SuperFox with my radios. >>> On the FT847 that I have always used, I configured with omnirig2 >>> when I go into transmission in SUPERFOX mode the base frequency >>> SF 750Hz of the red bar of the superfox always moves to 500Hz >>> and therefore transmits from 500HZ instead of 750Hz, while on >>> the FTDX101 it always remains at 750 Hz or where I always put it >>> with OMNIRIG1. >>> With the FT847 even by only putting the TUNE the SF always moves >>> around 500Hz and does not remain on 750 or where I put it. >>> Did I make a mistake in some option that I can't find? >>> PrintScreen: >>> 1. RX and setup SUPERFOX for 750Hz >>> ** >>> clip_image002[5] >>> 2. If TUNE or TX it always moves TX bar around 500Hz >>> clip_image002[6] >>> 3. RADIO setup, whether with SPLIT NONE or RIG or FAKE always >>> the same thing:: >>> clip_image002[7] >>> It does this on practically all bands and any frequency if I >>> transmit in SUPERFOX mode as per the images. >>> Maybe I'm missing some option somewhere? >>> thanks >>> 73 >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------ >> _______________________________________________ >> Wsjt-x-improved-community mailing list >> Wsj...@li... >> https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community > > _______________________________________________ > Wsjt-x-improved-community mailing list > Wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community > |
|
From: Charles S. <g3...@gm...> - 2024-10-12 11:04:06
|
Hi Uwe Having trouble reproducing this with a simple loop back test. I can demonstrate the effect where the TX frequency goal post bar moves if you uncheck Hold TX, but SF still actually transmits with sync at 750Hz when the goal post moves. 73 Charlie On Sat, 12 Oct 2024 at 12:40, Uwe, DG2YCB via Wsjt-x-improved-community < wsj...@li...> wrote: > Hi Franco, > > I can confirm it is something else. In Fox or SuperFox mode, "Hold Tx > Freq" must be checked. Otherwise, a certain function is activated which, > however, does not make sense here. > > I'm going to discuss this internally with the other members of or WSJT Dev > Team, whether we shouldn't make it more “foolproof”, because obviously far > too many people are playing around with settings that they don't have the > slightest idea what they do, hi. > > 73 de DG2YCB, > Uwe > ________________________________________ > German Amateur Radio Station DG2YCB > Dr. Uwe Risse > eMail: dg...@gm... > Info: www.qrz.com/db/DG2YCB > > > Am 12.10.2024 um 12:09 schrieb Franco Borsa [HB9oab]: > > > HI Uwe > > I think it's just not the same problem. > > Yes I tried with last *241005-RC7_001* on all bands and without > activating the "lock TX frequency" check, in SuperFox even without clicking > on the WF or on the RX list, even by pressing only the TUNE or simply going > to TX "ENABLE", when it switches to TX the red bar it moves, it does it > with all my radios and it does not stay fixed where I put it. > > I have to remember to select only the "LOCK TX FREQ". > > Is this a correct behavior or am I doing something wrong? > > --- > Franco > > *From:* Franco [HB9oab] > *Sent:* Saturday, October 12, 2024 12:37 AM > *To:* DG2YCB ; Wsjt Improved > *Subject:* Re: [Wsjt-x-improved-community] grid square 4 or 6 > > HI Uwe, thanks > > Tomorrow I'll try to download it, but I think it's not the same problem. > > I can still update report for the "problem" that maybe isn't a problem. > I correct that It also does it on the FTDX101 and on any band, so with the > three radios I have it does it on all of them: > > I hadn't noticed and I don't know if it's this, however I still checked > that if it "fixes the transmission" with the check in the "lock the TX > frequency" window then it stays where I put it. > In fact the one on the FTDX101 was with the check and the one on the 847 > wasn't. > > I don't know now if I forgot the CHECK on " or if it's normal that it > moves in superfox without the check on "fixes the transmission". > > So I think it should be left checked? But I don't understand why the red > line moves if I don't select it also with TUNE. > > Sorry maybe it's just the oversight on the "FIX TX check box" > > 73 > --- > Franco HB9oab > > > *From:* DG2YCB > *Sent:* Friday, October 11, 2024 10:49 PM > *Subject:* Re: [Wsjt-x-improved-community] grid square 4 or 6 > > Hi Franco, > > See if this unwanted effect is gone with the following test version: > > https://sourceforge.net/projects/wsjt-x-improved/files/WSJT-X_v2.7.1/Test%20versions/wsjtx-2.7.1-devel-win64_improved_PLUS_241005-RC7_001.exe/download > > There was an issue with SuperFox mode when Rig was selected as your method > for Split Operation and operating on VHF or UHF bands. The _001 version has > already the fix kindly provided by Matt KA1R. > > 73 de DG2YCB, > Uwe > _________________________________________ > German Amateur Radio Station DG2YCB > Dr. Uwe Risse > eMail: DG...@gm... > Info: www.qrz.com/db/DG2YCB > > > > > Am 11. Oktober 2024 22:27:48 schrieb "Franco [HB9oab]" <hb...@ti...> > <hb...@ti...>: > >> HI >> >> A strange thing. >> >> It only happens on the YAESU FT847 (which I also use for V/U SAT EME), >> while on the FTDX101MP it does not happen: >> >> I was playing with the latest improved version on a dummy load the >> SuperFox with my radios. >> >> On the FT847 that I have always used, I configured with omnirig2 when I >> go into transmission in SUPERFOX mode the base frequency SF 750Hz of the >> red bar of the superfox always moves to 500Hz and therefore transmits from >> 500HZ instead of 750Hz, while on the FTDX101 it always remains at 750 Hz or >> where I always put it with OMNIRIG1. >> >> With the FT847 even by only putting the TUNE the SF always moves around >> 500Hz and does not remain on 750 or where I put it. >> >> Did I make a mistake in some option that I can't find? >> >> >> >> >> >> PrintScreen: >> >> 1. RX and setup SUPERFOX for 750Hz >> >> [image: clip_image002[5]] >> >> >> 2. If TUNE or TX it always moves TX bar around 500Hz >> [image: clip_image002[6]] >> >> >> 3. RADIO setup, whether with SPLIT NONE or RIG or FAKE always the same >> thing:: >> [image: clip_image002[7]] >> >> >> It does this on practically all bands and any frequency if I transmit in >> SUPERFOX mode as per the images. >> >> Maybe I'm missing some option somewhere? >> >> thanks >> 73 >> >> >> > > > ------------------------------ > > ------------------------------ > _______________________________________________ > Wsjt-x-improved-community mailing list > Wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community > > > _______________________________________________ > Wsjt-x-improved-community mailing list > Wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-x-improved-community > |
1 message has been excluded from this view by a project administrator.