Re: [time-nuts] Vintage Frequency Measurement

2017-02-12 Thread Ilia Platone

Hi,

With low-pass filters, I think.
This is the simplest method: an rc filter and measure is done on the 
capacitor poles.

Ilia.

On 02/12/17 06:08, Scott Stobbe wrote:

I was inspired recently coming across a Lampkin 105 frequency meter, as to
how  frequency measurement was done before counters.

Certainly zero-beating a dial calibrated oscillator, would be one approach.

Is there a standout methodology or instrument predating counters?
___
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.



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Measuring sidereal/solar time? Re: A Leap Second is coming

2016-12-30 Thread Ilia Platone

Brooke,

The problem in radio ground observation can be resolution accuracy, but 
there's also a good transmission into far infrared wavelengths, which 
could require smaller dishes to get stellar images. The problem of far 
IR is the cost of right filters/sensor, which are a bit difficult to find.


Radio objects, on the other hand, can be solved using an interferometer: 
LOFAR interferometers work at frequencies higher than 10MHz, frequencies 
totally transparent to the atmosphere and easily computable even by 
consumer PCs. There is some work done with common PCs using two RTL-SDR 
dongles and two satellite dishes.


see http://www.sbrac.org/files/DTP_RX.pdf

Best Regards,

Ilia.


On 12/30/16 17:18, Brooke Clarke wrote:

Hi Anders:

That's something I've thought about for decades using an optical 
system.  A few  years ago I looked at it again and found that 
astronomical "seeing" limits the accuracy.  So the accuracy achieved 
by a spaceborne "Stellar compass" will be much better than a ground 
based observation.  A radio based observation might work since the 
atmosphere would not be a factor.

http://www.prc68.com/I/StellarTime.shtml



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] FPGA SDR? (GnuRadio related)

2016-12-30 Thread Ilia Platone
I got an old valve radio, an Italian Wundercart FM610, not really The 
radio, but I like it because it can receive MW and SW bands in AM 
modulation :), and FM at 88/110MHz of course. an 82-years old electronic 
friend helped me to get it working and I'm so happy for this.


By the way, I read about various Software Defined Radio projects and got 
interested on this. In past I designed a 30MHz SAR ADC/DAC board using 
an FPGA, and wanted to implement this into an SDR project. This is not 
related to my past posts like astronomy or else: it's only for passion 
and knowledge. Can anyone point me on how to interface with a GnuRadio 
software and on how GnuRadio works? Links and documents are well accepted.


Thanks to everybody,
Best Regards,
Ilia.

--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Measuring sidereal/solar time?

2016-12-30 Thread Ilia Platone

Bruce,

I think that you refer on prjects like Astrometry plate solving. I think 
one should got a reference to get a time reference instead of scope 
"pointing" reference, so, once one's got local coordinates in encoder 
positions, for example the values of the north pole with an alt/az 
mounting, can use a sub/arcsec plate solver to obtain good sidereal 
timing reference. using two encoders helps much.


The problem can be visibility of the reference points, however.

Best Regards,

Ilia.


On 12/30/16 10:59, Bruce Griffiths wrote:

Attila
Lookup "Stellar compass" as used for determining space probe attitude.Can also 
be used to determine the direction of the centre of an image of a field of bright 
stars.Subarcsecond accuracy is fairly routine.Pattern recognition techniques combined 
with measures of the relative brightness of the stars is used to identify them.Subpixel 
accuracy in determining the location of the stellar image centroids is also routine.
There is at least one US PhD thesis on such stellar compass techniques.A 
stellar compass technique has been used to determine the pointing direction of 
small portable telescopes without requiring precision axis encoders etc.
Bruce

 On Friday, 30 December 2016 11:43 PM, Attila Kinali <att...@kinali.ch> 
wrote:
  


  On Fri, 30 Dec 2016 10:59:03 +0200
Anders Wallin <anders.e.e.wal...@gmail.com> wrote:


out of curiosity, are there any amateur/semi-pro experiments that can
measure the length of the solar or sidereal day to sub-millisecond
resolution?
To reproduce data like this:
https://upload.wikimedia.org/wikipedia/commons/5/5b/Deviation_of_day_length_from_SI_day.svg

Something in the sky that goes "ping" every day - detected with a pointing
accuracy of < 1ms/24h or <0.01 arc-seconds (!?). Or perhaps two
satellite-dishes pointed at the sun and noise-correlation/interferometry??

I don't know of any such experiment already performed, but I am not up
to date on what's going on in the hobby astronomy community.

I am not sure whether sub-milisecond resolution is feasible, but
I think the "easiest" method would be to do a "modern" version of
an meridian telescope:

