Tnf removal

Doug - K3TZR

When I create a Tnf in SmartSDR and then subsequently remove it, the Radio responds with a "tnf <number> removed" message. If I create a Tnf in SmartSDR but remove it in another connected client (by sending "tnf remove <number>" no reply is generated other than R<seqnum>|0|.

Is this by design or is it a bug?

Bill -VA3WTB

what version of SSDR?

Doug - K3TZR

SmartSdr 2.2.8 with a local (i.e. not SmartLink) connection.

KC2QMA_John

I would love to just have  a simple "Delete All TNF" option, something that allows me to clear all TNF with a single click.

Doug - K3TZR

To clarify a bit, I'm using an app I created that connects to the Radio as a non-GUI client. When I start SmartSDR and my app I can see most of what is sent back and forth.

When I create a Tnf in SmartSDR and then delete it in SmartSDR I see the following (in my app):

S71E35CA3|tnf 32 freq=15.019872 depth=1 width=0.000099 permanent=0
S71E35CA3|tnf 32 removed
 
When I create a Tnf in SmartSDR and then delete it using my app to send the remove command, I see the following:

S71E35CA3|tnf 33 freq=15.019872 depth=1 width=0.000099 permanent=0
C223|tnf r 33
R223|0|

The creation looks the same but the removal doesn't generate the tnf <number> removed message .

Doug - K3TZR

That's a good idea and would be easy to implement from a non-gui client. Simply loop through the list of Tnf's and delete each one. Maybe one of the 3rd party apps out there will do that.

K1DBO

Doug,

I suspect that what you are seeing is by design.  All API commands generate a reply.  That's just the radio acknowledging the receipt of the command.  In some cases, the reply will include an error message or even useful information.  But, if the API command changes something interesting inside the radio, a "S" status message will also be generated.  The status message is often (always?) not sent to the client that requested the change in the first place.  The theory (I suspect) is that the client making the request knows what the effect of that request would be.  So when your client requests that a TNF be removed, already knows that the TNF is to be removed. It doesnt need the status message to tell it. But when SSDR removes a TNF, the only way your client would know is if it is sent a status message describing the change.

I do think the API would be a bit easier to use if a client could also subscribe to the status messages that it causes.  It would make the API a bit more "chatty" but also make it easier for the client to stay in sync with the radio.  But.... that's a whole other discussion.

--Don
  

Doug - K3TZR

Don,

Thanks for your reply. I agree with a lot of what you have said. I'm aware that all commands generate a reply type message. In my test case I can see the one sent to my client but the one sent to the radio is not visible to me. What I am more interested in is the "removed" status message. 

There are numerous other objects in the API that send a status message containing either "in_use=0" or "removed" to indicate that the object is no longer in use and is being removed. The API has evolved over a period of time and is not always consistent. I think this is just one of those cases.

As an example, if I create a Slice (using either SmartSDR or my client) and then remove it my client always receives the "slice 1 in_use=0 tx=0 active=0" message regardless of which app sent the remove command. If my client removes it, the status message has the handle of my client. If SmartSDR removes it, the status message has the handle of SmartSDR (and off course additionally, the remove command receives a "R<seqnum>|0| reply message).

To be consistent, I think that the "tnf <#> removed" message should be sent when my client removes it.

I can (and do at this point) interpret the reply to the remove command and when it is "R<seqnum>|0| know that the Tnf was deleted but if that is the intent, why not do that for all of the commands? Why have both types of messages, a reply that says your command was executed and a status message telling you it was executed? Personally, I like the "removed" or "in_use=0" types of status messages. 

I know this is a small point but I'm curious to know if there is a reason or if it's just an oversight.

Thanks for taking time to help.

Doug