Topics

QCX Firmware change request: Validate CAT frequency values. #qcx #firmware #cat


Sheldon Hartling
 

Hi Hans,

 

Please consider validating the frequency values received in "FA" and "FB" CAT commands to confirm they are valid for the QCX's band.  Currently, in v1.5, out-of-band values are accepted and set the VFO to unsupported frequencies.  Easy to do, by accident, when hand-entering values in logging programs.

 

Thanks and 73, Sheldon VE1GPY

 


N3MNT
 

Not sure there is sufficient program space go support this and it varies by location.


Richard
 

This may require a different firmware for each band.


Sheldon Hartling
 

I'm assuming the QCX knows which band it was built for; based on the stored answer to the "Select band:" question answered during initial setup.

Sheldon VE1GPY


Sheldon Hartling
 

Not sure there is sufficient program space go support this and it varies by location.
For sure about sufficient space!  I've developed firmware and am painfully award of the challenges trying to "shoe horn" additional features into very limited space. 

Even a range check that looks for reasonable (course) values for the band without following the specific regional band plan would be a help.  Right now, I threw my QCX into a sputtering fit by entering "70201" instead of "7020" in N1MM+. ☺︎

Sheldon VE1GPY


jjpurdum
 

Sheldon:

I think Hans is down to less than 10 bytes of unused memory. Another problem is that "out of band" likely varies at different places in the world. I'm not sure if Hans could use the EEPROM space, but that still means a change in the source code, and that's not going to happen.

Jack, W8TEE

On Wednesday, August 12, 2020, 12:38:25 PM EDT, Sheldon Hartling <ve1gpy@...> wrote:


Hi Hans,

 

Please consider validating the frequency values received in "FA" and "FB" CAT commands to confirm they are valid for the QCX's band.  Currently, in v1.5, out-of-band values are accepted and set the VFO to unsupported frequencies.  Easy to do, by accident, when hand-entering values in logging programs.

 

Thanks and 73, Sheldon VE1GPY

 


Arv Evans
 

Seems that all that is needed is for the QCX to inhibit keying for out-of-band 
frequencies.  This would leave it still able to listen to out-of-band stations.

_._


On Wed, Aug 12, 2020 at 11:04 AM Sheldon Hartling <ve1gpy@...> wrote:
Not sure there is sufficient program space go support this and it varies by location.
For sure about sufficient space!  I've developed firmware and am painfully award of the challenges trying to "shoe horn" additional features into very limited space. 

Even a range check that looks for reasonable (course) values for the band without following the specific regional band plan would be a help.  Right now, I threw my QCX into a sputtering fit by entering "70201" instead of "7020" in N1MM+. ☺︎

Sheldon VE1GPY


jjpurdum
 

That's still not cut-and-dried if out-of-band can vary among countries. The only alternative would be for Hans to offer specific 328 chips for each country for each band. That's a train just begging to leave the rails. I say this because, last I talked with Hans, he was down to less than 10 bytes of free memory.

Jcak, W8TEE

On Wednesday, August 12, 2020, 2:46:46 PM EDT, Arv Evans <arvid.evans@...> wrote:


Seems that all that is needed is for the QCX to inhibit keying for out-of-band 
frequencies.  This would leave it still able to listen to out-of-band stations.

_._


On Wed, Aug 12, 2020 at 11:04 AM Sheldon Hartling <ve1gpy@...> wrote:
Not sure there is sufficient program space go support this and it varies by location.
For sure about sufficient space!  I've developed firmware and am painfully award of the challenges trying to "shoe horn" additional features into very limited space. 

Even a range check that looks for reasonable (course) values for the band without following the specific regional band plan would be a help.  Right now, I threw my QCX into a sputtering fit by entering "70201" instead of "7020" in N1MM+. ☺︎

Sheldon VE1GPY


Arv Evans
 

Jack

Yes, it would probably need a few more bytes of memory to compare actual 
frequency with EEPROM stored "upper limit" and "lower limit" that could be 
a user entered semi-fixed variable.  Multi-band rigs could have upper and lower 
user settable limits for each band.

The 1602 display can store an additional 32 bytes of memory if you enable the 
R/W lead.

_._

