Call Search
     

New to Ham Radio?
My Profile

Community
Articles
Forums
News
Reviews
Friends Remembered
Strays
Survey Question

Operating
Contesting
DX Cluster Spots
Propagation

Resources
Calendar
Classifieds
Ham Exams
Ham Links
List Archives
News Articles
Product Reviews
QSL Managers

Site Info
eHam Help (FAQ)
Support the site
The eHam Team
Advertising Info
Vision Statement
About eHam.net

   Home   Help Search  
Pages: Prev 1 2 [3] 4 5 6 Next   Go Down
  Print  
Author Topic: SDR Knobs and Buttons in the future  (Read 88929 times)
W6RMK
Member

Posts: 649




Ignore
« Reply #30 on: August 18, 2013, 12:43:23 PM »

the PC that controls the radio is part of the radio,

Exactly correct. Window Computers were never designed or meant for real time applications like Hamradio. Which of course is one the reasons Flexradios and other SDR's will never be mainstream hamradios.

Stan K9IUQ

PCs are very good at "real time" data stream processing, as long as you are matching your hardware specs with the needs of the software you are using.  My home desktop computer could process a full SDR stream, play a high end 3D video game, and capture live video from a video camera all at the same time, without even breathing hard.  Granted, I built my machine to be a monster, but the reality today is that our computer hardware largely exceeds the demands of today's software.  Especially with quad and hex core processors, cheap memory, and fast hard drives.


There's quite a bit more to it than just having fast hardware.  Your software architecture AND the connected hardware needs to be appropriate for the OS. Windows does provide fairly good near real time multimedia support.  However, there's a substantial learning curve on making it play right, and to date, very little ham generated software has made the necessary investment.  Instead, they tend to take wrappers and libraries which *almost* get there and "leave the rest as an exercise for the reader" in good open source tradition. 

It's an expensive proposition to write high quality real time device drivers and the supporting software for Windows (as in multiple work-years of effort).  If you're selling millions of dollars worth of "Call of Duty" or "Skyrim", you can afford to work through all this stuff (and even those guys don't do a perfect job.. there's plenty of bugs in those too).  It is not likely that you're going to get good open-source/free (as in beer) code for Windows to do this stuff, for a variety of reasons, so we wind up with strange hybrids (PowerSDR is an example of such a hybrid) that blend code from a variety of sources and target platforms (dttsp, the DSP core of PowerSDR, was written for *nix type platforms, for instance).


Unfortunately, another aspect which requires substantial sophistication is that the typical "interaction" model with the software for a ham radio doesn't map well into the conventional desktop metaphor, with modal dialogs, focus, etc.  That is, Windows is really designed to have "input" going to one process/window at a time (e.g. you're either typing into a Word document, or an Excel spreadsheet, or another document, but not into all documents at the same time).  You can have multiple output streams fairly well (e.g. play video in one window, look at the output of Word in another, see notices in Outlook or Communicator)

So this raises a problem with designing a radio UI where you want, say, to have a pan display that you can click on, and  a tuning knob (virtual or real), and various other "knobs" (bandwidth, clarifier, volume, etc.).  You can put it all in one window (so that window always has the focus), but that gets awfully cluttered.  And besides, anything that pops up (that text message /IM from someone else, the DX spot message, what have you) tends to pull the focus (unless both applications somehow cooperate).  Digital modes are even trickier.. you have the focus in your text entry/display screen, but you also need to be manipulating the tuning frequency of the radio at the same time.  A lot of programs sort of get around this by implementing "pass through" schemes (e.g. your digimode program can send tuning commands to the radio via CAT or similar)

However, I wouldn't agree with IUQ that ham SDR won't ever be good on a PC.  PC user models are evolving.  There are more and more people who understand how to write good real-time code on Windows, and Windows itself is getting smoother.  Especially if we get rid of the insistence on legacy compatibility that will help.  "I want it to run on my old Win 3.1 machine!"

That said, the near term future for SDRs that use PCs is to have the PC embedded in the radio. Then, the PC can be dedicated to the needed functions, just as embedded PCs are used in oscilloscopes, spectrum analyzers, etc. PC mobos are cheap (<$100) compared to the cost of a fancy ADC/DACs or FPGAs.
Logged
K9IUQ
Member

