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
Please send your suggestions feedback regarding this approach.
-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 <[email protected]>
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:
Hi Marcus,
Yes its true I couldn' t make much progress on this. Not able to find time as
I have a full time job. If I remember correctly, you mentioned that no-one has
implemented audio control loop within GNU Radio. And you were suggesting to
write it for ALSA and not with JACK.
May I know why not with JACK ? If I need to make it with JACK, GNU radio should
run as a client and output to JACK input port and another client which does
the audio control loop and send the output for playback. May be its not
required, if we can make a sink block with ALSA and implement the audio
control loop.
Here, I need your inputs. Can you please state the requirements. How it has to
be in GNU radio chain etc.
-ben
________________________________
From: USRP-users
<[email protected]><mailto:[email protected]>
on behalf of Marcus Müller via USRP-users
<[email protected]><mailto:[email protected]>
Sent: Tuesday, September 19, 2017 2:10 AM
To: [email protected]<mailto:[email protected]>; GNURadio
Discussion List
Subject: Re: [USRP-users] Audio Control loop testing
Hi Ben,
that's the old multi-clock problem we've been talking about multiple times –
it's hard to even define what the "correct" clock is, so you usually just
settle on recovering the transmitter clock and, if you were doing this in
hardware, would derive the audio DAC's clock from that.
In a software receiver, you need to estimate the offset of the audio DAC clock
from the sender's audio clock. That's hard to do properly, because these clock
offsets might be to fine to do it with general purpose PC CPU software. But
we've talked about all that before on the Discuss-gnuradio list!
As a way around that, you might use the same clock to derive the RF receiver's
sampling clock and the audio DAC's sampling clock. You then get a direct
relation between RF sampling and audio playback, for example "every 1 million
RF samples, I need to produce one audio sample". Fons and I really tried to
explain that in about 20 emails on discuss-gnuradio. So, I think we've covered
the stage of "any suggestions on this would be helpful" pretty well. It is a
hard problem, and there's a solid chance you can't solve it for all use cases
in software. There's also a solid chance you might be able to solve it for a
specific use case, but that would require you to become an expert on multi-rate
processing and clock matching, and frankly, you're not showing much progress at
that over last 10 months.
Best regards,
Marcus
On 09/16/2017 05:38 AM, Benny Alexandar via USRP-users wrote:
Hi,
I want to create an artificial audio drift in transmitter side and test it
using my audio control loop in receiver. This is what I'm planning.
Take an audio wav file which is sampled at 12 kHz. Re sample it such that the
sample rate is now having a drift of 100 ppm, ie with sample frequencies with
an error up to 12000*100e-6 is 1.2Hz in case of 12kHz sample frequency. Now
transmit this audio file using Gnu radio and USRP.
Receiver does the channel decoding and audio decoding.
So in this most extreme case the receiver drifts with more than one sample per
second, so after an hour it is drifted by 1.2*3600 = 4320 samples
If the receiver doesn't have an audio control loop then it will go into under
run. By enabling the audio control loop i can check the drift compensation.
Any suggestions on this method of testing.
-ben
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
