Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
If you are having a problem, please check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.

Back to the UDP discovering protocol

IW7DMH, Enzo
IW7DMH, Enzo Member ✭✭
edited July 2017 in SmartSDR API
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

image



Answers

  • Walt - KZ1F
    Walt - KZ1F Member ✭✭
    edited January 2017
    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
    Walt - KZ1F Member ✭✭
    edited November 2016
    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
    Steve-N5AC Community Manager admin
    edited February 2017
    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
    IW7DMH, Enzo Member ✭✭
    edited December 2016
    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
    Walt - KZ1F Member ✭✭
    edited November 2016
    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
    Walt - KZ1F Member ✭✭
    edited November 2016
    I'll send you some snippets on that (demultiplexing data) as well.
  • Eric-KE5DTO
    Eric-KE5DTO Administrator, FlexRadio Employee admin
    edited February 2017
    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
    IW7DMH, Enzo Member ✭✭
    edited December 2016
    Thank you very much. I got it.

    73'
  • IW7DMH, Enzo
    IW7DMH, Enzo Member ✭✭
    edited January 2017
    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
    Eric-KE5DTO Administrator, FlexRadio Employee admin
    edited February 2017
    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
    Mark_WS7M Member ✭✭✭
    edited July 2017
    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
    Walt - KZ1F Member ✭✭
    edited November 2016
    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
    Steve-N5AC Community Manager admin
    edited December 2016
    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
    Mark_WS7M Member ✭✭✭
    edited April 2016
    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
    Walt - KZ1F Member ✭✭
    edited November 2016
    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
    Tim - W4TME Administrator, FlexRadio Employee admin
    edited December 2016
    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
    Steve-N5AC Community Manager admin
    edited December 2016
    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
    Walt - KZ1F Member ✭✭
    edited November 2016
    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
    N7BCP Member ✭✭
    edited November 2016
    If your radio client was always the last device to be started/turned on, this might work.
  • IW7DMH, Enzo
    IW7DMH, Enzo Member ✭✭
    edited March 2017
    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
    Mark_WS7M Member ✭✭✭
    edited April 2016
    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
    IW7DMH, Enzo Member ✭✭
    edited December 2016
    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
    Tim - W4TME Administrator, FlexRadio Employee admin
    edited December 2016
    There is a place to put this type of information and that is in the API wiki (http://wiki.flexradio.com)

Leave a Comment

Rich Text Editor. To edit a paragraph's style, hit tab to get to the paragraph menu. From there you will be able to pick one style. Nothing defaults to paragraph. An inline formatting menu will show up when you select text. Hit tab to get into that menu. Some elements, such as rich link embeds, images, loading indicators, and error messages may get inserted into the editor. You may navigate to these using the arrow keys inside of the editor and delete them with the delete or backspace key.