Posts: 1626




Ignore
« Reply #31 on: August 18, 2013, 01:04:55 PM »

 Surely they have been tested with CW.

The end user tests Beta Software for Flexradio. Which is one reason there are so many unhappy and EX-customers.

Flexradio stopped calling their software Beta. Now they use that much better description of "Preview Edition" for the 6000 series. Unless you agree to use Preview Edition software they will not sell you a radio at this time.

I bought my Flex 5K in 2010, almost 3 years after it's introduction. PSDR still was not polished software with basic Features such as a notch filter or FM mode or FSK mode completely missing.

They are doing the same method of operation again. Somewhere on this forum I recently posted a list of the Bugs/Limitations of SmartSdr software. The list was long and I did not list all the Bugs. Flex announced SmartSdr and the 6000 series in May 2012. They took down payments of $1-2K from early adopters. A year and a half of effort later and the software does not have a basic Panafall....

Stan K9IUQ

 
Logged
KK6GNP
Member

Posts: 158




Ignore
« Reply #32 on: August 18, 2013, 01:08:33 PM »

the PC that controls the radio is part of the radio,

Exactly correct. Window Computers were never designed or meant for real time applications like Hamradio. Which of course is one the reasons Flexradios and other SDR's will never be mainstream hamradios.

Stan K9IUQ

PCs are very good at "real time" data stream processing, as long as you are matching your hardware specs with the needs of the software you are using.  My home desktop computer could process a full SDR stream, play a high end 3D video game, and capture live video from a video camera all at the same time, without even breathing hard.  Granted, I built my machine to be a monster, but the reality today is that our computer hardware largely exceeds the demands of today's software.  Especially with quad and hex core processors, cheap memory, and fast hard drives.


There's quite a bit more to it than just having fast hardware.  Your software architecture AND the connected hardware needs to be appropriate for the OS. Windows does provide fairly good near real time multimedia support.  However, there's a substantial learning curve on making it play right, and to date, very little ham generated software has made the necessary investment.  Instead, they tend to take wrappers and libraries which *almost* get there and "leave the rest as an exercise for the reader" in good open source tradition.  

It's an expensive proposition to write high quality real time device drivers and the supporting software for Windows (as in multiple work-years of effort).  If you're selling millions of dollars worth of "Call of Duty" or "Skyrim", you can afford to work through all this stuff (and even those guys don't do a perfect job.. there's plenty of bugs in those too).  It is not likely that you're going to get good open-source/free (as in beer) code for Windows to do this stuff, for a variety of reasons, so we wind up with strange hybrids (PowerSDR is an example of such a hybrid) that blend code from a variety of sources and target platforms (dttsp, the DSP core of PowerSDR, was written for *nix type platforms, for instance).


Unfortunately, another aspect which requires substantial sophistication is that the typical "interaction" model with the software for a ham radio doesn't map well into the conventional desktop metaphor, with modal dialogs, focus, etc.  That is, Windows is really designed to have "input" going to one process/window at a time (e.g. you're either typing into a Word document, or an Excel spreadsheet, or another document, but not into all documents at the same time).  You can have multiple output streams fairly well (e.g. play video in one window, look at the output of Word in another, see notices in Outlook or Communicator)

So this raises a problem with designing a radio UI where you want, say, to have a pan display that you can click on, and  a tuning knob (virtual or real), and various other "knobs" (bandwidth, clarifier, volume, etc.).  You can put it all in one window (so that window always has the focus), but that gets awfully cluttered.  And besides, anything that pops up (that text message /IM from someone else, the DX spot message, what have you) tends to pull the focus (unless both applications somehow cooperate).  Digital modes are even trickier.. you have the focus in your text entry/display screen, but you also need to be manipulating the tuning frequency of the radio at the same time.  A lot of programs sort of get around this by implementing "pass through" schemes (e.g. your digimode program can send tuning commands to the radio via CAT or similar)

