[time-nuts] Z3810AS PPS to a Raspberry Pi

[Dan Watson]

The delay between the PPS and the rising edge of the 555 output is 150 ns.
This is with the 555 running on 3.3V. I could likely get a faster rise time
if I ran the 555 on 5V, though I would then have to level shift the output
back to 3.3 for the GPIO pin. Not a big deal, as long as there is a
benefit. I have one bare board left so I will cut a couple traces and make
up a 5V version.

I was concerned about jitter and noise, and it seems that is a valid
concern. I'm not familiar with proper methods for measuring jitter in the
ns range. I can say that NTP stats shows a jitter of 4 us after some
settling, where as I would normally have 2 us jitter with other GPS modules
I have tried. So roughly 100% worse than a GPS module sitting on the RPi
with no added circuitry. That gives me a starting point to work from though.

Measuring the output on my 53131A it reads a period of 1 second out to 10
zeros, with +/- 1 count of jitter on the last digit.

I have attached the schematic. The input for the PPS made sense when using
pins 1 and 7 on the connector, but with pins 1 and 6 I am not as clear on
how to properly interface the differential signal. Besides the fact that
what I have now does properly trigger the 555. So thanks for any
suggestions on improving that part and reducing jitter/noise.

Pete: If I eventually get to a circuit I'm happy with, I'll share the
project on OshPark. And a PTH version would be easy to make up as well.
That way you can order some if you like, or just see the layout and make
your own. A board this size is only about $5 for 3 using that service.

Regards,

Dan Watson

On Tue, Mar 24, 2015 at 3:42 PM, Attila Kinali <attila at kinali.ch> wrote:

> On Mon, 23 Mar 2015 19:25:33 -0700
> Chris Albertson <albertson.chris at gmail.com> 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 at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pipps_sch.png
Type: image/png
Size: 13512 bytes
Desc: not available
URL: <http://www.febo.com/pipermail/time-nuts/attachments/20150329/6d197420/attachment.png>