On Wed, Aug 12, 2020 at 12:51 PM jjpurdum via groups.io <jjpurdum=yahoo.com@groups.io> wrote:
That's still not cut-and-dried if out-of-band can vary among countries. The only alternative would be for Hans to offer specific 328 chips for each country for each band. That's a train just begging to leave the rails. I say this because, last I talked with Hans, he was down to less than 10 bytes of free memory.

Jcak, W8TEE

On Wednesday, August 12, 2020, 2:46:46 PM EDT, Arv Evans <arvid.evans@...> wrote:


Seems that all that is needed is for the QCX to inhibit keying for out-of-band 
frequencies.  This would leave it still able to listen to out-of-band stations.

_._


On Wed, Aug 12, 2020 at 11:04 AM Sheldon Hartling <ve1gpy@...> wrote:
Not sure there is sufficient program space go support this and it varies by location.
For sure about sufficient space!  I've developed firmware and am painfully award of the challenges trying to "shoe horn" additional features into very limited space. 

Even a range check that looks for reasonable (course) values for the band without following the specific regional band plan would be a help.  Right now, I threw my QCX into a sputtering fit by entering "70201" instead of "7020" in N1MM+. ☺︎

Sheldon VE1GPY


Dave
 

Isn’t it rather on the licensed amateur to ensure he or she is within their band.  Pretty nonsense to expect a rig to do everything!

Dave


On Aug 12, 2020, at 14:58, Arv Evans <arvid.evans@...> wrote:


Jack

Yes, it would probably need a few more bytes of memory to compare actual 
frequency with EEPROM stored "upper limit" and "lower limit" that could be 
a user entered semi-fixed variable.  Multi-band rigs could have upper and lower 
user settable limits for each band.

The 1602 display can store an additional 32 bytes of memory if you enable the 
R/W lead.

_._

On Wed, Aug 12, 2020 at 12:51 PM jjpurdum via groups.io <jjpurdum=yahoo.com@groups.io> wrote:
That's still not cut-and-dried if out-of-band can vary among countries. The only alternative would be for Hans to offer specific 328 chips for each country for each band. That's a train just begging to leave the rails. I say this because, last I talked with Hans, he was down to less than 10 bytes of free memory.

Jcak, W8TEE

On Wednesday, August 12, 2020, 2:46:46 PM EDT, Arv Evans <arvid.evans@...> wrote:


Seems that all that is needed is for the QCX to inhibit keying for out-of-band 
frequencies.  This would leave it still able to listen to out-of-band stations.

_._


On Wed, Aug 12, 2020 at 11:04 AM Sheldon Hartling <ve1gpy@...> wrote:
Not sure there is sufficient program space go support this and it varies by location.
For sure about sufficient space!  I've developed firmware and am painfully award of the challenges trying to "shoe horn" additional features into very limited space. 

Even a range check that looks for reasonable (course) values for the band without following the specific regional band plan would be a help.  Right now, I threw my QCX into a sputtering fit by entering "70201" instead of "7020" in N1MM+. ☺︎

Sheldon VE1GPY


ajparent1/KB1GMX
 

Well since its cat if the users program sends out trash its on you, not like the
display on the radio and computer are turned off.  Tell your cat program
what boundaries apply.

I have plenty of radios that will go out of band and since I'm not an idiot I
just insure whats on t he dial is legal.  Or at least where I want to be.

I listened as a local dumbo run phone CQs for a half hour on 14.480mhz
(outside the band here in US).   No wonder why he got no takers.

Allison
-------------------------------
Please reply on list so we can share.
No private email, it goes to a bit bucket due address harvesting


Sheldon Hartling
 

Allison,

 

Yep, It would likely come down to operator error.  Unfortunately, it’s easy to do.  Many logging programs allow direct keyboard entry of frequencies.  It’s pretty easy to miss a key, hit the wrong key, or hit an extra key in error.  Especially in a contest.  Of course, We’d expect the operator to check the VFO before transmitting!  Meanwhile the radio has tuned to some very erroneous frequency.  Is there any danger running the QCX receiver WAY off frequency - say at 70Mhz instead of 7Mhz?

 

Another possibility is that a digit or two of the input CAT command gets dropped because of an LCD write conflict on the shared IC2 pins.

 

Sheldon. VE1GPY


Richard
 

