Hi, 
Guest
Pic
Sign In

time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

Archiving Data

PS
paul swed
Sat, Jan 8, 2011 2:33 PM

Loran c was complicated by the fact that there were phase reversals in the
patterns that had to be emulated it doubled the size of the code. But to
answer your question John its all done in simple readable basic language.
Think of it as a endless loop pattern. The real trick is using a good
reference. I think Magnus said 10 KC. What you do is count the 10 KC
reference. Using a Parallax SXB chip that can run all the way up to 80 Mhz.
The code runs so fast that 99.9% of the time the micro is just waiting and
counting edges.
I like to create dumb simple stupid, reliable as heck programs like that.
The Loran C sim allows the Austrons to compare to their limit of 1 e -13.
There is a bit more cleverness in the C simulator external to the program.

I thought there were different frequencies at about 1.8 Mhz.

I remember the gone-ometer (I still think thats a disease sailors can get),
green crt black box about 2 ft tall.
If you really wanted to do a location you might need 2 or 3 chips at
different GRIs and phases. But at $3.56 not a really big deal. Lastly there
must be some overall sync relationship between the chains that has to be
maintained I might guess.

Oddly enough I emailed the group several times at the ship and never
received a response.
Figured they were all set.
Regards
Paul.

On Sat, Jan 8, 2011 at 1:27 AM, Magnus Danielson <magnus@rubidium.dyndns.org

wrote:

On 08/01/11 06:54, Magnus Danielson wrote:

John,

On 08/01/11 05:04, J. Forster wrote:

Magnus,

See my post of a few minutes ago.

The GRI and Delay counters need to be 5 decimal digits. My current
thinking is manual entry of the numbers via BCD coded thumbwheel
switches.

If you only need a static location that will be fine. Naturally you tune
it up to the ships current (final?) position. Good exercise for the
visitors. :)

LORAN-A has 24 possible GRIs; in three blocks of 33 PPS; 25 PPS; and 20

PPS. It also has 4 RF frequencies.

I did a fashinating read-up here:
http://www.jproc.ca/hyperbolic/loran_a.html

GRI is a LORAN-C term if I get it correctly, where as PRR is used
together with frequency indication in LORAN-A.

Pondering some more on this, doing some calculations (spread-sheets) the
actual scheme emerge... the range of 0 to 7 is not selected by accident.

The base pulse repetition rate is 30 ms, 40 ms and 50 ms. The pulse
repetition rate modifiers modifies the repetition rate by -100 us per step.
It would only take two (or possibly three) wheels to select PRR.
This explains the high rate starts with 33 3/9... it also makes the
receiver design easier to understand.

So a 10 kHz source would suffice for PRR settings. A phantastron divider
from a 100 kHz standard should do it in those days technology, if not a 10
kHz standard was used directly.

Only the delayed pulse would need the full set of thumb-wheels.

Cheers,
Magnus

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Loran c was complicated by the fact that there were phase reversals in the patterns that had to be emulated it doubled the size of the code. But to answer your question John its all done in simple readable basic language. Think of it as a endless loop pattern. The real trick is using a good reference. I think Magnus said 10 KC. What you do is count the 10 KC reference. Using a Parallax SXB chip that can run all the way up to 80 Mhz. The code runs so fast that 99.9% of the time the micro is just waiting and counting edges. I like to create dumb simple stupid, reliable as heck programs like that. The Loran C sim allows the Austrons to compare to their limit of 1 e -13. There is a bit more cleverness in the C simulator external to the program. I thought there were different frequencies at about 1.8 Mhz. I remember the gone-ometer (I still think thats a disease sailors can get), green crt black box about 2 ft tall. If you really wanted to do a location you might need 2 or 3 chips at different GRIs and phases. But at $3.56 not a really big deal. Lastly there must be some overall sync relationship between the chains that has to be maintained I might guess. Oddly enough I emailed the group several times at the ship and never received a response. Figured they were all set. Regards Paul. On Sat, Jan 8, 2011 at 1:27 AM, Magnus Danielson <magnus@rubidium.dyndns.org > wrote: > On 08/01/11 06:54, Magnus Danielson wrote: > >> John, >> >> On 08/01/11 05:04, J. Forster wrote: >> >>> Magnus, >>> >>> See my post of a few minutes ago. >>> >>> The GRI and Delay counters need to be 5 decimal digits. My current >>> thinking is manual entry of the numbers via BCD coded thumbwheel >>> switches. >>> >> >> If you only need a static location that will be fine. Naturally you tune >> it up to the ships current (final?) position. Good exercise for the >> visitors. :) >> >> LORAN-A has 24 possible GRIs; in three blocks of 33 PPS; 25 PPS; and 20 >>> PPS. It also has 4 RF frequencies. >>> >> >> I did a fashinating read-up here: >> http://www.jproc.ca/hyperbolic/loran_a.html >> >> GRI is a LORAN-C term if I get it correctly, where as PRR is used >> together with frequency indication in LORAN-A. >> > > Pondering some more on this, doing some calculations (spread-sheets) the > actual scheme emerge... the range of 0 to 7 is not selected by accident. > > The base pulse repetition rate is 30 ms, 40 ms and 50 ms. The pulse > repetition rate modifiers modifies the repetition rate by -100 us per step. > It would only take two (or possibly three) wheels to select PRR. > This explains the high rate starts with 33 3/9... it also makes the > receiver design easier to understand. > > So a 10 kHz source would suffice for PRR settings. A phantastron divider > from a 100 kHz standard should do it in those days technology, if not a 10 > kHz standard was used directly. > > Only the delayed pulse would need the full set of thumb-wheels. > > > Cheers, > Magnus > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. >
JF
J. Forster
Sat, Jan 8, 2011 3:00 PM

