Re: [Discuss-gnuradio] compressing I/Q files

[Benny Alexandar]

 Yes, converting float 32bit to short16 is an option, compressing using 7zip or 
gzip won't give good compression .

From: Discuss-gnuradio  
on behalf of Kristoff 
Sent: Sunday, March 10, 2019 3:57 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] compressing I/Q files

Hi all,



Simple and short question:
What is the best way to compress a raw I/Q file? A generic
compression-tool like gzip, zip? Or are there better and specialised tools?


Is converting the data in the I/Q file from float to short an option?


Kristoff


___
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

Re: [Discuss-gnuradio] How to stop GRC flowgraph after a defined time

[Benny Alexandar]

Hi Priyanka,

GRC will generate python code for free when you create the flow graph. After 
that its like any python coding adding delay. timer etc.
Modify the python code for your need.

-ben

From: Discuss-gnuradio  
on behalf of Priyanka 
Sent: Tuesday, March 27, 2018 4:32 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] How to stop GRC flowgraph after a defined time

Hello,

I am very new to GNURadio and I have made a FM radio receiver in which I
am recording the data in a file sink.

But, I want to record the data for one millisecond(means i want to stop
the flow graph after 1 millisecond). How can I run the execution of the
flow graph for this specified time?

Any help would be appreciated. Thank you.

Priyanka


___
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

Re: [Discuss-gnuradio] [GSoC2018] Adding Passive radar and multiple device support to gr-radar toolbox

[Benny Alexandar]

Hi Suraj,

I would like to know for measuring the reference signal how do you determine 
the direction of transmitter ?  In case of WiFi which direction you set your 
antenna for making it as reference ?

-ben

From: Discuss-gnuradio  
on behalf of suraj hanchinal 
Sent: Sunday, March 25, 2018 7:36 PM
To: jmfriedt
Cc: mar...@gnuradio.org; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] [GSoC2018] Adding Passive radar and multiple 
device support to gr-radar toolbox

Hello everyone,
After reading the suggestions as well as feedback from Marcus Muller and Martin 
Braun, I have made the suggested changes as well as explained the algorithms in 
greater detail. Please read the updated proposal and provide feedback and 
suggestions.

Thanking you,

Regards,
Suraj Hanchinal

GSoC Proposal: 
https://github.com/surajhanchinal/GSoC_proposal/blob/master/My%20GSoC%20Proposal.pdf

On Sun, Mar 25, 2018, 2:18 PM suraj hanchinal 
> wrote:
Hello Jean-Michel Friedt,

Thank you for your valuable feedback. That is a very good insight since I 
overlooked the cross-ambiguity function and its calculation considering them 
trivial. I will definitely look into the papers that you mentioned and include 
them in my proposal.

Thank you,

Regards,
Suraj Hanchinal

On Sun, Mar 25, 2018 at 2:12 PM, jmfriedt 
> wrote:
> All in all, this is pretty ambitious, but exciting!
> How will you tackle the OFDM signal recovery? I think your reference
> [2] is really much to be completely done in one GSoC, so it would be
> totally OK to say you just picked a reduced approach. Still, if you
> want to do that in all its glory, that would be cool, too, but I'd ask
> Martin how much work he'd expect that to be, and if necessary, reserve
> more time for the algorithmic part alone. I'm also including Jean-
> Michel Friedt of low-cost passive radar fame[A], as I hope he might
> have a moment to read and comment on your proposal.

I am not sure I can provide useful comments on the proposal, whose
various iterations I have been reading as they were being updated. Real
time passive radar processing seems challenging to me, and I would
advise looking at alternatives to the brute force cross correlation of
the Doppler shifted signal. You might want to have a look at
https://www.researchgate.net/publication/279069212_Batches_algorithm_for_passive_radar_A_theoretical_analysis
and especially its Table I which lists computational complexity of
various algorithms. An updated version of the document cited by Marcus
is at http://jmfriedt.free.fr/dvbt_hardware.pdf (submitted for
publication but not yet accepted): beyond the improved batches
algorithm allowing for much faster computation, we also address using
multiple receivers in parallel, each tuned to different carrier
frequencies.

JM

--
JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
25000 Besancon, Fr Michaelance

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Timestamping baseband samples

[Benny Alexandar]

Hi Marcus,

If USRP crystal has a ppm of +-25ppm, then its  RF deviation, and
the baseband decoder detects this drift and correct it by resampling
till it gets the required number of samples.

So my question is this input side drift is corrected by baseband
synchronization, and this should not be seen at audio output
side. 25ppm drift is corrected and the time stamp will be
put after that.

For example if 10% interpolation is done on RF samples, then
the timestamp should be modified to add for 10 samples.

Is that the correct way to timestamp for audio packets ?

-ben



From: Marcus Müller <marcus.muel...@ettus.com>
Sent: Saturday, February 10, 2018 9:47 PM
To: Benny Alexandar; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Timestamping baseband samples

Hi ben,

the Ettus USRP series of devices (N2x0, B2xx, E3xx, X3xx, N3xx) have RX
sample time stamping that you can find as tags in your sample flow.

That means they can annotate a sample buffer with the device time of
the first contained sample. The device time can be set according to an
external standard, if helpful (e.g. a GPS clock).

You won't find anything surprising in there: The first received item
will have a tag containing the device time at which that sample was
received. From there on, you can use (sample number)/(sampling rate) to
calculate the device time corresponding to each packet. Since absolute
time doesn't matter to your application, you could just as well do
without that tag and simply count samples. With the timestamps, you
still count samples, and add the timestamp from the first sample.
There's no additional information that helps you solve the two-clock
problem to be gained here.

Best regards,
Marcus

On Sat, 2018-02-10 at 07:06 +, Benny Alexandar wrote:
> Hi All,
>
> In Broadcast receiver where the RF samples are received on AIR and
> channel decoder does the demodulation of digital radio symbols, and
> extracts the compressed audio data. This is then fed to an audio
> decoder to decode the audio. After decoding the uncompressed audio
> has to be played out.
> I would like to implement the jitter buffer, by having time stamps.
> So my question is where to do the timestamping, the timestamp put
> after audio decoding will be jittery because of variable audio
> content and compression effects. So the best place is to put at the
> RF input when baseband samples are buffered using DMA, this then can
> be corrected for clock recovery and use it while sending out audio.
>
>
> Any suggestions on this approach.
>
> -ben
>
> ___
> 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

[Discuss-gnuradio] Timestamping baseband samples

[Benny Alexandar]

Hi All,

In Broadcast receiver where the RF samples are received on AIR and channel 
decoder does the demodulation of digital radio symbols, and extracts the 
compressed audio data. This is then fed to an audio decoder to decode the 
audio. After decoding the uncompressed audio has to be played out.

I would like to implement the jitter buffer, by having time stamps. So my 
question is where to do the timestamping, the timestamp put after audio 
decoding will be jittery because of variable audio content and compression 
effects. So the best place is to put at the RF input when baseband samples are 
buffered using DMA, this then can be corrected for clock recovery and use it 
while sending out audio.


Any suggestions on this approach.


-ben

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Hi all

[Benny Alexandar]

Hi Nirmala,

Can you be more specific on what simulations you are planning to do with GNU 
radio ?
There are plenty of tutorials available in net.

-ben

From: Discuss-gnuradio  
on behalf of Nirmala Soundararajan 
Sent: Saturday, November 4, 2017 2:50 AM
To: Discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Hi all

I am new to gnu radio although I know some elementary stuff.. But first want to 
try only simulation without actually using the hardware. Request help

thanks

Nirmala
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Fw: Channel model & frequency offset

[Benny Alexandar]

Hi Atif,


For frequency offset , a signal with (cos ((w + delta)t) + j sin((w + 
delta)t)), where delta is the offset compared to original signal.
This can be achieved by creating a grc as attached. In this grc the signal 
source (Tx) sample rate is fixed and in the sink (Rx) which is fft, the sample 
rate is slightly offset to create the frequency offset.
You can add a slider for sample rate offset, and move to see the effect.

Similarly If you want to create a time offset, which is (cos (w + delta(t))t) + 
j sin(w + delta (t))t), where delta (t) is a monotonous function over t: in 
case delta (t) is positive, the frequency offset will increase over time.
-ben

-

I am trying to analyze channel model effect between am transmitter and receiver 
but whenever i change frequency offset using slider i can't be able to see the 
frequency change. In both transmitter and receiver are at the same frequency .
Best,
ATIF JAVED


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Channel model & frequency offset

[Benny Alexandar]

From: Benny Alexandar
Sent: Friday, October 27, 2017 6:38 AM
To: discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] Channel model & frequency offset

Hi Atif,


