greatscottgadgets
Timed commands and clocks phase synchronization
This firmware extension provides the capabilities to perform timed commands and a precise phase synchronization of internal clocks (sampling, MCU, output). This extension was developed for a time transfer application described here. The documentation is here. The main features are:
- unix-like time scale, with a resolution of 5 ns
- RX/TX sampling synchronized with the time scale
- fine time scale/frequency adjust for synchronization with remote reference radio signals with a resolution of about 0.25 Hz @ 10 MHz
- no external hardware required
- host time tool for access to the time extension API.
Hi @fabriziop, this is very interesting indeed, we'll take a look.
The test failure on formatting should be fixable by running ./tools/reformat-source.sh, which will apply our preferred clang-format rules.
This is very impressive work! I look forward to trying this out!
I am currently finalizing the HackRF Pro design, so I'm checking to see if there is anything I can do to make this solution work more easily on HackRF Pro.
Did you consider adjusting the PLLA/PLLB configuration instead of the output multisynth for the MCU reference clock? PLLA or PLLB is the used to generate the 800 MHz VCO inside Si5351C that every output clock is derived from. If we were to adjust PLLA/PLLB, we could support all HackRF One revisions without a clock jumper. It would discipline all of the clocks, including CLKOUT, not just the MCU clock.
This is very impressive work! I look forward to trying this out!
Thanks for the appreciation.
I am currently finalizing the HackRF Pro design, so I'm checking to see if there is anything I can do to make this solution work more easily on HackRF Pro.
Did you consider adjusting the PLLA/PLLB configuration instead of the output multisynth for the MCU reference clock? PLLA or PLLB is the used to generate the 800 MHz VCO inside Si5351C that every output clock is derived from. If we were to adjust PLLA/PLLB, we could support all HackRF One revisions without a clock jumper. It would discipline all of the clocks, including CLKOUT, not just the MCU clock.
I developed the time commands on a R9 board, only later I discovered that all other versions have a quite different clock architecture. So I tried to adapt the first solution to other board versions. I also made an attempt to manipulate PPLA/PLLB in coordination with multisynth sections to have a finer step for frequency control, but I noticed a malfunction of my application that is very sensitive to tuning changes. So I preferred to keep the original solution that does not manipulate the 40 MHz for the tuner.
I developed the time commands on a R9 board, only later I discovered that all other versions have a quite different clock architecture. So I tried to adapt the first solution to other board versions. I also made an attempt to manipulate PPLA/PLLB in coordination with multisynth sections to have a finer step for frequency control, but I noticed a malfunction of my application that is very sensitive to tuning changes. So I preferred to keep the original solution that does not manipulate the 40 MHz for the tuner.
Yeah, it makes sense that changing the RF reference clocks and the sample clock could make the software more challenging. However, you are limiting the frequency adjustments to fairly small changes, so I suspect those challenges could be overcome. Also having those clocks on the client device more closely match the server's clock could in theory improve correlation.
To be clear, I'm just speculating about ways we could do things better in the future. I'm not opposed to merging the existing solution with output multisynth adjustment.
There is an error in the clock jumper diagram/photo. It shows a connection to P22 pin 12 instead of P20 pin 12.
To be clear, I'm just speculating about ways we could do things better in the future. I'm not opposed to merging the existing solution with output multisynth adjustment.
I agree that adjusting only PLLA/PLLB is a much cleaner design. I am thinking (tempted :) ) to do some tests with my application.
There is an error in the clock jumper diagram/photo. It shows a connection to P22 pin 12 instead of P20 pin 12.
The diagram and photo are correct. The text is wrong. The P22 pin12 is connected to MCU PF_4 pin120, programmed as GP_CLKIN.
The README.md changes need to go somewhere else.
Yes, this page is only the cover for my fork. It may be substituted by some kind of "entry point" in the original documentation.
On HackRF Pro, we may eventually prefer to migrate timing functions to gateware on the FPGA, but we think it is important to initially provide support for the existing, proven implementation using the microcontroller timer. With that in mind I have formulated the following plan:
- Connect P2_5 to CLKIN multiplexer. Configured as T3_MAT2, P2_5 can provide PPS output on the CLKIN SMA connector. P2_5 can also be configured as CTIN_2 or GPIO5[5] for other applications.
- Connect TRIGGER.IN through a 100 ohm resistor to PD_12. Configured as CTOUT_10, PD_12 can serve as Timer 3 match output 3. This eliminates the need for an external trigger jumper. TRIGGER.IN can also be multiplexed onto either CLKOUT or CLKIN SMA connectors, so it will be possible to monitor this signal externally or to use it simultaneously for PPS output and to trigger the FPGA.
- Connect TRIGGER.OUT through a 100 ohm resistor to P2_6. Configured as T3_CAP3, P2_6 can serve as PPS input when TRIGGER.OUT is multiplexed onto either CLKIN or CLKOUT SMA connector. FPGA control of TRIGGER.OUT would need to be disabled in gateware to use this as PPS input. P2_6 also provides alternative functions CTIN_7 and GPIO5[6].
- Move MCU_CLK (GP_CLKIN) from Si5351C CLK7 to CLK2. This enables fine control of the output multisynth used for the MCU reference clock with no clock jumper required.
- Move FPGA_CLK from CLK2 to CLK1, shared with SCT_CLK. SCT_CLK on CLK1 provides the sample clock (MS0) x2 to CTIN_6 in order to support Opera Cake's sample-synchronous time mode. (On HackRF One, the SGPIO input clock is used to clock SCT, but on HackRF Pro the SGPIO input clock is not synchronous with the sample clock.) FPGA_CLK is currently unused but is intended to provide the option to clock the FPGA at a multiple of the sample clock.
I believe that these changes will allow the HTime client implementation to be ported easily from HackRF One to HackRF Pro, making it possible to use the solution without jumpers and without having to open the enclosure. Furthermore, it should be possible to implement the HTime server with HackRF Pro's new PPS input.
These changes are relatively minor which is good because right now I am finishing up the final hardware revision for production. :)
These changes are relatively minor which is good because right now I am finishing up the final hardware revision for production. :)
Wow! Hackrf pro becomes a powerful time machine :)
I was wondering how one could make the PPS output on the clkin connector compatible with the following configurations.
The hackrf is used as timing client/slave (it radio synchronizes and outputs a 10 MHz and PPS synchronized with the master SDR). In this configuration, one may wish to have an external programmable clock with higher stability and even finer adjusting to feed the hackrf clkin.
As alternative, this clock may come from an advanced version of the internal TCXO module, pluggable on P22 pin 1-12, with a fine frequency adjust controlled via the I2C lines (P22 pin 5-6).
The hackrf is used as timing client/slave (it radio synchronizes and outputs a 10 MHz and PPS synchronized with the master SDR). In this configuration, one may wish to have an external programmable clock with higher stability and even finer adjusting to feed the hackrf clkin.
In this scenario you could use both CLKIN and CLKOUT (configured for default functions) and provide the PPS output on a pin header (as is required on HackRF One). For CLKOUT to be disciplined, we would need to adjust PLLA/PLLB or we would need to adjust the output multisynths of both MCU_CLK and CLKOUT (CLK3).
As alternative, this clock may come from an advanced version of the internal TCXO module, pluggable on P22 pin 1-12, with a fine frequency adjust controlled via the I2C lines (P22 pin 5-6).
Yes, that should work. P22 on HackRF Pro is largely the same as P22 on HackRF One. It would also be possible to implement analog control using a DAC pin on P20 instead of I2C.
CLKIN on P22 connects directly to the CLKIN SMA connector (the multiplexer is adjacent to the clock generator at the other end of P22), so the CLKIN SMA connector would be unused in this scenario (or it could be used to externally monitor CLKIN). You would need to use a pin header for PPS output.
I was wondering how one could make the PPS output on the clkin connector compatible with the following configurations.
Another option, and this would allow your scenario with the TCXO add-on to work without any use of pin headers, would be to have two separate clock input signals, one on the CLKIN SMA connector and one on P22. I would add a new analog switch that connects the clock generator's input to either of those clock input signals.
The TCXO (really a VCTXO or something fancier) add-on would provide an input clock on P22 pin 2. This would be selected by the new analog switch as input to the clock generator. The CLKIN SMA connector would be connected through its multiplexer to P2_5 for PPS output. The CLKOUT SMA connector would be used for 10 MHz output.
This new clock input selector switch would also make it possible for anyone with an internal clock add-on (which are popular and in some cases are integrated into PortaPacks) to use the CLKIN SMA connector for clock input or other purposes even if they are not using HTime. This is something we previously considered.
I think I will do this. I also think I should rename the CLKIN and CLKOUT SMA connectors to something more generic like P1 and P2.
By the way, HackRF Pro has an internal TCXO instead of the basic XO on HackRF One. Existing TCXO add-ons are typically no better than the internal TCXO, but a newer add-on (perhaps with VCOCXO) could be useful.
Just one more thought on the TCXO of the Hackrf Pro. What about installing a VCTCXO controlled by a PWM output of the MCU. With a 5 ppm VCTCXO and 14 bit PWM one can reach 1 ppb control step. Currently, at best (control on PLLA/B and CLKIN active) one can reach 12 ppb.
The XTAL of Hackrf One is 25 MHz. If this XO would be 10 MHz (same freq of CLKIN), changing from internal to external ref will not change the minimum control step (12ppb). Otherwise it will grow to 30 ppb with the internal ref. Obviously, with a higher PLLA/B multiplication factor, the phase noise gets worse.
Just one more thought on the TCXO of the Hackrf Pro. What about installing a VCTCXO controlled by a PWM output of the MCU.
It is a good idea, but there are complications. We have already purchased the TCXO for production. We don't have time to prototype a PWM or DAC solution. The XTAL input on Si5351C requires 25-27 MHz. If we want to use 10 MHz, we would have to multiplex it onto CLKIN and build a separate solution for clock detection (as we did on HackRF One r9). Replacement of the main oscillator is a risky change that would need to be prototyped.
Mostly it is just too late. The changes I made over the weekend are done, and that was the last chance to add a new feature. Those changes were more extensive than I had planned for this revision, but I thought it was worth squeezing them in. They were relatively low risk changes, partly because we had already anticipated similar applications. Other than passives, I only had to add one analog switch, and it was a part already used elsewhere on the board.
I am interested in designing a more sophisticated oscillator add-on, however!
Is the complete software for the time transfer application described in the paper available somewhere? It is difficult to justify merging and supporting these features without any application that uses them.