TNF support

Jim Shaffer

When is TNF support coming to FlexLib?
I can create and request a TNF, but then the TNF is not present after the radio is powered off, even though the TNF was marked as permanent.  I request the TNF by issuing the TNF.RequestTNFFromRadio() function, and had to uncomment the _radio.SendReplyCommand() call, and making a small update to updateId().
I can get around this by saving the TNFs myself, and recreating them.  However, if I terminate my program, causing a disconnect, but don't power the radio off, the TNFs are still there, but I get no TNFAdded interrupt upon reconnecting and loading my default profile.
In other words, when I bring up my software, I have no idea whether the radio has tNFs defined or not.
I'm wondering how the SmartSDR software deals with this?  It appears that the radio itself is not reporting its defined TNFs, but maybe I've missed something?

Eric-KE5DTO

Jim,

Have you looked at the RequestTNF function in radio.cs?  Between this and the status message handling built into FlexLib, the TNF functionality should all be there.  This is all that we use for the TNF functionality in SmartSDR-Win, so anything we do there, you can do with FlexLib.  Are you seeing TNF status messages?

Jim Shaffer

How do I get the TNF status messages?  I am not getting any TNF added interrupts unless I add a TNF.

Eric-KE5DTO

The TNF list is dumped to a client via status messages when the UDP port is set.  See public bool Connect() in radio.cs and look for:

// set the streaming UDP port for this client               
SendCommand("client udpport " + API.UDPPort);

Jim Shaffer

Huh?  Sorry, I'm totally confused now.  The only TNF status I can find is the TNFAdded event, which I don't get upon connect.

Eric-KE5DTO

Upon setting the udpport, the radio will send tnf status messages (status messages that begin with "tnf").  These get handled in ParseStatus in radio.cs (see case "tnf").  This checks the tnf_id to see whether the referenced TNF object already exists in the client or whether it needs to add it.  This logic should eventually end up firing the TNFAdded event after calling the StatusUpdate function in TNF.cs.

If you aren't seeing these, it is likely that the radio is not storing them as permanent for some reason.  Does this feature work in SmartSDR properly for you?

James Whiteway

Jim, is your program a GUI client? It may be if it is not ,the status is only being sent to the GUI client (SSDR if it's running alongside your app) setting isGUI = true should fix that IF that's the problem . Before I started making my test app's the GUI client, there were several properties that I had issues getting status messages back for. James WD5GWY

Eric-KE5DTO

If this is the case, it is a bug.  TNF should not be restricted to the GUI client.  Jim, can you confirm?

Eric-KE5DTO

UPDATE: It looks like this is a bug.  I have added Issue #2473 to address this.  Thanks for helping us find that one!

Jim Shaffer

Eric, first of all, I am setting IsGUI to true.  I've tried adding a TNF both with Permanent set and not set.  In neither case do I get a tNFAdded event upon a reconnect.  I do see a TNFAdded event when I add the TNFs originally.
However, I can tell the radio thinks the TNFs are present, because when I add the second TNF, which I did after a reconnect, the id is 2.
The sequence is:
1:  Add a TNF, Permanent = false.
2:  Shutdown the program, disconnecting the radio.
3:  Bring up the program, connecting the radio.
4:  Add another tNF, Permanent = true.
Note:  I've watched the _tnf list in tnf.cs, and after adding the second tnf, it only shows that tnf; _tnf.count is 1.  However, the id on the second tnf is 2.
I am unable to use the SmartSDR client.  I'm the guy updating my JJRadio software for use by blind users.
Maybe we can talk about this on the 26th if you're going to be around for my presentation.  It isn't absolutely critical that I solve this problem immediately.

Eric-KE5DTO

Jim, I'll be there. I'm sure we can figure this out.