API control of panadapter Fill parameter

John G3WGV

I've recently upgraded to Smart SDR 2.1.33 and noticed the cool new Fill feature. Is control of this parameter possible via the API? I looked in FlexLib and can't see any obvious candidate, nor can I see any API traffic when I change the fill parameter via SSDR (I've done a 'sub pan all' and I do see other pan parameter changes).

73, John.

Mark WS7M

Hi John,

Just a guess... I suspect this is NOT something sent to the radio as it is really just a fill of the area under the data sent by the radio.  The radio doesn't do anything more than send you and array of line points.

James Whiteway

Mark is right. The fill feature is just GUI eye candy. Not anything tied to radio data itself. I had that working in my poor man's version of SSDR long before it happened in SSDR. But, I haven't touched that code in most of a year. If you're using C# instead of using DrawLine to connect the points from the panadapter data arrays being sent, take a look at using DrawRectangle instead. It has a Fill feature built into it. James WD5GWY

John G3WGV

Hi Mark and James, thanks for the replies. I see that but Smart SDR can get/set its value and the published API is supposed to be the same as that used by SSDR. So it's got to be there!

James Whiteway

No, because the "Fill" does not represent "Data" from or to the radio. It is strictly a visual , you as a developer, can create, using the Graphic features of any Controls available to you in your DEVELOPMENT Tool . In the case of Visual Studio and the C# language, it is, (in my case) the DrawRectangle Graphic command. Again, Fill, only occurs in the client application. Not in the radio itself. I could draw Happy Faces in the same area and it would not need any data to or from the radio. James WD5GWY

John G3WGV

Ok, I see what you are saying. Effectively it is a client function (SSDR in this case) that the radio has no say in and, importantly, isn't something other clients need to be aware of or have control of.

That's OK, though slightly disappointing - my non-GUI controller client runs in parallel with SSDR and can control just about every other visual aspect of SSDR, so this is something of an exception.

Not a problem in any sense, I was curious, went off to investigate and was surprised by what I found. Looks like I won't be writing that new bit of code after all!

James Whiteway

Exactly! It's really no different than not being able to change the color of SSDR's various controls. That is strictly a function of the client (SSDR in this case) and not the radio or any 3rd party app that happens to be running in conjunction with SSDR. The only reason you are able to control any part of SSDR, is because those commands and functions exist in the radio. What you see when you issue the AddPanadapter command for example, is the radio itself responding to the command and sending an Event Changed message to SSDR along with any associated data, that SSDR uses to construct a panadapter. Your 3rd party app is not talking directly to SSDR the Windows client/app, but, thru the API, to the radio. And as long as your app is not a GUI app that needs a panadapter of its own, you can indirectly issue commands that SSDR will show when it receives an Event Changed message from the radio. ( FRS defines a GUI app as any that needs the panadapter/Waterfall.....which won't be supported for 3rd party apps till they impliment MultiClient in SSDR) James WD5GWY

Wayne

John,

email me at kd5spx@gmail.com offline I have some info for you.