API session question

philip.theis

Have a few questions about the reply numbering system.  
Does it ever get reset?   
What if there are multiple conversations on the same port (4992)
Do these help distinguish sessions?
Is this covered anywhere?
thanks 
Phil K3TUF

Stu Phillips - K6TU

Phil,

The sequence number on the command (like C1|slice c freq=....) is supplied by the client and is echoed back by the radio in the R response.  The sequence number is solely for the benefit of the client to be able to match commands and responses...  critical in a multi-threaded client.

Most clients increment the sequence number monotonically but the radio doesn't check.  For example, if you are manually sending api commands via telent, there is nothing to stop you using the same serial number for every command - like 1!

Each connection to the radio on port 4992 is identified by TCP using TWO port numbers - 4992 which is the port on the radio and some system supplied port number on the client.  The same client can open multiple connections to the radio and each one is unique - its the combination of the port number PAIR that identifies the conversatio - aka a TCP stream.

Serial numbers for commands are only relevant with a single stream - you could have two commands issued with the same serial number on different streams and the radio will have no problems.

Hope this helps.
Stu K6TU

philip.theis

What's happening is I am subscribing with a 1 as in: tel.send("c1|sub slice all
");
and I get the proper reply: Received *** R1|0|
But status after comes with an S2
It works, just confused with the numbering.   This is in the same program session.
BTW, what is a type M response?  as in: Received *** M10000001|Client connected from IP 192.168.x.x
Thanks,
Phil

Stu Phillips - K6TU

Phil,

Status messages have the form S<handle>| where the <handle> identifies which client initiated the command that caused the status update.  When you connect to the radio you always get the following sequence back...

V1.1.0.0

H3B29E519

The first is the version of the API supported by the radio to which you are connected.  The second is the <handle> the radio has assigned to this client connection.  Each connection will have a unique handle.  This way you can distinguish between general radio status updates (sent with handle 0) and the specific handle.  Sometimes you will get a status message resulting from a change you made - then the handle will the one assigned above - this way you can choose what to do with status messages resulting from changes you made (I generally ignore them as I already know the answer!).

The M response is just a message.  As a client you can choose what to do with them - SmartSDR displays a little pop up window in the lower right of the screen.  I don't know the significance of the number associated with the M - I suspect its bit fields relating to radio subsystem but this is a semi-educated wild assed guess on my part.

Stu K6TU

philip.theis

Ok, now we're getting somewhere.  So the direct response matches the request, but the changes caused by SmartSDR (which is what I am doing; tuning the radio) likely come back with the next  higher number from when I requested status.   That makes sense.
Thanks,
Phil K3TUF

Stu Phillips - K6TU

Nope; the number in the Status command is totally unrelated to the sequence numbers you use on the commands.

The number in the status command is a handle... 

Stu K6TU

philip.theis

ok then, unrelated.  Thanks

philip.theis

Stu,
I believe from your above description that that handle that is assigned will be used in the status replies I get when I subscribe.  Here is a dialog I am getting, notice that the status handle does not match the one assigned at the beginning of the session:

V1.1.0.0H81BE5AF3

R5|0|
M10000001|Client connected from IP 192.168.254.32
S81BE5AF3|radio slices=7 panadapters=7 lineout_gain=46 lineout_mute=1 headphone_gain=51 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=144-6700 callsign=K3TUF-1
S81BE5AF3|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

S81BE5AF3|slice 0 in_use=1 RF_frequency=10368.185700 rit_on=0 rit_freq=0 xit_on=0 xit_freq=0 rxant=XVTR mode=USB wide=0 filter_lo=100 filter_hi=2800 step=100 step_list=1,10,50,100,500,1000,2000,3000 agc_mode=med agc_threshold=70 agc_off_level=10 pan=0x40000000 txant=XVTR loopa=0 loopb=0 qsk=0 dax=1 dax_clients=1 lock=0 tx=0 dax_tx=0 active=1 audio_gain=50 audio_pan=50 audio_mute=0 record=0 play=disabled record_time=0.0 anf=0 anf_level=50 nr=0 nr_level=50 nb=0 nb_level=50 apf=0 apf_level=0 squelch=0 squelch_level=0 diversity=0 diversity_parent=0 diversity_child=0 diversity_index=1342177293 ant_list=ANT1,ANT2,RX_A,RX_B,XVTR mode_list=LSB,USB,AM,CW,DIGL,DIGU,SAM,FM,NFM,DFM fm_tone_mode=OFF fm_tone_value=67.0 fm_repeater_offset_freq=0.000000 tx_offset_freq=0.000000 repeater_offset_dir=SIMPLEX
S81BE5AF3|waveform installed_list=

