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 <marcus.muel...@ettus.com>
*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 <usrp-users-boun...@lists.ettus.com> on behalf of
Marcus Müller via USRP-users <usrp-us...@lists.ettus.com>
*Sent:* Tuesday, September 19, 2017 2:10 AM
*To:* usrp-us...@lists.ettus.com; 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
usrp-us...@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