John,

On 08/01/11 05:04, J. Forster wrote:

Magnus,

See my post of a few minutes ago.

The GRI and Delay counters need to be 5 decimal digits. My current
thinking is manual entry of the numbers via BCD coded thumbwheel
switches.

If you only need a static location that will be fine. Naturally you tune
it up to the ships current (final?) position. Good exercise for the
visitors. :)

True, and that's the plan. The TDs would vary very slowly when the ship is
underway anyway. Not something a visitor would really notice. Roughly, the
TDs change a microsecond for every 1/5 mile.

Clearly, if the TDs were settable from an external 'puter, a manovercould
be simulated, but visitors don't get to twiddle knobs (they steal them),
so a static display is probably best.

LORAN-A has 24 possible GRIs; in three blocks of 33 PPS; 25 PPS; and 20
PPS. It also has 4 RF frequencies.

I did a fashinating read-up here:
http://www.jproc.ca/hyperbolic/loran_a.html

Yes, Jerry's site is very good on many things like LORAN and radios and
crypto.

GRI is a LORAN-C term if I get it correctly, where as PRR is used
together with frequency indication in LORAN-A.

You got me! Yes. GRI = 1/PRF. I prefer to deal with microseconds than 1/9
CPS.

Currently I plan only one Slave, but a second would be an easy addition.

Indeed. Considering the chain that used to be there, you could allow for
two chains to be setup on the same frequency (1H chains).

Cheers,
Magnus

Right. Thanks,

-John

============

> John, > > On 08/01/11 05:04, J. Forster wrote: >> Magnus, >> >> See my post of a few minutes ago. >> >> The GRI and Delay counters need to be 5 decimal digits. My current >> thinking is manual entry of the numbers via BCD coded thumbwheel >> switches. > > If you only need a static location that will be fine. Naturally you tune > it up to the ships current (final?) position. Good exercise for the > visitors. :) True, and that's the plan. The TDs would vary very slowly when the ship is underway anyway. Not something a visitor would really notice. Roughly, the TDs change a microsecond for every 1/5 mile. Clearly, if the TDs were settable from an external 'puter, a manovercould be simulated, but visitors don't get to twiddle knobs (they steal them), so a static display is probably best. >> LORAN-A has 24 possible GRIs; in three blocks of 33 PPS; 25 PPS; and 20 >> PPS. It also has 4 RF frequencies. > > I did a fashinating read-up here: > http://www.jproc.ca/hyperbolic/loran_a.html Yes, Jerry's site is very good on many things like LORAN and radios and crypto. > GRI is a LORAN-C term if I get it correctly, where as PRR is used > together with frequency indication in LORAN-A. You got me! Yes. GRI = 1/PRF. I prefer to deal with microseconds than 1/9 CPS. >> Currently I plan only one Slave, but a second would be an easy addition. > > Indeed. Considering the chain that used to be there, you could allow for > two chains to be setup on the same frequency (1H chains). > > Cheers, > Magnus Right. Thanks, -John ============ > >
JF
J. Forster
Sat, Jan 8, 2011 3:28 PM

Loran c was complicated by the fact that there were phase reversals in the
patterns that had to be emulated it doubled the size of the code. But to
answer your question John its all done in simple readable basic language.
Think of it as a endless loop pattern. The real trick is using a good
reference. I think Magnus said 10 KC. What you do is count the 10 KC
reference. Using a Parallax SXB chip that can run all the way up to 80
Mhz.
The code runs so fast that 99.9% of the time the micro is just waiting

and counting edges.

OK. Thanks. You talk to the uP with a dumb terminal program?

I like to create dumb simple stupid, reliable as heck programs like that.
The Loran C sim allows the Austrons to compare to their limit of 1 e -13.
There is a bit more cleverness in the C simulator external to the
program.

I thought there were different frequencies at about 1.8 Mhz.

There are 3 between 1.8 and 2.0 MHz, one higher that was mostly unused.

I remember the gone-ometer (I still think thats a disease sailors can
get), green crt black box about 2 ft tall.

That's for a DF loop, no? Was that used on the LORAN receiver? If so,
that's news to me. The crossed roughly 4' loops were common on ships, but
I didn't think they were LORAN antennas.

If you really wanted to do a location you might need 2 or 3 chips at
different GRIs and phases. But at $3.56 not a really big deal. Lastly
there
must be some overall sync relationship between the chains that has to be
maintained I might guess.

I'm not sure about inter-chain sync, but IMO it does not matter much.

Oddly enough I emailed the group several times at the ship and never
received a response.
Figured they were all set.
Regards
Paul.

If you're interested, I can make sure you talk to the right person.

Best,

-John

===============

