API session question

  • 2
  • Question
  • Updated 4 years ago
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
Photo of philip.theis

philip.theis, Elmer

  • 123 Posts
  • 20 Reply Likes

Posted 4 years ago

  • 2
Photo of Stu Phillips - K6TU

Stu Phillips - K6TU, Elmer

  • 642 Posts
  • 256 Reply Likes
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
Photo of philip.theis

philip.theis, Elmer

  • 123 Posts
  • 20 Reply Likes
What's happening is I am subscribing with a 1 as in: tel.send("c1|sub slice all\n");
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
Photo of Stu Phillips - K6TU

Stu Phillips - K6TU, Elmer

  • 642 Posts
  • 256 Reply Likes
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

Photo of philip.theis

philip.theis, Elmer

  • 123 Posts
  • 20 Reply Likes
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
Photo of Stu Phillips - K6TU

Stu Phillips - K6TU, Elmer

  • 642 Posts
  • 256 Reply Likes
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
Photo of philip.theis

philip.theis, Elmer

  • 123 Posts
  • 20 Reply Likes
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
Photo of philip.theis

philip.theis, Elmer

  • 123 Posts
  • 20 Reply Likes
My use of the word "active" relates to the yellow center line.  On your app it's the highlighted slice on the left panel
Photo of Stu Phillips - K6TU

Stu Phillips - K6TU, Elmer

  • 642 Posts
  • 256 Reply Likes
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
Photo of philip.theis

philip.theis, Elmer

  • 123 Posts
  • 20 Reply Likes
Thank you