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.
PS I Have dabbled in a contest or two... :-)
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.
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.
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.
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.
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.
I just looked at the ARRL's Tx to Rx Turn-Around test procedure (Sec. 4.9) but note that: (1) Fig. 4-9 needs correction to show TRANSCEIVER and not TRANSMITTER. At first, I could not understand why they wanted to sample audio from the transmitter to determine Rx recovery time; and (2) Fig. 4-9A needs a lot of clarification. What is the upper trace? Why is the trace delayed? Where exactly does key-up occur on the display? I see two envelopes. Is one RF and the other audio? If so, which? Those two figures need cleaning up to make any sense.
Clearly not an issue when running a frequency but a definite limitation on S&P...
Yes.. I know Writelog has a pretty good bandmap but it is static and does not correlate to the actual received signals on the Flex Display so one does not know if one should waste time listening on the spotted frequency or not..
If working S&P in contests we run NaP3 on a (Heaven Forbid) K3... the integrated spots into the Real Time display make a huge difference to rate as you can see immediately if the spot is actually there to work....
140ms latency is not really a significant issue in SSB Contesting as the human brain can usually integrate the odd time you miss a 1/2 syllable. Realistically most contesters are not EXPERTS so few S&P operators will jump onto your call within that 140ms latency delay....
I have actually (without knowing that it had less latency) run a few contests via DIGU and DAX.. did seem a tad quicker but not enough that I really felt a difference... I have used DIGU and DAX for Remote - where i did notice a quicker turn around.. but the Internet Latency was the real issue so every bit helped...
I can't comment on CW Contesting. No experience whatsoever
On RTTY Contesting... I can see where latency could be a major issue.. but then I have never come in the top 10 in an RTTY contest.. so until I build my RTTY Skill levels to contest grade, I doubt that the latency will have that much effect on my scores..
This weekend is my favorite contest WPX SSB... I am usually the only KY6 in the contest so I am a desirable multiplier which means that I can hold a frequency for the entire 48 hour contest and everyone comes to me. easy to do 100-200 Q/hr for a while anyways.... IIRC I have done over 2K Q's a couple of times Enough to dominate my area but Not as good as some of the Europeans who rack up 4-5K Q's
HOWEVER..XYL is NOT traveling this weekend .. so butt in the chair time will likely be severely limited... Likely only a very few hours of rates 100-200 Q/hr followed by intense silence...
My other favorite contests from my QTH are Asia Pacific and JIDX SSB Contests because my SteppIR MonstIR @85' @600' ASL 1KM from Pacific gives me about 30 minute longer openings at each end than anyone else in NA... Really helps to have a big station...as those contests seem to be like shooting fish in a barrel.. I tend to own the Pacific in contests.. I only wish I could same for Europe where the 1000' mountain in my backyard kills propagation....
BTW... love working the Japanese in contests.. they are so disciplined that I can get the rate up to almost 300 Q/hr by sitting on a frequency... I really wish some of the Europeans would take contest discipline lessons from the Japanese as everyone's rates would be better..
When we work ARRL Contests... I usually head up to the NX6T contest station which has the big gun to the East (I have a 1000' mountain in my backyard to the East)... NX6T wins lots of contests every year.. Mainly with K3's albeit we have many different transceivers (K3, 6700, KX3, FT 5000, 7800 to name a few)....
As i said the big difference maker for S&P is to use the NaP3 App to integrate Spots into the real time display on the K3.
By my estimates that can almost double S&P rates from 60Q/hr to over 100Q/Hr...
Why ......because you don't have to waste time trying to listen for spots you cannot see on the display as being workable... the lack of integrated spots is the one major shortcoming of the 6700 for S&P Contesting...
Finally .. they run a Contest University, every year at the Visalia International DX Convention and at Dayton.. the crowd is much more sophisticated at Visalia...
I don't have much of a dog in this hunt as I believe contesting to be the bane of amateur radio .. but I digress. no dog, but I do have a research-grade electronics lab and took the time to make a few measurements.
latency AM - 135.5ms
latency SSB - 146.5ms
remember too, that the sending station also has latency and switchover times that may help ameliorate the timing dependencies. geez .. I just want to call CQ and get an answer. any answer .. even if I have to wait an interminable 150ms!
I do have my Flex 6300 outputting a bodacious AM signal that I am very pleased with.
San Juan Island, Wa.
Just my 2 cents but, on my desk, i have a FT-991, a FTDX-3000 and a Flex 6500. Tune all the 3 on the same RX frequency and the flex is receiving ANY station much faster then the 2 other, in fact, the FT-991 and FTDX 3000 sound like echo because the flex receive and send the operating station to my speakers ( ears ) few milisecond faster then the 2 other and to me, by MUCH MORE then a full syllabe then the 2 yaesu..... Beside the fact that the flex can hear poor signal that the 2 yaesu are even not aware of, to me, if you RECEIVE faster you transmitt faster.... MUCH faster...
Speaking of Latency, I was just reminded of (stumbled into) a few simple performance enhancement tricks. Best of all, they're free:
LatencyMon - Just for kicks, I installed this free software from Resplendence Software on my Flex PC. In the PSDR days, I ran it on my shared I7 Windows 7/64 PC. Now using a dedicated I7/Win 8 machine along with SSDR 1.4, I didn't think latency was much of an issue. My machine did OK when receiving but going into transmit, LatencyMon said it was unsuitable for drop-out free audio. Wow!
First, it suggested turning off "power saver" so my CPU would run at 100%, all the time. (Control Panel, Power Management, etc.). That kept everything green no matter what I did. Who would have expected Dell to throttle back one of their faster machines, right from the factory. Tree huggers!
LatencyMon also suggested checking the BIOS. Pretty elementary but oh well. Doing a BIOS refresh further reduced latency while using SSDR 1.4.
Surprisingly, it didn't complain about video drivers. They were up to date. Still, making sure your video drivers are current can also help reduce latency.
For whatever it's worth...
I am aware I am discussing a different, but related, spec than the "TX-to-RX" latency in this thread (or maybe they really are the same spec but using a different way to set the origin of the time measurement?) By latency on TX I mean the delay between the mic audio and the RF power in my dummy load (where I test), and, on RX, my standard of comparison is the delay between audio from two receivers, one being my 6500 and the other being any not-so-smart receiver, tuned to the same signal. An acceptable number, in my opinion for contesting, is something well below 100msec, and it has to be down below 50msec or so to be imperceptible. I see there is debate on this thread about whether 150msec Tx-to-Rx delay is acceptable for contesting. I personally am in the "50 msec is barely acceptable" camp. I am not sure how to convince a "150msec is OK" advocate, except maybe to suggest you engage in a rapid-fire VOX SSB conversation with another Flex user. The delays from the mic in one shack to the earphones on the other add: the TX antenna signal is roughly 150msec behind the mic, and the RX antenna to receiver headphone delay is another 150msec. (Speed of light between stations even at earth antipodes adds maybe 70msec antenna-to-antenna.) This is not Tx-to-Rx switching time, this is just a static measurement of how long it takes for a vibration in the transmitter's mic to be repeated in the receiver's headphones when a Flex is at both ends of the conversation. Anyone old enough to remember telephone calls through geosynchronous satellites will recognize this 300msec end-to-end delay, and I can testify its not easy to hold a conversation through it. You learn to say "over," ending every transmission. SSB contesters probably aren't going back to that anytime soon.
There is one posting on this thread that DAX might reduce the latency. My measurements indicate quite the opposite. DAX adds delay for either RX or TX compared to what the 6500 does with signals at its rear panel ACC connector. That is, I have a cable from my 6500's ACC connector with audio line in and line out to both line in&out of a physical sound board. If I configure WriteLog to use the TX and RX on the physical sound board, I get delays on both the TX path and the RX path I estimate in the 150msec range. If I switch to a DAX channel to repeat either the TX or RX delay measurement, add another 200msec (wow!) to make 350msec. Do this in the on-the-air experiment I mention above and its 700msec end-to-end. I am pretty certain I won't be able to sell that configuration to serious SSB contesters, nor do I think we want to cable a sound card to reduce the latency in our shiny new SDRs, so am looking for what can be done.
Some times I like someone explain things to me, If I look it up I may find it confusing if I don't understand what they are saying. We are all on different levels here, sorry to say I'm on the lowest level I think....
But I agree, most things can be researched on line to increase understanding.
This conversation is no longer open for comments or replies.
This conversation is no longer open for comments or replies.
- 4892 Conversations
- 1476 Followers
- 2871 Conversations
- 601 Followers
- 3410 Conversations
- 882 Followers
- 803 Conversations
- 146 Followers
- 2802 Conversations
- 808 Followers