> Loran c was complicated by the fact that there were phase reversals in the > patterns that had to be emulated it doubled the size of the code. But to > answer your question John its all done in simple readable basic language. > Think of it as a endless loop pattern. The real trick is using a good > reference. I think Magnus said 10 KC. What you do is count the 10 KC > reference. Using a Parallax SXB chip that can run all the way up to 80 > Mhz. > The code runs so fast that 99.9% of the time the micro is just waiting and counting edges. OK. Thanks. You talk to the uP with a dumb terminal program? > I like to create dumb simple stupid, reliable as heck programs like that. > The Loran C sim allows the Austrons to compare to their limit of 1 e -13. > There is a bit more cleverness in the C simulator external to the > program. > > I thought there were different frequencies at about 1.8 Mhz. There are 3 between 1.8 and 2.0 MHz, one higher that was mostly unused. > I remember the gone-ometer (I still think thats a disease sailors can > get), green crt black box about 2 ft tall. That's for a DF loop, no? Was that used on the LORAN receiver? If so, that's news to me. The crossed roughly 4' loops were common on ships, but I didn't think they were LORAN antennas. > If you really wanted to do a location you might need 2 or 3 chips at > different GRIs and phases. But at $3.56 not a really big deal. Lastly > there > must be some overall sync relationship between the chains that has to be > maintained I might guess. I'm not sure about inter-chain sync, but IMO it does not matter much. > Oddly enough I emailed the group several times at the ship and never > received a response. > Figured they were all set. > Regards > Paul. If you're interested, I can make sure you talk to the right person. Best, -John ===============
PS
paul swed
Sat, Jan 8, 2011 3:33 PM

The goniometer that I remember was to allow a controlled phase change for
measurments. It was inside the rcvr.

On Sat, Jan 8, 2011 at 10:28 AM, J. Forster jfor@quik.com wrote:

Loran c was complicated by the fact that there were phase reversals in

the

patterns that had to be emulated it doubled the size of the code. But to
answer your question John its all done in simple readable basic language.
Think of it as a endless loop pattern. The real trick is using a good
reference. I think Magnus said 10 KC. What you do is count the 10 KC
reference. Using a Parallax SXB chip that can run all the way up to 80
Mhz.
The code runs so fast that 99.9% of the time the micro is just waiting

and counting edges.

OK. Thanks. You talk to the uP with a dumb terminal program?

I like to create dumb simple stupid, reliable as heck programs like that.
The Loran C sim allows the Austrons to compare to their limit of 1 e -13.
There is a bit more cleverness in the C simulator external to the
program.

I thought there were different frequencies at about 1.8 Mhz.

There are 3 between 1.8 and 2.0 MHz, one higher that was mostly unused.

I remember the gone-ometer (I still think thats a disease sailors can
get), green crt black box about 2 ft tall.

That's for a DF loop, no? Was that used on the LORAN receiver? If so,
that's news to me. The crossed roughly 4' loops were common on ships, but
I didn't think they were LORAN antennas.

If you really wanted to do a location you might need 2 or 3 chips at
different GRIs and phases. But at $3.56 not a really big deal. Lastly
there
must be some overall sync relationship between the chains that has to be
maintained I might guess.

I'm not sure about inter-chain sync, but IMO it does not matter much.

Oddly enough I emailed the group several times at the ship and never
received a response.
Figured they were all set.
Regards
Paul.

If you're interested, I can make sure you talk to the right person.

Best,

-John

===============

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

The goniometer that I remember was to allow a controlled phase change for measurments. It was inside the rcvr. On Sat, Jan 8, 2011 at 10:28 AM, J. Forster <jfor@quik.com> wrote: > > Loran c was complicated by the fact that there were phase reversals in > the > > patterns that had to be emulated it doubled the size of the code. But to > > answer your question John its all done in simple readable basic language. > > Think of it as a endless loop pattern. The real trick is using a good > > reference. I think Magnus said 10 KC. What you do is count the 10 KC > > reference. Using a Parallax SXB chip that can run all the way up to 80 > > Mhz. > > The code runs so fast that 99.9% of the time the micro is just waiting > and counting edges. > > OK. Thanks. You talk to the uP with a dumb terminal program? > > > I like to create dumb simple stupid, reliable as heck programs like that. > > The Loran C sim allows the Austrons to compare to their limit of 1 e -13. > > There is a bit more cleverness in the C simulator external to the > > program. > > > > I thought there were different frequencies at about 1.8 Mhz. > > There are 3 between 1.8 and 2.0 MHz, one higher that was mostly unused. > > > I remember the gone-ometer (I still think thats a disease sailors can > > get), green crt black box about 2 ft tall. > > That's for a DF loop, no? Was that used on the LORAN receiver? If so, > that's news to me. The crossed roughly 4' loops were common on ships, but > I didn't think they were LORAN antennas. > > > If you really wanted to do a location you might need 2 or 3 chips at > > different GRIs and phases. But at $3.56 not a really big deal. Lastly > > there > > must be some overall sync relationship between the chains that has to be > > maintained I might guess. > > I'm not sure about inter-chain sync, but IMO it does not matter much. > > > Oddly enough I emailed the group several times at the ship and never > > received a response. > > Figured they were all set. > > Regards > > Paul. > > If you're interested, I can make sure you talk to the right person. > > Best, > > -John > > =============== > > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. >
JF
J. Forster
Sat, Jan 8, 2011 3:36 PM

Paul, I see none on the prints. It may have been used on later receiver
designs.

Thanks,

-John

The goniometer that I remember was to allow a controlled phase change for
measurments. It was inside the rcvr.

Paul, I see none on the prints. It may have been used on later receiver designs. Thanks, -John ============= > The goniometer that I remember was to allow a controlled phase change for > measurments. It was inside the rcvr.
A
asmagal@fc.up.pt
Sat, Jan 8, 2011 5:25 PM

John,

Quoting "J. Forster" jfor@quik.com:

The GRI and Delay counters need to be 5 decimal digits. My current
thinking is manual entry of the numbers via BCD coded thumbwheel switches.

More than thirty years ago, I built a Rate Generator for LORAN-C
excatly according to the above principle. It is still wandering
at my junk box and is a three digit preset counter (3XSN7490)
a quad input decoding gate (SN7420) and the thumbwheel switches.