Using a camera fix mounted (ie not moving and if possible vibration isolated)
on a pedestal pointed at the sky, approximately looking south. A simple
webcam would be probably enough for first experiments, as long as you get
a good picture of the stars. A good compact camera which allows to use
a remote shutter with a proper lens and exposure control should be better.
Probably the best resource here are the people/websites that deal with
book scanning, as they tend to automate the whole picture taking process.
Using magic lantern (http://magiclantern.fm) with Canon cameras might
give additional features needed for the task.

>From the pictures taken, calculate the positions of the stars (by fitting
circles onto the bright pixels) and figure out which star is which (using
astronomical list of stars). For this step there is a plethora of open source
astronomical software available, but I don't know how well they fit the task
of figuring out what the position of the stars relative to the camera reference
frame. After that, it's just some simple math of calculating the difference
between the position of the stars and where you would have expecteded them
at the time when the picture has been taken.

Some usefull software projects are:
http://astro.corlan.net/gcx/
http://www.clearskyinstitute.com/xephem/
http://starlink.eao.hawaii.edu/starlink
http://astro.corlan.net/avsomat/index.html
http://rhodesmill.org/pyephem/

HTH

 Attila Kinali



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Measuring sidereal/solar time?

2016-12-30 Thread Ilia Platone
Another solution from ground can be radio observation using a precise 
interferometer: radio wavelengths are transparent to the earth 
atmosphere and there are various references like sun during day, and (if 
antennas are sensible) bright pulsars and other radio sources during night.



Best Regards,

Ilia.


On 12/30/16 10:42, Attila Kinali wrote:

On Fri, 30 Dec 2016 10:59:03 +0200
Anders Wallin <anders.e.e.wal...@gmail.com> wrote:


out of curiosity, are there any amateur/semi-pro experiments that can
measure the length of the solar or sidereal day to sub-millisecond
resolution?
To reproduce data like this:
https://upload.wikimedia.org/wikipedia/commons/5/5b/Deviation_of_day_length_from_SI_day.svg

Something in the sky that goes "ping" every day - detected with a pointing
accuracy of < 1ms/24h or <0.01 arc-seconds (!?). Or perhaps two
satellite-dishes pointed at the sun and noise-correlation/interferometry??

I don't know of any such experiment already performed, but I am not up
to date on what's going on in the hobby astronomy community.

I am not sure whether sub-milisecond resolution is feasible, but
I think the "easiest" method would be to do a "modern" version of
an meridian telescope:

Using a camera fix mounted (ie not moving and if possible vibration isolated)
on a pedestal pointed at the sky, approximately looking south. A simple
webcam would be probably enough for first experiments, as long as you get
a good picture of the stars. A good compact camera which allows to use
a remote shutter with a proper lens and exposure control should be better.
Probably the best resource here are the people/websites that deal with
book scanning, as they tend to automate the whole picture taking process.
Using magic lantern (http://magiclantern.fm) with Canon cameras might
give additional features needed for the task.

>From the pictures taken, calculate the positions of the stars (by fitting
circles onto the bright pixels) and figure out which star is which (using
astronomical list of stars). For this step there is a plethora of open source
astronomical software available, but I don't know how well they fit the task
of figuring out what the position of the stars relative to the camera reference
frame. After that, it's just some simple math of calculating the difference
between the position of the stars and where you would have expecteded them
at the time when the picture has been taken.

Some usefull software projects are:
http://astro.corlan.net/gcx/
http://www.clearskyinstitute.com/xephem/
http://starlink.eao.hawaii.edu/starlink
http://astro.corlan.net/avsomat/index.html
http://rhodesmill.org/pyephem/

HTH

        Attila Kinali



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Logging SPAD pulses on synced devices (was: Linux PPS clues?)

2016-11-22 Thread Ilia Platone

Hi,
Do a SPI bus do this job correctly? I'd have the clock on one line and 
the pulses logged on a second line. Like CLK for clock pulses and 
MOSI/MISO for serial logging of pulses. I'd avoid I2C because of 
addressing packets.


Best Regards,
Ilia


On 11/05/16 04:48, Casey L. Jones wrote:
Yes, you might need a separate dedicated chip to take in the serial 
input steadily. Although you may not. Many serial ports have a small 
buffer to prevent missed serial input when the operating system gets 
distracted with something other than processing serial data.

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



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Logging SPAD pulses on synced devices

2016-11-05 Thread Ilia Platone
Attached to this mail there are three files: the APD.asc LTSpice4 
simulation schematics, a model for the AD8561 comparator, a model for 
the VN2210 mosfet transistor, and a model for the BF959 bipolar transistor.


Please note that the APD model included into the schematics may have 
errors: I took it from an LTSpice demo and adapted on the APDs I have, 
some Marktech MTAPD, and observations made with them.


Unfortunately the boards have been ordered, but components shortening or 
value editing can be done. (the real value of the capacitor of the psu 
is 47uF, for faster rendering I dropped it to a lower value.


Best Regards,
Ilia.

On 11/05/16 06:10, Bruce Griffiths wrote:

Ilia
Circuit diagrams are  posted here from time to time, so it should be OK.
Bruce

 On Saturday, 5 November 2016 7:02 PM, Ilia Platone <i...@iliaplatone.com> 
wrote:
  


  Hi, and thank you for these suggestions.

Currently this project becomes reality (slowly): this kind of
synchronization/grabbing is very interesting, but I need something fast
(I expect the SPAD with active quenching circuitry could output 30ns
pulses, and the quantization frequency I hope to run at is 350/450MHz
range).
Anyway, I found some FPGA code for so fast UART, not difficult to
implement, and using these kind of devices this system you propose can
be built from scratch, including a small buffer.

Can I post an LTSpice drawing for review here describing the active
quenching circuitry?

Best Regards,
Ilia

On 11/05/16 04:48, Casey L. Jones wrote:

Yes, you might need a separate dedicated chip to take in the serial
input steadily. Although you may not. Many serial ports have a small
buffer to prevent missed serial input when the operating system gets
distracted with something other than processing serial data.
___
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.



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

.MODEL VN2210 NMOS (LEVEL=3 RS=0.02 NSUB=3.0E15 DELTA=1.0 KAPPA=1.20 TPG=1 
CGDO=1.61E-10 RD=0.03 VTO=1.650 VMAX=5.0E6 ETA=0.053089 NFS=6.6E10 TOX=725E-10 
LD=1.698E-9 UO=862.425 XJ=6.4666E-7 THETA=1.0E-5 CGSO=4.850E-9 L=4.0E-6 W=85E-3)

.MODEL BF959 NPN(IS=10.2e-15 BF=78.00 NF=1.000 VAF=80.50 IKF=60.00m ISE=16.80p 
NE=2.000 BR=4.000 NR=1.000 VAR=12.00 IKR=90.00m ISC=0.000 NC=2.000 RB=2.060 
IRB=0.000 RBM=0.000 RE=515.0m RC=206.0m CJE=1.740p VJE=1.100 MJE=500.0m 
TF=227.0p XTF=0.000 VTF=0.000 ITF=0.000 PTF=0.000 CJC=2.250p VJC=300.0m 
MJC=300.0m XCJC=1.000 TR=158.0n CJS=0.000 VJS=750.0m MJS=0.000 XTB=1.500 
EG=1.110 XTI=3.000 KF=0.000 AF=1.000 FC=500.0m TNOM=27.00)

* AD8561 SPICE Macro-Model Typical Values
* 4/98, Ver. 1.0
* TAM / ADSC
*
* Node assignments
*   non-inverting input
*   |   inverting input
*   |   |   positive supply
*   |   |   |   negative supply
*   |   |   |   |   Latch
*   |   |   |   |   |   DGND
*   |   |   |   |   |   |   Q
*   |   |   |   |   |   |   |   QNOT
*   |   |   |   |   |   |   |   |
.SUBCKT AD8561  1   2   99  50  80  51  45  65
*
* INPUT STAGE
*
*
Q1 4  3 5 PIX
Q2 6  2 5 PIX
IBIAS 99  5 800E-6
RC14 50 1E3
RC26 50 1E3
CL14  6 1E-12
CIN1  2 3E-12
VCM1  99  7 1
D1 5  7 DX
EOS3  1 POLY(1) (31,98) 1E-3 1
*
* Reference Voltage
*
EREF 98 0 POLY(2) (99,0) (50,0) 0 0.5 0.5
RREF 98 0 100E3
*
* CMRR=80dB, ZERO AT 1kHz
*
ECM1 30 98 POLY(2) (1,98) (2,98) 0 0.5 0.5
RCM1 30 31 10E3
RCM2 31 98 1
CCM1 30 31 15.9E-9
*
* Latch Section
*
RX 80 51 100E3
E1 10 98 (4,6) 1
S1 10 11 (80,51) SLATCH1
R2 11 12 1
C3 12 98 10E-12
E2 13 98 (12,98) 1
R3 12 13 500
*
* Power Supply Section
*
GSY1 99 52 POLY(1) (99,50) 4E-3 -2.6E-4
GSY2 52 50 POLY(1) (99,50) 3.7E-3 -.6E-3
RSY  52 51 10
*
* Gain Stage Av=250 fp=100MHz
*
G2 98 20 (12,98) 0.25
R1 20 98 1000
C1 20 98 10E-13
D2 20 21 DX
D3 22 20 DX
V1 99 21 DC 0.8
V2 22 50 DC 0.8
*
* Q Output
*
Q3  99 41 46 NOX
Q4  47 42 50 NOX
RB1 43 41 200
RB2 40 42 5E3
CB1 99 41 10E-12
CB2 42 50 5E-12
RO1 46 45 2E3
RO2 47 45 500
EO1 98 43 POLY(1) (20,98) 0 1
EO2 40 98 POLY(1) (20,98) 0 1
*
* Q NOT Output
*
Q5  99 61 66 NOX
Q6  67 62 50 NOX
RB3 63 61 200
RB4 60 62 5E3
CB3 99 61 10E-12
CB4 62 50 5E-12
RO3 66 65 2E3
RO4 67 65 500
EO3 63 98 POLY(1) (20,98) 0 1
EO4 98 60 POLY(1) (20,98) 0 1
*
* MODELS
*
.MODEL PIX PNP(BF=100,IS=1E-16)
.MODEL NOX NPN(BF=100,VAF=130,IS=1E-14)
.MODEL DX D(IS=1E-16)
.MODEL SLATCH1 VSWITCH(ROFF=1E6,RON=500,VOFF=2.1,VON=1.4)
.ENDS AD8561
Version 4
SHEET 1 2888 1012
WIRE 208 0 -592 0
WIRE 1456 0 224 0
WIRE 1936 0 1472 0
WIRE 16 144 -64 144
WIRE 112 144 80 144
WIRE 128 144 112 144
WIRE 1216 144 10

Re: [time-nuts] Logging SPAD pulses on synced devices (was: Linux PPS clues?)

2016-11-05 Thread Ilia Platone

Hi, and thank you for these suggestions.

Currently this project becomes reality (slowly): this kind of 
synchronization/grabbing is very interesting, but I need something fast 
(I expect the SPAD with active quenching circuitry could output 30ns 
pulses, and the quantization frequency I hope to run at is 350/450MHz 
range).
Anyway, I found some FPGA code for so fast UART, not difficult to 
implement, and using these kind of devices this system you propose can 
be built from scratch, including a small buffer.


Can I post an LTSpice drawing for review here describing the active 
quenching circuitry?


Best Regards,
Ilia

On 11/05/16 04:48, Casey L. Jones wrote:
Yes, you might need a separate dedicated chip to take in the serial 
input steadily. Although you may not. Many serial ports have a small 
buffer to prevent missed serial input when the operating system gets 
distracted with something other than processing serial data.

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



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Linux PPS clues?

2016-10-21 Thread Ilia Platone
it's a BC546, 10k collector resistor... I thought it was fast enough, 
but also think the signal is inverted, since there's passive quenching 
in this circuit, so the breakdown voltage of the APD is lowering too 
slowly before next photon, causing this kind of positive edge.. if you 
see well there's the same slope in all the signals. I'm currently 
searching for an active quenching circuit that fits into my application.


Best Regards,
Ilia.


On 10/21/16 09:53, Adrian Godwin wrote:

What is the circuit driving that signal ? It appears to have too little
positive drive to overcome the capacitance. Perhaps it's an open collector
with too large a pull-up ?

On 21 Oct 2016 12:23 a.m., "Ilia Platone" <i...@iliaplatone.com> wrote:


sorry, no attachment, this mail contains two images, one is the previous
attempt, the second (IMG_003.JPG) was taken at 5us/div, 1v/div with a
different oscilloscope setup.

Best Regards,
Ilia.

On 10/20/16 18:12, Attila Kinali wrote:


On Thu, 20 Oct 2016 10:59:21 +0100
"David J Taylor" <david-tay...@blueyonder.co.uk> wrote:

Actually, of the 15 Raspberry Pi cards I have only one is used in a

graphics
application.


Yes, the rpi are used for all kind of stuff and there is a huge community
around them that helps with all kind of questions. Unfortunately, the
rpi is also used for all kind of stuff that it is a suboptimal choice
(to put it mildly), but people do not care or do not want to check
for alternatives. It kind of works, that's all they care about.

On the positive side they work very well with external devices for control

and measurement,


And for most of these applications a 32bit uC that uses a fraction of
the power would be the right choice. Often a clock of 1MHz would be
enough.

and have a huge amount of software and hardware support for

a vast range of devices which makes for fast and easy development.


That's the only plus side. But then, most of the code written in C
can be used on a uC just the same with little to no modification.

I will be interested to see what is recommended for a 100 kHz event rate.
This is actually a very tough question. 100kHz means that for each event
there is only 10µs available for detection, processing and output. Using
a uC that would be something in the order of 1000-2000 CPU cycles. On an
application processor (rpi and its cusins) that would be 2000 to 20'000
cycles.
While 1000 cycles on a uC is quite a lot, you cannot do any fancy
processing
with so few cycles.

On the application processor 20k cylces is plenty, but you have the
complex
OS that eats up a few thousand cycles itself. Addtionally there comes
the interrupt latency that the application processors suffer from, which
is in the order of 1-10µs... So they would need a kind of (hardware)
system
to queue up the events to process them in badges. Because of this, an rpi
wouldn't work at all (bitbanging takes several µs for each operation).

Going for an uC is easier in that regard as they have very little
interrupt
latency (usually just 5-10 cycles), but then you have problems with
getting the output out of the uC as their I/O subsystems are usually
optimized to work in a stand-alone fashion.

Maybe one way would be to use an arm9/cortex-a5 based uC (ie not an
application
processor) and use their high speed I/O.

For better answers, I would need to know what kind of events these are
and what exactly need to be done/measured.

     Attila Kinali




--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999


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



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Linux PPS clues?

2016-10-21 Thread Ilia Platone
I really think that a wired correlator would be the best choice... using 
an FPGA :)

Best Regards,
Ilia.

On 10/21/16 06:45, Bruce Griffiths wrote:

Another issue is that the finer the timestamp quantisation step size the larger 
the signal of interest (Intensity correlation). The signal doesn't vanish as 
the timestamp quantisation step size increases however the signal decreases 
requiring a longer observation time to achieve a given SNR. Handwaving without 
calculation to inform the resultant guesses is likely to result in a required 
observation greater than the age of the universe. This of course is 
impractically long. This fundamental error was made by several investigators in 
the some of the first attempts to do intensity interferometry.
Brue

 On Friday, 21 October 2016 7:32 PM, Chris Albertson 
<albertson.ch...@gmail.com> wrote:
  


  On Wed, Oct 19, 2016 at 11:15 PM, Ilia Platone <i...@iliaplatone.com> wrote:


I need to know how much precise this system can be. How much resolution
can I obtain with a cheap receiver (maximum quantization frequency)?
Formulas are well accepted.



Even a cheap receiver will have error that is orders of magnitude smaller
then the resolution that the linux kernel can work in.

You should expect the system time to have error on the order of about 10
microseconds

The PPS signal error comping out of events low cost GPS receiver has error
oon order of say a few tens of nano seconds, that is 100 to 1000 times less
error

The major source of error is not GPS , but is the interrupt latency
uncertainty. But this is not bad at all, you can expect roughly a 10
microsecond uncertainly in the time stamps more or less.

But a lot depends on how you handle the second GPIO interrupt.  the GPS
interrupt is handled inside a kernel level handler.  The handler snap shots
the system clock and stores it in RAM, then sets a flag that the user space
process checks.Does your GPIO interrupt have a kernel level driver to
snapshot the system clock ir is this happening in a user space process?  If
the later expect worse performance.For best performance copy and paste
the Linux PPS code and then re-build the Linux kernel with your new driver.


Getting event time stamps much better then this requires some purpose built
hardware outside of the computer.

Chris Albertson
Redondo Beach, California
___
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.



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Linux PPS clues?

2016-10-20 Thread Ilia Platone



On 10/20/16 22:08, Hal Murray wrote:

i...@iliaplatone.com said:

These events are random photon arrivals (converted to 5vTTL pulses),  their
rate was measured using the pulse width of the smaller detected,  which was
5~10 uS during an observation in low-light environment. The photon arrival
and pulse width were random with a minimum pulse  width of 10uS. What I want
to do is measuring the photon arrival  precisely (low to high transition -
interrupt I guess), consider that  the maximum rate would be 100Kcps because
the photon events would  overlap if higher. If the 3130 controller can
handle such rate it would  be great :)

I think your 100K samples per second is going to be exciting.

You can collect some data by writing some code and connecting up a signal
generator.  Start with a slow frequency to debug the software than turn it up
and see how fast you can go.

I assume it's OK if some (but not many) samples are lost.

You (or I) may be confusing the data rate.  There are two issues.  One is the
peak rate.  That sounds like your 100K above.  The other is the average.  How
many samples do you expect in a typical second?  If that is low enough, you
can solve the peak problem with enough buffering.

My straw man would be a FPGA.  The idea is to collect a batch of pulse
arrival times and DMA them into memory.  When the buffer fills up or a timer
expires, it would finish that block and switch to the next one.  You could
feed a PPS to the FPGA if you want timing linked to the outside world rather
than just relative times.

This was the very first approach. But.. err.. I'm trying to determine 
more precisely the pulse width right now, so the maximum event rate. The 
real problem is my analogue oscilloscope that seems to lose time at peak 
detection: it shows a ramp at each pulse raise.
If this can help, I attach a photo with the reading of my oscilloscope 
(2uS/div, 1V/div). not all pulses saturate, but can be detected by a 
CMOS input. It's difficult to sync because of the high entropy of this 
signal.

Let me know if you can give me any hint on how to setup the oscilloscope..



Best Regards,
Ilia.

--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Linux PPS clues?

2016-10-20 Thread Ilia Platone



On 10/20/16 18:12, Attila Kinali wrote:

On Thu, 20 Oct 2016 10:59:21 +0100
"David J Taylor" <david-tay...@blueyonder.co.uk> wrote:


Actually, of the 15 Raspberry Pi cards I have only one is used in a graphics
application.

Yes, the rpi are used for all kind of stuff and there is a huge community
around them that helps with all kind of questions. Unfortunately, the
rpi is also used for all kind of stuff that it is a suboptimal choice
(to put it mildly), but people do not care or do not want to check
for alternatives. It kind of works, that's all they care about.


On the positive side they work very well with external devices for control
and measurement,

And for most of these applications a 32bit uC that uses a fraction of
the power would be the right choice. Often a clock of 1MHz would be enough.


and have a huge amount of software and hardware support for
a vast range of devices which makes for fast and easy development.

That's the only plus side. But then, most of the code written in C
can be used on a uC just the same with little to no modification.


I will be interested to see what is recommended for a 100 kHz event rate.

This is actually a very tough question. 100kHz means that for each event
there is only 10µs available for detection, processing and output. Using
a uC that would be something in the order of 1000-2000 CPU cycles. On an
application processor (rpi and its cusins) that would be 2000 to 20'000 cycles.
While 1000 cycles on a uC is quite a lot, you cannot do any fancy processing
with so few cycles.
I can use one of my boards, which have (checked better) 6MHz sampling 
frequency on the GPIO, but the sysclock runs at 180MHz, this should be 
enough except logging support bandwidth. check the NXP3130 uC which is 
powering these boards: it's old but its dirty job is done perfectly.

On the application processor 20k cylces is plenty, but you have the complex
OS that eats up a few thousand cycles itself. Addtionally there comes
the interrupt latency that the application processors suffer from, which
is in the order of 1-10µs... So they would need a kind of (hardware) system
to queue up the events to process them in badges. Because of this, an rpi
wouldn't work at all (bitbanging takes several µs for each operation).

Going for an uC is easier in that regard as they have very little interrupt
latency (usually just 5-10 cycles), but then you have problems with
getting the output out of the uC as their I/O subsystems are usually
optimized to work in a stand-alone fashion.
Maybe one way would be to use an arm9/cortex-a5 based uC (ie not an application
processor) and use their high speed I/O.

yes.

For better answers, I would need to know what kind of events these are
and what exactly need to be done/measured.

Attila Kinali
These events are random photon arrivals (converted to 5vTTL pulses), 
their rate was measured using the pulse width of the smaller detected, 
which was 5~10 uS during an observation in low-light environment.
The photon arrival and pulse width were random with a minimum pulse 
width of 10uS. What I want to do is measuring the photon arrival 
precisely (low to high transition - interrupt I guess), consider that 
the maximum rate would be 100Kcps because the photon events would 
overlap if higher. If the 3130 controller can handle such rate it would 
be great :)