For frequency offset , a signal with (cos ((w + delta)t) + j sin((w + 
delta)t)), where delta is the offset compared to original signal.
This can be achieved by creating a grc as attached. In this grc the signal 
source (Tx) sample rate is fixed and in the sink (Rx) which is fft, the sample 
rate is slightly offset to create the frequency offset.
You can add a slider for sample rate offset, and move to see the effect.

Similarly If you want to create a time offset, which is (cos (w + delta(t))t) + 
j sin(w + delta (t))t), where delta (t) is a monotonous function over t: in 
case delta (t) is positive, the frequency offset will increase over time.
-ben

-

I am trying to analyze channel model effect between am transmitter and receiver 
but whenever i change frequency offset using slider i can't be able to see the 
frequency change. In both transmitter and receiver are at the same frequency .
Best,
ATIF JAVED


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSOC 2018] Ideas please!

[Benny Alexandar]

Please consider China Digital Radio standard (CDR)

-ben

From: Benny Alexandar
Sent: Saturday, October 14, 2017 8:26 PM
To: discuss-gnuradio@gnu.org; felix.wun...@kit.edu
Subject: RE: [Discuss-gnuradio] [GSOC 2018] Ideas please!

Hi Felix,

I have couple of Ides for GSOC

1. DRM digital radio receiver on GNU Radio.  We have only DRM transmitter but 
no receivers are available.
DRM is mainly used in Europe, India and in South America. xHE-AAC codec has 
recently made license free
this will be good to add.

2. Audio Control block:
This is to synchronize the audio clock of digital radio receiver with 
transmitter clock. Currently there exits no blocks in GNU radio to
fully support it.


-ben


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSOC 2018] Ideas please!

[Benny Alexandar]

Hi Felix,

I have couple of Ides for GSOC

1. DRM digital radio receiver on GNU Radio.  We have only DRM transmitter but 
no receivers are available.
DRM is mainly used in Europe, India and in South America. xHE-AAC codec has 
recently made license free
this will be good to add.

2. Audio Control block:
This is to synchronize the audio clock of digital radio receiver with 
transmitter clock. Currently there exits no blocks in GNU radio to
fully support it.


-ben


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

>>No. I'll stop contributing to this discussion now. The average sound card has 
>>a 25ppm clock accuracy, >>according to design specs of Texas Instrument audio 
>>ADC/DAC ICs. So, that's way, way better than >>your CPU clock, and even more 
>>better than your CPU clock sampled through a system call in a 
>>>>non->>realtime userland application.


>>I wish you the best with your application! I'm clearly not helping you, 
>>because I feel that you're still >>repeating things that I've already tried 
>>to explain

Actually I'm new to this field and learning new things in the past 10 months or 
so. My apologies for repeating things.

I'm still wondering how JACK server  and zita-ajbridge kind of audio 
applications are able to address this issue. Since they are addressing the same 
issues for audio streaming through network, why can't it be reused here ?

-ben

From: Benny Alexandar
Sent: Wednesday, October 4, 2017 10:39 PM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing

>>Yeah. But that doesn't help at all, since clock recovery of any digital 
>>receiver will give you samples resampled to the transmitter's clock...
>>Anyway, notice how you say "roughly". Now, compare that "roughness" to the 
>>"roughly the same" transmitter and receiver audio clock.
>>You're at least in the same order of magnitude here, and my point is that by 
>>introducing yet another clock into this
>>(the abyssimal bad PC clock), you're making things way worse than they need 
>>be, and atop of that, unnecessarily complicated.


Actually there exist a resampler at the input as well. After clock recovery the 
base band samples are synchronized with transmitter.  Then the symbols which 
make the transmission frames are timestamped. At this point we are in sync with 
transmitter.

The conversion  error of clocks  should be negligible compared to audio  sample 
rate as we are dealing with
microseconds timer. If you read Fons paper again, you will find his paper uses 
*some* clock which can be CPU, or real-time or any clock.
According to him "The stability of the timer used to get timestamps on both the 
input and output streams of the resampler doesn't matter much,
it basically almost disappears from the equations. Any random variations will 
be smoothed by a DLL."


>> Again, I don't see where you see the audio device clock in your system.
>> I'd be very thankful if you could explain **that** to me, since well, 
>> there's no clock line between my sound card and my CPU.

One way to make a sound card clock is to use the callback from JACK or ALSA and 
count samples.
The code must be robust in the sense that at no time, must even a single sample 
be lost.
With JACK this should be possible, and the callback happens precisely when the 
number of samples
configured for the buffer is over.


>> nd we're stating the original problem again.
>> We don't know any of these rates relative to any other of these rates.

Now the audio decoded is synchronized to transmitter rate  and send to sound 
card. By using a resampler this audio clock is adjusted to sound card clock 
rate.


-ben

From: Benny Alexandar
Sent: Tuesday, October 3, 2017 11:18 PM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing

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?


For a) & b) will use the sound card clock and using micro seconds timer.

And for c) run the decoded PCM through a FIFO buffer this is a local buffer 
which is not part of gnu-radio connect buffers,  between the SRC and the 
play-out stage. The trade-off for th

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

>>Yeah. But that doesn't help at all, since clock recovery of any digital 
>>receiver will give you samples resampled to the transmitter's clock...
>>Anyway, notice how you say "roughly". Now, compare that "roughness" to the 
>>"roughly the same" transmitter and receiver audio clock.
>>You're at least in the same order of magnitude here, and my point is that by 
>>introducing yet another clock into this
>>(the abyssimal bad PC clock), you're making things way worse than they need 
>>be, and atop of that, unnecessarily complicated.


Actually there exist a resampler at the input as well. After clock recovery the 
base band samples are synchronized with transmitter.  Then the symbols which 
make the transmission frames are timestamped. At this point we are in sync with 
transmitter.

The conversion  error of clocks  should be negligible compared to audio  sample 
rate as we are dealing with
microseconds timer. If you read Fons paper again, you will find his paper uses 
*some* clock which can be CPU, or real-time or any clock.
According to him "The stability of the timer used to get timestamps on both the 
input and output streams of the resampler doesn't matter much,
it basically almost disappears from the equations. Any random variations will 
be smoothed by a DLL."


>> Again, I don't see where you see the audio device clock in your system.
>> I'd be very thankful if you could explain **that** to me, since well, 
>> there's no clock line between my sound card and my CPU.

One way to make a sound card clock is to use the callback from JACK or ALSA and 
count samples.
The code must be robust in the sense that at no time, must even a single sample 
be lost.
With JACK this should be possible, and the callback happens precisely when the 
number of samples
configured for the buffer is over.


>> nd we're stating the original problem again.
>> We don't know any of these rates relative to any other of these rates.

Now the audio decoded is synchronized to transmitter rate  and send to sound 
card. By using a resampler this audio clock is adjusted to sound card clock 
rate.


-ben

From: Benny Alexandar
Sent: Tuesday, October 3, 2017 11:18 PM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing

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?


For a) & b) will use the sound card clock and using micro seconds timer.

And for c) run the decoded PCM through a FIFO buffer this is a local buffer 
which is not part of gnu-radio connect buffers,  between the SRC and the 
play-out stage. The trade-off for this approach of course is increased latency.
This way any variable work-load length is not going to affect and the local 
fifo will have fixed length.
Timing errors needs to be filtered using DLL which is  the same used in JACK.

-ben









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 t

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

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?


For a) & b) will use the sound card clock and using micro seconds timer.

And for c) run the decoded PCM through a FIFO buffer this is a local buffer 
which is not part of gnu-radio connect buffers,  between the SRC and the 
play-out stage. The trade-off for this approach of course is increased latency.
This way any variable work-load length is not going to affect and the local 
fifo will have fixed length.
Timing errors needs to be filtered using DLL which is  the same used in JACK.

-ben









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*

-ben

--

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
________
From: 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

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
___

Re: [Discuss-gnuradio] Signal Processing Block with Control Port

[Benny Alexandar]

Hi,

I'm not sure about control port, you are asking for sending asynchronous input 
to blocks.  GNU Radio blocks shud support data as well as control ports, which 
will be of much use.

-ben

--
Hi,

Is it possible to make a signal processing block which contains two input 
ports, one is byte type and the other is complex type. The only output port is 
also complex type. The byte type input port would just act like a controller 
port that when it receives "1", it allows data to flow form input complex port 
to output complex port.
If it is not possible, is there any alternative way to do this job in gnuradio 
companion?




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

>> 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?


For a) & b) will use the sound card clock and using micro seconds timer.

And for c) run the decoded PCM through a FIFO buffer this is a local buffer 
which is not part of gnu-radio connect buffers,  between the SRC and the 
play-out stage. The trade-off for this approach of course is increased latency.
This way any variable work-load length is not going to affect and the local 
fifo will have fixed length.
Timing errors needs to be filtered using DLL which is  the same used in JACK.

