Hi!
If it is all the same for you, I prefer this thread continue "in the open"
as I am interested both in using an Arduino-like for my first GPSDO and
STM32 for event capture and timming.
Regards,
Edésio
On Mon, Apr 21, 2014 at 04:29:35PM -0400, paul swed wrote:
> Good afternoon very interested
Actually GCC supporting Cortex. So, I am using Raisonance IDE plus GCC
Toolchain as a development environment. My current project functional
diagram is following:
+--- STM32 -- (Pulse Counter, TTL Generator, DDS
driver, GPSDO monitor)
GPSDO--LTC6957-3--| |
Perhaps this thread should go off line not to distract from the originators
thread.
Regards
Paul.
On Mon, Apr 21, 2014 at 4:29 PM, paul swed wrote:
> Good afternoon very interested in the work you are doing with the STM
> board.
> As I mentioned far earlier in this thread I am attempting to use
Good afternoon very interested in the work you are doing with the STM board.
As I mentioned far earlier in this thread I am attempting to use it to
correct the BPSK WWVB signal here. Initial thoughts were using FORTH to
program the STM board.
Very curious what you are using as examples.
My experien
I was experimenting with the same setup for STM32 MCU. This
microprocessor has accept the sine wave from external OCXO or GPSDO. No
problem with this. The only thing: I was need to start MCU from slow
"watch" crystal first. And then switch it to work to external one. In
another case I got in
- Original Message -
From: "Chris Albertson"
To: "Discussion of precise time and frequency measurement"
; "Magnus Danielson"
Sent: Sunday, April 13, 2014 12:30 AM
Subject: Re: [time-nuts] First success with very simple, very low cost
GPSDO, under $8
O
On Sat, Apr 12, 2014 at 9:48 AM, Magnus Danielson <
mag...@rubidium.dyndns.org> wrote:
>
> In fact a 5 bit counter is enough, and then a '373 to sample it. The
> enable to the 373 needs to be synchronous to the 5/10 MHz clock, so a pair
> of DFFs ('74) is needed to synchronize the PPS and another
Hi,
On 10/04/14 06:43, Tom Van Baak wrote:
You are right in the I don't even need data cycles. All I want is the
error which is 5,000,000 minus the count. this is hopefully zero.
Correct. Keep the counter running. No need to zero it, ever. Use differential
measurements. Essentially you are
faces byte carry
corruption in the multi-byte value of t_besier. True, this works fine
on a 32- or 64-bit cpu, but not on an 8- or 16-bit cpu.
Hmm...
- Original Message -
From: "d0ct0r"
To:
Sent: Thursday, April 10, 2014 10:12 AM
Subject: Re: [time-nuts] First success with v
True, this works fine on a 32- or 64-bit cpu, but not on an 8- or
16-bit cpu.
/tvb
- Original Message -
From: "d0ct0r"
To:
Sent: Thursday, April 10, 2014 10:12 AM
Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO,
under $8
>
> I am n
10,000,000, unless your oscillator
is capable of running at one of the other values that gives 0x9680 as
the lower two bytes.
Bob
From: Chris Albertson
To: Discussion of precise time and frequency measurement
Sent: Wednesday, April 9, 2014 6:35 PM
Subject:
In my case, the cold-start frequency of my OCXO with EFC at midpoint was off
sufficiently far that I needed a minimum number of remainder bits to know which
way to initially steer it. Don't recall the exact number I needed, but it was
more than eight at 10 MHz. Like this design, I had 16 bits to
On Wed, Apr 9, 2014 at 11:43 PM, Tom Van Baak wrote:
> > You are right in the I don't even need data cycles. All I want is the
> > error which is 5,000,000 minus the count. this is hopefully zero.
>
> Correct. Keep the counter running. No need to zero it, ever. Use
> differential measurements.
Tom Harris
On 10 April 2014 16:35, Chris Albertson wrote:
> To many "ifs" and "you could...". The Arduino is what it is. There
> is no capture register, no interrupt priorities and the counter is...
>
There certainly is an input capture, and it makes the code EASIER to
understand, as you kn
> But I still need to count all the cycles in the second and can't just let a
> 8 or 16 bit counter run free. The reason is I don't know where the
> overflow happens. Overflow is not in sync with PPS.
> OK this might work. I hope it does as it would allow a bit of code to be
> removed. Let
on
To: Discussion of precise time and frequency measurement
Cc: Tom Van Baak ; Hal Murray
Sent: Thursday, April 10, 2014 12:11 AM
Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO,
under $8
On Wed, Apr 9, 2014 at 11:18 PM, Hal Murray wrote:
t...@
A couple more comments on the Arduino...
>
> 1) Have you checked for glitches in your dual-DAC system? The Arduino API
> is forcing you to make two successive calls to analogWrite(). I wonder if
> there might be a glitch when the LSB carries/borrows into the MSB, since
> each PWM is configured sepa
On Wed, Apr 9, 2014 at 11:18 PM, Hal Murray wrote:
>
> t...@leapsecond.com said:
> > You only need enough bits to cover the worst case OCXO frequency drift or
> > the worst case GPS jitter error, per second. For example, if your OCXO
> stays
> > accurate to 1 ppm it can't possibly drift more than
>> You only need enough bits to cover the worst case OCXO frequency drift or
>> the worst case GPS jitter error, per second. For example, if your OCXO stays
>> accurate to 1 ppm it can't possibly drift more than 1 us per second.
>> Similarly, it's a safe assumption that your GPS 1PPS stays within 1
To many "ifs" and "you could...". The Arduino is what it is. There
is no capture register, no interrupt priorities and the counter is
16-bits and the overflow actually takes one cycle. The code is
posted. You can read it. Every second it does what is suggested and
computers the difference i
t...@leapsecond.com said:
> You only need enough bits to cover the worst case OCXO frequency drift or
> the worst case GPS jitter error, per second. For example, if your OCXO stays
> accurate to 1 ppm it can't possibly drift more than 1 us per second.
> Similarly, it's a safe assumption that your
> You are right in the I don't even need data cycles. All I want is the
> error which is 5,000,000 minus the count. this is hopefully zero.
Correct. Keep the counter running. No need to zero it, ever. Use differential
measurements. Essentially you are using binary modulus arithmetic.
> This wo
On Wed, Apr 9, 2014 at 11:03 AM, Chris Albertson
wrote:
> On Wed, Apr 9, 2014 at 2:08 AM, Hal Murray
> wrote:
>
> >
> > > Also any code that accesses them needs to do so with interrupts turned
> > > off... otherwise you can wind up with corrupted values.
> >
>
> Forgot if I made this point but i
one of the other values that
> gives 0x9680 as the lower two bytes.
>
> Bob
>
>
>
>>
>> From: Chris Albertson
>>To: Discussion of precise time and frequency measurement
>>Sent: Wednesday, April 9, 2014 6:35 PM
>>Subject: Re: [time-nuts
ower two bytes.
Bob
>
> From: Chris Albertson
>To: Discussion of precise time and frequency measurement
>Sent: Wednesday, April 9, 2014 6:35 PM
>Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO,
>under $8
>
>
>On
On Wed, Apr 9, 2014 at 1:04 PM, Tom Harris wrote:
> Another point with the software is that your handler for the PPS just reads
> the counter. This gives an offset between the PPS edge and the value read,
> as your software takes time to respond to the interrupt and read the
> counter. In your cod
Well, where interrupts are involved, NEVER assume something about how the
code SHOULD/MIGHT be working. It is easy enough to disable interrupts before
accessing the volatile variables and restore them afterwards. This is by far
the simplest and most reliable way to do it correctly (no messy
Another point with the software is that your handler for the PPS just reads
the counter. This gives an offset between the PPS edge and the value read,
as your software takes time to respond to the interrupt and read the
counter. In your code, it doesn't matter as you only have one interrupt.
Howeve
> From: Brian Lloyd
>To: Discussion of precise time and frequency measurement
>Sent: Wednesday, April 9, 2014 3:17 PM
>Subject: Re: [time-nuts] First success with very simple, very low cost GPSDO,
>under $8
>
>
>On Wed, Apr 9, 2014 at 1:34 PM, Hal Murray wrote:
On Wed, Apr 9, 2014 at 1:34 PM, Hal Murray wrote:
>
> > But I think you over looked one point that makes this project easier: We
> > KNOW 100% for certain that the interrupts happen only once per second.
> So
> > the foreground code knows for certain it has exclusive access to shared
> > variab
On Wed, Apr 9, 2014 at 11:18 AM, Hal Murray wrote:
>
> I think you can turn that into a feature. Suppose you start with the
> DAC/OCXO running at exactly 10 MHz, and the phasing such that you are right
> on. Due to noise, the last count will be early and get counted half the
> time. The other h
If my one interrupt per second assumption is wrong the GPS is badly
broken and nothing I can do will make the gpsdo work. In a final
system I should try and detect violations of the assumption and go
into hold over mode. That said I tried a test where I took the
interrupt line in my hand and rubb
> But I think you over looked one point that makes this project easier: We
> KNOW 100% for certain that the interrupts happen only once per second. So
> the foreground code knows for certain it has exclusive access to shared
> variables for a given period of time. There is zero chance of a prob
> Actaully I don't care much about an "off by one" count because the problem
> is corrected in the next second. If I happen to miss a count one second the
> very next second this shows up as an extra count.I notice that something
> like this happens every few hundred seconds.
I think you ca
On Wed, Apr 9, 2014 at 2:08 AM, Hal Murray wrote:
>
> > Also any code that accesses them needs to do so with interrupts turned
> > off... otherwise you can wind up with corrupted values.
>
Forgot if I made this point but in a GPSDO when the interrupt is caused by
the PPS, the interrupts are in
On Wed, Apr 9, 2014 at 9:39 AM, Orin Eman wrote:
> On Wed, Apr 9, 2014 at 2:08 AM, Hal Murray
> wrote:
>
> The order the interrupt routine updates the counter shouldn't matter since
> it's atomic as far as the mainline code is concerned.
>
>
In my case it's the other way around, the 16 bit co
On Tue, Apr 8, 2014 at 10:44 PM, Mark Sims wrote:
> I'm not sure how the Arduino environment handles interrupts, but in C you
> need to declare any variables altered by an interrupt as "volatile" so that
> the compiler optimization routines know not to assume they contain known
> values.
> Also
On Wed, Apr 9, 2014 at 2:08 AM, Hal Murray wrote:
>
> hol...@hotmail.com said:
> > I'm not sure how the Arduino environment handles interrupts, but in C
> you
> > need to declare any variables altered by an interrupt as "volatile" so
> that
> > the compiler optimization routines know not to assu
hol...@hotmail.com said:
> I'm not sure how the Arduino environment handles interrupts, but in C you
> need to declare any variables altered by an interrupt as "volatile" so that
> the compiler optimization routines know not to assume they contain known
> values.
Good point.
> Also any code t
I'm not sure how the Arduino environment handles interrupts, but in C you need
to declare any variables altered by an interrupt as "volatile" so that the
compiler optimization routines know not to assume they contain known values.
Also any code that accesses them needs to do so with interrupt
I just had some success with a new GPSDO based very much on Lars Walenius'
design
I cut his design and his software down to make it even more simple and cost
less. The controller is now well under $8. The software is also much
simpler and easy to read even if you are not a "software guy".
Lars'
41 matches
Mail list logo
