Let me try to understand this:
If you want to learn more, please visit our website interwiser.
1. You are using a 3rd party board that has the LMK
2. You are not sure what the settings are for this board for the LMK
3. If you knew the settings for the LMK, then you could use TICSPRO, but provider of the board (Real Digital), is not giving you this information.
With TICSPRO, you can export and import hex registers to other tools and this does not require you to have TICSPRO hooked up to the board. If TICSPRO is hooked up to the board, you can also read back the register states.
Or if you are asking for a configuration file based on the frequencies in the above diagram, we can provide that. However, to do this we need:
With your frequencies, I think you want the VCO to be .12. You could use the 160 MHz OSCin value, but this will lead to a very low phase detector frequency, which will work, but yield not very good perforamnce. It would perform much better with a differetn OSCin frequency like 122.88, but this is a hardware change.
Regards,
Dean
Regards,
Dean
Hi Danilo,
first of all, although the board was not design by our customer, I have doubt to the block diagram.
7.68MHz clocks have to be generated by the SYSREF block of LMK, as the clock divider is not big enough to support 7.68MHz. This is fine as long as the SYSREF block is configured as Continuous SYSREF output.
OUT4 and OUT1 are used as the SYNC signal to LMX, SYNC signal is a single pulse so it also have to be generated by the SYSREF block of LMK. However, in this case, the SYSREF block needs to be configured as Pulser mode.
That means, OUT3 and OUT9 will be a pulse instead of continuous clock when we attempt to synchronize the LMX devices.
Back to the LMK configuration, here is the configuration.
The 10MHz clock needs to be square wave, otherwise PLL1 may not lock. Use a square wave clock and set the input type to MOS.
Use the register next to PLL1 R Dividers to select CLKin1 or CLKin0.
Configure SYSREF to Continuous clock mode.
example output configuration, you may need to select the correct output format based on the board design.
here is the tcs file.
.lmk.tcs
Hi Danilo,
To add to what Noel said, in order to achieve phase synchronization between the input and output signals, you will have to put the device into zero-delay mode. I have attached a tcs file that does that, you will just need to update all of the outputs as you see fit. However, the phase noise performance will be suboptimal due to the numbers that the configuration will have to support - as Dean mentioned, it would be better if the VCXO frequency were 122.88 MHz.
lmk_rfsoc.tcs
Furthermore, in order to achieve the deterministic phase relationship between the input and output, you will need to generate a SYNC event. Section 9.7.3.10 provides an overview of how to generate one. The SYNC event results in all of the output dividers being phase aligned, and you will have achieved your necessary clock tree and input output relationships.
Thanks,
Michael
Hi Noel and Michael,
Thank you for your help. We have 3 more questions regarding this. I modified the zero-delay rfsoc file to match with our required clock output values and also enabled continuous SYNC for deterministic phase relationship. Here is how it looks right now.
We have a few more questions.
1- The first .tcs file you provided has a different internal VCO clock compared to the zerodelay .tcs file. (MHz / MHz). As long as the output clocks have the right frequency, does the internal VCO clock's frequency matter?
2- I modified SYNC/SYSREF to be in continuous SYSREF mode referencing from the section you mentioned, I think this mode should continuously align the phases. Also, the selected clock input for PLL1 should be CLK0 since that's where the signal generator's 10MHz will be connected. Are these right assumptions?
3- PLL1 and PLL2 are both locked in this configuration. Before continuing to test this .tcs file with our RFSoC4x2 board and signal generator. Is it possible for you to check/verify the accuracy? I attached .txt file for raw register values. Real Digital doesn't reply back to our emails. We want to make sure to have the correct configuration.
R0 (INIT) 0x R0 0x R2 0x R3 0x R4 0xD0 R5 0xB R6 0x R12 0x000C51 R13 0x000D04 R256 0xC R257 0x R258 0x R259 0x R260 0x R261 0x R262 0xF0 R263 0x R264 0xC R265 0x R266 0x010A55 R267 0x010B00 R268 0x010C22 R269 0x010D00 R270 0x010EF0 R271 0x010F10 R272 0xC R273 0x R274 0x R275 0x R276 0x R277 0x R278 0xF1 R279 0x R280 0x R281 0x R282 0x011A55 R283 0x011B00 R284 0x011C02 R285 0x011D00 R286 0x011EF1 R287 0x011F33 R288 0x R289 0x R290 0x R291 0x R292 0x R293 0x R294 0xF0 R295 0x R296 0xC R297 0x R298 0x012A55 R299 0x012B00 R300 0x012C02 R301 0x012D00 R302 0x012EF9 R303 0x012F00 R304 0xC R305 0x R306 0x R307 0x R308 0x R309 0x R310 0xF9 R311 0x R312 0x R313 0x R314 0x013A01 R315 0x013B80 R316 0x013C00 R317 0x013D08 R318 0x013E03 R319 0x013F11 R320 0x R321 0x R322 0x R323 0x R324 0xF R325 0xF R326 0xB R327 0xBA R328 0x R329 0x R330 0x014A02 R331 0x014B16 R332 0x014C00 R333 0x014D00 R334 0x014EC0 R335 0x014F7F R336 0x R337 0x R338 0x R339 0x R340 0xA R341 0x R342 0x R343 0x R344 0x R345 0x R346 0x015AA0 R347 0x015BD4 R348 0x015C20 R349 0x015D00 R350 0x015E00 R351 0x015F0B R352 0x R353 0xD0 R354 0x R355 0x R356 0x R357 0x R369 0xAA R370 0x R380 0x017C15 R381 0x017D33 R358 0x R359 0x R360 0x R361 0x R362 0x016A20 R363 0x016B00 R364 0x016C00 R365 0x016D00 R366 0x016E13 R371 0x R386 0x R387 0x R388 0x R389 0x R392 0x R393 0x R394 0x018A00 R395 0x018B00 R 0x1FFD00 R 0x1FFE00 R 0x1FFF53
Regards,
Danilo
Hi Danilo,
1. Preferably, you would use .6 MHz as your VCO frequency, as this will require a lower N divider value, which will reduce the phase noise.
2. Continuous SYSREF (while the correct SYSREF configuration)will not automatically align the phases, you must perform a SYNC event to achieve that. Also, yes, you should select CLKin0 as the driver of PLL1 if that is the input for the 10 MHz signal.
3. I cannot test your exact configuration on my board, as our evaluation boards come with 122.88 MHz VCXOs attached. However, I can confirm that both of your PLLs lock. I downloaded your configuration and tested it (albeit with different numbers for the first PLL, but with numbers that have the exact relationship as in your configuration) and found that both PLLs will lock.
I have attached the final configuration for good measure. Hope this helps.
rfsoc_lmk.tcs
Thanks,
Michael
There are two main ways to use the TICC for this kind of timing: (a) as
a traditional time interval counter with one DUT and one reference PPS
input plus a 10 MHz clock input, or (b) as a timestamping counter with
one (or two) PPS input, and a 10 MHz clock that also acts as the reference.
In case (a) you measure the (changing) interval between the two PPS
sources, and the 10 MHz clock is used as a transfer standard -- its
performance does not need to be anything special because you are using
it to measure such short time periods that the clock noise is irrelevant
(within reason). You analyze the changes in time interval over time to
determine frequency offset and stability.
In case (b) you measure a series of timestamps from one PPS source and
compare the second-to-second variations of the PPS source compared to
the 10 MHz clock. In that case, the clock is important. The
timestamps might look like this (lots of decimal places removed for
simplicity):
5.000 103
6.000 054
7.000 005
7.999 953
8.999 902
To extract phase data from this, you subtract the prior timestamp from
the present one, and then subtract the nominal period to get the
relative phase of the PPS compared to the 10 MHz clock, and analyze how
that varies over time. [ In this case, the TICC can measure timestamps
from each of its two channels independently, so you can compare two
oscillators against a common reference, if you want. ]
Case (a) is the traditional method and works just fine if you have two
PPS sources; the 10 MHz source doesn't need to be anything too fancy.
Case (b) is more convenient if you already have a 10 MHz output from
your reference; it avoids a divider. With the TICC, case (a) also gives
you a two channel measurement system instead of just one. In theory you
can argue that the timestamp method might have slightly better
performance than time interval, but in practice it's very hard to see
the difference.
To completely avoid that I wanted to use a TDC solution. Hence I thought of asking you all!
From what I understand going through Thomas's (and John's) and please correct me if I am wrong, I would be using our stable OCXO clock to run the TICC and then feed that same signal(10 MHz) into one of the input signal ports. In that case, would I also need to square the sine wave output of my OCXO? for that purpose would an LTC (with a CMOS logic output) be useful?
And do I just insert the 1 PPS from the GPS into the other signal port of the TICC? Won't there be an issue as I am trying to measure two signals with different frequencies i.e 10MHz and 1 PPS? I guess I didn't quite understand that well.
Also, do you think overall the TICC would fit my case? Would I be able to measure the phase drift information well enough using this setup?
I would then just feed this phase drift information through my FPGA and simply store them in the disks.
Also, any input on the position tracking system would be also highly appreciated!
Thanks for your time and help!
Regards,
Mayukh
Mayukh Bagchi (He/Him), MSc
Graduate Student
Department of Physics, Engineering Physics, and Astronomy
:
[Queen's University Logo]https://www.queensu.ca/
If you are looking for more details, kindly visit RFSoC Signal Processing Boards.
From: Thomas Abbott
Sent: Tuesday, October 4, 2:16 AM
To: Mayukh Bagchi
Subject: Re: Compairing the phase drifts between two PPS signals
Hi Mayukh,
I've done this recently and can make a few suggestions.
But first - what's your real goal here?
If you're looking to get good data about the OCXO or the GPS and have a several thousand dollar budget, then you should just buy the necessary professional equipment. My previous company did this:
But if you're looking for the minimal set of equipment to do some basic time-nut experiments, (more like me now), then you can learn a lot by hooking up
I've used both the TDC Click demo board, which is fine but you have to deal with its quirks, and also Marek Dorsic's PicoPEThttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdorsic%2FPicoPET&data=05%7C01%7Cmayukh.bagchi%40queensu.ca%7Cb89cdbac409e49a92b4e08daa5d%7Cd61ecb3b38b142d582c4efbb925c%7C1%7C0%7C%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C%7C%7C%7C&sdata=%2B96GgMXvg%2BXc7m2M71EMXhP21g%2Ft2wdZjR9pUC2Rf%2FQ%3D&reserved=0 (see the list from a year ago) which is a raspberry pi pico modified to accept an external clock and used to timestamp the GPS PPS signals. You need some electronics common sense to avoid issues like spurious signal pickup (false PPS signals) and dropped clock pulses, and also coupling between channels leading to pulling of the TDC results. Breadboard construction is OK to get started but will drive you crazy when trying to get real data, it will b
e full of glitches when someone turns on a printer two offices away.
I recommend clocking the PicoPET (or the TICC) directly from the 10 MHz OCXO, not dividing it down to 1PPS and then capturing the timestamps of the 1PPS of the GPS. Otherwise the two PPSs drift apart until you have whole microseconds of difference, and then the accuracy of the TIC clock starts to matter too. Or worse, the pulses cross over and the TIC stops counting because Stop happens before Start.
If you use a TDC, I suggest squaring up the OCXO if it isn't already a square wave, and using it as the "stop" channel. Then you have a Stop signal every 100 ns, and it will count from the GPS pulse to the soonest available clock edge (within its limits), This way it's never counting too long, so its timebase doesn't matter too much. I got to this point when I realised the clock sine wave wasn't triggering the TDC reliably, and that I had bad coupling between channels, leading to very non-uniform distribution of time values. Hence the recommendation about soldering everything and using proper ground planes and metal boxes.
Finally you need to capture and use the TIM_TP messages from the GPS, telling you how far ahead/behind the true 1 second edge the next PPS will be.
I plotted everything in Timelab, after some manual repair of the files, glitch removal etc, in python. It's not difficult to learn, accepts all kinds of input formats and plots many files easily.
Hope this helps for starters, I'm happy to answer more questions off-list.
Regards, Thomas
Thomas Abbott
: +1 604 365
On Mon, 3 Oct at 13:43, Mayukh Bagchi via time-nuts <:> wrote:
Hello,
I am trying to compare the phase drifts between a 1PPS signal generated by a GPS receiver with a 1PPS from an OCXO( using a frequency divider to convert 10MHz to 1 PPS).
I was thinking of using a TDC like the texas instruments TDC boards.
Do any of you have an idea for doing this?
Let me know if you need more background on the kind of work I am trying to achieve.
Thanks,
Mayukh
Mayukh Bagchi (He/Him), MSc
Graduate Student
Department of Physics, Engineering Physics, and Astronomy
:
[Queen's University Logo]https://www.queensu.ca/
time-nuts mailing list -- :
To unsubscribe send an to :
time-nuts mailing list --
To unsubscribe send an to
Hey Thomas and Others,
Thanks for your input!
I could explain my background and goals a bit more in-depth.
So we here at my university are building a balloon-borne VLBI station that will observe a bright radio source at K-band simultaneously with a large ground-based radio dish. Our balloon will be flying 35-40kms in the stratosphere.
To do a correlation of the signals later on( and hence interferometry/VLBI) we would need to be able to track the position of our balloon to a fraction of the wavelength at which we are observing (which is 1.3cm). Our positional tracking requirements are down to a few millimeters. For such position tracking requirements, we are using a high-precision GPS unit with differential correctional services (ex: Hemisphere GNSS, etc). For the shorter timescales, we are using a Kalman filter to fuse accelerometer and gyroscope solutions.
Of course, a key aspect of doing interferometry would be to be able to timestamp our data very precisely. For that reason, we are using a pretty expensive RAKON OCXO(RK409) having an ADEV of about 6*10^-11.
Another important requirement will be to have excellent phase offset information for our own clocks. The plan over here is to be able to measure and record the phase drifts between our onboard OCXO with the GPS. Initially, I was planning to implement this in our FPGA board that we are already using for our IF signal processing (we are using the RFSoC). However, a lot of people quickly pointed out that this could be a problem as I would need to manually override the internal clocks of the RFSoC FPGA, and even then there might be jitters.
To completely avoid that I wanted to use a TDC solution. Hence I thought of asking you all!
From what I understand going through Thomas's (and John's) and please correct me if I am wrong, I would be using our stable OCXO clock to run the TICC and then feed that same signal(10 MHz) into one of the input signal ports. In that case, would I also need to square the sine wave output of my OCXO? for that purpose would an LTC (with a CMOS logic output) be useful?
And do I just insert the 1 PPS from the GPS into the other signal port of the TICC? Won't there be an issue as I am trying to measure two signals with different frequencies i.e 10MHz and 1 PPS? I guess I didn't quite understand that well.
Also, do you think overall the TICC would fit my case? Would I be able to measure the phase drift information well enough using this setup?
I would then just feed this phase drift information through my FPGA and simply store them in the disks.
Also, any input on the position tracking system would be also highly appreciated!
Thanks for your time and help!
Regards,
Mayukh
Mayukh Bagchi (He/Him), MSc
Graduate Student
Department of Physics, Engineering Physics, and Astronomy
:
[Queen's University Logo]https://www.queensu.ca/
From: Thomas Abbott
Sent: Tuesday, October 4, 2:16 AM
To: Mayukh Bagchi
Subject: Re: Compairing the phase drifts between two PPS signals
Hi Mayukh,
I've done this recently and can make a few suggestions.
But first - what's your real goal here?
If you're looking to get good data about the OCXO or the GPS and have a several thousand dollar budget, then you should just buy the necessary professional equipment. My previous company did this:
But if you're looking for the minimal set of equipment to do some basic time-nut experiments, (more like me now), then you can learn a lot by hooking up
I've used both the TDC Click demo board, which is fine but you have to deal with its quirks, and also Marek Dorsic's PicoPEThttps://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdorsic%2FPicoPET&data=05%7C01%7Cmayukh.bagchi%40queensu.ca%7Cb89cdbac409e49a92b4e08daa5d%7Cd61ecb3b38b142d582c4efbb925c%7C1%7C0%7C%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C%7C%7C%7C&sdata=%2B96GgMXvg%2BXc7m2M71EMXhP21g%2Ft2wdZjR9pUC2Rf%2FQ%3D&reserved=0 (see the list from a year ago) which is a raspberry pi pico modified to accept an external clock and used to timestamp the GPS PPS signals. You need some electronics common sense to avoid issues like spurious signal pickup (false PPS signals) and dropped clock pulses, and also coupling between channels leading to pulling of the TDC results. Breadboard construction is OK to get started but will drive you crazy when trying to get real data, it will b
e full of glitches when someone turns on a printer two offices away.
I recommend clocking the PicoPET (or the TICC) directly from the 10 MHz OCXO, not dividing it down to 1PPS and then capturing the timestamps of the 1PPS of the GPS. Otherwise the two PPSs drift apart until you have whole microseconds of difference, and then the accuracy of the TIC clock starts to matter too. Or worse, the pulses cross over and the TIC stops counting because Stop happens before Start.
If you use a TDC, I suggest squaring up the OCXO if it isn't already a square wave, and using it as the "stop" channel. Then you have a Stop signal every 100 ns, and it will count from the GPS pulse to the soonest available clock edge (within its limits), This way it's never counting too long, so its timebase doesn't matter too much. I got to this point when I realised the clock sine wave wasn't triggering the TDC reliably, and that I had bad coupling between channels, leading to very non-uniform distribution of time values. Hence the recommendation about soldering everything and using proper ground planes and metal boxes.
Finally you need to capture and use the TIM_TP messages from the GPS, telling you how far ahead/behind the true 1 second edge the next PPS will be.
I plotted everything in Timelab, after some manual repair of the files, glitch removal etc, in python. It's not difficult to learn, accepts all kinds of input formats and plots many files easily.
Hope this helps for starters, I'm happy to answer more questions off-list.
Regards, Thomas
Thomas Abbott
: +1 604 365
On Mon, 3 Oct at 13:43, Mayukh Bagchi via time-nuts <:> wrote:
Hello,
I am trying to compare the phase drifts between a 1PPS signal generated by a GPS receiver with a 1PPS from an OCXO( using a frequency divider to convert 10MHz to 1 PPS).
I was thinking of using a TDC like the texas instruments TDC boards.
Do any of you have an idea for doing this?
Let me know if you need more background on the kind of work I am trying to achieve.
Thanks,
Mayukh
Mayukh Bagchi (He/Him), MSc
Graduate Student
Department of Physics, Engineering Physics, and Astronomy
:
[Queen's University Logo]https://www.queensu.ca/
time-nuts mailing list -- :
To unsubscribe send an to :
time-nuts mailing list --
To unsubscribe send an to
If you want to learn more, please visit our website phased array surveillance radar manufacturer.