Latency 1.4.....Improvement?

Steve N4LQ

en four 

George - AB4FH

Thanks for the measurements, Dan.  BTW, do you know Randall Benson?  He lives on San Juan Island, too.  He is one of the principals in BioCast Technologies, LLC.  I am also a principal.

K6OZY

It certainly looks like a filter width of 401Hz would be a 43ms filter.

George - AB4FH

Good point.  I missed that.  Steve, N5AC, is that correct?  I'll use 401 Hz from now on.  Doesn't seem to work out for 100Hz to 250 Hz when things get really crowded.

KY6LA_Howard

@Burt

Playing Video Games makes for Skilled Drone Pilots

Counting Blades of Grass makes for skilled agricultural scientists...

Surprisingly Contesting also makes for very valuable EMCOMM Skills ...

I was a responder in the 2003 San Diego Fires and Net Control during the 2007 San Diego Fires.   The volume of EMCOMM traffic was huge because all normal and especially all Government Communications failed..  Hams picked up the slack and passed hundreds and hundreds of EMCOMM Traffic.

With the traffic volumes being so incredibly intense, it quickly became obvious that ARES was conspicuous by its absence because they were stuck manning hospitals and the CERT Ham responders just could not handle the volumes without creating life threatening errors..  Contesters and DX'ers checked in, quickly took control of the nets and soon smoothly handled the previously overwhelming traffic flows...

It was the hams that had practiced High Q rates under difficult conditions who saved the day....

BTW.. I have a write up of the 2007 San Diego Fires compiled from my station activity log that was published widely in the press if you ever want become aware of a real practical example where contesting training and experience proved invaluable....

KY6LA_Howard

All the major Contestors in San Diego county who hadn't been evacuated because of the fires pitched in to help. ....as the fires advanced mor nd more were evacuated. .. Several refused to be evacuated so that they could continue to pass traffic and direct rescue efforts in the area. All in all IIRC more than 300,000 were evacuated over a couple of days. ... In some cases minutes before firsts burned their homes.

Steve N4LQ

Why does this bring to mind Foghorn Leghorn and Napoleon Dynamite?

The Count

I have done tests on a couple radios regarding RX latency. This because a while ago I had a 6300 tuned to a Colorado time server frequency and a Kenwood 590 also. Noticed a perceivable delay between the 2 audio streams which made me wonder. Using a Rigol scope I was able to compare RX latency between several radios. Not surprisingly, the most basic, simple radios (like the MFJ Cub) had the lowest latency. Reason: No DSP and other complex circuitry. The Flex had the absolute highest delay around 150ms if I remember correctly. A K3 has about 15ms. TX latency (CW) I have not looked into, if anybody has done tests in that respect I would like to hear from them.

VE2MBT

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...

W7NGA

Marc-André, your observations don't match what would be expected from the architectures of the radios you mentioned. Perhaps you can perform additional testing and forward your results.

K6OZY

I would like to  know this too since they both have "brick wall" filters.

Bill Roberts

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...

Tim - W4TME

Justified! - https://community.flexradio.com/flexradio/topics/remote-audio-stuttering-drop-out-on-transmit

See my comments about DPCs.

Wayne, W5XD

I would like to know whether this discussion about latency in the Flex audio--both for TX and for RX--is considered settled. I am trying to configure WriteLog for SSB operation and am unable to get latency for transmitted audio, especially, down to an acceptable delay, so far. I am also unsatisfied with the RX side. My interpretation of my measurements, so far, is that the latency is not inside WriteLog, but is inside the Flex itself, and even more is contributed by the DAX devices.

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.

Wayne

Stu Phillips - K6TU

Wayne,

I don't see the same additional delay you mention when using DAX either with Writelog or with N1MM+.  To be fair, I haven't measured it but from the point I push the function key when using either logging program, the RF starts out will minimal perceived delay.

Have you tried rebooting your PC?  I do see issues with DAX from time to time that seem to due to some buffer management issues in PortAudio.  A reboot or even forcing the deselection of the DAX device and re-selection generally removes  the issues.

I will say that as a serious contester, I haven't seen my SSB rate impacted other than positively by using the Flex 6700.  This past year I put in a personal best in SS Phone that was substantially higher than any of my prior efforts.

I'm not pushing back on the issue or TX-RX turn around time - quite the contrary - it is too long.

Stu K6TU

km9r.mike

I do not have a great appreciation for the work that would be required to achieve the 43ms @ <=400 Hz target but I would appreciate this as well especially in the cw mode. At the same time, I am learning that many good cw testing ops better than I will open up the filter ( 500-1000Hz) while running to better catch all callers. However, many times crowded band conditions do not allow such wide filters so the 43ms @ <=400 Hz seems to be a good target and far better than 85ms.

