Desires for SmartSDR & API

Mark_WS7M

I am fairly new to Flex radio but I jumped in because of the software interface. I've been doing software all my life and I can completely see how such a system could turn into something cool.

Here are some things I've not only heard but also would like to see Flex provide through SmartSDR and the API:

1) Remote access (WAN).  This needs to include tx/rx audio and the ability to remotely key for CW.  The abililty to fire up your laptop, connect to your radio from a hotel room and use it would be cool.  Yes you can do with VPN.  But I think native ability would be better.

2) Assuming #1 becomes a reality I really love the idea of making a slice available to other SmartSDR users.  I could imagine this would be on an invitation basis and once connected the slice looks and operates as if it was on your own flex.  Perhaps it has an additional annunciation showing it is remoted.   It would be a cool way to experience the world from another shack without the hassle of travel.

3) External API integration into SmartSDR.  I've done this for years with the software I've written.  You provide documentation and some basics on a protocol and a mechanism to setup the connection within SmartSDR.  The protocol would need to support things from simple data transfer to receiving data and posting it somewhere on a SmartSDR display.  It should also include controls.  This is a networked API meaning it can be manipulated over a network connection.  So a remote server, either over your LAN or even over the internet can provide data to SmartSDR.

So imagine something like this:

Flex defines a protocol.  To be an acceptable connection you must follow the protocol.

The protocol allows the remote server to do a number of things:  Simply receive data from SmartSDR, exchange data (two way), and also have SmartSDR display and provide controls.

Example:

Assume someone created a DX spots server that followed the Flex protocol.

Within SmartSDR, on a setup screen you give the IP address, port and some other info about the connection and enable it.  This could include how often to poll or send data etc.

SmartSDR would open the connection, verify the connection follows the protocol.  Then something like the following could happen:

SmartSDR -> server Request Spot Data, 7.000 -> 7.150  (so SmartSDR requests spots in a freq range)

Server -> SmartSDR  - Some packet of data that follows the protocol saying WS7M is at 7.023, KZ1F is at 7.031,  This return packet could contain display instructions of some form.

Upon receiving that packet SmartSDR paints the call signs above the frequency.

Of course to make something like this work there has to be a well defined protocol so that when the data is received by SmartSDR it can do something useful with it.  So simply sending back WS7M 7,023 is not enough.  It would need to include a display command so SmartSDR extracts the data, sees it must display it and does so.

So the API would need formats and commands to do a number of things.  For example:

cmd 1 - Display enclosed data at frequency on panadapter, lifetime (how long to keep it displayed)
cmd 2 - Display enclosed data in a notification window (like a DX spot log) within SmartSDR, include date/time stamp, serial number, etc (options in the packet)
cmd 3 - Create or update control window (creates a window to display controls for remote devices).  Included is a list of needed controls, current values, max values, etc.
cmd 4 ...
cmd 5 ...
...
...
cmd 24 - Here is a remote slice from server **** (this is the idea above)
etc... etc...

Now I'm sure some of you are concerned about security.  Keep in mind that in this protocol idea SmartSDR, your local copy, MUST BE SETUP AND MUST INITIATE THE CONNECTION.  The protocol could contain encryption and maybe authentication too.  But no your radio is not sitting there letting the world connect on in.

For the most concerned Ham you just don't enable any external servers.

For the more conservative you would make the connections on your local LAN so you'd need to install your own servers and set them up.

For the more connected ham they use the external connections but register and setup authentication and encryption.

So since you control the connection you have full control over how far you want to go.

But think about this idea for a second.  The Dx spots idea would not be difficult to implement.  Flex would need to provide a protocol and how to tell SmartSDR in the return packet where to post the data. But once the packet is received from the server SmartSDR just executes the commands in the packet.  So the call signs would be posted to the display.

This kind of external server/command protocol would remove from SmartSDR the requirement to have specific code.  There have been requests to put Dx spots on the panadapter.  To do this SmartSDR would need to connect to a spot server and support that servers protocol to gather the spot data.   What if the protocol changes?  A modification to SmartSDR would be required to get it working again.

Using the server idea whoever created the network server would make the change and SmartSDR would remain unchanged.  

I can see this concept working for many things.  For example some of use like the digital modes.  Right now to use them we have to run SmartSDR, setup DAX and then run some program like WSJT-X and it uses CAT to control the radio.  This all works pretty well but imagine that with a protocol like above you could even pipe the IQ data out, and have as a return the JT65 data directly showing up on the panadapter or even in a log window perhaps.

Anyway just dreaming a little.  As I said I've done this in commercial software I've written for device control and medical devices and it is very powerful but a lot of thought has to be put into the data exchange so things are kept clean and manageable.

In one program I did years ago, a wire pulling / monitoring application we supported network server data comm and allowed for a small but very powerful protocol.  This allowed the customer to feed data from our program into an external stat program that could be configured to transmit back display data to be shown on our display.  The cool thing was once it was up and working they could change the stat program and our software really didn't care.

Walt - KZ1F

