Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Long term phase continuity for LOs #1322

Open
KVasya opened this issue May 11, 2023 · 1 comment
Open

Long term phase continuity for LOs #1322

KVasya opened this issue May 11, 2023 · 1 comment
Labels
enhancement potential new feature

Comments

@KVasya
Copy link

KVasya commented May 11, 2023

What feature would you like to see and why?

As I doubt my request is technically plausible the post is mainly a question and possibly a feature request.

The problem I encountered with is as follows. I've got 2 HackRFOnes, synchronized in clocks, their reception being triggered by external source. I use standart utitility 'hackrf_transfer' to get signals from 2 boards. The boards are fed the same signal and show some random phase difference between signals, which is tolerable.
What torments me is that this phase difference varies between subsequent data receptions (i.e. 2 subsequent 'hackrf_transfer' launches).

I suspect the reason is that various LOs are turned off when hackrf_transfer finishes (thanks to energy saving improvements), and than start from random phases anew.
Could the LOs somehow please stay on? I think it could be a solution to the problem, because phase difference remains intact for very long times. Also, as I see from this diagram
https://github.com/greatscottgadgets/hackrf/assets/19487262/a163d1dc-4ed7-4563-b8ac-fbde058da146,
all LOs are derived from same clock source, so they should stay synchronized.

May be it could already be done via some hackrf_debug writing of 'power saving' registers?

@KVasya KVasya added the enhancement potential new feature label May 11, 2023
@KVasya KVasya changed the title Long term stability of LOs Long term phase continuity for LOs May 11, 2023
@martinling
Copy link
Member

Interesting idea. Perhaps the approach in #1314 could be extended to control whether the LOs should be switched off when the transceiver is in OFF mode.

The other approach, which you could use with current firmware, would be to write some form of server that keeps the two HackRFs in RX mode continuously, and a client program which would function like hackrf_transfer, but make requests to the already-running server program in order to maintain the operating state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement potential new feature
Projects
None yet
Development

No branches or pull requests

2 participants