Hello Larry and Thanks for your answers;

One other complex question which also may seem silly to you.

Does your program invent a new time for imaginary
(thoughts of the mind and not a math number)
samples that would through the human imagination be a
START AT an exact second then the program create its own samples
by the numbers from start to end ?

This means to me the samples magnitudes being displayed are not the
same as the samples magnitudes which were taken.

Your program would then be creating a new set of imaginary samples
and not using the originals. This means an adjustment to
the overall picture in time. (shifting the entire picture ever so slightly)
Otherwise the very first sample time instant (sample zero) would
have to be identicle to the one given by the supplier
of the data.

Im not sure exactly how to test this
but i may pursue it simply to satisfy
my own curiosity by inventing artificial data sets.

To me it appears you are NOT adjusting the picture
because your samples seem to possess the very same magnitudes
of the original samples provided to the program?

If you were adjusting the overall picture the
magnitudes would be a count or two in difference
from the originals ?

Comment please, Im not trying to cause you troubles
just to understand without knowing your source code.


Suggestion for winquake program:
I have an FFT like waterfall display Id like to
let you see and comment on for the latest
california quake just received.
Time is thirty minutes and freq is like 4.5 Hz.

http://gmvoeth.home.mchsi.com/091103_105436_FFT.BMP

time left to right, past to present 30 minutes
freq bottom to top, low to high 4.5 Hz


It would be nice if your program could display data in this way.

Regards;
geoff

----- Original Message ----- 
From: "Larry Cochrane" 
To: 
Sent: Monday, November 02, 2009 8:52 PM
Subject: Re: WINQUAKE QUESTION ABOUT HEADER INFO


> Geoff,
> 
> This has been discussed before. WinQuake skips the first few samples in the event 
> file so that the display starts at the top of the first second. This is only done if 
> there is a fraction of a second in the nanosecond start time field.
> 
> > A. Put the fraction 0.151 into the nanoseconds variable times one billion
> 
> This is the correct way of doing this. Since the nanosecond field is a 32 bit long 
> you will need to multiply .151 times one billion and place the integer result into 
> the nanosecond field.
> 
> Regards,
> Larry Cochrane
> Redwood City, PSN
> 
> Geoffrey wrote:
>> Hello Folks;
>> 
>> Please bear with me here I know you do not like to hear this
>> but it will help me decide how to finish my program.
>> 
>> I am rewriting my recording and display programs
>> to use 12 bits instead of 8 to avoid saturation problems.
>> In my display program I create a PSN4 file to be able to
>> read times in winquake and share with the rest of you.
>> I am having problems getting WINQUAKE to properly
>> show the time of the very first sample since
>> MY first sample can be something OTHER than
>> an exact second and usually has a fraction.
>> 
>> There are two Items in the header that affect time readings
>> And I'm wondering how to properly use them.
>> 
>> WINQUAKE TYPE4 HEADER DATA
>> GIVEN: FIRST SAMPLE TIME 00:00:35.151
>>        Hour?    == 00  byte value 0 to 23
>>        Minute?  == 00  byte value 0 to 59
>>        Seconds? == 35  byte value 0 to 59
>>        SPACE HOLDER?   byte value 0
>>        NANOseconds&    LONG signed integer value 4 bytes low endean
>>        0 to 999,999,999
>>        OFFSETseconds#  DOUBLE floating point value  8 bytes IEEE
>> 
>> 
>> Find: What is the proper way to indicate
>>       the fractional value which remains ?
>> 
>> A. Put the fraction 0.151 into the nanoseconds variable times one billion
>> B. Put the fraction 0.151 into the offset area following the nanoseconds area
>> C. CROP the recorded DATA to start at an exact second
>> D. THERE IS NO WAY TO GET THE FIRST SAMPLE TO SHOW THE PROPER FRACTIONAL VALUE
>> 
>> What's the best answer here ?
>> 
>> I know if I crop the file to an exact cal mark second
>> I get pretty good fractional times. I am guessing
>> this may be the best way to go since I may be using
>> WQ in ways it was not designed to be used.
>> This will mean saving 4 minutes of modulo history
>> instead of three. I do not want to do this
>> unless absolutely necessary.
>> 
>> When I look at my own data I will assign
>> discreet date-times UTC to each sample
>> relative to a given calibration mark
>> and not guess between samples.
>> The cal sample happens at the transition
>> between second 59 and second zero the first
>> sample after this event and I call that the
>> exact second and calculate all other sample times
>> from that one reference point.
>> WINQUAKE works different, possibly better,
>> I just need to understand it better.
>> The times I use are in the WINQUAKE "?"
>> type relating to synchronization with WWV
>> radio broadcast.
>> 
>> Thanks for answers,
>> geoff
>> 
>> ps, I have found lots of errors in my older program
>> leading to not so good time readings in the past.
>> Every time I do this, the results seem better
>> than before.
>> But now I'm reaching the point of diminishing returns.
>> 
>> 
>> __________________________________________________________
>> 
>> Public Seismic Network Mailing List (PSN-L)
>> 
>> To leave this list email PSN-L-REQUEST@.............. with 
>> the body of the message (first line only): unsubscribe
>> See http://www.seismicnet.com/maillist.html for more information.
>> 
> __________________________________________________________
> 
> Public Seismic Network Mailing List (PSN-L)
> 
> To leave this list email PSN-L-REQUEST@.............. with 
> the body of the message (first line only): unsubscribe
> See http://www.seismicnet.com/maillist.html for more information.
>
__________________________________________________________

Public Seismic Network Mailing List (PSN-L)