-ben









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*

-ben

--

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
____
From: 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

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 i

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

>>Could you maybe elaborate how you're planning to solve all a),b),c) instead 
>>of asking for new feedback?


For a) & b) will use the sound card clock and using micro seconds timer.

And for c) run the decoded PCM through a FIFO buffer this is a local buffer 
which is not part of gnu-radio connect buffers,  between the SRC and the 
play-out stage. The trade-off for this approach of course is increased latency.
This way any variable work-load length is not going to affect and the local 
fifo will have fixed length.
Timing errors needs to be filtered using DLL which is  the same used in JACK.

-ben









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*

-ben

--

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
________
From: 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

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

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

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*

-ben

--

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

From: 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

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><mailto:usrp-users-boun...@lists.ettus.com> 
on behalf of Marcus Müller via USRP-users 
<usrp-us...@lists.ettus.com><mailto:usrp-us...@lists.ettus.com>
Sent: Tuesday, September 19, 2017 2:10 AM
To: usrp-us...@lists.ettus.com<mailto:usrp-us...@lists.ettus.com>; GNURadio 
Discussion List
Subject: Re: [USRP-users] Audio Control loop testing


Hi Ben,


that's the old multi-clock pr

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

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><mailto:usrp-users-boun...@lists.ettus.com> 
on behalf of Marcus Müller via USRP-users 
<usrp-us...@lists.ettus.com><mailto:usrp-us...@lists.ettus.com>
Sent: Tuesday, September 19, 2017 2:10 AM
To: usrp-us...@lists.ettus.com<mailto: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 m

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

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><mailto:usrp-users-boun...@lists.ettus.com> 
on behalf of Marcus Müller via USRP-users 
<usrp-us...@lists.ettus.com><mailto:usrp-us...@lists.ettus.com>
Sent: Tuesday, September 19, 2017 2:10 AM
To: usrp-us...@lists.ettus.com<mailto: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 

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

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<mailto: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

Re: [Discuss-gnuradio] [GSoC 17] DAB: Updates

[Benny Alexandar]

Hi All,


Nice to see some discussion on DRM. Well, I also used gr-drm and is not fully 
supported like multiple audio and data services. DRm also uses tow audio codecs 
namely AAC and xHE-AAC. gr-drm supports only AAC. I don't know about any 
xHE-AAC encoder/decoder open source available. If anybody knows please let me 
know. I'm there to enhance the gr-drm to make it a fully blown DRM transmitter.


-ben



From: Benny Alexandar <ben.a...@outlook.com>
Sent: Saturday, August 19, 2017 10:30:23 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] [GSoC 17] DAB: Updates


Hi All,


Nice to see some discussion on DRM. Well, I also used gr-drm and is not fully 
supported like multiple audio and data services. DRm also uses tow audio codecs 
namely AAC and xHE-AAC. gr-drm supports only AAC. I don't know about any 
xHE-AAC encoder/decoder open source available. If anybody knows please let me 
know. I'm there to enhance the gr-drm to make it a fully blown DRM transmitter.


-ben
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC 17] DAB: updates of the week

[Benny Alexandar]

Hi Luca,


Nice to see your progress so far. Once you have the
DAB receiver audio listening in place, I would
suggest to have an audio synchronization for continuous
playback without any buffer overflow or under-runs.

DAB+ audio super frame length is 120ms according to DAB+
standard (ETSI TS 102 563). Each audio super frame is
carried in five consecutive logical DAB frames.
Which means 120ms of audio is mapped to 5 DAB frames.

If I add a timestamp at the receiver when the first DAB frame
sample arrives, I can check the max latency when it comes to
audio renderer, I mean after buffering to adjust the variable
decoding time of compressed audio.

t_D = t_A -  t_B ,
where,
 t_A = time at audio out
 t_B = time at input baseband sample.
 t_D = maximum system delay.

The difficulty is to estimate the slow clock drift correctly
and separate it from the short-time channel/decoding jitter.

Add a delay to buffer audio at audio out, say  D, which is larger
than max system delay. Whenever the audio reaches audio out, check the
delay to separate the clock drift.

 drift = t_D - D

Please let me know if you need any more details.

-ben













From: Discuss-gnuradio  
on behalf of Moritz Luca Schmid 
Sent: Friday, May 26, 2017 6:19:31 PM
To: GNURadio Discussion List
Subject: [Discuss-gnuradio] [GSoC 17] DAB: updates of the week


Hi everyone,

I just published my latest updates of my DAB project in a new blog 
post.

This week, I created a source block for the Fast Information Channel and 
started to build a reception chain for the Main Service Channel (where the 
audio data is transmitted).

Read more about it in my post.


Cheers

Luca
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] Audio Synchronization

[Benny Alexandar]

Hi Marcus,


Yes, we had long discussions and I had discussion
with Fons separately as well.

I tried to implement his paper
http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf
on an embedded platform to quickly check the behavior as
well, were I can adjust the audio sample rate in hardware.
So, I don't need an adaptive re-sampler.

Because of the limitations in implementing the paper
as such, I had to modify it and Fons stopped supporting me!

Instead of controlling the average  number of samples
control the average time any particular sample
stays in the buffer.Please find the attached
figure modified to control the average time.

In the fig,
'W(k)' and 'R(k)'  are functions  which can take an arbitrary sample
number as their argument and returns the corresponding write and read time.

If a straight line is drawn horizontally the intersection points
corresponds to the Write and Read timings for the same number of samples.

During callback the delay error is calculated as
 err = t_R - t_W + aDec_t - D

 where,
 t_R   = time at read side callback when it finished
 DMAing the k samples.
 t_W   = write time of buffer when it wrote k samples.
 aDec_t  =  average decoding time.
 D   = target delay.

If ‘err’ is positive we need to increase the read sample
rate. If it is negative we need to decrease it.

This approach is a very good optimization in terms of
computation. On the write side I have to apply
the DLL to smooth time and send only the
write timestamp as meta data to callback.
I don't need to compute the sample rate at
 write side and even number of samples written
 also. The interpolation of time at read side
 is just the previous buffer timestamp for the
 same number of samples written and read
assuming the buffering is only two buffers
between write and read.

Unlike other broadcast standards such as DVB-T where
the transmitter sends a reference TimeStamp counter
(CTS,PTS) as a global reference clock information to receiver,
in digital radio standards such as DAB there are
no reference timestamp from transmitter. Only by using
the local clock the receiver estimates a worst case delay.

Please review this proposal, I would like to implement
it for GNU radio as a GSoC project as well.
I'm planning this for broadcast receivers such as
DAB/DAB+ , DRM/DRM+ etc.

 -ben


From: Marcus Müller <marcus.muel...@ettus.com>
Sent: Monday, March 20, 2017 11:42:50 PM
To: Benny Alexandar; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Synchronization


Hi Ben,


please keep discussions on the list.


I don't fully understand your question. You, Fons and I (as well as others) had 
a very very lengthy discussion on why this is hard and how to do that on the 
mailing list a while back.


Best regards,

Marcus


On 03/19/2017 07:13 AM, Benny Alexandar wrote:

Hi Marcus,


I'm using digital radio (DRM) receiver.


How to synchronize the audio in digital radio reception with transmitter audio 
clock to avoid buffer over flow and under run ?


Audio In-> DRM Tx --->..--->USRP> gr-drm---> Audio out


-ben


From: USRP-users 
<usrp-users-boun...@lists.ettus.com><mailto:usrp-users-boun...@lists.ettus.com> 
on behalf of Marcus Müller via USRP-users 
<usrp-us...@lists.ettus.com><mailto:usrp-us...@lists.ettus.com>
Sent: Sunday, March 19, 2017 12:03:11 AM
To: usrp-us...@lists.ettus.com<mailto:usrp-us...@lists.ettus.com>
Subject: Re: [USRP-users] Audio Synchronization


Hi Benny,


what kind of broadcast are you referring to? AM, FM (which are analog audio, so 
you'd not have any audio clock), DRM, DAB/DAB+?

maybe a really quick block diagram would help me understand the issue at hand.


Best regards,

Marcus

On 18.03.2017 14:03, Benny Alexandar via USRP-users wrote:

Hi,


I'm implementing the broadcast receiver using USRP & GNU Radio. For audio 
synchronization with transmitter clock, should I use the RF local clock base 
band arriving sample time or estimate the audio clock after audio decoding ?


How to do the synchronization with audio transmitter clock ?


-ben



___
USRP-users mailing list
usrp-us...@lists.ettus.com<mailto: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] [GSoC] A DAB/DAB+ transceiver app: Draft of proposal

[Benny Alexandar]

Hi Luca,