On Wed, Aug 12, 2020 at 05:22 PM, Dave wrote:
Isn’t it rather on the licensed amateur to ensure he or she is within their band.  Pretty nonsense to expect a rig to do everything!
These days people rely on machines too much to keep them from making ID-10-T errors that would have never happened 15 or 20 years ago.  I agree that it should be up to the operator.  I'd rather have prosigns decoded than trying to idiot-proof the box.


Sheldon Hartling
 

Richard,

I agree, I’d prioritize additional CW characters/prosigns first.  It’ll be hard for Hans to make those “10 bytes” do all this. :-) 

Based on my experience so far, I probably won’t use the QCX CAT interface with a logging program anyway.  The CAT interface seems reliable.  :-(  With Log4OM, the program I use in the shack,  it only runs for a few minutes before Log4OM declares the QCX “off-line” and I find the QCX is no longer responsive to CAT commands.  Powering the QCX off/on restores the CAT interface.

 

It works better with N1MM+, the program I use in the field for POTA activations.  However, once in a while N1MM+ declares the QCX “is not responding” and I have to cycle the power on the QCX to restore the CAT port operation.

73 Sheldon VE1GPY


Sheldon Hartling
 

Should have been ...

The CAT interface seems unreliable :-(  


Shirley Dulcey KE1L
 

I wonder if the problem with the logging programs happens because the QCX doesn't receive CAT commands while the LCD is being updated? The programs may interpret that lack of response as the QCX being offline.


On Wed, Aug 12, 2020 at 7:30 PM Sheldon Hartling <ve1gpy@...> wrote:
Should have been ...

The CAT interface seems unreliable :-(  


jjpurdum
 

Ask your kids/grandkids to "write" something...write, not print. I was shocked to see some cannot write. I agree, we are putting too much faith in technology.

Jack, W8TEE

On Wednesday, August 12, 2020, 6:44:17 PM EDT, Richard <groups.io@...> wrote:


On Wed, Aug 12, 2020 at 05:22 PM, Dave wrote:
Isn’t it rather on the licensed amateur to ensure he or she is within their band.  Pretty nonsense to expect a rig to do everything!
These days people rely on machines too much to keep them from making ID-10-T errors that would have never happened 15 or 20 years ago.  I agree that it should be up to the operator.  I'd rather have prosigns decoded than trying to idiot-proof the box.


jjpurdum
 

I've wondered this, too. I'm running on a machine with a 3.8GHz clock talking to a xcvr with a mullti-core processor in charge of things. Then, along comes a push cart with tennis balls for wheels and we expect it to keep pace. There could be a problem here, Houston.

Jack, W8TEE

On Wednesday, August 12, 2020, 9:05:48 PM EDT, Shirley Dulcey KE1L <mark@...> wrote:


I wonder if the problem with the logging programs happens because the QCX doesn't receive CAT commands while the LCD is being updated? The programs may interpret that lack of response as the QCX being offline.

On Wed, Aug 12, 2020 at 7:30 PM Sheldon Hartling <ve1gpy@...> wrote:
Should have been ...

The CAT interface seems unreliable :-(  


Sheldon Hartling
 

Hi Jack,
The serial interface helps to equalize the massive differences in performance between the mighty PC and the lowly QCX. :-)  At 38400 baud with 1 start bit and 1 stop bit and no parity, the PC can not not push more than 3,840 characters a second at the QCX.  In practice, it’s much less!  Usually only a few CAT commands are sent from the PC to the QCX on every poll request and the polling interval is typically 1/2 second or 1/4 second.

 

Hi Shirley,

It certainly could be related to the shared serial/LCD lines.  The serial read might be stuck waiting for a command terminator character (;).  However, It almost seems like a timing issue or a buffer overrun.  Once the QCX stops responding to CAT commands, it remains broken even if you unplug the CAT cable and plug in a completely different CAT cable connected to a different computer.  By the time the logging program complains, the QCX has gone CAT deaf.

 

I discussed this problem a little more in another post (#51103 ).

73 Sheldon VE1GPY


David Fine
 

Allison,

When you heard the local dumbo calling CQ on 14.480 did you check to see if he was actually transmitting on 7.240.  I once heard a guy out of band on 20 mtrs, but then checked and found him on 40 mtrs.  I called him on 40 and told him, but he gave me the "I have good equipment" story and told me my receiver was at fault.  He later emailed me and apologized.  He found that his linear amplifier dipped in two different places and he chose the wrong one.

Dave, W0DF