Back to the UDP discovering protocol

IW7DMH, Enzo

Hello,

I am going to look more in depth at the discovering protocol in the official FlexLib implementation (ver. 1.6.21). I did a reverse engineering of the Flex.Smoothlake.Vita package, for the part (I suppose) involved in the discovering protocol.
Looking in the FlexLib package I found a Discovery Class that I suppose I have to instantiate to start the discovering process.
What am I missing is the right sequence to declare-instantiate-run the discovery process.
I would be glad if someone could help me.

73' Enzo
iw7dmh

Walt - KZ1F

Good afternoon Enzo. I'll be happy to help when I return from the gym, 90 mins. Do you have a language preference? Also, part of discovery is discovering a radio went away.

Walt - KZ1F

Did you create class diagrams? I should put XPSLib classes in Enterprise Architect to produce the ERDs. An email is on it's way.

Steve-N5AC

Have you looked at the RadioAdded and RadioRemoved events?  You should be able to instantiate the API and bind handlers to these events to see when radios are found or lost (leave network):

    API.RadioAdded += new API.RadioAddedEventHandler(API_RadioAdded);
    API.RadioRemoved += new API.RadioRemovedEventHandler(API_RadioRemoved);

IW7DMH, Enzo

Hello Walt,

yes I did it. I am using a 2012 Visual Studio Ultimate version we use in my University.
You teach me that structure is not enought in OOP. The best would be a sequence diagram
And this is what I am going to better understand.
Somewhere else I expect to find the code that identifyies each particular packet and emit the related event.

Walt - KZ1F

I am not sure how certain people would respond if I did a full UML doc set on flexlib. It might be illuminating to find out. Kind of like Matt Damen (The Martian) on contemplating being the fastest man in space. Ya have to see the movie to understand the reference.

The email I referenced has code snippets of what would otherwise be a sequence diagram if it were a picture rather than code fragments. It's based on XPSLib however but can easily be mapped to comparable methods in flexlib.

Walt - KZ1F

I'll send you some snippets on that (demultiplexing data) as well.

Eric-KE5DTO

If you're trying to just _use_ FlexLib, I agree with Steve -- use the events.  If you're trying to understand how it works, then you'll want to have a look at Discovery.cs.  Feel free to ask questions as you go.

IW7DMH, Enzo

Thank you very much. I got it.

73'

IW7DMH, Enzo

Hello Steve and Eric,

thank you very much for your answers.
I did some tests using the official libraries and I have a basic knowledge of the "events" approach. Now I would like to understand how it works. I realized that I missed at all the "API" class where most of the object in the diagram are instantiated.
I am wondering if, adding the API class to the above diagram, I have the whole set of classes needed to implement the discovering protocol.
 

Eric-KE5DTO

Well, the API class definitely references the Radio class.  And Radio references...well, pretty much everything else.    I do think the majority of what you're looking for is in API.cs and Discovery.cs on the startup/discovery.

The actual code that connects to the Radio is in the Radio class (see Connect function).

Mark_WS7M

Am I correct in assuming that "undiscovering" a radio is really a case of a timer where if no UDP discovery packet arrives from the radio in some duration and you are not connected to the radio actively that the radio is in effect undiscovered?

Walt - KZ1F

Radios broadcast discovery packets at regular intervals, whether one is connected or not. Currently, so long as you are on the same subnet and listening for broadcasts you've discovered the radio if you decode the discovery packet.

Steve-N5AC

Mark, you are correct in the first part -- it is a timer. But the discovery protocol is a connectionless broadcast so no connection is involved. When on, the radio continually emits discovery

Mark_WS7M

Thanks Walt and Steve.  I got that.  I wasn't sure if once you connect to a radio if it still sent out broadcasts but actually I should know the answer since I rely up on that in my HRI Agent.

So to "undiscover" a radio we basically start a timer on the last received UDP discovery broadcast and if we don't see another one in some period of time we say ok the radio is no longer there.

What is the period of time?  The UDP broadcasts seem to come about once a second I think so I guess reasonable amount of time might be like 5 seconds or something?