Good proposal to see you are planning to add audio coding/decoding into the 
module.

Please add a synchronization method to synchronize the received audio with 
transmitter audio clock.


Let me know if you need any details.


-ben
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Regarding GSoC'17

[Benny Alexandar]

Hi Kartik,


You can start by going through the following link,

http://gnuradio.org/redmine/projects/gnuradio/wiki/Tutorials


Just google it you will get plenty to start with.


Since you are from communication and DSP background, I suggest to contribute on 
Digital Radio standard DRM for India. Already digital radio transmissions are 
available in India.  GNURadio has DRM transmitter too.


Please let me know if you need any more details.


-ben


From: Discuss-gnuradio  
on behalf of Kartik Patel 
Sent: Friday, December 16, 2016 10:04:19 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Regarding GSoC'17

Hi.

I'm Kartik, a student of IIT Roorkee. I'm interested in contributing to GNU 
Radio and am aiming for GSoC '17. I'm fluent in Python and C++. Having the 
background in communication engineering, I have strong fundamentals in 
communication systems and DSP etc. As I have already developed a module in NS3, 
I have some idea of the open-source development. It'd be great if I could get 
some help on how to start off with GNU Radio development.

Thank you.

Regards,
Kartik Patel

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Benny Alexandar]

>> If you mean that the internal buffer isn't needed and that the gr buffer can 
>> take
its role, that's not going to work.

This is what I'm thinking of.
All the packets which are put into the input queue of audio sink has
to be timestamped using the same clock used in audio sink. Pass this
timestamp info as part of metadata of packet. Every packet in the queue
has a timestamp which tells the time of last sample W(t), and how many
samples k(t).

First time when audio sink receives the  packet, it reads the current time
c(t) and packet timestamp W(t). Add a fixed delay (D) to the packet timestamp
to delay the audio playback.

deviation = W(t) + D - c(t)->   (1).
The delay is such that equ (1) never becomes negative.

When audio hardware finishes playing out R(t) of each packet data it interrupts
and in isr callback calculate equ (1) for next packet and average deviation.

This in effect reflects the internal buffer operation exactly.

-ben



From: Fons Adriaensen <f...@linuxaudio.org>
Sent: Tuesday, November 15, 2016 1:44:37 AM
To: Benny Alexandar
Cc: Marcus Müller; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( 
Delay locked loop for the two-clock problem)

On Mon, Nov 14, 2016 at 04:59:24PM +, Benny Alexandar wrote:

> I have some questions regarding it.
> How many blocks of audio the internal buffer  need to store ?

Enough to keep feeding samples to the audio HW until the sink's
work() is called again.

> When does the copy from gr buffer to internal buffer happens ? Is it
> during the audio hardware driver call back or during gr scheduling
> the audio sink ?

When gr calls the sink's work().

> Before copying to the internal buffer the audio block has to be played
> to prevent overwrite of data. In a way it has to do the same check
> what the gr buffers do, space is available to copy etc.

The sink's work() will block until all input data is transferred
to the internal buffer.

> Why not handle this with gr buffer ? Audio sink can query the
> available data in its input queue.

I don't understand what exactly you mean. If you mean that the
internal buffer isn't needed and that the gr buffer can take
its role, that's not going to work.

> I was reading the paper "usingdll.pdf" in that the first figure (fig 1)
> ( The thin (blue) line is the exact mapping we want. Note
> that in this example the real sample frequency is
> slightly lower that the nominal — the thin line
> is lagging the grid as time advances.)
>
> In an ideal case the thin blue line should intersect all the grid points.
> Why the real sample frequency is slightly lower than nominal ?

It's just an example, illustrating what happens in that case.

Ciao,

--
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Benny Alexandar]

Hi Fons,

Thanks for the detailed explanation.

I have some questions regarding it.
How many blocks of audio the internal buffer  need to store ?
When does the copy from gr buffer to internal buffer happens ? Is it
during the audio hardware driver call back or during gr scheduling the
audio sink ?
Before copying to the internal buffer the audio block has to be played
to prevent overwrite of data. In a way it has to do the same check
what the gr buffers do, space is available to copy etc.
Why not handle this with gr buffer ? Audio sink can query the
available data in its input queue.

I was reading the paper "usingdll.pdf" in that the first figure (fig 1)
( The thin (blue) line is the exact mapping we want. Note
that in this example the real sample frequency is
slightly lower that the nominal — the thin line
is lagging the grid as time advances.)

In an ideal case the thin blue line should intersect all the grid points.
Why the real sample frequency is slightly lower than nominal ?

-ben



From: Fons Adriaensen <f...@linuxaudio.org>
Sent: Sunday, November 13, 2016 9:47:48 PM
To: Benny Alexandar
Cc: Marcus Müller; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( 
Delay locked loop for the two-clock problem)

On Sun, Nov 13, 2016 at 02:46:57PM +, Benny Alexandar wrote:

[ Please use the  key to limit the lenght of your text lines ]

> Only the receiver has to measure the drift and adjust to the incoming
> rate.
> ...
> So my problem is how to measure the ppm drift using timestamps from
> only the audio sink

You do not need to measure the rate error, at least not explicitly.
That is not how it works.

There will be some buffer between whatever provides the audio stream
(receiver, network, ...) and whatever consumes it (resampler or hardware
with adjustable sample rate).

If the rates are matched, then the *average* number of samples in that
buffer will be constant. Whenever it is greater than some target value
you increase the hardware sample rate. When it is lower you decrease
the hardware sample rate.

So the remaining problem is to find the average number of samples in
the buffer (and not to measure the 'ppm drift').

This is done by timing both the arrival and consumption of samples,
i.e. the write and read operations to the buffer. For each block
that is written or read, you mark the time 't' (using the same clock
for both) and you also keep a sample count 'k'. So on both ends you
have a series of (t, k),  These provide a piecewise-linear function
k(t), mapping 't' to 'k'. A DLL is used to ensure this is a smooth
function (in other words, one that is stays close to a straight line).

Then the average number of samples is the difference of these two
functions evaluated at the same time. This is compared to the target
value and the smoothed difference is used to adjust the hardware
sample rate. Note that this is a feedback system, and you need to
ensure stability.

That's it, I don't think I can explain it more clearly.

Ciao,

--
FA


A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Benny Alexandar]

>>It can, even if the data stream has irregular timing. That's why there
>>is a DLL there. See the links posted before for how it works.

Suppose if I have an audio hardware where I can set the ppm drift and the 
hardware adjusts the sampling frequency based on the ppm drift, then no need of 
the resampler and delay caused by resampler, but I need to measure the ppm 
drift. I was reading your paper on adaptive resampling. For example in case of 
broadcast receiver there is no feedback path from transmitter or any other 
sources. Only the receiver has to measure the drift and adjust to the incoming 
rate.  So my problem is how to measure the ppm drift using timestamps from only 
the audio sink and do I need the DLL if my hardware supports programing the ppm 
for adjusting the sampling frequency ? I can adjust it after every block of 
audio samples being rendered, which may be too frequent, instead average over 
few seconds and adjust it.

-ben


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Benny Alexandar]

Hi Fons,



>>  codec -> [ buffer -> resampler ] -> audio HW.

>>where [...] is the audio sink block. The buffer is *an internal part*
>>of the audio sink, and *not* the one that gr provides to connect codec
>>and audio sink.

So, there is an internal buffer in audio sink, which should at least be able to 
store a minimum of two audio frame blocks of same duration say (Tf).
- Gnuradio scheduler puts each audio frames of duration 'Tf' into the queue 
between codec and audio sink.
- Audio sink copies into internal buffer and starts the audio hardware when two 
audio frames( frame_delay) are available in the internal buffer.
- Audio hardware triggers a callback after finishing each audio frame, ie after 
Tf time.
- For each callback measure the elapsed time  diff = (t2 - t1).
- The error is (Tf - diff)  - (2 * frame_delay)


>>For this it needs timing info on
>>both the incoming and the outgoing blocks of data, using the same
>>clock for both.

Yes, but the input rate cannot be measured, because the codec is scheduled 
whenever there is output space in the queue and input bitstream is available to 
decode. This makes the input rate of audio sink to be variable based on codec 
processing time and  is highly variable based on the content encoded . How to 
apply the DLL here ?
But the codec can use the time stamp of the input bitstream which is stamped at 
RF sample entry time. So codec gets every transmission frame timestamped from 
USRP.   These transmission frames will be decoded into 'N' audio frames which 
does a interpolation of the timestamp from the RF entry time for each audio 
frame as explained earlier.


>>That means that only the audio sink block can do meaningfull timing of
the buffer writes, and any other info provided by upstream blocks
is useless. That's also why the buffer is part of the audio sink.

