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,
Marcus
On 09/26/2017 07:26 PM, Benny Alexandar
wrote:
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 <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:
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
<address@hidden> on
behalf of Marcus Müller via USRP-users
<address@hidden>
Sent: Tuesday, September 19, 2017 2:10 AM
To:
address@hidden; 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
address@hidden
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|