On 04/07/2015 14:13, Jim Lux wrote:
...
BUT now, I'd like to add a web interface, so that it can be
manipulated by a mobile device using a browser.
...
Is the best scheme to go in and modify the webserver code to look for
specific URLs requested, and then fire off some custom code to do what
On 01/07/2015 16:23, Tom Van Baak wrote:
3) Adafruit Ultimate GPS Breakout
http://www.adafruit.com/products/746
This GPS receiver appeared to mess up the 2015 leap second, with a double 5959
and possible receiver reset:
(I also had serial communications issues with this board today)
If
On 14/12/2014 04:08, d...@irtelemetrics.com wrote:
Note that most high-end GNSS timing receivers go one better and
simply have an external input for the clock. That way you feed your
own lab clock into the receiver. If you have Rb/Cs/maser you would use
that as the reference. It's what the
Of course, a collection of distributed, very accurate clocks does
already exist:
http://en.wikipedia.org/wiki/Global_Positioning_System
And there was a recent paper using this with a similar approach as you
are suggesting, not for gravitational waves, but in the hunt for dark
matter:
Getting a BBB to take 10MHz refclk input (in the fashion of
http://www.febo.com/pages/soekris/)
and being able to timestamp _multiple_ PPS signals via the PRUs would
make for a pretty awesome time-nuts toy.
This is quite do-able and I posted a few weeks ago with the details of
where to poke
Just to echo that using the PRU cores is the wrong way to go, the BBB
has a multitude of hardware timers that will give better performance for
less hassle.
Having said that, by far the Number One thing to consider is controlling
the impact of temperature changes. If you sort that, the rest is
On 11/12/2014 04:15, Chris Albertson wrote:
Those sub 1 u-second numbers are very good. They argue for using the BBB
as an NTP server but I wonder if it really is the best. I think the
numbers that matter are measures of the close on the computers who use your
BBB as a server. In other words
Thanks Pablo.
I've been finding that my implementation is a very good noise detector
(in all kinds of fun ways) and my most recent effort has been at the
hardware level in better layout, shielding and in reducing the number of
noise sources.
The impact of non-random noise is that
boards in cape form factor that would
feed this perfectly. I've been waffling on my choice of microcontroller
but in the spirit of this application I'll likely go with an msp430.
On Friday, November 14, 2014, Simon Marsh subscripti...@burble.com wrote:
Most processors can be clocked from
Many thanks to everyone for your suggestions and patience.
Short answer, the problem was power related, but more accurately, it was
a shielding problem.
Long answer, it was not immediately obvious as power in the setup itself
didn't seem to be a problem. I need 12v (for the mv89a or 8663
On 30/10/2014 07:12, Iain Young wrote:
Hi Simon,
On 29/10/14 20:15, Simon Marsh wrote:
This is a fairly long post, at the top is a bit of description of of
changes since my last posts and then around the middle is some
description of the data thats attached. The data raises a few questions
Lots more pictures and data uploaded here:
https://drive.google.com/folderview?id=0BzvFGRfj4aFkMFBtNWFSZVBKWkkusp=sharing
In an effort to understand which component was responsible for my ~17us
spikes I decided to go back to basics with just a single DFlop (AC74) on
a breadboard; no BBB, just
This is the second post related to my attempts to create a BBB DDMTD,
the first post had a load of graphs showing details of what was
happening around glitch periods. This post is about interpreting those
graphs.
Pretty obvious from only a cursory glance at the graphs are that
transitions
original post had a lot of attachments, these have been uploaded here
for viewing:
https://drive.google.com/folderview?id=0BzvFGRfj4aFkMFBtNWFSZVBKWkkusp=sharing
---
This is a fairly long post, at the top is a bit of description of of
changes since my last posts and then around the middle is
On 29/10/2014 22:22, Bob Camp wrote:
Hi
It is not at all unusual for signals to be re-clocked when going into a micro.
Often the documentation on this process is somewhere between vague and
non-exsistant.
Bob
Yes, luckily the Sitra TRM has a nice clear diagram for the mechanism I
use and
On 24/10/2014 21:33, Joseph Gray wrote:
Timestamping a message to the nearest 100 ns is what I am after. If I can't
do it directly with the ublox, I'll have to look at the PRU on the
Beaglebone. It has a 200 Mhz clock and single cycle instructions.
The BBB has no less than 8 peripherals that
There are two ways that both positive and negative slopes could be used,
that is, with the input clocks and/or with the reference clock.
The PRU on the BBB is not really fast enough to identify the edge
direction at a 10mhz rate, so I only collect state changes in real time
and then sort it
Thanks for the great explanation.
Is there any data on the performance ?
Cheers
Simon
On 21/10/2014 22:29, Dennis Ferguson wrote:
On 21 Oct, 2014, at 08:58 , Simon Marsh subscripti...@burble.com wrote:
How do you map the timer counter value in to a PPS timestamp ?
(that is, how do you turn
Running the BBB as an NTP server is a breeze and has a couple of
advantages over the Pi. Specifically, on the BBB, the kernel module is
pre-built and configuring the PPS driver is done at runtime using the
device tree. No kernel re-compilation is required to get up and running,
just plug and
Iain,
How do you map the timer counter value in to a PPS timestamp ?
(that is, how do you turn the HW counter value in to what the OS thought
the time was when the event occured ?)
Cheers
Simon
On 21/10/2014 13:54, Iain Young wrote:
It's been done on FreeBSD. See:
a Invalid argument error from
ppsapitest after running it more than once. Reboot solves it,
and since the BBB's don't do anything else, and I don't restart ntp
too often, its not a big deal for me.)
Iain
On 21/10/14 14:58, Simon Marsh wrote:
Iain,
How do you map the timer counter value in to a PPS
Javier,
I'm merely implementing a poor man's copy of the ideas in the White
Rabbit project, so thank you for taking the time to post.
On 15/10/2014 14:27, Javier Serrano wrote:
[snip]
Do you have a precise idea of what the offset in frequency is between
your DUT(s) and the slightly-offset
Many thanks to Bob D, Bob C, Bruce and Magnus for the links, references
and being patient.
I've spent a bit of time looking at the glitching with the idea of
evaluating a few different algorithms to deal with it. I also looked a
bit at the hardware and instead of very simply having a single
(to the plane) with a near zero lead length capacitor.
Bob L.
Sent: Tuesday, October 14, 2014 at 11:32 AM
From: Simon Marsh subscripti...@burble.com
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Subject: Re: [time-nuts] Digital Mixing with a BeagleBone Black and D
Darby
On 10/10/2014 3:46 PM, Simon Marsh wrote:
Bob,
It's good to know someone else is trying this and it's not just me going off on
a tangent somewhere. I'd be very interested in understanding how you'd set this
up and how you'd got a nice clean rising edge.
My understanding
I (mostly) understand this when considering an analogue mixer, but I'm
lost on whether there are any similar effects going on with a digital
signal ?
TBH, I'm not really sure 'mixing' is the right phrase in the digital
case, and my apologies if I got that wrong.
What's actually going on is
On 11/10/2014 20:33, Robert Darby wrote:
If I can rephrase your first post, you plan to capture the state
transitions along with their timing and subsequently post-process them
to determine the time from one zero-crossing to another. Each
zero-crossing is the sum of number of closely spaced
I've been a lurker on time-nuts for a while, most of the discussion
being way over my head, but I thought there may be interest in some
proof of concept code I've written for simple digital hetrodyne mixing
using just a BeagleBone Black and an external dual D Flip Flop.
The idea is based on
28 matches
Mail list logo
