On Dienstag, 3. März 2020 18:41:43 CET Attila Kinali wrote:
> On Tue, 03 Mar 2020 14:42:49 +0100
>
> Matthias Welwarsky wrote:
> > In the meantime, I'm thinking of another modification to make: getting rid
> > of the HC390 ripple counter. I think I might be able to use the STM32 as
> > a
From: folkert
You can also keep the GPU busy. That'll work as well with the bonus that
the main cpu stays mostly idle (iirc) for other tasks.
https://vanheusden.com/ntpheat.cpp
requires https://github.com/mn416/QPULib
===
That's neat! Thanks!
Does anyone have any updates to this gps to work in the present epoch?
A while ago it started setting to 00-07-18 but the seconds time seems ok,
and it locks up ok
Julian
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go
To answer Achim's recent question (that's also been posed by others,
neither Tom nor I are fans of "list scraping" sites like gmane.org.
They offer convenience, but they also divert searches from the canonical
archive at lists.febo.com to their own archives, which may not be
complete. Their
[sorry for breaking the threading, I'm replying from the list archive since
gmane.io does not have this list anymore]
Hi David,
[ntpheat]
> I didn't know about that program and I'd like to try it here. A neat idea.
> Is it available stand-alone - ready to run? I could compile it here given
>
Hi John,
It seems that the time-nuts mailing list has lapsed from gmane.io (if indeed
it got re-subscribed under the new domain, changed from formerly gmane.org)
somewhere in January (there is one later mail from February, but I think
that's courtesy of a cross-posting). Could you check
On Tue, 03 Mar 2020 14:42:49 +0100
Matthias Welwarsky wrote:
> In the meantime, I'm thinking of another modification to make: getting rid of
> the HC390 ripple counter. I think I might be able to use the STM32 as a
> frequency divider. I just have to figure out how to program the timers. What
On Tue, 3 Mar 2020 12:14:37 -0500
Jim Harman wrote:
> I don't understand why you say the DAC should have a resolution of 24-30
> bits. I can see that the loop time constant affects the precision needed in
> the filter calculations, but what does the time constant have to do with
> the needed DAC
Attila,
In your post from October you say,
What, I think, you haven't had a look at is the resolution of your DAC.
> You get, including your resistive divider a 17bit resolution. But this
> is not enough. You want to be able to control the OCXO such, that at
> the loop time constant, you have
On Sun, 1 Mar 2020 07:39:43 -0800
jimlux wrote:
> How does a CSO compare with a Mercury Ion clock - the latter does fit in
> a satellite and is intended to replace the USO kind of function.
They use/used CSO's as local oscillators for the Hg ion clock.
Their first papers ([1] and [2]) used to
On Dienstag, 3. März 2020 14:14:37 CET Attila Kinali wrote:
> N'achmittag!
>
> > No heatsink, just a couple of thermal vias into the ground plane and it
> > gets a bit warm, but not more than 35°C (case temperature). I just
> > checked with a thermocouple.
>
> Ok.. I'm surprised. Is the PCB able
N'achmittag!
On Sun, 01 Mar 2020 01:38:11 +0100
Matthias Welwarsky wrote:
> On Samstag, 29. Februar 2020 20:08:13 CET Attila Kinali wrote:
> > The bulk (ie a bit less than half) of the power is dissipated in U3,
> > which is a 0.5A spec'ed LDO in D3PAK... if it's properly cooled.
> > Your PCB
> Thanks, Adam and Hal. I will have a play. I need to decide which of my
> flock to use, as some already sit in a fairly stable environment, and others
> are doing real work which may be affected by running the CPU at 100%.
>
> OK, there's a non-critical one rather nearer to a CH radiator than
Hi,
On 2020-03-03 09:48, Matthias Welwarsky wrote:
> On Dienstag, 3. März 2020 09:25:13 CET Dana Whitlow wrote:
>> Matthias,
>>
>> You said that the LPRO has a pulling range of 4 PPM. Really? I
>> would think that 4PPB would be much more likely for a Rb.
> Yes, sorry, typing mistake. The user
The source code is here:
https://github.com/ntpsec/ntpsec/blob/master/contrib/ntpheat
It imports ntp.util. But from my rudimentary knowledge of Python I see that
it only uses it to get version number. So I think removing lines 24-29 and
51-53 should make it work without ntpsec.
Cheers,
Adam
On Dienstag, 3. März 2020 09:25:13 CET Dana Whitlow wrote:
> Matthias,
>
> You said that the LPRO has a pulling range of 4 PPM. Really? I
> would think that 4PPB would be much more likely for a Rb.
Yes, sorry, typing mistake. The user guide says "more then +/- 1.5E-9", I
found it more in the
Matthias,
You said that the LPRO has a pulling range of 4 PPM. Really? I
would think that 4PPB would be much more likely for a Rb.
Dana
On Mon, Mar 2, 2020 at 3:21 PM Matthias Welwarsky
wrote:
> On Montag, 2. März 2020 18:32:44 CET Skip Withrow wrote:
> [...]
> > The Thunderbolt DAC steps
On Montag, 2. März 2020 22:20:48 CET Matthias Welwarsky wrote:
> On Montag, 2. März 2020 18:32:44 CET Skip Withrow wrote:
> With a reasonably stable PPS from a timing receiver, just looking at the DAC
> movements, it should not be a problem to have a MDEV of 1e-14'ish for
> tau=1s. The LPRO
18 matches
Mail list logo