Using more or less the same principle there is also a six digit
delay resolving one microsecond.

They are very ancient designs but they work pretty well.

Best regards
Antonio
CT1TE

John, Quoting "J. Forster" <jfor@quik.com>: > > The GRI and Delay counters need to be 5 decimal digits. My current > thinking is manual entry of the numbers via BCD coded thumbwheel switches. > More than thirty years ago, I built a Rate Generator for LORAN-C excatly according to the above principle. It is still wandering at my junk box and is a three digit preset counter (3XSN7490) a quad input decoding gate (SN7420) and the thumbwheel switches. Using more or less the same principle there is also a six digit delay resolving one microsecond. They are very ancient designs but they work pretty well. Best regards Antonio CT1TE
JF
J. Forster
Sat, Jan 8, 2011 5:35 PM

That's just about what I want to do.

Best,

-John

========================

John,

Quoting "J. Forster" jfor@quik.com:

The GRI and Delay counters need to be 5 decimal digits. My current
thinking is manual entry of the numbers via BCD coded thumbwheel
switches.

More than thirty years ago, I built a Rate Generator for LORAN-C
excatly according to the above principle. It is still wandering
at my junk box and is a three digit preset counter (3XSN7490)
a quad input decoding gate (SN7420) and the thumbwheel switches.

Using more or less the same principle there is also a six digit
delay resolving one microsecond.

They are very ancient designs but they work pretty well.

Best regards
Antonio
CT1TE

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

That's just about what I want to do. Best, -John ======================== > John, > > Quoting "J. Forster" <jfor@quik.com>: > >> >> The GRI and Delay counters need to be 5 decimal digits. My current >> thinking is manual entry of the numbers via BCD coded thumbwheel >> switches. >> > > More than thirty years ago, I built a Rate Generator for LORAN-C > excatly according to the above principle. It is still wandering > at my junk box and is a three digit preset counter (3XSN7490) > a quad input decoding gate (SN7420) and the thumbwheel switches. > > Using more or less the same principle there is also a six digit > delay resolving one microsecond. > > They are very ancient designs but they work pretty well. > > Best regards > Antonio > CT1TE > > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > >
BC
Bob Camp
Sun, Jan 9, 2011 5:15 PM

Hi

I'm sitting here running data on a bunch of TBolts and the like. Might that data be useful to others - maybe. Could it be useful 100 years from not - doubtful. I have the ability to create enormous amounts of likely useless trivia. To me the burring the useful nugget in the mountain of trivia is the bigger issue. It's the librarian, not the library that we need more than ever.

Without a process for cataloging, indexing, and retrieving data - it's as good as lost. Finding and identifying data from a year or two back - forget it. Storage / duplication is (as mentioned in another post) is cheap and easy. Indexing and cataloging is what makes sure the stuff is retained and useful.

Yes I will eventually get to the point ....

I doubt very much I'm the only one taking a mountain of timing data and not properly cataloging it. My guess is that maybe > 90% of the list members are in the same boat. How about:

  1. A set of not to restrictive data format standards (CSV with a few restrictions ...)
  2. A simple / brief method of  identifying that data (likely fancier than a text file)
  3. A list repository to stuff it away in and retrieve it from.
  4. A (to be written) database app to let you rummage around and find things

There are a number of very nice software programs out there that a lot of us use. Ideally the "magic standard" format would eventually wok (at least for export) from all of them.

Bob

On Jan 7, 2011, at 3:59 PM, Perry Sandeen wrote:

List,

I apologize in advance for my long posting

Several weeks ago I posted what were my attempts to save data and my school-of hard-knocks learning curve.  Unfortunately several posters just had to nit-pick the process I had used and started a long series of posts and counter-posts about the process while totally missing the message.  So I’m going to walk through this again hopefully for the edification of the majority.

Just several days ago a 10 year old Canadian girl discovered a super-nova while studying photographic images.  Observations by the world’s two most powerful earth based telescopes confirmed here discovery.

Now consider the case of the Antikythera mechanism.  It was close to 2,000 years ahead of what was eventually developed in Europe.  Most likely we never knew about it was that the library in Alexandria Egypt was joyfully burned three times by religious idiots [see Wikipedia].

This mechanism was so complicated and accurate that as least passing knowledge, if not some or all of its drawings, would have been there.  In context to the science of that time, it ranked up with what the Hubble telescope accomplished for science today.

Which brings us here to today.

Governments and private businesses are storing millions of tons of written documents in the evacuated chambers of salt mines of the world [see Wikipedia].  This does beg the question of where the inventory lists are stored.  The reason for this is that no other archival grade of mass storage really exists.  The last method that I’m aware of is black & white polyester microfilm which is rated at 500 years.  With the almost total transition to digital cameras, there is no financial incentive to produce the necessary film stock to continue that process.

NASA has lost large amounts of acquired data as no equipment now exists to read the information.

Current CD/ DVD media is no solution.  A 2004 report published in the Journal of Research of the National Institute of Standards and Technology entitled "Stability Comparison of Recordable Optical Discs-A Study of Error Rates in Harsh Conditions."  You can read it yourself at http://nvl-p.nist.gov/pub/nistpubs/jres/109/5/j95sla.pdf.

Until someone invents a stabilized glass DVD and perhaps a holographic laser beam to create the needed pits W/O chemicals (embedded gold maybe?) archival data storage W/O paper is a crap-shoot.

So where am I going with all this?  Glad you asked.

