Radio ack

Mark Erbaugh

What FlexLib API requests get an Ack message from the radio? Is it just requests that don't return an immediate response? How does a program use Ack's? Should it wait for an Ack before doing anything further? Is it possible for more than one Ack to be pending, and if so, is there a way to tell which request is being Ack'ed?

Walt - KZ1F

Mark, you can grep through the code to find the SendReplyCommands. I believe most are in Radio.cs. And, yes, they pretty much are near instantaneous. But, for instance, would you want the UI to mark itself in transmit mode if, for whatever reason, the radio didn't switch to transmit mode? And you'll see in those cases there is behavior prior to sending the command but other behavior after a successful execution of the command. Take, for instance, my example of the display pan command. When it fails it makes no sense to try to instantiate a slice receiver on a non existent pan. or to set gain on a slice that didn't get populated because the panadapter didn't get built.

The other thing you can do is open a telnet session to <address> 4992 and let it just sit as you use the radio, it will display the command and it's response from the radio. A lot of interlocks before transmit for example.

There are been discussions on here about losing contact with the radio. In Radio.KeepAlive() you can see where that happens, while the radio is connected to, no point when it's not, a periodic ping is sent to the radio if there is no response it's a fair bet SSDR lost contact with the radio, no need to expect freq changes or PTT to work at that point.

Walt

Walt - KZ1F

If you meant strictly RadioAck, that is done more for property change than to allow synchronous logic to span asynchronous operations. There are about 9 different classes that share the 39 occurrences of it and the action is to notify those interested parties that an event took place. I would say generally speaking, these are to notify UI widgets but it can equally notify other classes that added a listener for specific events.  As above, for instance, you wouldn't want SSDR the UI to draw a TNF that didn't get built so, that would be an example of no you wouldn't want any part of the software to assume something happened. If you use that example, for instance, of the notch filter, the requesting one and drawing of one is pretty near instantaneous but still could take 100ms which is eternity in CPU execution.  Even though FRS made the source publicly available I don't feel comfortable discussing line by line where things occur. There is the API corner of this site which you can more freely discuss this stuff with Eric.

Eric-KE5DTO

Mark,

FlexLib uses the RadioAck property in several classes to indicate when the object has been synchronized with the radio.  For several resources like Slices and Panadapters, the client will make a request to the radio for the resource.  If successful, the radio will return information about the object (the center frequency for a Panadapter, for example).  Once the RadioAck property is set, the client can take action on those properties knowing that they are good values from the radio (as opposed to default values in the FlexLib object).  This is the nature of talking asynchronously to the radio.  I hope that answers your question.  If not, please clarify your specific question and I'll do what I can to help.

Mark Erbaugh

Eric,  Thanks. I had missed the issue that FlexLib might return invalid data before the RadioAck is received. Is there some documentation that explains the sequence of setting up things like Slices and Panadapters (w/o SSDR) that shows when one needs to wait for a RadioAck before proceeding? 

Another question?  If my program is setting up multiple slices and panadapters (for example), could the program have multiple requests that respond with RadioAck's outstanding and, if so, is there a way for the program to examine the RadioAck message to determine which request is being Ack'ed?

Eric-KE5DTO

Mark,

The sequence is:

1. Create the object: Slice slc = radio.CreateSlice();
2. Subscribe to the PropertyChanged event on that object: slc.PropertyChanged += new PropertyChangedEventHandler(Slice_PropertyChanged);
Inside this handler, you can do the following:
void Slice_PropertyChanged(object sender, PropertyChangedEventArgs e)
{
   Slice slc = sender as Slice;
   if(slc == null) return; // sender was not a Slice

   switch (e.PropertyName)
   {
      case "RadioAck":
         if(slc.RadioAck)
         {
            // do something here now that you know the object is ready
         }
         break;
   }
}

3. Then make the call to request the resource from the radio: slc.RequestSliceFromRadio();

Note that you can inspect the Slice object in the PropertyChanged event handler to look for a particular index or frequency once RadioAck is true to differentiate between multiple Slice objects.

Walt - KZ1F

I thought I had it before, clearly not.
Eirc, I have a question. Isn't RadioAck effectively synonymous with the added event? Be it Panadapter or Slice the StatusUpdate sets the set_radio_ack flag to true. After each kv pair is parsed if the set_radio_ack flag is true, for slice in_use=1 and for Pan somethng to do with waterfall, then the radio.OnSliceAdded or OnPanAdded is processed. I see now why my slice OnSliceAdded isn't fired, I do not see why the pan added event isn't fired, but in either case RadioAck is on if and only if, the event would have been fired, from what I can tell.

