Welcome to the FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
Need the latest SmartSDR or 4O3A Genius Product Software?
SmartSDR v3.9.19 and the SmartSDR v3.9.19 Release Notes
SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
The latest 4O3A Genius Product Software and Firmware
SmartSDR v3.9.19 and the SmartSDR v3.9.19 Release Notes
SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
The latest 4O3A Genius Product Software and Firmware
If you are having a problem, please refer to the product documentation or check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
TNF support
Jim Shaffer
Member ✭✭
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?
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?
1
Answers
-
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?0 -
How do I get the TNF status messages? I am not getting any TNF added interrupts unless I add a TNF.0
-
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);
0 -
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.0
-
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?0 -
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 WD5GWY0
-
If this is the case, it is a bug. TNF should not be restricted to the GUI client. Jim, can you confirm?0
-
UPDATE: It looks like this is a bug. I have added Issue #2473 to address this. Thanks for helping us find that one!1
-
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.0 -
Jim, I'll be there. I'm sure we can figure this out.0
Leave a Comment
Categories
- All Categories
- 339 Community Topics
- 2.1K New Ideas
- 607 The Flea Market
- 7.9K Software
- 6.3K SmartSDR for Windows
- 172 SmartSDR for Maestro and M models
- 405 SmartSDR for Mac
- 265 SmartSDR for iOS
- 248 SmartSDR CAT
- 186 DAX
- 372 SmartSDR API
- 9.2K Radios and Accessories
- 19 Aurora
- 195 FLEX-8000 Signature Series
- 7.1K FLEX-6000 Signature Series
- 916 Maestro
- 53 FlexControl
- 859 FLEX Series (Legacy) Radios
- 888 Genius Products
- 451 Power Genius XL Amplifier
- 321 Tuner Genius XL
- 116 Antenna Genius
- 283 Shack Infrastructure
- 199 Networking
- 442 Remote Operation (SmartLink)
- 137 Contesting
- 744 Peripherals & Station Integration
- 137 Amateur Radio Interests
- 964 Third-Party Software