The reason for timestamping each audio frame from the start of transmission 
frame is because of not possible to timestamp every RF sample while entering. 
Timestamping will be at RF block of frames, which in a way maps to audio 
frames. But we can check the timestamps of every audio frame at audio sink, and 
the variation in data rate will be captured for every new RF received frame. So 
in effect if the RF block duration is Trf, the timestamping is also on the same 
duration.  In between timestamps are interpolated.

-ben


FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-drm reconfiguration & Channel simulations

[Benny Alexandar]

Hi Felix,


I pulled the master version of gr-drm from  (https://github.com/kit-cel/gr-drm) 
  and build and installed it. But when tried to execute the flow graph under 
apps/grc_flowgraphs/drm_transmitter.grc it throwed the attached errors.


[cid:89c79bb6-1556-4210-8212-981342832201]




-ben


From: Felix Wunsch <felix.wun...@kit.edu>
Sent: Thursday, November 10, 2016 10:22:38 PM
To: Benny Alexandar; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gr-drm reconfiguration & Channel simulations


Hi Ben,


the flowgraph is not tested at all as I have no DRM+ receiver to test against. 
I'm not aware of any other open source implementations.


- Felix

On 11/09/2016 05:29 PM, Benny Alexandar wrote:

Hi Felix,


Any update on DRM+, I'm planning to use DRM+ transmission using gr-drm. Is it 
fully functional and tested ?  DREAM doesn't support DRM+ reception. Any open 
source receiver available to receive DRM+ ?


-ben


From: Felix Wunsch <felix.wun...@kit.edu><mailto:felix.wun...@kit.edu>
Sent: Monday, November 7, 2016 5:44:16 PM
To: Benny Alexandar; discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] gr-drm reconfiguration & Channel simulations


Hi Ben,


even though the stable version should work, please use the master branch, which 
contains all the recent changes. As you can see in the commit log, we moved our 
activity towards the kit-cel fork.


Regarding the DRM receiver: Actually, a student of mine wrote some code during 
his Master's thesis this year.We did not yet merge it into gr-drm, you can find 
the code here: https://github.com/florianbrauchle/gr-rxdrm. The code probably 
won't run in real-time, though. As the audio decoder is still missing, we never 
had to look into issues like clock drift.


- Felix



On 11/05/2016 05:31 AM, Benny Alexandar wrote:

Hi Felix,


>>>>

I'm happy to hear that gr-drm is being used! I hope you are using the newest 
version, I did quite some refactoring some time ago.,

I pulled the git stable version from this link,
https://github.com/kit-cel/gr-drm/tree/stable

Which is the latest version of gr-drm ?  I see another git version
https://github.com/fewu/gnuradio_drm

which one to use to get the latest changes ? Please send me the link. Do you 
have anyworking version of DRM receiver available on git ?

I'm using USRP N210 for transmission. Have you looked at receiver audio 
tracking to make sure the DRM receiver is compensating the drift in audio 
sample rates, to prevent overflow/uderrun etc ?

-ben



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Cheers
Felix

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Felix Wunsch, M.Sc.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-46276
Fax: +49 721 608-46071
E-Mail: felix.wun...@kit.edu<mailto:felix.wun...@kit.edu>

www.cel.kit.edu<http://www.cel.kit.edu>

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Felix Wunsch, M.Sc.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-46276
Fax: +49 721 608-46071
E-Mail: felix.wun...@kit.edu<mailto:felix.wun...@kit.edu>

www.cel.kit.edu<http://www.cel.kit.edu>

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Felix Wunsch, M.Sc.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-46276
Fax: +49 721 608-46071
E-Mail: felix.wun...@kit.edu<mailto:felix.wun...@kit.edu>

www.cel.kit.edu<http://www.cel.kit.edu>

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Benny Alexandar]

Hi Fons,

>The only time that would make sense would be the
>timestamp at the A/D converter of the RF sample that in some way
>corresponds to the start of the compressed frame. And even that
>assumes that there is simple linear relation between the RF samples
>and audio samples.

Yes, thats right. But now the problem is RF samples are captured by USRP and
is passed to PC for further processing. So, if USRP timestamps the RF block of 
samples
it will be based on a different clock. For example the timer used in USRP is 
2MHz counter,
 when it is received at PC side clock conversion is required to match the PC 1 
MHz counter.
Can this conversion affect the timestmaping at PC side because of round off 
error?

RF block duration is directly propotional to audio frame durations. 100ms of RF 
block duration will corresponds to 100ms of audio.
Otherwise it won't be continuous audio streaming. This is my understanding, 
please correct if I'm wrong.

-ben

From: Fons Adriaensen <f...@linuxaudio.org>
Sent: Thursday, November 10, 2016 2:56:50 AM
To: Benny Alexandar
Cc: Marcus Müller; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( 
Delay locked loop for the two-clock problem)

On Wed, Nov 09, 2016 at 05:12:25PM +, Benny Alexandar wrote:

> So the logic is whenever an audio compressed frame arrives at the audio codec,
> it is timestamped with the current time (Ti) and after uncompressed each audio
> frame blocks (24ms) is timestamped by adding 24ms ( Ti + ( frame_no * 
> frame_duration )),
> where Ti is the start time and frame_no is the decoded uncompressed frames 
> ranges from
> 0 to n and frame_duration is 24ms.

That doesn't make much sense, for at least two reasons.

First, the time when a compressed frame arrives at the codec has no
meaning. At that point the signal is just data stored in memory, not
a physical one. The only time that would make sense would be the
timestamp at the A/D converter of the RF sample that in some way
corresponds to the start of the compressed frame. And even that
assumes that there is simple linear relation between the RF samples
and audio samples.

Now that doesn't mean that such timestamps can't be used. But you
can't use them in the naive way you describe.

Second, if you read the timer once and then just add the nominal 24ms
for all following timestamps, you don't get any information about the
data rate at all. Simple reason is only the first timestamp contains
any new information, all the others are redundant because they can be
computed from the first. But maybe I misunderstand that part of your
scheme.

> ... After some N seconds this accumulated value is averaged by dividing
> by N sec. So I get the drift in sampling rate in terms of samples.
> Then all I need to do is slow down or speed up the sampling rate based
> on which side the drift is.

You'd need to do this continuously. A single correction can't be perfectly
accurate, and any remaining error is integrated w.r.t. time and will grow
without bound. And you can't assume the sample rate ratio is fixed, it
will drift as well.

> Is it possible to change the sample rate of ALSA by drift amount ?

On a few professional (and very expensive) audio cards allow continuous
control of the sample rate, e.g. RME's MADI interfaces.


Ciao,

--
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Benny Alexandar]

Hi Fons/Marc,


For Digital radio the audio data is received in compressed format. Using audio 
codec it is uncompressed. The uncompressed audio will be sent to audio sink 
with a block size of 24ms. Before sending  these audio blocks are timestamped 
using PC microsecond timer. To access the clock value of timer, I do a "direct" 
read of memory mapped hardware register (TSC) to avoid OS delays and jitter 
etc.  So the logic is whenever an audio compressed frame arrives at the audio 
codec, it is timestamped with the current time (Ti) and after uncompressed each 
audio frame blocks (24ms) is timestamped by adding 24ms ( Ti +   ( frame_no * 
frame_duration ) ), where Ti is the start time and frame_no is the decoded 
uncompressed frames ranges from 0 to n and frame_duration is 24ms.


When these audio frames reaches the audio sink, it reads the current time (Tc) 
from   same clock (TSC) and measure the elapsed time ,   diff  =( ( Tk + 
delay )  -  Tc ),   where  Tk  = ( Ti +   ( frame_no * frame_duration ) ) 
and delay is 2 frame delay (48ms) . Every time the audio sink call back happens 
   (aftre streaming an aduio frame(24ms) interrupt happens) , the diff is 
calculated and  accumulated. Ideally if the audio sink is sending at the 
"nominal sample rate" the delay should be constant.  After some N seconds this 
accumulated value is averaged by dividing by N sec. So I get the drift in 
sampling rate in terms of samples.  Then all I need to do is slow down or speed 
up the sampling rate based on which side the drift is.



Is it possible to change the sample rate of ALSA by drift amount ?




-ben


From: Fons Adriaensen <f...@linuxaudio.org>
Sent: Monday, November 7, 2016 1:34:07 AM
To: Marcus Müller
Cc: Benny Alexandar; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( 
Delay locked loop for the two-clock problem)

On Sun, Nov 06, 2016 at 07:32:47PM +0100, Marcus Müller wrote:

> under the hood, sinks are sync_blocks.

Which is what surprises me. Sinks have no outputs, and
sources have no inputs, so the whole 'sync' concept seems
out of place...

Ciao,

--
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-drm reconfiguration & Channel simulations