thoughts?
Phil

Stu Phillips - K6TU

Phil,

Not sure I quite understand...

The radio assigned handle is 81BE5AF3 and this appears to be the same handle in each of the status messages...

R5|0|

M10000001|Client connected from IP 192.168.254.32
S81BE5AF3|radio slices=7 panadapters=7 lineout_gain=46 lineout_mute=1 headphone_gain=51 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=144-6700 callsign=K3TUF-1
S81BE5AF3|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

S81BE5AF3|slice 0 in_use=1 RF_frequency=10368.185700 rit_on=0 rit_freq=0 xit_on=0 xit_freq=0 rxant=XVTR mode=USB wide=0 filter_lo=100 filter_hi=2800 step=100 step_list=1,10,50,100,500,1000,2000,3000 agc_mode=med agc_threshold=70 agc_off_level=10 pan=0x40000000 txant=XVTR loopa=0 loopb=0 qsk=0 dax=1 dax_clients=1 lock=0 tx=0 dax_tx=0 active=1 audio_gain=50 audio_pan=50 audio_mute=0 record=0 play=disabled record_time=0.0 anf=0 anf_level=50 nr=0 nr_level=50 nb=0 nb_level=50 apf=0 apf_level=0 squelch=0 squelch_level=0 diversity=0 diversity_parent=0 diversity_child=0 diversity_index=1342177293 ant_list=ANT1,ANT2,RX_A,RX_B,XVTR mode_list=LSB,USB,AM,CW,DIGL,DIGU,SAM,FM,NFM,DFM fm_tone_mode=OFF fm_tone_value=67.0 fm_repeater_offset_freq=0.000000 tx_offset_freq=0.000000 repeater_offset_dir=SIMPLEX
S81BE5AF3|waveform installed_list=

Can you expand?
Stu K6TU

philip.theis

In my case the handle of the status is not the handle that I received when I started the session.  But I now believe that the handle on the status is the handle of the client that initiated the change in status.  Which makes sense.  I am just a BeagleBone and the changes are being made by SmartSDR and I am monitoring the changes with the BBB

philip.theis

Looking back at my initial post, you are right.  I didn't continue with the rest of the status entries, which were made by SmartSDR and would have a different handle.  
This thread is done,  I get it now. :-)

Stu Phillips - K6TU

RR!
Stu K6TU

philip.theis

When would a slice be not in use?   or in_use=0 ?

Stu Phillips - K6TU

When is a slice not a slice? - After its been eaten!

The radio sends all connected clients show have sub'd to slices a status message with in_use=0 when a slice is removed/deleted.

This allows clients to trace which slices exist within the radio.

Next you are going to ask... what does active= mean....

;-)
Stu K6TU

philip.theis

What is an interlock?

SBD43A421|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

philip.theis

My use of the word "active" relates to the yellow center line.  On your app it's the highlighted slice on the left panel

Stu Phillips - K6TU

The interlock command/status shows you the configuration of the different enables/ptt lines etc.  

There is also a interlock status that shows additional useful information like this...

interlock state=NOT_READY reason=CLIENT_TX_INHIBIT source=  

This for example shows that DDUtil has disabled transmit while moving my SteppIR to a new tune position...

Yes - active shows the concept of an "active" slice.  This is simply a notification to clients and then can do with it what they will... except that there can only be one Active slice regardless of how many connected clients there are...  The radio will send slice status update to connected clients when the active state is changed...

Stu K6TU

philip.theis

Thank you