Date   

locked Re: WSJT-X 2.5.0 and MCHF: issue reading-back the VFO setting #Cat_RigControl #linux #Yaesu #IssueReport

Michael Black
 

I made the one change for the 817 copy that should work OK.  That is the get_vfo function which broke the emulation.

Mike




On Wednesday, November 3, 2021, 05:32:14 PM CDT, PFA <fpaolo63@...> wrote:


Hi Mike,

just check the real Yaesu ft817 : It is working fine with Hamlib 4.3.1

About new RIG " 1045  M0NKA                  mcHF QRP                20211103.0      Beta        RIG_MODEL_MCHFQRP"
just clone your commit going to test..

Just a doubt : you added the new rig on top of 817, but we already know that mchf emulation is wrong and is ot anymore working with HamLib 4.3.1.
I think it is better to add mchf on top of ft487 that it seems compatible with mcHF emulation also with 4.3.1

Let me do some test and may be patch in a different way. In case I will send diff.

--
73 paolo IU2OMT




locked Re: WSJT-X 2.5.0 and MCHF: issue reading-back the VFO setting #Cat_RigControl #linux #Yaesu #IssueReport

Bill Somerville
 

On 03/11/2021 22:32, PFA wrote:
Hi Mike,

just check the real Yaesu ft817 : It is working fine with Hamlib 4.3.1

About new RIG " 1045  M0NKA                  mcHF QRP   20211103.0      Beta        RIG_MODEL_MCHFQRP"
just clone your commit going to test..

Just a doubt : you added the new rig on top of 817, but we already know that mchf emulation is wrong and is ot anymore working with HamLib 4.3.1.
I think it is better to add mchf on top of ft487 that it seems compatible with mcHF emulation also with 4.3.1

Let me do some test and may be patch in a different way. In case I will send diff.

--
73 paolo IU2OMT
Hi Paolo,

using a broken CAT protocol that is one-way only is not the way to go, your rig emulates an FT-817, but not the undocumented CAT commands that Hamlib unfortunately uses. I am sure Mike has implemented the new back end to use only documented FT-817 CAT commands when talking to the mxHF and it should work with your rig, without having to revert to assuming the rig state is never changed from the front panel.

73
Bill
G4WJS.


locked Re: Possible to Adjust Time to Match Sending Station? #Timesync

Robert Lorenzini
 

There is a new version out that makes fudging a menu item.

Bob - wd6dod

On 11/3/2021 2:33 PM, Dave Garber wrote:
I use bkttimesync

sent via LG hand held device