However, I wouldn't agree with IUQ that ham SDR won't ever be good on a PC.  PC user models are evolving.  There are more and more people who understand how to write good real-time code on Windows, and Windows itself is getting smoother.  Especially if we get rid of the insistence on legacy compatibility that will help.  "I want it to run on my old Win 3.1 machine!"

That said, the near term future for SDRs that use PCs is to have the PC embedded in the radio. Then, the PC can be dedicated to the needed functions, just as embedded PCs are used in oscilloscopes, spectrum analyzers, etc. PC mobos are cheap (<$100) compared to the cost of a fancy ADC/DACs or FPGAs.

I agree with this in general.  My guess is that the problems with CW have more to do with the limits of the Flex, either in the software and/or hardware.  You covered my main point, which was to say that the problems people are experiencing with latency on SDRs isn't due to some inherent problem with PCs, or their operating systems.

I'm not against the idea of having the radio do all of the heavy processing + thin client capability either, though I would wonder if this would possibly limit future development of new experimental features in radio.  My main interest in SDR is having the larger screens and the potential for custom controllers, not to mention homebrew and experimental software development for radio.

It would be interesting to have some coders who write digital instrument and DSP-plugin software for music production take a look at SDR latency and comment on it. These problems (or similar ones) may have already been solved, complete with open source code projects to learn from.
« Last Edit: August 18, 2013, 01:10:40 PM by JEEPESCAPE » Logged

73 ~ Cory (JeepEscape)
KK6GNP
KK6GNP
Member

Posts: 158




Ignore
« Reply #33 on: August 18, 2013, 01:15:37 PM »

 Surely they have been tested with CW.

The end user tests Beta Software for Flexradio. Which is one reason there are so many unhappy and EX-customers.

Flexradio stopped calling their software Beta. Now they use that much better description of "Preview Edition" for the 6000 series. Unless you agree to use Preview Edition software they will not sell you a radio at this time.

I bought my Flex 5K in 2010, almost 3 years after it's introduction. PSDR still was not polished software with basic Features such as a notch filter or FM mode or FSK mode completely missing.

They are doing the same method of operation again. Somewhere on this forum I recently posted a list of the Bugs/Limitations of SmartSdr software. The list was long and I did not list all the Bugs. Flex announced SmartSdr and the 6000 series in May 2012. They took down payments of $1-2K from early adopters. A year and a half of effort later and the software does not have a basic Panafall....

Stan K9IUQ


I hear you on this one, Stan.  This has become a common practice in some markets with PC software.  One definitely needs to weigh the pros and cons when purchasing a product from a company with  only beta/preview software available.  I'd like to say that we can bet they will sort all of this out in time, but I don't know them that well, and in my professional life, I deal with software that is in a constant state of beta all the time.  Some of these programs cost multiple tens of thousands of dollars too, but they get away with it because they are the only game in town for a niche market.
Logged

73 ~ Cory (JeepEscape)
KK6GNP
SWL2002
Member

Posts: 227




Ignore
« Reply #34 on: August 18, 2013, 01:38:28 PM »

Flex's PowerSDR has given SDR a bad name on Windows PCs.  You can write the SDR software to work properly on Windows, but Flex has been unable to do so.  It should be no surprise that the software for the Flex 6000 series is so bad and far behind.  Flex has never been strong in the software programming arena.  Unfortunately, most guys are familiar with only PowerSDR and have not experienced correctly written SDR software on Windows.  Flex and PowerSDR has set a BAD example and it colors most Hams views about SDR at this point.
Logged
W4HIJ
Member

Posts: 367




Ignore
« Reply #35 on: September 06, 2013, 02:49:46 PM »

I actually enjoy operating my SDR with the mouse and keyboard.  I would not take an add on VFO knob type control if it was given to me. I will never ever go back to a traditional knob radio or if I did, I'd use some type of PC control software like HDR to avoid having to tune with a VFO knob. Just because some folks don't have the intelligence and coordination  to operate multiple programs and the SDR program from the PC all at the same time does not mean that everyone suffers from the problem. I typically operate with PowerSDR, logging and digital programs all going at the same time and now that I've gotten used to it, I never have issues with window "focus" or anything else.
73,
Michael, W4HIJ
Logged
W6RMK
Member