[Benny Alexandar]

Hi Felix,


Any update on DRM+, I'm planning to use DRM+ transmission using gr-drm. Is it 
fully functional and tested ?  DREAM doesn't support DRM+ reception. Any open 
source receiver available to receive DRM+ ?


-ben


From: Felix Wunsch <felix.wun...@kit.edu>
Sent: Monday, November 7, 2016 5:44:16 PM
To: Benny Alexandar; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] gr-drm reconfiguration & Channel simulations


Hi Ben,


even though the stable version should work, please use the master branch, which 
contains all the recent changes. As you can see in the commit log, we moved our 
activity towards the kit-cel fork.


Regarding the DRM receiver: Actually, a student of mine wrote some code during 
his Master's thesis this year.We did not yet merge it into gr-drm, you can find 
the code here: https://github.com/florianbrauchle/gr-rxdrm. The code probably 
won't run in real-time, though. As the audio decoder is still missing, we never 
had to look into issues like clock drift.


- Felix



On 11/05/2016 05:31 AM, Benny Alexandar wrote:

Hi Felix,


>>>>

I'm happy to hear that gr-drm is being used! I hope you are using the newest 
version, I did quite some refactoring some time ago.,

I pulled the git stable version from this link,
https://github.com/kit-cel/gr-drm/tree/stable

Which is the latest version of gr-drm ?  I see another git version
https://github.com/fewu/gnuradio_drm

which one to use to get the latest changes ? Please send me the link. Do you 
have anyworking version of DRM receiver available on git ?

I'm using USRP N210 for transmission. Have you looked at receiver audio 
tracking to make sure the DRM receiver is compensating the drift in audio 
sample rates, to prevent overflow/uderrun etc ?

-ben



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Cheers
Felix

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Felix Wunsch, M.Sc.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-46276
Fax: +49 721 608-46071
E-Mail: felix.wun...@kit.edu<mailto:felix.wun...@kit.edu>

www.cel.kit.edu<http://www.cel.kit.edu>

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Felix Wunsch, M.Sc.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-46276
Fax: +49 721 608-46071
E-Mail: felix.wun...@kit.edu<mailto:felix.wun...@kit.edu>

www.cel.kit.edu<http://www.cel.kit.edu>

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Benny Alexandar]

Hi Marc,



>>>The problem I have with this is that we get a fourth clock involved here: it 
>>>relies on the OS'es "microsecond-accurate time", and that runs at an 
>>>oscillator in your CPU or on your motherboard, and thus, relative to a f3. 
>>>Again, for audio stuff, the short-term stability and accuracy of that clock 
>>>>>>should be good enough for that delay-based estimation; if you wanted to 
>>>synchronize MS/s streams, that might change, IMHO.

>>>So the main technical problem that we have is that whilst this DLL (I'd just 
>>>call it a buffer-fillage control loop) is conceptually nice to understand, 
>>>no-one has implemented it within GNU Radio – if you found yourself able to 
>>>write it for ALSA (not much sense writing it for the Jack sink, if Jack can 
>>>>>>already do it internally), we shall surely find a way to "upstream" this 
>>>and help you with code review!

Instead of relying the fourth clock on CPU,  we can use a counter from audio 
hardware that will be more stable than CPU timer.  I would like to explore this 
option of using a TimeStampCounter (TSC) from  audio hardware if it exists. If 
you know of any please let me know.



-ben

________
From: Marcus Müller <marcus.muel...@ettus.com><mailto:marcus.muel...@ettus.com>
Sent: Friday, November 4, 2016 10:32:26 PM
To: Benny Alexandar; discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>; 
f...@linuxaudio.org<mailto:f...@linuxaudio.org>
Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( 
Delay locked loop for the two-clock problem)


Hi Benny,

Drift between what and what?

So, drift between the RF receiver hardware and the transmitter: that's job of 
the timing recovery in the receiver.

The output of that is an audio signal that is correctly resampled for the 
*nominal* sampling rate of the Soundcard, measured in nominal sampling rate of 
your RF device.


Now, the Audio over and underrun problems happen because these nominal rates 
are derived from two different oscillators and don't agree.


So, there's two problems:


1. Receiver Timing recovery (solvable in software)

2. Resampling to match the actual audio hardware sampling rate


so, for 2., Fons' approach is described in his papers. The resampling isn't 
actually the problem, the estimation of frequency offset is.


The question on how to get timestamps from the receiver is a) RF hardware 
specific (for example, as far as I know, the USRPs are pretty much the only 
devices that add timestamps – but I think I might be wrong) and b) irrelevant 
to the problem of resampling, because a timestamp from the receiver device is 
completely independent from a time in your PC and both are independent from how 
fast your audio hardware's sampling rate is. Really.


Imagine you have three rooms, each with a clock on the wall. All three clocks 
run slightly wrong, and all were set to 12:00 at different times, and all you 
do is put things into parcels in the first room, strap that parcel onto the 
back of a tortoise and tell the tortoise to go to the next room. The timestamp 
you put on the parcel in the first room will not be that much help in the 
second room, aside from telling you roughly how late it was in the first (RF 
hardware) room when the tortoise started to go into the second room (CPU). You 
can then take the samples out of your parcel, process them and put them into 
another parcel strapped to a tortoise aiming for the third room (audio 
hardware).


The problem at discussion here is how to estimate the individual clock's speed 
differences (since there is no inherently "true" clock), purely based on when 
the tortoises arrived in the next room – and while we're at it, eliminate the 
effects of the tortoises being unevenly motivated, unevenly loaded, and 
randomly delayed, all while the clocks drift faster than the tortoises move...


Best regards,

Marcus


On 11/04/2016 05:47 PM, Benny Alexandar wrote:

Hi Marcus,


I have read the papers from Fons, and was interesting to know how the algorithm 
implements the control loop. For broadcast receiver also the same can be 
applied.  Here  the received audio will be in blocks of samples and the output 
audio rate can drift due to crystal inaccuracies.


How to estimate the drift in case of broadcast receiver ?

How to get the timestamps for broadcast receiver ?


[1] http://kokkinizita.linuxaudio.org/papers/adapt-resamp-pres.pdf
[2] Adriaensen, Fons: "Controlling adaptive resampling", 2012, 
http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf

Controlling adaptive resampling - 
Linuxaudio.org<http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf>
kokkinizita.linuxaudio.org
Controlling adaptive resampling Fons ADRIAENSEN, Casa della Musica, Pzle. San 
Francesco 1, 43000 Pa

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Benny Alexandar]

Hi Marcus,


Thanks for the detailed explanation.



May be my understanding is wrong, please correct me if it is wrong.  For 
example I'm using the DRM digital radio transmission and using the receiver for 
reception of digital radio. During live transmission the  sound from microphone 
or other sources are digitized and samples at a "nominal sampling frequency",  
and the oscillator used here for sampling the audio signals can drift.  This is 
encoded and channel coded and transmitted.


I'm using USRP N210 to receive the digital transmission. USRP samples the RF 
input signal and converts to IQ signals and sends to PC or other hardware 
receiver. The receiver then does the channel decoding (OFDM demoudlation, 
carrier frequency offset correction etc) and audio  decoding and sends the 
audio output at "nominal sampling frequency" using audio hardware. So, the 
drift can happens in the following scenarios.


1. Transmitter crystal drifts which affects the audio sampling rate.

2. USRP uses separate crystal which can drift introducing drift on IQ samples.

3. PC audio hardware has to adjust these drifts to send the audio at adjusted 
sampling frequency to avoid buffer overrun/underun etc


I guess the drift in 2. can be adjusted through timing recovery as you 
mentioned.  But what about the audio drifts ?


Since there are no timestamps send as part of transmission,  to correct the 
drift in receiver the following can be applied.


Put a timestamp using receiver timer  (micro seconds timer) and stamp every 
physical frame arriving at receiever. After audio decoding stamp every audio 
frame with the corresponding frame duration. Then when it is rendered at the 
audio hardware it can check the current time and the packet time during every 
callback of audio frame and average the drift over some duration and correct 
the sampling frequency.



-ben


From: Marcus Müller <marcus.muel...@ettus.com>
Sent: Friday, November 4, 2016 10:32:26 PM
To: Benny Alexandar; discuss-gnuradio@gnu.org; f...@linuxaudio.org
Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( 
Delay locked loop for the two-clock problem)


Hi Benny,

Drift between what and what?

So, drift between the RF receiver hardware and the transmitter: that's job of 
the timing recovery in the receiver.

The output of that is an audio signal that is correctly resampled for the 
*nominal* sampling rate of the Soundcard, measured in nominal sampling rate of 
your RF device.


Now, the Audio over and underrun problems happen because these nominal rates 
are derived from two different oscillators and don't agree.


