DSP API anomalies on mode change

  • 1
  • Problem
  • Updated 4 years ago
On any mode change, the DSP functions of NR, ANF or APF are turned off in the radio (you can hear the difference) but status messages emitted are inconsistent.

For example; here is a sequence where the mode is set to LSB, ANF and NR are turned on and then the mode is changed to CW.

S3BBEF666|slice 0 anf=1 anf_level=50
S3BBEF666|slice 0 nr=1 nr_level=50
S3BBEF666|slice 0 agc_mode=med agc_threshold=60 agc_off_level=50
S3BBEF666|slice 0 agc_mode=med agc_threshold=60 agc_off_level=50
S3BBEF666|slice 0 agc_mode=med agc_threshold=50 agc_off_level=50
S3BBEF666|slice 0 mode=CW filter_lo=-200 filter_hi=200 agc_mode=med agc_threshold=50 agc_off_level=50 qsk=0 step=10 step_list=1,5,10,50,100,200,400
S3BBEF666|slice 0 nr=0 nr_level=50
S3BBEF666|slice 0 nb=0 nb_level=50
S3BBEF666|slice 0 apf=0 apf_q=30
S3BBEF666|slice 0 qsk=1

There is no status message for ANF being turned off.

This has required me to add logic into my interface library for ObjectiveC that doesn't belong there....  i.e. set all DSP related functions OFF on a mode change.

Is this the intent or is this a bug?

Thanks
Stu K6TU

Photo of Stu Phillips - K6TU

Stu Phillips - K6TU, Elmer

  • 642 Posts
  • 256 Reply Likes
  • puzzled...

Posted 4 years ago

  • 1
Photo of Steve - N5AC

Steve - N5AC, VP Engineering

  • 1007 Posts
  • 969 Reply Likes
This is really an oversight so it qualifies as a bug.  Ideally what we would do would be to enumerate all of the DSP algorithms for each mode, saying which are enabled or not.  Then if we added a new DSP algorithm, you would get that in a string.  While this is all dynamic and fancy, it makes your implementation a lot harder since you would have to know for each of these whether there is a button or a slider, and what does, blah blah.

One way to implement what you are suggesting would be to have a separate parameter like "anf_enabled=0|1" that indicates if you should even show the button/slider at all.  We could also co-opt the on off variable to be "anf=0|1|disabled".  This first method seems cleaner if not more verbose.

Thoughts?
Photo of Stu Phillips - K6TU

Stu Phillips - K6TU, Elmer

  • 642 Posts
  • 256 Reply Likes
Steve,

I think the simpler approach would be to just use the existing status messages and error responses...

For example, simply send out a status of 

slice 0 anf=0 nr=0

when the mode is changed to something that doesn't support them like DIGL/U.

That way at least the user control would be turned off.  The anf=disabled makes sense in so far as it allows the UI to remove the control.  This is like vox_visible that was in the API at one point...

The interesting meta question here is the knowledge of the partitioning of logic between the radio and the UI - what level of knowledge is appropriate to embed in the client versus being told by the radio.

For now, just getting consistent status messages from the radio on changes would be ideal.

Stu K6TU
Photo of Steve - N5AC

Steve - N5AC, VP Engineering

  • 1007 Posts
  • 969 Reply Likes
So would you prefer the behavior to work like you suggest and then if the person presses the button (for a disabled function), we detect that the algorithm isn't present and send back an error and a refresh on a value of zero?
Photo of Stu Phillips - K6TU

Stu Phillips - K6TU, Elmer

  • 642 Posts
  • 256 Reply Likes
That would be perfect! :-)

Stu
Photo of Steve - N5AC

Steve - N5AC, VP Engineering

  • 1007 Posts
  • 969 Reply Likes
RRR this is DE1753
Photo of Ed.G

Ed.G, Software Engineer

  • 86 Posts
  • 20 Reply Likes
This should be fixed in the next alpha. 

A mode change will now report a DSP algorithm as off if it doesn't apply to that mode.

Photo of Stu Phillips - K6TU

Stu Phillips - K6TU, Elmer

  • 642 Posts
  • 256 Reply Likes
Awesome!
Thanks
Stu