|
From: | Benny Alexandar |
Subject: | Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing |
Date: | Tue, 3 Oct 2017 17:48:53 +0000 |
By using the PC clock, and calling set time now with
the current PC time before scheduling streaming. This will make the USRP tick counter roughly match the PC clock. usrp_source->set_time_now(uhd::time_spec_t(secs, micros, long(1e6)); Then use the Jack audio clock and maps this audio clock to system one .
At the input side USRP decides the input rate, slave the audio to this rate.
-ben
From: Benny Alexandar
Sent: Friday, September 29, 2017 11:59 PM To: Marcus Müller; GNURadio Discussion List Subject: Re: [USRP-users] Audio Control loop testing
>> you don't get the sound card clock anywhere in software. If you did, there would >> be no problem
Jack uses audio
clock and maps this audio clock to system one
with the use of DLL (delay locked loop).
-ben
From: Benny Alexandar
Sent: Wednesday, September 27, 2017 10:45 PM To: Marcus Müller; GNURadio Discussion List Subject: Re: [USRP-users] Audio Control loop testing >>Could you maybe elaborate how you're planning to solve all a),b),c) instead of asking for new feedback?
----------------------------------------------------------------
And as also said earlier, I don't believe very much that it will work that easily, since the CPU clock is a) worse than the typical SDR and sound card clocks, b) has different resolutions, c) and needs to still be sufficiently interpolatable for the jittery, variable-workload-length that GNU Radio has. The point c) is what's different for Jack internally, because that can work on fixed-length buffers.
This is a comment that you've gotten from me (and by the way, Fons, too) multiple times now. Could you maybe elaborate how you're planning to solve all a),b),c) instead of asking for new feedback?
From: Benny Alexandar
Sent: Wednesday, September 27, 2017 6:50 AM To: Marcus Müller; GNURadio Discussion List Subject: Re: [USRP-users] Audio Control loop testing Hi Marcus,
As said earlier there is no true clock as such. We need to rely on CPU clock and measure the deviation. The reference clock is the transmitter time duration between two symbols which is a preset value. Do you have any suggestions for a *better reference clock*
--------------------------------------------------------------
Hi Benny, you're, again, missing the core problem: it's hard to measure the time deviation between two symbols without a better reference clock. And you don't have that. And thus, we're back at the start of all our email chain. Best regards, MarcusFrom: Benny Alexandar
Sent: Tuesday, September 26, 2017 10:56 PM To: Marcus Müller; GNURadio Discussion List Subject: Re: [USRP-users] Audio Control loop testing
Hello,
Now the timing of input side is after detecting the start of symbol. Every symbol will be timestamped and measure the time deviation between two symbols.
d = t1 - t0,
where t0 - time of arrival of symbol (n)
t1 - time of arrival of symbol (n+1)
d - time deviation between two symbols.
D - time duration between two symbols according to digital radio standards, then error = ( D / d ) - 1
-ben
From: Benny Alexandar
Sent: Friday, September 22, 2017 10:26 PM To: Marcus Müller; GNURadio Discussion List Subject: Re: [USRP-users] Audio Control loop testing
Hi Marcus,
Please find the attached figure on how the audio control loop will be placed in
Gnu Radio chain. In the figure the first block is the RF IQ acquisition block which samples the RF samples and put a timestamp. It is then passed on to channel and audio decoder and finally reaches the audio sink. Audio sink does the audio playback on fragments
of audio.
The audio control loop module has two inputs and one output. The inputs are for sending the timestamp of write side and read side. In this case write side is RF capture and read is from audio sink. Note these two time stamps are coming from different clock,
the RF capture uses PC CPU clock where as the audio sink has sound card clock. The output of audio control loop is used to control the re sampler which sits in between audio decoder and audio sink.More details on how the audio control loop will be send soon.
Please send your feedback regarding this approach.
-ben
From: Marcus Müller <address@hidden>
Sent: Tuesday, September 19, 2017 10:47 PM To: Benny Alexandar; GNURadio Discussion List Subject: Re: [USRP-users] Audio Control loop testing Hi Ben,
May I know why not with JACK ? From the very same email you're referring to:
(not much sense writing it for the Jack sink, if Jack can already do it internally)Also, Here, I need your inputs.I spent around 5 hrs on input on this topic already. I don't feel like you need more input, it feels more like you haven't had the chance yet to understand all the input that there is on the GNU Radio mailing list. We should also not be having this discussion on usrp-users, as your approach doesn't involve USRPs directly! Can you please state the requirements. How it has to be in GNU radio chain etc. Please re-read my previous email. I explicitly say I'm not even convinced this will reliably work in software. GNU Radio is software. What about you just start by trying to implement a control loop, and read as much on theory of discrete-time control systems as you'll need for this? I'm afraid I can't take that burden off your shoulder if you want to implement a control loop. It is hard stuff. Best regards, Marcus On 09/19/2017 10:10 AM, Benny Alexandar wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |