<div dir="ltr">Keith,<div><br></div><div>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. </div><div><br></div><div>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?</div><div><br></div><div>Thanks & 73,</div><div><br></div><div>Scott</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 8, 2015 at 12:04 PM, Keith Ennis <span dir="ltr"><<a href="mailto:nelasat@yahoo.com" target="_blank">nelasat@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="color:#000;background-color:#fff;font-family:HelveticaNeue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"><div><span></span></div><div></div><div dir="ltr">Scott,</div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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</div><div dir="ltr"><br></div><div><div>Keith, KV5J, XE3/K5ENS</div></div> <br><div><br><br></div><div style="display:block"> <div style="font-family:HelveticaNeue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div dir="ltr"> <font face="Arial"> On Wednesday, April 8, 2015 10:21 AM, Scott Traurig <<a href="mailto:scott.traurig@gmail.com" target="_blank">scott.traurig@gmail.com</a>> wrote:<br> </font> </div> <br><br> <div><div><div><div dir="ltr">Keith,<div><br clear="none"></div><div>First of all let me just say that that is phenomenal. I have no idea how you top contesters do it.</div><div><br clear="none"></div><div>Your configuration would imply a receive-to-transmit latency of about 140 to 150mS based on current software performance.</div><div><br clear="none"></div><div>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!</div><div><br clear="none"></div><div>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.</div><div><br clear="none"></div><div>Thanks & 73!</div><div><br clear="none"></div><div>Scott/w-u-2-o</div><div><br clear="none"></div><div>P.S. Fabulous place you have down there in Mexico. I've been to Cancun and Coz for diving, it's a great area.</div><div><div><br clear="none"><div>On Wed, Apr 8, 2015 at 10:15 AM, Keith Ennis <span dir="ltr"><<a href="mailto:nelasat@yahoo.com" rel="nofollow" shape="rect" target="_blank">nelasat@yahoo.com</a>></span> wrote:<br clear="none"><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div><div style="color:rgb(0,0,0);font-family:HelveticaNeue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px;background-color:rgb(255,255,255)"><div><span></span></div><div></div><div dir="ltr">Scott,</div><div dir="ltr"><br clear="none"></div><div dir="ltr">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.".</div><div dir="ltr">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:</div><div dir="ltr"><br clear="none"></div><div dir="ltr">1st place in Mexico</div><div dir="ltr">1st place is North America</div><div dir="ltr">4th place in the World</div><div dir="ltr"><br clear="none"></div><div dir="ltr">I was entered in single operate assisted LP 10 meters.</div><div dir="ltr">Scores were:</div><div dir="ltr"><br clear="none"></div><div dir="ltr">794,240 points</div><div dir="ltr">2,284 QSO's</div><div dir="ltr">Total time on air: 25.1 hours</div><div dir="ltr"><br clear="none"></div><div dir="ltr">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. </div><div dir="ltr"><br clear="none"></div><div dir="ltr"><br clear="none"></div><div><div>Keith, KV5J, XE3/K5ENS</div></div> <br clear="none"><div><br clear="none"><br clear="none"></div><div style="display:block"> <div style="font-family:HelveticaNeue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:16px"> <div dir="ltr"> <font face="Arial"> On Wednesday, April 8, 2015 12:47 AM, Scott Traurig <<a href="mailto:scott.traurig@gmail.com" rel="nofollow" shape="rect" target="_blank">scott.traurig@gmail.com</a>> wrote:<br clear="none"> </font> </div> <br clear="none"><br clear="none"> <div><div><div dir="ltr">You are not missing anything. Latency is an inevitable trade-off associated with digital signal processing.<div><br clear="none"></div><div>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.<div><br clear="none"></div><div>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.</div><div><br clear="none"></div><div>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.</div><div><br clear="none"></div><div>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.</div><div><br clear="none"></div><div>73!</div><div><br clear="none"></div><div>Scott/w-u-2-o</div></div></div><div><br clear="none"><div>On Sun, Apr 5, 2015 at 6:54 AM, G3XJP <span dir="ltr"><<a href="mailto:G3XJP@rhodesg3xjp.plus.com" rel="nofollow" shape="rect" target="_blank">G3XJP@rhodesg3xjp.plus.com</a>></span> wrote:<br clear="none"><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">***** High Performance Software Defined Radio Discussion List *****<br clear="none">
<br clear="none">
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<br clear="none">
______________________________<u></u>_________________<br clear="none">
HPSDR Discussion List<br clear="none">
To post msg: <a href="mailto:hpsdr@openhpsdr.org" rel="nofollow" shape="rect" target="_blank">hpsdr@openhpsdr.org</a><br clear="none">
Subscription help: <a href="http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org" rel="nofollow" shape="rect" target="_blank">http://lists.openhpsdr.org/<u></u>listinfo.cgi/hpsdr-openhpsdr.<u></u>org</a><br clear="none">
HPSDR web page: <a href="http://openhpsdr.org/" rel="nofollow" shape="rect" target="_blank">http://openhpsdr.org</a><br clear="none">
Archives: <a href="http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/" rel="nofollow" shape="rect" target="_blank">http://lists.openhpsdr.org/<u></u>pipermail/hpsdr-openhpsdr.org/</a><br clear="none">
</blockquote></div><br clear="none"></div></div><br clear="none">***** High Performance Software Defined Radio Discussion List *****<br clear="none"><br clear="none"><br clear="none">_______________________________________________<br clear="none">HPSDR Discussion List<br clear="none">To post msg: <a href="mailto:hpsdr@openhpsdr.org" rel="nofollow" shape="rect" target="_blank">hpsdr@openhpsdr.org</a><br clear="none">Subscription help: <a href="http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org" rel="nofollow" shape="rect" target="_blank">http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org</a><br clear="none">HPSDR web page: <a href="http://openhpsdr.org/" rel="nofollow" shape="rect" target="_blank">http://openhpsdr.org</a><br clear="none">Archives: <a href="http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/" rel="nofollow" shape="rect" target="_blank">http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/</a><br clear="none"><br clear="none"></div> </div> </div> </div></div></div></blockquote></div><br clear="none"></div></div></div></div></div><br><br></div> </div> </div> </div></div></div></blockquote></div><br></div>