Back to the UDP discovering protocol

  • 1
  • Question
  • Updated 2 years ago
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

Photo of IW7DMH, Enzo

IW7DMH, Enzo

  • 350 Posts
  • 83 Reply Likes

Posted 2 years ago

  • 1
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 642 Reply Likes
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.
(Edited)
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 642 Reply Likes
Did you create class diagrams? I should put XPSLib classes in Enterprise Architect to produce the ERDs. An email is on it's way.
(Edited)
Photo of IW7DMH, Enzo

IW7DMH, Enzo

  • 350 Posts
  • 83 Reply Likes
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.
(Edited)
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 642 Reply Likes
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.
(Edited)
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 642 Reply Likes
I'll send you some snippets on that (demultiplexing data) as well.
Photo of IW7DMH, Enzo

IW7DMH, Enzo

  • 350 Posts
  • 83 Reply Likes
Thank you very much. I got it.

73'
Photo of Steve - N5AC

Steve - N5AC, VP Engineering

  • 1007 Posts
  • 970 Reply Likes
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);


Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 661 Posts
  • 203 Reply Likes
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.
Photo of IW7DMH, Enzo

IW7DMH, Enzo

  • 350 Posts
  • 83 Reply Likes
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.
 
Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 661 Posts
  • 203 Reply Likes
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).
Photo of Mark - WS7M

Mark - WS7M

  • 959 Posts
  • 339 Reply Likes
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?
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 642 Reply Likes
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.
(Edited)
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9052 Posts
  • 3435 Reply Likes
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.
Photo of Steve - N5AC

Steve - N5AC, VP Engineering

  • 1007 Posts
  • 970 Reply Likes
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.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 642 Reply Likes
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.
Photo of Larry da Ponte

Larry da Ponte

  • 159 Posts
  • 15 Reply Likes
If your radio client was always the last device to be started/turned on, this might work.
Photo of IW7DMH, Enzo

IW7DMH, Enzo

  • 350 Posts
  • 83 Reply Likes
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?
(Edited)
Photo of Mark - WS7M

Mark - WS7M

  • 959 Posts
  • 339 Reply Likes
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.
Photo of IW7DMH, Enzo

IW7DMH, Enzo

  • 350 Posts
  • 83 Reply Likes
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
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

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