Date
1 - 20 of 21
Locked WSJT-X 2.5.0 and MCHF: issue reading-back the VFO setting #Cat_RigControl #linux #Yaesu #IssueReport
|
Thank you, thank you, thank you!
This has been driving me crazy for days! I FINALLY reverted back to 2.1.2 to get things working, but this is such a better solution! |
|
|
|
Danilo
Hi,
new UHSDR firmware 2.12.2 has been released and tested successfully with WSJTX 2.5.0 and 2.5.2. Both the mcHF and the FT817 entry work now as expected. 73 Danilo DB4PLE |
|
|
|
Danilo
Hi,
HAMLIB issue should be fixed in next firmware release of UHSDR. Just update to 2.12.1 (to be release in the next days) or newer from https://df8oe.github.io/UHSDR/ THX to Paolo for reporting this in our UHSDR github issue tracker https://github.com/df8oe/UHSDR. For details on this issue, see comments in github: https://github.com/df8oe/UHSDR/issues/1921 BTW, all devices running UHSDR, not just the mcHF rig, had the issue as all have the same FT817 emulation. 73 Danilo DB4PLE |
|
|
|
I cloned https://github.com/Hamlib/Hamlib/commit/544fcf719440e641285f30ada4c268f33dd36f60
and build WSJTX just a smoke test new rig mcHF is not working  Instead using ft847 it is working fine  .... going to sleep :) ... will continue have a good night, ciao -- 73 paolo IU2OMT |
|
|
|
Mike 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 |
|
|
|
On 03/11/2021 22:32, PFA wrote:
Hi Mike,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. |
|
|
|
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 |
|
|
|
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. Andy |
|
|
|
... got the A.I. :) , I will do it in the next days ...
toggle quoted message
Show quoted text
ciao -- 73 paolo IU2OMT On Wed, Nov 3, 2021 at 05:34 PM, Michael Black wrote:
|
|
|
|
Mike 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 Mike W9MDB
On Wednesday, November 3, 2021, 11:07:51 AM CDT, PFA <fpaolo63@...> wrote:
[Edited Message Follows] Hi Mike, Andysome 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:
Will followup -- 73 paolo IU2OMT |
|
|
|
Mike 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, Andysome 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:
Will followup -- 73 paolo IU2OMT |
|
|
|
On 03/11/2021 16:16, Andy TALBOT wrote:
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 |
|
|
|
Andy Talbot
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 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:
Will followup -- 73 paolo IU2OMT |
|
|
|
Mike Black
You may be misreading the manual. It's the Power On/Off that talks about the battery pack. Mike W9MDB 
On Wednesday, November 3, 2021, 09:59:20 AM CDT, Andy TALBOT <andy.g4jnt@...> wrote:
Reading this thread piqued my intrigue, so went and had a look at the manual for my FT817ND. The CAT command for getting frequency is there, but has the feeling of having been added as an afterthought. It looks bodged Issue CAT command 03 with 4 dummy bytes It should return 5 bytes of data with frequency and mode. BUT BUT BUT ... In footnotes, firstly it states "Do not use this command when using alkaline batteries or the supplied FNB-85 Ni-MH battery pack" Then it goes on to state "Send a 5-byte dummy data (such as 00 00 00 00 00) first when sending this command Why the battery pack should affect this particular CAT command I shudder to think Andy |
|
|
|
Andy Talbot
Reading this thread piqued my intrigue, so went and had a look at the manual for my FT817ND. The CAT command for getting frequency is there, but has the feeling of having been added as an afterthought. It looks bodged Issue CAT command 03 with 4 dummy bytes It should return 5 bytes of data with frequency and mode. BUT BUT BUT ... In footnotes, firstly it states "Do not use this command when using alkaline batteries or the supplied FNB-85 Ni-MH battery pack" Then it goes on to state "Send a 5-byte dummy data (such as 00 00 00 00 00) first when sending this command Why the battery pack should affect this particular CAT command I shudder to think Andy |
|
|
|
Mike Black
The FT847 does not have a get_vfo function. The FT817 does now have a get_vfo function which apparently is not supported by that rig. So looks like you need to use the FT847. Mike W9MDB
On Wednesday, November 3, 2021, 03:34:25 AM CDT, PFA <fpaolo63@...> wrote:
[Edited Message Follows] Hi Mike,just a clarification: as per subject and tags, my tests are based on linux using my mcHF-QRP rig: it has a native CAT/Audio USB interface and emulate the ft817 ... hamlib 4.3.1 ( wsjtx 2.5.0) and mcHF with 817 setting I got this error testing CAT:
as you suggested, i will repeat the test also for HamLib 4.4 As well I will repeat tests using my ft817 .... I start a thread on mcHF group: https://groups.io/g/mcHF/topic/86598682 PS. just understood what really means 847UNI .... sorry for the confusion -- 73 paolo IU2OMT |
|
|
|
Hi Mike,
just a clarification: as per subject and tags, my tests are based on linux using my mcHF-QRP rig: it has a native CAT/Audio USB interface and emulate the ft817 ... hamlib 4.3.1 ( wsjtx 2.5.0) and mcHF with 817 setting I got this error testing CAT:
as you suggested, i will repeat the test also for HamLib 4.4 As well I will repeat tests using my ft817 .... I start a thread on mcHF group: https://groups.io/g/mcHF/topic/86598682 PS. just understood what really means 847UNI .... sorry for the confusion -- 73 paolo IU2OMT |
|
|
|
Mike Black
And what if you replace the dll with the appropriate 32/64-bit one from here which is the current 4.4 development ? What error do you get from the FT817? Mike W9MDB
On Tuesday, November 2, 2021, 08:30:31 PM CDT, PFA <fpaolo63@...> wrote:
for who is interested on this topic: just done some troubleshooting ... RECAP working settings: wsjtx 2.4.0 (it use Hamlib 4.2) -> set CAT for FT817 or FT847 wsjtx 2.5.0rc5 (it use Hamlib 4.3) -> set CAT for FT817 or FT847 wsjtx 2.5.0 + Hamlib 4.3.1 -> set CAT for FT847 (no UNI) wsjtx 2.5.0 + Hamlib 4.3 -> set CAT for FT817 or FT847 ... so which is the expected settings ? 817 or 847 or both ? Any way it seems new Hamlib introduced the different behaviour . -- 73 paolo IU2OMT |
|
|
|
for who is interested on this topic:
just done some troubleshooting ... RECAP working settings: wsjtx 2.4.0 (it use Hamlib 4.2) -> set CAT for FT817 or FT847 wsjtx 2.5.0rc5 (it use Hamlib 4.3) -> set CAT for FT817 or FT847 wsjtx 2.5.0 + Hamlib 4.3.1 -> set CAT for FT847 (no UNI) wsjtx 2.5.0 + Hamlib 4.3 -> set CAT for FT817 or FT847 ... so which is the expected settings ? 817 or 847 or both ? Any way it seems new Hamlib introduced the different behaviour . -- 73 paolo IU2OMT |
|
|