km9r.mike

New York Approach has nothing on Chicago nor Delhi but I will agree they are quick. After being invited to op at a station far better equipped than I can hope to achieve, I have gotten a great appreciation of just how tight final scores can be and 25-35 Q's / mults can make a whole world of difference in the world of big guns and others as well. And while it is not the sole strategy, running q's is definitely the biggest factor at such stations.

 I love the quoted 8ms time for pouncing but the potentially long turn around time while running is not good and that is if all goes well. If the running op has to repeatedly ask for a fill due to missing the first letter/number of a prefixe, well as the New Yorkers say fugeddaboutit.

From my own station, I have limited myself to qrp testing which limits me to mainly S&P. I have seen zero issues wrt latency time since 8ms is sierra hotel. 5w on the other hand is the bigger issue for me and a dipole at 35ft. : (

km9r.mike

As I posted above, I like the target of 43ms <=400 Hz that George AB4FH proposed but due to the architecture of the 6k I do not have a full appreciation if this is even possible. I saw where it was for the 5k but understand kinda that the 5k was a whole different animal.

k0eoo

Thanks Steve, FRS made the right choice.  Better filters serve us ALL, every day and every contact....

Tim - W4TME

We can give you fast filters, but the shape factor will be high.  You can't have sharp filters with low latency.  This is the first rule of DSP thermodynamics.

k0eoo

Please NO NOT change the filters ...  FRS will be playing into our competitors hands if we reduce our GREAT filters.  We have contesters in the fold who have NEVER made this an issue so lets not spoil the porridge... This is one mans opinion, YMMV.

George - AB4FH

Thanks, Tim.  I would like to repeat my request for a "Fast Turnaround" option of
43 milliseconds at <=400 Hz.  I understand this will give Very Good filtering (less steep skirts) instead of Excellent.  What would be even better is a selectable "Taps"
setting for each filter width that allows us to choose the compromise of skirt vs. latency.

Tim - W4TME

I seriously doubt we will degrade the shape factor of the filters to reduce latency.  The filters rock like they are now.  If we can achieve lower latency without changing the shape factor, that would be considered.

Stu Phillips - K6TU

PowerSDR had significantly lower tx to rx transition time and great filters so we know it can be done.

For folks to say that contesters have never raised this issue is simply incorrect - I raised the issue a long time ago.

Lower latency is a key requirement for me as a contester.  So are excellent filters...

I don't want one or the other - I want both.  There are likely trade offs in functionality or capacity that result but that would be a fine alternative for me.

Stu K6TU

George - AB4FH

As a clarifying note, this compromise would still give the user the same skirt at <=400 Hz as they currently have at <=1 kHz per the user's guide clip above.  

Bill -VA3WTB

Leave it alone Tim. as you said we can't have both. If you trade off soon others will complain about the trade off. My vote? just leave it .

George - AB4FH

Final comment to allay the fears of non-contesters.  I was asking for an optional "Fast turnaround" selection, perhaps in the CW tab when first turning on SSDR.  The default would be exactly as today.

Wayne, W5XD

W4TME said: I seriously doubt we will degrade the shape factor of the filters to reduce latency.  The filters rock like they are now.  If we can achieve lower latency without changing the shape factor, that would be considered.

Some users request lower latency at the cost of filter shape. I, for one, am not satisfied with "filters rock as they are now" as a reason that no users can make that tradeoff. Sure, there are users saying, to paraphrase, "I cannot see why anyone would want that." But that does not reduce the number of contesters saying, "I won't use the Flex because the latency is too high." My own assessment, for now, is that I am getting too much delay in the Flex for the really snappy SSB QSOs that happen among the very best ops (which, by the way, does not include me, although I try to not slow them down when I work them.)

I haven't yet looked into the Waveform API's, but am willing to build my own filters to reduce latency if that is an option? (I appreciate any pointers.)

I limit my comments, for the moment to SSB. I have not done enough work to say anything about CW or RTTY contesting on the Flex.
Wayne

Mark Griffin

I am a K3 owner, but looking to purchase a Flex in the next 6 months or so. I am a day to day operator as well as I operate in the major contests. With my K3 I have 2 cw filters, a 250 Hz and 400 Hz 8 pole filters. For SSB I have a 2.8 Khz and 1.8 Khz 8 pole filters. These filters serve my needs very well for both kinds of operating. I realize that with the Flex you can have unlimited filter combinations. That is great, but in a nut shell how many filter alternatives does one need to operate?

From what I am reading here, it seems the issue with the latency delays is more software then hardware. If I had my choice, I would like to have less filters but a better latency time. Because it not only effects those who contest, but day to day operating also.

Charles - K5UA

Give me 1:1 shape factor filters or give me.........uh.....1.04 :1 shape factors.