Walt - KZ1F

Or...put that differently, whenever you see a broadcast, key on serial number, update the current time. If you already have it update the time. If, after a couple of seconds or a minute or 30 seconds, whatever, you stop seeing it, you have then discovered it's gone. I am avoiding your other question as just because you didn't get a periodic broadcast doesn't mean the radio is gone. It could mean the broadcast got eaten by something else on the wire, so, for instance, in XPSLib (safer than talking about what someone else wrote) I give it 3 seconds to determine if there is but one radio present or more than one. I can support multiple radios if there are more than one. If there is only the one, no need for the chooser dialog, I can auto connect. In Java one can schedule a periodic task to run, say, cleanup() and in that I interrogate lastHeard time and act accordingly.

My take...if you are presenting a chooser dialog you likely don't want to list absent radios but other than that it makes sense to schedule that cleanup when you do regular housekeeping chores.

Tim - W4TME

Mark - I think the timeout for SSDR is ~15 seconds, but you can easily test it by running SSDR, disconnecting the SSDR client from the network and measure the time delta between disconnect and the radio disappearing from the radio chooser.

And make sure your app keeps listening and adds the radio back to your available radio list once you hear it's UDP broadcast packets again.  Your radio chooser should have logic to handle multiple radios too.

Steve-N5AC

Mark, you can safely ignore Walt's comments if you are using the SmartSDR API in FlexLib because it does all this for you.  If you want to see the details and understand what it's doing, have a look at API.cs and just search for discovery.  The timeout value is set with RADIOLIST_TIMEOUT_SECONDS, a constant and equal to 15s in the API.

Walt - KZ1F

Wow...where to start. What Mark and I have been talking about for about a month now is his C++ program that is a, or becoming a, facsimile of SSDR. However, similar to William, his is a straight TCP/UPD program. So, over the last month we've been discussing how various, let's call them, supervisory, functions would be handled and appropriate. This dovetailed very nicely with conversations I've also had with Enzo on how to accomplish something, in his case, he was writing it in Java, or contemplating it as a language of choice, where I've sent him code fragments to demonstrate an approach. Neither C++ nor Java lend themselves to using Flexlib. In fact, I mentioned I was not talking about Flexlib.

Now to the computer science of it. Just as with spot (station heard) notifications, radio presence notification is point in time. It is important really only when the user wants to see relevant data. Mark's comment was "we basically start a timer on the last received update from it". That's probably not the best way to handle that.

If a facsimile of SSDR either knew there was only a single radio present or only heard a single radio present there is little reason to require multiple keystrokes via the discovery dialog...or one could safely draw that conclusion. At what point would it be wise or relevant to housekeep old dated information? I would argue either at the point a user asked for the, then current, state information, or at some opportunistic time when the software might be doing other periodic cleanup activities.

I am awed that you, as vendor, would start a paragraph with "You can safely ignore Walt's comments", especially given the context and the science. I am very disappointed.

N7BCP

If your radio client was always the last device to be started/turned on, this might work.

IW7DMH, Enzo

From a C# developer perspective, what would be the effort to build a gui component like a simple rig selector Listbox.
Also, can C# gui components be shaped using external xml style-sheets or similars?

Mark_WS7M

Enzo, I did a movie of this process using FlexAPI.  See this link:

https://community.flexradio.com/flexradio/topics/from-flexapi-1-6-17-to-a-wpf-application

As far as shaping it, it is possible to create your own controls. Just harder to do so.  You can give some some definite look and feel and get creative.  

For example in SSDR from FRS the controls are not "standard".  They have some custom controls in that app that give it a unique look/feel.

IW7DMH, Enzo

Thank you very much Mark, it is a very well documented example, Tim should stick it somewhere.
Before going deeper into it I have another question about the embedded devices that can support C#. Can FlexLibs be used on Windows IoT? Probably you already talked about this subject but I can't find informations.

73' Enzo

Tim - W4TME

There is a place to put this type of information and that is in the API wiki (http://wiki.flexradio.com)