Register your application

Walt - KZ1F

I am reasonably certain I know the answer but the references to registering your app still exist and the API to setProgramName() fails with invalid program name.

1) is registering one's app still necessary? or advisable?
2) what is the function of setProgramName and why does it fail? I assume it fails because it is not SmartSDR.
3) what does setGUI do? <- I thought I'd throw that in to clear it off the list.

Eric-KE5DTO

Walt, Can you reference the code to which you are referring?

Walt - KZ1F

In Radio::Connect():750

                // send client program to radio
                if (API.ProgramName != null && API.ProgramName != "")
                    SendCommand("client program " + API.ProgramName);

                if (API.IsGUI) SendCommand("client gui");

Sorry Eric, I less than accurately referred to client program = as setClientProgram.

As you can see though, it does, sort of, imply had one registered the program on the nifty program registry dialog, and it was on the NDA application form, that the client program "OtherSmartSDR might not fail.

sending cmd C3|client program OtherSmartSDR
received reply  R3|10000002|unknown client program

Walt - KZ1F

It would be easy to dismiss as 'appears to be unnecessary, so I will remove it. There was a time back in the 60's and 70's where guys routinely did that to pieces of their first car and really unpleasant things happened as a result.

The net of some of these questions are:

 I can create a radio, I issue the API.Init(), I get onRadioAdded called.
I can populate the radio with callbacks for pan added/removed and slice added/removed
I can connect to the radio object (the radio proper)
From what you wrote in First Steps with flexlib https://community.flexradio.com/flexradio/topics/first_steps_with_flexlib, that should be all I need to do to see the pan added via onPanadapterAdded and see the invocation of onSliceAdded.

To this point there are no errors but no callbacks.
It's when I get creative with building a pan and a slice that status goes from 4 pans 4 slices (available) to 2 pans 2 slices avail and I only created the 1 of each.

