Panadapter API requests

Mark_WS7M

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 **** 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 **** 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
--

K5CG

And you could put up other HRI agent operators on the panadapter.

Peter K1PGV

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

Mark_WS7M

Peter I have tried.  From what I can see they are rendered through DirectX and don't appear to have any "window handles".  All I can seem to find is the SmartSDR window itself.

Walt - KZ1F

Mark, you supply the size..more specifically, the GUI client does. For instance, when you add a second pan the size of the first needs to alter. Have you gotten to writing your own GUI client yet? Even when you resize the app, that triggers constant changes to size. Wireshark TCP 4992 and you'll see the textual API. I suspect James will get around to responding to you. He was stuck on that for the longest time.

Walt - KZ1F

I can't speak for WPF but in JavaFX8 the only object that resolves to a Microsoft OS window is the Stage object. Regions or other graphical nodes are added to that stage. Do, following that model it would be hard to equate that to an hwnd.

Mark_WS7M

Walt, that is true if you are creating your own pan via the API.  What I am doing here is querying what pans SmartSDR has.  If you try this you will see that their width and height show as zero.

The reason for this is probably not clear from the document above but I came to the realization that to get where I want to go I have a couple options:

1) Use SmartSDR and augment it with tools and utilities including this spot concept.

2) Write my own replacement for SmartSDR and I can do whatever I want.

Clearly #2 solves the problem as I can do anything I'd like once I have the pan data I can draw x's and o's on it if I want.  The problem with #2 is frankly SmartSDR is really good.  I don't want to re-invent that wheel.

So I'm hoping to use SmartSDR as the core program and client programs that interact with it to post spots, show details, control amps, rotors (if I ever get a tower) etc.

My first attempt to do #1 resulted in me looking at the pans provided by the API currently in use by SmartSDR and I found the height and width were zero.

Next I used a window/control sniffer to try and see if I could figure out handles and access them.  Well it seems like the pans in SmartSDR are being rendered not as common windows controls.  WPF tends to do this.  It uses direct X and things don't show up like older WinForms app where each button, label etc had a handle you could access.

Anyway that is my logic.

Walt - KZ1F

Right, that's why I made the analogy to JavaFX8. What you said was actually incorrect. The radio returns both a pan and a slice and, as you said, size is (0,0). It is up to the GUI to tell the radio what size to make the window. If you listen to notifications from having priced the status messages you'll see the size change as a result of the'display pan create x=nnn y"nnn' command. Or, create your own listener to TCP:4992 and extract it yourself.

James Whiteway

Mark, as long as SmartSDR is running, any client app will get a zero value for the Height and Width of the Panadapter(s) when querying the API /radio, for those values. Remember, only one GUI client can "currently" display a panadapter and waterfall. Until FRS puts multi-GUI clients into the API , and allows mirroring panafalls, or allowing the radio to send one or more panafalls to other client apps, while SSDR ( or Maestro) is running, we are stuck with rolling out own version of SSDR to get what we want.
I have toyed with the idea of looking at the data packets with WireShark, while SSDR is running, to see if a packet sniffer can see the raw panadapter and waterfall data. If so, it "might" be possible to include packet sniffing code in an app and grabbing the data that way. But, that would be a real pain to do, writing FFT code etc to handle the raw data. I'm betting that some form of multi-GUI ability will show up sooner than later, once Maestro starts shipping.
Good luck!
James
WD5GWY

James Whiteway

Looks like Walt beat me to to it! :-)

Mark_WS7M

Guys I understand that all. But it is the 0.0 I'm complaining about. I realize SmartSDR owns the pans but I want to know how big they are so I can interact with them as best I can until the API (#2) I've requested becomes reality. @Walt, I think you are just missing my point. SmartSDR owns the pan. I just want to know where on screen it is. Maybe there is a reason for returning 0,0 but it doesn't make any since to me and it makes it hard for an external client to now where the pan is. I can think of a lot of reasons that knowing the X, Y, W, H of a pan in SmartSDR would be helpful. One is my desire to post on top of it, two might be another app that just wants to snap periodic pictures of the pan, etc. @James. Yes you are exactly right but again I dont' see why just because the pan is owned by SmartSDR that it should return a W and H of 0,0. Anyway it just seems to me to be minor update to SmartSDR and the API to populate the pan sizes and ideally to add X, Y. This way an non-GUI client could know where the pans are and either draw over them like I hope to OR snap pictures of them. M