Would you clarify?

Thanks,
Walt


Eric-KE5DTO

Walt,

There is a chicken and egg thing happening when a developer creates a FlexLib object (Slice slc = radio.CreateSlice(14.1);).  As soon as you execute this line, you have a perfectly good Slice object that the radio knows nothing about.  Changing properties in that object will do no good at this point.  RadioAck is the property we have chosen to indicate when the radio and this object have been "synced", so to speak.  This happens when the RequestObjectFromRadio function is called.  This sends a command to the radio which generates a reply and subsequent status messages to fill in the details with any information the radio might provide (default frequency, Mode, etc).  This is how Slices end up with similar properties when they are made in proximity to another nearby Slice.  

In the instance where the radio is pushing information about an object (think persistence restore on startup), RadioAck is going to be true by the time you get the SliceAdded event.

Walt - KZ1F

"Changing properties in that object will do no good at this point". Yep, totally understand that. That is why any actions against that object were originally in the OnSliceAdded event callback, well, I don't call it that but it is the SliceAdded sink. When that wasn't getting invoked then I sort of had an issue.

I am trying to understand the subtle difference between a propertyChanged event and the RadioAdded event. It appears, esp in the case of a Slice they happen almost simultaneously. 
        if (set_radio_ack) {
            checkRadioACK();
        }

    public final void checkRadioACK() {
        Panadapter pan = _radio.FindPanadapterByStreamID(_panadapterStreamID);
        if (!_radioAck && _fullStatusReceived && ((pan != null && pan.getRadioAck()) || _panadapterStreamID == 0)) {
            _panadapter = pan;
            setRadioAck(true);
            _radio.onSliceAdded(this);
        }
    }
Just, by way of background. My use of propertyChanged be it in Swing or JavaFX is it more reflects the change of an attribute to coordinate the visual representation of an object's attribute as opposed to the object's existence.

For instance, an early artefact of the issue with the Panadapter than never got displayed was in the RX dialogBox on the right hand vertical 'tower' of tabbed dialogs was completely void of any information as no Pan meant no Slice meant no currently tuned frequency.
I could be missing something but it sounds like there are two notification vehicles. Since the visual representation of it is a different 'sub project' I, frankly, hadn't wired the propertyChanged notifications. It's wired now.

Eric-KE5DTO

I am trying to understand the subtle difference between a propertyChanged event and the RadioAdded event.

First, some background.  The PropertyChanged event and the whole pattern of handling changed events like this is an industry standard for Model-View-ViewModel (MVVM) designs.  Using the ObservableObject class, a wrapper around the INotifyPropertyChanged interface, it makes it easy to propagate events up the Model tree.  Googling for examples of C# MVVM, INotifyPropertyChanged, etc will yield much reading about that.

Then we have 2 unique things we are using:

1. <object>Added events (e.g. SliceAdded, PanadapterAdded, etc).  These are used to signify that a new object is now available (and gives a reference to said object.

2. RadioAck property.  Using the PropertyChanged mechanism, we can wait for this to ensure that the object is synced with the radio to ensure changes are reflected on both the client and the radio.

Often times these 2 things will happen concurrently.  These concepts do serve different purposes though as one requires that you already have a reference to the object (and are subscribed to the PropertyChanged event).  The other actually offers a reference that would allow such a connection.  I hope this helps.

Walt - KZ1F

This is weird, I could have sworn I just did my history with MVC. Yes, I understand MVC as the case where a Text item or a RadioButton or Slider or some other graphic representation is bound to the backing attribute in an object, not the object itself. I get that, in the above case you are sending a property notification for something that doesn't exist yet as both notifications will fire from the same thread. Using the prior method of instantiation, requestPanFromRadio() one creates an empty pan then passes that to Radio to activate. Using Radio.createPanafall, you aren't passing in an object to take action on as the pan object is created in Radio and the user doesn't have visibility to it. I was just referring to using propertychangenotification for objects and objects that don't yet exist.
OK, so that's how you chose to do it.

Yes, I am familiar with  MVVM and am very familiar with Martin Fowler who first proposed it.