No one knows if their or others data will lead to a new discovery or process.  Da Vinci certainly didn’t.  It can however; lead to learning that can then can be taken to the next level of knowledge and invention.

Words cannot express my gratefulness to those who have taken the considerable effort and expense to post science information and support technical lists such as this on the net as well as the posters who have kindly shared their knowledge with us.

I just hope it doesn’t get lost.

End of Rant.  I now get off my soapbox and return you to your normal programming.

Regards,

Perrier

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi I'm sitting here running data on a bunch of TBolts and the like. Might that data be useful to others - maybe. Could it be useful 100 years from not - doubtful. I have the ability to create enormous amounts of likely useless trivia. To me the burring the useful nugget in the mountain of trivia is the bigger issue. It's the librarian, not the library that we need more than ever. Without a process for cataloging, indexing, and retrieving data - it's as good as lost. Finding and identifying data from a year or two back - forget it. Storage / duplication is (as mentioned in another post) is cheap and easy. Indexing and cataloging is what makes sure the stuff is retained and useful. Yes I will eventually get to the point .... I doubt very much I'm the only one taking a mountain of timing data and not properly cataloging it. My guess is that maybe > 90% of the list members are in the same boat. How about: 1) A set of not to restrictive data format standards (CSV with a few restrictions ...) 2) A simple / brief method of identifying that data (likely fancier than a text file) 3) A list repository to stuff it away in and retrieve it from. 4) A (to be written) database app to let you rummage around and find things There are a number of *very* nice software programs out there that a lot of us use. Ideally the "magic standard" format would eventually wok (at least for export) from all of them. Bob On Jan 7, 2011, at 3:59 PM, Perry Sandeen wrote: > List, > > I apologize in advance for my long posting > > Several weeks ago I posted what were my attempts to save data and my school-of hard-knocks learning curve. Unfortunately several posters just had to nit-pick the process I had used and started a long series of posts and counter-posts about the process while totally missing the message. So I’m going to walk through this again hopefully for the edification of the majority. > > Just several days ago a 10 year old Canadian girl discovered a super-nova while studying photographic images. Observations by the world’s two most powerful earth based telescopes confirmed here discovery. > > Now consider the case of the Antikythera mechanism. It was close to 2,000 years ahead of what was eventually developed in Europe. Most likely we never knew about it was that the library in Alexandria Egypt was joyfully burned three times by religious idiots [see Wikipedia]. > > This mechanism was so complicated and accurate that as least passing knowledge, if not some or all of its drawings, would have been there. In context to the science of that time, it ranked up with what the Hubble telescope accomplished for science today. > > Which brings us here to today. > > Governments and private businesses are storing millions of tons of written documents in the evacuated chambers of salt mines of the world [see Wikipedia]. This does beg the question of where the inventory lists are stored. The reason for this is that no other archival grade of mass storage really exists. The last method that I’m aware of is black & white polyester microfilm which is rated at 500 years. With the almost total transition to digital cameras, there is no financial incentive to produce the necessary film stock to continue that process. > > NASA has lost large amounts of acquired data as no equipment now exists to read the information. > > Current CD/ DVD media is no solution. A 2004 report published in the Journal of Research of the National Institute of Standards and Technology entitled "Stability Comparison of Recordable Optical Discs-A Study of Error Rates in Harsh Conditions." You can read it yourself at http://nvl-p.nist.gov/pub/nistpubs/jres/109/5/j95sla.pdf. > > Until someone invents a stabilized glass DVD and perhaps a holographic laser beam to create the needed pits W/O chemicals (embedded gold maybe?) archival data storage W/O paper is a crap-shoot. > > So where am I going with all this? Glad you asked. > > No one knows if their or others data will lead to a new discovery or process. Da Vinci certainly didn’t. It can however; lead to learning that can then can be taken to the next level of knowledge and invention. > > Words cannot express my gratefulness to those who have taken the considerable effort and expense to post science information and support technical lists such as this on the net as well as the posters who have kindly shared their knowledge with us. > > I just hope it doesn’t get lost. > > End of Rant. I now get off my soapbox and return you to your normal programming. > > Regards, > > Perrier > > > > > > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.
S
scmcgrath@gmail.com
Sun, Jan 9, 2011 5:27 PM

Have you thought of using RRD (Round Robin Database).

RRD is a CSV format which stores value vs time and is generally used for archiving network performance data which is generally kept for years.  This format has the advantage of compactness and arbitrary x y scaling.

MRTG (Multi-Router Traffic Grapher) is probably the best known application
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Bob Camp lists@rtty.us
Sender: time-nuts-bounces@febo.com
Date: Sun, 9 Jan 2011 12:15:30
To: Discussion of precise time and frequency measurementtime-nuts@febo.com
Reply-To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Subject: Re: [time-nuts] Archiving Timing Data

Hi

I'm sitting here running data on a bunch of TBolts and the like. Might that data be useful to others - maybe. Could it be useful 100 years from not - doubtful. I have the ability to create enormous amounts of likely useless trivia. To me the burring the useful nugget in the mountain of trivia is the bigger issue. It's the librarian, not the library that we need more than ever.

Without a process for cataloging, indexing, and retrieving data - it's as good as lost. Finding and identifying data from a year or two back - forget it. Storage / duplication is (as mentioned in another post) is cheap and easy. Indexing and cataloging is what makes sure the stuff is retained and useful.

Yes I will eventually get to the point ....