Walt - KZ1F

Mark, the problem is they won't know where on the screen it is either, and if they can, not without great difficulty. Case and point the geometry inset margin and spacing problem.. If you fire off a thread to read TCP:4992, you'll at least know how large it is then do some facial recognition to find where it starts, assuming a single one, which you can't. Then, is the left border in or out, is the right border in or out? It's way easier to write a new client and add a transparent child canvas layer where you want. I was merely telling you how it gets sized and where it gets sized and the radio doesn't know where the window is or how big it is either. Don't shoot the messenger. That actually is a good counter idea, have FRS add a transparent canvas over the waterfall and/or spectrum and give you back its owning node. Then you'll have a drawing surface. But then it would need to be in every relevant event notification path. I am not sure how sound even that would be. But it would be cleaner than what you are proposing. The easiest is learn how to write WPF apps.

Walt - KZ1F

In other words you could have a node Id who's parent was destroyed or resized etc.

Mark_WS7M

Walt, I have to disagree. Let me try to explain: First one can easily find the X,Y of SmartSDR. I'm doing it now. Second what I've asked for is the X,Y RELATIVE TO SmartSDR. So if SmartSDR's window is at 1600, 250... What I want is to know that pan 1 is at 5, 8 and is 600 pixels wide. Then pan 2 is at 5, 201 and it is also 600 pixels wide. While we may be off a pixel or do or a border width I think in the big picture simply taking the X,Y of SmartSDR adding the X of pan1 and placing a transparent window at that location with that width of that pan would be accurate enough to align the spots over the frequency. I have simulated this myself. Using a ruler tool I figured up SmartSDR found the X,Y of the window from the Windows API call to so do. I then measured using the ruler tool in magnify mode until I was at the left edge of the pan. I think I got 3 pixels. I then measured how wide it was. Using the measure width and the center frequency and bandwidth reported by the API I came up with a freq/pixel factor. I then fed in my own call into my test program and said I was at 7.056 and a line appeared pretty much right over that spot on the pan. I mean it was good enough. Was it perfect? probably not but I think it was ok for the first pass. Frankly when/if Flex provides the API I want then this all goes away. Now I really do like your idea of a canvas provided by Flex. In fact that is probably #2. So #1 is my idea of simply giving back more data about where the pans are so programs like mine can try to get close in drawing over the top or perhaps taking images of the pans. #2 is your idea of a canvas provided by flex we can draw on. The problem I see with this is that to get things to align with frequencies you need to know the bandwidth of the pan versus the pixel width. Either that or Flex gives us that number as part of the canvas. I did verify and you can check this on your radio that if you have a pan say from 7.010 to 7.110. displayed and the radio pane on the right is open, that bandwidth of 100 is spread over X pixels. When you close the radio pane, The pan does not expand the frequency. The range is still 7010 to 7110 but the width of the pan is now wider by the space that the radio pane took up. Lastly idea #3 is the API I spoke of above. But yes your idea of a transparent canvas provided by flex would be great as long as we still knew how to scale things so they aligned over the desired frequencies.

Mark_WS7M

Oh ya... my point of disagreement is in writing your own client. While I very much want to do so I think providing what Flex provides in SmartSDR takes a lot of work and they have it fine tuned to the radio so that when new firmware or updates come out everything mostly stays working. Any client written outside of that environment will be must more liable to being broken by updates.

James Whiteway

Mark, I "think" part of the problem is from some 3rd party controls that FRS is using in SSDR. Look in SSDR's install folder and you'll see which one's I'm talking about. I looked them up some time back and if I remember right, a couple are layout and graphics controls. I tried to use them, but they are licensed to FRS and I could not reference them in a test project. But, even so, what Walt says makes sense. Until multi-GUI is supported, you'll have to roll your own version of SSDR. James

Mark_WS7M

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.

Mark_WS7M

@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.

K5CG

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.

James Whiteway

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

Walt - KZ1F

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.

Mark_WS7M

something weird this way cometh...

Mark_WS7M

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.

Mark_WS7M

I was having all kinds of trouble posting the reply below

K5CG

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.

K5CG

Yes, I think we got 3 or 4 7 or 8 of them in email. No worries.

Barry N1EU

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

Mark_WS7M

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.

Peter K1PGV

James Whiteway

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

IW7DMH, Enzo

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