Panadapter API requests

  • 6
  • Idea
  • Updated 4 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

  • 1356 Posts
  • 503 Reply Likes

Posted 4 years ago

  • 6
Photo of Danny K5CG

Danny K5CG

  • 387 Posts
  • 61 Reply Likes
And you could put up other HRI agent operators on the panadapter. :)
Photo of Peter K1PGV

Peter K1PGV, Elmer

  • 553 Posts
  • 323 Reply Likes
These ideas would certainly be "nice to have"...

Aren't the Pan and the Fall both windows?  If they are, can you not get the properties of the window(s) already, using Win32?  Can't say I've tried.

In any case, the top, left, height, and width properties should be a no-brainer to add.  No risk, simple.

There could easily be significant complications to providing text for SSDR to paint into the display (once you open the door, people will be whining about font, weight, color, right to left, left to right, top to bottom... it could become endless).

OTOH, if Flex were to provide ONE method (paint the data in the font/weight/color, orientation Flex chooses for SSDR) and be done with it, this would still be a tremendous value-add.  And by choosing the font/weight/color Flex could very easily ensure that "added text" is easily differentiated from "actual SSDR generated text" and thereby avoid any potential support issues.

These are both very good ideas...

Peter
K1PGV
Photo of Mark - WS7M

Mark - WS7M

  • 1350 Posts
  • 503 Reply Likes
I do see your point about don't shoot the messenger meaning that the radio itself does not know where the client has placed things. Makes sense.

So we have the fact that SmartSDR sits at some point on the screen and it has a pan at x,y,w,h. The API calls go to the radio who can tell things like the bandwidth but not where the pan it is sending data to exists.

Got it. I think I was on drugs but still maybe my request is valid in that the API doesn't go to the radio but rather to SmartSDR. May it could work like this:

Radio - API - returns info about the pan including pan ID.
SmartSDR - API - returns info about where things are located.

This kind of means two connections but it could work.

Alternatively if Flex were to allow SmartSDR to pipe back to the pan object in the radio the x,y,w,h then that would work too.

This all comes down to the fact that ti would be a ton easier if the API simply was provided by Flex to draw stuff. Maybe that API to draw stuff actually belongs in SmartSDR.

I would like to make my own client but man doing what Flex has done with SmartSDR would take some time.
Photo of Mark - WS7M

Mark - WS7M

  • 1350 Posts
  • 503 Reply Likes
@James, yes you are probably right. I think thought it would really be a big selling point for Flex to have DX spots built in. I mean is there any other radio that without an add on does this?

I know some radios have add ons or software that did it but imagine just being able to turn that on in SmartSDR or perhaps feed it with output from some spot network.

Anyway, I think what I'm trying to do is to find away to "get by" without having to try and rebuild SmartSDR which actually is very nice.

For me personally I will "fudge" it by doing what I'm doing now, taking measurements of SmartSDR and posting a small window "near" the pan that shows my spots. This way I'm not drawing anything on the pan, no API needed other than what is already there.

It will get me by. I just hope to see Flex take off on a way to integrate this right into SmartSDR.

From what I said above my request for an API might actually be a connection to SmartSDR. If I could connect to it, request info about pans and it could return x,y,w,y and bandwidth/frequency then I can do everything I need.
Photo of Danny K5CG

Danny K5CG

  • 385 Posts
  • 61 Reply Likes
OK, A shot in the dark here Mark. Maybe there is a hybrid solution of SmartSDR AND your own client, but only for the purpose of displaying waypoints. If you can get the upper and lower edges of a SmartSDR panadapters and slice info, display a ribbon/ruler in your own windows object the user can re-size independently of SmartSDR that shows vertical lines/flags where the slices are and other objects you want to add which are present in the viewable spectrum.
(Edited)
Photo of James Whiteway

James Whiteway

  • 1059 Posts
  • 302 Reply Likes
Wouldn't that require the user to resize the ruler each time they added or deleted a panadapter?
I think someone using an app like Mark's idea, would get frustrated having to resize and adjust to fit each time a panadapter was added or deleted.
Plus, it would make it hard for an external app to align the spots to the correct freq. And then you have screen resolution to deal with as well.
WPF is "supposed" to make concerns about screen resolution a thing of the past. But, I have read where that is not all ways the case.
James
WD5GWY
(Edited)
Photo of Danny K5CG

