I haven't tried it myself, but my guess is that hackrf_transfer is the
wrong tool for this - most of the time is probably due to the startup of
the HackRF, which happens each time you invoke hackrf_transfer, instead of
just due to tuning.
You should write an app (maybe just a simple modification of
hackrf_transfer) that opens the device once and then tunes different
frequencies at fixed intervals, and I bet you'll find a much shorter
settling time on all subsequent tunings.
--Quentin
On Thu, 9 Oct 2014, Ibrahim Basaran wrote:
We are trying to sweep all ~ 6GHz with HackRF. In our tests we have seen that
it takes 2.5ms to 5ms to settle for a configuration.
Our test is simply run hackrf_transfer, record for a second, look at the data
in time domain and note the point where it seems settled
visually.
My questions are :
1. Are our settling time values correct?
2. Is there any better way to test or has anybody done such tests?
3. Which part of the hardware causing this time? Our guess is the clock source.
4. Is there any way to make it faster?
İbrahim BAŞARAN
Senior Researcher / Uzman Araştırmacı
TÜBİTAK BİLGEM M070
41470 GEBZE KOCAELİ / TURKEY
[email protected]
T +90 262 648 1268
F +90 262 648 1100
www.bilgem.tubitak.gov.tr
Sorumluluk Reddi
_______________________________________________
HackRF-dev mailing list
[email protected]
https://pairlist9.pair.net/mailman/listinfo/hackrf-dev
