Panadapter API requests

  • 6
  • Idea
  • Updated 3 years ago
  • Under Consideration
I have a couple of API requests that I'd like Flex to put on the list.  I think posting them here is a good way to get additional feedback from developers that might also be interested in these.

The primary goal of these API requests is leading to something Howard has asked for, for some time.  A way to post DX spots on the panadapter.   In my case I'm also considering posting other information as well and not making this feature limited to DX spots.

My first request is what I would consider minor updates/fixes to SmartSDR and the API which would go a long way in allowing an external client to know a little more about the state of things when SmartSDR is running.

The small and relatively simple update:
 
When SmartSDR is running as the GUI app, it of course gets panadapters and waterfalls.  From the API a client can connect and get a list of those pans and falls can be accessed.   It would help a lot if the pan and fall objects were modified to have Top, Left, Height, Width values relative to the 0,0 origin of SmartSDR.   I see that pan has a height and width property but they always seem to be zero.

The reason for having top,left,height,width would be to allow an external client to know where on screen the pan was.  Specifically I want to use this to place a transparent window over the pan with DX spot information.  If the API provided the location I could maneuver my window to align with the pan.  The pan already gives data on center frequency and bandwidth so if an external app could also figure out where the pan was in screen coordinates we could paint in a window over the top or even take screen shots from that rectangle.

The more complex update:
 
I would like to see an API added that would allow the addition of "data items" to pans/falls.

I think two methods would suffice:
 
int AddOrUpdateDataItem( int itemID, int timeToLive, double freqLoc, string itemTag, string itemData );

bool RemoveDataItems( int itemID ); 

AddOrUpdateDataItem takes in an itemID.  If non-zero then we are updating a data item with replacement data.  TimeToLive is time in milliseconds perhaps for this item to exist before the pan deletes it automatically.  This would allow an external client to post an item and let it say on screen for like 3 minutes before SmartSDR/API just kill it.

double freqLoc is the alignment for the data item.  IE it would paint it over this frequency on the pan.

string itemTag is small, simple text to plot.  For DX spots this would be a call sign.  Perhaps HTML is allowed to paint the text in a color.  But this has to be small.    I am thinking that a line similar to the slice line but perhaps much lighter and at the top the itemTag is written vertically like:

 
  W

  S

  7

  M

   |

   |

   |

   |

 
The box surrounding the item tag would support mouse hover like for many parts of SmartSDR.  When hovered over the text from itemData would come up in the popup help box.  This would allow more details behind the spot.

Basically, an external client would make AddOrUpdateDataItem calls to post spots.  For new data the itemID is zero.  To update a data item the external client must pass in the ItemID they got earlier when it was added along with new data.

I think that the most recent data items are painted on top of the older ones.  So in effect if you kept a list of the data items to paint on the display, you'd paint old to new that way the newer ones could potentially draw over the older ones.

I think the data passed in needs some basic ability to color the small text as well as the more specific text.  HTML might be appropriate but other mark ups might work.

I think these data items need to have the ability to enable click to tune where if you click on it, you tune to that spot and change modes to match.

I would prefer to see Flex implement this in such a way that the data to be plotted or posted is independent meaning it can come from a client that supplies spots, or perhaps another client posting net frequencies etc.  I think it would be a mistake if Flex built DX spotting directly into SmartSDR. 

I think providing an API such as this opens the door for DX spots as well as many other uses of painting data on the pans.
 
As far as styles, colors etc we can go one of two ways.  Either SmartSDR defines how these data items look and somewhere there is a place to set line colors, text types, sizes, etc or even disable them all together.  This might be best so that picky users don't have to try and figure out where in client XXX they change the look/feel of data posted.  Also they can quickly turn it off.  So perhaps there is a button that just hides all data items to clean up the display.
 
The alternative is to let the clients handle all of that meaning that the call to add or update would need style data including colors provided.  It makes the API harder to use but moves the responsibility to the client.

So the basic features I would see this data item needing are:

a) Ability to add new data
b) Ability to update existing data
c) Ability to remove data
d) Ability to format both the displayed and hover over data
e) Some keys perhaps in the data that turn on/off click to tune
f) Keys in the day perhaps to make an external call to control something like a rotor.

Rationale:
 
My rationale is this:  One of the reasons I purchased a Flex Radio over something like a Kenwood TS-2000 was the data visualization.  I am still mesmerized by the pan display.  During my work day I often just have SmartSDR running and I visually watch what is going on.

So in this age of connectivity and to further enhance the visualization aspect I propose the data item API so that the display of SmartSDR can be even more informative.  I don't believe this data display is limited to spots.  I could be used to label just about anything on the pan/fall display.
 
Of course spots are one big request and since I know Flex has targeted DX and contesting with the radio and SmartSDR I personally think having the ability to integrate spot data into the display would make the combination unbeatable.
 
From a contest standpoint imagine this:
 
N1MM is updated to post item data to SmartSDR.  It can post two types to data at minimum:  Stations worked and stations not worked on other bands for example.  So imagine your pan is busy with lots of peaks but each peak has a label perhaps in green or yellow or red clearly indicating you need to get to that station and work it or perhaps you've already worked it.

It might also show multiplier stations in some color so you can easily see them.
 
Also a dx spot or contest spot program could feed in where stations are camped out.   Clicking on the spot could cause a click-tune, mode change to work that spot. This should be an option for the item data.   Some key string which says if clicked on tune to the freq and change to this mode.
 
 
 
73s - Mark WS7M
--
Photo of Mark - WS7M

Mark - WS7M

  • 1192 Posts
  • 419 Reply Likes

Posted 3 years ago

  • 6
Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 720 Posts
  • 211 Reply Likes
Official Response
Mark,

Thanks for posting the ideas.  I agree that what you're asking for is likely better suited for a SmartSDR API -- something that we don't have today.  We will take this into consideration.

As an aside, we have intentionally kept the details about the client to a minimum with regard to what you can learn from talking to the radio.  In other words, we try to keep the client to client communication and dependencies to a minimum.  This has helped us to be able to deliver Panadapter and Waterfall information to clients on multiple platforms without having to touch the Ethernet API.  Obviously this approach is diametrically opposed to the kind of thing you are trying to accomplish here (an overlay on top of a specific client implementation).