Ethernet API - Status messages - Different behaviour in 1.4.3

IW7DMH, Enzo

Hello,

after 1.4.3 upgrade, I experimented a strange behaviour in status message responses.
It seems that a client, after having sent a command, can't receive its related status response.
It happens only for some commands, not for all.
In the following picture I started two clients A and B.
Client A is only "listening" and it receives "all" status responses.
On the other side Client B is sending commands but for two of them, "slice agc_threshold" and "mixer lineout_gain" it can't get status responses. I underlined these with red lines.

When this happens my Arduino console loose synchronization with the Flex rig, so this behaviour, could be a big issue.

Could you confirm this?

Thank you very much
73' Enzo


iw7dmh

Steve-N5AC

Enzo,

In general, the philosophy is that the client that sent the message in the first place already knows the situation and doesn't need to hear it from the radio.  The key reason we did this was to avoid race conditions.  For example, if you are tuning with the mouse and sending "slice tune" commands, you might send 2-3 before you hear our first response.  If we send a status with that and it reiterates the frequency of the first tune, your client will "jump" the slice back to the first frequency.  This would result in a jittery display.  So we opt not to send most status back to the client that originated the change.  Your GUI should reflect any changes you send to the radio.  The radio will either respond with an result of 0 (success) or it will return an error AND a new status to tell you the situation in the radio since your command did not work.  Does this make sense?  There are a few exceptions to this, but it is the general rule.

So what you should do in your client is assume that anything you tell the radio to do will happen.  You can optionally wait until you get a response to show the change if you like.  Status is not guaranteed with a successful operation that you initiate.  It is guaranteed for a change made by another client.

IW7DMH, Enzo

Ok Steve,

I looked for status messages, before updating internal objects, because I was, erroneously, considering status messages were granted to all clients.
The key aspect of your explanation "Status is not guaranteed with a successful operation that you initiate.  It is guaranteed for a change made by another client" was not immediate to me reading the wiki docs (that are my starting points).
Of course my client knows the situation and considering the success result logic does make a lot of sense. I will adapt the parser to respect this logic.
But at this point I have only a doubt: does make sense sending, to an active client, both response packets and status packets? It could be time and band consuming as it systematically forces the client to update two times the same object status. (assuming one have an handler for responses and one handler for status).
That's all for the moment.
Many many thanks for your help.

73' Enzo

Steve-N5AC

But at this point I have only a doubt: does make sense sending, to an active client, both response packets and status packets?

I'm not sure I understand the question, Enzo.

IW7DMH, Enzo

Dear Steve, I am sorry for my poor English.

An active client for me is a client that send a command to the rig and wait for a response.
If I am right, it receives "always" the R response, and sometimes the S message.
So, in this scenario, the S answer is not deterministic.
If I have to implement an handler for R and another for S (as I have done) I must have two place in my code that can update the same object.
Using an high level programming language this is not a great problem, but in a micro-programmed enviroment this could be.

I don't know the reason of this choice, but I would consider the following use case:

1- the client connect the Flexrig and subscribe itself to some or every Flex objects;
2- when a client send a command it receives only the R packet (no more the S packets);
3- if an error happens it receives R and the related S packet;
4- when it needs, the client could ask for the "whole" status object.
 
I think this logic could be more convenient for both rig and clients: the rig send back less data and the client is free to ask for the status when it needs.

Best regards and Happy Easter

73' Enzo
iw7dmh  


 
 

Steve-N5AC

Dear Steve, I am sorry for my poor English.

Enzo, it beats my Italian any day (although I continue to study from time to time)  ;-)

An active client for me is a client that send a command to the rig and wait for a response. 
If I am right, it receives "always" the R response, and sometimes the S message. 
So, in this scenario, the S answer is not deterministic.
If I have to implement an handler for R and another for S (as I have done) I must have two place in my code that can update the same object. 
Using an high level programming language this is not a great problem, but in a micro-programmed enviroment this could be.

Well yes you have to parse both and you have to decide how to handle both.  But the status message is what requires all of the parsing.  The response generally won't require you to update a specific item -- it just tells you if what you tried to do was successful and, if not, why it was not successful.  We generally ignore the response in our client except in some special circumstances.  So most of the parsing occurs with the status.  As a developer the response will help you figure out what is wrong.  You can even issue commands like "CD1|slice tune 99 14.1" and it will give you more details on why the command won't work.

I don't know the reason of this choice, but I would consider the following use case:

1- the client connect the Flexrig and subscribe itself to some or every Flex objects;
2- when a client send a command it receives only the R packet (no more the S packets);
3- if an error happens it receives R and the related S packet;

This is basically what happens now.  In a few cases we send out the status when it is not needed.  I can't tell you today why this is done in every case, but we often had a good reason to do so.

4- when it needs, the client could ask for the "whole" status object.

Polling the status or asking really goes against the way we have things working.  It will cause unnecessary network traffic which would make remote operation with your client potentially more difficult.
 
I think this logic could be more convenient for both rig and clients: the rig send back less data and the client is free to ask for the status when it needs.

But if there are other clients changing things and you are not being notified, how do you know when to ask for the status of the item?  You don't so you must poll.  When you start polling, everything falls apart because you might poll once a second and then someone will ask you to poll more often and for more things and before you know it, this will work just like CAT.  CAT is a horrible design using polling as a crutch.

Best regards and Happy Easter

Happy Easter to you as well!