Replies: 3 comments
-
I remain suspicious of the benchmark, especially after successfully integrating the real time processing in GNU Radio at https://github.com/jmfriedt/gr-allan. For reference, https://github.com/jmfriedt/gr-allan/blob/main/python/allan/allantxt.py should provide a simple and compact example for accessing the results of the real time computation without the overhead of the full graphical display demonstrated at https://github.com/jmfriedt/gr-allan/blob/main/python/allan/allan.py Thank you for the excellent library. |
Beta Was this translation helpful? Give feedback.
-
The tests have a more realistic use-case, maybe they can be of help: I just created a short example as a github gist here: we are also using Ettus N210 and B200 sdrs as frequency counters, so testing out a realtime ADEV-display for gnuradio would be very interesting - please keep us updated on progress if/when you have time! Anders |
Beta Was this translation helpful? Give feedback.
-
I'll give the B210 a test on my own as well as phase detector, but the https://github.com/jmfriedt/gr-allan repository sounds quite functional now (GNU Radio 3.10) and ready to be fed with real phase samples rather than simulated datasets as was done so far. Edit: Thanks |
Beta Was this translation helpful? Give feedback.
-
May I inquire about the realtime processing API? I fail to identify how to recover the {tau,mdev} values after new samples have been pushed.
I am confused by the example
realtime_benchmark.py
withwhere the random data sequence seems to be overwritten by the decade definition. When trying to add calls to dev_rt.taus() I get realistic integration delays but calling dev_rt.devs() always returns an array of 0s with different length than taus.
Can enyone enlighten on the usage of the realtime API for recovering and displaying the ongoing Allan deviation calculation as new samples are pushed?
Thanks.
Beta Was this translation helpful? Give feedback.
All reactions