Best Regards,
Ilia.

--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Linux PPS clues?

2016-10-20 Thread Ilia Platone
the only essential task is sampling and logging into an usb drive. the 
timestamps must be as accurate as possible with the GPS reference clock. 
This for an undefined number of devices.


Since this 100KHz is a starting point, I must know how fast can be the 
event rate. Linux Clock tick on some boards should be 100ns for example, 
giving a maximum event rate of 5MHz.


I must only ensure if the kpps/gpsd system can have a good accuracy for 
5-8 hours. I own a dozen of the Glomation sbc3130s boards (100MHz / 
12MHz GPIO speed / NXP3130 uC). If these boards can do this work, I'd be 
happy.


Best regards,
Ilia.

On 10/20/16 09:59, David J Taylor wrote:

From: Attila Kinali

[]
Yes, but in embedded there are huge differences between the various
boards and processors. While an rpi is a great device if you want
to do graphics based stuff, it's a very poor choice for control
and measurment applications, or anything that needs fast I/O
[]

Attila Kinali
=

Actually, of the 15 Raspberry Pi cards I have only one is used in a 
graphics application.


On the positive side they work very well with external devices for 
control and measurement, and have a huge amount of software and 
hardware support for a vast range of devices which makes for fast and 
easy development.  On the negative side, certainly they are not the 
fastest of devices, although the current quad-core RPi3 is capable of 
handling thousands of messages per second, and having Ethernet over 
USB won't give the lowest jitter if sub-millisecond timing is important.


I will be interested to see what is recommended for a 100 kHz event rate.

Cheers,
David


--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Linux PPS clues?

2016-10-20 Thread Ilia Platone

Thank you Attila :)

Actually the system for timestamping is at design stage yet.
I expect an event rate of about 100kcps, but I found little infos about 
the bandwidth variable for the receivers.


Since I don't want to fill in the list with off-topic posts, just limit 
in time-related quests.
There's not any problem for the board I'll use, I referenced the 
raspberry because it's well known. My questions are for the software 
side and relative efficiency of the system.


Best Regards,
Ilia.

On 10/20/16 08:01, Attila Kinali wrote:

On Thu, 20 Oct 2016 07:52:10 +
Ilia Platone <i...@iliaplatone.com> wrote:


I quickly read the gpsd howto and it explains what I want to do using
kpps on a raspberry. From there I can see a typical accuracy of 1uS, but
the informations of the live graphs page are precise down to the ns: are
these averaged?

What do you intend for granularity? Consider that I'm a newbie in
frequency/time specific terms.

If you are still going for the synchronization of telescopes, then
you definitly don't want a rpi. Go for one of the more industrial
oriented boards (the original rpi is basically just a graphics card with
an attached arm processor as USB controller). Like the beaglebone,
or probably even better for the Vybrid based boards (Colibry family)
from Toradex (has less EMI noise than the BBB).

Attila Kinali



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Linux PPS clues?

2016-10-20 Thread Ilia Platone

Thank you.

I quickly read the gpsd howto and it explains what I want to do using 
kpps on a raspberry. From there I can see a typical accuracy of 1uS, but 
the informations of the live graphs page are precise down to the ns: are 
these averaged?


What do you intend for granularity? Consider that I'm a newbie in 
frequency/time specific terms.


Regards,
Ilia.



On 10/20/16 07:02, Gary E. Miller wrote:

Yo Ilia!

On Thu, 20 Oct 2016 06:15:39 +
Ilia Platone <i...@iliaplatone.com> wrote:


I am trying to take some timestamps of events on a GPIO using an ARM
SBC, and noticed that the kernel linux can be interfaced to a PPS
signal, wanted to sync another GPIO to a GPS receiver for time
reference.

You should check out the gpsd time howto, and ntpsec.

http://www.catb.org/gpsd/gpsd-time-service-howto.html

https://www.ntpsec.org


I need to know how much precise this system can be. How
much resolution can I obtain with a cheap receiver (maximum
quantization frequency)?

On average, on a RasPi 3, you can expect about


Formulas are well accepted.


How about a graph, or two?  See attached.  From the histogram, I suspect the
granularity is about 200 nano sec.  From the offset graph you can
see how the offset jumps.

Here is the offset data on PPS v. the system clock:
 Percentiles..
 Min1%  5%  50% 95% 99% Max
 -21.645-2.587  -0.834  -0.020  0.991   0.991   13.557 µs

 Ranges..   
 90%95% StdDev  MeanUnits
 1.825  5.318   0.850   -0.006  µs

Or see a lot more live graphs here: https://pi4.rellim.com/day/


RGDS
GARY
---
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com  Tel:+1 541 382 8588


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


--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Linux PPS clues?

2016-10-20 Thread Ilia Platone

Hi all,
I need some clues on the Linux PPS subsystem.
I am trying to take some timestamps of events on a GPIO using an ARM 
SBC, and noticed that the kernel linux can be interfaced to a PPS 
signal, wanted to sync another GPIO to a GPS receiver for time 
reference. I need to know how much precise this system can be. How much 
resolution can I obtain with a cheap receiver (maximum quantization 
frequency)?

Formulas are well accepted.

Thanks,
Ilia.
___
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] Adding holdover to your optical clock...

2016-05-28 Thread Ilia Platone
Thank you for posting, but.. how does the optical strontium clock 
described in the paper work?


Didn't they reach to use a flywheel frequency to regulate it before this?

Regards,

Ilia.


Il 27/05/2016 02:05, Mark Sims ha scritto:

https://www.osapublishing.org/optica/fulltext.cfm?uri=optica-3-6-563=340980  

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



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] 10khz gps board

2016-05-16 Thread Ilia Platone
Thank you all, I have a discrete components OCXO board that needs a 
10MHz down decade clock input, phase looped with its clock and were 
searching for a stable clock.


These boards are what I was searching for, thank you all!

Ilia.


Il 16/05/2016 18:41, rob...@live.nl ha scritto:


On eBay you can find the Navman TU60-D120-131 for USD 25.



Outlook voor Android downloaden






On Mon, May 16, 2016 at 1:07 AM -0700, "Ilia Platone" <i...@iliaplatone.com> 
wrote:





Can anybody here advice me a gps module breakout board with 10KHz
output? I read on some web page that there are some jupiter receivers
that can do this but I can't find any board or receiver with these modules.

I need an output in lower decades than 10MHz, for a test project.
("cheap" if possible)
Thanks in advance
Ilia.
___
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.



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] 10khz gps board

2016-05-16 Thread Ilia Platone
Can anybody here advice me a gps module breakout board with 10KHz 
output? I read on some web page that there are some jupiter receivers 
that can do this but I can't find any board or receiver with these modules.


I need an output in lower decades than 10MHz, for a test project. 
("cheap" if possible)

Thanks in advance
Ilia.
___
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] laser as clock source

2016-05-07 Thread Ilia Platone

Wait... no telescopes, very close distances...

only a laser, with a photon limiter like a dark window, "close" like 
10mm or so... just the space required for the laser optics plus the 
"limiter", and a photon counting detector that can be an APD or a PMT, 
it depends on the size required and scale of integration.


The "idea" came because my professor told me that laser is a light 
source composed by a limited number of harmonics, so close the ones as 
some nm wavelengths, to get these lights can be directional and 
manouverable: if these should be the carachteristics of lasers (a laser 
expert can correct me), photons emitted by this type of light source 
should hit the detector at a constant rate. The (very dark) limiter 
serves to regulate the photon flux so a very limited number of photons 
reach the sensor part.


The question was if the photodetector could use the individual photon 
detection as clock tick, and if these ticks can be regular in frequency. 
Many have replied that it would be noisy: phase noise? I don't think a 
single photon can cause AM noise, because I was talking about single 
photon pulses into the photon counting region, not into the analog 
region. Please correct me if I'm wrong.


Ilia.


Il 05/05/2016 21:22, Hal Murray ha scritto:

jim...@earthlink.net said:

Well, in deep space optical comm, we send many photons with a laser, and  we
use pulse position modulation at the receiver detecting single  photons (or
"few photons"), by which we can send "many bits/photon"  (e.g. if you have
256 possible time slots in which the photon can  arrive, you have 8 bits/
photon)

Neat.  Could you please say a bit more.

What sort of distance?  Bandwidth?  Error rate?

How big is the laser and telescope?   What sort of optics on the receiver?
How hard is it to point the receiver in the right direction?  How hard is it
to point the transmitter telescope?  ...

How does the receiver get timing?




--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] laser as clock source

2016-05-05 Thread Ilia Platone
Is it possible to use the photon flux of a laser as clock source using a 
sensor in photon-counting mode?


Or the photon rate will be chaotic and unstable (as I think but wanted 
to know)?


Regards,
Ilia.

--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] High rate, high precision/accuracy time interval counter methods

2016-05-04 Thread Ilia Platone
For the sensor timestamping you can try replicate an avalanche effect 
with a device which uses a pn-pn substrate configuration ... or 
something similar to the avalanche photodiodes.
The avalanche photodiode has very high gain and a response time of some 
ps (5ps a commercial APD).
This system may cause some effects like high noise and would need high 
breakdown voltages however.
The spurious capacitances can be minimized because in APDs it depends on 
the sensor area, which is not needed in your case.

Regards,
Ilia.

On 05/03/16 12:31, Attila Kinali wrote:

Hi,

We had here a discussion about measuring events (ie time stamping
them precisely) with high rates. As some of you know, Javier and
his group, Bruce and me are working on a system that should give
us something better than 10ps (my guess is that we should get close
to 1ps) at a rate of (guestimated) 1MHz per channel. (Based on the
excitation of a LC tank and measuring the ring-down/phase with an ADC).

As it is with researches, we want the moon, and prossible even more.
So we were talking about getting the measurement rate up even higher,
to 10MHz and if possible 50MHz with the same precision. The above
approche will not work above 1MHz. Using different filters it might
be possible to get it up to maybe 10MHz, but it would be an awkward
design at best.

The only methods I am aware of (and could find) that achieve such high
rates are those, based on (vernier) delay lines (and their equivalent
ring oscillator ones) in ASICs. But this means that a costly ASIC needs
to be produced.

Does someone know of other methods that could achieve high measurements
rates with better than 10ps precision/accuracy? (This question is mostly
a hypothetical question out of interest, I don't plan to build one...yet :-)

Attila Kinali



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] synchronization for telescopes

2016-05-04 Thread Ilia Platone
You got it, however: It only matters relative time. Start and Stop times 
will be known, and that is solved.
Someone has proposed using TV or other broadcasting carrier as reference 
clock: this can be another very cheap solution. There are many AM 
stations near the places we chosen, and these can be used.
A problem found was how to increase SNR: do you have a solution for 
this? If possible this method would be the best, since longer baselines 
could be made. The distance from the carrier source is not a problem 
since we'd use a GPS module at each telescope. Also the software part is 
not a problem too.

Good the relative timestamp also, as it saves HDD space.

Regards,
Ilia.

On 05/04/16 15:28, Chris Albertson wrote:

One more comment.   It seems to me time-raging events is hard because you
need many very good clocks that tracks absolute time.

If you redefine the problem to be "determine the time difference between to
events that occurred a couple nights ago it might be much easier.  This
does not need to be done in real  time

On Wed, May 4, 2016 at 8:25 AM, Chris Albertson <albertson.ch...@gmail.com>
wrote:


Maybe there is some simpler way to synchronize the telescopes.   Do they
even need to know the absolute time?  I think only relative time maters.

For that all they need is some kind of a signal that all the telescope can
"see".   Could they use an FM or TV broadcast station?  They could sample
and record the signal at a very high sample rate (maybe 4X the career
frequency) and record their data at the same time.  each telescope would
need to know its distance to the broadcast antenna.

The idea is to make the hardware cheaper and simpler and put all the
"work" on the post processing software developers.

For this purpose, measuring the time difference of photons detected at
different locations, I don't think the broadcast career needs to be
exceptionally stable.  In post all you do to slide the recorded signal
until a best match is found.  So we do need a modulated carrier.  We also
have LOTS of data to use to compute the time alignment because you do it
later, we'd have billions of samples so it should be immune to noise







--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] synchronization for telescopes

2016-05-04 Thread Ilia Platone
 This is something you have to
test for.


That's why I'm proposing timing receivers. They are the ones that have
the additional software and hardware bits which allow to relate an
external oscillator to the satellite phases.

I think we're talking about the same thing here. By 'geodetic receiver' I meant:
L1/L2 + carrier phase measurements + externally supplied 10 MHz and 1 pps.
This is the typical kind of receiver installed at an IGS station, with
the external clock a Cs or H-maser. They cost around $10-$15K.


I don't know what resolution the LEA family offers there, but the
spec of the protocol defines a 1ps resolution in the data. So I would
guess that the phase data resolution is probably in the order of 10-100ps.

Coincidentally, I am currently writing software so that I can test the
LEA-8MT for GPSCV time-transfer. This is code-based, in the usual way.
I will be doing a comparison of a number of different single-frequency
receivers for time-transfer - this may be of interest to the time-nuts
community because the testing platform is all open source
(www.openttp.org) .

This whole discussion has been very useful  because it has alerted me
to an interesting application for post processed timing!

Cheers
Michael
___
time-nuts mailing list --time-nuts@febo.com
To unsubscribe, go tohttps://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 tohttps://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Using lasers for data transmission

2016-05-01 Thread Ilia Platone

Thank you, I personally were talking about 1400nm 1mw lasers, however.

Supplying just above the threshold current is not a problem.

does the raising time can be reduced if using lower current/voltage 
raises or falls? I mean: how's calculated the raise time, full-scale 
pulse or for a mW/mA or so amount?


Ilia.


Il 01/05/2016 18:48, Mark Sims ha scritto:

There are "eye-safe" wavelengths that some laser diodes can operate at 
(generally greater than 1300 nm).  These are much less prone to damage eyes.  Basically 
your eyeball juice blocks the wavelength.  Still, there is some potential for cornea and 
lens damage at higher powers.
http://www.laserfocusworld.com/articles/2008/03/photonic-frontiers-eye-safe-lasers-retina-safe-wavelengths-benefit-open-air-applications.html


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



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Using lasers for data transmission

2016-05-01 Thread Ilia Platone
Threshold current should not be a problem because if there's no data the 
laser could go into "power saving mode".


As am modulation a simple buffer/r2r network DAC should do the job. The 
signals to transmit are three: Tx, and two bidirectional.


Ilia.


Il 01/05/2016 10:27, Dr. David Kirkby (Kirkby Microwave Ltd) ha scritto:

Hi,
Several (many?) years ago National Geographic magazine show a picture

taken here in southern California of the state government sending red laser
signals between different mountain tops to keep track what was going on
near fault lines

There were no technical details on what was taking place.  So it can be

done.

At a hamfest a few years ago I bought both a red and green 35 mW laser

pen for about $15 each.  They do shine a long, long way.

35 mW is certainly unsafe to the eyes, so be very careful.  There maybe
legal issues about doing this.


Whether these are powerful enough, or can be properly modulated for what

is needed, I have no idea.

You can pretty much modulate any laser diode. There are two important
currents to know about

* Threshold current I_th - below which it will not lase.
* Maximum operating current I_max - above which the device will be
destroyed.

You can AM modulate them by applying a DC current

I_th + (I_max - I_th)/2.

Then superimpose the modulation which has a peak value of (I_max - I_th)/2.

Those currents ensure that the laser is always lasing,  and gets you
theoretically 100% modulation.  For best lifetime,  run at lower levels of
peak modulation current.

Watch out for transient currents - lasers make transistors look like
antisurge fuses!

For point to point contact you want a beam which diverges as little as
possible.  IIRC the divergence is something like inversely proportion to
the cavity length.  For this reason a diode laser with its short cavity is
not optimal. But of course they are cheap.

A veey long time ago I used to know quite a lot about lasers,  but not
using them for years I realise that I have forgotten an awful lot!

FWIW, at university we had a 10 W argon ion laser. I think it took about 50
kW to produce those 10 W. When it was disposed of, it was sold to a company
that put on light shows.

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.



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Using lasers for data transmission

2016-05-01 Thread Ilia Platone
The problem would be modulating a 10GBASE-T signals into a single laser 
beam, and demodulating it using (I think) an APD.


except the one depending on light travel, that shouldn't be a problem if 
using White Rabbit, there could be some problem with the modulating and 
transmitter/receiver delay response times.


I mean that lasers offer 100ps rise time, and the APDs I found offer 5ps 
rise time, these must be multiplied by all the wires that GigE needs, 
which should be 4 pairs if I remember correctly, and some are 
bi-directional, plus the modulation process.


Ilia.


Il 01/05/2016 07:13, Perry Sandeen via time-nuts ha scritto:

Hi,
Several (many?) years ago National Geographic magazine show a picture taken 
here in southern California of the state government sending red laser signals 
between different mountain tops to keep track what was going on near fault 
lines.
There were no technical details on what was taking place.  So it can be done.
At a hamfest a few years ago I bought both a red and green 35 mW laser pen for 
about $15 each.  They do shine a long, long way.  Whether these are powerful 
enough, or can be properly modulated for what is needed, I have no idea.
On line I saw at least one China site that had much larger outputs available.  
The prices were modest. FWIW.
Regards,
Perrier
___
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.



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Optical transfer of time and frequency

2016-04-30 Thread Ilia Platone

I found only preliminary data about these transceivers.

I was meaning for a <2000€ overall solution, does a White Rabbit 
implementation fill this requisite ( I couldn't find much information 
about its costs)?


Also consider that nodes could be more than three also.

Ilia.


Il 30/04/2016 12:27, Bruce Griffiths ha scritto:

There are synchronous free space optical gigabit ethernet links available, it 
shouldn't take too much to modify one for White Rabbit.
Bruce
  


 On Saturday, 30 April 2016 10:13 PM, Magnus Danielson 
<mag...@rubidium.dyndns.org> wrote:
  


  Hi,

On 04/29/2016 11:45 PM, Michael Wouters wrote:

On Sat, Apr 30, 2016 at 6:14 AM, Magnus Danielson
<mag...@rubidium.dyndns.org> wrote:

Well, giving the conditions mentioned, doing ranging codes such as those
used by GPS is very easy and cheap. Doing this in bidirectional isn't too
hard. Doing a suitably high chip-rate should cost very little.

I've done two-way time-transfer over optical fibre using exactly this
technique. The TDEV is about 1 ps for tau>1s. Not so cheap, about 25K
euro per node (20K signal processing - NI FPGA, 2K laser and power
supplies, 1K detector, 1K RF electronics) in my setup, but that cost
could be greatly reduced since a $100 OEM FPGA could do the signal
processing (I've already done work on this but currently looking for
motivation to finish it off) and a simple, intensity-modulated laser
would probably be fine. A 2K euro budget would be a challenge though.

FPGA-wise, you need a very little FPGA resources.
If you consider the RedPitaya (200 USD) for instance, it is way beyond
what is needed.


The two-way time-transfer is relatively easy, but you will need to do some
calibration to get the precision needed.


At first glance, I would think that you should be able to define the
optical RX/TX path to within 10 cm without any trouble and that gives
you 300 ps accuracy. Even on fibre links, I don't think anyone would
claim an accuracy of better than a few hundred ps.

With a bit of calibration you can remove each nodes systematic asymmetry.

For optical fibers many does not even bother to do a pseudorandom
rangning. A repeating pattern suffice, such as that of SDH frames.

Cheers,
Magnus
___
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.



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Optical transfer of time and frequency

2016-04-29 Thread Ilia Platone
Fiber is not what I need because the system will not be in fixed 
locations, and distances will be far more than 2km.


The requirements are to record photon arrival timestamps with a sampling 
clock of 400MHz, 2.5ns resolution. The two clocks are independent, and 
the timestamps will be the effective clock number at the photon arrival. 
An averaging algorithm will be used to normalize the timestamps.


Since the software I'll use can adjust some "small" time drift. Some 
clock cycle every houe is acceptable, so requirements, you see , are far 
to be impossible.


1 clock cycle = 2.5ns

max clock cycles @ 1 hour = can vary, 1024 would be a good value. 
Something achievable with commercial products and easily averagable by 
software.


So:

1280ns each 1H dT (less is well accepted).

Ilia.


Il 29/04/2016 22:14, Magnus Danielson ha scritto:
Well, giving the conditions mentioned, doing ranging codes such as 
those used by GPS is very easy and cheap. Doing this in bidirectional 
isn't too hard. Doing a suitably high chip-rate should cost very little.


The two-way time-transfer is relatively easy, but you will need to do 
some calibration to get the precision needed.


Now, what is the needed precision?

Why can't you pull fiber?

Still wonder how you use the time, to understand the timing requirements.

Cheers,
Magnus

On 04/29/2016 08:50 PM, Ilia Platone wrote:

There is line of sight.

The budget is around 2k€ by now, but can be increased.

This project is for an amateur astro club, and the resources they would
give to me are limited, except the place where to do this and some 
optics.


The setup must be mobile, I mean that I should be able to place the
telescopes in other places "easily".

There is some material however. Material includes FPGA boards, VOCXO +
PLL boards, IR lasers and APD sensor boards, ARM boards, and consumer 
PCs.


There is also the possibility to use some optics like small reflector
telescopes, as pointed before, they could be used as beam expanders for
IR lasers.

Ilia.


Il 29/04/2016 09:36, Michael Wouters ha scritto:

On Fri, Apr 29, 2016 at 1:18 PM, Bruce Griffiths
<bruce.griffi...@xtra.co.nz> wrote:

Quoting Michael Wouters: "According to this,

http://www.nist.gov/manuscript-publication-search.cfm?pub_id=912449

there are many practical challenges  with a one way free-space
optical link."
That paper indicates that  one way transfer with noise of a few
picosec should be feasible using an IR laser.

Oh, yes I see in Fig 2b that the short term, one-way noise is ca. +/-
5 ps. And probably with temperature measurements, the long term
variation could be compensated.

But we still don't know if there is line of sight.

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



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] Optical transfer of time and frequency

2016-04-29 Thread Ilia Platone

There is line of sight.

The budget is around 2k€ by now, but can be increased.

This project is for an amateur astro club, and the resources they would 
give to me are limited, except the place where to do this and some optics.


The setup must be mobile, I mean that I should be able to place the 
telescopes in other places "easily".


There is some material however. Material includes FPGA boards, VOCXO + 
PLL boards, IR lasers and APD sensor boards, ARM boards, and consumer PCs.


There is also the possibility to use some optics like small reflector 
telescopes, as pointed before, they could be used as beam expanders for 
IR lasers.


Ilia.


Il 29/04/2016 09:36, Michael Wouters ha scritto:

On Fri, Apr 29, 2016 at 1:18 PM, Bruce Griffiths
<bruce.griffi...@xtra.co.nz> wrote:

Quoting Michael Wouters: "According to this,

http://www.nist.gov/manuscript-publication-search.cfm?pub_id=912449

there are many practical challenges  with a one way free-space optical link."
That paper indicates that  one way transfer with noise of a few picosec should 
be feasible using an IR laser.

Oh, yes I see in Fig 2b that the short term, one-way noise is ca. +/-
5 ps. And probably with temperature measurements, the long term
variation could be compensated.

But we still don't know if there is line of sight.

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



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] SE880 GPSDO

2016-04-28 Thread Ilia Platone

Rimini 999KHz RAI broadcast AM

Taranto 1008 era kerkyra corfu (greece) very strong even during daytime.

I'm informing, on mid-waves there's a nice signal even for long 
distances usually.


Ilia.


Il 29/04/2016 00:21, Bruce Griffiths ha scritto:

Multipath effects due to local terrain (mountains etc) may be a significant 
issue.Relying on AM broadcasts is fraught with issues. Whilst you may find one 
in Italy, what about Greece (another potential site)?

Bruce

  


 On Friday, 29 April 2016 9:22 AM, Attila Kinali <att...@kinali.ch> wrote:
  


  On Thu, 28 Apr 2016 21:01:49 +0200
Ilia Platone <i...@iliaplatone.com> wrote:


Thanks Attila, I know how to build a transmitter and a receiver, and now
is more clear the system you designed. But as I will propose this system
to an astro club, and in this astro club there's the possibility that
not all would have a radio license, I need something "free-to-play", if
it concern.

Ok.. that's quite some constraint. This rules out any kind of transmission.


I was wondering if it would be more convenient to lock to a signal from
an AM broadcasting station, if available to a multiple of the OCXO. What
do you think about?

AFAIK most radio and TV transmitters are using some stable reference.
I don't know though what they use these days. It used to be an Rb.

I would guess that using a radio station should in general work.
It should be as close as possible, so that you get as little
reflection as possible and that any multi-path from the troposphere
and ionosphere is minimized. If you still have any AM stations close
by, that would work. But these are more and more switched off and
replaced by digital broadcast systems.

The most common radio and TV transmitters these days are DAB and DVB-T.
Both use QPSK or QAM signals. This makes locking to those signals
quite a bit more difficult. What you can do is, use a DAB/DVB-T
tuner chip like the MAX3580 or MAX3541, down convert the signals,
then use the FPGA to track the signals and steer the OCXO's EFC DAC.
Yes, this is a lot more complicated and you need to build quite a bit
of a DVB-T/DAB receiver in the FPGA. Fortunately, this is something
people have already implemented in software using GNURadio. Ie you
can have a look at what they have done, copy the over the parts that
you need. But still, this will be quite some serious effort and will
take you months at best.

I also have no idea what the signal stability of the DVB-T and DAB
stations is. Maybe someone else (Magnus?) can comment on that.

As such... I think using an AM station that is close by would be feasible.
Using DVB-T/DAB stations would be a lot of effort and I would advise
against it in a first step. GPS alone should give you ~1ns when done right.
With more expensive equipment (high qual geodetic or timing antennas with
L1/L2 receivers) you should be able to go below that (see Michael Wouters'
mail).

An alternative approach would be to use an Rb reference instead of an
OCXO at the telescopes. This way you have a frequency stable reference
that you can use like the reference signal I mentioned in the other mail.
You would need one that has low phase noise (that rules out the FE-5680's
that are so cheap on ebay, ie you would need to go for LPRO, PRS10, FRS
or LPFRS). As now you only have a kind of stable reference, but you don't
know how far off it is (and probably not how fast its drifting), some
precision will need to be spend on determining its exact frequency.
But nonetheless it should give you additional precision when doing
the post-processing that you can use to increase the timing solution's
precision.


     Attila Kinali



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] SE880 GPSDO

2016-04-28 Thread Ilia Platone

Il 28/04/2016 23:22, Attila Kinali ha scritto:

On Thu, 28 Apr 2016 21:01:49 +0200
Ilia Platone <i...@iliaplatone.com> wrote:


Thanks Attila, I know how to build a transmitter and a receiver, and now
is more clear the system you designed. But as I will propose this system
to an astro club, and in this astro club there's the possibility that
not all would have a radio license, I need something "free-to-play", if
it concern.

Ok.. that's quite some constraint. This rules out any kind of transmission.


I was wondering if it would be more convenient to lock to a signal from
an AM broadcasting station, if available to a multiple of the OCXO. What
do you think about?

AFAIK most radio and TV transmitters are using some stable reference.
I don't know though what they use these days. It used to be an Rb.

I would guess that using a radio station should in general work.
It should be as close as possible, so that you get as little
reflection as possible and that any multi-path from the troposphere
and ionosphere is minimized. If you still have any AM stations close
by, that would work. But these are more and more switched off and
replaced by digital broadcast systems.
I know that some AM station still exists, a place where to setup the 
telescopes will have the local repetitors very close.
I think that airports use AM modulation, but I sincerely don't know if 
it's legal even to listen at those frequencies. Their signal should be 
strong, however.



The most common radio and TV transmitters these days are DAB and DVB-T.
Both use QPSK or QAM signals. This makes locking to those signals
quite a bit more difficult. What you can do is, use a DAB/DVB-T
tuner chip like the MAX3580 or MAX3541, down convert the signals,
then use the FPGA to track the signals and steer the OCXO's EFC DAC.
Yes, this is a lot more complicated and you need to build quite a bit
of a DVB-T/DAB receiver in the FPGA. Fortunately, this is something
people have already implemented in software using GNURadio. Ie you
can have a look at what they have done, copy the over the parts that
you need. But still, this will be quite some serious effort and will
take you months at best.

Will inform on AM stations.

I also have no idea what the signal stability of the DVB-T and DAB
stations is. Maybe someone else (Magnus?) can comment on that.

I would appreciate his contibution :)

As such... I think using an AM station that is close by would be feasible.
Using DVB-T/DAB stations would be a lot of effort and I would advise
against it in a first step. GPS alone should give you ~1ns when done right.
With more expensive equipment (high qual geodetic or timing antennas with
L1/L2 receivers) you should be able to go below that (see Michael Wouters'
mail).
An alternative approach would be to use an Rb reference instead of an
OCXO at the telescopes. This way you have a frequency stable reference
that you can use like the reference signal I mentioned in the other mail.
You would need one that has low phase noise (that rules out the FE-5680's
that are so cheap on ebay, ie you would need to go for LPRO, PRS10, FRS
or LPFRS). As now you only have a kind of stable reference, but you don't
know how far off it is (and probably not how fast its drifting), some
precision will need to be spend on determining its exact frequency.
But nonetheless it should give you additional precision when doing
the post-processing that you can use to increase the timing solution's
precision.
The problem is not the absolute stability, but the relative error 
between the various stations. ie the telescopes clocks must not drift 
too much by each other.


Attila Kinali



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] SE880 GPSDO

2016-04-28 Thread Ilia Platone



Il 28/04/2016 12:28, Attila Kinali ha scritto:

On Thu, 28 Apr 2016 10:07:56 +0200
Ilia Platone <i...@iliaplatone.com> wrote:


Please note that not all the frequencies will be utilizable, here only
433MHz is free-for-all and at low power: only under 50mA transmitting power.

Does this mean you don't have an amateur radio license?
Then it would be a good time to get one :-)

:) yes, maybe...

BTW: you also have the 868MHz SRD and the 2.4GHz range available,
with similar power constraints though.


There are some very cheap FSK transmitters that can output at a maximum
rate of 9600bps: a 1KHz quad signal on these carriers, can drive a GPSDO
like the 10KHz output of some GPS receivers? The clock being compared to
this would be 10MHz downscaled by some decade counters.

this would be much simpler to implement.

I don't get exactly what you mean, but these FSK transmitters for sub-GHz
radios will not work. Their only purpose is low power radio transmissions
over a couple of 10m. Yes, you can use them to send data. Yes, you can
lock to that. But you will not get the control over phase/frequency you
need to implement a good frequency transfer or time transfer system.

Building your own 70cm is not difficult. There are plenty of amateur
radio books from the 70s and 80s  around that explain how to build
one with minimal effort. The QRP community has also quite a few designs
that are very simple to build (and a bit more modern).

All you actually need for a CW transmitter is some oscillator, ie a VCO,
that you can either build yourself (L-C tank with a varactor)
or buy as a chip. Use some simple PLL to lock it to your reference
(ADF4002 or similar are a decent choice). Add a simple amplifier
to get the signal to a decent level and a piece of wire as antenna.

The receiver is a bit more involved. There you need to downmix
the received signal to a frequency that is not higher than your
OCXO's frequency, feed that to an amplifier and from there to
a PLL that steers the OCXO. The downmixing LO needs to be derived
from the OCXO as well.

The PLL of the receiver can be an analog design as with the transmitter
or a digital design where you digitze the signal and process it in
an FPGA that produces an output for a DAC that then steers the OCXO.

But all this depends on quite a bit of knowledge on how to design
analog circuits. If you have never done that, it would be a good
idea to find a companion where you live that helps you with the
project.

Attila Kinali
Thanks Attila, I know how to build a transmitter and a receiver, and now 
is more clear the system you designed. But as I will propose this system 
to an astro club, and in this astro club there's the possibility that 
not all would have a radio license, I need something "free-to-play", if 
it concern.
I was wondering if it would be more convenient to lock to a signal from 
an AM broadcasting station, if available to a multiple of the OCXO. What 
do you think about?


--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] SE880 GPSDO

2016-04-28 Thread Ilia Platone
Please note that not all the frequencies will be utilizable, here only 
433MHz is free-for-all and at low power: only under 50mA transmitting power.


There are some very cheap FSK transmitters that can output at a maximum 
rate of 9600bps: a 1KHz quad signal on these carriers, can drive a GPSDO 
like the 10KHz output of some GPS receivers? The clock being compared to 
this would be 10MHz downscaled by some decade counters.


this would be much simpler to implement.

Ilia.

Il 27/04/2016 23:38, Bruce Griffiths ha scritto:

On Wednesday, April 27, 2016 09:40:05 PM Attila Kinali wrote:

On Wed, 27 Apr 2016 20:18:10 +0200

Mike Cook <michael.c...@sfr.fr> wrote:

Use this CW signal on all the telescope stations to phase lock a local
OCXO. Using a good OCXO, it should be possible to use loop bandwidths
in the 0.1-10Hz range. My guess is, that this frequency transfer system
would yield stabilities in the order of 10^-12 @ 1s (or even better).
For additional performance, one could modulate the CW with a PRN
sequence
to get a better SNR and probably get another order of magnitude out of
it.
For the simple CW case, the circuitry should be fairly simple and easy
to do. The PRN case would require at least some processing in an FPGA.

It might be possible to clock the FPGA directly from a suitably massaged
CW. Do any clock at 1GHz+???
It would be also possible to do away with LO’s in this case..

That would make the system more complicated than simpler, because
you need to extract a signal from a noisy environment, pass it through
narrow band filter so you get something that resembles a sinus in order
to use it in the electronics. This kind of works when the reference
signal comes in via cable. With over the air transmission, this wont work.

Using an OCXO together with a PLL basically forms a very narrow band
filter that has a very small tempco, adjustable (and adaptive)
frequency and allows to change the filter coefficiencts quickly
to acquire the signal at start-up.

Very few chips (of any kind, not just FPGA) allow input clocks higher
than a couple 100MHz. Single ended CMOS inputs usually go only up
to 200MHz, often much lower than that. Differential (LVDS and PECL)
ends usually in the 500MHz range.

Also. Running an FPGA at 1GHz is not trivial at all. Most designs
don't do more than 500MHz even on the fastest FPGAs out there.
100-300MHz are common values. And unlike with CPUs, there is often
no need to run an FPGA faster than the data arrives or leaves, as
the functions can be run in parallel and use a pipelined architecture..


The CW could also carry time, and if it was feasible, local GPS would be
unnecessary.

If the CW would carry time, it wouldn't be CW anymore ;-)

Yes, that's the idea with the PRN modulation i mentioned in the other mail.
But it wont lift the necesity of GPS. There is an unknown delay from the
sender to the receiver, through multiple filter and frequency conversion
stages. Some of them can be measured, some of them come from the ambiguity
of the phase in the system. Others, like the path delay, cannot be measured.

One solution would be, to use 2 transmitters with known positions and
known phase relations, then it would be possible to extract time,
given one knows the positions of the receivers exactly.
To get around that requirement, one would need at least 4 transmitters...
Ie. one would be recreating the GPS system... at which point it becomes
simpler to just use GPS and live with the degraded accuracy.

Also keep in mind, that with GPS it is well known where the errors
come from and how big they are. Also lots of techniques are implemented
to counter those. With a DIY-GPS system, one would need to implement
those and measure their performance again, which would be a whole lot of
work.

Attila Kinali

The solution to this conundrum is to use a high speed serial to parallel
converter and proces 4/8/16 timeslots in parallel at 1/4, 1/8 or 1/16 the
serial clock rate as required.

If the high speed serial interface offered by many modern FPGAs could be used
for this then 100ps or finer timestamp quantisation may be feasible.

Bruce

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



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] SE880 GPSDO

2016-04-27 Thread Ilia Platone

It was a joke :)

Interesting the idea of Attila, it can be the less expensive solution:

"Assuming that you have an amateur radio license, you could use a
well located central station to transmit a CW signal in the 70cm or
23cm band. There should be some effort put into this station
to make it stable (eg by using a good rubidium as frequency source,
or even an ensemble) and low noise."

...

"Now that all stations have the "same" frequency, one can use the GPS
module to get the time information using long integration times.
Under the assumption that the (sawtooth corrected) PPS is good to ±10ns
an has a nice, time-invariant distribution, it should be possible to get
below 1ns in precision within 100s. Using common view phase data it
should be possible to get even better than that."

Regards,
Ilia.

Il 27/04/2016 10:12, Bruce Griffiths ha scritto:

A 60kHz receiver is unlikely to be useful for nanosecond timing applications.
Bruce
  


 On Wednesday, 27 April 2016 6:36 PM, Ilia Platone <i...@iliaplatone.com> 
wrote:
  


  Hi All,

I read from an article about this receiver: C-Max CMMR-6P-60

Can it be useful?

One of the places where I'll setup the telescopes will be in mount
Carpegna, near where I live. There are the repetitors of television and
radio over there. Can the carrier wave of such repetitors be used as
clock? they will be distant 5 Km or less from the observation location.

Regards,

Ilia.


Il 26/04/2016 23:51, Attila Kinali ha scritto:

On Wed, 27 Apr 2016 08:25:55 +1200
Bruce Griffiths <bruce.griffi...@xtra.co.nz> wrote:


1) Relative position of any pair of clocks located up to 2km apart has to be
known to within 3cm or so. Post processing is OK, however differential Earth
tides between the clock locations may need to be considered.

That's doable. People at ETHZ got sub cm accuracy from LEA-6T modules
with post-processing of the recorded phase data with an integration time
of several hours. Using phase data of multiple timing modules should give
relative positions with better than 1cm accuracy on these short baselines..
I don't know how much post-processing is necessary though. Haven't looked
into the the field of RTK[1] and PPP[2] yet. Probably data from IGS[3] is
needed as well.


2) The difference in the time offset between any pair of clocks located up to
2km apart shall not vary by more than 200ps (1ns time stamp quantisation) or
2ns (10ns timestamp quantisation) over an 8 hour period (at night).
Post processing of data to fit wander etc is not practical as the SNR is too
low to support this.

Now this is quite a bit more challenging. While i'd say 1ns should be doable
(using receivers that are calibrated against each other and using common in
view mode during post-processing of the data), i'm not so sure whether 200ps
is possible. What might work is using an LEA-M8F with it's external frequency
input, to record the phase of an stable external reference (e.g. Rb).
Averaging that over a dozen minutes or so should make it possible to
measure the phase of the reference oscillator with 200ps precision, relative
to the other stations.

Another way would be to use L1/L2 receivers with calibrated antennas.
I know that BIPM has a GPS station that can deliver time transfer
accuracy <2ns over a distance of several 100km. It could be possible
to use such receivers with the <3km distances to deliver 10 times better,
if they are frequently calibrated (eg. every couple of days).
But of course, this makes things much more expensive.

But all this is a wild guess. I haven't seen anything like this done.
If you want a more precise answer i would need to think about the design
of the system for some time.


I guess using some cable/fibre between the telescopes is out of question?


 Attila Kinali

[1] http://www.navipedia.net/index.php/Real_Time_Kinematics
[2] http://www.navipedia.net/index.php/Precise_Point_Positioning
[3] http://www.igs.org/



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] SE880 GPSDO

2016-04-27 Thread Ilia Platone

Hi All,

I read from an article about this receiver: C-Max CMMR-6P-60

Can it be useful?

One of the places where I'll setup the telescopes will be in mount 
Carpegna, near where I live. There are the repetitors of television and 
radio over there. Can the carrier wave of such repetitors be used as 
clock? they will be distant 5 Km or less from the observation location.


Regards,

Ilia.


Il 26/04/2016 23:51, Attila Kinali ha scritto:

On Wed, 27 Apr 2016 08:25:55 +1200
Bruce Griffiths <bruce.griffi...@xtra.co.nz> wrote:


1) Relative position of any pair of clocks located up to 2km apart has to be
known to within 3cm or so. Post processing is OK, however differential Earth
tides between the clock locations may need to be considered.

That's doable. People at ETHZ got sub cm accuracy from LEA-6T modules
with post-processing of the recorded phase data with an integration time
of several hours. Using phase data of multiple timing modules should give
relative positions with better than 1cm accuracy on these short baselines.
I don't know how much post-processing is necessary though. Haven't looked
into the the field of RTK[1] and PPP[2] yet. Probably data from IGS[3] is
needed as well.


2) The difference in the time offset between any pair of clocks located up to
2km apart shall not vary by more than 200ps (1ns time stamp quantisation) or
2ns (10ns timestamp quantisation) over an 8 hour period (at night).
Post processing of data to fit wander etc is not practical as the SNR is too
low to support this.

Now this is quite a bit more challenging. While i'd say 1ns should be doable
(using receivers that are calibrated against each other and using common in
view mode during post-processing of the data), i'm not so sure whether 200ps
is possible. What might work is using an LEA-M8F with it's external frequency
input, to record the phase of an stable external reference (e.g. Rb).
Averaging that over a dozen minutes or so should make it possible to
measure the phase of the reference oscillator with 200ps precision, relative
to the other stations.

Another way would be to use L1/L2 receivers with calibrated antennas.
I know that BIPM has a GPS station that can deliver time transfer
accuracy <2ns over a distance of several 100km. It could be possible
to use such receivers with the <3km distances to deliver 10 times better,
if they are frequently calibrated (eg. every couple of days).
But of course, this makes things much more expensive.

But all this is a wild guess. I haven't seen anything like this done.
If you want a more precise answer i would need to think about the design
of the system for some time.


I guess using some cable/fibre between the telescopes is out of question?


Attila Kinali

[1] http://www.navipedia.net/index.php/Real_Time_Kinematics
[2] http://www.navipedia.net/index.php/Precise_Point_Positioning
[3] http://www.igs.org/



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] SE880 GPSDO

2016-04-26 Thread Ilia Platone
I will use a dedicated FPGA design, and the data will be stored into an 
SDXC card (UHS), or an IDE drive (maybe not), in RAW mode (no filesystem).


Each timestamp will be stored into a word of 48bits, the clock will be 
400MHz, so the quantization will be 2.5ns, but the maximum error/clock 
offset should be 1/10 of this, so 500ps , as said by Bruce.


Regards,

Ilia.

Il 27/04/2016 00:29, Attila Kinali ha scritto:

On Tue, 26 Apr 2016 22:24:08 +0200
Ilia Platone <i...@iliaplatone.com> wrote:


I must print each photon event captured by an APD at the focus of more
telescopes, these events must be timestamped with an accuracy of 2.5ns,

As i wrote before, 1ns should be doable with standard timing GPS receiver
and calibration at those short baselines. Going below that will be a
challenge though.


and the expected rate is lower than 10MHz.

10MHz is quite a high rate of events that need to be timestamped.
How do you intend to measure events at such a high rate? And how
do you intend to store so much data? Each measurement will need
at least 40bit resolution, at 10MHz that's 50MByte/s. Even if you
say that the average rate is only a fraction of that and you use
lots of buffers, that's still a high data rate for a measurement
instrument.

Attila Kinali


--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] SE880 GPSDO

2016-04-26 Thread Ilia Platone

Errata..


Il 26/04/2016 22:24, Ilia Platone ha scritto:

Hi Attila,

This is a hobby project, by now, but if these devices can be versatile 
and small, they could be used for a work project. till now, hobby and 
open source.
I am stuck at the timing issues. After finding a suitable stable 
clock, on multiple and independent boards, for 8 hours, I'll begin 
designing the software of these.


I must print each photon event captured by an APD

...each telescope will have an avalanche photodiode ( plus amp )...
at the focus of more telescopes, these events must be timestamped with 
an accuracy of 2.5ns, and the expected rate is lower than 10MHz, The 
overall capture runs will take about 4-5 hours, it depends on the 
object observed, after capturing I must compare the timestamps logs 
each other to find if are there common events/timestamps in the 
various fluxes. I need a stable clock to reduce the software needs, 
for example if the automated captures of each device ends withinone 
second each other I think it would be too much, but I am thinking I 
must be more flexible in the software side.


Regards,
Ilia.

Il 26/04/2016 14:40, Attila Kinali ha scritto:

Ciao Ilia,

On Tue, 26 Apr 2016 02:24:04 +0200
Ilia Platone<i...@iliaplatone.com>  wrote:


Just for informations, as I must build the board from scratch, does this
design is good to implement into the datalogger?
I mean, for the second RTK purpose, does this u-blox module satisfy my
requirements (link below)?
http://www.opendigitalradio.org/lea-m8f-gpsdo

I cannot say. I don't know what your requirements are and thus
cannot say what a good design choice is.

Yes, the LEA-M8F does support the output of satellite phase data.
Yes you can use that for RTK. BTW: this is stated in the documentation
for the module. You just need to read it.

BTW2: is this a hobby project or is this a work project?

Attila Kinali



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999


--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] SE880 GPSDO

2016-04-26 Thread Ilia Platone

Hi Attila,

This is a hobby project, by now, but if these devices can be versatile 
and small, they could be used for a work project. till now, hobby and 
open source.
I am stuck at the timing issues. After finding a suitable stable clock, 
on multiple and independent boards, for 8 hours, I'll begin designing 
the software of these.


I must print each photon event captured by an APD at the focus of more 
telescopes, these events must be timestamped with an accuracy of 2.5ns, 
and the expected rate is lower than 10MHz, The overall capture runs will 
take about 4-5 hours, it depends on the object observed, after capturing 
I must compare the timestamps logs each other to find if are there 
common events/timestamps in the various fluxes. I need a stable clock to 
reduce the software needs, for example if the automated captures of each 
device ends withinone second each other I think it would be too much, 
but I am thinking I must be more flexible in the software side.


Regards,
Ilia.

Il 26/04/2016 14:40, Attila Kinali ha scritto:

Ciao Ilia,

On Tue, 26 Apr 2016 02:24:04 +0200
Ilia Platone <i...@iliaplatone.com> wrote:


Just for informations, as I must build the board from scratch, does this
design is good to implement into the datalogger?
I mean, for the second RTK purpose, does this u-blox module satisfy my
requirements (link below)?
http://www.opendigitalradio.org/lea-m8f-gpsdo

I cannot say. I don't know what your requirements are and thus
cannot say what a good design choice is.

Yes, the LEA-M8F does support the output of satellite phase data.
Yes you can use that for RTK. BTW: this is stated in the documentation
for the module. You just need to read it.

BTW2: is this a hobby project or is this a work project?

Attila Kinali



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] SE880 GPSDO

2016-04-26 Thread Ilia Platone

:) yes, it is.

Basically I need to sync two signals at a variable frequency centered at 
about 10MHz, for 8 hours. The actual bandwidth depends because there 
will be a variable number of harmonics on such signal.


The data logging system is for the intensity interferometer, and it 
needs an error management like the above, it will use a PLL of an FPGA 
that pulls up the frequency from the main oscillator into 400MHz, the 
FPGA's PLL is very flexible, so the main XT frequency may not be 
obligatory at 10MHz.


Regards,

Ilia.

Il 26/04/2016 00:12, Bruce Griffiths ha scritto:

There's no spec for th 10MHz option you originally specified.What's the jitter 
bandwidth of interest?

Still need a spec for the data logging system timebase error.This is for your 
intensity interferometer?

Bruce

 On Tuesday, 26 April 2016 10:00 AM, Ilia Platone <i...@iliaplatone.com> 
wrote:
  


  I haven't bought anything yet, so feel free to recommend me any
components/setup.

here is the datasheet I am referring to:
http://www.foxonline.com/pdfs/FVXO_HC53.pdf

It contains some informations about phase jitter on page 5.

The

I selected this because of the CMOS output, since I didn't find any
Connor Winfield osc with these levels yet.

Actually  want to achieve less than around 78ps jitter at 125MHz. (this
should be achievable using this also:
http://www.digikey.it/product-detail/it/fox-electronics/FVXO-HC53B-125/FVXO-HC53B-125-ND/2153894)

Let me know,

Ilia.


Il 25/04/2016 22:51, Bruce Griffiths ha scritto:

On Monday, April 25, 2016 09:41:57 PM Ilia Platone wrote:

Hi all,

I'm trying to build a GPSDO with a FVXO-HC53BR-10 (Fox Electronics) VCXO
and a Telit Jupiter
<http://www.digikey.com/Suppliers/it/Fox-Electronics.page?lang=en>SE880, this serves
for a datalogger an I want to achieve a highly reliable clock.

This GPS receiver has two clock inputs: a 16MHz, and a 32KHz XT input
for the RTC functions.
My problem is this: The crystal must be driven by a voltage depending to
the phase difference between the GPS 1PPS output and the uC 1s cycles,
but must I drive (feedback) the RTC of the GPS also from a divider of
the main clock, or the 16MHz TCXO input, or both (or none...)?

Suggestions of any other component, for driving both the VCXO, and
possibly for a RTK implementation, are welcome.
Thank you,
Ilia.
___
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.

What are the timing specifications for the data logging system?
Without this data, its not possible to decide if the proposed GPSDO will meet
these specifications.
Whist its possible to construct a GPSDO using almost any crystal controlled
oscillator, the timing performance will vary widely.
The datasheet for the Fox VCXO you selected does not specify the phasenoise,
jitter or ADEV for the 10MHZ option.

Bruce
   
___

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



--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] SE880 GPSDO

2016-04-26 Thread Ilia Platone

Thank you Attila,

Just for informations, as I must build the board from scratch, does this 
design is good to implement into the datalogger?
I mean, for the second RTK purpose, does this u-blox module satisfy my 
requirements (link below)?

http://www.opendigitalradio.org/lea-m8f-gpsdo

Regards,
Ilia.

Il 26/04/2016 01:36, Attila Kinali ha scritto:

On Mon, 25 Apr 2016 23:34:52 +0200
Ilia Platone <i...@iliaplatone.com> wrote:


I selected this because of the CMOS output, since I didn't find any
Connor Winfield osc with these levels yet.

To get to CMOS levels, you usually add a simple inverter, with an
capacitor in front and a 1M resistor across the inverter (from input
to output).



Actually  want to achieve less than around 78ps jitter at 125MHz. (this
should be achievable using this also:
http://www.digikey.it/product-detail/it/fox-electronics/FVXO-HC53B-125/FVXO-HC53B-125-ND/2153894)

I think you are mixing up a few things here:

Your logger might have very relaxed jitter requirements, but the
GPS module needs a low noise reference signal. If you feed it with
the noisy HC53 output, you will degrade your GPS receivers performance
severely. At the minimum, you should use a normal XO for the GPS modul.
You can of corse use a HC53 as the reference for your logger if its
jitter is ok for you.

And for comparison, for a XO you usually talk about jitter in the
order of 100fs to 1ps (10kHz-20MHz)



Attila Kinali


--
Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999

___
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] SE880 GPSDO

2016-04-26 Thread Ilia Platone

Thanks Bruce,

I know this, the delays due to the light path difference will be 
calculated later by software, and i can have filters with a bandwidth of 
3-5 nm, two 0.4m diameter telescopes. the distance of the two telescopes 
will be around 2500m and the maximum delay between these two signals may 
be 8us. The expected photon flux (the actual center frequency of the 
data logged) will be less than 10M/s, but the clocks that record these 
data must be synced with a maximum error of some ps, otherwise I'll not 
find any correlation.


I would propose a software capable of aligning these two (or more, 
sequentially) logs by finding correlation by a slighty variable 
time-base, excluding pseudo-correlations by a discriminating algorithm, 
but this is for an interferometry forum/list maybe.


Regards,
Ilia.

Il 26/04/2016 02:50, Bruce Griffiths ha scritto:

You've omitted the following pertinent data:
1) The idea is to correlate photon arrival times at pairs of stations with 
lateral separations of up to 1 km or so.
2) The Signal to noise ratio of the resultant measurement is proportional to
 A) The geometric mean of the areas of the pair of telescopes  This 