Posts: 649




Ignore
« Reply #36 on: September 08, 2013, 06:07:46 PM »

I don't think it's a matter of user skill, familiarity, etc.

It's more a matter of multiple simultaneous processes going on that need to interact (e.g. a digimode program, the radio, and perhaps others).  Frankly, NO consumer operating system's user interface works very well with this; which is why in such situations, one tends to fall back to using multiple computers or writing custom software as a UI front end so all the user interaction is managed consistently.

"windowing" user interfaces (Mac, Windows, Gnome, KDE, X11.. all the same) all have this issue with "to which process does that keystroke, mouse click, etc go", and the choices tend to be biased towards a "desktop/document" model: if you have sheets of paper on your (physical) table top, and a pencil, the input goes to the one which the pencil is touching.   But most computer GUIs do this as a two step process: select which window to send input to (e.g. giving it the focus), then send the input to the process attached to that window.  Where it gets real ugly is when an underlying process wants attention, and its user interaction space/window is hidden.  (viz, the bouncing icon on the Mac dock).  You can either automatically direct the focus to the process requesting input, or notify the user, and let them decide.  With Windows, you can do either, and there's no real consistency among applications.

Indeed, tuning with a mouse is convenient, although I find that if you need to "set a value exactly" a manual knob with "clicks" or typing the number is easier. And it's not like knob interfaces are all that wonderful either (e.g. HP/Agilent must have had 5 or 6 different ways of changing the step size for the knob on the front panel of instruments over the last 20 years).  There's also a whole thing in UI design about moving from one modality to another.  For instance, it's usually faster for a user to do a series of mouse clicks than it is to mouse, then keyboard, then go back to the mouse; and vice versa.

getting it "right" in the sense of being facile for the greatest number of users is non-trivial and expensive.
Logged
K5TED
Member

Posts: 699




Ignore
« Reply #37 on: September 08, 2013, 08:49:47 PM »

PowerSDR is easy to use. Digi modes with FLDigi or PowerSDR is a simple matter.

1. When using digi modes such as PSK, MFSK, etc., one generally does not need to fiddle much with the radio controls, since most digi operation occurs within predefined slots. Once you've clicked on the slot, set your drive and output power, there's really no need to go back to the radio console other than to adjust speaker volume. Logging programs run easily side by side with the digi program, and in some cases, such as DM-780/MiniDeluxe/PSDR, are completely integrated. Most everything you need runs from the DM-780 screen.

2. Did I mention that PowerSDR is very easy to use?

3. Proper radio/PC configuration is up to the user, not the manufacturer. Failure to dedicate a proper PC system to the radio may leave the user baffled and disgruntled. While sometimes unintended or unanticipated, this is all self inflicted pain.

4. PowerSDR is really, seriously, easy to use. It works really well with other programs.

5. Expert Electronics... Bring on the knobbed SDR!

6. It has been well documented that some CW users do not enjoy the CW options available for use with the second gen Flex radios. It is well documented and therefore, complaining about it is a bit pointless, since it has been well documented for some time. Some CW users do well with the radio. Some drivers do well with the Ford Fiesta. I do not, for reasons that are well documented by car review mags.

Logged
W6RMK
Member

Posts: 649




Ignore
« Reply #38 on: September 09, 2013, 10:08:26 AM »


3. Proper radio/PC configuration is up to the user, not the manufacturer. Failure to dedicate a proper PC system to the radio may leave the user baffled and disgruntled. While sometimes unintended or unanticipated, this is all self inflicted pain.


This is true for experimenter, developer environments.  It is decidedly not true for most end user environments. 

I would venture that the single biggest complaint, comment, feedback from users of PC software of any type is the complexity of installation and configuration in a multi application environment. Even more so after applications have been removed, updated, etc over some period of time.  There's a reason the term DLL hell exists.

Users are not sys admins, nor should they require the skills of one.

Dedicating a PC per application is a viable strategy in some environments, and is how I see the SDR evolving. Embed the thing and don't try to make one machine do multiple things, then there is less chance for incompatibility, resource contention, etc.  The software developer can then focus on designing and producing good interfaces between boxes, because just like good fences, they make for good neighbors.
Logged
M0HCN
Member