Danny K5CG

  • 385 Posts
  • 61 Reply Likes
No, the ruler can remain at whatever size the user sets. As the pan changes scope (zoom, width or upper/lower edges), the data inside the ruler changes with it but the ruler size/shape doesn't. Now, how to handle multiple pans... Add another ribbon inside the ruler box in a stacked fashion? If you had a 6700 you could have 8 horizontal ribbons, you'd need another monitor for all of it. But for a 6300 with only 2 ribbons it wouldn't be hard to accommodate on the screen with SmartSDR.

The ruler IS the external app so you can place whatever, wherever you want on it as long as you know the frequencies at the edges and anywhere in between in each ribbon. It would all shift as you change the view of the pan and the objects would shift with it.

Obviously having this built into SmarSDR is the penultimate solution.

I'm not a programmer so I have no idea what is not possible. :)
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 645 Reply Likes
No Mark, don't shoot the messenger meant me. I doubt Flex can do what you want nor do I think they should (or will) try. What I was trying to do was stepwise walk you through why. XPSSDR uses XPSLib at 1.4.16. It works just fine with the radio at 1.6.17. The new t full release may break it due to a different discovery method. They likely will deprecate the current method for a full release before removing it. So the 1/4 version of XPSSDR will likely work for some time.
So you know the x,y of what, top left of the client GUI? I was referring to the origin of a region layers into that window. There is an outstandingly good reason why the initial size is 0.

The reason I said write your own is because it's infinitely easier.
Photo of Mark - WS7M

Mark - WS7M

  • 1356 Posts
  • 503 Reply Likes
something weird this way cometh...
(Edited)
Photo of Mark - WS7M

Mark - WS7M

  • 1356 Posts
  • 503 Reply Likes
I was having all kinds of trouble posting the reply below
Photo of Danny K5CG

Danny K5CG

  • 387 Posts
  • 61 Reply Likes
Yes, I think we got 3 or 4 7 or 8 of them in email. No worries.
(Edited)
Photo of Mark - WS7M

Mark - WS7M

  • 1356 Posts
  • 503 Reply Likes
Well posting these ideas here has cleared up at least one thing for me.

I think the #2 API at the top, to have methods to post data items really is not a FlexLib radio API but rather a SmartSDR API.

In fact thanks to Walt I think this makes more sense. My request to have a AddOrUpdateDataItem() and RemoveDataItem() really need to be a TCP/IP port that SmartSDR opens and accepts connections on.

The reason I say this is that it is on SmartSDR that I want to paint the spots and perhaps other data and frankly this data doesn't involve the radio at all, only the display of the radio data which is a big part of SmartSDR's job.

So if SmartSDR opened a TCP/IP port for connections and accepted commands like:

addDataItem freq=7.038.1 tag="ws7m" ttl=300000 detail="WS7M" mode:CW clicktotune:true"
return:
dateItemAdded id=0x108

updateDataItem id=0x108 freq=7.250 ttl=100000 detail="WS7M" mode:LSB clicktotune:true"
return:
dataItemUpdated id=0x108

removeDataItem id=0x108
return
dataItemRemoved id=0x108

And SmartSDR would paint these data items on all pan adapters that covered the target frequency then frankly we have everything, or perhaps I have everything I need.

Walt brought it to light that really this isn't a radio or radio related data at all. This is just display data related to a frequency.

The above would do everything I want. Of course there is more detail needed like what can be in the detail strings, now to enable click to tune, mode change. Style support, etc.

I do think if SmartSDR provided this there should be a new button, perhaps down next to FDX that enables external data. Perhaps it is even called EXD. Clicking that enables the display of all data items, clicking it off turns them off.

That would for my purposes be perfect and would not involve the radio or even FlexLib API at all.

On the subject of rolling your own client:

I've been programming a very long time. I'm sure many of you here have as well. I am going to standby and maintain my stance that to re-create roughly what SmartSDR is takes a lot of work.

First there is a need to for flawless interaction with the radio. The API is great but there are nuances that I think you can only discover after hours of hard work. Flex has already done this with SmartSDR

Next I like SmartSDR. I like the look, the feel, and it seems to really work. I've left SmartSDR running for a solid week and unless Windows craps out somewhere it just cranks on.

