¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

More testing. Re: flrig 2.0.05.63. "Extra Commands" buttons, long UI blocking delay when used!


 

¿ªÔÆÌåÓý

OK.? Some more detailed tests.

Using the FT736r, TS870s and PCR1000, all the "Extra command" function keys work nicely now, WITHOUT hanging the UI for some 7 seconds, so that? "waitResponse(200);? was the cause of the trouble.
(All three instances of Flrig, and one Fldigi up and running at the same time, no Serial port clashes noticed either.)? Running here (at the moment) on LMDE 5.


But....
In the case of the FT736, there is a problem when recalling a Flrig Memory.? The radio goes to the recalled frequency and mode etc, but the PC-screen UI is then "updated" but ends up showing the previous frequency.? This is probably a result of expecting to be able to read the radio's frequency after setting it.? In the case of this old Yaesu (and some others) it cannot return ANY data via the CAT system, other than a 'S' meter related value (working) and the state of the RX Squelch (not implemented.)

VFO A/B swap works OK though!? But, if a "Flrig Memory" was previously recalled, that recalled frequency is of course lost, as it never was "stuck" in Flrig's VFO display.

"Tuning" the radio from the PC by scrolling digits in the Frequency display, does work, and is recalled and A/B swapped just fine.


Also...? The Icom PCR1000 also has it's displayed Frequency stuck at the Old value, after a memory recall, though the RX is tuned to the recalled frequency.? (Again, I'm not sure that particular Icom can report it's frequency back to the computer.)? Again, VFO A/B swap works OK, but as in the case of the FT736, any previously "Recalled Flrig Memory" data, is lost, as it never stuck in Flrig's active frequency display.


This version (2.0.05.63) also does not allow the RX IF filters to be "adjusted" in the case of the TS870s.? It just shows "N/A" in the drop-down, so something else has changed too.

I did see something about a generic Kenwood change being made in a past message, but not sure what, there has been a history of "generic" changes, adversely affecting one or more specific Kenwood radios in the past.

Sadly, Kenwood (and others) don't do "Generic" commands etc across their model range it seems, there are always subtle differences to trip up the unwary!? Icom too, have some strange differences between even similar models, that make you wonder why...


This version also does not pickup my preconfigured (dark-ish) colour scheme, so something else funny about how it reads an existing preferences file seems present too.? Perhaps related one or more of the other issues above?

FYI:? I use the "Wide UI" mode here, it fits my needs better.? In case that has any bearing on the above.


Any other info needed, or things to test, just ask, with enough detail please, so I can do "Exactly" what is needed, for what you need to see.

73.

Dave G0WBX.






On 09/06/2024 18:34, Dave B wrote:
Thankyou Dave (HKJ).

Re:-
In the source file dialogs.cxx

Inline image

comment out line 1849 by placing '//' at the beginning of the line. ?Report results.


That seems to have fixed the issue.

However, I found that in line 2006 in dialogs.cxx in the ...

flrig-20.05.63/src/support/dialogs.cxx? file.

I commented out that line, rebuilt and tested.? It seem to have fully corrected the issue, so far.


However, I'm not sure why I found that at





?while line 1849 contained :-
"??? 0x3f487f00,"