Posts: 473




Ignore
« Reply #39 on: September 09, 2013, 11:16:50 AM »

I have written both hard RT safety critical code and music signal processing code, and neither are easy....

My suspicion is that a big part of the CW issues come down to sending the key status to the PC at far too low a rate, consider if a packet contains say 128 I/Q samples, but only a couple of bits for key state, then the keyer code has no way to know when the key was actually pressed, and thus no way to ensure that the delay between the key and the sidetone is constant rather then variable.

If the key data was sent as a side channel running at the same rate as the samples, then the keyer code could contrive to introduce a constant delay between contact and sidetone which I suspect would work better (This is how most soft synths work with MIDI, you set the hardware up to timestamp the midi messages with a clock derived from the soundcard and you don't respond to the note as soon as you can (Which is variable) you respond after a fixed time interval that you can always meet reliably).

There is a very similar issue with MIDI instruments, in that a few ms of latency is not a major problem (Sound after all only travels at ~1ft/ms), but latency jitter of the same order can make it completely unplayable.

The real answer for CW is to move the keyer into a tiny little bit of VHDL running at Mhz rates on the radios gate array, and to have the gate array use an NCO to produce the sidetone and RF envelope, that way you are assured of deterministic behavior with timing jitter measured in the sub microsecond region. 

General purpose computers really are actually NOT very good at short deadline soft realtime, they like to process data in largeish blocks rather then doing the work in interrupt context (Which something like a TMS320C6 can easily handle), so you cannot really do sample by sample processing, instead being forced into working with blocks of several hundred samples. If you try to make a general purpose machine run with short buffers and correspondingly very high interrupt rates what tends to happen is that throughput goes way down and there is a threshold below which you start to miss deadlines due to the OS having its own ideas about priorities.

Can it be done better on a general purpose box, sure it can, but if designing a radio it is easier to stick a couple of modest dsp or even arm parts in there and use something like FreeRtos rather then Windows, offload the FFT to some VHDL and it does not take a huge amount of processor power.

Software development is inherently expensive and difficult, and for a product expected to sell in the thousands rather then the millions it may well be that the $20 BOM cost of putting a dedicated processor core on the board is worthwhile, then you have the interesting possibilities of things like the Cyclone V some of which have on board hardwired arm cores.

73, Dan.
Logged
W4HIJ
Member

Posts: 367




Ignore
« Reply #40 on: September 09, 2013, 04:23:22 PM »


3. Proper radio/PC configuration is up to the user, not the manufacturer. Failure to dedicate a proper PC system to the radio may leave the user baffled and disgruntled. While sometimes unintended or unanticipated, this is all self inflicted pain.


This is true for experimenter, developer environments.  It is decidedly not true for most end user environments. 

I would venture that the single biggest complaint, comment, feedback from users of PC software of any type is the complexity of installation and configuration in a multi application environment. Even more so after applications have been removed, updated, etc over some period of time.  There's a reason the term DLL hell exists.

Users are not sys admins, nor should they require the skills of one.


I will say again, as I've said many times before, if you don't know your way around a PC environment pretty dang well then you have no business buying an SDR in the first place.  Like it or not, they are not usually "plug and play" and I don't really think people should expect them to be at this point in time. They may never be although I think maybe the Flex 6000 series will be, given time for the software to mature. If someone wants to be able to hook 12v and coax, a mic and a key and start yakking away to their buddies about their latest operation then they need to stick with the plain old tired and boring knob radio designs that have been available for years. Myself, I enjoy the work and thinking involved in configuring a properly functioning SDR station.
73,
Michael, W4HIJ
Logged
AK7V
Member

Posts: 249




Ignore
« Reply #41 on: September 09, 2013, 04:45:09 PM »

I think software is a very young engineering discipline, easily accessible, and not as refined as - for example - electrical engineering or mechanical engineering.  Lots of software is tragically buggy and unreliable.  Not as much discipline taken in its creation (perhaps because there aren't material costs, manufacturing costs/effort, etc. to deal with).  And anyone can do it -- I was writing programs in grade school (but not ones that anyone should rely on!).

I like that my radios aren't going to blue screen or freeze or crash or stutter or conflict.
Logged
K5TED
Member

Posts: 699




Ignore
« Reply #42 on: September 09, 2013, 04:59:29 PM »

" if you don't know your way around a PC environment pretty dang well then you have no business buying an SDR in the first place. "

Similar comments were likely made back in the early days of amateur radio, when there were no "off-the-shelf" transceivers.

A second generation consumer grade SDR is a breeze to implement and operate with a very few exceptions. One only needs to read the requirements and follow the instructions, and understand that the PC is an integral part of the radio, and treat it as such. It is the knobs. You wouldn't try to chip ice with the front panel of a FTDX5000, so why would you expect to get email on your SDR?




Logged
M1BJR
Member

Posts: 13




Ignore
« Reply #43 on: September 11, 2013, 05:07:23 PM »

I think software is a very young engineering discipline, easily accessible, and not as refined as - for example - electrical engineering or mechanical engineering.  Lots of software is tragically buggy and unreliable.  Not as much discipline taken in its creation (perhaps because there aren't material costs, manufacturing costs/effort, etc. to deal with).  And anyone can do it -- I was writing programs in grade school (but not ones that anyone should rely on!).

Excellent point, well made.

But there have been an equal number of badly designed 'off the shelf' analogue parts with well resourced corporations behind them.

Same issues but in a different package.... the difference with software is you can fix it without even opening the box.

Steve.
Logged
W6RMK
Member

Posts: 649




Ignore
« Reply #44 on: September 13, 2013, 06:04:38 AM »

Same issues but in a different package.... the difference with software is you can fix it without even opening the box.

Assuming the box has the underlying capabilities needed.  This might be the case with using consumer PCs and their OSes (Win, Linux, Mac)  as a platform: getting desired performance may not be possible in that framework without changing/adding hardware (e.g. the hardware keyer/DDS mentioned above).

 This is a huge issue in the professional SDR world: historically, one bought a radio which would perform certain functions, and it either did or it didn't.  With SDRs, you have the problem of specifying and buying a hardware platform to meet some speculative needs of some future software which has not been written yet.

Flex and VB+Windows is a fine example. The very first VB software + extremely simple hardware (IQ demod/mod from soundcard) did what it was expected to do (basically SSB on a 1 Watt radio), but didn't do a lot of other things it was desired to do.  PowerSDR was the next attempt, while staying within the same PC+windows+simple RF hardware platform, and is very successful at some things, not so successful at others, especially where hard realtime issues come into play (missing a buffer on output leads to CW tone coming out of radio on Tx; variable latency means using RF for CW sidetone is impractical);  A change in the HW platform (MIDI for keying information) helped a bit, but the Windows environment is very tough to do hard real time in (and Linux or Mac OS are really no better).

I think it is *possible* to do SDR on a PC platform with a consumer operating system, but it's going to be very expensive.  And it''s so easy today to move some of the functionality off the PC and into something else, that's the logical step.  Big FPGAs are pretty expensive still, so the USRP model may not be optimum (although, a low end USRP isn't a whole lot more expensive than the original Flex 3 board set); but it's certainly heading in the right direction. 

SDR tinkering on the part of hams has also moved away from where there's a significant fraction of the buyers interested in writing/modifying the DSP code.  The beauty (in my mind) of the original SDR1K and VB was that it was incredibly inexpensive for someone to "get their feet wet". The codebase was small and limited and could be understood in a day. A similarly simple software backend to one of the $20 USB pods would be the same; but can't transmit easily. 

Today, though SDR is perceived as "super duper multi function transceiver" competing with the big iron from the Japanese mfrs. And to get there requires an enormous amount of software, and hardware help to solve the real time problem.

But for the original "hack the DSP code" market, the actual platform is almost unimportant.  Writing BASIC or C code is easier than VHDL or Verilog, but in all cases, there are cheap parts and free software tools to work with.
Logged
Pages: Prev 1 2 [3] 4 5 6 Next   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!