cannot be too large as it smears out the details in the Fourier plane.
 B) Square root of the electronic system bandwidth (or equivalently the 
reciprocalof the photon relative arrival time stamp accuracy)

 C) Square root of the observation time.
 The differential light path delays between the telescope pair can be up to 
3.3us or so.
The effect of differential noise between the timestamps at a telescope pair is 
to in effect reduce the effective electronic bandwidth or equivalently increase 
the observation time for a given SNR. For example with a time stamp resolution 
of 1ns (~500 MHz bandwidth) the differential timestamp noise should be much 
less than this (ie 100-200ps or so). With a 10ns (~50MHz bandwidth) timestamp 
resolution 1-2ns of differential timmestmp noise is tolerable, however the 
required observation time increases by a factor of 10 for a given SNR.
The SNR is independent of the optical filter bandwidth so that with a 
sufficiently narrow optical filter bandwidth its possible to ensure that photon 
counting is feasible.

The original Hanbury-Brown Twiss interferometer used 10m light buckets running 
on a circular railway track with interconnecting coax cables. The position of 
the collector pair was adjusted to maintain the baseline at right angles to the 
light path to the observed object thus ensuring zero differential light path 
delay between the collectors. The two signals were multiplied together using an 
analog circuit with a bandwidth of around 40MHz. Observation times of several 
hours were required even for relatively bright stars.
  For further details see:Long baseline optical intensity Interferometry

|   |
|   |  |   |   |   |   |   |
| [1506.05804] Long-baseline optical intensity interferome...Submission 
historyFrom: Dainis Dravins [view email] [v1] Thu, 18 Jun 2015 20:00:34 GMT 
(4473kb,D)  |
|  |
| View on arxiv.org | Preview by Yahoo |
|  |
|   |

Bruce


  


 On Tuesday, 26 April 2016 11:03 AM, Bruce Griffiths 
<bruce.griffi...@xtra.co.nz> wrote:
  


  There's no spec for th 10MHz option you originally specified.What's the 
jitter bandwidth of interest?

Still need a spec for the data logging system timebase error.This is for your 
intensity interferometer?

Bruce

 On Tuesday, 26 April 2016 10:00 AM, Ilia Platone <i...@iliaplatone.com> 
wrote:
  


  I haven't bought anything yet, so feel free to recommend me any
components/setup.

here is the datasheet I am referring to:
http://www.foxonline.com/pdfs/FVXO_HC53.pdf

It contains some informations about phase jitter on page 5.

The

I selected this because of the CMOS output, since I didn't find any
Connor Winfield osc with these levels yet.

Actually  want to achieve less than around 78ps jitter at 125MHz. (this
should be achievable using this also:
http://www.digikey.it/product-detail/it/fox-electronics/FVXO-HC53B-125/FVXO-HC53B-125-ND/2153894)

Let me know,

Ilia.


Il 25/04/2016 22:51, Bruce Griffiths ha scritto:

On Monday, April 25, 2016 09:41:57 PM Ilia Platone wrote:

Hi all,

I'm trying to build a GPSDO with a FVXO-HC53BR-10 (Fox Electronics) VCXO
and a Telit Jupiter
<http://www.digikey.com/Suppliers/it/Fox-Electronics.page?lang=en>SE880, this serves
for a datalogger an I want to achieve a highly reliable clock.

This GPS receiver has two clock inputs: a 16MHz, and a 32KHz XT input
for the RTC functions.
My problem is this: The crystal must be driven by a voltage depending to
the phase difference between the GPS 1PPS output and the uC 1s cycles,
but must I drive (feedback) the RTC of the GPS also from a divider of
the main clock, or the 16MHz TCXO input, or both (or none...)?

Suggestions of any other component, for driving both the VCXO, and
possibly for a RTK implementation, are 

Re: [time-nuts] SE880 GPSDO

2016-04-25 Thread Ilia Platone
I haven't bought anything yet, so feel free to recommend me any 
components/setup.


here is the datasheet I am referring to: 
http://www.foxonline.com/pdfs/FVXO_HC53.pdf


It contains some informations about phase jitter on page 5.

The

I selected this because of the CMOS output, since I didn't find any 
Connor Winfield osc with these levels yet.


Actually  want to achieve less than around 78ps jitter at 125MHz. (this 
should be achievable using this also: 
http://www.digikey.it/product-detail/it/fox-electronics/FVXO-HC53B-125/FVXO-HC53B-125-ND/2153894)


Let me know,

Ilia.


Il 25/04/2016 22:51, Bruce Griffiths ha scritto:

On Monday, April 25, 2016 09:41:57 PM Ilia Platone wrote:

Hi all,

I'm trying to build a GPSDO with a FVXO-HC53BR-10 (Fox Electronics) VCXO
and a Telit Jupiter
<http://www.digikey.com/Suppliers/it/Fox-Electronics.page?lang=en>SE880, this serves
for a datalogger an I want to achieve a highly reliable clock.

This GPS receiver has two clock inputs: a 16MHz, and a 32KHz XT input
for the RTC functions.
My problem is this: The crystal must be driven by a voltage depending to
the phase difference between the GPS 1PPS output and the uC 1s cycles,
but must I drive (feedback) the RTC of the GPS also from a divider of
the main clock, or the 16MHz TCXO input, or both (or none...)?

Suggestions of any other component, for driving both the VCXO, and
possibly for a RTK implementation, are welcome.
Thank you,
Ilia.
___
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.

What are the timing specifications for the data logging system?
Without this data, its not possible to decide if the proposed GPSDO will meet
these specifications.
Whist its possible to construct a GPSDO using almost any crystal controlled
oscillator, the timing performance will vary widely.
The datasheet for the Fox VCXO you selected does not specify the phasenoise,
jitter or ADEV for the 10MHZ option.

Bruce
  
___

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] SE880 GPSDO

2016-04-25 Thread Ilia Platone

Hi all,

I'm trying to build a GPSDO with a FVXO-HC53BR-10 (Fox Electronics) VCXO 
and a Telit Jupiter 
SE880, 
this serves for a datalogger an I want to achieve a highly reliable clock.


This GPS receiver has two clock inputs: a 16MHz, and a 32KHz XT input 
for the RTC functions.
My problem is this: The crystal must be driven by a voltage depending to 
the phase difference between the GPS 1PPS output and the uC 1s cycles, 
but must I drive (feedback) the RTC of the GPS also from a divider of 
the main clock, or the 16MHz TCXO input, or both (or none...)?


Suggestions of any other component, for driving both the VCXO, and 
possibly for a RTK implementation, are welcome.

Thank you,
Ilia.
___
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] Precise Time transfer and relative position over a short baseline

2016-04-11 Thread Ilia Platone
If using this system can the relative positions of the telescopes be
calculated also? You said the delay corresponding with 1mm is about 1ps,
so during processing we'd calculate the relative positions also using
delays between the various stations, if using common-view pulses at a
different frequency also, positions would be adjusted later with such
precision.

Regards,
Ilia.

Il 11/04/2016 14:33, jimlux ha scritto:
> On 4/11/16 1:40 AM, Björn wrote:
>> Hi Bruce,
>>
>> For such short baselines single frequency GNSS should be able to keep
>> fixed integer solutions. Not sure how much money thas is going to
>> save, since you might need timing specific geodetic receivers to get
>> external 10MHz input.
>>
>> Did you consider implementing time transfer using time reversal using
>> say a sdr tranciever (usrp or other) where your clock is driving the
>> radio. As done on HF by Yen & Sengupta at last PTTI.
>>
>> https://www.ion.org/ptti/abstracts.cfm?paperID=3373
>>
>
>
> VLA used VHF (I think) radio links to provide common phase reference
> among apertures.
>
> Consider, for example, using a 1 GHz CW carrier among your stations.
> With good SNR, tracking phase to 1/1000th of a cycle should be
> straightforward.
>
> The challenge will be (as always with this kind of thing) the
> mechanical effects.  Motion of 1mm is 3ps.
>
> On the other hand, my victim detection radar trivially measures 1mm
> displacements in path length with 20 dB SNR with EIRP of 1 mW, omni
> antennas, and a range of 30m with a 0.1 square meter target.  That's
> at 3 GHz.
>
>
>
>
>
> ___
> 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.
>

-- 
*Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999
* --
Questa email e qualsiasi allegato sono riservati e potrebbero anche
essere confidenziali. Qualora non foste il destinatario ed aveste
ricevuto questo messaggio per errore siete pregati di informare
immediatamente il mittente (via email) e di distruggere questa email e
gli allegati dal vostro sistema. Qualsiasi uso, distribuzione,
riproduzione o rivelazione da parte di terzi diversi dal destinatario e'
severamente vietata per legge.
Grazie

This email and any attachments are confidential and may also be
privileged. If you are not the intended recipient and have received this
message in error, please immediately notify the sender (by email) and
delete this email and any attachments from your system. You are hereby
notified that any use, distribution, reproduction or disclosure by any
person other than the intended recipient is strictly prohibited.
Thank you 

___
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] Precise Time transfer and relative position over a short baseline

2016-04-11 Thread Ilia Platone
As alternative to independent clocks and single photon tagging, we
considered to use TDCs: a possible solution would be radio cross links
between the telescopes that drive the start/stop signals of the TDCs,
then we'd tag only the lapses between photon detection from each
telescope. In this way a single clock would be used on a receiving and
recording station.

Is this a good solution?
Regards,
Ilia.

Il 11/04/2016 07:00, Bruce Griffiths ha scritto:
> There is a proposal to use multiple light bucket style optical telescopes to 
> do Intensity stellar Interferometry over short baselines (up to perhaps 1km  
> or so) by using independent clocks to time tag photon  arrivals. store the 
> time tags and process the data off line. Depending on the time tag resolution 
> there is a need to measure the time differences between the independent 
> clocks to an accuracy in the 1ns to 100ps range. Is there a better way of 
> doing this other than using geodetic grade GPS receivers capable of GPS 
> carrier phase measurements?Since the local clock flywheel oscillators will 
> need to not deviate by more than 100ps or so over the several minutes 
> required to perform the carrier phase averaging what sort of clock will be 
> suitable apart from a good rubidium standard with a cleanup oscillator?
> NB Running fibres or coax between the telescopes isnt an option.
>
> The relative positions of the telescopes has to be known to within a cm or so 
> for this to work.
> Bruce
>
> ___
> 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.
>

-- 
*Ilia Platone
via Ferrara 54
47841
Cattolica (RN), Italy
Cell +39 349 1075999
* --
Questa email e qualsiasi allegato sono riservati e potrebbero anche
essere confidenziali. Qualora non foste il destinatario ed aveste
ricevuto questo messaggio per errore siete pregati di informare
immediatamente il mittente (via email) e di distruggere questa email e
gli allegati dal vostro sistema. Qualsiasi uso, distribuzione,
riproduzione o rivelazione da parte di terzi diversi dal destinatario e'
severamente vietata per legge.
Grazie

This email and any attachments are confidential and may also be
privileged. If you are not the intended recipient and have received this
message in error, please immediately notify the sender (by email) and
delete this email and any attachments from your system. You are hereby
notified that any use, distribution, reproduction or disclosure by any
person other than the intended recipient is strictly prohibited.
Thank you 

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