I doubt very much I'm the only one taking a mountain of timing data and not properly cataloging it. My guess is that maybe > 90% of the list members are in the same boat. How about:

  1. A set of not to restrictive data format standards (CSV with a few restrictions ...)
  2. A simple / brief method of  identifying that data (likely fancier than a text file)
  3. A list repository to stuff it away in and retrieve it from.
  4. A (to be written) database app to let you rummage around and find things

There are a number of very nice software programs out there that a lot of us use. Ideally the "magic standard" format would eventually wok (at least for export) from all of them.

Bob

On Jan 7, 2011, at 3:59 PM, Perry Sandeen wrote:

List,

I apologize in advance for my long posting

Several weeks ago I posted what were my attempts to save data and my school-of hard-knocks learning curve.  Unfortunately several posters just had to nit-pick the process I had used and started a long series of posts and counter-posts about the process while totally missing the message.  So I’m going to walk through this again hopefully for the edification of the majority.

Just several days ago a 10 year old Canadian girl discovered a super-nova while studying photographic images.  Observations by the world’s two most powerful earth based telescopes confirmed here discovery.

Now consider the case of the Antikythera mechanism.  It was close to 2,000 years ahead of what was eventually developed in Europe.  Most likely we never knew about it was that the library in Alexandria Egypt was joyfully burned three times by religious idiots [see Wikipedia].

This mechanism was so complicated and accurate that as least passing knowledge, if not some or all of its drawings, would have been there.  In context to the science of that time, it ranked up with what the Hubble telescope accomplished for science today.

Which brings us here to today.

Governments and private businesses are storing millions of tons of written documents in the evacuated chambers of salt mines of the world [see Wikipedia].  This does beg the question of where the inventory lists are stored.  The reason for this is that no other archival grade of mass storage really exists.  The last method that I’m aware of is black & white polyester microfilm which is rated at 500 years.  With the almost total transition to digital cameras, there is no financial incentive to produce the necessary film stock to continue that process.

NASA has lost large amounts of acquired data as no equipment now exists to read the information.

Current CD/ DVD media is no solution.  A 2004 report published in the Journal of Research of the National Institute of Standards and Technology entitled "Stability Comparison of Recordable Optical Discs-A Study of Error Rates in Harsh Conditions."  You can read it yourself at http://nvl-p.nist.gov/pub/nistpubs/jres/109/5/j95sla.pdf.

Until someone invents a stabilized glass DVD and perhaps a holographic laser beam to create the needed pits W/O chemicals (embedded gold maybe?) archival data storage W/O paper is a crap-shoot.

So where am I going with all this?  Glad you asked.

No one knows if their or others data will lead to a new discovery or process.  Da Vinci certainly didn’t.  It can however; lead to learning that can then can be taken to the next level of knowledge and invention.

Words cannot express my gratefulness to those who have taken the considerable effort and expense to post science information and support technical lists such as this on the net as well as the posters who have kindly shared their knowledge with us.

I just hope it doesn’t get lost.

End of Rant.  I now get off my soapbox and return you to your normal programming.

Regards,

Perrier

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Have you thought of using RRD (Round Robin Database). RRD is a CSV format which stores value vs time and is generally used for archiving network performance data which is generally kept for years. This format has the advantage of compactness and arbitrary x y scaling. MRTG (Multi-Router Traffic Grapher) is probably the best known application Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Bob Camp <lists@rtty.us> Sender: time-nuts-bounces@febo.com Date: Sun, 9 Jan 2011 12:15:30 To: Discussion of precise time and frequency measurement<time-nuts@febo.com> Reply-To: Discussion of precise time and frequency measurement <time-nuts@febo.com> Subject: Re: [time-nuts] Archiving Timing Data Hi I'm sitting here running data on a bunch of TBolts and the like. Might that data be useful to others - maybe. Could it be useful 100 years from not - doubtful. I have the ability to create enormous amounts of likely useless trivia. To me the burring the useful nugget in the mountain of trivia is the bigger issue. It's the librarian, not the library that we need more than ever. Without a process for cataloging, indexing, and retrieving data - it's as good as lost. Finding and identifying data from a year or two back - forget it. Storage / duplication is (as mentioned in another post) is cheap and easy. Indexing and cataloging is what makes sure the stuff is retained and useful. Yes I will eventually get to the point .... I doubt very much I'm the only one taking a mountain of timing data and not properly cataloging it. My guess is that maybe > 90% of the list members are in the same boat. How about: 1) A set of not to restrictive data format standards (CSV with a few restrictions ...) 2) A simple / brief method of identifying that data (likely fancier than a text file) 3) A list repository to stuff it away in and retrieve it from. 4) A (to be written) database app to let you rummage around and find things There are a number of *very* nice software programs out there that a lot of us use. Ideally the "magic standard" format would eventually wok (at least for export) from all of them. Bob On Jan 7, 2011, at 3:59 PM, Perry Sandeen wrote: > List, > > I apologize in advance for my long posting > > Several weeks ago I posted what were my attempts to save data and my school-of hard-knocks learning curve. Unfortunately several posters just had to nit-pick the process I had used and started a long series of posts and counter-posts about the process while totally missing the message. So I’m going to walk through this again hopefully for the edification of the majority. > > Just several days ago a 10 year old Canadian girl discovered a super-nova while studying photographic images. Observations by the world’s two most powerful earth based telescopes confirmed here discovery. > > Now consider the case of the Antikythera mechanism. It was close to 2,000 years ahead of what was eventually developed in Europe. Most likely we never knew about it was that the library in Alexandria Egypt was joyfully burned three times by religious idiots [see Wikipedia]. > > This mechanism was so complicated and accurate that as least passing knowledge, if not some or all of its drawings, would have been there. In context to the science of that time, it ranked up with what the Hubble telescope accomplished for science today. > > Which brings us here to today. > > Governments and private businesses are storing millions of tons of written documents in the evacuated chambers of salt mines of the world [see Wikipedia]. This does beg the question of where the inventory lists are stored. The reason for this is that no other archival grade of mass storage really exists. The last method that I’m aware of is black & white polyester microfilm which is rated at 500 years. With the almost total transition to digital cameras, there is no financial incentive to produce the necessary film stock to continue that process. > > NASA has lost large amounts of acquired data as no equipment now exists to read the information. > > Current CD/ DVD media is no solution. A 2004 report published in the Journal of Research of the National Institute of Standards and Technology entitled "Stability Comparison of Recordable Optical Discs-A Study of Error Rates in Harsh Conditions." You can read it yourself at http://nvl-p.nist.gov/pub/nistpubs/jres/109/5/j95sla.pdf. > > Until someone invents a stabilized glass DVD and perhaps a holographic laser beam to create the needed pits W/O chemicals (embedded gold maybe?) archival data storage W/O paper is a crap-shoot. > > So where am I going with all this? Glad you asked. > > No one knows if their or others data will lead to a new discovery or process. Da Vinci certainly didn’t. It can however; lead to learning that can then can be taken to the next level of knowledge and invention. > > Words cannot express my gratefulness to those who have taken the considerable effort and expense to post science information and support technical lists such as this on the net as well as the posters who have kindly shared their knowledge with us. > > I just hope it doesn’t get lost. > > End of Rant. I now get off my soapbox and return you to your normal programming. > > Regards, > > Perrier > > > > > > >_______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
BC
Bob Camp
Mon, Jan 10, 2011 12:48 PM

