Re: [time-nuts] Maser on a chip

2015-01-26 Thread Bill Byrom
I have a Science subscription so can read the complete paper and
supplementary material. Their current device has about two orders of
magnitude greater linewidth (34 kHz) than the ~400 Hz linewidth
predicted from maser theory. The coherence time is ~9.4 us. They suggest
this is due to charge flunctuations, and show time domain examples of
the I/Q downconverted signal with discontinuities where the device drops
out of masing. 

This is a moderately complex experimental setup, with very low signal
levels requiring a superconducting Josephson parametric amplifier for
some measurements at a reasonably S/N. The device maser cavity is
superconducting. 

I agree that this is an initial proof of concept demonstrating masing
with quantum dots.
-- 
Bill Byrom N5BB
Tektronix RF Application Engineer

On Tue, Jan 20, 2015, at 01:51 AM, Attila Kinali wrote:
 On Sun, 18 Jan 2015 22:59:57 +
 Mark Sims hol...@hotmail.com wrote:
 
  http://www.princeton.edu/main/news/archive/S42/13/37M75/index.xml
  Not much detail there...  but there is an article in Science.
 
 It looks like the supplemantary material[1] of the paper isnt behind a
 pay wall.
 
 
   Attila Kinali
 
 
 [1] http://www.sciencemag.org/content/347/6219/285/suppl/DC1
 -- 
 It is upon moral qualities that a society is ultimately founded. All 
 the prosperity and technological sophistication in the world is of no 
 use without that foundation.
  -- Miss Matheson, The Diamond Age, Neil Stephenson
 ___
 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] D term (was no subject)

2015-01-26 Thread Jim Lux

On 1/25/15 1:30 PM, WarrenS via time-nuts wrote:


I second  Poul-Henning Kamp's comments concerning D-terms,
(mostly) as done in the TBolt and likely other GPSDOs.





Bear in mind that a PID loop is basically a fairly simple control loop 
that is easily susceptible to linear analysis.
They're simple to implement with analog controls, they're simple to 
analyze, and for a whole lot of applications, they'll work just fine.


And there's decades, if not centuries, of experience with P, PI and PID 
controllers in a practical sense.  A lot of people know how to *tune* 
the parameters based on observed system dynamics.



But for a lot of systems:ones where there are significant nonlinearities 
and/or time delays and/or saturation/limiting effects a PID loop might 
not be a good choice.  (for instance, if you're doing a closed loop 
position control with a stepper motor as the actuator, with a small 
motor and a big heavy load, with low friction...)


For myself, I am seduced by the idea of a control system that builds and 
adjusts a model of the system being controlled, and then derives the 
needed control inputs from inverting that model (whether arithmetically, 
or by some clever algorithmic means).


For instance, a PID controller doing temperature control doesn't have a 
*good* way of incorporating side information like the outside 
temperature.  There's all kinds of schemes for doing this (double loops, 
extra terms, etc.)



___
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] Help me make some sense of adev measurements of SR620'sown clock

2015-01-26 Thread Dr. David Kirkby (Kirkby Microwave Ltd)
On 25 Jan 2015 23:02, Tom Van Baak t...@leapsecond.com wrote:

 You're getting 1e-12 at 1 second. Sounds fine to me.

Obviously you have the experience to know that 1e-12 at 1 second is fine.

But if it's possible,  I would like to understand the relationship between
the counters specification and the adev (or one of the modifications of it)
one would expect to see.

Obviously it is nice to know that the counter is working ok, but I would
like to understand how one can ascertain that from the data I recorded,
based on the SR620's specifications.

 Also, when you plot phase with TimeLab you'll notice a jump around
T+23600 seconds. This is likely you breathing near the instrument, or
touching a cable, or closing a door.

That's interesting.  It is about 4:30 am local time here, so when I was
asleep. I would have expected data then to be better than during the day
when I move around. The biggest disturbance occurred at a time I would have
least expected it.

  Do most people save time information as I have done there, or phase
  information?

 Always save phase. Not sure what you mean by time.
The counter can measure the time between the start and stop inputs, which
is what I done. The numbers are around 17.5 ns due to the cable length.

But instead of saving those time values, I could have configured the
counter to save the phase in the range -180 to +180 degrees. Your adev1
programe expected time in seconds rather than phase in degrees, which is
why I saved time rather than phase.  But I will use adev5 as you
suggested.  I used adev1 primarily since you had a web page on it.

I am not talking about elapsed time, time of the day etc. That's something
quite different.

 Even better is to save both phase and elapsed time or real time; the
latter can be used as a check that your sample rates are what you expect.

I did save elapsed time as you can see. I was in fact a bit surprised that
the data points are spaced very slightly *less* than a second apart. I
would have expected the data to take 1 second to collect, then some time
processing time, especially since I introduced a delay of about 200 us to
stop the GPIB reads randomly failing.   That's a bit of a mystery.

 Personally, I prefix every ascii line received with a MJD timestamp. That
way all my log files, everything from counters to temperature sensors to
GPS NMEA lines can all be correlated against themselves and with other
people.

I had never heard of the MJD, but I will do what you suggest.

  Data collection started at: 23:2:55 GMT on 24/01/2015 (day/month/year
format)

 Always use leading zeros for hours, minutes, and seconds.

That was not intensional. I would have intended to put the leading zero.

 The preferred way to write this is simply 2015-01-24 23:02:55 (see ISO
8601).

OK, I'll do that, despite it seems quite unnatural to us brits!

John's software looks impressive. In fact is TimePod hardware too, but far
out of my budget. I will have to make do with the SR620.

I just wish I didn't have to load the data into a Windows program. Maybe at
some point I will try to get gnuplot to do similar.

 /tvb

Thank you Tom. Also to Bob. I will do as Bob suggested and repeat using an
external 10 MHz source, rather than use the counters own timebase.

Dave
___
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] Unique TBolt GPS characteristics

2015-01-26 Thread WarrenS via time-nuts

Another unique thing about the TBolt engine is how fast it can calculate a
Freq change in its 10MHz osc.
Over short times periods, it can be 100 times better than a standard 1PPS
GPS engine.
It would be interesting to compare it to a high end dual freq GPS.

With the Tbolt in manual hold over mode, and using Lady Heather for the
readout,
It takes less than 10 seconds, to measure the freq offset to well under
1e-11.
Typically about 1e-11 freq error in 3 seconds
When setup to use an external freq input, it makes a fast 11 plus digit,
10 MHz freq counter.

The PPT output (osc Freq offset) of the Tbolt, responds to any freq changes
in the next 1 sec output.
How it does this is a mystery to me, because it is not using phase error.
The limit is the noise which is very low.
In a well set up Tbolt, the 1 second PPT freq noise is about 10ppt RMS
(50e-12 PP).
5e-12 with 5sec filter, 3.5e-12 with 10 sec filter and 2.5e-12 with a 50
second filter.
Attached is an old  plot showing the noise floor difference between the
TBolts phase and Freq outputs.

The Uncertainty of a non-sawtooth corrected 1 sec GPS can be around 10 ns
plus, with sawtooth correction that can go down to near 1ns uncertainty
The GPS signal its self has up to a 10 ns uncertainly, so using the 1PPS
signal out of a common GPS engine you get at best a 1e-8 to 1e-9 freq
uncertainty using two readings 1 second apart.

ws
*

This operation is very typical of all of the cell site GPSDO's. The only
part that is unique to the TBolt is the ability to fiddle the loop
characteristics a bit.
bob
And the fact that the GPS's CPU clock is derived from the 10MHz and
therefore aligned to the PPS so there is no hanging bridge and sawtooth
correction is not required.

I am not aware of any other GPSDO implementing that scheme, which is very
elegant in its simplicity.

Didier KO4BB
**

It is indeed an elegant solution. Based on looking at 1 pps outputs on a
group of them over a year or more,  It's actual impact on the control loop
function is pretty minor compared to a properly executed sawtooth correction
process. It would have a significant advantage if compared to a GPSDO that
does not use sawtooth correction.

Bob
___
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] LTE Lite time error

