<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19120">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff text=#000000>
<DIV><FONT size=2 face=Arial>Hi Riho,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>You may care to do some tests on you system using 
KISS Konsole since I suspect you are dropping packets between the PC and HPSDR 
hardware.  If you are only losing the odd packet then you are not going to 
hear them.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>The Metis Ethernet code has a packet number 
included in each data frame both to and from the PC. KK will indicate if a  
packet is lost and what the expected and received  packet numbers 
are.  Similarly Metis will light a LED if it misses a packet.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Using KK with Metis at 192ksps I have never seen a 
missed packet in either direction - in fact I had to deliberately send incorrect 
packet numbers to check the code was working!</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>I'm also currently doing some work that involves 
time stamping the data from Mercury via Metis - again no dropped packets. 
</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>The PC has absolutely no idea what the sample rate 
is of the data it is being sent. It's not acceptable that an SDR can't be used 
for DRM, SSTV etc - this needs to be investigated and corrected.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>73 Phil...VK6APH </FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px" 
dir=ltr>
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> 
  <A title=es7aaz@gmail.com href="mailto:es7aaz@gmail.com">Riho B., ES7AAZ</A> 
  </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=hpsdr@lists.openhpsdr.org 
  href="mailto:hpsdr@lists.openhpsdr.org">hpsdr@lists.openhpsdr.org</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Saturday, October 01, 2011 6:00 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [hpsdr] about latency growth 
  with HPSDR</DIV>
  <DIV><BR></DIV>***** High Performance Software Defined Radio Discussion List 
  *****<BR><BR>
  <P>
  <HR>

  <P></P>Steve,<BR><BR>It may be right that SDR is not capable to run time 
  sensitive applications.<BR>I was scoping 10Mhz WWV today, output shows that 
  real time/SDR time<BR>varies, escpecially while minimizing and maximizing 
  PowerSDR window<BR>which causes higher CPU load. IIt was @ 48kHz sampling 
  rate  all over<BR>the path, biggest buffers, no audioble drop-outs, max 
  DPC latency 170<SPAN 
  style="WIDOWS: 2; TEXT-TRANSFORM: none; BACKGROUND-COLOR: rgb(255,255,255); TEXT-INDENT: 0px; FONT: small/16px arial, sans-serif; WHITE-SPACE: normal; ORPHANS: 2; LETTER-SPACING: normal; COLOR: rgb(34,34,34); WORD-SPACING: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px" 
  class=Apple-style-span>μs.<BR>Anyway, it's now clear why's there are drop-outs 
  while listening DRM, why's<BR>there are out of sync line blocks in SSTV, why's 
  digital SSTV misses the blocks.<BR>I'm not struggling with it anymore. All the 
  other, CW and SSB works just fine.<BR><BR><BR><BR><BR><BR>73's,<BR>Riho, 
  ES7AAZ.<BR></SPAN><BR><BR>29.09.2011 23:56, Steve Bunch kirjutas: 
  <BLOCKQUOTE cite=mid:198ED828-6C7C-4EEF-8C71-094E5905EBBE@ameritech.net 
  type="cite">Riho, 
    <DIV><BR></DIV>
    <DIV>I can't answer your question exactly, but this can happen because of 
    buffering somewhere in your sample chain, when the sampling rate of your 
    system is slightly slower than realtime so the samples aren't being consumed 
    as fast as they're generated.  The unread samples are saved up 
    somewhere, and accumulate there.  I had this happening to me in an 
    ALSA-based Linux system -- I would over time be listening several seconds 
    behind realtime when using a USRP to listen to FM radio.  Restarting 
    the chain will clear out the buffered data; when you restart it will grow 
    again.  </DIV>
    <DIV><BR></DIV>
    <DIV>I don't know if the Ozy/Mercury sample chain is capable of buffering 
    this much data (someone familiar with it should be able to tell you exactly 
    how much can be buffered there), but in my case it was in my audio 
    system.  Unfortunately, I don't know the various Windows audio 
    systems well enough to give you any help, but that is where I would look 
    first.</DIV>
    <DIV><BR></DIV>
    <DIV>Steve, K9SRB</DIV>
    <DIV><BR>
    <DIV>
    <DIV>On Sep 29, 2011, at 3:07 AM, Riho B., ES7AAZ wrote:</DIV><BR 
    class=Apple-interchange-newline>
    <BLOCKQUOTE type="cite">***** High Performance Software Defined Radio 
      Discussion List *****<BR><BR>
      <DIV text="#000000" bgcolor="#FFFFFF">Hi,<BR><BR>I have a program called 
      Faros which is a beacon monitor.<BR>Faros gets his time sync from ntp GPS 
      time servers.<BR><SPAN class=apple-style-span><SPAN 
      style="FONT-FAMILY: 'Tahoma','sans-serif'; BACKGROUND: #fcfaea; FONT-SIZE: 10.5pt">NCDXF</SPAN></SPAN> 
      network beacons have GPS dicsiplined controller<BR>which allows path delay 
      calculation and Faros does it.<BR><BR>After 2h running I see 120ms latency 
      growth (linear graph)<BR>and it's growing on. Which means that radio waves 
      are traveling<BR>about one  more circle around the world. It can't be 
      so. Restarting<BR>PowerSDR brings the latency back to its initial state. 
      Exactly the same <BR>effect with CWSkimmer console. It's almost same vith 
      VAC and with<BR>analog audio cable.<BR><BR>The question is not even about 
      latency itself or how much it is.<BR>The question is why's latency growing 
      and how much it does?<BR> Is it somewhere in USB connection ?  
      I'm Ozy user.<BR><BR><BR><BR>73,<BR>Riho, 
      ES7AAZ<BR></DIV>_______________________________________________<BR>HPSDR 
      Discussion List<BR>To post msg: <A href="mailto:hpsdr@openhpsdr.org" 
      moz-do-not-send="true">hpsdr@openhpsdr.org</A><BR>Subscription help: <A 
      href="http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org" 
      moz-do-not-send="true">http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org</A><BR>HPSDR 
      web page: <A href="http://openhpsdr.org" 
      moz-do-not-send="true">http://openhpsdr.org</A><BR>Archives: <A 
      href="http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/" 
      moz-do-not-send="true">http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/</A></BLOCKQUOTE></DIV><BR></DIV></BLOCKQUOTE><BR>
  <P>
  <HR>

  <P></P>_______________________________________________<BR>HPSDR Discussion 
  List<BR>To post msg: hpsdr@openhpsdr.org<BR>Subscription help: 
  http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org<BR>HPSDR web page: 
  http://openhpsdr.org<BR>Archives: 
  http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
  <P>
  <HR>

  <P></P><A></A>
  <P class=avgcert align=left color="#000000">No virus found in this 
  message.<BR>Checked by AVG - <A 
  href="http://www.avg.com">www.avg.com</A><BR>Version: 10.0.1410 / Virus 
  Database: 1520/3929 - Release Date: 09/30/11</P></BLOCKQUOTE></BODY></HTML>