API command responses

John G3WGV

Here's another one for you Eric:

When my (non GUI) controller sends a command to the API I expect and always receive the response message, e.g.

15:06:30.837 | [API>] C26|slice tune 0 18.070275
15:06:30.846 | [<API] R26|0|

15:26:03.903 | [API>] C35|filt 0 -330 330
15:26:03.940 | [<API] R35|0|

For most commands, that's all I get but for the slice audio gain command I get more:

15:06:45.201 | [API>] C32|audio client 0 slice 0 gain 91
15:06:45.272 | [<API] R32|0|
15:06:45.275 | [<API] SD3D79865|slice 0 audio_gain=91 audio_pan=50 audio_mute=1

The API has effectively echoed back the setting I just gave it (and some other information for good measure).

I'm wondering why this would be? On the one hand I can see a valid argument that my app knows what setting it just asked for and it got a good response back, so it doesn't need anything else. Conversely, I can see that echoing back the change is a useful thing to do.

I tend to think that echoing back the all changes would be a good thing. It would certainly reduce the complexity of my code a bit. Is there any reason why some commands do and some do not?

TIA, John, 'WGV.

Eric-KE5DTO

In general, we try to avoid sending back a status message with the same information that a client has just handed to the radio assuming the command worked properly.  This is to minimize bandwidth and avoid latency issues when you grab a slider and move it from 0 to 100 (100 events) in <1 sec (e.g. you really don't want to see the slider move through those same 100 values as the radio processes those commands).  We will typically send a status update to all subscribed clients other than the one that sent the command.

This general idea is sometimes complicated by the fact that often your command will set A which changes B which changes C which may come back and align A.  We do what we can to recognize these kind of situations and prevent them, but this becomes increasingly difficult to catch intuitively as the software becomes more complex (more features, etc).

I've written this particular example up in issue #4254.  We'll look into it and see what we can find.

John G3WGV

Thanks Eric, this is more or less what I was expecting and I can see the logic in your approach. I'll continue to assume that I will not get an echo-back, which is what I was doing before I came across the audio_gain oddity.

If I come across any others I'll let you know. As you can see, I now have a rather handy API monitor that lets me see exactly what is going back and forth, and when. Some of the timings are interesting too...

73, John.

Eric-KE5DTO

It is worth noting that if you send a command with the correct syntax, but that wouldn't work (say audio client 0 slice 0 gain 101), then you SHOULD expect to see a status message seeing the value back to the original value.

Also, keep in mind that you need to implement status message handling in case OTHER clients make changes so that your view of the radio state is accurate.  Lots to keep up with, but it is fun to see it all work together.

John G3WGV

Good point about setting erroneous values. I shouldn't ever do that (famous last words!) because each control has config defined max/min/step values.

Yes, I'm handling status message classes that I've subscribed to from other clients. Effectively my "middleware" turns each of these messages into events that can be hooked by the app. Sometimes I get 50+ events from a single API string - like starting a new slice for example. Of course the app doesn't have to hook any events that it's not interested in. So my logging program, for example, only hooks events like frequency, mode etc.

It was quite a bit of work getting all that middleware working but it's pretty well there now and it makes writing apps that use the API very straightforward. As you say, very satisfying to see it all working together. Typically I am simultaneously running WinSSDR, my Mk I controller, my logging program and my development Mk II controller all as separate clients to my 6500.

I get the impression that not many people are doing this sort of thing. I suppose it is a bit esoteric.

Kevin

John... I think what you are doing is pretty darn cool and hope I can figure it all out someday. I've installed Visual Studio and C# and have been going through a book (C# 6 Programming with Visual Studio 2015) but still at the "how do you write a function" level. Real basic stuff. How to talk to a radio or anything external is way down the road for me.

Hoping your conversations in the community continue as I'm learning a lot from them. Maybe when you have it all figured out you could write the Programmer's Guide to Flexlib.

I keep feeling there's a ton of untapped energy out there that can benefit Flex users. I also believe the radio homebrewer of yesteryear is the programmer/hacker of today.

Thanks,
Kev K4VD

John G3WGV

Hi Kev,

Thank you so much for your kind words. I can only encourage you to persevere with your programming endeavours. I am certainly no expert, having only programmed professionally for a few short years in the early 1970s. Everything I've done since has been at an amateur level, learning by experimentation, trial and error.

I completely agree with your suggestion that programming is a modern day construction project for radio amateurs. As so much more is done in software, so programming skills are becoming the modern equivalent of the metal bashing and soldering we did in our youth. And the Flex platform provides a wonderful vehicle for DIY experimentation through the API.

It's interesting that you mention a programmer's guide to the API. I did in fact make a start on exactly that a couple of months back but it got put to one side as  programming effort on my API middleware project and Mk II controller intensified. I should perhaps get back to it while all this stuff is fresh in my mind!

Thanks again

73, John, G3WGV

John G3WGV

Hi Eric,

Here's another command that gets echoed back to the originating client. This one is unlocking/locking the slice:

[TCP>] C269|slice unlock 0
[<TCP] R269|0|
[<TCP] S4AEFC428|slice 0 RF_frequency=10.117850 wide=0 lock=0
[TCP>] C270|slice lock 0
[<TCP] R270|0|
[<TCP] S4AEFC428|slice 0 RF_frequency=10.117850 wide=0 lock=1

More if/when I find 'em

Eric-KE5DTO

Thanks.  Keep them coming.  I'll add these to #4254.