Re: [time-nuts] serial parsing program

[Bob Stewart]

Hi Cash,
Have you looked at the sourcecode for the "gpsd" package?  "packet.c" would 
probably be your starting point.  The gpsd package parses pretty much every gps 
receiver.  I'm not sure if this is what you're looking for, or if you 
specifically want something high-level.  

Bob

  From: Cash Olsen 
 To: time-nuts@febo.com 
 Sent: Tuesday, March 24, 2015 5:22 PM
 Subject: [time-nuts] serial parsing program
   
I'd like to find a program that has a very flexible serial input and can be
easily setup to parse a binary sentence. Specifically, U-Blox timing but
more general purpose would be nice for future projects. Has to be able to
handle 1, 2, and 4 byte fields, and checksums would be nice also. Should
run on Windows for the immediate project but Linux for next projects.

-- 
S. Cash Olsen KD5SSJ
ARRL Technical Specialist
___
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.

Re: [time-nuts] serial parsing program

[Henry Hallam]

RealTerm is my go-to for this sort of thing on Windows, though it
might not be quite as flexible as you'd like.
Linux: just mung together a pipeline involving things like xxd, awk, grep..

Henry

On Tue, Mar 24, 2015 at 3:22 PM, Cash Olsen  wrote:
> I'd like to find a program that has a very flexible serial input and can be
> easily setup to parse a binary sentence. Specifically, U-Blox timing but
> more general purpose would be nice for future projects. Has to be able to
> handle 1, 2, and 4 byte fields, and checksums would be nice also. Should
> run on Windows for the immediate project but Linux for next projects.
>
> --
> S. Cash Olsen KD5SSJ
> ARRL Technical Specialist
> ___
> 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.

Re: [time-nuts] serial parsing program

[Prologix]

Hello Cash,

Check out Google Protocol Buffers
https://developers.google.com/protocol-buffers/

And here is a discussion of it from an embedded software perspective
http://www.ganssle.com/tem/tem277.html#article1

Hope that helps.

Regards,
Abdul


-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Cash Olsen
Sent: Tuesday, March 24, 2015 3:22 PM
To: time-nuts@febo.com
Subject: [time-nuts] serial parsing program

I'd like to find a program that has a very flexible serial input and can be 
easily setup to parse a binary sentence. Specifically, U-Blox timing but more 
general purpose would be nice for future projects. Has to be able to handle 1, 
2, and 4 byte fields, and checksums would be nice also. Should run on Windows 
for the immediate project but Linux for next projects.

--
S. Cash Olsen KD5SSJ
ARRL Technical Specialist
___
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] serial parsing program

[Cash Olsen]

I'd like to find a program that has a very flexible serial input and can be
easily setup to parse a binary sentence. Specifically, U-Blox timing but
more general purpose would be nice for future projects. Has to be able to
handle 1, 2, and 4 byte fields, and checksums would be nice also. Should
run on Windows for the immediate project but Linux for next projects.

-- 
S. Cash Olsen KD5SSJ
ARRL Technical Specialist
___
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.

Re: [time-nuts] M12+ Site Survey

[Tim Shoppa]

Assuming pure position fix:

A foot is a nanosecond.

A mile is 5 microseconds.

30 miles is 150 microseconds.

Quite sure the GPS would declare sanity check failure if it ever saw more
than one or two satellites and saw the position fix was wrong.

Tim N3QE

On Tuesday, March 24, 2015, Martyn Smith  wrote:

> Hello,
>
> I apologize if this question has been asked before.
>
> I have a frequency standard that uses the M12+ to discipline a rubidium
> oscillator.
>
> I set the M12+ to do a site survey and then set it to position hold mode
> for best accuracy.
>
> My question is:
>
> If I then move the unit, for example 30 miles and leave it in position
> hold (without doing another site survey)
>
> How will the accuracy of the 1 pps pulse be affected?
>
> In this instance, I don’t actually care about alignment to UTC.
>
> I’m just worried about the accuracy of the 1 pps pulse and ultimately the
> accuracy of my rubidium’s frequency.
>
> I’m about to do some testing, but wondered if anyone had an answer already.
>
> Best Regards
>
> Martyn
>
> ___
> 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.

Re: [time-nuts] M12+ Site Survey

[Attila Kinali]

On Tue, 24 Mar 2015 19:52:30 -
"Martyn Smith"  wrote:

> If I then move the unit, for example 30 miles and leave it in position hold 
> (without doing another site survey)
> 
> How will the accuracy of the 1 pps pulse be affected?
> 
> In this instance, I don’t actually care about alignment to UTC.
> 
> I’m just worried about the accuracy of the 1 pps pulse and ultimately the
> accuracy of my rubidium’s frequency.

I think you mean "precision" and not "accuracy"[1] :-)


If you leave the module in position hold and the module does not realize
itself it has been moved, then the PPS will be very jittery. How much,
I cannot tell (I have not seen any data of extreme off positions like that).
I would guess several ms. But it would be still a pulse roughly every second.

Poul-Henning had some experience with "a bit off" position with his M12
due to high solar activity (I've seen it on his webpage, but cannot find
it at the moment). He used (uses?) an algorithm with which the receiver
can "creep" up to its actual position over time[2].

If you move around often, i would simply disable position-hold and live
with "normal" GPS precision, which is better than 100ns for most receivers
and good sky view.