Mark, what you are asking for exists. Remote will be internal to the public api in the SSDR 2.0 timeframe, maybe next year, maybe later, but in 2.0.

On the opening page, rather than defaulting to ALL, select API. FRS posts the source code for the interface code, called flexlib, for their C# GUI. Stu, I believe makes public the source for the Objective C or maybe its binary. I have a 100% compatible to flexlib java interface which is pretty close to method invocation. At this juncture, I do not intend to release the source for either it, XPSLib) or XPSSDR which is the cross platform (XPS is cross platform support).

Flexlib is intended to marry gui events to a cmd line tcp structure that is what actually sends commands and receives statuses from the radio. One could choose to do that natively in whatever language they want, Perl, Python, Ruby on Rails. Of course JRuby could use XPSLib as well as Groovy.

There is not javadoc or the C# equivalent really but there are samples floating around. Pick your poison.

Sorry, bad advice. On the 'menu bar', Home Category About, choose Category THEN choose API.

Mark_WS7M

Awesome to hear.

I am aware of the API but I was not aware it would have things like I propose... For example can I tell SmartSDR to display something at point point on the panadapter?   

Anyway good to hear.

Walt - KZ1F

Perhaps I misunderstood. FRS does not provide any windowing guidance or api. That part you own but the do provide asynchronous event callbacks you can register for.

Stu Phillips - K6TU

Mark,

It's worth drawing the distinction between SmartSDR - THE RADIO and SmartSDR - THE CLIENT.  The API is used between the radio and the client - stating the obvious (sorry) but much of what you are describing would require a second API to the CLIENT.

You might take a look at dogParkSDR which already has the capability of displaying spots on the pan adaptor - this is a Mac OS X client that also interfaces with MacLogger DX (its source of filtered spot information).

Many things are already possible for implementation on a client (dogParkSDR shows this as does my K6TU Remote iPad app).

It's just a simple matter of programming ;-)

Currently the API defines the interface between the client and the radio in radio terms - it would be great (some day) to have additional API's that provided access to the things you describe.  Many great and interesting things to wish for in the future!

Stu K6TU

Walt - KZ1F

You could certainly write a program to proxy requests from other users outbound of you program. Currently FRS does not provide for multiuser graphics but as "there is no problem in computer science that cannot be solved by adding another layer of indirection", you could proxy those requests.

Mark_WS7M

Hi Stu,

I own both dogPark and also your iPad client.  Both great products.  Dogpark is a great illustration of what can be done with the API.  In short dogpark does everything (almost) that SmartSDR does.

I do know that dogpark offers the spots which is pretty cool.

I guess I'm thinking about the path forward.  I'm not at all and expert and I am new to Flex so I have no idea what their plans are.  But frankly SmartSDR is very cool.  I find no matter what I am doing that I want it to be up and visible.  

So now for example to do jt65 I have SmartSDR plus WSJT-X both up and connected via cat/dax.  It works and works pretty nicely.  All good and probably things will remain this way for sometime.

But my point is that I think Howard said he wanted to see spots on the panadapter as a feature being added to SmartSDR.  This got me thinking about just how it could be added.

Of course the "usual" way would be for Flex to code up a module that connects to some spot server you could define in some setup screen and as long as that server returned data in a format they had planned on then they could map that data to be displayed on the pan...   All good until someone changes something and it breaks.

To me and from my experience in the device and medical software field this is all too common.  We have to transfer data from Lab Info Systems into our software.  The first time we did this years ago we accepted the format directly in our software and it worked very well UNTIL someone at one of the LIS systems added a field then everything broke until we could gen a new release with a fix.

So what we did for that fix was extract that logic out into a DLL that had a well defined interface so it could get data from the LIS but always put it in a format we wanted for our software.  The next time the LIS group made a change, we updated the DLL and everything was working.  Validating a DLL in our case was 2000 times easier than validating an entire new release.

So at 3am this morning I was considering the same thing for SmartSDR.  Now it could be that Flex has no desire to go this way but I started to think if they provided some primitives that could be linked to things then external servers/programs could do some fun stuff.

I imagined a set of primitives that allowed for drawing, creating small log windows, outputting to those windows and even setting up controls for things like rotors, amps etc.

So my process which I probably did not describe very well above is something like this:

1) Flex would have to provide a way in SmartSDR for you to add outbound connections.  Once you add and enable them, SmartSDR would attempt the connection and listen for commands.

2) The connected to program would have to abide by the primitive API.  So if it wanted to draw something on the panadapter it would have to format a packet of data exactly as specified to cause the data to be drawn on the panadapter.

3) Same logic for log windows, controls, etc.

By creating a detailed and powerful API flex takes themselves out of the business of manually maintaining spots and other tools they may want to integrate into SmartSDR.  They leave that up to the other parties that want to support it.

Anyway, it would be a lot of work but it could be very powerful and would allow SmartSDR to become the primary tool and allow integration of many features directly into SmartSDR without having to write code/modules for each one.

Stu Phillips - K6TU

Mark,

I think the challenge simply put is one of development resources and how FlexRadio applies those to deliver the largest bangs for their bucks.

The second challenge is handling all the different sources of information in a way that doesn't have FlexRadio impacted by third party changes - even the API approach you describe can have unintended performance consequences that appear as SmartSDR problems.

FlexRadio is very responsive in considering ways of enhancing the product in ways that provide a lot of leverage - these get worked into development priorities over time.

Stu K6TU

James Whiteway

Mark, It sounds like part of what you are proposing (#2) is something similar to allowing Plug-in's from 3rd parties in SSDR. That has been brought up in the past and FRS stated they were not in favor of it. I can see why they feel that way. It would have their support group going crazy trying to find if issues were their fault or that of the plug-in. Stu's version of Flexlib (for Apple devices) and Walt's (if he ever releases it :-) ) for Java, would be good if you wanted to write your own software for those platforms. I like Flexlib and C# and that's why I am learning that. But, I do intend to.learm Java as well. I would think what you are wanting, while a very good idea, would require a rewrite of Flexlib and the radio's firmware to accomodate all that you are asking. They may well be so deep into the current codebase, that such a rewrite, would be cost prohibitive. James WD5GWY

Walt - KZ1F

James, I have no particular issue with releasing it as a jar file (bytecode) but I'd need to obfuscate it first. I am, however, unaware of anyone embarking on a Java project for Flex control.

Peter K1PGV

he wanted to see spots on the panadapter as a feature being added to SmartSDR.  This got me thinking about just how it could be added.

You know... this keeps getting brought up, and I keep saying the same thing:  While the ability to display stuff in the Flex panadapter window would be handy, you don't really need Flex to add anything to SmartSDR to enable you to add stuff to their windows.  Just write a program that finds the window you want to display stuff in, and create your own window with a transparent background that overlays that window, and put whatever you want, wherever you want.

Or extend this idea to add forms/dialog adjacent to one of the SSDR displays.

It's not hard. It's something you need to do in C (not in a handy dandy .Net OO language)... Getting the Z-axis correct in all circumstances can be a bit tricky, but that's true ANY time you're playing games with windows.

Clearly not optimally convenient, but it'll work.

Peter
K1PGV

Mark_WS7M

Hi Peter,

Yes this is possible but what would be a pain is to match scale.  IE where should my transparent overlay paint the call or display I want?

To be useful things like a Dx spot belong over the place in the pan the station is at.  

I have not completely looked the API but it might be possible to determine the bounds of the frequency being displayed. But even then there is one other possible problem...

I suspect that to achieve the update rates Flex has on at least the pan I think they are double buffering things and writing out the entire new buffer every time.  If you were trying to update their window externally then this would be a problem.  The overlay idea might work.

M

Walt - KZ1F

yes, Peter has been consistent with his response here, as has his accuracy. The easiest thing for folks to do is write their own ui and merge dxcluster info with waterfall data. Personally, I think mapping to another apps window would be more difficult than an app the author can control. In any event this is not an frs issue.

Walt - KZ1F

In any event....boy its nice not to type on a tablet or tablet folio. In any event it would be instructive and informative for folks to write,initially, a small app, choose your language, that processes dxcluster info and processes the OnDataReady for waterfalls and merge the two. Each waterfall data callback has a preamble of what frequency the data starts at,to the left of the active window, and how many data items there are, and the bandwidth. This is why I said elsewhere there is some interpolation involved. I am sure there is some facsimile of this in WPF but in JavaFX you can have 'layers' and map the dxcluster info (for that band) on top of the waterfall info at the same offset into the window, I am highly confident Peter has more experience mapping to some other PID's window, then find the appropriate child window and figure it's bounds and overwrite it than I have. But if you are in C# and WPF the person to talk to is Peter. I would just suggest you come armed with some personal experience with processing the data. Seriously, as a user I would not want FRS to be spending dollars on staff time to merge some dxcluster information on their waterfall presentation. Spectrum data starts at x=0, waterfall data starts, if in the same coordinates, x <0, again, interpolation. So, in the overlay, write the text field of the callsign at the derived x value - 1/2 the width of the text data then rotate (transform) 90 degrees to make it vertical.

In the interpolation process, for each pixel you will have ascertained it's frequency against the sprectrum data, so you know where to center the dxcluster info, as that comes with it. Yeah, it may be off a tad, but it doesn't need single hz accuracy.

As Stu would say, it's not rocket science.

Mark_WS7M

Actually that sounds like kind of a fun exercise... I think I will try to grab the data coming out from the rig using the API and see if I can generate my own window with dx spots in it.  Would be kind of fun!

Walt - KZ1F

Mark, it is incredibly fun!! No doubt about it. This is why I said, 'pick your poison'.

Mark_WS7M

Well it's one reason I have this radio instead of any other.  I want to play with the thing and see what I can come up with.  For me in radio, 1/2 the fun is building, connecting, programming things to make a better station.

Like I recently added this 130 foot end fed wire antenna.  It works great.  In fact I was just testing some CW connections sending test test de ws7m and got a call back from Croatia on 25w.  

So much to experiment with, so little time!