Part of a long bunch of data that starts:-
static unsigned flrig_cmap[256] = {


I manipulate the sources in Geany, if that makes any difference.

At present, with a quick test, it seems fixed.?? I'm off out shortly to watch the Canadian GP with a bunch of friends. ? But will fully test tomorrow morning when I have the time to run up the rest of the shack.

Anyway, thanks for the response Dave, and enjoy the rest of your vacation.

More news tomorrow after more extensive tests.

73.
Dave G0WBX.

-- 
Created on and sent from a Unix like PC running and using free and open source software:


-- 
Created on and sent from a Unix like PC running and using free and open source software:


Cliff, AE5ZA
 

¿ªÔÆÌåÓý

Regarding the color scheme: is yours named filename.UI.prefs? If not it won't be recognized as a color scheme.

73,
Cliff, AE5ZA



On Jun 10, 2024, at 08:45, Dave, G?WBX via <g8kbvdave@...> wrote:

OK.? Some more detailed tests.

Using the FT736r, TS870s and PCR1000, all the "Extra command" function keys work nicely now, WITHOUT hanging the UI for some 7 seconds, so that? "waitResponse(200);? was the cause of the trouble.
(All three instances of Flrig, and one Fldigi up and running at the same time, no Serial port clashes noticed either.)? Running here (at the moment) on LMDE 5.


But....
In the case of the FT736, there is a problem when recalling a Flrig Memory.? The radio goes to the recalled frequency and mode etc, but the PC-screen UI is then "updated" but ends up showing the previous frequency.? This is probably a result of expecting to be able to read the radio's frequency after setting it.? In the case of this old Yaesu (and some others) it cannot return ANY data via the CAT system, other than a 'S' meter related value (working) and the state of the RX Squelch (not implemented.)

VFO A/B swap works OK though!? But, if a "Flrig Memory" was previously recalled, that recalled frequency is of course lost, as it never was "stuck" in Flrig's VFO display.

"Tuning" the radio from the PC by scrolling digits in the Frequency display, does work, and is recalled and A/B swapped just fine.


Also...? The Icom PCR1000 also has it's displayed Frequency stuck at the Old value, after a memory recall, though the RX is tuned to the recalled frequency.? (Again, I'm not sure that particular Icom can report it's frequency back to the computer.)? Again, VFO A/B swap works OK, but as in the case of the FT736, any previously "Recalled Flrig Memory" data, is lost, as it never stuck in Flrig's active frequency display.


This version (2.0.05.63) also does not allow the RX IF filters to be "adjusted" in the case of the TS870s.? It just shows "N/A" in the drop-down, so something else has changed too.

I did see something about a generic Kenwood change being made in a past message, but not sure what, there has been a history of "generic" changes, adversely affecting one or more specific Kenwood radios in the past.

Sadly, Kenwood (and others) don't do "Generic" commands etc across their model range it seems, there are always subtle differences to trip up the unwary!? Icom too, have some strange differences between even similar models, that make you wonder why...


This version also does not pickup my preconfigured (dark-ish) colour scheme, so something else funny about how it reads an existing preferences file seems present too.? Perhaps related one or more of the other issues above?

FYI:? I use the "Wide UI" mode here, it fits my needs better.? In case that has any bearing on the above.


Any other info needed, or things to test, just ask, with enough detail please, so I can do "Exactly" what is needed, for what you need to see.

73.

Dave G0WBX.






On 09/06/2024 18:34, Dave B wrote:
Thankyou Dave (HKJ).

Re:-
In the source file dialogs.cxx

<5n5lUWdTbEWEk0yt.png>

comment out line 1849 by placing '//' at the beginning of the line. ?Report results.


That seems to have fixed the issue.

However, I found that in line 2006 in dialogs.cxx in the ...

flrig-20.05.63/src/support/dialogs.cxx? file.

I commented out that line, rebuilt and tested.? It seem to have fully corrected the issue, so far.


However, I'm not sure why I found that at

<bGCGRMiD1xlKNQVm.png>



?while line 1849 contained :-
"??? 0x3f487f00,"

Part of a long bunch of data that starts:-
static unsigned flrig_cmap[256] = {


I manipulate the sources in Geany, if that makes any difference.

At present, with a quick test, it seems fixed.?? I'm off out shortly to watch the Canadian GP with a bunch of friends. ? But will fully test tomorrow morning when I have the time to run up the rest of the shack.

Anyway, thanks for the response Dave, and enjoy the rest of your vacation.

More news tomorrow after more extensive tests.

73.
Dave G0WBX.

-- 
Created on and sent from a Unix like PC running and using free and open source software:


-- 
Created on and sent from a Unix like PC running and using free and open source software:



 

Ermmm...

Why would it not pickup the settings in the existing preferences file(s) created by the earlier v2.0.05.05 ?
Where everything (including the UI colours) are held?...

Other than laboriously (for each of the three radio's I use) edit the colours by hand, why can't it just read the original preferences files for that, just like it seems to be doing fine for all the other customisation settings (radio choices, port settings, extra commands, memories etc) ?

I'm guessing I missed something in the evolution of Flrig...

73.

Dave G0WBX.

--
Created on and sent from a Unix like PC running and using free and open source software: