Latency 1.4.....Improvement?

George - AB4FH

Steve, Excellent read, thanks. I didn't see any numbers for the associated latency of each bandwidth, however. Based on what Howard says below, I agree that latency will only matter to the average contester who does a lot of S&P. Hmmm...I think this means it is a spec that could be significant to a number of us average Joe's. I would propose, as someone else suggested, either having a contest latency switch, or make it prominently visible in the documentation how to choose low latency.

Rich McCabe

Interesting. I guess this explains why I cant seem to listen to my 6500 audio on another receiver.  I thought my brain was not working correctly.  This is the first radio I have tried to EQ via monitor on another device and although all by radio buddies do it, I could not make it work for me.  Maybe my drain in not bamaged.

Joe, KQ1Q

What is the proven basis that a 100 mS latency differential results in loosing a "quick draw" contest pounce? That is 1/10th of a second. According to this research paper, the average English syllable length is about 200 mS: http://www.researchgate.net/profile/Steven_Greenberg5/publication/222530556_Temporal_properties_of_s...

This means on average, the latency might result the other party getting a 1/2 syllable head start, given equal human response times.

It would be interesting to set up a double-blind test with variable Rx latency (radios not required) and see if unprepared subjects can even detect 100 mS, or if others can truly leverage that to their advantage. Until that is investigated I don't see pulling limited resources off higher priority tasks to implement something with unproven benefit, based on an allegation with multiple possible causes besides latency.

ctate243

This is an interesting thread.  I am going to run some comparative testing soon from the N6RO contest station where we will have my Flex 6500 and several other K3's and document it.  This may be a hard concept for some to swallow but this type of performance metric does make a difference in the minds of performance based radio ops, and perception is 9/10ths of the rule.  We need to try and have a solution in place when numbers like this appear.  Contesters are very performance conscious some times logically and some times not so much.  Contesting is skill.. and to maximize skill requires top performance.  think car racing as the mind set.   We are excited to start putting thousands of QSO's per year via the flex signature platform.. I have already started. providing filter sets and any latency reducing solutions(call it contest mode or whatever) will facilitate putting Signatures in contesting shacks. A lot of the platform is ready to rumble.. just a few details, and watch the Signatures start filling up 3830 reflector.  

Chris, N6WM

PS I Have dabbled in a contest or two...  :-)

Barry N1EU

Latency is not an issue when you're running at a high rate?  If it's enough latency that you miss the first syllable/character of a fast responder, it WILL slow you down.

Steve N4LQ

Note: The latency doubles between two Flex-6000 users. 

Barry N1EU

Joe, that sounds about right to me - I think 200 msec is the critical delay where it's going to definitely impact you at times.

Barry N1EU

Steve N4LQ

Note: Latency doubles between two stations. 2 flex 6000 users experience 280 ms delay per exchange. A contest full of Flex rigs would slow the overall count for the entire contest. 
During Field Day 2014 there were 1, 268,916 QSOs. Someone do the math on how many fewer QSO there would be with an extra 200 ms delay per station.

Rich McCabe

To me it doesn't matter. However I am not sure it has anything to do with math and less stations worked. Its all about getting the contact or not.  Losing 2/10 of a second for every connect is not going to add up to anything worth noting. Losing a contact because of delay is another thing.

Joe, KQ1Q

Yes, that was my point. If (just supposing) 200 mS is the critical delay threshold, and the Flex 6000 is 1/2 of that, how would it cause a major problem? Actually I'm not sure anyone authoritatively knows what the latency threshold is where it provably and measurably causes a disadvantage in this one narrow area of contest performance.

This is especially so since changing to lower latency would involve losing other filtering advantages. Any hypothetical advantage from reducing the 100 mS latency might be offset by worse filter performance. If poorer filtering caused just 1 in 20 QSOs to require a single 3 sec retransmit due to unintelligibility, overall contest performance would ironically be worse by using faster latency.

Dan -- KC4GO

Unless you do what I did during the FRS net on  Sunday I monitored Dudley's stream and tried to reply to net control from my radio. I was way out of sync!!! Dudley's stream had a much better copy so i needed to be able to use his transmitter...

Ken - NM9P

If you are S&P, and know your station lags a 100ms on beginning of your transmission, just develop the habit of being a little quicker on the mike.  End of story.  

I run S&P all the time because I don't have enough antenna or power to RUN a frequency.
If that is the case, my best chance is often not to be the first syllable anyway, because I will likely get stomped by the stronger stations.  Sometimes my best chance is to be the first of the second wave calls.  "Timing" doesn't always mean being first, but often it means being the "smartest."

Mike_N1MD

I am a contester. Not a "big gun" but a steady,"little pistol" participant.
Frankly, I do not care about lab testing numbers.
What I am interested in are contest scores and finishes.
Those of us with FlexRadios who contest need to report scores and let the contest results determine the viability of the Flex 6000 as a tool for amateur radio contesters.

Scoring performance trumps theoretical argument.

Mike N1MD

George - AB4FH

For CW contesters, consider this. At only 30 wpm, which is not unusual in a contest, each code element takes 40 ms. The current latency of 140 ms is 3.5 code elements. My call goes from AB4FH to EB4FH if you truncate the first 3.5 elements including intracharacter element. Practically speaking, the other guy has already sent the first letter of his call while mine is making it to my antenna. This might explain why a 38 ms latency or one dit, is more acceptable.

Barry N1EU

You need to either call the other guy or call cq plus your exchange xmsn so you do 2 xmsns per contact.  Let's say an average contact is 15 seconds.  So you add .4 seconds (200msec x 2) to that so there's a 2.7% time penalty.

(I realize you were being facetious Steve ;-)  )

Stu Phillips - K6TU

Turn around time is an issue - perhaps less so in phone than in CW or RTTY but there is an issue.

The ARRL review of the K3 says its turn around time is measured as 25 mS.  The same figure for the 6700 is 184 mS.  In both cases this is transmit to receive turnaround.  Some other numbers from ARRL review...  FTDX5000 - 66 mS, TS-590 - 30 mS, IC7800 - 15 mS...

Flex 5000 - 29 mS - and this has brick wall filters too...

Like Chris N6WM, I am a serious contester and I have a reasonably competitive mid-sized station. Whenever possible in all modes, I run a frequency - I call CQ and try to maximize my rate.

The issue with turn around time in both CW and RTTY is that I miss part of the call that is sent back to my CQ.  In RTTY, its common that someone sends their callsign twice - if both print ok, I don't have to ask for a repeat to verify that I have the call correctly.  Yes, there are other opportunities to verify the call but that's not the point.

Its not the additional 149 mS that is the sole issue - its whether I have to get a fill or miss copy the call as the result of the delay.  If I have to do this frequently enough, its an issue.  Why?  Because in a contest where I will make > 1500 QSO's, even a couple of seconds per Q translates into meaningful operating time in the course of a 48 hour contest when your rate is 60-100 Q's per hour...

I am competitive with my 6700 - in fact, I continue to exceed my previous personal bests in each contest where I make a concerted effort.  Some of this is modest skill improvement (I keep thinking after each contest how to do better in the next one) but I credit the radio for its reception capabilities as well as the much lower fatigue level that results from it's operation.

How much of an issue does the additional turn around time represent?  Hard to quantify but in RTTY I can SEE the issue - it audible in CW and Phone.

Chris rightly points out that contesters are heavily spec driven - it sure would be nice to see the turn around time addressed if for nothing other than the comfort level for the serious contester.  Even that said, I believe that getting into the 50mS range would significantly reduce the possibility of having to ask for a fill or repeat.

Stu K6TU

Bill -VA3WTB

What I know is Howard is one of the best contesters around and has won many. If he says latency is not an issue for him then that seals it for me. And Ken says the same. I'm sure if it were a problem they would have said so.......

Stu Phillips - K6TU

Howard and Ken are serious contesters to be sure and perhaps its not an issue for them - they can add their own comments and also quantify their rates/QSO totals as part of the response if they wish.

I'm glad it seals the issue for you.

Alas, my personal experience doesn't for me.
Respectfully,
Stu K6TU

George - AB4FH

Ditto. Respectfully, George

Tim - W4TME

"Wouldn't a contest mode with poor filter skirts be counterproductive ?"

Yes, but sharper filters result in greater signal propagation delays. 

Barry N1EU

Ditto, my experience says otherwise.

Barry N1EU

ctate243

Stu I agree 100%.  This is an issue that is going on my list as a problem requiring Optimization to reach the top bar.  Our racecars(signature rigs) need to be tuned for maximum performance. Think of the boost in QSO count Howard and Ken would get with the turnaround latency resolved! 5,10, 50?  This could be a winning difference. I want my flex to be my primary contest rig.  We have to have that level of optimization for mass adoption of the platform by the contest community.  They are a fickle group that obsess over numbers like cw rise times, easily selected optimized filters and, yes turn around times.

  My suggestion for Flex Radio would be to take some of the weaknesses being brought out by the testing lab and get them turned around Quickly.  The vendor of the current #1 preferred contest platform does this quite effectively.

Ken - NM9P

Bill, Stu and others...
While I am flattered to be mentioned in the same sentence with contesting greats like Howard and Stu, I am not in the same league.  (Though, thanks to the 6500 I am getting better!)

However...here are some expanded thoughts after additional thought and feedback from others...

As a Phone & CW S&P-er..., the slightly higher latency hasn't hampered my rate nearly as much as the improved TX quality and superior RX sensitivity, selectivity, RX IMD/Blocking figures, reduced operator fatigue, and other improvements have added to my contesting experience.

Adjusting my timing and operating habits has eliminated any defect upon the beginning of my transmission.

I have had to make adjustments, however upon the end of my transmissions.  
In the beginning, I found that I was getting off the footswitch just a hair too early and cutting off the last half of the last letter in my call...."November Mike Nine Pa...."  instead of "papa."  This caused me to miss a few stations or required repeats until I learned to be a little faster on the press of the footswitch and a little slower on the release.  VOX operations wouldn't matter once you got the delay set correctly.

However... As Stu has mentioned, I can see how a longer latency-induced turnaround time could be a hindrance when running a frequency on RTTY or other Digital modes...perhaps even CW, though my CQ skills fer running a frequency rather than S&P would be the severe limiting factor at my station!

Long ago, when AMTOR was gaining popularity, they were trying to shave turn around times down to <25 ms, if I remember correctly.  Some were even trying for <15 ms?

I am a big fan of the brickwall filters...I almost always use 50 Hz when DXing or Contest S&P to give me the best chance of hearing a station.  When running split, I run the "much wider" 250 Hz filter on the "mob" frequency so I can get a better picture of what is around the station being worked and give me a better chance of finding a hole or hearing the next station up or down.   (I can't believe I am calling 250 Hz a "wider" filter!  It used to be the standard for "narrow.")

However, I can see that there might be some occasions where I might be willing to sacrifice a little bit of sharpness in order to gain some improvement in turn-around.  That might mean running 50 Hz reduced slope instead of 100 Hz, which would still be great compared to most other rigs.  IF... and it is a big IF... This could be selected and turned off at will.
I would not be willing to sacrifice my ultimate filter performance on CW & SSB permanently. 

Perhaps it could be implemented in DIGI only?  Or defined per-mode at the user's discretion?

This would be an interesting for the FRS staff to have as they work on V.1.5...
I don't know how much time could be shaved off of other procedures and timing loops, but it seems reasonable that while fine-tuning all the other functions they might do a complete sweep (again) of the timing elements and other things that contribute to latency and turn-around time.  (I am sure that they have swept this many times in the past already.)


Anyway... my $.02

Ken - NM9P

Tim - W4TME

You should be setting the EQ with all processing turned off, such as PROC os it will not "color" your audio and will also decrease the latency a little when listening to your transmitted signal in a second receiver.

George - AB4FH

Ken (corrected), I think there are different cases. At a leisurely 30 Q's per hour I could afford to wait. But when at 100 Q's per hour S&P with N1MM+ and CW Skimmer loading the bandmaps, I often skip to the next station rather than wait for the exchange to finish. I work up the band like this and catch him on my way back down. My experience shows this works better for me. In fact if a station is spending too much time repeating CQ TEST over and over, I move and try to catch him one of the times he's near the end . My particular enjoyment is to work the contest for a few hours, enough to get 300+ Q's. This leaves more time for my family and other activities. In other words, I enjoy the exhilaration of speed and intensity, not the ****-in-the chair time of winning.

FWIW, you are absolutely 100% spot on when working a DX pileup while not in a contest.
BTW, I am a CW contester. ;-)

George - AB4FH

To elaborate further, it's good to run SO2V. Then, while waiting, switch to the other slice/VFO and make a Q...switch back to VFO A and make the Q you were first waiting on.

ctate243

"This would be an interesting for the FRS staff to have as they work on V.1.5...
I don't know how much time could be shaved off of other procedures and timing loops, but it seems reasonable that while fine-tuning all the other functions they might do a complete sweep (again) of the timing elements and other things that contribute to latency and turn-around time.  (I am sure that they have swept this many times in the past already.)"

Spot on.   I dont agree that some trade off is the best approach.   I would also add some specific ease of use filters, for example  a RTTY specific filter that would not require the invocation of the XIT/RIT, to be on qrg etc.  Click and run.  no time to mess or worry with stuff when logging at 300 qph.

~C./N6WM

George KF2T

Thanks for the info - learned something new today!

Paul Christensen, W9AC

Probably a good thing I'm not a contester!  My first and last was the 1972 Novice Roundup.  Hated it.   

Something is not adding up though... 

One year ago, I measured T=>R turn-around time in CW.  I measured approximately 50 ms in QSK mode.  I measured from the time of the actual CW key "key-up" (green trace) to the point of receive audio.  Not sure what that measures today with v1.4, but it needs measuring in multiple modes and multiple bandwidth settings and that takes a lot of  time.

https://community.flexradio.com/flexradio/topics/flex_6700_cw_keying_v_elecraft_k3

Scroll down to the section where I discuss the 50ms delay -- and N5AC responds.  Steve explains the delay in detail and discusses delay factors. 

As I recall, during my test, Rx bandwidth in CW mode was set to 2.8 kHz, my normal "ragchew" bandwidth setting.  That setting is close to a normal SSB receive bandwidth.  In CW at 30 WPM, the duration of one "dit" is approximately 40ms.  [T(ms)=1200/wpm] 

So, what we're talking about here is an audio delay of just over one dit at 30 WPM.  I'm not going to argue whether or not that affects a contester's  CW run rate, but I can say that the issue has never been noticed by me when trying to precisely time split DX contacts where "getting in" at the right moment is just as important.  I'm surprised the ARRL measured T=>R time of 184ms and R=>T time of 138ms, assuming a normal SSB receive bandwidth.  Why is SSB taking longer to turn around than CW?  I'm not disputing the ARRL's measurement, but I would like to know the exact test condition since my measurements in CW didn't show that kind of delay.  

This is an instance where the expanded QST Product Reviews would be a big help.  Not sure why that was discontinued, but as SDR dominates our shacks, the T/R and R/T turn-around times should be measured under varying conditions of mode, Rx bandwidth and other factors, including rigs that allow one to adjust filter tap settings where firmware/software must compensate for those changes. 

Paul, W9AC

 

  

Stu Phillips - K6TU

Paul,

Excellent comments as always!  I had forgotten the thread you referenced and the 50 mS number!

Something about Lies, Lies and **** statistics comes to mind!

There is truth in numeric data but only when you understand the test conditions!

ARRL Labs document their test procedures - here's the link:

http://www.arrl.org/files/file/Technology/Procedure%20Manual%202011%20with%20page%20breaks.pdf

Page 27 provides the turnaround test measurement configuration - could you take a look and see how this compares to your test set up?  There is a very detailed description of this test even with scope pictures...

I know qualitatively that on RTTY I typically miss (not mis-print, miss as in NOT present) between 2 to three characters of a callsign on the first print.  If I have the math right...  at 45.45 bps, 5 data bits, 1 start bit and perhaps 1.5 stop bits - would translate to approximately 165 mS per character...  i'm assuming that the decoder itself has some "training" time as well.

Really curious now as to the correlation between the real world and the lab test numbers...

Stu K6TU