Receive Latency

W7NGA

Well, I *do* understand Barry's concerns. I am just surprised that latency is the problem it appears to be. 

M0GVZ

Then quite frankly they're as dillusional as everyone else who thinks it makes a difference or they're trying to come up with excuses as to why they've not done that well. Stations don't answer calls that start to get sent 50ms before others, they answer the ones they can hear enough of a complete or partial of. 

Here's how asinine the argument is and the that of claims your friends are making. At 20WPM a dit is 50ms. Being generous and assuming a 50WPM send rate then at most they're a dash behind the fastest person who gets their transmission out first. And that's at 50WPM. That is nowhere near a good enough difference to be the make or break between making a contact or not. 

And if its so critical I assume you're all using CW keyers that are analysing the RX audio for the millisencond the last dit is sent so you're not wasting time with the 0.7 seconds of human reaction time so there isn't a single millisecond wasted more than is needed or are you wasting time reaching for the function key on the keyboard or the paddle/key?

Yours sincerely, someone who holds a first in world in class certificate for a CQ-WPX-RTTY contest and a bunch of first in class in England for contests including CQ-WW, CQWPX, IARU HF World Championship and ARRL International DX and who ranks consistently in the top 20% of all entries despite only running 100W, an inverted L and a Hexbeam at 36ft.

M0GVZ

A remote rig isn't having to process a ton of data. Its processing at best about 3kbit/s, probably less than that. The K3 is also processing far less data. Quite simply its about the number of bits needing shifting and the Flex is shifting a load more than a K3 and RemoteRig.

As I've said earlier the additional delay is a dash at 50WPM. Hardly world ending or contest losing and if you're blaming that for not making contacts in a contest then you're just another bad workman blaming their tools instead of their lack of ability.

Andreas Junge

Exactly. The remote Audio on the Flex should be as low latency as on a RemoteRig connection, which it is not. The decoding is already done, so the remote audio should only add a few MS to the whole stream. I am OK with the latency at the audio connector at the back of the radio. I think there is room to improve the "Remote" audio stream as part of the Maestro rollout and WAN remote in 2.0.

Why does it matter? While you may not be able to tell a difference, at lot of us can and do. You should be happy with the performance you got. Let the rest of us help this fine company to make the Flex 6K line of radios the best in the market.

Why leave performance on the table if it can be improved? The hardware can do a lot, so I don't accept mediocre performance. They can and will do better than that. Not in this version, but maybe next. The Elecraft K3 would not be where it is today if it wasn't for all the user input and Elecraft's willingness to listen to them. 

And yes, I do contest from a hill at 2000' with limited road access at times, so remote latency matters. 

So please let's make this less personal and more about the data.

73, Andreas, N6NU

Barry N1EU

sorry, not buying it; 165msec is more latency that many somewhat fast cw contesters want to compete with

The cw filter slopes can be softened a bit by going to slightly over 400hz BW and turning on APF10.  But I suspect the APF might add even more latency.

Anyway, how did they get the latency down to 70msec on ANAN when they're even dealing with an ethernet roundtrip transport of the data since dsp is in the pc and not rig's FPGA?  Sure seems like Flex should be beating ANAN.

Walt - KZ1F

Is this something even fixable or is it a side effect of SDR or SDR as implemented in the 6000 series verses PSDR?

Lewis Cheek

Good question, how about some input Flex?

Lew
N4CO

Walt - KZ1F

I, vaguely, remember Steve talking abt this at one point but I have a very hard time searching for specific posts in getsatisfaction. Someone should introduce them to Lucene or (Sol).

km9r.mike

I am gonna have to side with M0GVZ on this. While I would definitely like to see Flex SS rigs have industry leading numbers wrt this issue, in the big scheme of things how big of a detriment are the current numbers wrt real world operating ? The only direct experience I have with this and I think it is noteworthy is operating the weekly NCCC cw sprint events. I think the bigger detriment for me is my ocf dipole at 35 feet, but that works out even better for this discussion. I mention the cw sprint events specifically because of their unique rules. A station can not sit on a freq and run stations. Once a qso is made they must qsy so if you do not get that station before another station does you are SOOL and must find someone else to work.

 Ignorance can be bliss and I had no idea our rigs were so slow but not knowing this I operated them with the understanding that they were just as quick as the next rig. While my qso totals are about one half of the top scores in these events, I think this is more of a reflection of my antenna's performance and lack of experience in these events compared to the top scorers. In other words, I am not getting beat out consistently while answering a cq because my Flex SS is so slow. I am able to win my fair share of qsos by beating the other guy to this critical punch. Now if this is indeed an issue, I need to start playing my rig's handicap and should start transmitting as soon as I start to hear the last dah or 3 dits being sent by the station calling cq.

Jay Nation

Was it this thread??
https://community.flexradio.com/flexradio/topics/latency-1-4-improvement

73, Jay - NO5J

M0GVZ

What I find funny is that some of those "contesters" complaining about latency run a radio with DSP which has latency no matter whether its an old Yaesu FT1000, an Elecraft K3, a Kenwood TS590 or a Flex 6000, run an amplifier which introduces its own latency and will run full break in which increases it even more. If 50ms latency was the make or break they're claiming it is they'd be running a non-DSP radio such as a Kenwood TS850 in semi break in and barefoot. 

M0GVZ

" If I get an option to select a filter shape of steep vs shallow with the resulting effect of high vs low latency then I can decide.  "

But then given as CW ops seem to be the most vehement complainers (complain about people not sending uniform morse but then complain about perfectly spaced computer generated CW for example) it'll then be decided that this isn't good enough and you should have the same latency with the steep filters.

Actually thinking about it if you implement soft filters instead of a "anything outside of 14.030.00 to 14.030.400 will be completely ignored", that involves more maths and data processing than vertical skirts because you're then having to calculate different steps of attenuation at both decreasing and increasing increments. 

In the linked thread K5UA makes a very important point and that is that having steep skirts is far more important in a contest than the extra delay. The only reason I bought a Flex for contesting is because the filtering of mechanical filters and DSP filtering implementation in conventional receivers is quite simply not good enough. The turnaround time is of no consequence to me until it starts to be measured in seconds. Far more time is wasted having to repeat information either way because a nearby station is overwhelming the station I'm in a QSO with than a 150ms latency will ever cause. 

Would it be nice to have a lower latency? Probably if that is a thing that floats your boat. Are the vast majority of users likely to notice any difference? No. Only those more interested in numbers on a bit of paper rather than real world effect are going to be concerned.

I'll leave with this final point. It is interesting to note how many people were completely unaware of any issue until the QST review mentioned it, such is how little impact it has.

Barry N1EU

Can you please repeat the point that K5UA made or tell me how to find it?

Walt - KZ1F

Good memory Jay! And / or you have mastered search arguments in GetSatisfaction. In either event, I believe that is what I was recalling, Thank you!

One thing I would caution folks about. If someone says or implies their sense is that <such and such>, they are not wrong, it is a general feeling of how well something is to them. Sure, there may be things that aggravate or mitigate the effect as M0GVZ and Steve point out, but the 'take away' for an individual is not wrong, as that's how they feel about the subject. Devolving a thread into personalities and blame serve no useful purpose.

Jay Nation

My search terms were, Latency N5AC KZ1F, I figured if you remembered it, you might have participated in the discussion. I had a feeling you were referring to N5AC, but there are plenty of other Steve's so I used callsigns which many people sign their post with. I got lucky! after I posted the link it seems those terms are less lucky. Now this thread tops the results, where before it was 4-5 down the results list.

A guide about better search terms would be nice.

73, Jay - NO5J 

Walt - KZ1F

ya know what? You are absolutely right, that didn't even occur to me, Wordpress Steve. But, I don't recall being part of that conversation as I am not at the point where even 500ms would make a difference in my success or failure to make a CW contact...Cool, I can blame SSDR or SDR in general from now on. Yes, Jay, I was referring to "the Zen of Flex" Steve.

N9VV

I am very interested in the Latency issue. One factor that I find very disturbing is that the ARRL has eliminated or discontinued their "TOR" test for PACTOR and AMTOR TRx operation.  These modes are now obsolete.  But for SSB operators, it points out that the Boat Anchor gear was designed to send a signal, switch back to Receive and then Respond within 20ms to the transmitting station.

TOR capable rigs are truly a delight to operate on CW using the examples for working DX that Barry presented earlier. Please do not throw away the "TOR" test/criteria just because *NONE* of the current rigs have that capability.

Latency is relevant to modern operation by operators who experienced the joy of true silky QSK in the past. When one is faced with spending $4K - $8K for a new rig, the Latency issue creates a truly major decision point. QSK is more of a necessity than just a preference for this operator.
thanks,
HNY de Ken N9VV

Barry N1EU

Interesting Web page with latency measurements:  http://www.n1kdo.com/sdr-delay-measured/

Barry N1EU

Andrew O'Brien

Very interesting
Andy K3UK

Lewis Cheek

Confirms what most of us knew, hope it improves soon.

Lew N4CO

ctate243

Barry just an fyi all the items we discussed back when you originally started this thread, latency, cw sidetone, adding MOX to the automated cw tx,  etc. are still on a "most wanted" features list for implementation.  After the Maestro smoke settles I am quite optimistic that work will start to be done to loop back on a couple of these issues.  These guys did a full context switch to get the Maestro done and as soon as they get rested and come up for air hopefully some of these items will be addressed.  the flex team appear to be keenly aware of some of the current issues and I probably burned some "nice guy" credit hammering home the contester nit list.  lets let them come up for air and see what the next pass of enhancements bring.

Kevin

Today I found a practical if not obscure impact of high latency and a slightly different take on what might be important about latency.

I've been playing around with Faros from VE3NEA which monitors NCDXF beacons on 20 though 10 meters. I was hearing the signals but they weren't being recorded. After an email to VE3NEA I was told to adjust the delay correction so that recorded points cluster around the short path.

I did that with the filters set at their lowest latency and got a few points for each station. Then I move the filters to their sharpest setting and, roughly averaged, I was seeing about 156 ms of delay. The effect makes everything look like it is coming in on the long path. 

Obscure. I know.

But here's my takeaway from this little experiment. It seems that, within reason of course, predictable latency through the filters (through the whole rig for that matter) is more important than low latency when it comes to measuring paths.

I'm not good enough to even consider 156 ms as impacting my ability to make a contact. More often it is fumbling with the key or living with a less-than-ideal antenna that keeps me at the back of the pack. But it is nice to finally figure out how latency can be important. Today I feel smart. Tomorrow it's back to being a pain in the neck.

73,
Kev K4VD

dl9eri/oe9eri

Today I took my scope and measured the receive latency of the new filter
settings just for knowing how they work and found that I can now use the slider for equal latency in all choosen bandwidth and modes. The numbers are +- 5mS.

The numbers: left is 0 - 1 - 2 - 3 and auto

In 0 : all modes and bandwidth  55 mS
In 1 : all modes and bandwidth  75 mS
In 2 : all modes and bandwidth 105 mS
in 3 : all modes and bandwidth 165 mS

In the -auto- position of the sliders there are different latencies for the bandwidth in CW and DIGI
from 55mS on 3-5KHz, 75mS on 1KHz, 105mS on 800Hz, and <400Hz 165mS. On SSB in auto there is always 165mS latency but you can choose from sliderposition 0 to 3 to change.

note: it is the receive latency when your partner sends a -did- and you can hear it on the 6500 after the delay in mS

best 73

W9OY

I don't know if K5FR has developed a macro yet, but it's my understanding these filers are callable in the API, as are filter bandwidth to the hz and filter position in the pass band. With all of that available designing a filter around a given parameter like latency should be do-able. I have several custom filters in my macro table 73 W9OY

Ria

I was at a friend's house yesterday doing some troubleshooting on his low band antennas and coax. For signal strength comparison we fired up my ssdr for IOS on my iPad and also his K3S. There was definitely a noticeable delay almost I would say 250ms or so. I am wondering if this is only in the app or in general?