So, there's two problems:


1. Receiver Timing recovery (solvable in software)

2. Resampling to match the actual audio hardware sampling rate


so, for 2., Fons' approach is described in his papers. The resampling isn't 
actually the problem, the estimation of frequency offset is.


The question on how to get timestamps from the receiver is a) RF hardware 
specific (for example, as far as I know, the USRPs are pretty much the only 
devices that add timestamps – but I think I might be wrong) and b) irrelevant 
to the problem of resampling, because a timestamp from the receiver device is 
completely independent from a time in your PC and both are independent from how 
fast your audio hardware's sampling rate is. Really.


Imagine you have three rooms, each with a clock on the wall. All three clocks 
run slightly wrong, and all were set to 12:00 at different times, and all you 
do is put things into parcels in the first room, strap that parcel onto the 
back of a tortoise and tell the tortoise to go to the next room. The timestamp 
you put on the parcel in the first room will not be that much help in the 
second room, aside from telling you roughly how late it was in the first (RF 
hardware) room when the tortoise started to go into the second room (CPU). You 
can then take the samples out of your parcel, process them and put them into 
another parcel strapped to a tortoise aiming for the third room (audio 
hardware).


The problem at discussion here is how to estimate the individual clock's speed 
differences (since there is no inherently "true" clock), purely based on when 
the tortoises arrived in the next room – and while we're at it, eliminate the 
effects of the tortoises being unevenly motivated, unevenly loaded, and 
randomly delayed, all while the clocks drift faster than the tortoises move...


Best regards,

Marcus


On 11/04/2016 05:47 PM, Benny Alexandar wrote:

Hi Marcus,


I have read the papers from Fons, and was interesting to know how the algorithm 
implements the control loop. For broadcast receiver also the same can be 
applied.  Here  the received audio will be in blocks of samples and the output 
audio rate can drift due to crystal inaccuracies.


How to estimate the drift in case of broadcast receiver ?

How to get the timestamps

Re: [Discuss-gnuradio] gr-drm reconfiguration & Channel simulations

[Benny Alexandar]

Hi Felix,




I'm happy to hear that gr-drm is being used! I hope you are using the newest 
version, I did quite some refactoring some time ago.,

I pulled the git stable version from this link,
https://github.com/kit-cel/gr-drm/tree/stable

Which is the latest version of gr-drm ?  I see another git version
https://github.com/fewu/gnuradio_drm

which one to use to get the latest changes ? Please send me the link. Do you 
have anyworking version of DRM receiver available on git ?

I'm using USRP N210 for transmission. Have you looked at receiver audio 
tracking to make sure the DRM receiver is compensating the drift in audio 
sample rates, to prevent overflow/uderrun etc ?

-ben



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Cheers
Felix

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Felix Wunsch, M.Sc.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-46276
Fax: +49 721 608-46071
E-Mail: felix.wun...@kit.edu

www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Benny Alexandar]

Hi Marcus,


I have read the papers from Fons, and was interesting to know how the algorithm 
implements the control loop. For broadcast receiver also the same can be 
applied.  Here  the received audio will be in blocks of samples and the output 
audio rate can drift due to crystal inaccuracies.


How to estimate the drift in case of broadcast receiver ?

How to get the timestamps for broadcast receiver ?


[1] http://kokkinizita.linuxaudio.org/papers/adapt-resamp-pres.pdf
[2] Adriaensen, Fons: "Controlling adaptive resampling", 2012, 
http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf

Controlling adaptive resampling - 
Linuxaudio.org<http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf>
kokkinizita.linuxaudio.org
Controlling adaptive resampling Fons ADRIAENSEN, Casa della Musica, Pzle. San 
Francesco 1, 43000 Parma (PR), Italy, f...@linuxaudio.org Abstract Combining 
audio ...


[3] Adriaensen, Fons: "Using a DLL to filter time", 2005, 
http://kokkinizita.linuxaudio.org/papers/usingdll.pdf
Using a DLL to ?lter time - 
Linuxaudio.org<http://kokkinizita.linuxaudio.org/papers/usingdll.pdf>
kokkinizita.linuxaudio.org
Using a DLL to ?lter time Fons ADRIAENSEN Alcatel Space 
fons.adriaen...@skynet.be Abstract A new mechanism to obtain an accurate 
mapping between samples and system ...




-ben


From: Discuss-gnuradio <discuss-gnuradio-bounces+ben.alex=outlook@gnu.org> 
on behalf of Marcus Müller <marcus.muel...@ettus.com>
Sent: Friday, November 4, 2016 3:52:18 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( 
Delay locked loop for the two-clock problem)

Hi Ben,

Ok, I'm not 100% sure I'm following you here:

"Broadcast Receiver Audio Synchronization w.r.t Transmitter Clock"

is of course what you'll need to do, mathematically, anyway, and any
reasonable receiver has some kind of timing recovery (sync)
functionality that does that, in order to be able at all to extract
symbols from the signal correctly.

So, in hardware, this is a bit easier, because your receiver can define
the clock of your Audio device. In other words, there can be no
underflows/overflows, because you make your audio hardware work at a
rate derived from the symbol rate.

With PC hardware, that possibility doesn't exist: You can't tell your
sound card to run with a specific physical clock - it has its own,
independent oscillator, which you can't influence.

So, no, there's no GNU Radio blocks to influence your Audio hardware's
clock, because that is impossible.

However, you're asking about resampling: Well, resamplers do exist :) !
We've got a totally different problem, though: To resample properly,
you'd need to know (or better: estimate) the clock error. For audio rate
systems, Fons has a proposed architecture that looks promising and is
already implemented within the Jack Audio architecture, as far as I can
tell.

Seeing that it works in Jack for audio resampling there, that's the way
I'd go: Use Jack. In fact, maybe it's relatively easy to get this
running. Problem is that if I understood Fons correctly (he seemed a bit
upset about that at the time), the Jack sink is currently broken, and he
seems to be the only one who touched that in a while, so no-one fixed that.

Now, most Linux distros these days use Pulse Audio anyway, and use that
as an ALSA backend

GNU Radio Audio sink (libalsa) --> "default" ALSA device (loopback) -->
Pulseaudio (using libalsa) --> actual audio hardware

For Pulseaudio, a Jack backend exists, so you could configure your Pulse
audio to do

Audio Sink -> "default" ALSA device -> Pulseaudio -> Jack -> resampling
incl. DLL -> ...

Notice that I'm absolutely no expert in Pulseaudio, Jack, or ALSA
configuration, so this will be quite some trial and error, if it doesn't
work right away.

Best regards,
Marcus

On 04.11.2016 10:40, Benny Alexandar wrote:
> Hi,
>
> Broadcast Receiver Audio Synchronization w.r.t Transmitter Clock
>
> This can be applied to broadcast receiver where, for broadcast digital raido 
> receiver the audio output buffers will undergo buffer overflow or underflow 
> if the audio clock is not adjusted to the transmitter clock drift.
> This needs resampling of audio at the receiver side based on the drift in 
> transmitter clock or other drifts due to crystal inaccuracies in receiver.
> In Gnuradio any blocks available to introduce transmitter drift of 
> transmitter ?
>
> -ben
>
>
>
>
>
> ___
> 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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-drm reconfiguration & Channel simulations

[Benny Alexandar]

Hi,


I was able to use the gr-drm to transmit using USRP and receive it  on DRM 
receiver.  However when tried to change RM to mode A, it fails to transmit. I'm 
using  GNU Radio Companion 3.7.10.1.


I would like to experiment more on gr-drm, like DRM transmission 
reconfiguration.  DRM standard supports  two types of reconfiguration: a 
service reconfiguration and a channel reconfiguration. This can be applied on 
the fly with or without audio interruption. I guess gr-drm doesn't support 
these.


Can GNU Radio support on the fly changes to a block ?  How can a block be 
created to cycle through a set of values ? My aim is to automate the 
transmission by chnaging the parameters randomly.



I also like to add some channel simulations, like AWGN and Rayleigh channels o 
DRM transmission in gr-drm. I checked in GNU radio some blocks exist for 
Channel models which can be plugged in before USRP sink block. Has any body 
done any channel simulations on DRM transmission ?


-ben
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Benny Alexandar]

Hi,

Broadcast Receiver Audio Synchronization w.r.t Transmitter Clock

This can be applied to broadcast receiver where, for broadcast digital raido 
receiver the audio output buffers will undergo buffer overflow or underflow if 
the audio clock is not adjusted to the transmitter clock drift.
This needs resampling of audio at the receiver side based on the drift in 
transmitter clock or other drifts due to crystal inaccuracies in receiver.
In Gnuradio any blocks available to introduce transmitter drift of transmitter ?