On Wed., Nov. 3, 2021, 11:24 a.m. K1dj via groups.io, <k1dj=aol.com@groups.io> wrote:
Is it possible to adjust my time to match an off-time DX station?  [Right now, 7P8RU's clock is running about 1.2 sec fast.]
73 - Rich, K1DJ







locked Re: WSJT-X 2.5.0 and MCHF: issue reading-back the VFO setting #Cat_RigControl #linux #Yaesu #IssueReport

PFA
 

Hi Mike,

just check the real Yaesu ft817 : It is working fine with Hamlib 4.3.1

About new RIG " 1045  M0NKA                  mcHF QRP                20211103.0      Beta        RIG_MODEL_MCHFQRP"
just clone your commit going to test..

Just a doubt : you added the new rig on top of 817, but we already know that mchf emulation is wrong and is ot anymore working with HamLib 4.3.1.
I think it is better to add mchf on top of ft487 that it seems compatible with mcHF emulation also with 4.3.1

Let me do some test and may be patch in a different way. In case I will send diff.

--
73 paolo IU2OMT


locked Re: Possible to Adjust Time to Match Sending Station? #Timesync

Dave Garber
 

I use bkttimesync

sent via LG hand held device

On Wed., Nov. 3, 2021, 11:24 a.m. K1dj via groups.io, <k1dj=aol.com@groups.io> wrote:
Is it possible to adjust my time to match an off-time DX station?  [Right now, 7P8RU's clock is running about 1.2 sec fast.]
73 - Rich, K1DJ



locked Re: #FoxAndHound: Please do not QSY back to "normal" frequency

Dave Garber
 

Is the f/h frequency in you main frequency list?   I am guessing that is why the frequency change happens.  Its defaulting to known drop down frequency

sent via LG hand held device

On Wed., Nov. 3, 2021, 5:00 p.m. Bill, WB6JJJ, <bill@...> wrote:
Why should I need to set up a separate configuration for one QSO?  Still, evoking F/H should not change my radio’s frequency.

Bill
WB6JJJ 

On Nov 3, 2021, at 12:16 PM, Philip Rose via groups.io <gm3zza=btinternet.com@groups.io> wrote:


Thanks Martin.

This was a one-off. "What are those signals at 18,095?" If I chased expeditions 24/7 I might consider this. But I have a life outside amateur radio, and other amateur radio activities.

73 Phil GM3ZZA

On 3 Nov 2021 18:57, Martin G0HDB <marting0hdb@...> wrote:
On Wed, Nov 3, 2021 at 06:27 PM, Bill, WB6JJJ wrote:
 
I also found this problem…  why move the radio back to the normal frequency when that is not supposed to be allowed in F/H mode.  It caught me a few times recently with the numerous DXpeditions using F/H mode away from the normal frequency.   Selecting F/H mode should not change my radio frequency.
Bill (and Phil):

If you use separate, dedicated configurations for normal and Hound mode then each configuration can have its own frequency set that can be tailored so that, when in the Hound configuration, none of the standard FT8 frequencies are included so the inadvertent QSY'ing you've described will be completely avoided.  This is yet another of the undeniable advantages of using a separate configuration for each different operating scenario.

--
Martin G0HDB


--
73 Phil GM3ZZA






locked Re: #FoxAndHound: Please do not QSY back to "normal" frequency

Al Groff
 

Bill,
  Add the F/H frequency to the frequency table.. Then will not switch when you switch in/out of F/H mode.

AL, K0VM


On 11/3/2021 4:00 PM, Bill, WB6JJJ wrote:
Why should I need to set up a separate configuration for one QSO?  Still, evoking F/H should not change my radio’s frequency.

Bill
WB6JJJ 

On Nov 3, 2021, at 12:16 PM, Philip Rose via groups.io <gm3zza@...> wrote:


Thanks Martin.

This was a one-off. "What are those signals at 18,095?" If I chased expeditions 24/7 I might consider this. But I have a life outside amateur radio, and other amateur radio activities.

73 Phil GM3ZZA

On 3 Nov 2021 18:57, Martin G0HDB <marting0hdb@...> wrote:
On Wed, Nov 3, 2021 at 06:27 PM, Bill, WB6JJJ wrote:
 
I also found this problem…  why move the radio back to the normal frequency when that is not supposed to be allowed in F/H mode.  It caught me a few times recently with the numerous DXpeditions using F/H mode away from the normal frequency.   Selecting F/H mode should not change my radio frequency.
Bill (and Phil):

If you use separate, dedicated configurations for normal and Hound mode then each configuration can have its own frequency set that can be tailored so that, when in the Hound configuration, none of the standard FT8 frequencies are included so the inadvertent QSY'ing you've described will be completely avoided.  This is yet another of the undeniable advantages of using a separate configuration for each different operating scenario.

--
Martin G0HDB


--
73 Phil GM3ZZA







locked Re: #FoxAndHound: Please do not QSY back to "normal" frequency

Bill, WB6JJJ
 

Why should I need to set up a separate configuration for one QSO?  Still, evoking F/H should not change my radio’s frequency.

Bill
WB6JJJ 

On Nov 3, 2021, at 12:16 PM, Philip Rose via groups.io <gm3zza@...> wrote:


Thanks Martin.

This was a one-off. "What are those signals at 18,095?" If I chased expeditions 24/7 I might consider this. But I have a life outside amateur radio, and other amateur radio activities.

73 Phil GM3ZZA

On 3 Nov 2021 18:57, Martin G0HDB <marting0hdb@...> wrote:
On Wed, Nov 3, 2021 at 06:27 PM, Bill, WB6JJJ wrote:
 
I also found this problem…  why move the radio back to the normal frequency when that is not supposed to be allowed in F/H mode.  It caught me a few times recently with the numerous DXpeditions using F/H mode away from the normal frequency.   Selecting F/H mode should not change my radio frequency.
Bill (and Phil):

If you use separate, dedicated configurations for normal and Hound mode then each configuration can have its own frequency set that can be tailored so that, when in the Hound configuration, none of the standard FT8 frequencies are included so the inadvertent QSY'ing you've described will be completely avoided.  This is yet another of the undeniable advantages of using a separate configuration for each different operating scenario.

--
Martin G0HDB


--
73 Phil GM3ZZA



locked Re: Possible to Adjust Time to Match Sending Station? #Timesync

Kai-KE4PT
 

Michael is too modest! His tiny TimeFudge module lets you nudge your PC clock as you want. It also occupies no more than a small postage stamp sized window on your screen. Thanks again, Mike!
Kindest regards,
Kai, KE4PT

On 11/3/2021 11:34, Michael Black via groups.io wrote:
Look for TimeFudge on my QRZ page.
I have a Windows executable and source code for Linux/Unix.

Mike W9MDB


    


locked Re: #FoxAndHound: Please do not QSY back to "normal" frequency

 

Thanks Martin.

This was a one-off. "What are those signals at 18,095?" If I chased expeditions 24/7 I might consider this. But I have a life outside amateur radio, and other amateur radio activities.

73 Phil GM3ZZA

On 3 Nov 2021 18:57, Martin G0HDB <marting0hdb@...> wrote:
On Wed, Nov 3, 2021 at 06:27 PM, Bill, WB6JJJ wrote:
 
I also found this problem…  why move the radio back to the normal frequency when that is not supposed to be allowed in F/H mode.  It caught me a few times recently with the numerous DXpeditions using F/H mode away from the normal frequency.   Selecting F/H mode should not change my radio frequency.
Bill (and Phil):

If you use separate, dedicated configurations for normal and Hound mode then each configuration can have its own frequency set that can be tailored so that, when in the Hound configuration, none of the standard FT8 frequencies are included so the inadvertent QSY'ing you've described will be completely avoided.  This is yet another of the undeniable advantages of using a separate configuration for each different operating scenario.

--
Martin G0HDB


--
73 Phil GM3ZZA


locked Re: No power or tones on alternate tries #txaudio #Yaesu #stopped_working

Robert Ahrens
 

Update:  This morning, it now has no tones/power on any try.  The "every other" behavior has changed.  Go figure ...

It may matter ... I just looked and I am still using V2.4.0 c19d62 of WSJT-X  and V2.50.2 of JTAlert.  

I also reviewed my Windows sound settings.  The Realtech Speakers and Stereo Mix are the default ins/outs.  If I switch the "Output" to the USB Codec, the tones come out of the speaker EVERY time I hit the tune button ... conclusion, this is NOT a WSJT issue.  The USB Codecs are properly set in WSJT and the device drivers are present and do not indicate any problems (no "!" notices on the Device Driver screen).

I have the radio tab set to OmniRig1, CAT, USB, and Rig.  All other options are grayed out.  The Test CAT and Test PTT work as they should.  But again, I think that I have concluded that I do not have a control problem - only an audio one.

Does this ring a bell for anyone?  Any suggestions?

Tnx.  NT5A - Bob



On Wed, Nov 3, 2021 at 6:46 AM Robert Ahrens via groups.io <robertahrens52=gmail.com@groups.io> wrote:
I have been going crazy.  I jerked around with my setup for the CQWW SSB contest over the weekend and since then things have been weird.  I cannot fathom how anything I did could cause the problem I am having now.

Every other time that WSJT keys my FTDX3000, it fails to send tones so there is no power out.  The rig reliably keys and I have confirmed via the MON function that tones are produced only every other time that the Tune button on WSJT is activated, or that WSJT "transmits" a CQ (or any other message).

I am using OmniRig, full CAT with a single cable to the computer, and Win4Yaesu with a Win10 computer ... but I cannot imagine how any of that should matter.  The radio is keying every time, and the audio path (selection of audio devices, etc) appears to be OK since it does work predictably every other time. 

Any ideas?  Thank you for your help.  It is driving me crazy watching one DX station after another  scroll up the screen and I cannot even try. 

73 de NT5A - Bob



locked Re: #FoxAndHound: Please do not QSY back to "normal" frequency

Martin G0HDB
 

On Wed, Nov 3, 2021 at 06:27 PM, Bill, WB6JJJ wrote:
 
I also found this problem…  why move the radio back to the normal frequency when that is not supposed to be allowed in F/H mode.  It caught me a few times recently with the numerous DXpeditions using F/H mode away from the normal frequency.   Selecting F/H mode should not change my radio frequency.
Bill (and Phil):

If you use separate, dedicated configurations for normal and Hound mode then each configuration can have its own frequency set that can be tailored so that, when in the Hound configuration, none of the standard FT8 frequencies are included so the inadvertent QSY'ing you've described will be completely avoided.  This is yet another of the undeniable advantages of using a separate configuration for each different operating scenario.

--
Martin G0HDB


locked Re: #FoxAndHound: Please do not QSY back to "normal" frequency

Bill, WB6JJJ
 

I also found this problem…  why move the radio back to the normal frequency when that is not supposed to be allowed in F/H mode.  It caught me a few times recently with the numerous DXpeditions using F/H mode away from the normal frequency.   Selecting F/H mode should not change my radio frequency.

Bill
WB6JJJ 

On Nov 3, 2021, at 9:38 AM, Philip Rose via groups.io <gm3zza@...> wrote:



Sorry 17m!

 

Sent from Mail for Windows

 

From: Philip Rose via groups.io
Sent: 03 November 2021 16:12
To: main@WSJTX.groups.io
Subject: [WSJTX] #FoxAndHound: Please do not QSY back to "normal" frequency

 

This afternoon I was on 12m, and on the IC-7300 spectrum scope I could see FT8 activity 5kHz down. Tuned down to see what it was and it was the HD8R DXPedition. Thought I would join the throng so went into Hound mode. I wondered why I was now seeing normal transmissions and realised that setting "hound" mode had reset the frequency to the normal for 12m.

 

I assume that the dial frequency was 18.095 - this put the fox on 530 Hz plus the 3 60 Hz higher. When they came back, I cleared the "Enable TX" in my excitement - I had the mouse hovering over it to re-enable it when it was cleared after too many transmissions.

 

--

73 Phil GM3ZZA

 


--
73 Phil GM3ZZA



locked Re: Possible to Adjust Time to Match Sending Station? #Timesync

Sam Birnbaum
 

Hi Chas,

If you are running a version  MS Windows you are more than welcome to us a program "SyncTime.exe"  that I wrote 
and that is available for free on ProgramsByW2JDB. It can be used to keep your PC synced to internet time and also 
to nudge you PC clock +/-  a number of milliseconds.  However, if you are only off by less that 2 seconds, WSJT-X
should not have any problem in decoding the messages from the other stations.

73,

Sam W2JDB



-----Original Message-----
From: chas cartmel <chas@...>
To: main@WSJTX.groups.io
Sent: Wed, Nov 3, 2021 12:17 pm
Subject: Re: [WSJTX] Possible to Adjust Time to Match Sending Station? #Timesync

Alan" I have not used as a default timekeeper so I do not know how it performs in the long term."In answer to your perceived question above, the default for windows is totally inadequate for WS modes.73 CharlieG4ESTwww.g4est.me.ukStay safe out there-----Original Message-----From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Alan G4ZFQSent: Wednesday, November 3, 2021 4:01 PMTo: main@...: Re: [WSJTX] Possible to Adjust Time to Match Sending Station? #Timesync> I think the only way is to stop sync and adjust your clock manually. > But if there exists a sync software with this capability I'm interested, too!Pietrohttps://www.qsl.net/dl4yhf/rsNTP/rsNTP.htmI have used this on Windows 10.I have not used as a default timekeeper so I do not know how it performs in the long term.73 Alan G4ZFQ


This email has been scanned by BullGuard antivirus protection.
For more info visit www.bullguard.com







locked Re: WSJT-X 2.5.0 and MCHF: issue reading-back the VFO setting #Cat_RigControl #linux #Yaesu #IssueReport

Andy Talbot
 

There is something odd with the FT817 power anyway.  I made a keypad for direct frequency entry that interprets a numeric keypad ands sends the entered value on the CAT input - it gets it's power from the CAT socket on the FT817. 
http://g4jnt.com/FT817_Keypad.pdf     Just for the sake of it, I put a LED on the keypad that illuminates whenever a key is pressed

I notice that when the FT817 is powered off, pressing any key still illuminates the LED, so even when off power is still present on the back connector.   So if any accessory is plugged in there that gets its power from the rig, it will drain the battery even when off.   My PIC + regulator draws about a few mA with no key pressed so it would drain the battery after a few days if it wasn't permanently left connected to a 12V supply.


locked Re: WSJT-X 2.5.0 and MCHF: issue reading-back the VFO setting #Cat_RigControl #linux #Yaesu #IssueReport

PFA
 

... got the A.I. :) , I will do it in the next days ...

ciao

 
--
73 paolo IU2OMT


On Wed, Nov 3, 2021 at 05:34 PM, Michael Black wrote:
I just added the mcHF to hamlib as model#1045 and M0NKA as the manufacturer....but maybe that should be "OpenSource" as the manufacturer to have something for additional rigs in the future.
 
  1045  M0NKA                  mcHF QRP                20211103.0      Beta        RIG_MODEL_MCHFQRP
 
Give it a try and let me know if it works OK.
 
Mike W9MDB
 


locked Re: #FoxAndHound: Please do not QSY back to "normal" frequency

 

Sorry 17m!

 

Sent from Mail for Windows

 

From: Philip Rose via groups.io
Sent: 03 November 2021 16:12
To: main@WSJTX.groups.io
Subject: [WSJTX] #FoxAndHound: Please do not QSY back to "normal" frequency

 

This afternoon I was on 12m, and on the IC-7300 spectrum scope I could see FT8 activity 5kHz down. Tuned down to see what it was and it was the HD8R DXPedition. Thought I would join the throng so went into Hound mode. I wondered why I was now seeing normal transmissions and realised that setting "hound" mode had reset the frequency to the normal for 12m.

 

I assume that the dial frequency was 18.095 - this put the fox on 530 Hz plus the 3 60 Hz higher. When they came back, I cleared the "Enable TX" in my excitement - I had the mouse hovering over it to re-enable it when it was cleared after too many transmissions.

 

--

73 Phil GM3ZZA

 


--
73 Phil GM3ZZA


locked Re: WSJT-X 2.5.0 and MCHF: issue reading-back the VFO setting #Cat_RigControl #linux #Yaesu #IssueReport

Michael Black
 

I just added the mcHF to hamlib as model#1045 and M0NKA as the manufacturer....but maybe that should be "OpenSource" as the manufacturer to have something for additional rigs in the future.

  1045  M0NKA                  mcHF QRP                20211103.0      Beta        RIG_MODEL_MCHFQRP

Give it a try and let me know if it works OK.

Mike W9MDB


On Wednesday, November 3, 2021, 11:07:51 AM CDT, PFA <fpaolo63@...> wrote:


[Edited Message Follows]

Hi Mike, Andy

some notes / clarifications

My Rig is mcHF-QRP (http://www.m0nka.co.uk/) an open HW device, running UHSDR sw  (https://github.com/df8oe/UHSDR).

Its CAT interface is emulating FT817.
Everything were fine till Hamlib 4.3.0, and CAT for 817 was fine reading VFO, as well FT847. Starting from Hamlib 4.3.1, on my case, cat for ft817 is failing read back VFO.   


@Mike
Your reply doesn't  match with my observations (not yet open the src code ...) with Hamlib till 4.3.0:
  • FT817 and FT847 seems support in some way the VFO read back and wsjtx updates the freq box according my rig manual setting
  • FT847UNI is not reading back the VFO since CAT is unidirectional. Freq BOX on wsjtx become RED and value is set to "0". This affect ADIF file that report wrong band and freq. (very annoying)  
any way this evening I'm going to repeat tests using a real FT817.

Will followup


--
73 paolo IU2OMT




locked Re: WSJT-X 2.5.0 and MCHF: issue reading-back the VFO setting #Cat_RigControl #linux #Yaesu #IssueReport

Michael Black
 

FT847UNI should be reading back the last frequency set (it has to assume it doesn't change).

If it's not then I need to see some debug.

The FT817 backend is written for a real FT817 -- not an emulator.  It's trying read the eeprom location 0x55 to get the vfo.

Perhaps it's time to create an entry for the mcHF-QRP rig.

Mike


On Wednesday, November 3, 2021, 11:07:51 AM CDT, PFA <fpaolo63@...> wrote:


[Edited Message Follows]

Hi Mike, Andy

some notes / clarifications

My Rig is mcHF-QRP (http://www.m0nka.co.uk/) an open HW device, running UHSDR sw  (https://github.com/df8oe/UHSDR).

Its CAT interface is emulating FT817.
Everything were fine till Hamlib 4.3.0, and CAT for 817 was fine reading VFO, as well FT847. Starting from Hamlib 4.3.1, on my case, cat for ft817 is failing read back VFO.   


@Mike
Your reply doesn't  match with my observations (not yet open the src code ...) with Hamlib till 4.3.0:
  • FT817 and FT847 seems support in some way the VFO read back and wsjtx updates the freq box according my rig manual setting
  • FT847UNI is not reading back the VFO since CAT is unidirectional. Freq BOX on wsjtx become RED and value is set to "0". This affect ADIF file that report wrong band and freq. (very annoying)  
any way this evening I'm going to repeat tests using a real FT817.

Will followup


--
73 paolo IU2OMT




locked Re: WSJT-X 2.5.0 and MCHF: issue reading-back the VFO setting #Cat_RigControl #linux #Yaesu #IssueReport

Bill Somerville
 

On 03/11/2021 16:16, Andy TALBOT wrote:
Oh dear, red face, I must be getting too old for this sort of thing
Yes, you're quite right, command 03 is just a straightforward one; send and wait for response

Andy

Hi Andy,

also I think the warning is simply to remind users that a CAT "POWER OFF" command is not really powering off the rig since there is a matching "POWER ON" command. So I think it is just about preserving battery life.

73
Bill
G4WJS.

7101 - 7120 of 36729