2015-01-26 Thread Bill Beam
Odd indeed.  My LTE-lite is one second late, appears to have already added the 
pending leap second.
I can compare with four other GPS timeing receivers using time pulse on DCD 
line.  The NMEA data
reports in error.  I am awaiting reply from JL.  This is not good for an eBay 
sniper

Bill, NL7F

On Sun, 25 Jan 2015 12:12:55 -0800, Tom Van Baak wrote:

Hi Paul,

Odd, my LTE-Lite appears spot on. Let's take this off-list and see what's 
going on.

If anyone else has been logging SkyTraq NMEA or binary from the LTE-Lite let 
us know.


Bill Beam
NL7F



___
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] D term (was no subject)

2015-01-26 Thread Didier Juges
Maybe we are getting a little off-topic here, but a very long time ago I
was dealing with industrial ovens used to braze ceramics used to make
microwave tubes.
It was very difficult to maintain the precise temperature ramp up and down,
particularly as the oven was not always loaded the same way.

In order to automatically compensate for different oven loading (and
ambient conditions), the controller injected a very low level random
noise over the temperature setting and by analyzing how that noise was
filtered by going through the oven, was able to determine the response of
the oven itself and from that optimize the PID terms in real time as a
function of the load. This was in the early 80's. It was pretty hot stuff
then, even for an oven :)

Didier KO4BB


On Sun, Jan 25, 2015 at 8:12 PM, Jim Lux jim...@earthlink.net wrote:

 On 1/25/15 1:30 PM, WarrenS via time-nuts wrote:


 I second  Poul-Henning Kamp's comments concerning D-terms,
 (mostly) as done in the TBolt and likely other GPSDOs.




 Bear in mind that a PID loop is basically a fairly simple control loop
 that is easily susceptible to linear analysis.
 They're simple to implement with analog controls, they're simple to
 analyze, and for a whole lot of applications, they'll work just fine.

 And there's decades, if not centuries, of experience with P, PI and PID
 controllers in a practical sense.  A lot of people know how to *tune* the
 parameters based on observed system dynamics.


 But for a lot of systems:ones where there are significant nonlinearities
 and/or time delays and/or saturation/limiting effects a PID loop might not
 be a good choice.  (for instance, if you're doing a closed loop position
 control with a stepper motor as the actuator, with a small motor and a big
 heavy load, with low friction...)

 For myself, I am seduced by the idea of a control system that builds and
 adjusts a model of the system being controlled, and then derives the needed
 control inputs from inverting that model (whether arithmetically, or by
 some clever algorithmic means).

 For instance, a PID controller doing temperature control doesn't have a
 *good* way of incorporating side information like the outside temperature.
 There's all kinds of schemes for doing this (double loops, extra terms,
 etc.)



 ___
 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] Tek FCA3100/Pendulum CNT91 vs Keysight/Agilen 53230A

2015-01-26 Thread James via time-nuts
Hi Time Nuts

This is my first posting on Time-Nuts though I've been reading others postings 
for quite a while.

I am thinking of upgrading my very basic counter but only have limited lab 
space which rules out the SRS 620 on the basis of physical size.

Tektronix are offering an ex demo FCA3100 (which I think is a rebadged Pendulum 
CNT91) and the other choice seems to be to wait for the Keysight store to get 
some more 53230As in (I missed out on the last lot about six months ago).

I am finding it hard to compare the FCA3100 to the 53230 in terms of practical 
differences (as apposed to the data sheet numbers).

The key difference seems to be the single shot resolution of 20 psecs for the 
53230A compared to 50 psecs for the FCA3100. I've seen three sets of results 
for the 53230A which actually measure around 8 to 11 psecs (using the delay of 
a length of coax method).

But I've not seen any practical results for the FCA3100. If it is up at the 50 
psec mark and the 53230A is really nearer 10 psecs then the difference between 
the two is even more marked than the data sheet numbers.

Have any owners of the FCA3100/CNT 91 done such measurements?

The FCA3100's main advantage over the 53230A is that it is cheaper but it also 
seems to have higher voltage resolution (1mV vs 2.5mV) and less noise (200 uV 
vs 350uV typical) and it has a pulse generator that I might find quite useful.

Is there anything else I should consider?

Any practical info/advice would be much appreciated. I'm hoping to use it for 
general GPSDO development and other experiments.

James
___
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] D term (was no subject)

2015-01-26 Thread Jim Lux

On 1/26/15 5:55 AM, Poul-Henning Kamp wrote:


In message 54c5a270.7090...@earthlink.net, Jim Lux writes:


And there's decades, if not centuries, of experience with P, PI and PID
controllers in a practical sense.


Not quite a century I belive:  Only the advent of electronics formalized
the theory and developed the practice.

Almost all mechanical governors er pure P.





Maxwell strikes again

http://upload.wikimedia.org/wikipedia/commons/b/b1/On_Governors.pdf

definitely more than P controllers..

cups with liquid (Siemens governor), nonlinear mechanisms, etc.

___
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] LTE Lite time error

2015-01-26 Thread Keith Loiselle
We have confirmed this issue with the Skytraq firmware on the LTE-Lite and
are working with Skytraq to obtain a firmware update.  I will post again
when a firmware update is available.

Keith


Keith

On Sun, Jan 25, 2015 at 5:47 PM, Bill Beam wb...@gci.net wrote:

 Odd indeed.  My LTE-lite is one second late, appears to have already added
 the pending leap second.
 I can compare with four other GPS timeing receivers using time pulse on
 DCD line.  The NMEA data
 reports in error.  I am awaiting reply from JL.  This is not good for an
 eBay sniper

 Bill, NL7F

 On Sun, 25 Jan 2015 12:12:55 -0800, Tom Van Baak wrote:

 Hi Paul,

 Odd, my LTE-Lite appears spot on. Let's take this off-list and see what's
 going on.

 If anyone else has been logging SkyTraq NMEA or binary from the LTE-Lite
 let us know.


 Bill Beam
 NL7F



 ___
 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] question Alan deviation measured with Timelab and counters

2015-01-26 Thread Bruce Griffiths
The performance of the 2 systems should be comparable provided the similar 
equivalent noise bandwidths are used.Every 10Mhz edge needs to be timestamped 
with ps resolution and the resulting phase samples low pass filtered and 
decimated to achieve this.The 10MSPS picosecond or better resolution time 
stamping with femtosecond integral linearity will be a bit of a challenge to 
achieve.
Bruce 

 On Tuesday, 27 January 2015 3:26 PM, Stéphane Rey steph@wanadoo.fr 
wrote:
   

 I do understand. 
Has anyone already compared the performances of squaring the 10 MHz vs squaring 
the IF ? 

Stephane

-Message d'origine-
De : time-nuts [mailto:time-nuts-boun...@febo.com] De la part de Bob Camp
Envoyé : dimanche 25 janvier 2015 19:01
À : Discussion of precise time and frequency measurement
Objet : Re: [time-nuts] question Alan deviation measured with Timelab and 
counters

Hi

The approach in the original NIST paper below was sort of a “best guess” about 
how to do the limiting and filtering. When the paper was presented, a number of 
us questioned how that part of the circuit was arrived at. The conversation 
more or less ended up with “that’s something we can investigate further”. The 
Collins paper (and Bruce’s work based on it) is a much better way to look at 
the 10 Hz squaring process. At 10 MHz, that stuff is not needed.

Bob

 On Jan 25, 2015, at 10:44 AM, Stéphane Rey steph@wanadoo.fr wrote:
 
 Hi everyone.
 
 Many thanks for your very useful comments.
 I had already seen most of the documents you were pointing but not on 
 the collins and Bruce discussion around the multistage filter. However 
 I've already seen this approach in the document from Allan
 (http://tf.nist.gov/timefreq/general/pdf/84.pdf)
 
 At first I had in mind to square the 10 MHz but this is the aim of the 
 evaluation board to evaluate various architectures. So I will 
 implement several squarers including the Collins Approach both at 10 
 MHz and 100 Hz and all the blocks will have input and output 
 connectors so that I will be able to test several layouts.
 
 I will show you the final design.
 
 Cheers
 Stephane
 
 
 -Message d'origine-
 De : time-nuts [mailto:time-nuts-boun...@febo.com] De la part de 
 Charles Steinmetz Envoyé : dimanche 25 janvier 2015 08:08 À : 
 Discussion of precise time and frequency measurement Objet : Re: 
 [time-nuts] question Alan deviation measured with Timelab and counters
 
 Stephane wrote:
 
 I'm now trying to evaluate various architectures of 2-channels 
 squarers and a DMDT. For that I'm designing a PCB with 4 squarers :
 simple 74ac04 gate biased at VCC/2, a LT1016 comparator, the 
 transistor based differential amplifier from Winzel and the one from Charles.
 
 Note that squaring a 10MHz sine wave and squaring a 10 or 100Hz mixer 
 output are two very different tasks.  If you start at baseband, a 
 Collins-style multi-stage limiting amp is a great benefit.  That is 
 generally not necessary if you start at 10MHz (or if you do use a 
 Collins-style limiter it needs far fewer stages).  All of the squarers 
 you mention work well at 10MHz, but not as well at baseband.
 
 The LT1719 is easier to apply and faster than the LT1016.  You may 
 want to use that instead of the 1016.  The LT1719 and LT1715 
 datasheets show the simplest possible implementation (see below).
 
 The MPSH81 devices in my version are available in surface-mount
 (MMBTH81) if that is more convenient.  Other fast transistors will 
 also work (BFT92, BFT93, BFG31).
 
 Best regards,
 
 Charles
 
 
 
 ---
 L'absence de virus dans ce courrier électronique a été vérifiée par le 
 logiciel antivirus Avast.
 http://www.avast.com
 
 ___
 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.



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com

___
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] question Alan deviation measured with Timelab and counters

2015-01-26 Thread Stéphane Rey
I do understand. 
Has anyone already compared the performances of squaring the 10 MHz vs squaring 
the IF ? 

Stephane

-Message d'origine-
De : time-nuts [mailto:time-nuts-boun...@febo.com] De la part de Bob Camp
Envoyé : dimanche 25 janvier 2015 19:01
À : Discussion of precise time and frequency measurement
Objet : Re: [time-nuts] question Alan deviation measured with Timelab and 
counters

Hi

The approach in the original NIST paper below was sort of a “best guess” about 
how to do the limiting and filtering. When the paper was presented, a number of 
us questioned how that part of the circuit was arrived at. The conversation 
more or less ended up with “that’s something we can investigate further”. The 
Collins paper (and Bruce’s work based on it) is a much better way to look at 
the 10 Hz squaring process. At 10 MHz, that stuff is not needed.

Bob

 On Jan 25, 2015, at 10:44 AM, Stéphane Rey steph@wanadoo.fr wrote:
 
 Hi everyone.
 
 Many thanks for your very useful comments.
 I had already seen most of the documents you were pointing but not on 
 the collins and Bruce discussion around the multistage filter. However 
 I've already seen this approach in the document from Allan
 (http://tf.nist.gov/timefreq/general/pdf/84.pdf)
 
 At first I had in mind to square the 10 MHz but this is the aim of the 
 evaluation board to evaluate various architectures. So I will 
 implement several squarers including the Collins Approach both at 10 
 MHz and 100 Hz and all the blocks will have input and output 
 connectors so that I will be able to test several layouts.
 
 I will show you the final design.
 
 Cheers
 Stephane
 
 
 -Message d'origine-
 De : time-nuts [mailto:time-nuts-boun...@febo.com] De la part de 
 Charles Steinmetz Envoyé : dimanche 25 janvier 2015 08:08 À : 
 Discussion of precise time and frequency measurement Objet : Re: 
 [time-nuts] question Alan deviation measured with Timelab and counters
 
 Stephane wrote:
 
 I'm now trying to evaluate various architectures of 2-channels 
 squarers and a DMDT. For that I'm designing a PCB with 4 squarers :
 simple 74ac04 gate biased at VCC/2, a LT1016 comparator, the 
 transistor based differential amplifier from Winzel and the one from Charles.
 
 Note that squaring a 10MHz sine wave and squaring a 10 or 100Hz mixer 
 output are two very different tasks.  If you start at baseband, a 
 Collins-style multi-stage limiting amp is a great benefit.  That is 
 generally not necessary if you start at 10MHz (or if you do use a 
 Collins-style limiter it needs far fewer stages).  All of the squarers 
 you mention work well at 10MHz, but not as well at baseband.
 
 The LT1719 is easier to apply and faster than the LT1016.  You may 
 want to use that instead of the 1016.  The LT1719 and LT1715 
 datasheets show the simplest possible implementation (see below).
 
 The MPSH81 devices in my version are available in surface-mount
 (MMBTH81) if that is more convenient.  Other fast transistors will 
 also work (BFT92, BFT93, BFG31).
 
 Best regards,
 
 Charles
 
 
 
 ---
 L'absence de virus dans ce courrier électronique a été vérifiée par le 
 logiciel antivirus Avast.
 http://www.avast.com
 
 ___
 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.



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com

___
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] LTE Lite time error

2015-01-26 Thread Keith Loiselle
Skytraq has also confirmed the issue and is working on a firmware update.
Updating the Skytraq firmware on the LTE-Lite Eval Board requires the unit
be returned to Jackson Labs for reprogramming.  We will update the Skytraq
firmware on units at no charge if units are returned to us.  Please contact
us off list to make arrangements for returns.

Also, the ROM firmware in the Skytraq does not exhibit this issue, so
selecting the ROM boot with a jumper between pins 1 and 2 of J3 is a
work-around.  When making the J3 connection, be sure to remove power to the
board to avoid corrupting the flash.  The LTE-Lite will operate in a mobile
mode without sawtooth correction when the Skytraq is booted from ROM.

Thanks,
Keith


Keith

On Mon, Jan 26, 2015 at 10:43 AM, Keith Loiselle keith.loise...@gmail.com
wrote:

 We have confirmed this issue with the Skytraq firmware on the LTE-Lite and
 are working with Skytraq to obtain a firmware update.  I will post again
 when a firmware update is available.

 Keith


 Keith

 On Sun, Jan 25, 2015 at 5:47 PM, Bill Beam wb...@gci.net wrote:

 Odd indeed.  My LTE-lite is one second late, appears to have already
 added the pending leap second.
 I can compare with four other GPS timeing receivers using time pulse on
 DCD line.  The NMEA data
 reports in error.  I am awaiting reply from JL.  This is not good for an
 eBay sniper

 Bill, NL7F

 On Sun, 25 Jan 2015 12:12:55 -0800, Tom Van Baak wrote:

 Hi Paul,

 Odd, my LTE-Lite appears spot on. Let's take this off-list and see
 what's going on.

 If anyone else has been logging SkyTraq NMEA or binary from the LTE-Lite
 let us know.


 Bill Beam
 NL7F



 ___
 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] LTE Lite time error

2015-01-26 Thread Bill Beam
Be careful with 'eyeball data'.  GPS receiver does not generate NMEA time data 
and the leading edge of PPS at the same time.
Programs like Tac32 (totally accurate clock) and Lady Heather increment the 
time display at the leading edge of PPS with a
value 1 second greater than the previous NMEA data time.

I am able to run multiple GPS receivers into multiple computers running Tac32.  
The LTE-lite displays one second earlier than
all the others.

Prior to the announcement of Leap Second Pending in the GPS data stream the 
LTE-lite agreed with all other units.  Now it does not.

On Mon, 26 Jan 2015 22:59:36 +0100, Mike Cook wrote:

Yes there is certainly an error here:
With my timing module I was just eyeballing the output on a windows platform , 
comparing GUI data.
I have just linked the module up to a BeagleBone Black syncG€™d with NTP and 
this is the NMEA msg log:

root@bb3:/home/mike/serial-ports# while read GGA; do echo `date` $GGA; done  
/dev/ttyO4
Mon Jan 26 21:51:07 UTC 2015 
$GPGGA,215106.000,4847.3526,N,00216.3005,E,1,04,2.8,192.8,M,47.0,M,,*5C
Mon Jan 26 21:51:07 UTC 2015 $GPGLL,4847.3526,N,00216.3005,E,215106.000,A,A*56
Mon Jan 26 21:51:07 UTC 2015 $GPGSA,A,3,25,12,06,31,3.0,2.8,1.0*3A
Mon Jan 26 21:51:07 UTC 2015 
$GPRMC,215106.000,A,4847.3526,N,00216.3005,E,000.0,173.5,260115,,,A*60
Mon Jan 26 21:51:07 UTC 2015 $GPVTG,173.5,T,,M,000.0,N,000.0,K,A*0D
Mon Jan 26 21:51:07 UTC 2015 $GPZDA,215106.000,26,01,2015,00,00*54
Mon Jan 26 21:51:07 UTC 2015 $PSTI,00,2,0,4.6,,*30

snip

The time data is all a second late so they appear to have a serious issue.

 Le 26 janv. 2015 +  02:47, Bill Beam wb...@gci.net a +ªcrit :

snip

 Odd indeed.  My LTE-lite is one second late, appears to have already added 
 the pending leap second.
 I can compare with four other GPS timeing receivers using time pulse on DCD 
 line.  The NMEA data
 reports in error.

snip



Bill Beam
NL7F



___
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] D term (was no subject)

2015-01-26 Thread Poul-Henning Kamp

In message 5E5E892CF8A2440FBF18FFAD000B65FD@NewComputer, Lee Mushel writes:

I'm fairly sure that Jim is right.   I never had to worry about PID machine 
control before the late sixties and by the mid-seventies the concepts were 
firmly in place and in use.

The basic math of PID has been around for about 100 years.  The invention
of the servo (and synchro/resolver) is what makes its day...

 Almost all mechanical governors er pure P.

 Maxwell strikes again

 http://upload.wikimedia.org/wikipedia/commons/b/b1/On_Governors.pdf

 definitely more than P controllers..

I said Almost all... :-)

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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] LTE Lite time error

2015-01-26 Thread Mike Cook
Yes there is certainly an error here:
With my timing module I was just eyeballing the output on a windows platform , 
comparing GUI data.
I have just linked the module up to a BeagleBone Black sync’d with NTP and this 
is the NMEA msg log:

root@bb3:/home/mike/serial-ports# while read GGA; do echo `date` $GGA; done  
/dev/ttyO4
Mon Jan 26 21:51:07 UTC 2015 
$GPGGA,215106.000,4847.3526,N,00216.3005,E,1,04,2.8,192.8,M,47.0,M,,*5C
Mon Jan 26 21:51:07 UTC 2015 $GPGLL,4847.3526,N,00216.3005,E,215106.000,A,A*56
Mon Jan 26 21:51:07 UTC 2015 $GPGSA,A,3,25,12,06,31,3.0,2.8,1.0*3A
Mon Jan 26 21:51:07 UTC 2015 
$GPRMC,215106.000,A,4847.3526,N,00216.3005,E,000.0,173.5,260115,,,A*60
Mon Jan 26 21:51:07 UTC 2015 $GPVTG,173.5,T,,M,000.0,N,000.0,K,A*0D
Mon Jan 26 21:51:07 UTC 2015 $GPZDA,215106.000,26,01,2015,00,00*54
Mon Jan 26 21:51:07 UTC 2015 $PSTI,00,2,0,4.6,,*30
Mon Jan 26 21:51:08 UTC 2015 
$GPGGA,215107.000,4847.3526,N,00216.3005,E,1,04,2.8,192.8,M,47.0,M,,*5D
Mon Jan 26 21:51:08 UTC 2015 $GPGLL,4847.3526,N,00216.3005,E,215107.000,A,A*57
Mon Jan 26 21:51:08 UTC 2015 $GPGSA,A,3,25,12,06,31,3.0,2.8,1.0*3A
Mon Jan 26 21:51:08 UTC 2015 
$GPGSV,3,1,10,25,73,294,42,12,59,063,44,14,45,264,20,29,41,196,25*7B
Mon Jan 26 21:51:08 UTC 2015 
$GPGSV,3,2,10,24,34,136,13,02,28,091,21,31,22,306,34,06,19,047,37*74
Mon Jan 26 21:51:08 UTC 2015 $GPGSV,3,3,10,32,03,310,,03,01,347,*7A
Mon Jan 26 21:51:08 UTC 2015 
$GPRMC,215107.000,A,4847.3526,N,00216.3005,E,000.0,173.5,260115,,,A*61
Mon Jan 26 21:51:08 UTC 2015 $GPVTG,173.5,T,,M,000.0,N,000.0,K,A*0D
Mon Jan 26 21:51:08 UTC 2015 $GPZDA,215107.000,26,01,2015,00,00*55
Mon Jan 26 21:51:08 UTC 2015 $PSTI,00,2,0,-3.9,,*15

