Howto disconnect and re-connect to radio / api?

Bill - K7UOP

I have a Radio Class where I can connect to various radio types via RS-232 and now the FlexLib API. On program start I successfully connect to my 6700 but if I switch to a different radio and then back to the Flex via the API it doesn't re-discover the radio.

Right now, to disconnect the radio and API, I'm trying:
API.CloseSession();
Thread.Sleep(1000);
radio.Disconnect();
then remove my Class object, Flex6K_APIradio = null;

and get a output result of:
API_RadioRemoved Fired: 192.168.0.110 FLEX-6700: xxxx
API_RadioRemoved Fired: 192.168.0.110 FLEX-6700: xxxx
The thread 'FlexAPI Discovery Thread' (0xbd0) has exited with code 0 (0x0).

Don't know why API_RadioRemoved is fired twice.
Had to add the sleep() or the radio was re-discovered before the Discovery Thread was exited.

But later when I try to re-connect:
by creating a new Flex6K_APIradio and initialize (in my class constructor):
   radio event handlers and program name and
   API.Init();

the radio is NOT re-discovered and the API_RadioAdded() event does NOT fire.

I expected that API.Init() would turn radio Discovery back on but guess I'm mistaken.

What is the proper way to completely disconnect from the radio / API so that it will be re-discovered when my class constructor is called, same as it does at program start?

What am I doing wrong?

--Bill - K7UOP

Eric-KE5DTO

The events generated in the API class are oriented around the presence of the radio. Calling disconnect on the radio class will not cause another RadioAdded event to fire. To do what you are describing, you would need to either store a reference to the radio somewhere to use when reconnecting or use the ObservableCollection RadioList in the API class to search for such a reference.

Bill - K7UOP

Thanks for the reply Eric,

I probably had too much information in my initial post...

API.CloseSession() (FlexLib v1.3.0.25781) turns off radio discovery which then allows me to disconnect from the radio.  I expected some way to turn discovery back on.  As I said, I expected that API.Init() would turn radio discovery back on, it does not.

You suggest that I stay connected to radio. In fact, I did this in my program as a workaround so I could re-select the Flex radio after being connected to a different radio. Problem is though that all the events I subscribed to on the Flex (like slice.SmeterReady) are still firing in the background (not a good thing). I could manually back out these event handlers but it would be better to just disconnect from the radio and API session.

Right now, radio discovery is initiated only on program startup. Seems like there should be a way to programmatically turn radio discovery back on, ideally via API.Init().

Eric-KE5DTO

I can see how you got there.  I need to get together with the developer that added the CloseSession function to understand it's intended purpose.  Today it simply stops the discovery thread.  We use it in SmartSDR only when shutting the application down.

Unfortunately, the approach you took will not work as we set a boolean flag (initialized) when you call Init so that calling it multiple times would not cause multiple discovery receivers to be created.

=====
Back to how to do what you're trying to do...
I am not suggesting that you stay connected to the radio.  I am suggesting that you need to keep a reference to the radio around so that when you want to connect to it, you can simply call the .Connect() routine on it.  If it makes it easier on you if we have a way to turn discovery on/off, we can do that as well.

Your approach just didn't occur to me as I had always treated the API list as the complete list of radios which had shown up so far.  I think the approach changes when in an environment like our office where there can be 10s of radios showing up on that list.  Just removing a radio and connecting to the next one that shows up when you turn discovery on would lead to connecting to the wrong radio here.  This is unlikely to be an issue in most of our customer's locations, but consider if your app might one day be in use at Field Day or some other venue with multiple radios on the network.

I love how programming allows lots of ways to solve a problem and thinking about things in different ways.  Thanks for the opportunity.  

Bill - K7UOP

As usual, email or posts make it difficult to discuss all of the details with something as complex as programming.

In the approach I'm taking, I do create a menu of available radios. But, as in the CAT program example, if only one radio is found I automatically connect to that one. Of course, not fully tested since I only have one radio.

I've been trying to implement your suggestion but keep running into issues. Using a global reference to the radio and logic seems a ticklish business. For now (for instance) I've given up trying to update my radio list combobox and handling selectedIndex change events when setting up to re-connect to the radio. Probably not impossible ("anything's possible in software" , just more convoluted.

Ran into other issues that I won't go into now. Phone or Skype would be better for more detail.

IF API.Init() made sure "discovery" is running, seems like things would be a lot more straight forward. And would then follow the simple sequence in your response to a previous post: First steps with FlexLib . Even after a call to API.CloseSession().

Bill - K7UOP

You said, "... we set a boolean flag (initialized) when you call Init so that calling it multiple times would not cause multiple discovery receivers to be created."

It occurred to me that calling API.CloseSession() could set initialized=false.  That way, when subsequently calling API.Init(), discovery would be turned back on and normal startup events would occur.

It may not be that simple, but it might be.

Bill - K7UOP

Got API.CloseSession working as I requested. Eric (Flex Radio developer) made a change in FlexLib but there was still a problem. I found the problem in Discovery.Receive(). I expect the fixes will be in the next release of FlexLib.