[hpsdr] FFT latency

Wed Apr 8 10:13:47 PDT 2015

Keith,

I have to say I love the panadapter, panafall actually, for everything. I
don't use a tuning knob, just click on a signal and roll the mouse wheel
for fine tune, not that fine tune is usually necessary. You can check every
signal in the band in no time flat! Can't be beat for contesting or DX.

It's a little off topic, so please forgive the thread drift, but do you use
a tuning wheel or Hercules Midi controller for contesting?

Thanks & 73,

Scott

On Wed, Apr 8, 2015 at 12:04 PM, Keith Ennis <nelasat at yahoo.com> wrote:

> Scott,
>
> Thanks for the comments.  Being at he top of the list as a contester is
> not easy.  It requires a lot more than a great radio.  But if we just talk
> about the ANAN-100D as a contest radio, it adds the visual pluses of a
> great panadapter. For me to be able to see all that is happening on the
> bands is a huge plus.
>
> Your comment about making the DSP buffers smaller may reduce the latency
> but this is negatively changing the filter.  Having brickwall filters is
> more important than zero latency.  To better the radio for contesting I
> need to be able to increase the buffer size to sharpen the filters.
>
> My contesting style is to "run" on a single frequency most of the time.
> So I need  to be able to block all the close signals.  My ideal setup would
> be with the DPS buffers at max.  That adds way to much latency.  And weak
> signal work in way down the list.  To make the kind of QSO's required to
> place high I don't have time to spend asking for several repeats of call
> sign.  Every contact is important but I need to work the loudest first and
> move down the pileup.
>
> So for me I need sharp filters first then as small of a latency time as I
> can operate with.  I am waiting for the day I get both.  hihihi
>
> Keith, KV5J, XE3/K5ENS
>
>
>
>   On Wednesday, April 8, 2015 10:21 AM, Scott Traurig <
> scott.traurig at gmail.com> wrote:
>
>
> Keith,
>
> First of all let me just say that that is phenomenal. I have no idea how
> you top contesters do it.
>
> Your configuration would imply a receive-to-transmit latency of about 140
> to 150mS based on current software performance.
>
> I am not a contester per se, but I have tried my hand at it a little, most
> recently during the CQ WPX contest the other week, using a configuration
> that provides about 200mS of latency. That contest seemed to have a little
> more of a relaxed pace and the contacts came easy.  However I tried to play
> in the NA SSB Sprint last September at the same latency and literally could
> barely get a contact in edgewise. That contest had some pretty fast talkers!
>
> At any rate, no doubt as a champion contester you have proven it is
> possible beyond any shadow of a doubt. Nevertheless you might try using
> some smaller DSP buffer sizes on the next one and let us all know what you
> think as to whether or not it improves things for you. Certainly the radio
> has more than adequate RF performance at smaller buffer sizes.
>
> Thanks & 73!
>
> Scott/w-u-2-o
>
> P.S. Fabulous place you have down there in Mexico. I've been to Cancun and
> Coz for diving, it's a great area.
>
> On Wed, Apr 8, 2015 at 10:15 AM, Keith Ennis <nelasat at yahoo.com> wrote:
>
> Scott,
>
> I feel I need to make a statement in response to your comment "I have
> noticed, however, that 200mS seems to be *far* too much for contesting,
> where everyone is speaking so fast one can barely get a word in edgewise.".
> I have contested many times from my QTH here in Mexico.  I used a Elecraft
> K3 for about 5 years.  Last year in the CQ WW DX phone contest I switched
> to my ANAN-100D for this contest.  I have done nothing special other than
> set the main sample rate to 96000 and buffer to 512.  The DSP is set at
> sample rate RX 1024 TX 2048.  Heil headset plugged into the front panel.
> Using N1MM Logger+ with VAC1 for DVK.  My results were:
>
> 1st place in Mexico
> 1st place is North America
> 4th place in the World
>
> I was entered in single operate assisted LP 10 meters.
> Scores were:
>
> 794,240 points
> 2,284 QSO's
> Total time on air: 25.1 hours
>
> My hopes are some day everyone will stop stating you can not contest with
> an SDR radio.  I frequency have rates of over 200 per hour.  The ANAN-100D
> is a fine contesting radio. I have sold my "contest" Elecraft K3 and plan
> to use my ANAN-100D for all my contesting.
>
>
> Keith, KV5J, XE3/K5ENS
>
>
>
>   On Wednesday, April 8, 2015 12:47 AM, Scott Traurig <
> scott.traurig at gmail.com> wrote:
>
>
> You are not missing anything. Latency is an inevitable trade-off
> associated with digital signal processing.
>
> To use the ANAN series of (Hermes based) radios as an example, transmit
> audio latency has been characterized to be approx. 40mS *before* any
> additional delays caused by the Phone DSP Buffer size setting. This is
> because audio must be digitized, sent over the Ethernet to the PC,
> processed by the openHPSDR software, then sent back to the radio over
> Ethernet. If the VAC facility in openHPSDR is used to obtain transmit audio
> rather than the front panel microphone connector, this latency can range
> from 40mS using ASIO sound drivers to 2 to 3 times that for Windows sound
> drivers.
>
> The Phone DSP Buffer (a misnomer, this is really the length of the audio
> passband FIR filter) will add additional delay that is equal to the buffer
> size divided by sample rate. As the internal audio sample rate in that
> section is 48KHz, this can add an additional delay of between 5.3mS for a
> buffer size of 256 and 341.3mS for a buffer size of 16384. Larger buffer
> sizes (larger FIR filters) produce sharper passband filter skirts.
>
> Most ANAN operators use a DSP Phone Buffer size of 1024 or 2048 to achieve
> passband filters skirts that are already very sharp at that filter size.
> They thereby experiencing a total transmit latency of approx. 62 or 83mS
> (including the baseline 40mS) depending on the buffer size selected. One
> can expect similar latency on the receive side, for a total receive to
> transmit latency of say, conservatively, 160mS. This does approach your
> suggested 1/5 second limit, and it is certainly noticeable.
>
> Operators who use digital audio workstation software to process their
> transmit audio can see additional transmit side delays in the range of
> 50mS, pushing the total receive-to-transmit latency right up against the
> suggested 200mS "comfort factor". There are many who do this, including
> myself. It is something that you get used to and it does not substantially
> affect break-in style multi-way QSOs, but it is noticeable. Obviously in
> nets and roundtables this is not an issue. It's not even that big an issue
> for DX pile-ups. I have noticed, however, that 200mS seems to be *far* too
> much for contesting, where everyone is speaking so fast one can barely get
> a word in edgewise. In this latter case the solution is to trade-off
> sharper passband filter skirts for speed and reduce the DSP Phone Buffers
> to 256, and perhaps also bypass external audio processing, if used. In the
> ANAN using Puresignal linearization this can be done with relative impunity
> on the transmit side, as linearization effectively creates a sharp cut-off
> on the transmit passband compared to non-linearized implementations.
>
> 73!
>
> Scott/w-u-2-o
>
> On Sun, Apr 5, 2015 at 6:54 AM, G3XJP <G3XJP at rhodesg3xjp.plus.com> wrote:
>
> ***** High Performance Software Defined Radio Discussion List *****
>
> I need your collective wisdom!  Is it not an inescapable fact that any
> serious FFT in the real-time path between your antenna and your ears must
> introduce an inherent and inevitable delay that will preclude a
> conversational VOX/QSK QSO?  I can see that it would not preclude listening
> to a monologue - or to watching spectral pictures on a display.  But
> anything more than about 1/5 sec is doomed to feel like Skype on a bad day
> - where you often end up having to say "over".  As a generality, am I
> missing something fundamental here?  Peter G3XJP
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/
> listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>
>
>
> ***** High Performance Software Defined Radio Discussion List *****
>
>
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help:
> http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/attachments/20150408/b86c3da6/attachment-0003.htm>