Larry,

Many thanks for your information and suggstions.  Regarding offset, I'll 
play with that some more with your information in hand.

Regarding the data drop, your explanation fits what I am seeing reasonably 
well, though I am still trying to reconcile that with the fact that the 
current hour displays fine--the data must have gotten into the computer 
from the network OK.  It's just when the screen refreshes that roughly a 
minute of the previously collected data gets dropped.

If you look on your Current Seismicity page, you will see that the 
currently-writing line (which is now starting at 40 min after the hour) has 
no dropouts, but that same data will show a gap after my screen has been 
redrawn to start a new line.

I may think about increasing the XP  TCP/IP buffer to allow it to absorb 
the roughly 200k which can arrive during redraw.  No idea if that can be 
done, or how to do it, or if it's the right answer, but expect I'll be able 
to find something on line.

We would prefer to maintain the data rate if we can.  We want to gather as 
much information on how the instruments are working as possible.  I suppose 
we can drop the rate if there's no other answer.

Thanks again,
Brett

At 07:41 PM 8/18/2009 -0700, you wrote:
>Brett,
>
>>Hi All,
>>I have been trying to provide calibration data for our 24-hour displays, 
>>by going to Settings > Channel Control > DC Offset, putting in a number, 
>>then watching how far the trace moves up/down.  Knowing the instrument 
>>sensitivity per count, I can translate that into velocity units per 
>>line.  I had been assuming that the number I was entering for the DC 
>>Offset is always representing counts, but now I am not so sure.
>>Does anyone know how that works?
>
>Looking at the code the offset is applied to the A/D count and then 
>divided by a
>number to get the trace to show up in the right Y location depending on 
>the Y Scale.
>Here's the code:
>
>yLoc = lineOffset + -( ( adcData + dcOffset ) / divScale );
>
>>BTW I am getting frequent short data dropouts in the output display.  I 
>>have tracked that down to the possibility that I don't have enough RAM 
>>(512MB) and am planning to add some more to see if that makes things better.
>
>Adding more memory may help, but you might be trying to displaying too 
>many data
>points. As WinSDR draws the screen it is not reading the TCP/IP packets 
>for the
>network stack so you will loose data if it takes to long to draw the screen.
>
>Regards,
>Larry Cochrane
>Redwood City, PSN

Watch our wiggles
http://bnordgren.org/seismo/gif_images.htm

or watch some very very good wiggles
http://aslwww.cr.usgs.gov/Seismic_Data/telemetry_data/ANMO_24hr.html


__________________________________________________________

Public Seismic Network Mailing List (PSN-L)