HTH

Attila Kinali


[1] http://en.wikipedia.org/wiki/Accuracy_and_precision 
[2] http://phk.freebsd.dk/raga/sneak/

-- 
< _av500_> phd is easy
< _av500_> getting dsl is hard
___
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] M12+ Site Survey

[Martyn Smith]

Hello,

I apologize if this question has been asked before.

I have a frequency standard that uses the M12+ to discipline a rubidium 
oscillator.

I set the M12+ to do a site survey and then set it to position hold mode for 
best accuracy.

My question is:

If I then move the unit, for example 30 miles and leave it in position hold 
(without doing another site survey)

How will the accuracy of the 1 pps pulse be affected?

In this instance, I don’t actually care about alignment to UTC.

I’m just worried about the accuracy of the 1 pps pulse and ultimately the 
accuracy of my rubidium’s frequency.

I’m about to do some testing, but wondered if anyone had an answer already.

Best Regards

Martyn 

___
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.

Re: [time-nuts] Z3810AS PPS to a Raspberry Pi

[Attila Kinali]

On Mon, 23 Mar 2015 19:25:33 -0700
Chris Albertson  wrote:

>  I'm surprised to can't
> get the Pi to interrupt on the raising edge of the PPS and that you had to
> make the pulse longer.

That's because the rpi does not have GPIO's like other SoC or uC.
When i wrote that it's a graphics card with attached usb controller,
i wasn't joking. The processor on the rpi was originally designed
as a test system to verify the graphics core on real workload.
To interface it to the outside world, they decided to use USB.
For unknown reasons they decided to use an arm9 core with a bit
of glue logic as USB controller (the best guess i've heard sofar
is, that they would have had to pay for a real USB controller,
while an old arm core like that costs (almost) nothing if you
buy a big/new one anyways).

This is the reason why there are no I2C or SPI interfaces,
and everything needs to be bitbanged (aka, you write single
bits to outputs in software and poll whether anything changes
on the inputs). Or that the "USB controller" generates an
interrupt every 125us that _must_ be handled imediatly
(the arm core has to set up the next USB microframe otherwise
USB stops working).

That is also the reason why Eben Upton got it so cheaply. Apparently,
broadcom had produced quite a few of those (couple thousand, don't ask
me why). And there was no risk that anyone would buy those (for above
reasons, they were never intended to be sold). Also, the mask set
(the most expensive part of chip production) was already there and
amortized by other means, so producing more wouldn't cost much either.


Attila Kinali

-- 
< _av500_> phd is easy
< _av500_> getting dsl is hard
___
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.

Re: [time-nuts] Opamp datasheet noise specs and their relation to phase noise

[Stephan Sandenbergh]

Thanks Charles. That should keep me busy for a while. :)

On 14 March 2015 at 01:51, Charles Steinmetz  wrote:

> Stephan wrote:
>
>  Any good texts on the subject that you can recommend?
>>
>
> I don't own any texts with comprehensive discussions of AM to PM
> conversion or low-PN design.  The best sources will most likely be papers.
> Some good search terms are "AM to PM conversion" (or "AM/PM conversion")
> and "low phase noise design" (or "low PN design").
>
> Here are a few to get you started:
>
> The Art of Phase Noise Measurement (Scherer, Hewlett Packard, 1985)  <
> www.thegleam.com/ke5fx/Scherer_Art_of_PN_measurement.pdf >
>
> Phase Noise and AM Noise Measurements in the Frequency Domain (Lance, et
> al., 1984) 
>
> RF and Microwave Phase Noise Measurement Seminar (HP, 1985) <
> www.thegleam.com/ke5fx/HP_PN_seminar.pdf >
>
> Phase Noise Measurement Using the Phase Lock Technique (Motorola AN1639,
> 1999) 
>
> Phase Noise in RF and Microwave Amplifiers (Boudot, Rubiola, 2010) <
> arxiv.org/pdf/1001.2047>
>
> Origin of 1/f PM and AM Noise in Bipolar Junction Transistor Amplifiers  <
> http://tf.nist.gov/timefreq/general/pdf/1134.pdf>
>
> Guidelines for designing BJT Amplifiers with Low 1/f PM and AM Noise  <
> http://tf.nist.gov/timefreq/general/pdf/1139.pdf>
>
> PM Noise Generated by Noisy Components   general/pdf/1244.pdf>
>
>
>
> Best regards,
>
> Charles
>
>
>
> ___
> 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.

Re: [time-nuts] Comparing the BeagleBone Black & Raspberry Pi asNTP servers

[David J Taylor]

From: Neil Schroeder

The other key key key item is make sure you hand build yourself a 3.14 or
.16 kernel.

NS
=

Thanks, Neil.  I'm afraid I have neither the expertise nor the patience to 
do that, and to an extent this was intended to be an out-of-the-box 
comparison.  Doubtless adding a TCXO would improve performance as well, but 
I will leave that to someone else to try.


I was really interested to see how much effect the extra Ethernet latency of 
the Raspberry Pi added in a real-world scenario.  Thanks to Philip 
Gladstone, I have now discovered a way of significantly reducing that 
latency, so that the delay reported by NTP is reduced from ~0.51 to ~0.35 
milliseconds.


 http://www.satsignal.eu/ntp/RaspberryPi-notes.html#EthernetLatency

Cheers,
David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
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.