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 97266 times)
W6RMK
Member

Posts: 662




Ignore
« Reply #60 on: September 21, 2013, 07:27:33 AM »

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



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.

Latency, on the RF path to the other end, is almost a non-issue regardless of mode *as long as the latency is constant*.  It takes 100 ms to propagate to the other side of the world, so adding 10-20-30 or even 100 ms isn't going to make a huge difference.

If the latency on the RF path varies randomly, though, it makes it very difficult to copy CW.

Where most people object to the latency thing is when trying to monitor their own CW transmission using a receiver.  There, the tens of ms latency bites you, because it's far enough out of sync to confuse you (the "singing on the PA in a stadium without earplugs" problem).

One can use a keyer or generate the sidetone some other way, but then you aren't listening to your own signal.
Logged
N4OI
Member

Posts: 210




Ignore
« Reply #61 on: September 23, 2013, 02:27:21 AM »

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



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.

Latency, on the RF path to the other end, is almost a non-issue regardless of mode *as long as the latency is constant*.  It takes 100 ms to propagate to the other side of the world, so adding 10-20-30 or even 100 ms isn't going to make a huge difference.

If the latency on the RF path varies randomly, though, it makes it very difficult to copy CW.

Where most people object to the latency thing is when trying to monitor their own CW transmission using a receiver.  There, the tens of ms latency bites you, because it's far enough out of sync to confuse you (the "singing on the PA in a stadium without earplugs" problem).

One can use a keyer or generate the sidetone some other way, but then you aren't listening to your own signal.

I do not believe the issue is the inability to listen to one's own signal.  There is just no way to compensate for significant latency, whether constant or not, and still have good QSK...  After experiencing QSK from a K3 or any of the older Ten-Tec radios, you're not going to "keep 'em down on the farm" with a keyer-generated sidetone either.....   

73

Logged
M0HCN
Member

Posts: 473




Ignore
« Reply #62 on: September 23, 2013, 11:05:26 AM »

The key question is what is significant?