Hi

I suspect it would indeed work. The database would not need to be very fancy.

Bob

On Jan 9, 2011, at 12:27 PM, scmcgrath@gmail.com wrote:

Have you thought of using RRD (Round Robin Database).

RRD is a CSV format which stores value vs time and is generally used for archiving network performance data which is generally kept for years.  This format has the advantage of compactness and arbitrary x y scaling.

MRTG (Multi-Router Traffic Grapher) is probably the best known application
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Bob Camp lists@rtty.us
Sender: time-nuts-bounces@febo.com
Date: Sun, 9 Jan 2011 12:15:30
To: Discussion of precise time and frequency measurementtime-nuts@febo.com
Reply-To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Subject: Re: [time-nuts] Archiving Timing Data

Hi

I'm sitting here running data on a bunch of TBolts and the like. Might that data be useful to others - maybe. Could it be useful 100 years from not - doubtful. I have the ability to create enormous amounts of likely useless trivia. To me the burring the useful nugget in the mountain of trivia is the bigger issue. It's the librarian, not the library that we need more than ever.

Without a process for cataloging, indexing, and retrieving data - it's as good as lost. Finding and identifying data from a year or two back - forget it. Storage / duplication is (as mentioned in another post) is cheap and easy. Indexing and cataloging is what makes sure the stuff is retained and useful.

Yes I will eventually get to the point ....

I doubt very much I'm the only one taking a mountain of timing data and not properly cataloging it. My guess is that maybe > 90% of the list members are in the same boat. How about:

  1. A set of not to restrictive data format standards (CSV with a few restrictions ...)
  2. A simple / brief method of  identifying that data (likely fancier than a text file)
  3. A list repository to stuff it away in and retrieve it from.
  4. A (to be written) database app to let you rummage around and find things

There are a number of very nice software programs out there that a lot of us use. Ideally the "magic standard" format would eventually wok (at least for export) from all of them.

Bob

On Jan 7, 2011, at 3:59 PM, Perry Sandeen wrote:

List,

I apologize in advance for my long posting

Several weeks ago I posted what were my attempts to save data and my school-of hard-knocks learning curve.  Unfortunately several posters just had to nit-pick the process I had used and started a long series of posts and counter-posts about the process while totally missing the message.  So I’m going to walk through this again hopefully for the edification of the majority.

Just several days ago a 10 year old Canadian girl discovered a super-nova while studying photographic images.  Observations by the world’s two most powerful earth based telescopes confirmed here discovery.

Now consider the case of the Antikythera mechanism.  It was close to 2,000 years ahead of what was eventually developed in Europe.  Most likely we never knew about it was that the library in Alexandria Egypt was joyfully burned three times by religious idiots [see Wikipedia].

This mechanism was so complicated and accurate that as least passing knowledge, if not some or all of its drawings, would have been there.  In context to the science of that time, it ranked up with what the Hubble telescope accomplished for science today.

Which brings us here to today.

Governments and private businesses are storing millions of tons of written documents in the evacuated chambers of salt mines of the world [see Wikipedia].  This does beg the question of where the inventory lists are stored.  The reason for this is that no other archival grade of mass storage really exists.  The last method that I’m aware of is black & white polyester microfilm which is rated at 500 years.  With the almost total transition to digital cameras, there is no financial incentive to produce the necessary film stock to continue that process.

NASA has lost large amounts of acquired data as no equipment now exists to read the information.

Current CD/ DVD media is no solution.  A 2004 report published in the Journal of Research of the National Institute of Standards and Technology entitled "Stability Comparison of Recordable Optical Discs-A Study of Error Rates in Harsh Conditions."  You can read it yourself at http://nvl-p.nist.gov/pub/nistpubs/jres/109/5/j95sla.pdf.

Until someone invents a stabilized glass DVD and perhaps a holographic laser beam to create the needed pits W/O chemicals (embedded gold maybe?) archival data storage W/O paper is a crap-shoot.

So where am I going with all this?  Glad you asked.

No one knows if their or others data will lead to a new discovery or process.  Da Vinci certainly didn’t.  It can however; lead to learning that can then can be taken to the next level of knowledge and invention.

Words cannot express my gratefulness to those who have taken the considerable effort and expense to post science information and support technical lists such as this on the net as well as the posters who have kindly shared their knowledge with us.

I just hope it doesn’t get lost.

End of Rant.  I now get off my soapbox and return you to your normal programming.

Regards,

Perrier

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Hi I suspect it would indeed work. The database would not need to be very fancy. Bob On Jan 9, 2011, at 12:27 PM, scmcgrath@gmail.com wrote: > Have you thought of using RRD (Round Robin Database). > > RRD is a CSV format which stores value vs time and is generally used for archiving network performance data which is generally kept for years. This format has the advantage of compactness and arbitrary x y scaling. > > MRTG (Multi-Router Traffic Grapher) is probably the best known application > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: Bob Camp <lists@rtty.us> > Sender: time-nuts-bounces@febo.com > Date: Sun, 9 Jan 2011 12:15:30 > To: Discussion of precise time and frequency measurement<time-nuts@febo.com> > Reply-To: Discussion of precise time and frequency measurement > <time-nuts@febo.com> > Subject: Re: [time-nuts] Archiving Timing Data > > Hi > > I'm sitting here running data on a bunch of TBolts and the like. Might that data be useful to others - maybe. Could it be useful 100 years from not - doubtful. I have the ability to create enormous amounts of likely useless trivia. To me the burring the useful nugget in the mountain of trivia is the bigger issue. It's the librarian, not the library that we need more than ever. > > Without a process for cataloging, indexing, and retrieving data - it's as good as lost. Finding and identifying data from a year or two back - forget it. Storage / duplication is (as mentioned in another post) is cheap and easy. Indexing and cataloging is what makes sure the stuff is retained and useful. > > Yes I will eventually get to the point .... > > I doubt very much I'm the only one taking a mountain of timing data and not properly cataloging it. My guess is that maybe > 90% of the list members are in the same boat. How about: > > 1) A set of not to restrictive data format standards (CSV with a few restrictions ...) > 2) A simple / brief method of identifying that data (likely fancier than a text file) > 3) A list repository to stuff it away in and retrieve it from. > 4) A (to be written) database app to let you rummage around and find things > > There are a number of *very* nice software programs out there that a lot of us use. Ideally the "magic standard" format would eventually wok (at least for export) from all of them. > > Bob > > On Jan 7, 2011, at 3:59 PM, Perry Sandeen wrote: > >> List, >> >> I apologize in advance for my long posting >> >> Several weeks ago I posted what were my attempts to save data and my school-of hard-knocks learning curve. Unfortunately several posters just had to nit-pick the process I had used and started a long series of posts and counter-posts about the process while totally missing the message. So I’m going to walk through this again hopefully for the edification of the majority. >> >> Just several days ago a 10 year old Canadian girl discovered a super-nova while studying photographic images. Observations by the world’s two most powerful earth based telescopes confirmed here discovery. >> >> Now consider the case of the Antikythera mechanism. It was close to 2,000 years ahead of what was eventually developed in Europe. Most likely we never knew about it was that the library in Alexandria Egypt was joyfully burned three times by religious idiots [see Wikipedia]. >> >> This mechanism was so complicated and accurate that as least passing knowledge, if not some or all of its drawings, would have been there. In context to the science of that time, it ranked up with what the Hubble telescope accomplished for science today. >> >> Which brings us here to today. >> >> Governments and private businesses are storing millions of tons of written documents in the evacuated chambers of salt mines of the world [see Wikipedia]. This does beg the question of where the inventory lists are stored. The reason for this is that no other archival grade of mass storage really exists. The last method that I’m aware of is black & white polyester microfilm which is rated at 500 years. With the almost total transition to digital cameras, there is no financial incentive to produce the necessary film stock to continue that process. >> >> NASA has lost large amounts of acquired data as no equipment now exists to read the information. >> >> Current CD/ DVD media is no solution. A 2004 report published in the Journal of Research of the National Institute of Standards and Technology entitled "Stability Comparison of Recordable Optical Discs-A Study of Error Rates in Harsh Conditions." You can read it yourself at http://nvl-p.nist.gov/pub/nistpubs/jres/109/5/j95sla.pdf. >> >> Until someone invents a stabilized glass DVD and perhaps a holographic laser beam to create the needed pits W/O chemicals (embedded gold maybe?) archival data storage W/O paper is a crap-shoot. >> >> So where am I going with all this? Glad you asked. >> >> No one knows if their or others data will lead to a new discovery or process. Da Vinci certainly didn’t. It can however; lead to learning that can then can be taken to the next level of knowledge and invention. >> >> Words cannot express my gratefulness to those who have taken the considerable effort and expense to post science information and support technical lists such as this on the net as well as the posters who have kindly shared their knowledge with us. >> >> I just hope it doesn’t get lost. >> >> End of Rant. I now get off my soapbox and return you to your normal programming. >> >> Regards, >> >> Perrier >> >> >> >> >> >> >> _______________________________________________ >> time-nuts mailing list -- time-nuts@febo.com >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.
Next page
Empathy v1.0   2026 ©emwd.com
Documentation