Over the past 15 (or thereabouts) years there have been several radios (both receivers and ham transceivers) which have used (or at least allowed) computer based (PC) user interfaces (UI).
This started with analog radios which, although they had a 'real buttons-and-knobs front panel', on the backside they had an interface that you could plug into with a computer if you wanted to. Then we had some analog radios that didn't have the buttons-and-knobs front panel (the Kachina and Ten-Tec Pegasus come-to-mind) but instead required that you interface with them through a PC UI. Then we had radios which began to use digital signal processing (DSP) and some of those off-loaded at least some of the processing to the PC and had a 'thick' inteface UI (the FLEX-5000 for one). Now we have radios which are (almost) entirely 'digital' - having co-located dedicated processing hardware (e.g. the FLEX-6000s) with a thin-EtherNet client UI used to take the place of the buttons-and-knobs that many of us grew up with (eons ago ....).
For the most part, ever since we began to move away from the physical buttons-and-knobs front panel, the PC UIs have taken their cue, on how they should look, from the previous physical front panel interfacing radios .... until the FLEX-6000 radios.
I confess .... I'm having trouble with the buttons-and-sliders on the right side of my SmartSDR UI screen .... with most of the real-estate being taken over by the panadaptor/spectrum analyzer display (I like the word Panadaptor ..... reminds me of when I was a kid - given a 1950s era Radio Products Panadaptor - got it working with my Lafayette HE-10 shortwave receiver - learning to adjust the IF amp's frequency response gave me an appreciation of critical-coupling and bandpass tuning).
I do not want to start a fuss. I'd just like to know if there are others who look at the Perseus UI (and similar) and think 'Ah ....' then the thought .... How hard would it be to use the API to build something similar for the FLEX-6000 ?
(Now I'll be quiet .... don't want to cause-a-stir .... just wanted to ask.)
- Paul, WB5AGF
This started with analog radios which, although they had a 'real buttons-and-knobs front panel', on the backside they had an interface that you could plug into with a computer if you wanted to. Then we had some analog radios that didn't have the buttons-and-knobs front panel (the Kachina and Ten-Tec Pegasus come-to-mind) but instead required that you interface with them through a PC UI. Then we had radios which began to use digital signal processing (DSP) and some of those off-loaded at least some of the processing to the PC and had a 'thick' inteface UI (the FLEX-5000 for one). Now we have radios which are (almost) entirely 'digital' - having co-located dedicated processing hardware (e.g. the FLEX-6000s) with a thin-EtherNet client UI used to take the place of the buttons-and-knobs that many of us grew up with (eons ago ....).
For the most part, ever since we began to move away from the physical buttons-and-knobs front panel, the PC UIs have taken their cue, on how they should look, from the previous physical front panel interfacing radios .... until the FLEX-6000 radios.
I confess .... I'm having trouble with the buttons-and-sliders on the right side of my SmartSDR UI screen .... with most of the real-estate being taken over by the panadaptor/spectrum analyzer display (I like the word Panadaptor ..... reminds me of when I was a kid - given a 1950s era Radio Products Panadaptor - got it working with my Lafayette HE-10 shortwave receiver - learning to adjust the IF amp's frequency response gave me an appreciation of critical-coupling and bandpass tuning).
I do not want to start a fuss. I'd just like to know if there are others who look at the Perseus UI (and similar) and think 'Ah ....' then the thought .... How hard would it be to use the API to build something similar for the FLEX-6000 ?
(Now I'll be quiet .... don't want to cause-a-stir .... just wanted to ask.)
- Paul, WB5AGF
Posted 5 years ago
Check out Android App on this forum.
Bill;
I you saw my cellphone you'd start laughing ..... 'being' a 3G phone is all that it can manage.
A good friend (ham of course) and his wife are both iPhone owners .... when I'm with them somewhere I find out which one has upgraded most recently (I should buy some Apple Stock .... its gotta' go up) .... We can be having lunch on a Saturday, or going to a hamfest, and if I innocently make the comment "I wonder ... ?" out comes the iPhone and it's 'Google-to-the-rescue'.
- Paul, WB5AGF
I you saw my cellphone you'd start laughing ..... 'being' a 3G phone is all that it can manage.
A good friend (ham of course) and his wife are both iPhone owners .... when I'm with them somewhere I find out which one has upgraded most recently (I should buy some Apple Stock .... its gotta' go up) .... We can be having lunch on a Saturday, or going to a hamfest, and if I innocently make the comment "I wonder ... ?" out comes the iPhone and it's 'Google-to-the-rescue'.
- Paul, WB5AGF
Paul,
No thanks.
If I wanted a radio "that looked like the Elecraft KX3 plugged into a FLEX-6000." I would buy it.
That's why I buy Flex! No knobs in my house.
Ps. I go to radio museum to see those knobs antique devices.
No thanks.
If I wanted a radio "that looked like the Elecraft KX3 plugged into a FLEX-6000." I would buy it.
That's why I buy Flex! No knobs in my house.
Ps. I go to radio museum to see those knobs antique devices.
(Edited)
Ernest;
To each their own .... :)
I even have one in my car (the 'UI' to the 5-speed manual transmission)
- Paul, WB5AGF
To each their own .... :)
I even have one in my car (the 'UI' to the 5-speed manual transmission)
- Paul, WB5AGF
You can't do good work without plenty of knobs-and-buttons :
LOL
I always have to chuckle whenever this topic comes up, and that the comparison to the controls for a vehicle or various other mechanical types of machinery is frequently brought up.
Basically the premise being that those items have physical controls and never software only controls. And they do so because physical controls make more sense, and yes, they basically do for mechanical things like vehicles and machinery. But that notion fails to consider that those types of objects are all "touchable" physical entities to begin with. And the controls that evolved to drive them are derived from that. In the case of our radio spectrum, it is mostly in the abstract. Nobody has every physically "touched" the radio spectrum with their hands to manipulate it or otherwise control it. So knobs and buttons of our radios are not just natural extensions of existing mechanical properties of the object being controlled like the controls are for vehicles and machinery.
So basically the knobs and buttons control interfaces that have dominated radio hardware user interfaces for 100+ years now were by virtue of necessity and cost considerations, not because they were ever the "optimal" way to do it.
The SDR technology of the last 10-15 years finally provides the opportunity to cost effectively do things that are truly more optimal to get around around the radio spectrum. Our beloved waterfall and pan adapters are a big piece of that. Those who "get it" when it comes to all this SDR stuff already know this.
But there certainly is legitimate debate for how to best design the interface to allow the user to get closer to the radio spectrum itself in various scenarios. But also there isn't a single best solution, there are differing operating styles and goals, with differing operating needs. So just one user interface is not appropriate for all use cases. And yes, physical knobs and buttons control panels do also have a place for certain operating regimes.
Basically the premise being that those items have physical controls and never software only controls. And they do so because physical controls make more sense, and yes, they basically do for mechanical things like vehicles and machinery. But that notion fails to consider that those types of objects are all "touchable" physical entities to begin with. And the controls that evolved to drive them are derived from that. In the case of our radio spectrum, it is mostly in the abstract. Nobody has every physically "touched" the radio spectrum with their hands to manipulate it or otherwise control it. So knobs and buttons of our radios are not just natural extensions of existing mechanical properties of the object being controlled like the controls are for vehicles and machinery.
So basically the knobs and buttons control interfaces that have dominated radio hardware user interfaces for 100+ years now were by virtue of necessity and cost considerations, not because they were ever the "optimal" way to do it.
The SDR technology of the last 10-15 years finally provides the opportunity to cost effectively do things that are truly more optimal to get around around the radio spectrum. Our beloved waterfall and pan adapters are a big piece of that. Those who "get it" when it comes to all this SDR stuff already know this.
But there certainly is legitimate debate for how to best design the interface to allow the user to get closer to the radio spectrum itself in various scenarios. But also there isn't a single best solution, there are differing operating styles and goals, with differing operating needs. So just one user interface is not appropriate for all use cases. And yes, physical knobs and buttons control panels do also have a place for certain operating regimes.
(Edited)
Duane;
My view is that people basically have not changed in a long (long) time. If you take a healthy human baby (at the right age for this sort of thing) and hold something bright-and-colorful in front of her-or-his face the child will reach out to grab it (and then they usually try to stick it in their mouths .... doubtless for further 'analysis'). If we had access to a baby from a thousand years ago (in good health) and ran the same test then I'm confident that the same results would be noted.
How many of us 'suffered' as we grew up being told, by those-in-charge, "don't point" ? (Is skeet-shooting an extension of pointing ? Seems likely.)
When NASA was gearing-up to send a few guys to the Moon 50 years ago what did they come up with for significant instrumentation changes ? A lot of the round gauges that populated aircraft got changed to vertical strip indicators - When the tape went 'up' the quantity was increasing .... When the tape went 'down' .... you get the idea.
What's been the big craze in aircraft instrumentation for the past 20 (or so) years ? Glass cockpits .... But have the engine throttles changed ? I don't believe so .... you still push them forward for more thrust or pull them back for less.
(Comment - several years ago I was in a western European country on business. The light switches in my hotel room were toggle switches wired so that up-was-off and down-was-on .... Gave me fits. I'll give-a-hint - the toilet was in a little room all by itself; when I first walked into the bathroom and looked around - I became concerned.)
The point is .... If something is familiar to us, and it works well, then making a change is risky as it may introduce unforeseen difficulties. (Has there ever been a major software release that was well tested beforehand ?)
- Paul, WB5AGF
My view is that people basically have not changed in a long (long) time. If you take a healthy human baby (at the right age for this sort of thing) and hold something bright-and-colorful in front of her-or-his face the child will reach out to grab it (and then they usually try to stick it in their mouths .... doubtless for further 'analysis'). If we had access to a baby from a thousand years ago (in good health) and ran the same test then I'm confident that the same results would be noted.
How many of us 'suffered' as we grew up being told, by those-in-charge, "don't point" ? (Is skeet-shooting an extension of pointing ? Seems likely.)
When NASA was gearing-up to send a few guys to the Moon 50 years ago what did they come up with for significant instrumentation changes ? A lot of the round gauges that populated aircraft got changed to vertical strip indicators - When the tape went 'up' the quantity was increasing .... When the tape went 'down' .... you get the idea.
What's been the big craze in aircraft instrumentation for the past 20 (or so) years ? Glass cockpits .... But have the engine throttles changed ? I don't believe so .... you still push them forward for more thrust or pull them back for less.
(Comment - several years ago I was in a western European country on business. The light switches in my hotel room were toggle switches wired so that up-was-off and down-was-on .... Gave me fits. I'll give-a-hint - the toilet was in a little room all by itself; when I first walked into the bathroom and looked around - I became concerned.)
The point is .... If something is familiar to us, and it works well, then making a change is risky as it may introduce unforeseen difficulties. (Has there ever been a major software release that was well tested beforehand ?)
- Paul, WB5AGF
Paul,
Your comments about the throttle controls vs. the instrumentation in modern aircraft underscores my point. The throttles are simply extensions of doing something "physical" to the engine. Whereas most of the instrumentation provides visual representations of many things that are not inherently visible otherwise, or at least visible with the required precision.
As for the shiny objects aspect, I want the dynamically changing RF spectrum information to always be the shiny object, and for it to not be competing with the radio's UI controls for my attention :).
Your comments about the throttle controls vs. the instrumentation in modern aircraft underscores my point. The throttles are simply extensions of doing something "physical" to the engine. Whereas most of the instrumentation provides visual representations of many things that are not inherently visible otherwise, or at least visible with the required precision.
As for the shiny objects aspect, I want the dynamically changing RF spectrum information to always be the shiny object, and for it to not be competing with the radio's UI controls for my attention :).
(Edited)
@ Paul. When one gets to designing things more complicated one needs to factor in psychology, neurology and many other disciplines to take into account instinctive behaviour. It is not just a matter of a designer giving the pilot a cockpit and saying 'learn it as I ain't changing anything'.
Regarding the light switch issue - that is the price you pay for being out of step with the vast majority of counties in the World (drives me nuts when I visit the USA too).
Regarding the light switch issue - that is the price you pay for being out of step with the vast majority of counties in the World (drives me nuts when I visit the USA too).
(Edited)
If it had a 2.5 - 3 inch tuning knob, that would be an awesome controller. But $199? Overkill, unless you already have one!
(Edited)
I don't think Paul means another "app" with a GUI. He wants a new box that plugs into the Flex, and gives you *real* knobs and buttons rather than another virtual front panel.
73, Jim
73, Jim
Jim;
Actually when I posted my original inquiry I was thinking of a software UI that would be more in-line with other radio's UIs (e.g. the Perseus).
However .... it's interesting that you made the comment you did ..... I've actually wondered (day-dreaming ?) at the practicability of putting together a physical UI (a 'box') that would (as you described) plug into the FLEX-6000.
(Back in the late 1980s I bought a Ten-Tec Paragon Transceiver and I've always thought that it has as 'sanitary' a radio control panel as I've ever seen. And then of course there' s the National HRO-500 Receiver .... goodness they're pretty.... <g>)
Just imagine a 'box' that looked like the Elecraft KX3 plugged into a FLEX-6000.
(One of the guys that I see every September at a hamfest in western Arkansas has a KX3 - the first time I saw his - it was all I could do not to call Elecraft and buy one.)
- Paul, WB5AGF
Actually when I posted my original inquiry I was thinking of a software UI that would be more in-line with other radio's UIs (e.g. the Perseus).
However .... it's interesting that you made the comment you did ..... I've actually wondered (day-dreaming ?) at the practicability of putting together a physical UI (a 'box') that would (as you described) plug into the FLEX-6000.
(Back in the late 1980s I bought a Ten-Tec Paragon Transceiver and I've always thought that it has as 'sanitary' a radio control panel as I've ever seen. And then of course there' s the National HRO-500 Receiver .... goodness they're pretty.... <g>)
Just imagine a 'box' that looked like the Elecraft KX3 plugged into a FLEX-6000.
(One of the guys that I see every September at a hamfest in western Arkansas has a KX3 - the first time I saw his - it was all I could do not to call Elecraft and buy one.)
- Paul, WB5AGF
KY6LA - Howard, Elmer
I use a KX3 sometimes at the NX6T contest station. Great receiver.
But like the K3 you really need to be EXTRA careful not to push the wrong button or hold a button too long or double click a button.. it then becomes a UI Nightmare with multiple nested menus to page thru.
Frankly I like the very clean SSDR visual interface
That said I have seen several interesting graphical UI.. for example
1. NaP3 has a really functional panadapter that shows spots and worked spots on the waterfall.... something we desperately need in SSDR.
2. the FMD-DUO UI uses different colors for different slices so you can quickly distinguish them..
there are many more
But like the K3 you really need to be EXTRA careful not to push the wrong button or hold a button too long or double click a button.. it then becomes a UI Nightmare with multiple nested menus to page thru.
Frankly I like the very clean SSDR visual interface
That said I have seen several interesting graphical UI.. for example
1. NaP3 has a really functional panadapter that shows spots and worked spots on the waterfall.... something we desperately need in SSDR.
2. the FMD-DUO UI uses different colors for different slices so you can quickly distinguish them..
there are many more
I've considered this, and often joked with my local friends that I could
interface a Elecraft K3/0 Mini to work with the Signature Series via a
BeagleBone Black or Raspberry Pi translator. Now that the remote audio codec is in place, it could be made to be a seamless experience.
I actually thought about building it but the $700 for a K3/0 Mini was more than I was willing to spend for a novelty item I didn't really care about.
I figured I could unveil it at Dayton and then run around Benny Hill with both the Elecraft and the Flex people chasing me with pitchforks for committing an act of heresy.
I actually thought about building it but the $700 for a K3/0 Mini was more than I was willing to spend for a novelty item I didn't really care about.
I figured I could unveil it at Dayton and then run around Benny Hill with both the Elecraft and the Flex people chasing me with pitchforks for committing an act of heresy.
Are referring to another type computer screen interface or a "knobs and buttons" physical interface?
In either case, don't think there would be that much demand to justify the expense.
Jim K4JAF
Jim;
I was a RF/Systems Engineer (back-in-the-day) and don't have the experience to know for sure what's practical to implement in a software-based UI.
My question (roughly speaking) was wondering-aloud how difficult it would be to use the FLEX-6000 API to put together a UI that is a bit less 'innovative' (i.e. more 'traditional') than what's currently provided ?
If I don't have any serious misunderstandings about what's implemented in the FLEX-6000 hardware then I suspect (but don't know) that there's enough horsepower-under-the-hood such that a minimalist interface can be implemented without-reinventing-the-wheel.
- Paul, WB5AGF
I was a RF/Systems Engineer (back-in-the-day) and don't have the experience to know for sure what's practical to implement in a software-based UI.
My question (roughly speaking) was wondering-aloud how difficult it would be to use the FLEX-6000 API to put together a UI that is a bit less 'innovative' (i.e. more 'traditional') than what's currently provided ?
If I don't have any serious misunderstandings about what's implemented in the FLEX-6000 hardware then I suspect (but don't know) that there's enough horsepower-under-the-hood such that a minimalist interface can be implemented without-reinventing-the-wheel.
- Paul, WB5AGF
KY6LA - Howard, Elmer
Paul
There is already an Open API which provides the data from the radio in VITA49 format. It's up to you to decide how you want to display it... I might add that they have not currently opened up the internal Display API but I am betting that will happen too...
There is already an Open API which provides the data from the radio in VITA49 format. It's up to you to decide how you want to display it... I might add that they have not currently opened up the internal Display API but I am betting that will happen too...
I remember the initial shock and a profound sense of loss, way back, when our new PDP-11/32 arrived with only a key on/off switch on the front panel.... what happened to all the toggle switches and lamps !?
A friend (ham) in Wisconsin had an Altair 8800 back in 1980 .... I had trouble understanding that anything useful could be accomplished flipping those toggle switches back-and-forth.
I remember when we got VT-220 terminals on-our-desks (now that was exciting).
- Paul, WB5AGF
I remember when we got VT-220 terminals on-our-desks (now that was exciting).
- Paul, WB5AGF
KY6LA - Howard, Elmer
I go way back before that ... We programed our computers with patch panels.. It was a miracle when we got a teletype and paper tape to load machine language code. Our computers were so slow, that if a tube burned out, I could grab it with a glove and change it out before the program lost its next step
(Edited)
Now Howard come on .... Next thing you'll be telling us is that you were a midshipman at Bletchley Park .....
KY6LA - Howard, Elmer
Not that old but it would have been fun.
Built my first computer in April 1958. 4 bits 8 tubes. Been playing with them ever since.
Built my first computer in April 1958. 4 bits 8 tubes. Been playing with them ever since.
Howard;
Ya' got me beat ....
I believe that was about when I taught myself that there was such a thing as series and parallel circuits while figuring out how to set off firecrackers electrically using the stranded steel wire in the battery powered phones that my folks bought me. (I ran the phone line from the wall in my mom's kitchen outside and up into the trees that were my imaginary 'ship' .... I 'sailed' the South Pacific from the pine trees in our backyard .... the TV show "Adventures In Paradise" was my favorite.)
- Paul, WB5AGF
Ya' got me beat ....
I believe that was about when I taught myself that there was such a thing as series and parallel circuits while figuring out how to set off firecrackers electrically using the stranded steel wire in the battery powered phones that my folks bought me. (I ran the phone line from the wall in my mom's kitchen outside and up into the trees that were my imaginary 'ship' .... I 'sailed' the South Pacific from the pine trees in our backyard .... the TV show "Adventures In Paradise" was my favorite.)
- Paul, WB5AGF
KY6LA - Howard, Elmer
I had a cousin who was a physicist who was working on the very early computers in the 1940-50's He caused me to become really interested in computers. He would let me wire up program patch panels for him which I thought was really cool.
So in 1958 thinking I was the high school computer maven, I built a 4 bit 8 tube computer for a Science Fair. My physics teacher said "Blah"... ( i stole that design from Popular Electronics)
So I built 2 - 4 bit computers and hooked them together with wire to send counts from one to the other.... My physics teacher said "Blah"
So I built a single tube transmitter and used my Mom's 1935 AM Radio, connected them to the respective computers and sent data counts wirelessly over the air between them.
My physics teacher said "Amazing...But it's illegal"...
"Why?" I said,
He said; "You need a Ham License to use that transmitter"
"What's a Ham License?" I said
I got a Ham License, won the Science Fair which got me far too young admission into engineering college and the rest is history.
So in 1958 thinking I was the high school computer maven, I built a 4 bit 8 tube computer for a Science Fair. My physics teacher said "Blah"... ( i stole that design from Popular Electronics)
So I built 2 - 4 bit computers and hooked them together with wire to send counts from one to the other.... My physics teacher said "Blah"
So I built a single tube transmitter and used my Mom's 1935 AM Radio, connected them to the respective computers and sent data counts wirelessly over the air between them.
My physics teacher said "Amazing...But it's illegal"...
"Why?" I said,
He said; "You need a Ham License to use that transmitter"
"What's a Ham License?" I said
I got a Ham License, won the Science Fair which got me far too young admission into engineering college and the rest is history.
When people comment about how difficult it was to program computers with toggle switches, etc. and how nothing much could be done with such simple programming, I am reminded how they had to reprogram the computers on the LEM and Command Modules in the Apollo program. It must have been a nightmare reprogramming the things on Apollo 13 in order to bring the guys back safely!
I don't remember how many lines of code they had to enter in HEX with a simple numeric keypad.....I have seen the documentaries, and all of that "modern" technology looks so ancient to us now!
Myself... I began programming in the late 70's on punch cards and FORTRAN. Then moved to various forms of basic. I have dabbled a little bit with "Processing" a derivative of JAVA in order to customize two different MIDI Controllers for my 6500, based upon the excellent work that William is doing. I have gotten stalled right now, trying to get my tower and LP in the air. But then I hope to finish some more elaborate stuff with the MIDI controllers and API functions. I have the theory in my head, just don't have the time to do it yet.
I still haven't wrapped my head around the transition to "object" level programming vs the linear logic of subroutines, IF/THEN/ELSE, DO Loops, and such that were the mainstay of programming when I was in college. At present, I know enough to vaguely follow what people are discussing, and perhaps take a few ideas and implement them as variations, but couldn't do much of it myself from scratch....yet.....I am a fast learner!
In the subject of "interfaces" my opinion is that there many, if not most functions that are easier and more efficient using the type of interface provided in SSDR right now. But there are others, such as tuning frequencies rapidly during a contest or searching for DX that seem to work better when there is some physical feedback, such as in a weighted tuning knob, where it is easier to control not only the amount of change but the speed of it at the same time.
The same thing is true when driving a car. My dad had a mercury back in the day that I absolutely hated to drive because its power steering was "too powerful." i.e. it gave me absolutely NO tactile feedback from the road. I felt so isolated from the road that my hands couldn't keep good control of the car.... It weaved back and forth because every slight fidget was translated into movement on the road. My other car, on the other hand, had some mechanical feedback that gave pressure back to my hand and let me know when I was applying turning pressure to the wheel. This was very important. It was an issue that many automotive engineers had to put into their designs when they developed the "drive by wire" systems using electrically operated steering motors linked to a wheel with no actual physical connection to the steering train.
On the SDR, there are still several functions that are much more convenient to activate on my MIDI panel without losing focus on the computer screen, rather than mousing around looking for the correct menu to drop and click. But that is the beauty of SDR...I can design a MIDI interface, or others can design one for their iPad or Android and lay it out exactly the way we want it... the best of both worlds!
It is a great time to be a ham......
Ken - NM9P
I don't remember how many lines of code they had to enter in HEX with a simple numeric keypad.....I have seen the documentaries, and all of that "modern" technology looks so ancient to us now!
Myself... I began programming in the late 70's on punch cards and FORTRAN. Then moved to various forms of basic. I have dabbled a little bit with "Processing" a derivative of JAVA in order to customize two different MIDI Controllers for my 6500, based upon the excellent work that William is doing. I have gotten stalled right now, trying to get my tower and LP in the air. But then I hope to finish some more elaborate stuff with the MIDI controllers and API functions. I have the theory in my head, just don't have the time to do it yet.
I still haven't wrapped my head around the transition to "object" level programming vs the linear logic of subroutines, IF/THEN/ELSE, DO Loops, and such that were the mainstay of programming when I was in college. At present, I know enough to vaguely follow what people are discussing, and perhaps take a few ideas and implement them as variations, but couldn't do much of it myself from scratch....yet.....I am a fast learner!
In the subject of "interfaces" my opinion is that there many, if not most functions that are easier and more efficient using the type of interface provided in SSDR right now. But there are others, such as tuning frequencies rapidly during a contest or searching for DX that seem to work better when there is some physical feedback, such as in a weighted tuning knob, where it is easier to control not only the amount of change but the speed of it at the same time.
The same thing is true when driving a car. My dad had a mercury back in the day that I absolutely hated to drive because its power steering was "too powerful." i.e. it gave me absolutely NO tactile feedback from the road. I felt so isolated from the road that my hands couldn't keep good control of the car.... It weaved back and forth because every slight fidget was translated into movement on the road. My other car, on the other hand, had some mechanical feedback that gave pressure back to my hand and let me know when I was applying turning pressure to the wheel. This was very important. It was an issue that many automotive engineers had to put into their designs when they developed the "drive by wire" systems using electrically operated steering motors linked to a wheel with no actual physical connection to the steering train.
On the SDR, there are still several functions that are much more convenient to activate on my MIDI panel without losing focus on the computer screen, rather than mousing around looking for the correct menu to drop and click. But that is the beauty of SDR...I can design a MIDI interface, or others can design one for their iPad or Android and lay it out exactly the way we want it... the best of both worlds!
It is a great time to be a ham......
Ken - NM9P
When people comment about how difficult it was to program computers with toggle switches, etc. and how nothing much could be done with such simple programming, I am reminded how they had to reprogram the computers on the LEM and Command Modules in the Apollo program. It must have been a nightmare reprogramming the things on Apollo 13 in order to bring the guys back safely!
I don't remember how many lines of code they had to enter in HEX with a simple numeric keypad.....I have seen the documentaries, and all of that "modern" technology looks so ancient to us now!
Myself... I began programming in the late 70's on punch cards and FORTRAN. Then moved to various forms of basic. I have dabbled a little bit with "Processing" a derivative of JAVA in order to customize two different MIDI Controllers for my 6500, based upon the excellent work that William is doing. I have gotten stalled right now, trying to get my tower and LP in the air. But then I hope to finish some more elaborate stuff with the MIDI controllers and API functions. I have the theory in my head, just don't have the time to do it yet.
I still haven't wrapped my head around the transition to "object" level programming vs the linear logic of subroutines, IF/THEN/ELSE, DO Loops, and such that were the mainstay of programming when I was in college. At present, I know enough to vaguely follow what people are discussing, and perhaps take a few ideas and implement them as variations, but couldn't do much of it myself from scratch....yet.....I am a fast learner!
In the subject of "interfaces" my opinion is that there many, if not most functions that are easier and more efficient using the type of interface provided in SSDR right now. But there are others, such as tuning frequencies rapidly during a contest or searching for DX that seem to work better when there is some physical feedback, such as in a weighted tuning knob, where it is easier to control not only the amount of change but the speed of it at the same time.
The same thing is true when driving a car. My dad had a mercury back in the day that I absolutely hated to drive because its power steering was "too powerful." i.e. it gave me absolutely NO tactile feedback from the road. I felt so isolated from the road that my hands couldn't keep good control of the car.... It weaved back and forth because every slight fidget was translated into movement on the road. My other car, on the other hand, had some mechanical feedback that gave pressure back to my hand and let me know when I was applying turning pressure to the wheel. This was very important. It was an issue that many automotive engineers had to put into their designs when they developed the "drive by wire" systems using electrically operated steering motors linked to a wheel with no actual physical connection to the steering train.
On the SDR, there are still several functions that are much more convenient to activate on my MIDI panel without losing focus on the computer screen, rather than mousing around looking for the correct menu to drop and click. But that is the beauty of SDR...I can design a MIDI interface, or others can design one for their iPad or Android and lay it out exactly the way we want it... the best of both worlds!
It is a great time to be a ham......
Ken - NM9P
I don't remember how many lines of code they had to enter in HEX with a simple numeric keypad.....I have seen the documentaries, and all of that "modern" technology looks so ancient to us now!
Myself... I began programming in the late 70's on punch cards and FORTRAN. Then moved to various forms of basic. I have dabbled a little bit with "Processing" a derivative of JAVA in order to customize two different MIDI Controllers for my 6500, based upon the excellent work that William is doing. I have gotten stalled right now, trying to get my tower and LP in the air. But then I hope to finish some more elaborate stuff with the MIDI controllers and API functions. I have the theory in my head, just don't have the time to do it yet.
I still haven't wrapped my head around the transition to "object" level programming vs the linear logic of subroutines, IF/THEN/ELSE, DO Loops, and such that were the mainstay of programming when I was in college. At present, I know enough to vaguely follow what people are discussing, and perhaps take a few ideas and implement them as variations, but couldn't do much of it myself from scratch....yet.....I am a fast learner!
In the subject of "interfaces" my opinion is that there many, if not most functions that are easier and more efficient using the type of interface provided in SSDR right now. But there are others, such as tuning frequencies rapidly during a contest or searching for DX that seem to work better when there is some physical feedback, such as in a weighted tuning knob, where it is easier to control not only the amount of change but the speed of it at the same time.
The same thing is true when driving a car. My dad had a mercury back in the day that I absolutely hated to drive because its power steering was "too powerful." i.e. it gave me absolutely NO tactile feedback from the road. I felt so isolated from the road that my hands couldn't keep good control of the car.... It weaved back and forth because every slight fidget was translated into movement on the road. My other car, on the other hand, had some mechanical feedback that gave pressure back to my hand and let me know when I was applying turning pressure to the wheel. This was very important. It was an issue that many automotive engineers had to put into their designs when they developed the "drive by wire" systems using electrically operated steering motors linked to a wheel with no actual physical connection to the steering train.
On the SDR, there are still several functions that are much more convenient to activate on my MIDI panel without losing focus on the computer screen, rather than mousing around looking for the correct menu to drop and click. But that is the beauty of SDR...I can design a MIDI interface, or others can design one for their iPad or Android and lay it out exactly the way we want it... the best of both worlds!
It is a great time to be a ham......
Ken - NM9P
I don't know why the forum double-posted my last lengthy post, but I have tried several times to delete one of them, and it won't go away. Sorry.
Technically the LM was not programmed with toggle switches -- its program was hard-wired into core memory. However certain trajectory variables involving subtle forces (light pressure, etc) could not be modeled far in advance and these were uplinked via telemetry during the mission. As a contingency if communications were lost, lists of these variables and state data were periodically read up to the astronauts, who could enter them by hand using the DSKY keypad (not toggle switches): http://www.ohiocityproductions.com/kscvisit.com/art/apollo-AGC-pad.png
The Apollo Guidance Computer had about 72 kilobytes of core memory, 4k of re-writable memory, and a memory cycle time of 11.7 microseconds, equating to roughly 85,000 instructions per second. The production AGC was wire-wrapped: http://www.ibiblio.org/apollo/AgcWirewrappedBackplane.jpg
However, running mostly assembly language it was capable of fly-by-wire real time control of the vehicle, plus navigation, monitoring of instruments and driving numeric displays. No Apollo guidance computer ever crashed during a mission, although during the Apollo 11 lunar descent it almost did. I did a custom edit combining various NASA audio files of the Apollo 11 descent which emphasized the decision making on the computer problem. Most people have never heard this. It and my transcript were posted here: http://forum.nasaspaceflight.com/index.php?topic=35230.msg1229852#msg1229852
It may be interesting to those working with critical real-time or embedded software systems.
The Apollo Guidance Computer had about 72 kilobytes of core memory, 4k of re-writable memory, and a memory cycle time of 11.7 microseconds, equating to roughly 85,000 instructions per second. The production AGC was wire-wrapped: http://www.ibiblio.org/apollo/AgcWirewrappedBackplane.jpg
However, running mostly assembly language it was capable of fly-by-wire real time control of the vehicle, plus navigation, monitoring of instruments and driving numeric displays. No Apollo guidance computer ever crashed during a mission, although during the Apollo 11 lunar descent it almost did. I did a custom edit combining various NASA audio files of the Apollo 11 descent which emphasized the decision making on the computer problem. Most people have never heard this. It and my transcript were posted here: http://forum.nasaspaceflight.com/index.php?topic=35230.msg1229852#msg1229852
It may be interesting to those working with critical real-time or embedded software systems.
(Edited)
Yes, I remember hearing the 1201 overrun error (or something like that) and the last minute reset that got things back on line seconds before an abort was required. I also remember that they almost ran out of fuel in the descent engine. Of course I was only 5 years old back then, but my little brother and I were more versed in things Apollo than many of the newscasters appeared to be. (in a 5 year old mind!)
I have seen footage of them using the DSKY pad. memories, memories....
I have seen footage of them using the DSKY pad. memories, memories....
Robert -- N5IKD, Elmer
Many people are experimenting with using MIDI controllers with micro-controllers for this very purpose.
https://community.flexradio.com/flexr...
Others are using iPad and Android apps for this.
https://community.flexradio.com/flexr...
Others are using iPad and Android apps for this.
Robert;
I've looked at K6TU's Apple app to see if it's clear to me (I want to understand) that all critical whistles-and-bells are there.
Makes me wonder what it would take to provide a similar control interface as a PC UI ? (Or, since it runs on portable Apple devices .... How hard would it be to port the app to OSX ?)
- Paul, WB5AGF
I've looked at K6TU's Apple app to see if it's clear to me (I want to understand) that all critical whistles-and-bells are there.
Makes me wonder what it would take to provide a similar control interface as a PC UI ? (Or, since it runs on portable Apple devices .... How hard would it be to port the app to OSX ?)
- Paul, WB5AGF
Stu would obviously be the best person to ask but my understanding is Stu wrote a contest centric UI. Which is actually smart. If all you want to do is work a contest, you don't want all the fru fru stuff muddying up the water vs. laser focused on the one goal fast efficient contesting.
Robert;
I didn't understand the sirens' call of MIDI Controllers until I began to read (and look) at the FLEX forum threads (what you referenced and : https://community.flexradio.com/flexradio/topics/hercules-midi-with-6300).
When I originally saw the term MIDI in the FLEX forums I remembered years ago when people were creating really clunky sounding imitations of piano music (or Stars-And-Stripes-Forever via MIDI; shudder) .... I was not 'current' and did not realize that the MIDI interface has spawned several physical interface 'boxes' .... now I see the attraction.
(True Confession - I still think it'd be neat to put a 'thin-box' together that looked something like the Ten-Tec Paragon's front panel but with a circuit board behind it that interfaced with the physical front-panel controls and then provided the data interface back to the FLEX Radio.)
- Paul, WB5AGF
I didn't understand the sirens' call of MIDI Controllers until I began to read (and look) at the FLEX forum threads (what you referenced and : https://community.flexradio.com/flexradio/topics/hercules-midi-with-6300).
When I originally saw the term MIDI in the FLEX forums I remembered years ago when people were creating really clunky sounding imitations of piano music (or Stars-And-Stripes-Forever via MIDI; shudder) .... I was not 'current' and did not realize that the MIDI interface has spawned several physical interface 'boxes' .... now I see the attraction.
(True Confession - I still think it'd be neat to put a 'thin-box' together that looked something like the Ten-Tec Paragon's front panel but with a circuit board behind it that interfaced with the physical front-panel controls and then provided the data interface back to the FLEX Radio.)
- Paul, WB5AGF
That's roughly the idea behind using the Tmate2 with my N4PY software.
Robert -- N5IKD, Elmer
The best part about adding our own knobs is that we can define and refine the functions as we wish.( Software defined knobs)
Paul, I have had that idea for quite some time. But, I have planned to use an old Drake rig I have sitting here that has so many internal problems, that it is beyond salvage. BUT, the case looks nice and all the controls and knobs are there. So, finding a way to interface the controls to an Arduno or even one of the NUC computer modules, and using that as a remote control to SSDR, or even another stand alone app to control the radio, would be a fun project. Just not near enough time to do it. Not to mention all my boatanchor friends would disown me!
james
WD5GWY
james
WD5GWY
James;
While I admire your inventive-ness (I have my R-4B in the closet), do you think perhaps that we are straying perhaps a bit far afield .... from reality ? (I'm beginning to imagine John Cleese in one of his skits working on something like this ('The Bureau Of Funny Control Panels ?') ..... or perhaps a famous canine from that side of the pond ?)
- Paul, WB5AGF
While I admire your inventive-ness (I have my R-4B in the closet), do you think perhaps that we are straying perhaps a bit far afield .... from reality ? (I'm beginning to imagine John Cleese in one of his skits working on something like this ('The Bureau Of Funny Control Panels ?') ..... or perhaps a famous canine from that side of the pond ?)
- Paul, WB5AGF
Only a bit :-)
But, it can be done and would be different!
But, straying from reality? Not really. Hardware is there, just requires hooking up all the correct parts and writing some software to go with it.
And, it's better than throwing away an old rig that still looks good.
james
WD5GWY
But, it can be done and would be different!
But, straying from reality? Not really. Hardware is there, just requires hooking up all the correct parts and writing some software to go with it.
And, it's better than throwing away an old rig that still looks good.
james
WD5GWY
James;
After I uploaded the Gromit control panel picture I began to reconsider :
- plenty of buttons ..... Check
- some nice large control knobs ..... Check
- flashing lights .... Check
- easy access panels ..... Check
- (and don't forget) that large, green, rotary knob .... Check
- ergonomically-approved operator's chair ..... Check
- (and last-but-not-least) headphones ..... Check
- (but wait !) where's the meter ?! Oh (whew) there on the left .... Check
See the circular viewport in front of Gromit ? Remember the pictures
of the round CRTs at Palo Alto Research Center ('PARC') in the 1960's ?
We could slip one of babies in there - at convenient eye level.
(This could be the new human interface radio control panel design mantra !)
re> your comment "Hardware is there ..." That sounds positively 'Zen'.
(What was it that the guy said when asked why he wanted
to climb Mt Everest ..... "because it is there.")
re> your comment "it's better than throwing away an old rig that still looks good."
You give me hope .... It almost broke-my-heart when I read that the
National HRO-500 Receiver wasn't-all-that-hot as regards dynamic
range (its bipolar transistors are somewhat prone to overloading) ....
Are we finding synergy with the steampunk design ethos ?
- Paul, WB5AGF
After I uploaded the Gromit control panel picture I began to reconsider :
- plenty of buttons ..... Check
- some nice large control knobs ..... Check
- flashing lights .... Check
- easy access panels ..... Check
- (and don't forget) that large, green, rotary knob .... Check
- ergonomically-approved operator's chair ..... Check
- (and last-but-not-least) headphones ..... Check
- (but wait !) where's the meter ?! Oh (whew) there on the left .... Check
See the circular viewport in front of Gromit ? Remember the pictures
of the round CRTs at Palo Alto Research Center ('PARC') in the 1960's ?
We could slip one of babies in there - at convenient eye level.
(This could be the new human interface radio control panel design mantra !)
re> your comment "Hardware is there ..." That sounds positively 'Zen'.
(What was it that the guy said when asked why he wanted
to climb Mt Everest ..... "because it is there.")
re> your comment "it's better than throwing away an old rig that still looks good."
You give me hope .... It almost broke-my-heart when I read that the
National HRO-500 Receiver wasn't-all-that-hot as regards dynamic
range (its bipolar transistors are somewhat prone to overloading) ....
Are we finding synergy with the steampunk design ethos ?
- Paul, WB5AGF
@Robert: you hit the target talking about "Software defined knobs". I think we only need some kind of K3-0 device with open programming APIs. I don't think we need more buttons: if only SSDR would give detachable panels we could position all controls in a very simple touchscreen display and position a panafall for each other big monitor.
@James: I am going on with my arduino projects and now I have programmed most of the SSDR controls. The ones I prefer are the two dedicated knob for filter bandwidth: they can work in HI/LOW or SHIFT/WIDTH mode; you can toggle between with a short click on any of the two knobs and you can reset (normalize) filter bandwidth (400HZ CW, 2400Hz SSB) with a long click. It is the same behaviour you can find in a K3 rig and I think it is the best I ever found. You can use it without having to look at the monitor nor to deal with mouse. Simple use it while you are looking signals on the panadaptor.
This part of my code is still not very stable, but there is a part of it, that give you the opportunity to program your own knobs and that works fine. You will find my libraries at this link https://community.flexradio.com/flexradio/topics/arduino-library-and-examples.
73' Enzo
@James: I am going on with my arduino projects and now I have programmed most of the SSDR controls. The ones I prefer are the two dedicated knob for filter bandwidth: they can work in HI/LOW or SHIFT/WIDTH mode; you can toggle between with a short click on any of the two knobs and you can reset (normalize) filter bandwidth (400HZ CW, 2400Hz SSB) with a long click. It is the same behaviour you can find in a K3 rig and I think it is the best I ever found. You can use it without having to look at the monitor nor to deal with mouse. Simple use it while you are looking signals on the panadaptor.
This part of my code is still not very stable, but there is a part of it, that give you the opportunity to program your own knobs and that works fine. You will find my libraries at this link https://community.flexradio.com/flexradio/topics/arduino-library-and-examples.
73' Enzo
@Robert: you hit the target talking about "Software defined knobs". I think we only need some kind of K3-0 device with open programming APIs. I don't think we need more buttons: if only SSDR would give detachable panels we could position all controls in a very simple touchscreen display and position a panafall for each other big monitor.
@James: I am going on with my arduino projects and now I have programmed most of the SSDR controls. The ones I prefer are the two dedicated knob for filter bandwidth: they can work in HI/LOW or SHIFT/WIDTH mode; you can toggle between with a short click on any of the two knobs and you can reset (normalize) filter bandwidth (400HZ CW, 2400Hz SSB) with a long click. It is the same behaviour you can find in a K3 rig and I think it is the best I ever found. You can use it without having to look at the monitor nor to deal with mouse. Simple use it while you are looking signals on the panadaptor.
This part of my code is still not very stable, but there is a part of it, that give you the opportunity to program your own knobs and that works fine. You will find my libraries at this link https://community.flexradio.com/flexradio/topics/arduino-library-and-examples.
73' Enzo
@James: I am going on with my arduino projects and now I have programmed most of the SSDR controls. The ones I prefer are the two dedicated knob for filter bandwidth: they can work in HI/LOW or SHIFT/WIDTH mode; you can toggle between with a short click on any of the two knobs and you can reset (normalize) filter bandwidth (400HZ CW, 2400Hz SSB) with a long click. It is the same behaviour you can find in a K3 rig and I think it is the best I ever found. You can use it without having to look at the monitor nor to deal with mouse. Simple use it while you are looking signals on the panadaptor.
This part of my code is still not very stable, but there is a part of it, that give you the opportunity to program your own knobs and that works fine. You will find my libraries at this link https://community.flexradio.com/flexradio/topics/arduino-library-and-examples.
73' Enzo
Thank you Enzo! I have downloaded your libraries. I do appreciate all your hard work. I have thought of using different devices as a control surface for SSDR and the idea I have for recycling an old transceiver keeps coming back to me. It would be a fun project in my mind. And using something like an Arduno to interface the controls on the old radio to my computer would be a challenge but, doable.
Thanks again.
james
WD5GWY
Thanks again.
james
WD5GWY
Well, there is the work William is doing. What I am doing is a new and replacement for the FRS FlexLib. The UI will be runnable everywhere and take the best parts, well, what I perceive as the best parts of the SSDR plus some missing features. After that process is complete I will create an HTTP based UI That will be markedly different. While some like the panadapter concept it is too married to the single application model. I will be removing that restriction and, indeed, making both the spectrum display and waterfall option. There is no reason why a smartphone display would not suffice to adequately handle a qso, spot to log entry.
Walt;
Is it feasible to implement a FLEX UI under LINUX, and by virtue of that have it functional on both native LINUX boxes as well as under OSX (a friend, another ham, tells me that he has had reasonable success at porting LINUX applications to run under OSX) ?
I believe that it is correct to say that anytime a software application is run under an OS other than what it's native to .... that processing speed suffers .... but I've been reading that there are people who believe that PC hardware is now fast enough to allow running virtual OSs for everything (multiple OS 'windows' all open on the same PC desktop ?).
- Paul, WB5AGF
Is it feasible to implement a FLEX UI under LINUX, and by virtue of that have it functional on both native LINUX boxes as well as under OSX (a friend, another ham, tells me that he has had reasonable success at porting LINUX applications to run under OSX) ?
I believe that it is correct to say that anytime a software application is run under an OS other than what it's native to .... that processing speed suffers .... but I've been reading that there are people who believe that PC hardware is now fast enough to allow running virtual OSs for everything (multiple OS 'windows' all open on the same PC desktop ?).
- Paul, WB5AGF
Paul, that is, what you just said, the necessity, being the mother of the invention. Yes, my primary goal is to have a smarter SSDR running on Linux. As it happens, it will also run on Mac and Windows and Raspberry Pi. In theory, it should work on Android but there are other things I plan for Android so it may get a unique UI and even more unique features.
Your second paragraph is kind of wrong, well, depending on what you really meant. If you are strictly talking about Parallels or KVM or VMWare, it depends. KVM, of which I know the most actually, depending on the app, could run faster in a virtual machine. I am not doing a virtual machine implementation, these will be native apps and, absolutely, run faster than a virtualized Windows environment running SDR. There is a real world case where rather than buy every employee their own machine, they get a virtual version of what that machine would be running. It's called virtual desktop Infrastructure. That provides way better security and cost structures to companies. You've likely heard a lot about 'the cloud'. That is, essentially, what in a business environment you are talking about. There is about a 10:1 ratio between a host machine and the number of virtual machines it can support. When you talk about something just a degree or two away from that, 'containers' there is a 100:1 ratio. However, what I am doing won't require virtualization. It is a single app that will natively run on Linux and many other platforms, even Windows. Having said all that, the one can I have, to date, kicked down the road is DAX / virtual audio channels. At this moment I do not know how to create a virtual device in Linux. It's not an impossible task, just not one I taken on as yet. The other issue is DAX is used to logically connect HRD or CW Skimmer to SSDR. Where they are all Windows applications connecting to them from not Windows is problematic. However, the better design is to connect to other apps through UDP/IP, which is how the IF data gets to SSDR to begin with. Why convert that to an OS audio device just to have it converted back to raw data. I believe FRS is resolving this problem. What I am doing will directly handle spotting, logging, and LOTW uploading. I don't mean, necessarily, one gigundo application. As part of this effort I will spawn off service endpoints, singularly focused services with a discrete internet address and requests will be made to it. It will be blindingly fast.
As far as what your friend said, yes, one can port a C or C++ program from Linux to Mac. There are other languages where no port is required. In the case of S(er)SDR the only difference between the versions, Linux and Mac, will effectively be the GUI itself will look more like Mac apps and not Window or Linux apps. But beneath the appearance will be identical code. This will be very exciting.
Your second paragraph is kind of wrong, well, depending on what you really meant. If you are strictly talking about Parallels or KVM or VMWare, it depends. KVM, of which I know the most actually, depending on the app, could run faster in a virtual machine. I am not doing a virtual machine implementation, these will be native apps and, absolutely, run faster than a virtualized Windows environment running SDR. There is a real world case where rather than buy every employee their own machine, they get a virtual version of what that machine would be running. It's called virtual desktop Infrastructure. That provides way better security and cost structures to companies. You've likely heard a lot about 'the cloud'. That is, essentially, what in a business environment you are talking about. There is about a 10:1 ratio between a host machine and the number of virtual machines it can support. When you talk about something just a degree or two away from that, 'containers' there is a 100:1 ratio. However, what I am doing won't require virtualization. It is a single app that will natively run on Linux and many other platforms, even Windows. Having said all that, the one can I have, to date, kicked down the road is DAX / virtual audio channels. At this moment I do not know how to create a virtual device in Linux. It's not an impossible task, just not one I taken on as yet. The other issue is DAX is used to logically connect HRD or CW Skimmer to SSDR. Where they are all Windows applications connecting to them from not Windows is problematic. However, the better design is to connect to other apps through UDP/IP, which is how the IF data gets to SSDR to begin with. Why convert that to an OS audio device just to have it converted back to raw data. I believe FRS is resolving this problem. What I am doing will directly handle spotting, logging, and LOTW uploading. I don't mean, necessarily, one gigundo application. As part of this effort I will spawn off service endpoints, singularly focused services with a discrete internet address and requests will be made to it. It will be blindingly fast.
As far as what your friend said, yes, one can port a C or C++ program from Linux to Mac. There are other languages where no port is required. In the case of S(er)SDR the only difference between the versions, Linux and Mac, will effectively be the GUI itself will look more like Mac apps and not Window or Linux apps. But beneath the appearance will be identical code. This will be very exciting.
WB5AGF: "...ever since we began to move away from the physical buttons-and-knobs front panel, the PC UIs have taken their cue, on how they should look, from the previous physical front panel interfacing radios .... until the FLEX-6000 radios."
There is actually a furious debate within the UI design community about this exact topic. Namely whether real-world shapes, textures, indicators and controls should be slavishly replicated in the computer UI. Those are called skeuomorphs, and the new approach is called "non-skeuomorphic design".
The Perseus UI and other discussed knob radio computer UIs are skeuomorphic. SmartSDR is a step toward non-skeuomorphism. I don't know if this was a formal intent by the designers but that was the result.
The older skeuomorphic approach often uses screen real estate for essentially decorative elements. These are disparagingly referred to as "chrome" by the non-skeuomorphs.
There are stronger and weaker forms of non-skeuomorphic design. A weaker form might be "let's not blindly replicate real-world UI elements if we can think of a better way". A strong form might be: "every real-world shape and texture must go, absolutely no color gradients, no drop shadows, no chrome of any kind." It is sometimes called the "flat look" UI. Microsoft and Apple are both moving their UIs in that direction.
There have been design excesses on both sides. Apple's old Mac calender which had a stitched leather binding, etc: http://www.fastcodesign.com/1670760/will-apples-tacky-software-design-philosophy-cause-a-revolt
OTOH the non-skeumorphs produced the flat, tiled Windows 8 UI. In their zeal to jettison all chrome, gradients and drop shadows, they have sometimes produced UIs which are non-intuitive, hard to read, and difficult to use.
I personally like the SmartSDR interface, even though it's not perfect. It feels uncluttered, clean and fresh, and puts the big panafall display front and center. If only they'd implement hotkey commands for common controls, you could operate it with all the controls minimized and off screen.
There is actually a furious debate within the UI design community about this exact topic. Namely whether real-world shapes, textures, indicators and controls should be slavishly replicated in the computer UI. Those are called skeuomorphs, and the new approach is called "non-skeuomorphic design".
The Perseus UI and other discussed knob radio computer UIs are skeuomorphic. SmartSDR is a step toward non-skeuomorphism. I don't know if this was a formal intent by the designers but that was the result.
The older skeuomorphic approach often uses screen real estate for essentially decorative elements. These are disparagingly referred to as "chrome" by the non-skeuomorphs.
There are stronger and weaker forms of non-skeuomorphic design. A weaker form might be "let's not blindly replicate real-world UI elements if we can think of a better way". A strong form might be: "every real-world shape and texture must go, absolutely no color gradients, no drop shadows, no chrome of any kind." It is sometimes called the "flat look" UI. Microsoft and Apple are both moving their UIs in that direction.
There have been design excesses on both sides. Apple's old Mac calender which had a stitched leather binding, etc: http://www.fastcodesign.com/1670760/will-apples-tacky-software-design-philosophy-cause-a-revolt
OTOH the non-skeumorphs produced the flat, tiled Windows 8 UI. In their zeal to jettison all chrome, gradients and drop shadows, they have sometimes produced UIs which are non-intuitive, hard to read, and difficult to use.
I personally like the SmartSDR interface, even though it's not perfect. It feels uncluttered, clean and fresh, and puts the big panafall display front and center. If only they'd implement hotkey commands for common controls, you could operate it with all the controls minimized and off screen.
(Edited)
I also like the SSDR interface on the whole. It is, however, riddled with minor inconsistencies and annoyances. Once 1.5 is out of the door, I would like to see the release after that to address the UI.
In that regard, that would be an outstanding move for FRS to undertake. Move away from the single monolithic fat client app. In other words, 1) have each pan be a child of the desktop not a child of the HWND_MAIN (app). Right now the main app is, for lack of a better word, using a border layout, there is are the buttons, BAND, DAX, etc on the left, the VBox on the right, menu across the top and whatever on the bottom. What takes up the most real estate is the pan in the center. If a user could move that off to another window the main app real estate reduces dramatically. 2) In the tabbed VBox on the right, using a small form like a laptop not all the dialog boxes are visible, in order to get to EQ I have to close several others. They should be scrollable. Or, ideally, let the user put the pan and the TX dialog in front of him and the others off line of sight.
KY6LA - Howard, Elmer
Anyone tried the CommCat control panel. Ali 9K2AW sent me a picture of him using it via iPhone Remote
Here is a screen shot from my iPad.
Here is an iPhone screen shot
Does not show the really cool spectrum display like parallels access but ergonomics for ipad, iPhone look good
Here is a screen shot from my iPad.
Here is an iPhone screen shot
Does not show the really cool spectrum display like parallels access but ergonomics for ipad, iPhone look good
(Edited)
Alex - DH2ID, Elmer
Steve - N5AC, VP Engineering / CTO
We actually had a lengthy discussion about skeuomorphism when we started work on the interface. Apple had started down this path several years ago as did many others, but the thinking in the industry (software/UI) was leaning away from these types of interfaces. Apple is a perfect example as they altered out most of the skeuomorphic elements of their applications as time moved forward. I think for Apple, most of these elements are gone.
I actually like skeuomorphic design, but one issue with it is that it tends to be a fashion-style thing. What looks good today will look tired tomorrow. Also the skeuomorphic elements I may like might remind you of something you really dislike. For example, I might make a Collins looking knob and lots of folks might like it, but someone with a Collins that didn't work well for them (ok bad example) might dislike the trip down memory lane. In the early SmartSDR days we talked about it on and off for a couple of weeks and decided to go with simple design elements with an emphasis on trying to provide an intuitive and clear interface.
I actually like skeuomorphic design, but one issue with it is that it tends to be a fashion-style thing. What looks good today will look tired tomorrow. Also the skeuomorphic elements I may like might remind you of something you really dislike. For example, I might make a Collins looking knob and lots of folks might like it, but someone with a Collins that didn't work well for them (ok bad example) might dislike the trip down memory lane. In the early SmartSDR days we talked about it on and off for a couple of weeks and decided to go with simple design elements with an emphasis on trying to provide an intuitive and clear interface.
Panadapter background is kind of skeuomorphism also.
I mean the lighter area in the center.
My first impression of it was and still is, tiring eye candy.
73, Timo OH5KW
I mean the lighter area in the center.
My first impression of it was and still is, tiring eye candy.
73, Timo OH5KW
Ah! Now I know what to do with my Hammond Organ now that I haven't played in a while.
Alex - DH2ID, Elmer
Steve, you can play my "Knob Loss Blues" on it, see above.
Notes/sound best taken from John Lee Hooker....
Notes/sound best taken from John Lee Hooker....
It's an interesting subject. I can say that Google and Oracle are not abandoning the 3D look and feel. No, they don't simulate wood grain or rich Corinthian leather but subtle raised buttons with recessed labels, Android's Material look. Background that are, rather than white or light blue have a subtle linen texture. Very subtle stuff, just not boring Windows API buttons boxes and labels, ala 1989.Isn't Microsoft's new Word doing an open book look and feel with 'pages' that can be 3d flipped and have real dogear page corners?
Steve - N5AC, VP Engineering / CTO
relevant ad courtesy TVLAND: https://www.youtube.com/watch?v=tfKHBB4vt4c
I thought I'd throw out that BFTP, to see who was paying attention. Thank you Steve!
Good discussion. A really interesting frontier is to shift toward activity-specific interfaces and away from mapping buttons to hardware features. With the APIs it's pretty easy to purpose-build interfaces for contesting, DXing, digital or whatever you like. You can interact with them on a computer or tablet screen or on 3rd-party control surfaces.
Simple example: why would a contest interface offer you a WARC band - or a band you don't have an antenna for? Better example: a pan showing an entire band with a fast tune knob and a second gang-tuned pan showing +/- 10 or 20 khz centered around a cursor with a slow tune knob. This is about an hour of coding in the FlexLib API once you've built the frameworks.
I'm excited with what we'll see in the next 12 months,
Simple example: why would a contest interface offer you a WARC band - or a band you don't have an antenna for? Better example: a pan showing an entire band with a fast tune knob and a second gang-tuned pan showing +/- 10 or 20 khz centered around a cursor with a slow tune knob. This is about an hour of coding in the FlexLib API once you've built the frameworks.
I'm excited with what we'll see in the next 12 months,
Asher;
I've been wondering if it's feasible to put a UI together that would provide graphic appearances of all commonly accessed radio controls and that, as part of the configuration process, you then selected how many of those appearances you wanted and where they went on the UI screen ?
I can't remember which one but back about 20 years ago there was a very high-end ham radio transceiver that had so many controls on the front panel that, the one time I got to use one, I had trouble finding the receiver volume control.
Many years before that there were some ham transmitters (the Hammarlund HX-Fifty and the Central Electronics 100V & 200V) that had little swing-open doors on the front panel that covered controls that were mostly set-and-forget.
I like the idea of being able to put the set-and-forget controls out-of-the-way so that the remaining screen real estate can be used for the controls that get constantly adjusted.
- Paul, WB5AGF
I've been wondering if it's feasible to put a UI together that would provide graphic appearances of all commonly accessed radio controls and that, as part of the configuration process, you then selected how many of those appearances you wanted and where they went on the UI screen ?
I can't remember which one but back about 20 years ago there was a very high-end ham radio transceiver that had so many controls on the front panel that, the one time I got to use one, I had trouble finding the receiver volume control.
Many years before that there were some ham transmitters (the Hammarlund HX-Fifty and the Central Electronics 100V & 200V) that had little swing-open doors on the front panel that covered controls that were mostly set-and-forget.
I like the idea of being able to put the set-and-forget controls out-of-the-way so that the remaining screen real estate can be used for the controls that get constantly adjusted.
- Paul, WB5AGF
Robert -- N5IKD, Elmer
One thing I've learned over the last two years is this forum is filled with people unable to be happy. They aren't happy with the company.
They aren't happy with the software.
They aren't happy with the software update cycle.
They aren't happy with not knowing what the company employees are working on.
They aren't happy with not knowing when software will be released.
They aren't happy not knowing their pet wish, right behind that pony, may or may not be coming.
They aren't happy knowing their pet wish, right behind the pony won't be coming.
They aren't happy knowing their pet wish, right behind the pony will be coming.
They aren't happy with the software appearance.
They aren't happy with the software behavior.
Maybe what it all comes down to is this forum is full of people unhappy with themselves, therefore, they can't be happy with anything else.
In no way does FRS own any part of that problem.
They aren't happy with the software.
They aren't happy with the software update cycle.
They aren't happy with not knowing what the company employees are working on.
They aren't happy with not knowing when software will be released.
They aren't happy not knowing their pet wish, right behind that pony, may or may not be coming.
They aren't happy knowing their pet wish, right behind the pony won't be coming.
They aren't happy knowing their pet wish, right behind the pony will be coming.
They aren't happy with the software appearance.
They aren't happy with the software behavior.
Maybe what it all comes down to is this forum is full of people unhappy with themselves, therefore, they can't be happy with anything else.
In no way does FRS own any part of that problem.
(Edited)
Alex - DH2ID, Elmer
Walt, I agree with you, and as I'm VERY happy with my Flex-6500
(and I am still happy with my Flex-3000) I wrote a (sarcastic) song
about having no knobs no more (see above) hi...
(and I am still happy with my Flex-3000) I wrote a (sarcastic) song
about having no knobs no more (see above) hi...
(Edited)
Lee, Elmer
DDUTIL already supports a user programmable physical interface, actually 2 of them. One is the FlexControl and one is the Genovation keypad. The FlexControl allows control of several slider funcions as well as up to 12 push button macros. The Genovation keypad allows up to 48 individually programmable buttons which execute specific macro functions. The macro functions are stackable and can be very complex. Many macro functions can also control slider values. The can also be toggled. When I push NB, the NB turns on and it sets the slider to the value I use most for my specific noise situation, and it does it for both slices. The command looks like this:
DD6NBK0:1;DD6NBK1:1;DD6NBG0:080;DD6NBG1:080;
It turns on NB0 and NB1 and sets both sliders to 80. One button press. I have this on a toggle so If I press the button again NB shuts off
Tune is like this
Tune on DD6TXL0:0;DD6TXT1;
Tune off DD6TXT0;DD6TXL0:1;ZZXS0;
Tune on: turns off TX key line and turns on tune at whatever power is set on the front panel
Tune off: turns off tune and then resets the key line. This way I can tune my automatic antenna tuner with one button press through the amp and my tuner never see high power and I never have to switch off my amp to tune
I have another button XIT+2 that turns on the XIT and sets it to +2khz
ZZXS1;ZZXG+02000;
another button press clears and cancels XIT
ZZXS0;
You also see ZZXSO; in tune off. So if I'm going to tune up on a QSO and its clear above I first hit XIT+2 and then tune on and tune 2 khz up the band. When I hit tune off the ZZXSO; command also cancels XIT. I have some very complex macros that do many things to configure the radio exactly how I like it for given situations all with one button press. For example you can make the entire sequence to go from SSB to AFSK entirely automatic including setting and centering RTTY filters, one button.
Another advantage of this is the keypad is always in focus, which neans I can be looking at a browser and hit the NB button and NB snaps to attention without changing focus. I have macros for record on/off playback on/off I can set the pan in both slices one to the left eat the other to the right exactly as I like it, one button press.
If you don't have a Genovation but you do have a FlexControl you can create up to 9 of these custom macros for your enjoyment and the FlexContol is also independent of focus, but you have to attach your FlexControl to DDUTIL and shut off FlexControl in SSDR to get that to work.
So here is another user interface available today that is very powerful. Much of what you do with a slider is actually a set value so using a macro to set the slider is often more than adequate. It also showcases the incredible power that Flex has given us for customization of our radio thrugh the API. Steve K5FR has spent mucho time bringing much of the API functionality to those of us who can't or do not have enough experience to roll your own
73 W9OY
DD6NBK0:1;DD6NBK1:1;DD6NBG0:080;DD6NBG1:080;
It turns on NB0 and NB1 and sets both sliders to 80. One button press. I have this on a toggle so If I press the button again NB shuts off
Tune is like this
Tune on DD6TXL0:0;DD6TXT1;
Tune off DD6TXT0;DD6TXL0:1;ZZXS0;
Tune on: turns off TX key line and turns on tune at whatever power is set on the front panel
Tune off: turns off tune and then resets the key line. This way I can tune my automatic antenna tuner with one button press through the amp and my tuner never see high power and I never have to switch off my amp to tune
I have another button XIT+2 that turns on the XIT and sets it to +2khz
ZZXS1;ZZXG+02000;
another button press clears and cancels XIT
ZZXS0;
You also see ZZXSO; in tune off. So if I'm going to tune up on a QSO and its clear above I first hit XIT+2 and then tune on and tune 2 khz up the band. When I hit tune off the ZZXSO; command also cancels XIT. I have some very complex macros that do many things to configure the radio exactly how I like it for given situations all with one button press. For example you can make the entire sequence to go from SSB to AFSK entirely automatic including setting and centering RTTY filters, one button.
Another advantage of this is the keypad is always in focus, which neans I can be looking at a browser and hit the NB button and NB snaps to attention without changing focus. I have macros for record on/off playback on/off I can set the pan in both slices one to the left eat the other to the right exactly as I like it, one button press.
If you don't have a Genovation but you do have a FlexControl you can create up to 9 of these custom macros for your enjoyment and the FlexContol is also independent of focus, but you have to attach your FlexControl to DDUTIL and shut off FlexControl in SSDR to get that to work.
So here is another user interface available today that is very powerful. Much of what you do with a slider is actually a set value so using a macro to set the slider is often more than adequate. It also showcases the incredible power that Flex has given us for customization of our radio thrugh the API. Steve K5FR has spent mucho time bringing much of the API functionality to those of us who can't or do not have enough experience to roll your own
73 W9OY
(Edited)
I did not know that Lee, good info, thanks!
Excellent Lee, I'm going to switch the Flexcontrol back to DDUtil and try your method. I might even use the FlexControl more, I might use it better.
Lee, Elmer
Paul, WB5AGF
Jim;
In my mind's-eye I was 'seeing' the Perseus's UI - I've recently been looking at how several radio UIs have been implemented.
- Paul, WB5AGF
Carl Moreschi