Re: [time-nuts] Question about frequency counter testing

[Magnus Danielson]

Hi Oleg,

On 05/18/2018 12:25 AM, Oleg Skydan wrote:
> Hi, Magnus!
> 
> --
> From: "Magnus Danielson" 
>>> 2. Study how PDEV calculation fits on the used HW. If it is possible to
>>> do in real time PDEV option can be added.
>>
>> You build two sums C and D, one is the phase-samples and the other is
>> phase-samples scaled with their index n in the block. From this you can
>> then using the formulas I provided calculate the least-square phase and
>> frequency, and using the least square frequency measures you can do
>> PDEV. The up-front processing is thus cheap, and there is meathods to
>> combine measurement blocks into longer measurement blocks, thus
>> decimation, using relatively simple linear processing on the block sums
>> C and D, with their respective lengths. The end result is that you can
>> very cheaply decimate data in HW/FW and then extend the properties to
>> arbitrary long observation intervals using cheap software processing and
>> create unbiased least square measurements this way. Once the linear
>> algebra of least square processing has vanished in a puff of logic, it
>> is fairly simple processing with very little memory requirements at
>> hand. For multi-tau, you can reach O(N log N) type of processing rather
>> than O(N^2), which is pretty cool.
> 
> I had some free time today to study the document you suggested and do
> some experiments in matlab - it was very useful reading and experiments,
> thanks!

Thanks for the kind words!

> It looks like the proposed method of decimation can be
> efficiently realized on the current HW.

The algorithm was crafted with the aim of achieving just that. It's
really a powerful method.

> Also as a side effect calculating large averaging in several blocks should 
> reduce floating
> point associated errors which can reach significant values with careless 
> coding.

Indeed. The framework provided should allow numerically precision to be
crafted without too much difficulty, which is another goal.

> Also all modes can be unified and can reuse the same acquisition code,
> nice... :)

As intended. :)

The C sums is what you use of MDEV type of processing.

>> I hope to have an updated version of that article available soon.
> 
> Please share the link if it will be publicly available.

Will do.

 From the 2.5 ns single shot resolution, I deduce a 400 MHz count clock.
>>>
>>> Yes. It is approx. 400MHz.
>>
>> OK, good to have that verified. Free-running or locked to a 10 MHz
>> reference?
> 
> Locked to OCXO (10MHz).

OK. I saw some odd frequencies, and I agree with Bob that if you can,
using two of those with non-trivial relationship can be used to get
really good performance.

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.

Re: [time-nuts] Question about frequency counter testing

[Oleg Skydan]

Hi, Magnus!

--
From: "Magnus Danielson" 

2. Study how PDEV calculation fits on the used HW. If it is possible to
do in real time PDEV option can be added.


You build two sums C and D, one is the phase-samples and the other is
phase-samples scaled with their index n in the block. From this you can
then using the formulas I provided calculate the least-square phase and
frequency, and using the least square frequency measures you can do
PDEV. The up-front processing is thus cheap, and there is meathods to
combine measurement blocks into longer measurement blocks, thus
decimation, using relatively simple linear processing on the block sums
C and D, with their respective lengths. The end result is that you can
very cheaply decimate data in HW/FW and then extend the properties to
arbitrary long observation intervals using cheap software processing and
create unbiased least square measurements this way. Once the linear
algebra of least square processing has vanished in a puff of logic, it
is fairly simple processing with very little memory requirements at
hand. For multi-tau, you can reach O(N log N) type of processing rather
than O(N^2), which is pretty cool.


I had some free time today to study the document you suggested and do some 
experiments in matlab - it was very useful reading and experiments, thanks! 
It looks like the proposed method of decimation can be efficiently realized 
on the current HW. Also as a side effect calculating large averaging in 
several blocks should reduce floating point associated errors which can 
reach significant values with careless coding.


Also all modes can be unified and can reuse the same acquisition code, 
nice... :)



I hope to have an updated version of that article available soon.


Please share the link if it will be publicly available.


