Re: [time-nuts] Question about frequency counter testing
Hi, Magnus! Sorry for the late answer, I injured my left eye last Monday, so had very limited abilities to use computer. From: "Magnus Danielson" As long as the sums C and D becomes correct, your path to it can be whatever. Yes. It produces the same sums. Yes please do, then I can double check it. I have write a note and attached it. The described modifications to the original method were successfully tested on my experimental HW. Yeah, now you can move your harware focus on considering interpolation techniques beyond the processing power of least-square estimation, which integrate noise way down. If you are talking about adding traditional HW interpolation of the trigger events I have no plans to do it. It is not possible to do it keeping 2.5ns base counter resolution (there is no way to output 400MHz clock signal out of the chip) and I do not want to add extra complexity to the HW of this project. But, the HW I use can simultaneously sample up to 10 timestamps. So, I can push the one shoot resolution down to 250ps using several delay lines (theoretically). I do not think that going down to 250ps has much sense (also I have another plans for that additional HW), but 2x or 4x one shot resolution improvement (down to 1.25ns or 625ps) is relatively simple to implement in HW and should be a good idea to try. I will probably throw out the power hungry and expensive SDRAM chip or use much smaller one :). Yeah, it would only be if you build multi-tau PDEV plots that you would need much memory, other than that it is just buffer memory to buffer before it goes to off-board processing, at which time you would need to convey the C, D, N and tau0 values. Yes, I want to produce multi-tau PDEV plots :). They can be computed with small memory footprint, but it will be non overlapped PDEVs, so the confidence level at large taus will be poor (with the practical durations of the measurements). I have a working code that realizes such algorithm. It uses only 272bytes of memory for each decade (1-2-5 values). I need to think how to do the overlapping PDEV calculations with minimal memory/processing power requirements (I am aware that decimation routines should not use the overlapped calculations). BTW, are there any "optimal overlapping"? Or I should just use as much data as I can process? Please report on that progress! Sounds fun! I will drop a note when I will move on the next step. The things are a bit slower now. Thanks! Oleg Efficient C and D sums calculation for least square estimation of phase, frequency and PDEV.pdf Description: Adobe PDF document ___ 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
Hi! From: "Magnus Danielson" 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. I had some free time yesterday and today, so I decided to test the new algorithms on the real hardware (the HW is still an old "ugly construction" one, but I hope I will have some time to make normal HW - I have already got almost all components I need). I had to modify the original decimation scheme you propose in the paper, so it better fits my HW, also the calculation precision and speed should be higher now. The nice side effect - I do not need to care about phase unwrapping anymore. I can prepare a short description of the modifications and post it here, if it is interesting. It works like a charm! The new algorithm (base on C and D sums calculation and decimation) uses much less memory (less than 256KB for any gaiting time/sampling speed, the old one (direct LR calculation) was very memory hungry - it used 4xSampling_Rate bytes/s - 20MB per second of the gate time for 5MSPS). Now I can fit all data into the internal memory and have a single chip digital part of the frequency counter, well, almost single chip ;) The timestamping speed has increased and is limited now by the bus/bus matrix switch/DMA unit at a bit more then 24MSPS with continuous real time data processing. It looks like it is the limit for the used chip (I expected a bit higher numbers). The calculation speed is also much higher now (approx 23ns per one timestamp, so up to 43MSPS can be processed in realtime). I plan to stay at 20MSPS rate or 10MSPS with the double time resolution (1.25ns). It will leave a plenty of CPU time for the UI/communication/GPS/statistics stuff. I will probably throw out the power hungry and expensive SDRAM chip or use much smaller one :). I have some plans to experiment with doubling the one shoot resolution down to 1.25ns. I see no much benefits from it, but it can be made with just a piece of coax and a couple of resistors, so it is interesting to try :). All the best! Oleg UR3IQO ___ 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] ✘NEO-M8N vs. NEO-M8T
From: "Bob kb8tq" You have always been able to poll the time offset message on any of the uBlox modules. Getting that message to auto repeat was the traditional issue on there earlier products. A serial dump would tell you if u-center is getting the information by polling or not. Thanks for the information. I have checked the console dump (of the NEO-6M module), it does not poll for TIM-TP, the message is sent automatically (after enabling in u-center). 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] ✘NEO-M8N vs. NEO-M8T
Hi! From: "Bob kb8tq" Not by default You go through the 390 pages of their manual and eventually find the bits to turn this and that on. When you do, those magic bits will enable the data on a T version and will not enable it on a non-T version. At least that’s the way it’s worked since the LEA-4T … You can use uBlox u-center software to enable and disable messages you need, the configuration can be saved. It looks like the NEO-M8N (non timing one) module should provide sawtooth correction data (at least the manual does not say that TIM-TP message is available on timing modules only). I was able to enable TIM-TP message on the older NEO-6M. You can test if it works with the help of u-center. 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
Hi! -- From: "Magnus Danielson" 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. I can use two or more, but unfortunately not simultaneously. So I will switch frequency if the problem is detected. Switching will interact with GPS data processing, but that probably can be fixed in software (I had no time to investigate the possible solutions and find the best one yet). BTW, the single shoot resolution can be doubled (to 1.25ns) with almost no additional HW (just a delay line for a bit more than 1.25ns and some resistors). Not sure if it worth to do (it also will halve the timestamping speed and double the timestamps memory requirements, so, in averaging modes it will be only sqrt(2) improvement). 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
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
Hi From: "Bob kb8tq" What I’m suggesting is that if the hardware is very simple and very cheap, simply put two chips on the board. One runs at Clock A and the other runs at Clock B. At some point in the process you move the decimated data from B over to A and finish out all the math there …. The hardware is simple and cheap cause it is all digital, requires no calibrations and the same HW is capable of driving TFT, UI handling, providing all control functionalities for input conditioning circuits, GPS module and etc. It also provides USB interface for data exchange or remote control. So doubling it is not a way to go if I want to keep things simple and relatively cheap. I think I will stay with the current plans for HW and try to handle some troubles to GPS timing in software. I have to make initial variant of HW, so I will be able to move on with the SW part towards useful counter. Then I will see how well it performs and will decide if it satisfies the requirements or I need to change something. BTW, after quick check of the GPS module specs and OCXO's one it looks like a very simple algorithm can be used for frequency correction. OCXO frequency can be measured against GPS for a long enough period (some thousands of seconds, LR algorithm can be used here also) and we have got a correction coefficient. It can be updated at a rate of one second (probably we do not need to do it as fast). I do not believe it can be as simple. I feel I missed something :)… That is one way it is done. A lot depends on the accuracy of the GPS PPS on your module. The module is uBlox NEO-6M, I know there is better suited for my needs NEO-6T, but the first one was easy to get and insanely cheap. It should be enough to start. More or less, with a thousand second observation time you will likely get below parts in 10^-10, but maybe not to the 1x10^-11 level. 1e-10 should satisfy my requirements. More sophisticated algorithm can be developed and used later, if needed. Thanks! 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
Hi! From: "Bob kb8tq" If such conditions detected, I avoid problem by changing the counter clock. But it does not solve the effects at "about OCXO" * N or "about OCXO" / M. It is related to HW and I can probably control it only partially. I will try to improve clock and reference isolation in the "normal" HW and of cause I will thoroughly test such frequencies when that HW will be ready. It’s a very common problem in this sort of counter. The “experts” have a lot of trouble with it on their designs. One answer with simple enough hardware could be to run *two* clocks all the time. Digitize them both and process the results from both. I thought about such solution, unfortunately it can not be implemented because of HW limitations. Switching 400MHz clock is also not ideal solution, cause it will make trouble to GPS correction calculations, the latter can be fixed in software, but it is not an elegant solution. It all still needs some polishing... still have the issue of a frequency that is a multiple (or sub multiple) of both clocks. The clocks (if we are talking about 400MHz) has very interesting values like 397501220.703Hz or 395001831.055Hz , so it will really occur very rarely. Also I am not limited by two or three values, so clock switching should solve the problem, but not in elegant way, cause it breaks normal work of GPS frequency correction algorithm, so additional steps to fix that will be required :-\. BTW, after quick check of the GPS module specs and OCXO's one it looks like a very simple algorithm can be used for frequency correction. OCXO frequency can be measured against GPS for a long enough period (some thousands of seconds, LR algorithm can be used here also) and we have got a correction coefficient. It can be updated at a rate of one second (probably we do not need to do it as fast). I do not believe it can be as simple. I feel I missed something :)... 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
Hi Bob! From: "Bob kb8tq" 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. I think I would spend more time working out what happens at “about 400 MHz” X N or “about 400 MHz / M” ……. If such conditions detected, I avoid problem by changing the counter clock. But it does not solve the effects at "about OCXO" * N or "about OCXO" / M. It is related to HW and I can probably control it only partially. I will try to improve clock and reference isolation in the "normal" HW and of cause I will thoroughly test such frequencies when that HW will be ready. 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
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. 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. 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. 2. Study how PDEV calculation fits on the used HW. If it is possible to do in real time PDEV option can be added. 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. 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. 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! 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
Hi Bob! From: "Bob kb8tq" I guess it is time to ask: Is this a commercial product you are designing? No. I have no abilities to produce it commercially and I see no market for such product. I will build one unit for myself, I may build several more units for friends or if somebody will like it. I will show the HW details when it will be ready. What I gain doing it? 1. I will have a new counter that suits my current needs 2. I will study something new If so, that raises a whole added layer to this discussion in terms of “does it do what it says it does?”. This question is also important for amateur/hobby measurement equipment. I do not need equipment that "does not do what it says it does" even if it is build for hobby use. The theme about *DEV calculations has many important details I want to understand right, sorry if I asked too many questions (some of them probably were naive) and thank you for the help, it is very appreciated! I hope our discussion is useful not only for me. Thanks! 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
Hi Magnus! From: "Magnus Danielson" The leftmost tau values are skipped and they "stay" inside the counter. If I setup counter to generate lets say 1s stamps (ADEV starts at 1s) it will generate internally 1/8sec averaged measurements, but export combined data for 1s stamps. The result will be strictly speaking different, but the difference should be insignificant. What is your motivation for doing this? My counter can operate in usual Pi mode - I got 2.5ns resolution. I am primary interested in high frequency signals (not one shoot events), and HW is able to collect and process some millions of timestamps continuously. So in Delta or Omega mode I can improve the resolution in theory down to several ps (for 1s measurement interval). In reality the limit will be somewhat higher. So I can compute the classical ADEV (using Pi mode) with a lot of counter noise at low tau (it will probably not be very useful due to the counter noise dominance in the leftmost part of ADEV plot), or MDEV (using Delta mode) with the counter noise much lower. I would like to try to use the excessive data I have to increase counter resolution in a manner that ADEV calculation with such preprocessing is still possible with acceptable accuracy. After Bob's explanations and some additional reading I was almost sure it is not possible (and it is so in general case), but then I saw the presentation http://www.rubiola.org/pdf-slides/2012T-IFCS-Counters.pdf (E. Rubiola, High resolution time and frequency counters, updated version) and saw inferences on p.54. They looks reasonable and it is just what I wanted to do. The mistake is easy to make. Back in the days, it was given that you should always give the system bandwidth alongside a ADEV plot, a practice that later got lost. Many people does not know what bandwidth they have, and the effect it has on the plot. I've even heard distinguished and knowledgeable person in the field admit of doing it incorrect. That makes sense. We can view at the problem in the frequency domain. We have a DUT, reference and instrument (counter) noise. In most cases we are interested in suppressing instrument and reference noise and leaving the DUT noise. The reference and DUT has more or less the same nature of noise, so it should not be possible to filter out reference noise without affecting DUT noise (with the simple HW). The counter noise (in my case) will look like white noise (at least the noise associated with the absence of the HW interpolator). When we process timestamps by Omega or Delta data processing we apply filter, so the correctness of the resulting data will depend of the DUT noise characteristics and filter shape. The ADEV calculation at tau > tau0 will also apply some sort of filter during decimation, it also should be counted for (cause we actually decimate the high rate timestamp stream making the points data for the following postprocessing). Am I right? Here is a good illustration how averaging affects ADEV http://www.leapsecond.com/pages/adev-avg/ . If we drop the leftmost part of the ADEV affected by averaging, the resulting averaging effects on the ADEV are minimized. Also they can be minimized by the optimal averaging strategy. The question is optimal averaging strategy and well defined restrictions when such preprocessing can be applied. If it works I would like to add such mode for the compatibility with the widely spread post processing SW (TimeLab is a good example). Of cause I can do calculations inside the counter without such limitations, but that will be another data processing option(s) (which might not be always suitable). I'm not saying you are necessarilly incorrect, but it would be interesting to hear your motivation. The end goal is to have a counter mode when the counter produces data suitable for post processing for ADEV and other similar statistics with resolution better (or counter noise lower) that one shoot one (Pi counter). I understand that, if it will be possible, the counter resolution will be degraded compared to usual Omega or Delta mode, also there will be some limitations for the DUT noise when such processing can be applied. Cross talk exists for sure, but there is a similar effect too which is not due to cross-talk but due to how the counter is able to interpolate certain frequencies. I have no HW interpolator. The similar problem in the firmware was discussed earlier and now it is fixed. If fact, you can do a Omega-style counter you can use for PDEV, you just need to use the right approach to be able to decimate the data. Oh, there's a draft paper on that: https://arxiv.org/abs/1604.01004 Thanks for the document. It needs some time to study and maybe I will add the features to the counter to calculate correct PDEV. It suggest a very practical method for FPGA based counters, so that you can make use of the high rate of samples that you have and reduce it in HW before handing
Re: [time-nuts] Question about frequency counter testing
Hi Bob! From: "Bob kb8tq" It’s only useful if it is accurate. Since you can “do code” that gives you results that are better than reality, simply coming up with a number is not the full answer. To be useful as ADEV, it needs to be correct. I understand it, so I try to investigate the problem to understand what can be done (if any :). I’m sure it will come out to be a very cool counter. My *only* concern here is creating inaccurate results by stretching to far with what you are trying to do. Keep it to the stuff that is accurate. I am interested in accurate results or at least with well defined limitations for a few specific measurements/modes. So I will try to make results as accurate as I can do/it can be done keeping simple hardware. Thanks! 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
Hi! From: "Magnus Danielson" ADEV assumes brick-wall filtering up to the Nyquist frequency as result of the sample-rate. When you filter the data as you do a Linear Regression / Least Square estimation, the actual bandwidth will be much less, so the ADEV measures will be biased for lower taus, but for higher taus less of the kernel of the ADEV will be affected by the filter and thus the bias will reduce. Thanks for clarification. Bob already pointed me to problem and after some reading *DEV theme seems to be clearer. Does the ADEV plots I got looks reasonable for the used "mid range" OCXOs (see the second plot for the long run test)? You probably want to find the source of the wavy response as the orange and red trace. I have already found the problem. It is HW problem related to poor isolation between reference OCXO signal and counter input signal clock line (it is also possible there are some grounding or power supply decoupling problems - the HW is made in "ugly construction" style). When the input clock frequency is very close (0.3..0.4Hz difference) to the OCXO subharmonic this problem become visible (it is not FW problem discussed before, cause counter reference is not a harmonic of the OCXO anymore). It looks like some commercial counters suffers from that problem too. After I connected OCXO and input feed lines with short pieces of the coax this effect greatly decreased, but not disappeared. The "large N" plots were measured with the input signal 1.4Hz (0.3ppm) higher then 1/2 subharmonic of the OCXO frequency, with such frequency difference that problem completely disappears. I will check for this problem again when I will move the HW to the normal PCB. If fact, you can do a Omega-style counter you can use for PDEV, you just need to use the right approach to be able to decimate the data. Oh, there's a draft paper on that: https://arxiv.org/abs/1604.01004 Thanks for the document. It needs some time to study and maybe I will add the features to the counter to calculate correct PDEV. If ADEV is needed, the averaging interval can be reduced and several measurements (more then eight) can be combined into one point (creating the new weighting function which resembles the usual Pi one, as shown in the [1] p.54), it should be possible to calculate usual ADEV using such data. As far as I understand, the filter which is formed by the resulting weighting function will have wider bandwidth, so the impact on ADEV will be smaller and it can be computed correctly. Am I missing something? Well, you can reduce averaging interval to 1 and then you compute the ADEV, but it does not behave as the MDEV any longer. With no averaging it will be a simple reciprocal counter with time resolution of only 2.5ns. The idea was to use trapezoidal weighting, so the counter will become somewhere "between" Pi and Delta counters. When the upper base of the weighting function trapezium is 0 length (triangular weighting) it is usual Delta counter, if it is infinitely long the result should converge to usual Pi counter. Prof. Rubiola claims if the ratio of upper to lower base is more than 8/9 the ADEV plots made from such data should be sufficiently close to usual ADEV. Of cause the gain from the averaging will be at least 3 times less than from the usual Delta averaging. Maybe I need to find or make "not so good" signal source and measure its ADEV using above method and compare with the traditional. It should be interesting experiment. What you can do is that you can calculate MDEV or PDEV, and then apply the suitable bias function to convert the level to that of ADEV. That can be done if the statistics is calculated inside the counter, but it will not make the exported data suitable for post processing with the TimeLab or other software that is not aware of what is going on inside the counter. Yes, they give relatively close values of deviation, where PDEV goes somewhat lower, indicating that there is a slight advantage of the LR/LS frequency estimation measure over that of the Delta counter, as given by it's MDEV. Here is another question - how to correctly calculate averaging length in Delta counter? I have 5e6 timestamps in one second, so Pi and Omega counters process 5e6 samples totally and one measurement have also 5e6 samples, but the Delta one processes 10e6 totally with each of the averaged measurement having 5e6 samples. Delta counter actually used two times more data. What should be equal when comparing different counter types - the number of samples in one measurement (gating time) or the total number of samples processed? Thanks! 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
Hi! From: "Bob kb8tq" There is still the problem that the first post on the graph is different depending on the technique. The leftmost tau values are skipped and they "stay" inside the counter. If I setup counter to generate lets say 1s stamps (ADEV starts at 1s) it will generate internally 1/8sec averaged measurements, but export combined data for 1s stamps. The result will be strictly speaking different, but the difference should be insignificant. The other side of all this is that ADEV is really not a very good way to test a counter. Counter testing was not a main reason to dig into statistics details last days. Initially I used ADEV when tried to test the idea of making the counter with very simple HW and good resolution (BTW, it appeared later it was not ADEV in reality :). Then I saw it worked, so I decided to make a "normal" useful counter (I liked the HW/SW concept). The HW has enough power to compute various statistics onboard in real time, and while it is not requisite feature of the project now, I think it will be good if the counter will be able to do it (or at least if it will export data suitable to do it in post process). The rest of the story you know :) If you are trying specifically just to measure ADEV, then there are a lot of ways to do that by it’s self. Yes, but if it can be done with only some additional code - why not to have such ability? Even if it has some known limitations it is still a useful addition. Of cause it should be done as good as it can be with the HW limitations. Also it was/is a good educational moment. Now it is period of tests/experiments to see the used technology features/limitations(of cause if those experiments can be done with the current "ugly style HW"). I have already got a lot of useful information, it should help me in the following HW/FW development. The next steps are analog front end and GPS frequency correction (I should get the GPS module next week). I have already tested the 6GHz prescaler and now wait for some parts to finish it. Hope this project will have the "happy end" :). 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
Hi -- From: "Bob kb8tq" The most accurate answer is always “that depends”. The simple answer is no. I have spent the yesterday evening and quite a bit of the night :) reading many interesting papers and several related discussions in the time-nuts archive (the Magnus Danielson posts in "Modified Allan Deviation and counter averaging" and "Omega counters and Parabolic Variance (PVAR)" topics were very informative and helpful, thanks!). It looks like the trick to combine averaging with the possibility of correct ADEV calculation in the post processing exists. There is a nice presentation made by prof. Rubiola [1]. There is a suitable solution on page 54 (at least I understood it so, maybe I am wrong). I can switch to usual averaging (Lambda/Delta counter) instead of LR calculation (Omega counter), the losses should be very small I my case. With such averaging the MDEV can be correctly computed. If ADEV is needed, the averaging interval can be reduced and several measurements (more then eight) can be combined into one point (creating the new weighting function which resembles the usual Pi one, as shown in the [1] p.54), it should be possible to calculate usual ADEV using such data. As far as I understand, the filter which is formed by the resulting weighting function will have wider bandwidth, so the impact on ADEV will be smaller and it can be computed correctly. Am I missing something? I have made the necessary changes in code, now firmware computes the Delta averaging, also it computes combined Delta averaged measurements (resulting in trapezoidal weighting function), both numbers are computed with continuous stamping and optimal overlapping. Everything is done in real time. I did some tests. The results are very similar to the ones made with LR counting. [1] http://www.rubiola.org/pdf-slides/2012T-IFCS-Counters.pdf E. Rubiola, High resolution time and frequency counters, updated version. All the best! Oleg UR3IQO ___ 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
Bob, thanks for clarification! From: "Bob kb8tq" If you collect data over the entire second and average that down for a single point, then no, your ADEV will not be correct. That probably explains why I got so nice (and suspicious) plots :) There are a number of papers on this. What ADEV wants to see is a single phase “sample” at one second spacing. After I read your answer I remembered some nice papers from prof. Rubiola, me bad - I was able to answer my question by myself. When we take a single phase "sample" at start and at end time of the "each tau" it is equivalent to summing all timestamps intervals I collect during that "tau", but by doing LR processing I calculate *weighted* sum, so the results will differ. So, it appears "ADEV" calculations is PDEV (parabolic) in reality, because of the current firmware processing. I made a test with two plots for illustration - one is the classical ADEV (with 2.5ns time resolution), the second one with LR processed data (5e6 timestamps per second). Both plots are made from the same data. It is obvious the classical ADEV is limited by the counter resolution in the left part of the plot. It is interesting is it possible to use the 498 extra points per each second to improve counter resolution in ADEV measurements without affecting ADEV? Thanks! Oleg UR3IQO ___ 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
Hi I have got a pair of not so bad OCXOs (Morion GK85). I did some measurements, the results may be interested to others (sorry if not), so I decided to post them. I ran a set of 5minutes long counter runs (two OCXOs were measured against each other), each point is 1sec gate frequency measurement with different number of timestamps used in LR calculation (from 10 till 5e6). The counter provides continuous counting. As you can see I reach the HW limitations at 5..6e-12 ADEV (1s tau) with only 1e5 timestamps. The results looks reasonable, the theory predicts 27ps equivalent resolution with 1e5 timestamps, also the sqrt(N) law is clearly seen on the plots. I do not know what is the limiting factor, if it is OCXOs or some counter HW. I know there are HW problems, some of them were identified during this experiment. They were expectable, cause HW is still just an ugly construction made from the boards left in the "radio junk box" from the other projects/experiments. I am going to move to the well designed PCB with some improvements in HW (and more or less "normal" analog frontend with good comparator, ADCMP604 or something similar, for the "low frequency" input). But I want to finish my initial tests, it should help with the HW design. Now I have some questions. As you know I am experimenting with the counter that uses LR calculations to improve its resolution. The LR data for each measurement is collected during the gate time only, also measurements are continuous. Will the ADEV be calculated correctly from such measurements? I understand that any averaging for the time window larger then single measurement time will spoil the ADEV plot. Also I understand that using LR can result in incorrect frequency estimate for the signal with large drift (should not be a problem for the discussed measurements, at least for the numbers we are talking about). Does the ADEV plots I got looks reasonable for the used "mid range" OCXOs (see the second plot for the long run test)? BTW, I see I can interface GPS module to my counter without additional HW (except the module itself, do not worry it will not be another DIY GPSDO, probably :-) ). I will try to do it. The initial idea is not try to lock the reference OCXO to GPS, instead I will just measure GPS against REF and will make corrections using pure math in SW. I see some advantages with such design - no hi resolution DAC, reference for DAC, no loop, no additional hardware at all - only the GPS module and software :) (it is in the spirit of this project)... Of cause I will not have reference signal that can be used outside the counter, I think I can live with it. It worth to do some experiments. Best! Oleg UR3IQO ___ 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
Hi From: "Bob kb8tq" Sent: Friday, April 27, 2018 4:38 PM Consider a case where the clocks and signals are all clean and stable: Both are within 2.5 ppb of an integer relationship. ( let’s say one is 10 MHz and the other is 400 MHz ). The amount of information in your data stream collapses. Over a 1 second period, you get a bit better than 9 digits per second. Put another way, the data set is the same regardless of where you are in the 2.5 ppb “space”. Thanks a lot for pointing me to this problem! It looks like that was the reason I lost a digit. The frequency in my experiment appear to be close to the exact subharmonic of the PLL multiplied reference. It was not less than 2.5ppb off frequency (the difference was approx 0.3ppm), but it still was close enough to degrade the resolution. Fortunately it can be fixed in firmware using various methods and I have made the necessary changes. Here are Allan deviation and frequency drift plots. The first one with the old firmware, the second one with the updated firmware that count for the lost of information you mention. The frequency difference plot also shows the measurement "noise" now is much lower. It looks like I have got 11 significant digits now and my old OCXOs are better than manufacturer claims by almost 10 times. Thanks! Oleg UR3IQO ___ 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
From: "Azelio Boriani" Sent: Friday, April 27, 2018 12:16 AM If your hardware is capable of capturing up to 10 millions of timestamps per second and calculating LR "on the fly", it is not a so simple hardware, unless you consider simple hardware a 5megagates Spartan3 (maybe more is needed). Moreover: if your clock is, say, at most in an FPGA, 300MHz, your timestamps will have a one-shot resolution of few nanoseconds. There is no FPGA. If I would use FPGA I probably should be able to get more resolution for one shoot measurements, cause there are some simple methods of interpolating signal inside FPGA (they do not require additional hardware). They can increase resolution by 2..16 times easily. So even with 200MHz internal FPGA clock it is possible to reach 1ns one shoot resolution or even better. I will show details when the project will be at the finishing stage. Where have you found a detailed description of the CNT91 counting method? The only detailed description I have found is the CNT90 (not 91) service manual and it uses interpolators (page 4-13 of the service manual). Sorry, I meant CNT-90, but I bet cnt90/cnt91 use the same technique. You can use interpolator along with the math processing. This will result in better resolution and/or you can use less memory and less processing power. I choose not use one to simplify the hardware. ___ 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
From: "Hal Murray"
Sent: Thursday, April 26, 2018 10:28 PM
Is there a term for what I think you are doing?
I saw different terms like "omega counter" or multiple time-stamp
average counter, probably there are others too.
If I understand (big if), you are doing the digital version of magic
down-conversion with an A/D. I can't even think of the name for that.
No, it is much simpler. The hardware saves time-stamps to the memory at
each (event) rise of the input signal (let's consider we have digital logic
input signal for simplicity). So after some time we have many pairs of
{event number, time-stamp}. We can plot those pairs with event number on
X-axis and time on Y-axis, now if we fit the line on that dataset the
inverse slope of the line will correspond to the estimated frequency.
The line is fitted using linear regression.
This technique improves frequency uncertainty as
2*sqrt(3)*tresolution/(MeasurementTime * sqrt(NumberOfEvents-2))
So If I have 2.5ns HW time resolution, and collect 5e6 events,
processing should result in 3.9ps resolution.
Of cause this is for the ideal case. The first real life problem is
signal drift for example.
Hope I was able to tell of what I am doing.
BTW, I have fixed a little bug in firmware and now ADEV looks a bit better.
Probably I should look for better OCXOs. Interesting thing - the counter
processed 300GB of time-stamps data during that 8+hour run :).
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
From: "Azelio Boriani" Sent: Thursday, April 26, 2018 10:06 AM Very fast time-stamping like a stable 5GHz counter? No, it is not 5GHz counter. It does the trick I first saw in CNT91 counters. The hardware is capable of capturing up to 10 millions of timestamps per second and calculating LR "on the fly". The plots I showed were made with approx. 5*10^6 timestamps per second, so theoretically I should get approx. 4ps equivalent resolution (or 11+ significant digits in one second). The resolution of a 200ps (one shot) interpolator can be replaced by a 5GHz time-stamping counter. I am not interesting in measuring timings of the single event, and I did not try to make a full featured timer-counter-analyser. It is just a high resolution RF frequency counter with very simple all digital hardware. 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.
[time-nuts] Question about frequency counter testing
Dear Ladies and Gentlemen, Let me tell a little story so you will be able to better understand what my question and what I am doing. I needed to check frequency in several GHz range from time to time. I do not need high absolute precision (anyway this is a reference oscillator problem, not a counter), but I need fast high resolution instrument (at least 10 digits in one second). I have only a very old slow unit so, I constructed a frequency counter (yes, yet another frequency counter project :-). I is a bit unusual - I decided not to use interpolators and maximally simplify hardware and provide the necessary resolution by very fast timestamping and heavy math processing. In the current configuration I should get 11+ digits in one second, for input frequencies more then 5MHz. But this is theoretical number and it does not count for some factors. Now I have an ugly build prototype with insanely simple hardware running the counter core. And I need to check how well it performs. I have already done some checks and even found and fixed some FW bugs :). Now it works pretty well and I enjoyed looking how one OCXO drifts against the other one in the mHz range. I would like to check how many significant digits I am getting in reality. The test setup now comprises of two 5MHz OCXO (those are very old units and far from the perfect oscillators - the 1sec and 10sec stability is claimed to be 1e-10, but they are the best I have now). I measure the frequency of the first OCXO using the second one as counter reference. The frequency counter processes data in real time and sends the continuous one second frequency stamps to the PC. Here are experiment results - plots from the Timelab. The frequency difference (the oscillators are being on for more than 36hours now, but still drift against each other) and ADEV plots. There are three measurements and six traces - two for each measurement. One for the simple reciprocal frequency counting (with R letter in the title) and one with the math processing (LR in the title). As far as I understand I am getting 10+ significant digits of frequency in one second and it is questionable if I see counter noise or oscillators one. I also calculated the usual standard deviation for the measurements results (and tried to remove the drift before the calculations), I got STD in the 3e-4..4e-4Hz (or 6e-11..8e-11) range in many experiments. Now the questions: 1. Are there any testing methods that will allow to determine if I see oscillators noise or counter does not perform in accordance with the theory (11+ digits)? I know this can be done with better OCXO, but currently I cannot get better ones. 2. Is my interpretation of the ADEV value at tau=1sec (that I have 10+ significant digits) right? As far as I understand the situation I need better OCXO's to check if HW/SW really can do 11+ significant digits frequency measurement in one second. Your comments are greatly appreciated! P.S. If I feed the counter reference to its input I got 13 absolutely stable and correct digits and can get more, but this test method is not very useful for the used counter architecture. Thanks! Oleg 73 de UR3IQO ___ 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] Oleg' s PN test Re: A new member & PN test set
-- From: "Bruce Griffiths" You actually need to measure the filter response. OK. It is here (the frequency span is 2..102MHz, the amplitude axis is 10dB/div): http://skydan.in.ua/PNTestSet/PN_LPF1.jpg Sorry, the network analyzer is a bit older than I am :), but it is still in a good condition. At 100MHz we still have more than 40dB attenuation. The inductor I used is low Q axial choke, so I do not expect multiple resonances at higher frequencies - there should be large losses and inductor will look much more like a resistor (at least until we go too high). The capacitors in the pi-LPF are 0805 SMD good quality ones. But, we all like perfect things :), so I tried to make the LPF a bit better adding the BLM31AJ601SN ferrite bead in series with the inductor. Here is the result: http://skydan.in.ua/PNTestSet/PN_LPF2.jpg I like it :) I also did another test checking DC shift at the AD797 output when the mixer was fed with two signal generators (there should be no DC - only different combinations of RF/LO signals). I recalculated all signal levels to LNA input point. Before installing the bead the DC shift was: <150MHz less than 150uV 150..250MHz less than 400uV 250..500MHz less than 1mV After installing the bead: <260MHz less than 80uV There is one big peak near the 300MHz where the DC goes up to 900uV, and several smaller peaks (up to 250uV) higer, up to 500MHz. When the two mixer ports are fed with the same signal (inphase) the DC voltage at LNA input is 130..150mV. With no RF at the mixer ports DC unbalance is 20uV (all voltages recalculated to LNA input). The filter can be made even better by cascading several pi sections using different capacitors and inductors/beads. But as far as I understand, with the current filter even at 500MHz it will not move too far from the quadrature, and at 60MHz everything is definitely OK. 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] Oleg' s PN test Re: A new member & PN test set
-- From: "Bruce Griffiths" Sent: Wednesday, March 30, 2016 7:29 AM To: "Discussion of precise time and frequency measurement" Subject: Re: [time-nuts] Oleg' s PN test Re: A new member & PN test set One hidden issue you don't address is that operation of the 40uH inductor at frequencies above its parallel resonance may allow substantial RF at the sum of the LO and RF frequencies to appear at the opamp input. 120MHz at the 797 input will likely lead to RF rectification effects in the opamp input stage. The resultant offset will create a number of issues including operation away from the quadrature point. Unless you use something like a series string of inductors and/or a conical inductor the first parallel resonance of the 40uH inductor is likely to be somewhat below 120MHz. Ohhh... I do not like words like "substantial", "much more" and etc. I like numbers and tests. ;) So I looked at the Murrata inductors datasheets, and it appeared 40uH inductor will have SRF in 10MHz region. But it does not mean that pi-LPF will not work at the higher frequencies. Actually it mean that our LPF will have response similar to the elliptic filters. So let's draw the model with the inductor with self resonance at 10MHz and well at 120MHz and 1MHz to see how bad the response is: 1MHz: http://skydan.in.ua/PNTestSet/1MSRF.png 10MHz: http://skydan.in.ua/PNTestSet/10MSRF.png 120MHz: http://skydan.in.ua/PNTestSet/120MSRF.png As we can see the RF+LO product will be attenuated more than 60dB in all cases. So, your comments? Would you like me to measure the RF voltage at the AD797 input in the real "test set"? However 50 ohms to ground at the LC filter output shouldn't be necessary. A somewhat larger value should suffice. I made some experiments trying to find the optimal value of the resistor at the LC filter output. The phase detector gain grew along with the resistor value, but so did the harmonics level. So I needed to apply more attenuation to the input signal to stay in the linear region. The resulting "test set" noise floor was almost identical for 50..300Ohm values (300Ohm was a bit better at offsets grater then 2kHz and a bit worse closer). Large values noticeably degraded the performance. I suppose the noise floor can be lowered only if better LNA will be used (currently the LNA noise dominates the PD noise), or if the levels on the mixer will be increased (this will require higher level mixer and/or new calibration routine if the mixer will not be in a linear region). 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] Oleg' s PN test Re: A new member & PN test set
Hi Magnus, Would not GNUradio be a good platform to encode the calibration stuff a little more gift-wrapped? I never used the GNUradio. Basically you can use any SA software/hardware which has the necessary capabilities. What spectrum-analyzer software do you use? (Just curious) It is an old SpectraLAB (which is now as far as I know SpectraPLUS). I also tried DL4YHF Spectrum Lab - it works, but lacks of logarithmic frequency scale (or I just did not find how to enable it). I think, from time to time, about writing specialized software with some special features, but there are always more important things to do :). 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] Oleg' s PN test Re: A new member & PN test set
Hi, Bruce, Thank you for the comments and useful link. Probably you did not understand the goal and positioning of this "project" and I did not tell the history of how it was build :) So, the solely goal of making this "test set" was to assist with the design of the synthesizer unit for my HF transceiver. The synthesizer PN goals are to archive PN better then -145..-150dBc/Hz@1kHz offset and better then -150..-155dBc/Hz@5kHz and farther. So I do not need something perfect to measure parts of the synthesizer or the complete unit. Now some words how it was build. Several years ago I experimented with the voltage regulators and needed to measure their noise. So I made an AD797 LNA for my soundcard. Later I added the mixer which I used (along with the signal generator) as a selective meter or primitive spectrum analyzer. Several months ago I started to work at the synthesizer project, so I needed PN "test set". I found a board with two TL071 in suitable configuration in my "junk box" and after several minutes of soldering I had the PLL board :) Usually I am not a fan of such construction methods, but that time it solved problem quickly. 1) The chosen mixer isnt as low noise as the various Minicircuits phase detectors. I just used what I have. There are some very bad things here :( (it is way out of the list theme), so buying parts (especially ones not widely used) is not a simple task here. The Minicircuits parts are expensive and exotic here. 2) The 50 ohm load after the filter merely serves to halve the phase detector gain. The IF port is terminated by a 15nF capacitor at RF and LO frequencies and their harmonics. This produces a frequency dependent gain, however it will likely be relatively flat over the sound card bandwidth. I know it does not terminate mixer correctly, but it is simple and it works. I tried the termination suggested in the NIST papers (with 50Ohm RF termination and 1kOhm DC/AF one) with no success - the noise floor of the "test set" was higher. As for the gain flatness, I checked it - you can see the results of the quick test here http://skydan.in.ua/PNTestSet/Screen(432)-e.png (it was 60MHz LO + signal generator slowly tuned around 60MHz, the SA was set to peak and hold mode). It completely satisfies my needs. 3) Saturating both mixer ports increases the phase detector gain substantially and has the lowest noise In this case the simple and reliable calibration method I use will not work, cause the mixer output will not be sinusoidal anymore. Another problem is the signal levels - two good RF LNAs will be needed to amplify signals up to the necessary levels to saturate mixer. 4) Cascading the PLL circuitry with the preamp causes interaction between the Preamp gain settings and the PLL bandwidth. Driving the PLL circuit in parallel with the preamp input directly from the low pass filtered mixer output avoids this issue as well as your 0.1x amplifier in the PLL section. I see no reason to use 20dB preamp gain for measurements (the sound card noise will have too much influence with this setting), so it useful only for calibration or the other LNA use (not in PN test set). On the other hand if the PLL circuit connected to the LNA output we have minimal components/wires/traces/connections in the most sensitive part of the test set, so the chance to pick up some external noise is also minimized. I can add that other good and simple/cheap additions will be the integrator reset button, two buttons to move integrator in positive or negative direction manually (to speed up the initial lock in some cases, or shift the output voltage into the necessary EFC range), potentiometer for the manual VCO/VCXO frequency control (for the calibration) with the switch to close/open PLL. An OCXO like the 10811A has an EFC gain of around 0.1Hz/volt. The PLL bandwidth should ideally be less than 1/10 of the lowest offset frequency for which the PN is to be measured. If the system frequency response is measured then the PLL bandwidth can be a little higher albeit with a reduction is sensitivity and an increase in system PN at the low offset frequency end of the range. AS is the PN noise of this test set is far too high to measure the PN of state of the art OCXOs or indeed most modern OXCOs. Ohh... I am not a time nut (or maybe not a time nut YET ;). I did not try to make something "state of the art" - my goals were/are different (see earlier). As for the PLL BW of cause one should be aware what the BW is. In my measurements the PLL BW is less then 30Hz. I am not interested in PN closer then 1kHz, so no need for any additional correction of the results. Much more sophisticated system can be made - better ADC, better LNA, RF LNAs to push mixer in saturation, better software, two channels with cross correlation and etc. Or we can even use two high speed ADC and move more things into digital domain. But it can not be done in one evening a
Re: [time-nuts] Oleg' s PN test Re: A new member & PN test set
Hi, everybody! OK. Let's start. Here is the schematics of the "test set" http://skydan.in.ua/PNTestSet/PN%20Test%20set.pdf . It consists of three small boards: 1. Mixer board - a simple mixer (500MHz ADE-1+) with 200kHz pi-LPF at the mixer output. 2. LNA board - a non-inverting low noise AF amplifier based on AD797 with switchable 20/40dB gain. 3. PLL board - contains two TL071 OP amps. One is inverting amplifier, the other is PLL integrator. The R4,R8,R2,R7,C8 sets the PLL parameters - gain, passband and damping factor. Loop parameters are also dependent of signal levels and VCO tuning sensitivity. So you may need to correct them if your setup differs from mine - VCXO's I use have tuning sensitivity approx 100Hz/V and I set RF level at mixer near 0dBm with LO level near +7dBm. If you want to build universal test set you will need to use some switchs to allow setting different loop parameters (I just use my soldering iron and change parts if needed :) ). The power supply is a simple design based on 7812/7912 regulators. I use the E-MU 0202 USB external sound card and laptop PC as the AF spectrum analyzer. You will also need some cables. Different fixed attenuators or switchable one will be also helpful. I also have several homemade low noise VCXOs for some frequencies (7MHz, 10MHz, 14.318MHz, 60MHz) which I use as the reference signal sources to make measurements at these frequencies. Another option is to test two identical oscillators (or other signal sources). Assuming that both signals will have identical phase noise characteristics we can correct the results by 3dB (or just add 3dB correction during calibration). The calibration and use is simple. 1. Set LNA gain to 20dB. 2. Set the FFT parameters - flattop window, small (2048..4096) points number and short averaging in SA software. 3. Connect reference signal to LO mixer port and signal you are going to test to RF mixer port through the attenuator. Do not close the PLL yet. 4. Set the beat level a bit less then the sound card full scale using the attenuator. Check the beat harmonics levels - they should be at least 30dB lower then the beat level (add more attenuation if harmonics are higher). 5. Now set the spectrum analyzer calibration so that beat level is at -27dB if you measure against low noise reference VXCO, or -30dB if you use two identical oscillators. 6. Switch the LNA to 40dB gain. 7. Set SA software to Blackman window, 131072points/96kHz SR/necessary averaging, close PLL, wait for the lock, measure the phase noise. Why I am calibrating to -27/-30dB: 20dB because the LNA gain is 20dB less during the calibration (compared to measurement time) 1dB because of FFT parameters 96k/131072 = 0.73Hz * 1.73 (Blackman window) = 1.267Hz, 10 log10(1.267) = 1.03dB 6dB is the correction inherent to used calibration method additional 3dB needed in case of testing identical oscillators. Now some words about results. The noise floor of this test set depends of the signals levels, and with the optimal levels it is in -160..-170dBc/Hz range (depending of the offset from the carrier). It completely satisfies my needs, better results can be achieved with the higher level mixer and/or better LNA. I just used parts that I had :). Here http://skydan.in.ua/PNTestSet/Screen%20(420)-e.png is an example of the phase noise measurements results of my homemade low noise 60MHz VCXO (two identical units were measured). The results at the offsets greater then 1kHz should be corrected cause the oscillators noise is too close to test set noise (the real oscillator noise is a bit lower then the displayed one). The test set noise floor and calibration spectrum is also there. The boards also have other use. For example I was able to measure my home made 60MHz VCXO harmonic content http://skydan.in.ua/PNTestSet/Screen%20(414)-e.png using the mixer, LNA boards and signal generator. I have no spectrum analyzer so it is a big help to me :). Power supply noise can be investigated with the LNA board and sound card. Look at this screen http://skydan.in.ua/PNTestSet/Screen%20(431)-e.png to see how bad the LDO regulator noise can be and a great difference in noise with the simple transistor filter (sorry there are a lot of power line noise pickup - I needed just to quickly check the power supply noise, so did not pay a lot attention to minimize them). The low noise VCXOs with the combiner and attenuator can be used to measure IMD3 of the receiver. If you add the mixer, LNA and signal generator you can measure the IMD3 of the separate units (mixers, filters, amplifiers and etc.). The low noise VCXO can also be used to test reciprocal mixing DR of the receiver. Other useful combinations are possible. If you like I can post the photos of the boards. They a bit ugly :). Every time I use them I think about mounting them in personal metal boxes, but I always find something more important to do... Best wishes,
[time-nuts] A new member & PN test set
Hi list, I am in a process of making a low noise frequency synthesizer for the 1st LO for my new DSP HF transceiver (http://neon.skydan.in.ua). This list is not directly related to my project, but I found a lot of useful information in this list - thanks for all contributors! I see a discussion regarding "$40 phase noise test set". I have built one and already use it for several months. It is a great help in design process (I am not "blind" anymore :) ). If somebody is interested I can share all the information about it. Best wishes! 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.