The following is all I should need to do, correct?

    public void radioAdded(Radio radio) {
        activeRadio = radio;
        PanadapterAddedEventHandler panAdded = (Panadapter panx, Waterfall fall) -> processPanAdded(panx, fall);
        PanadapterRemovedEventHandler panRemoved = (Panadapter pan) -> processPanRemoved(pan);
        activeRadio.addPanAddedEventListener(panAdded);
        activeRadio.addPanRemovedEventListener(panRemoved);
           
        SliceEventHandler sliceAdded = (Slice slc) -> processSliceAdded(slc);
        SliceEventHandler sliceRemoved = (Slice slc) -> processSliceRemoved(slc);
        activeRadio.addSliceAddedEventListener(sliceAdded);
        activeRadio.addSliceRemovedEventListener(sliceRemoved);
        activeRadio.Connect();

// at this point, what I think is happening the onPanAdded callback is never called, so any action against the panadapter is, likely before it is well formed. Ditto for the slice as the call back there isn't triggered either.



I am trying to deduce if there is something I should have done but didn't or is it due to being an unregistered app or not having specified it is a gui.

log follows:

Discovered /192.168.0.11 FLEX-6500: 3413-0588-6500-5922 (0x6AFE9936)
Entered Radio Added /192.168.0.11 FLEX-6500: 3413-0588-6500-5922 (0x6AFE9936)
Signalling Connected changed
sending cmd C3|client program OtherSmartSDR
sending cmd C4|sub tx all
sending cmd C5|sub pan all
sending cmd C6|sub slice all
sending cmd C7|sub gps all
sending cmd C8|info
sending cmd C9|version
 sending cmd C10|ant list
Signalling ClientID changed
 sending cmd C11|mic list
sending cmd C12|profile global info
sending cmd C13|profile tx info
sending cmd C14|profile mic info
 sending cmd C15|profile display info
sending cmd C16|client udpport 4991

received reply  R3|10000002|unknown client program

received msg M10000001|Client connected from IP 192.168.0.2

received status S8B8F1BBA|radio slices=4 panadapters=4 lineout_gain=53 lineout_mute=0 headphone_gain=54 headphone_mute=0 remote_on_enabled=0 pll_done=0 freq_error_ppb=0 cal_freq=15.000 tnf_enabled=1 snap_tune_enabled=1 nickname=Walt/kz1f callsign=KZ1F binaural_rx=0
11:26:43.639 [pool-2-thread-3] DEBUG org.cornova.smartersdr.flex.Radio - received status slices=4 panadapters=4 lineout_gain=53 lineout_mute=0 headphone_gain=54 headphone_mute=0 remote_on_enabled=0 pll_done=0 freq_error_ppb=0 cal_freq=15.000 tnf_enabled=1 snap_tune_enabled=1 nickname=Walt/kz1f callsign=KZ1F binaural_rx=0

received status S8B8F1BBA|interlock timeout=0 acc_txreq_enable=0 rca_txreq_enable=0 acc_txreq_polarity=0 rca_txreq_polarity=0 tx1_enabled=1 tx1_delay=0 tx2_enabled=1 tx2_delay=0 tx3_enabled=1 tx3_delay=0 acc_tx_enabled=1 acc_tx_delay=0 tx_delay=0

received reply  R4|0|
received status S8B8F1BBA|transmit freq=0 lo=100 hi=2900 tx_filter_changes_allowed=1 tx_rf_power_changes_allowed=1 rfpower=100 tunepower=10 am_carrier_level=100 vox_enable=0 vox_level=50 vox_delay=12 mic_level=78 mic_selection=MIC mic_boost=1 mic_bias=0 mic_acc=0 compander=1 compander_level=70 dax=0 pitch=600 speed=20 iambic=1 iambic_mode=1 cwl_enabled=0 swap_paddles=1 synccwx=1 break_in=1 break_in_delay=53 sidetone=1 monitor=0 mon_gain_cw=49 mon_gain_sb=80 mon_pan_cw=50 mon_pan_sb=50 tune=0 met_in_rx=0 hwalc_enabled=0 inhibit=0 speech_processor_enable=1 speech_processor_level=2 show_tx_in_waterfall=0 mon_available=1

11:26:43.673 [pool-2-thread-3] DEBUG org.cornova.smartersdr.flex.Radio - received reply  R5|0|
received reply  R6|0|
received status S8B8F1BBA|waveform installed_list=
Signalling WaveformsInstalledList changed
received reply  R7|0|
received status S8B8F1BBA|gps lat=N 41 49.795#lon=W 071 53.882#grid=FN41bt#altitude=117 m#tracked=9#visible=0#speed=0 kts#freq_error=0.000000e+00#status=Not Present#time=15:26:43Z
received reply  R8|0|model="FLEX-6500",chassis_serial="3413-0588-6500-5922",name="Walt/kz1f",callsign="KZ1F",gps="Not Present",atu_present=1,num_scu=1,num_slice=4,num_tx=1,software_ver=1.4.11.60,mac=84:7E:40:39:04:2E,ip=192.168.0.11,netmask=255.255.255.0,gateway=192.168.0.1,location="",region="USA",screensaver=name,options="None"
received reply  R9|0|SmartSDR-MB=1.4.11.60#PSoC-MBTRX=1.3.1.0#PSoC-MBPA100=1.1.2.2#FPGA-MB=0.0.23.167

received reply  R10|0|ANT1,ANT2,RX_A,XVTR
received reply  R11|0|MIC,BAL,LINE,ACC,PC
received reply  R12|0|
received status S8B8F1BBA|profile global list=Amp-oper^Amp-sdby^
received status S8B8F1BBA|profile global current=
received reply  R13|0|
received status S8B8F1BBA|profile tx list=*Amp-oper^*KZ1F-default^Amp-oper^Amp-sdby^Default^Default FHM-1^Default FHM-1 DX^Default HM-Pro^Default PR781^Default PR781 ESSB 3_2k^Default ProSet HC6^KZ1F-default^RadioSport DX M350-ADJ^RadioSport DX M360/EM56^RadioSport WIDE M350-ADJ^RadioSport WIDE M360/EM56^

received status S8B8F1BBA|profile mic list=*Amp-oper^*KZ1F-default^Amp-oper^Amp-sdby^Default^Default FHM-1^Default FHM-1 DX^Default HM-Pro^Default PR781^Default PR781 ESSB 3_2k^Default ProSet HC6^KZ1F-default^RadioSport DX M350-ADJ^RadioSport DX M360/EM56^RadioSport WIDE M350-ADJ^RadioSport WIDE M360/EM56^
received status S8B8F1BBA|profile tx current=
Profile List Problem!
received status S8B8F1BBA|profile mic current=
received reply  R14|0|
received status S8B8F1BBA|profile tx list=*Amp-oper^*KZ1F-default^Amp-oper^Amp-sdby^Default^Default FHM-1^Default FHM-1 DX^Default HM-Pro^Default PR781^Default PR781 ESSB 3_2k^Default ProSet HC6^KZ1F-default^RadioSport DX M350-ADJ^RadioSport DX M360/EM56^RadioSport WIDE M350-ADJ^RadioSport WIDE M360/EM56^
received status S8B8F1BBA|profile mic list=*Amp-oper^*KZ1F-default^Amp-oper^Amp-sdby^Default^Default FHM-1^Default FHM-1 DX^Default HM-Pro^Default PR781^Default PR781 ESSB 3_2k^Default ProSet HC6^KZ1F-default^RadioSport DX M350-ADJ^RadioSport DX M360/EM56^RadioSport WIDE M350-ADJ^RadioSport WIDE M360/EM56^
received status S8B8F1BBA|profile tx current=
Profile List Problem!
received status S8B8F1BBA|profile mic current=
received reply  R15|0|
received reply  R16|0|
received status S0|gps lat=N 41 49.795#lon=W 071 53.882#grid=FN41bt#altitude=117 m#tracked=9#visible=0#speed=1 kts#freq_error=0.000000e+00#status=Not Present#time=15:26:44Z


The rest are essentially gps status messages

Eric-KE5DTO

Walt,

Today there is no connection between what is submitted on your profile and the ProgramName the radio will accept.  Note that even though the reply is "unknown client program", this is not a fatal error.  This just means it is not a program that the radio recognizes.

Eric-KE5DTO

Two things come to mind:

1. Persistence may actually be restoring Panadapter and Slices that were present the last time a GUI client was connected to the radio.  These could result in less resources being available (though you should see these being added via status messages).

2. If you are adding a Slice without referencing a Panadapter, the radio may assign the Slice it's very own resource completely separate from the Panadapter (rather than sharing).  This will result in only 2 Slice and 2 Panadapters being available as the resource is drained by each of these unless they share.

Steve-N5AC

We have an ability to capture debug information when we run SmartSDR and the radio onsite at FlexRadio.  This program name would show up in the debug output to help us understand who is doing what with the radio since any number of clients might be connected to the radio.  We do not collect this information from customer radios, but we have discussed a way for customers with issues to request help and then set a flag that would allow us to gather the information (privacy consideration).  In the event that we wrote code to do this in the future, we would like to have you making this call so that we can help customers find any issues they have.  Does this make sense?

Eric-KE5DTO

To clarify context for future readers, this is in reference to the "client program <name>" command or API.ProgramName in FlexLib.

Walt - KZ1F

Yep, perfect sense, thank you Steve!

Tim - W4TME

Walt - the screen shot above is for the GetSatisfaction API; this has nothing to do with FlexRadio Systems' products.

https://education.getsatisfaction.com/reference-guide/api/get-satisfaction-api-getting-started/

Walt - KZ1F

I left out a boatload of propertyChanged notifications to keep things as short as possible.

I think the first question is, should I be expecting an OnPanadapterAdded  after the connect() or should I issue
 
            activePan = activeRadio.CreatePanadapter(new Size(1500,800));
            PanDataReadyEventHandler tempVar1 = (Panadapter panx, short[] data) -> processPanData(panx, data);
            activePan.addDataReadyEventListeners(tempVar1);
            boolean panResult = activePan.RequestPanadapterFromRadio();

It was my understanding from the aforementioned First Steps, that up to the radio.Connect() is all that was required.  I'll stop here for a second, in previous invocations I have gotten a full screen panadapter being very active watching the area in and around 14.1 or,sometimes, 14.086 or so, close to .1 but not quite. In this scenario I get the pandisplay very nicely but the slice, and what I hear is at 10.0 which is where I wanted to set things to. My assumption was I really don't want to be sending messages to the panadapter if it isn't fully up yet, the reply message hasn't been received and acted on. Where the callback is never received, there is little choice.


Too your second point Eric, in SDRCat there was a notation about on the createSlice, if you don't specify one (null) then it will get created.

Thanks,

Walt

Eric-KE5DTO

Walt,

You should probably subscribe to the PanadapterAdded event in the Radio class so you will know when a new Panadapter has been added (especially to catch ones that show up via persistence restore on startup).  In this scenario, you should be able to touch the Panadapter properties as soon as you know about the object as RadioAck should already be true (we don't fire the PanadapterAdded event until this happens).

You can then add your own Panadpaters using code similar to what you have described.  In this scenario, you don't want to go set a bunch properties until you get the RadioAck = true property change indicating that the radio knows about the object and you have current data pushed from the radio about the object.

I think RadioAck = true is the key to your question here if I am following you correctly.

Walt - KZ1F

AH, I did not realize that Tim, FRS does/did have an app registration. I remember it on the NDA form. But good to know...thanks TIm.

Walt - KZ1F

Thank you Eric.

Essentially the very first thing I do is add the event listeners for pan added and removed and slice added and removed. And this occurs long before the activeRadio.Connect().

If I understand what you are saying correctly, my question previous about my adding
 pan = radio.createPanadapter(new Size(1500, 800));
 pan.requestPanadapterFromRadio(...);

should be unnecessary as they should be created by virtue of the connect()?

Eric-KE5DTO

This depends on whether you are depending on previously created Panadapters to show up via persistence or whether you are creating new Panadapters.  The latter definitely requires code like you describe.  You may want to use the Radio.RequestPanafall() function as a simpler way to create a Panadapter/Waterfall combination.

Walt - KZ1F

Thank Eric, I am glad you mentioned that as I was going to open another question. Some weeks back I had opened on, maybe you guys were in Dayton, concerning Panadapter::UpdateStream (https://community.flexradio.com/flexradio/topics/api-requestpanadapterfromradio).

I was a bit perplexed that, I gather, the int.TryParse(.....) functions differently than the Integer.parseInt(string, radix).  What I did was change my code to **** off the pan streamid from the waterfall stream id). I gather UpdateStream really is a misnomer as it doesn't modify the object at this point.

For both the pan and the waterfall the stream ids are persisted from the status messages, correct?

There was another question I had, and I've forgotten who it was that answered the question (Obed?) but the subject of it was the logic that sets the radio status to 'Update' vs "Available". This had to do with the shipped FirmwareRequiredVersion.cs. In discovering the radio if there is a discrepency between the current and expected version the radio is marked Update which means "client start_persistence off" is sent. Bear with me a second longer.

The fact that statement was executed at all, does the radio 'remember' the persistence had been turned off? Is this related to the issue I reported perhaps a couple of months ago where the Panadapter was never displayed on a clean startup with SSDR)? It wasn't just an issue I saw, there were others. It just seems like the persistence of the radio is at work here with what I am seeing.

Is that a fair assumption? Should I send the radio a "client start_persistence on"?

Thanks Eric, I appreciate your time on this.

Walt

Eric-KE5DTO

Walt,

If the Radio UpdateStatus shows "Update", persistence will not fire.  This is taken care of in Radio.cs:

// turn off persistence if about to do an update               
if (ConnectedState == "Update")
    SendCommand("client start_persistence off");

As Abed mentioned, we do indeed need to sync the FirmwareRequiredVersion when we do a public release.  This variable is taken care of automatically for us by our build server, but it needs to be set correctly for those that are using the API as well.  We have added this to our release procedure for the next round.  Thanks for the heads up on that.

Walt - KZ1F

My question on that was, is the fact persistence was turned off, does that state itself, persist and do I need to turn it back on? Or, does the radio start assuming persistence is on?

Eric-KE5DTO

Persistence is default on unless you turn it off.