From the 2.5 ns single shot resolution, I deduce a 400 MHz count clock.


Yes. It is approx. 400MHz.


OK, good to have that verified. Free-running or locked to a 10 MHz
reference?


Locked to OCXO (10MHz).

All the best!
Oleg 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Question about frequency counter testing

[Magnus Danielson]

Hi,

On 05/13/2018 11:13 PM, Oleg Skydan wrote:
> Hi Magnus,
> 
> From: "Magnus Danielson" 
>> I would be inclined to just continue the MDEV compliant processing
>> instead. If you want the matching ADEV, rescale it using the
>> bias-function, which can be derived out of p.51 of that presentation.
>> You just need to figure out the dominant noise-type of each range of
>> tau, something which is much simpler in MDEV since White PM and Flicker
>> PM separates more clearly than the weak separation of ADEV.
> 
> 
>> As you measure a DUT, the noise of the DUT, the noise of the counter and
>> the systematics of the counter adds up and we cannot distinguish them in
>> that measurement.
> 
> Probably I did not express what I meant clearly. I understand that we
> can not separate them, but if the DUT noise has most of the power inside
> the filter BW while instrument noise is wideband one, we can filter out
> part of instrument noise with minimal influence to the DUT one.

Yes, if you for a certain range can show that the instruments noise is
not dominant, then you measure the DUT. This is what happens as the
1/tau slope on the ADEV reaches down the DUT noise, where the resulting
curve is mostly DUT noise.

We may then hunt better counters to shift that slope leftwards on the
plot to see more of the DUT noise.

>> There is measurement setups, such as
>> cross-correlation, which makes multiple measurements in parallel which
>> can start combat the noise separation issue.
> 
> Yes, I am aware of that technique. I event did some experiments with
> cross correlation phase noise measurements.

Check.

>> Ehm no. The optimal averaging strategy for ADEV is to do no averaging.
>> This is the hard lesson to learn. You can't really cheat if you aim to
>> get proper ADEV.
>>
>> You can use averaging, and it will cause biased values, so you might use
>> the part with less bias, but there is safer ways of doing that, by going
>> full MDEV or PDEV instead.
>>
>> With biases, you have something similar to, but not being _the_ ADEV.
> 
> OK. It looks like the last sentence very precisely describes what I was
> going to do, so we understood each other right. Summarizing the
> discussion, as far as I understand, the best strategy regarding *DEV
> calculations is:
> 1. Make MDEV the primary variant. It is suitable for calculation inside
> counter as well as for exporting data for the following post processing.

Doable.

> 2. Study how PDEV calculation fits on the used HW. If it is possible to
> do in real time PDEV option can be added.

You build two sums C and D, one is the phase-samples and the other is
phase-samples scaled with their index n in the block. From this you can
then using the formulas I provided calculate the least-square phase and
frequency, and using the least square frequency measures you can do
PDEV. The up-front processing is thus cheap, and there is meathods to
combine measurement blocks into longer measurement blocks, thus
decimation, using relatively simple linear processing on the block sums
C and D, with their respective lengths. The end result is that you can
very cheaply decimate data in HW/FW and then extend the properties to
arbitrary long observation intervals using cheap software processing and
create unbiased least square measurements this way. Once the linear
algebra of least square processing has vanished in a puff of logic, it
is fairly simple processing with very little memory requirements at
hand. For multi-tau, you can reach O(N log N) type of processing rather
than O(N^2), which is pretty cool.

I hope to have an updated version of that article available soon.

> 3. ADEV can be safely calculated only from the Pi mode counter data.
> Probably it will not be very useful because of low single shoot
> resolution, but Pi mode and corresponding data export can be easily added.

You will be assured it is bias-free. You want to have that option.

> I think it will be more than enough for my needs, at least now.
> 
>> From the 2.5 ns single shot resolution, I deduce a 400 MHz count clock.
> 
> Yes. It is approx. 400MHz.

OK, good to have that verified. Free-running or locked to a 10 MHz
reference?

>>> I have no FPGA also :) All processing is in the FW, I will see how it
>>> fits the used HW architecture.
>>>
>>> Doing it all in FPGA has many benefits, but the HW will be more
>>> complicated and pricier with minimal benefits for my main goals.
>>
>> Exactly what you mean by FW now I don't get, for me that is FPGA code.
> 
> I meant MCU code, to make things clearer I can use the SW term for it.
> 
> Thank you for the answers and explanations, they are highly appreciated!

Nice! Really hope you can make sense out of them and apply them. I hope
I contribute to insight about what to do when to do good measurements.

Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to 

Re: [time-nuts] Possible new run of TNS-BUF High Isolation, Low Noise Buffer Amp boards

[Magnus Danielson]

Hi John,

I missed the original run, and this is one of the things I sure would
gather a few, and hope they could also get into a more continuous
availability.

I intend to get a couple, but I would potentially want more later, but I
don't always have the resources to get that lifetime supply.

Appreciate the effort greatly, and when possible, I also recommend
friends to take a look at these projects just to get them of the ground.

Cheers,
Magnus

On 05/08/2018 09:09 PM, John Ackermann N8UR wrote:
> Back in October, 2016, TAPR did a build-to-order offering of the TNS-BUF
> low noise, high isolation buffer amplifier.  The original 2016 post is
> attached below.  All of those units sold out, and recently I've had a
> few questions about whether more will be available.
> 
> TAPR will do another one-off production run if we can get orders for at
> least 25 boards (the minimum to make manufacturing viable) by *June 1*.
> You can place an order by going to http://tapr.org/kits_tns-buf.  The
> price will be the same as the previous production -- $119 plus shipping.
> 
> If we receive orders for at least 25 boards by June 1, we will charge
> credit cards and place the production order with our contract
> manufacturer.  If we don't get 25 orders, we'll cancel the project and
> your card will not be charged.
> 
> We expect to ship finished TNS-BUF boards about 60 days after placing
> the production order.
> 
> Best regards,
> John
> 
>  Forwarded Message 
> Subject: [time-nuts] TNS-BUF High Isolation, Low Noise Buffer Amp Available
> Date: Wed, 5 Oct 2016 10:15:46 -0400
> From: John Ackermann N8UR 
> 
> I've previously mentioned a high performance buffer amplifier called the
> "TNS-BUF" that I built based on a design by Dr. Bruce Griffiths with
> further input from John Miles. Key numbers are:
> 
> *  Phase noise -140dBc/Hz at 1 Hertz offset, noise floor -175dBc/Hz.
>     (PN plot attached)
> *  Reverse isolation greater than 100dB; low enough that I can't make a
>     trustworthy measurement.
> *  Gain from -10 to +7 dB from 1 to 30 MHz; maximum output >18dBm.
> *  Nominal 18VDC operation, but works down to 12V with lowered
>     maximum output level.
> 
> There's information, including performance data and schematic, at
> http://www.febo.com/pages/TNS-BUF
> 
> There seems to be some interest in an amplifier like this, so TAPR has
> decided to do a limited production run.  The amp is built with surface
> mount parts, so we thought an assembled and tested board was better than
> a kit.  The price will be $119 each.  But we have no idea how much
> interest there is, and we need to build a minimum of 25 units to make
> production feasible.
> 
> So, here's the deal:  you can order your TNS-BUF at
> 
> http://tapr.org/kits_tns-buf
> 
> through *October 20*.  If we receive orders for at least 25 boards by
> then, we will charge credit cards and place the production order with
> our contract manufacturer.  If we don't get 25 orders, we'll cancel the
> project and credit cards will not be charged.  There's no guarantee that
> boards will be available for later order.
> 
> We expect about 60 days between placing the manufacturing order and
> receipt of the boards at TAPR.  We'll ship to customers ASAP after
> receipt.  So that means you can expect to receive your order shortly
> after January 1.
> 
> So, go to http://tapr.org/kits_tns-buf now to place your order before
> the deadline!
> 
> John
> 
> 
> 
> 
> ___
> 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.