The time data is all a second late so they appear to have a serious issue.

I module I have is the NS-T from NavSpark, so I will get on to them to see if 
they have a fix. Updates later.


Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une 
petite et provisoire sécurité, ne méritent ni liberté ni sécurité.
Benjimin Franklin

 Le 26 janv. 2015 à 02:47, Bill Beam wb...@gci.net a écrit :
 
 Odd indeed.  My LTE-lite is one second late, appears to have already added 
 the pending leap second.
 I can compare with four other GPS timeing receivers using time pulse on DCD 
 line.  The NMEA data
 reports in error.  I am awaiting reply from JL.  This is not good for an eBay 
 sniper
 
 Bill, NL7F
 
 On Sun, 25 Jan 2015 12:12:55 -0800, Tom Van Baak wrote:
 
 Hi Paul,
 
 Odd, my LTE-Lite appears spot on. Let's take this off-list and see what's 
 going on.
 
 If anyone else has been logging SkyTraq NMEA or binary from the LTE-Lite let 
 us know.
 
 
 Bill Beam
 NL7F
 
 
 
 ___
 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] D term (was no subject)

2015-01-26 Thread Poul-Henning Kamp

In message CAMQqFumOdB4gcFfQjQ_nced0C_U=fbmyofwl7vuxm8wotqg...@mail.gmail.com
, Didier Juges writes:

In order to automatically compensate for different oven loading (and
ambient conditions), the controller injected a very low level random
noise over the temperature setting and by analyzing how that noise was
filtered by going through the oven, was able to determine the response of
the oven itself and from that optimize the PID terms in real time as a
function of the load. This was in the early 80's. It was pretty hot stuff
then, even for an oven :)

Many off the shelf temperature controllers have an auto-tune button
these days which does exactly that:  Inject a heat-pulse, see what
happens, do math...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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] D term (was no subject)

2015-01-26 Thread Lee Mushel
I'm fairly sure that Jim is right.   I never had to worry about PID machine 
control before the late sixties and by the mid-seventies the concepts were 
firmly in place and in use.   It certainly was the appearance of solid state 
industrial controls which made it all possible.   And those ideas have made 
possible some system performance that I recall as being impossible only a 
few years earlier.


Lee Mushel
- Original Message - 
From: Jim Lux jim...@earthlink.net
To: Poul-Henning Kamp p...@phk.freebsd.dk; Discussion of precise time 
and frequency measurement time-nuts@febo.com

Sent: Monday, January 26, 2015 8:21 AM
Subject: Re: [time-nuts] D term (was no subject)



On 1/26/15 5:55 AM, Poul-Henning Kamp wrote:


In message 54c5a270.7090...@earthlink.net, Jim Lux writes:


And there's decades, if not centuries, of experience with P, PI and PID
controllers in a practical sense.


Not quite a century I belive:  Only the advent of electronics formalized
the theory and developed the practice.

Almost all mechanical governors er pure P.





Maxwell strikes again

http://upload.wikimedia.org/wikipedia/commons/b/b1/On_Governors.pdf

definitely more than P controllers..

cups with liquid (Siemens governor), nonlinear mechanisms, etc.

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