开云体育

Index of /alpha/flrig

73, David W1HKJ

Hi Guys,

?

Just wanted to report a couple of issues caused by recent changes to "rig_io::readResponse(...)" alpha v2.0.05.55 which impacted Yaesu FT-991A:

?

Issue 1.? Using "Command" and "SendCommand" UI flows hanging

Reviewing the code identified issue with "rig_io::readResponse(...)" were the "expect" variable is wrongly being set to "req2".? The current if statement line #174 should check result doesn't equal "std::string::npos".?? This issue has been here for a while but recent changes now means expect was being used by the respstr.find(expect) further down? line#182

?

Issue 2.? After fixing Issue 1 still having issues using "Command" and "SendCommand" UI flows stalling for (~1sec read timeout)

The issue here is again recent changes now always waiting for up to 1sec (100 loops 10ms sleep) waiting for response.? Well unfortunately not all commands send responses.? For example if you send a custom command "PC100;" to set the power level 100 FT991A is not returning a response.? My current workaround for this is when sending one or more commands I make sure the last command either needed or not will cause a response ie? PC100;PC;

?

Mark (VK4TMZ)

Well, that's one way to fix stuff, I guess it will work with my TS870s too.

But not the FT736, unless I as for a S meter or Squelch state as they are the only two things that old box can send back to the computer.

But why should we need to do such?

It wasn't broken in 2.0.05.05, so why was the scheme changed?? By accident perhaps, I don't recall seeing any comments from Dave HKJ about changes that could break existing setups.

There again, Dave has had a lot of other things on his plate to deal with not so long ago, not just ham software...

73.

Dave G0WBX (or G8KBV)

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

On Fri, Jun 7, 2024 at 02:25 PM, VK4TMZ wrote:

Just wanted to report a couple of issues caused by recent changes

Hi Mark,

I'm having the same (or similar?) issue with flrig on Linux Mint and Windows 10, which I first noticed while upgrading from 2.0.05.45 to 2.0.05.61, as reported here:

/g/winfldigi/topic/flrig_2_0_05_61_w_ts_570_not/106369517

The problem persists with flrig 2.0.05.63 as well. Unfortunately, my coding skills are too rusty and I don't have the ability to debug the source as you have done. So for now I have gone back to 2.0.05.45.

Sorry I don't have anything to add to the conversation other than "me too".? :(

Cheers,
Steve K4RVA

Mark.

Which source file are you referring to?

(I get lost trying to follow program flow in these multiple source file projects.)

73.

Dave G0WBX.

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

Dave,

?

As inferred by original post "rig_io::readResponse" -> "/src/support/rig_io.cxx"? and the method "readResponse" line #167.?? Here is a snapshot of my temp fix for issue 1:

Issue 2 - you can see the "do" loop line #175? now exists for both? "read_from_Remote" and "from serial" were as before was only looping for "read_from_Remote" path.

Will leave it up the devs to resolve that one as I have temp solution.

?

Mark (VK4TMZ)

Hi Mark.

Not sure which "Dave" you're replying to, but the postage stamp sized (in my mail client, I generally avoid the groups.io website) screen scrape of a source file is almost impossible to read here, but I can see your highlight !

Anyway, as you might also see by now, I've found other issues with the 2.0.05.63 issue of Flrig, that's forcing m e to stay for now, with 2.0.05.05, as that (for me anyway) works correctly.

73.

Dave G0WBX.

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