Access Flex 6000 basic info through web browser

EA4GLI

I would like to be able to type the IP address assigned or manually set on the Flex 6000 radio in a web browser and get basic information. I understand there is a lot of status info you can get from the radio, like temp, swr, frequency, etc... by creating an application (like FRstack). But the application is always tie to the operating system. A windows app, a mac app, etc....

Running a web server deamon inside the Flex 6000 radio will be great to get info from any device. I could open my android device web browser, point to http://192.192.1.x and get a web page with info from the radio. 

You could get your radio Name, ID, Slices active, frequency read out, PA Temperature, Power Out... even some statistics, time on, TX times, RX times, etc... In radios with the GPSDO you could also get time, date and location info and even serve it as NTP (netword time protocol) string. For example pointing to 192.168.1.x/npt gets you the string to be used by services that can read NTP that are connected to your local network.

With a simple username/password which can be changed through SmartSDR, you could access some functions like Turn ON or Turn OFF. I really like the idea to even be able to have RESET TO FACTORY command, REBOOT etc....

My understanding is that the Flex 6000 runs a linux distro inside, and a web server deamon wouldn't be taxing on the radio and could be very useful.

Just an idea!

Tim - W4TME

Remember, resources you use in the radio for non-radio functions results in fewer resources that can be used for actual radio features.

Kevin

Are resources becoming an issue? Can resource-intensive features have an on/off switch like WNB? Use it when needed?

Tim - W4TME

No, but they are finite.  Some features can be turned off, others not so easily.  The point being made is that any feature takes resources in the radio and programming resources ($$) as well.  So you have to be selective as to which ones provide the most global benefit.  I am not implying that this idea does or does not have global benefit, but that there are limits, as with any new feature.  Based on the scope, implementing this feature would be somewhat resource intensive. 

Sergey R5AU

For such realization better to use any external small server(ex.: Pi3) what can be utilize not only for RTP streaming but for ethernet VPN as well too, BTW this is one of the ways of the remote support.

Just as example and not any advert. - here http://www.cqham.ru/forum/showthread.php?34313-Software-Defined-Connectors&p=1318379#post1318379 Yurj UT4LW started thread with own utility for SunSDR2 transceiver  for support remote connection/LOGs/Profiles, however i am appreciate for such cases simple Linux server and RTP connections.

N6OIL

That site is GEO blocked here at work, darn.

EA4GLI

Well, they idea is that the Flex will provide the info by itself... And a website is OS agnostic.

KD7CAO

I really like this idea. You could take it a step further and use it for troubleshooting such as when your computer or Maestro's software can not see the radio you could point a browser to the radio and get the above information ensuring you are connected. How about having the ability to store the software for download when you may not have an internet connection available. Perhaps even a place to store logs, settings, other items. If space is an issue how about a flash drive out the back of the radio?

Walt - KZ1F

Or crate a MIB' internal to the radio and have NGINX or other mgmt console directly connect to it. That would be loads of fun creating hundreds if not thousands of jr system administrators that would keep the employees at FRS tied in knots explaining every internal metric available and what the combinations and permutations mean.. if you think about it, SSDRfW tracks many of these metrics and DDUtils tracks the others. Maybe the MIB can wait until the 7000. Personally, I'd much prefer FRS focus on whatever features can still fit into the box and drop the other distractions.

Sergey R5AU

i see plenty of spaces here and i hope FRS on the right way, to be pioneer of the SDR F6000 series gives many different ways in the future.

Rory, common Forum server is here:  www.cqham.ru,  SunSDR TRCVR is here- www. eesdr.com/en/ 
unfortunately mentioned tread above on RUS only, however SDC SW by UT4LW here (for SunSDR only)- https://drive.google.com/file/d/0B6nvX2SQAgY5SjZHcWVYZEFndEk/view  (WIN version)
RUS Manual here -https://drive.google.com/file/d/0B6nvX2SQAgY5VW91UktfbGVyNzA/view  i guess google translated well

Tim sorry, OFF Top here

EA4GLI

These are the kind of things that can set the Flex further apart from the competition. Great ideas.

EA4GLI

I don't think the idea presented here is to create a web server daemon inside the Flex instead of "other feature".

It is the idea that a network device could (should) be accesible by its IP address and display basic info that can be viewed by any system. It is a feature that works regardless of the Operating System. I can see myself putting a cheap 10 inch android tablet on the wall just reading info from the Flex. I can then get Time, Date, temperature, status of the radio, etc... how is that for coolness factor.

And it should just display info readily available. I am here, I am ID number ****, model #, I am on, I am connected to ****.

The second part of the feature, and that involves a bit more, is to have some authentication to allow for sending some commands. 

I fail to see that this will be resource intensive..... I am only sending text strings. And the daemon could be NWEB or SimpleHTTPServer, not a full fledged apache server.

IW7DMH, Enzo

Or you can build a Arduino web server that is able to find your Flex Rig and to dump its status through web pages.
It is not far from my Arduino switch box that relies on Arduino Flex libraries and has its own UDP protocol to set/read some Flex status variables. You could remove the UDP code and implements a specific Flex web server.
While it is a proof of concept device you can bet it can't be affected from OS issues.

73' Enzo
iw7dmh

 

Kevin

Just a reminder... there's a vote button at the top right of these idea posts. I have no clue whether they get any attention from FRS or not but it might be helpful to click it if you support the idea presented. In fact, I find it interesting to look back over older ideas in the community and reconsider them for my vote as I gain more experience with the Flex radio.

I know FRS has an issue with commitment but it really would be nice to see how these ideas and longer term bugs fit into their priority list.

Kev

EA4GLI

And that might end up being the case in my setup. I just thought that getting the info from the radio through a web server was a neat idea.

AA0KM

Smartsdr with out the fancy windows GUI like a DOS Box but through the web browser.
Really simple version with commands.
Not sure of what is to be gained by going this route.
But I suppose it would be less taxing on the computer it is run on.
If thats what you are asking seems like a good Idea.

73 Jeff

W4KCN

I did this with a .NET web application utilizing SignalR.  Allows me to control the rig via the web.

Although clunky, I stream my SSDR feed and needed a way to control the rig through a web interface. Hopefully, they will allow child clients in the future and can tap into existing panadapters.

Ria

It's definitely possible to pull the info via the flex API and from DDUtil (which is easy as well). I've tested a few things via a webserver as well.

I don't know the details of the flex hardware but even if there is room to spare, I'd rather just use a separate box... you guys use DDUtil, right? Put it on the same box, with lighty or apache, or even a Pi3. The APIs are open and it's easy to read data from DDUtil and the radio. I've been toying with the idea of a basic web panel for radio and station parameters (rotor, SteppIR, amp). 

Unfortunately with the election next week my bandwidth for programming projects is down to zero. So maybe afterwards.

But it's doable and not really hard for anyone with programming chops. 

KD7CAO

There is the kicker "But it's doable and not really hard for anyone with programming chops." Many of us don't have a clue how to program much more than a microwave timer. I consider myself to have advanced computer skills but programming code is not even remotely possible. I have an apache2 server at home on a Mint OS box for my Weewx station and can't for the life of me figure out how to get the data that is on the same box to work across two different programs. 

I would much rather see something physically built into the radio than something separate. There should not be much processing power or system resources tied up in something like this since there are many devices dating back to the 90s that can serve a basic webpage.

Ria

Of course. I would too. But I would rather have the radio be a radio first and foremost. I would not want to sacrifice performance for the convenience of web access. I'm not saying it can't be done but since I haven't physically gotten into my radio, I don't know what resources are available inside of it. I assume that Flex knows how much processing power is available.

What may be better is a companion app similar to SmartSDR CAT which polls the API and then uses a webserver on the host PC to serve up radio data. This would place almost zero load on the radio and allows you to use your PC to serve up the data. It could probably even be built into SmartSDR itself. 

EA4GLI

The key word being BASIC info. If it is in the radio we do not have to purchase yet another box. I just want to be able to get basic info out of the radio and read it with a web browser. If I have the radio in the network then I can just browse to the IP address and get info. I don't want to operate the radio through the web browser. 

Would a simple HTTP server tax the Flex so much? Really?

IW7DMH, Enzo

Actually APIs are for getting separated things tied together and this goal is fully achieved. Just think about SmartSdr, SmartSdr for Mac and the new Genius devices.
The good question is how much this code should be based on a Operating Systems. This dramatically reduces possibilities if you can give up high-level development systems. But consider that the embedded code, like the one in ours Flex Rigs, can go over Windows 10 or Sierra lifetime.

KC9NRN

How about an IFTTT recipe for turning the radio on or off, walk in the door and say to your Amazon Echo "Alexa, trigger Flex on" and when you get to your shack the radio is on and waiting.

I'm kinda kidding, but kinda not kidding....

KC9NRN

Salvador,

Adding basic functionality like you describe would not tax the 6000 but it would take time for them to create a secure interface for it. I would like this functionality as well but you know how people are, ok you gave me the basics, I love them now how about adding to them.

Walt - KZ1F

The thing about Apache2 Eric is it just serves up static pages, which is actually good as it has been around since dirt (so to speak) and is very efficient at what it does and largely bullet proof. For dynamic content which is what people are referring to you need a different container that is designed for dynamic content. Apache2 can act as a passthrough controlling the network side of the request/response but, in a controlled setting like behind your router, something like Jetty, Tomcat, Glassfish, Geronimo, is better, Tomcat or Jetty, being the lighter weight container as it is primarily a servlet container vs an enterprise container.

Think of SSDR (the radio) as a publish subscribe model. A app, any except for an app accessing panadapters and slices, connects to a radio it sees and subscribes to certain 'topics'. Currently, only a single app can register interest in panadapters and slices. Periodically information on those topics or, in some cases, completely asynchronous, information is deliver to all 'registered' clients. The client app then simply displays the received information. This is how SSDR is, relatively speaking, light weight. Information received and parsed from the radio is stored in radio attributes. A UI field links to it's peer attribute such that when that attribute in the radio instance changes it is automatically reflected in the display widget. But, as far as a SDRCat-like applet, how is that different that what DDUtils already displays?

Not to speak for Sal but I perceive the difference in what he is asking for is a web app to deliver the data to a browser. This would require a application container such as IIS (yuck, too heavy weight), or something like Tomcat that serves dynamic content.  If it is placed in the radio, that represents a lot of real estate just to make the data available at the same ip address that ssdr connects to.

Each one of these apps, be it SSDRfW, SSDRfIOS, XPSSDR, DDUtils, FlexMeter, etc connects to the radio and provides it with a UDP endpoint for itself. Let's say they all ask for the same information, each time that information in the radio changes the radio has to send a UDP packet to each application that registered interest in it. Most, if not all, apps using flexlib ultimate tell the radio they are interested in everything as that is what the Radio object's connect() method does.

But, yeah, I kind of agree with Sal that it is an interesting thought exercise.

KC9NRN

"Not to speak for Sal but I perceive the difference in what he is asking for is a web app to deliver the data to a browser."

Exactly how I took it.

Ria

Apache (or lighttpd or even IIS) can serve dynamic content via CGI or modules, it's not just for static content.

EA4GLI

I would love it! 

Walt - KZ1F

CGI? Wasn't that seriously before your time? Nobody does CGI anymore...maybe in highschool??? Certainly nobody professionally, it's a huge kludge.