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

donate to eham
   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 117338 times)
SWL2002
Member

Posts: 895




Ignore
« Reply #30 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: 402




Ignore
« Reply #31 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: 680




Ignore
« Reply #32 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: 1223




Ignore
« Reply #33 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: 680




Ignore
« Reply #34 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: 497




Ignore
« Reply #35 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: 402




Ignore
« Reply #36 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: 264




Ignore
« Reply #37 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: 1223




Ignore
« Reply #38 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 #39 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: 680




Ignore
« Reply #40 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
K9IUQ
Member

Posts: 2630




Ignore
« Reply #41 on: September 13, 2013, 06:28:53 AM »


 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); 

 the Windows environment is very tough to do hard real time in (and Linux or Mac OS are really no better).

And to get there requires an enormous amount of software, and hardware help to solve the real time problem.

I made the same point you just did concerning RTOS. I was told Real Time is a piece of cake on PC's or Macs. These comments are earlier in this thread.

Now we can not have it both ways. Someone here is wrong....

Stan K9IUQ
Logged
M0HCN
Member

Posts: 497




Ignore
« Reply #42 on: September 13, 2013, 09:40:48 AM »

Realtime has an interesting definition in the software game, it does not (necessarily) mean fast, it means there is a deadline and it WILL be met, no matter what.

A classical example of a realtime system is payroll processing, that money HAS to move on the specified day or really bad things happen to a lot of people. The deadline is once a month, so this is not fast, but it is immovable.

Now for our purposes we are looking at short deadline hard realtime, which even more then the other sort is not trivial, if we want to keep the latency in the say 10ms range, and it takes 1ms to get the data to and from the modulator, and our DSP takes say 5ms to do whatever it does to a block of data, then any delay in executing the dsp thread greater then 4ms will result in a missed deadline, and all sorts of things can cause delays.

Higher priority interrupts (SMM Mode springs to mind), lock contention (Another thread has a lock on some required resource), memory exhaustion (This is why one should NEVER allocate or free memory from a RT thread, it can always block), cache lines pingponging between cores, even the memory subsystem can throttle a pc in response to temperature, and for a worst case analysis you have to add up all the possible delay causes and ensure that the total comes in below the limit required time to meet the deadline.

Typically most general purpose operating systems have an average latency in the sub ms region, but with large spikes caused by things like contended locks in task management structures and interactions between the memory and IO subsytems, a hard RTOS guarantees that these spikes will never exceed a defined length, no commodity os makes ANY guarantee about the maximum scheduling latency.

Further, latency and throughput are goals that tend to work in opposition, low latency systems tend to not be particularly high throughput, so folks optimizing for a compute heavy load will trade poor scheduling latency for more throughput every time.

Doing reliable realtime at latency in the single digit realm on a commodity PC is tough, to the point that the guys doing serious audio and video editing get **very** picky about what hardware they will buy for the purpose. Even things like video cards can sometimes be shockingly badly behaved, locking the bus for entire milliseconds to get a few extra frames per second on the 'benchmark' in some random gamer magazine.

Now all that said, reasonable reliability as opposed to hard realtime is much easier, at least if you are a hacker and not above getting your hands dirty, but even this in the ms latency region can cause severe bouts of headscratching when you move the work to a new pc, selling and supporting such products is a bit if a nightmare.

Making SDR economic at the cheap HF set level needs the tech to become sufficiently mature for someone to be willing to commit to an ASIC rather then doing the work in a commodity FPGA, and at that point there is a question about just how 'software defined' the set really is, it becomes more of a 'digital radio' then a software defined one.
Eventually someone will pull the trigger on this, but not until they figure they have a product with at least a 5 year market life at a few thousand units a year, and the technology is still moving too fast for that to be the case.


73 Dan.
Logged
KF6QEX
Member

Posts: 643




Ignore
« Reply #43 on: September 15, 2013, 03:15:58 PM »

Quote
I made the same point you just did concerning RTOS. I was told Real Time is a piece of cake on PC's or Macs. These comments are earlier in this thread.

Now we can not have it both ways. Someone here is wrong....

It is,depending on your definition or "real time" what kind of cake and the size of the piece of cake.
"pretty fast" and "almost instantly" "barely noticable" and "negligible delay" don't count as "real time".
THe easiest test to perform is this: I stumbled on it accidentally when each kid turned on the TVs really loud so I could hear both "at the same time".
Two different model satellite TV receivers tuned to the same tv program, create an echo when you listen. One of the two lags behind just enough to create the echo effect.
I expect with a "conventional radio and a SDR tuned to the same station side by side, the SDR will have a noticable delay varying depending on the model/type of SDR.
I also know that any number of "conventional" radios tuned to the same station have no audible delay
As for music production, USB microphones for example, include a 3.5mm jack for  monitoring  in "real time" before the signal enters the digital chain.
ie: http://www.musiciansfriend.com/pro-audio/rode-microphones-podcaster-usb-microphone has one and this one actually mentions the delay /latency issue : http://www.musiciansfriend.com/pro-audio/blue-yeti-usb-microphone

Quote
...The Yeti utilizes a high quality analog-to-digital converter to send incredible audio fidelity directly into your computer, a built-in headphone amplifier for zero-latency monitoring, and simple controls for headphone volume, ... 

I call all this phenomenon "asychnronous real time". Of course when you have two realities that are out of step with each other, although they make pills for that for humans, they don't have a pill of radios yet Smiley
Logged
M0HCN
Member

Posts: 497




Ignore
« Reply #44 on: September 15, 2013, 03:40:08 PM »

Ah, you mean low latency, not realtime, definitions matter when discussing this stuff....

Odds are that that headphone jack on the usb mic is actually a digital mixer behind the ADC feeding a DAC and exists mostly so that the buffering in the PC does not cause comb filtering due to delay relative to the bone conduction path in the singers head.
The reason for putting a DAC in the mic is that attempting to use an ADC on one clock with a DAC on another is a can of worms, so best avoided to avoid customer support headaches.

The ADC and DAC will introduce about a ms of latency, due to the decimation and interpolation FIR networks, but the buffering to go from sample by sample processing (as you would do with a real DSP or in a gate array) to blocks of hundreds of samples as used in typical PC processing can add 10s of ms to the latency numbers, this moves the combing down from Khz to a few hundred Hz and makes it become very objectionable. 

In the context of a radio, for SSB latency of the up to say 50ms or so level is clearly a non issue, same for most data modes, as long as it is compensated for some of the EME modes.

CW is probably the only place it matters, and there are well known ways to solve this or at least to give the operator a choice of trade offs (Linear phase filters will ALWAYS introduce more group delay then non linear phase ones for example).

Low latency audio is a very tough problem on PCs, it can be done, but man what a pain.

73 Dan.
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!