-ben





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Not able to build GNU Radio (git checkout v3.7.10.1)

[Benny Alexandar]

Hi Marcus,


No luck, I removed complete folder and uninstalled all previous installations by

$ sudo apt-get purge --auto-remove uhd-host

and installed uhd & gnuradio from source. uhd completed successfully, but 
gnuradio showing same errors.


How to resolve it ?

-ben




From: Marcus Müller <marcus.muel...@ettus.com>
Sent: Sunday, October 30, 2016 8:41:44 PM
To: Benny Alexandar; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Not able to build GNU Radio (git checkout 
v3.7.10.1)


So, you want to make sure you *don't* install uhd-host via apt-get, then do the 
UHD source build and installation, and then do the GNU Radio source build and 
installation.

Best regards,

Marcus

On 10/30/2016 04:07 PM, Benny Alexandar wrote:

Hi Marcus,

I installed uhd from source and is ( git checkout release_003_010_000_000),  
from this link

https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux<https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>


Can i uninstall uhd completely, by the below command



sudo apt-get purge --auto-remove uhd-host

Again, fresh installation should I first install uhd followed by gnuradio ?

-ben


From: Marcus Müller <marcus.muel...@ettus.com><mailto:marcus.muel...@ettus.com>
Sent: Sunday, October 30, 2016 8:01:19 PM
To: Benny Alexandar; discuss-gnuradio@gnu.org<mailto:discuss-gnuradio@gnu.org>
Subject: Re: [Discuss-gnuradio] Not able to build GNU Radio (git checkout 
v3.7.10.1)

Hi Ben,
This is very symptomatic of a system with conflicting installs of a library, in 
your case UHD.

Uninstall all UHDs that you have (check by searching for 
libuhd.so<http://libuhd.so> and multi_usrp.* globally) and reinstall only that 
UHD you want. If that is not the UHD that came with your Linux distro, make 
sure you don't accidentally reinstall it, e.g. by installing something that 
depends on it.

Best regards,
Marcus

Am 30. Oktober 2016 15:22:22 MEZ, schrieb Benny Alexandar 
<ben.a...@outlook.com><mailto:ben.a...@outlook.com>:

Hi,


I get this following error while building GNU Radio 3.7.10.1. Please find the 
below errors


-


[ 86%] Built target uhd_swig_gr_uhd_swig_5e3ce
Scanning dependencies of target _uhd_swig
[ 86%] Building CXX object 
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function ‘PyObject* _wrap_dboard_iface_set_gpio_debug(PyObject*, PyObject*, 
PyObject*)’:
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:26696:15:
 error: ‘class uhd::usrp::dboard_iface’ has no member named ‘set_gpio_debug’
   (arg1)->set_gpio_debug(arg2,arg3);
   ^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function ‘PyObject* _wrap_dboard_iface_sptr_set_gpio_debug(PyObject*, 
PyObject*, PyObject*)’:
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:27979:16:
 error: ‘class uhd::usrp::dboard_iface’ has no member named ‘set_gpio_debug’
   (*arg1)->set_gpio_debug(arg2,arg3);
^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function ‘void init_uhd_swig()’:
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48039:91:
 error: ‘ATR_REG_IDLE’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_IDLE",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_IDLE)));

   ^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48040:94:
 error: ‘ATR_REG_TX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_TX_ONLY",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_TX_ONLY)));

  ^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48041:94:
 error: ‘ATR_REG_RX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_RX_ONLY",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_RX_ONLY)));

  ^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48042:98:
 error: ‘ATR_REG_FULL_DUPLEX’ is not a member of ‘uhd::usrp::dboard_iface’
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_FULL_DUPLEX",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_FULL_DUPLEX)));
   

Re: [Discuss-gnuradio] Not able to build GNU Radio (git checkout v3.7.10.1)

[Benny Alexandar]

Hi Marcus,

I installed uhd from source and is ( git checkout release_003_010_000_000),  
from this link

https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux<https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_%28UHD_and_GNU_Radio%29_on_Linux>


Can i uninstall uhd completely, by the below command



sudo apt-get purge --auto-remove uhd-host

Again, fresh installation should I first install uhd followed by gnuradio ?

-ben



From: Marcus Müller <marcus.muel...@ettus.com>
Sent: Sunday, October 30, 2016 8:01:19 PM
To: Benny Alexandar; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Not able to build GNU Radio (git checkout 
v3.7.10.1)

Hi Ben,
This is very symptomatic of a system with conflicting installs of a library, in 
your case UHD.

Uninstall all UHDs that you have (check by searching for 
libuhd.so<http://libuhd.so> and multi_usrp.* globally) and reinstall only that 
UHD you want. If that is not the UHD that came with your Linux distro, make 
sure you don't accidentally reinstall it, e.g. by installing something that 
depends on it.

Best regards,
Marcus

Am 30. Oktober 2016 15:22:22 MEZ, schrieb Benny Alexandar 
<ben.a...@outlook.com>:

Hi,


I get this following error while building GNU Radio 3.7.10.1. Please find the 
below errors


-


[ 86%] Built target uhd_swig_gr_uhd_swig_5e3ce
Scanning dependencies of target _uhd_swig
[ 86%] Building CXX object 
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function 'PyObject* _wrap_dboard_iface_set_gpio_debug(PyObject*, PyObject*, 
PyObject*)':
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:26696:15:
 error: 'class uhd::usrp::dboard_iface' has no member named 'set_gpio_debug'
   (arg1)->set_gpio_debug(arg2,arg3);
   ^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function 'PyObject* _wrap_dboard_iface_sptr_set_gpio_debug(PyObject*, 
PyObject*, PyObject*)':
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:27979:16:
 error: 'class uhd::usrp::dboard_iface' has no member named 'set_gpio_debug'
   (*arg1)->set_gpio_debug(arg2,arg3);
^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function 'void init_uhd_swig()':
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48039:91:
 error: 'ATR_REG_IDLE' is not a member of 'uhd::usrp::dboard_iface'
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_IDLE",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_IDLE)));

   ^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48040:94:
 error: 'ATR_REG_TX_ONLY' is not a member of 'uhd::usrp::dboard_iface'
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_TX_ONLY",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_TX_ONLY)));

  ^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48041:94:
 error: 'ATR_REG_RX_ONLY' is not a member of 'uhd::usrp::dboard_iface'
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_RX_ONLY",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_RX_ONLY)));

  ^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48042:98:
 error: 'ATR_REG_FULL_DUPLEX' is not a member of 'uhd::usrp::dboard_iface'
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_FULL_DUPLEX",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_FULL_DUPLEX)));

  ^
make[2]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] 
Error 1
make[1]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all] Error 2
make: *** [all] Error 2






Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Not able to build GNU Radio (git checkout v3.7.10.1)

[Benny Alexandar]

Hi,


I get this following error while building GNU Radio 3.7.10.1. Please find the 
below errors


-


[ 86%] Built target uhd_swig_gr_uhd_swig_5e3ce
Scanning dependencies of target _uhd_swig
[ 86%] Building CXX object 
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function 'PyObject* _wrap_dboard_iface_set_gpio_debug(PyObject*, PyObject*, 
PyObject*)':
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:26696:15:
 error: 'class uhd::usrp::dboard_iface' has no member named 'set_gpio_debug'
   (arg1)->set_gpio_debug(arg2,arg3);
   ^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function 'PyObject* _wrap_dboard_iface_sptr_set_gpio_debug(PyObject*, 
PyObject*, PyObject*)':
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:27979:16:
 error: 'class uhd::usrp::dboard_iface' has no member named 'set_gpio_debug'
   (*arg1)->set_gpio_debug(arg2,arg3);
^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: 
In function 'void init_uhd_swig()':
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48039:91:
 error: 'ATR_REG_IDLE' is not a member of 'uhd::usrp::dboard_iface'
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_IDLE",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_IDLE)));

   ^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48040:94:
 error: 'ATR_REG_TX_ONLY' is not a member of 'uhd::usrp::dboard_iface'
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_TX_ONLY",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_TX_ONLY)));

  ^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48041:94:
 error: 'ATR_REG_RX_ONLY' is not a member of 'uhd::usrp::dboard_iface'
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_RX_ONLY",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_RX_ONLY)));

  ^
/home/ben/workarea-gnuradio/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:48042:98:
 error: 'ATR_REG_FULL_DUPLEX' is not a member of 'uhd::usrp::dboard_iface'
   SWIG_Python_SetConstant(d, 
"dboard_iface_ATR_REG_FULL_DUPLEX",SWIG_From_int(static_cast< int 
>(uhd::usrp::dboard_iface::ATR_REG_FULL_DUPLEX)));

  ^
make[2]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] 
Error 1
make[1]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all] Error 2
make: *** [all] Error 2



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio