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!
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!
Posted 1 year ago
Tim - W4TME, Customer Experience Manager
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.
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.
That site is GEO blocked here at work, darn.
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?
These are the kind of things that can set the Flex further apart from the competition. Great ideas.
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.
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.
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 XXX, model #, I am on, I am connected to xxx.
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.
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 XXX, model #, I am on, I am connected to xxx.
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.
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
(Edited)
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
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
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.
Ria - N2RJ, Elmer
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.
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.
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.
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.
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.
"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 - N2RJ, Elmer
Apache (or lighttpd or even IIS) can serve dynamic content via CGI or modules, it's not just for static content.
CGI? Wasn't that seriously before your time? Nobody does CGI anymore...maybe in highschool??? Certainly nobody professionally, it's a huge kludge.
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.... :)
I would love it!
Kevin K4VD, Elroy
Tim - W4TME, Customer Experience Manager