Yes I could throw together a client but getting it to do all SmartSDR does I think is a big job.

So in summary:

I hereby modify my API request #2 at the top of this thread to target SmartSDR and providing a TCP/IP port and commands to have SmartSDR paint things.

In the meantime I have a workaround. It is not pretty, it requires the user to keep to two pan adapters so you guys with 8 gazillion pans and slices (6700 owners) might feel a little limited but it is due to the inability to know where things are in SmartSDR. My workaround puts a small window at the top and bottom of SmartSDR. This means you cannot have it in full screen mode.
In these little windows aligned by frequency are the spots and click to tune works on these.

This workaround is a little clunky since the data is outside of SmartSDR but the alignment works and the other bad things boil down to the limitation of two pans and needing space for these small windows above and below SmartSDR.

For me this works, gets me going. In the end I think it is clunky and Flex would do themselves a huge marking favor to provide the API I seek into SmartSDR.

Lastly, if we can ever have multiple GUI clients then this problem might be solvable in another way. Currently if I in my program attempt to request the first pan adapter while SmartSDR is running it gives me the pan. But it disappears from SmartSDR. So you have SmartSDR with a Slice running back and forth over no pan.

If multiple GUIs were enabled then I could request the pan while SmartSDR keeps it and in my copy in my own window that could be positioned anywhere I can plot the pan data and my spot data.
Photo of Barry N1EU

Barry N1EU

  • 495 Posts
  • 124 Reply Likes
I hope Flex understands what a game changer this potentially represents.  If users can get spots overlaid on a panadapter, Flex WILL sell a boat load more SDRs to contesters/dx'ers

73, Barry N1EU
Photo of Mark - WS7M

Mark - WS7M

  • 1356 Posts
  • 503 Reply Likes
Strange, I got a comment from Walt in email from this post but now I don't see it here.

Anyway, @Walt I don't take any of this as arguing. It is a sounding board, a way to exchange ideas and fine tune them and I definitely did come to realization about who owns what.

Yes if SmartSDR were to expose an API there is the risk of de-stabilization. But I think that can be mitigated by carefully checking what is accepted by the API.

Anyway I could roll my own. I am hopeful I do not have to since SmartSDR is pretty cool. For now I have a work around.

As far as SmartSDR cross platform, I am totally with you. I wish it worked across the board: PC, Mac, Linux etc. But it has been so good that frankly I'm using Windows more than my Mac these days.
Photo of Peter K1PGV

Peter K1PGV, Elmer

  • 553 Posts
  • 323 Reply Likes
I think the #2 API at the top, to have methods to post data items really is not a FlexLib radio API but rather a SmartSDR API.
Good observation on both Walt's and Mark's part.  Hmmmm....

This, of course, makes the request infinitely more difficult.  Because now you have to provide an entirely different "thing"... an API for SSDR.  Better, I think, to go back to asking for some sort of plug-in that allows you to "skin" SSDR and/or provide data to paint on the pan or fall. 

That's a lot of work and plenty of risk for Flex.  It'd be coo, but I wouldn't hold my breath on that one, personally.


Peter
K1PGV
Photo of James Whiteway

James Whiteway

  • 1060 Posts
  • 303 Reply Likes
I think Flex said some time back that a plug-in system will never happen. Which makes sense as their Tech Support guys would go crazy trying to determine if an issue is their's or some 3rd party developers plug-in. Just look at some of the issues raised here concerning 3rd party apps like loggers etc. Better to keep things as they are for them, money wise.
Building a stand alone GUI app using Flexlib isn't that horrible a learning experience. And when they allow multi-GUI clients with SSDR, then interesting 3rd party apps like a Spot program can be built and ran on a second screen (or the main monitor if it's big enough) along with SSDR or Maestro running at the same time!
James
WD5GWY
Photo of IW7DMH, Enzo

IW7DMH, Enzo

  • 356 Posts
  • 87 Reply Likes
If we could drop our dlls in the SMARTSDR execution enviroment, and have our plugins running next Flex GUI components, will be amazing. Even if not in multiplatform enviroment.
I hope in a big surprise with the 2.x

Enzo
iw7dmh
Photo of Eric - KE5DTO

Eric - KE5DTO, Official Rep

  • 916 Posts
  • 344 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).