I would guess that 10ms (as long as it is constant) probably is not significant (That is going to be in the ballpark for vacuum relay T/R switch and rx desense recovery time on a conventional rig, and actually a well crafted PC program should come close to this as long as the network frames are not too big.

20ms, 50ms? I have no idea, but I would bet the threshold is greater then 10ms for almost everyone and greater then 20ms for the vast majority of ops. 

Regards, Dan.
Logged
K5TED
Member

Posts: 781




Ignore
« Reply #63 on: September 23, 2013, 10:05:15 PM »

If the main objection to SDR is that CW ops can't listen to their own clicks, then I'd add this...

For about 15 years, I was accustomed to listening to myself over an air monitor. That way, I could hear myself as heard by listeners. With the advent of digital STL links, the latency was enough to make realtime listening impossible. We adjusted to listening to ourselves off console audio.

With the present SDR tech, and the inherent latency, it is impossible to listen live.

The overwhelming majority of amateur grade xcvrs do not offer a "MONITOR" function, yet we get along just fine.

It seems as if the insistence of CW ops to have the ability to listen to themselves "realtime" is just a crutch and excuse to malign current SDR tech.

Use a keyer and get along, or get left behind.

Logged
AK7V
Member

Posts: 251




Ignore
« Reply #64 on: September 24, 2013, 09:20:41 AM »

...
It seems as if the insistence of CW ops to have the ability to listen to themselves "realtime" is just a crutch and excuse to malign current SDR tech.

Use a keyer and get along, or get left behind.


I haven't used an SDR, but based on what I'm reading, I'd guess that the QSK isn't that great because of the latency.  For me, excellent QSK at mid to high speeds is something I love about CW and wouldn't want to sacrifice.  It's not so much listening to ourselves "realtime," but being able to hear the band "realtime" between code elements.

I'm not worried about being "left behind."  HF radio is old news all together, we've all been "left behind" already.  Smiley
Logged
AB7R
Member

Posts: 146




Ignore
« Reply #65 on: September 24, 2013, 10:50:41 AM »

I don't think there are any modern radios out there in the past 20 years that do not have a CW side tone monitor.  I have a 6700 and use an external keyer for contesting purposes but any radio that supports CW should have a usable side tone monitor available and QSK capability.  I understand from the Insider reports that there has been much focus on QSK and CW in general that I hope will be in the Ver. 1.0 release.

73
Greg
AB7R
Logged
K5TED
Member

Posts: 781




Ignore
« Reply #66 on: September 25, 2013, 07:07:34 PM »

I don't think there are any modern radios out there in the past 20 years that do not have a CW side tone monitor.  I have a 6700 and use an external keyer for contesting purposes but any radio that supports CW should have a usable side tone monitor available and QSK capability.  I understand from the Insider reports that there has been much focus on QSK and CW in general that I hope will be in the Ver. 1.0 release.

73
Greg
AB7R

Good point. I would say that QSK is purely a contest requirement and has no bearing on day to day typical amateur radio use as a whole. The solution is that those who plan to contest seek something besides an SDR, since at this juncture and for the foreseeable future, DSP based rigs simply will NOT be capable of delivering true QSK. Someday, maybe, but for now, the SDR is the realm of phone, digi, SSTV, and casual CW users. That's just the way it is, and no amount of harping will fix that. The only solution is a DSP platform that has no latency.

We don't have that capability now. We won't have that capability within the next 10 years. We won't have that capability until digital signal processing makes some leap of performance that is, at this time, inconceivable.
Logged
AK7V
Member

Posts: 251




Ignore
« Reply #67 on: September 26, 2013, 10:35:23 AM »

I don't think there are any modern radios out there in the past 20 years that do not have a CW side tone monitor.  I have a 6700 and use an external keyer for contesting purposes but any radio that supports CW should have a usable side tone monitor available and QSK capability.  I understand from the Insider reports that there has been much focus on QSK and CW in general that I hope will be in the Ver. 1.0 release.

73
Greg
AB7R

Good point. I would say that QSK is purely a contest requirement and has no bearing on day to day typical amateur radio use as a whole. The solution is that those who plan to contest seek something besides an SDR, since at this juncture and for the foreseeable future, DSP based rigs simply will NOT be capable of delivering true QSK. Someday, maybe, but for now, the SDR is the realm of phone, digi, SSTV, and casual CW users. That's just the way it is, and no amount of harping will fix that. The only solution is a DSP platform that has no latency.

We don't have that capability now. We won't have that capability within the next 10 years. We won't have that capability until digital signal processing makes some leap of performance that is, at this time, inconceivable.


I'm guessing you're not a high speed CW op, then.  QSK is not "purely a contest requirement."
Logged
K5TED
Member

Posts: 781




Ignore
« Reply #68 on: September 26, 2013, 05:41:33 PM »

If you're not contesting or in some sort of CW traffic net, then why do you need to hear in between your characters?

No, I'm not a high speed CW op. I admire those who are. SDR is not for them at this juncture.

 
Logged
N4OI
Member

Posts: 210




Ignore
« Reply #69 on: September 27, 2013, 04:33:55 AM »

If you're not contesting or in some sort of CW traffic net, then why do you need to hear in between your characters?
[...]

When I am responding to a CQ, or calling CQ, QSK allows me to stop sending as soon as I hear another station -- that helps me avoid me becoming QRM.   Also, when I am in a QSO, I can hear someone wanting to break in or comment and turn it over.  (I assume phone ops. use VOX for some of the same reasons.)

The only time I go to semi-breakin operation is when the QRN is so high that I cannot hear my sidetone -- and that is very rare.

QSK is essential for me; every radio I have, from my Rockmite to my K3, has it. 

73
Logged
M0HCN
Member

Posts: 473




Ignore
« Reply #70 on: September 27, 2013, 01:40:17 PM »

[quote or=AB7R link=topic=91646.msg702581#msg702581 date=1380045041]
We don't have that capability now. We won't have that capability within the next 10 years. We won't have that capability until digital signal processing makes some leap of performance that is, at this time, inconceivable.
[/quote]
Disagree, we can do this today, its just that we don't because the SDR scene is wedded to general purpose operating systems on commodity hardware and often has a poorly thought out keying input.

Lets say 10ms is a reasonable latency, and that getting to and from an I/Q pair at a reasonable symbol rate takes 2 of those ms (Probably realistic for the CIC and decimator/interpolator chains to do their thing).

Lets say we are getting an I/Q sample every 10us (100KHz I/Q sample rate), and that we are doing the work in a DSP interrupt handler on a core closely coupled to the FPGA fabric (Cyclone 5 for example can have a dual core hard IP arm  on the die) or at least on the same board.

Now we are processing a sample every 10us, and ignoring filter latencies can turn it around in 1.01ms aerial to audio dac or vice versa.
This leaves the filtering, which is surely going to be some kind of FIR/IIR mix, and if we switch to low latency mode is NOT going to be linear phase (For the same reason narrow crystal filters are not usually linear phase, causality makes the group delay excessive), filter delay is a fact of life in either analogue or digital filters, and the only reason we notice it more in digital is because we choose to optimize for other things (Constant group delay being the big one).

Note that 10ms is almost certainly faster then any rig not using diode switches can go from rx to tx without risking hot switching at least one relay, and is only slightly longer then the rise time of a well behaved keying envelope.

73 Dan.
Logged
K5TED
Member

Posts: 781




Ignore
« Reply #71 on: September 27, 2013, 07:06:35 PM »

"Disagree, we can do this today, its just that we don't because the SDR scene is wedded to general purpose operating systems on commodity hardware and often has a poorly thought out keying input. "

Add in the extra 8ms for the trip from the client to the router to the SDR and back.

Dependency on a networked client console will have inherent latencies that simply cannot be eliminated.
Logged
M0HCN
Member

Posts: 473




Ignore
« Reply #72 on: September 28, 2013, 02:58:44 AM »

Which is why I mentioned closely coupling a processor to the gate array.

Actually, 8ms would be shockingly poor for a uncontended local link, with preemption on in the kernel and tuned interrupt processing priorities, I am seeing network latencies in the 400us region (And could probably do better).

Still best to hook the processor directly to the gate array fabric, but networking is not a show stopper.

Regards, Dan.
Logged
W6RMK
Member

Posts: 662




Ignore
« Reply #73 on: September 29, 2013, 09:29:00 PM »

W
Actually, 8ms would be shockingly poor for a uncontended local link,

That's a sort of typical ping time for a household WiFi network.
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=6.162 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=6.279 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.911 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.228 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=3.053 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=7.518 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=6.028 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=4.803 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=6.370 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=1.276 ms

Just goes to show that one probably shouldn't use WiFi (competing with everything else) to do hard real time with <10ms latency requirements.

Wired should be <1 ms for the same scenario.

Logged
M0HCN
Member

Posts: 473




Ignore
« Reply #74 on: September 30, 2013, 10:41:06 AM »

Short deadline RT over wifi? "Doctor, it hurts when I do this".....

Not surely a reasonable thing to do if carting a reasonable chunk of spectrum around as an I/Q sample stream.

I have found that some so called gig-e cards have really shonky drivers that cannot keep up if you come even close to saturating the link, so you have to be a little picky wrt hardware if you want things to work well, but it was ever thus.

Regards, 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!