Re: [Discuss-gnuradio] Delay block controlled by input

[Carlos Alberto Ruiz Naranjo]

OK !! Thank you very much for the tips. Next week I will use it in my PC of
the lab. ;)

The delay is in the data, not in the modulated signal. And I insert the
average between the previous and the next sample.

Greetings

2014-10-08 14:53 GMT+02:00 Marcus Müller :

> Hi,
>
> On 08.10.2014 14:38, Carlos Alberto Ruiz Naranjo wrote:
> > Delay Block is controlled by Satellite Orbit and Satellite Orbit by
> > "simulated clock". The output of Satellite Orbit is the delay (samples).
> > Can I know the nitems_read of Delay Block from other block (Satellite
> > Orbit)?
> Yes. It's a public function, as you can see in the documentation I linked.
> >
> > Maybe a solution is to introduce Orbit Satellite in Delay block, but this
> > is really inefficient to do tests.
> Good point, but you should be able to test your "calculate transmission
> delay from an integer" functionality externally; also, there's no reason
> to have something like a class "delay_calculator", with methods you call
> from your modified delay block. You can test that very easily isolated.
> >  And a problem if I want to change the
> > Delay block for your solution (FFT).
> Well, yes, if you change approaches, the old approach will no longer
> apply. That's a design decision you'll have to make.
>
> >
> > Really the delay is in the non-modulated signal.
> I don't understand this sentence, sorry.
>
> Greetings,
> Marcus
>
> >
> >
> >
> > 2014-10-08 13:43 GMT+02:00 Jeff Long :
> >
> >> If you're comparing real time (system clock) to your sample stream,
> you'll
> >> get jitter, not drift, using a throttle. Throttle maintains a sample
> rate
> >> over time, but operates on blocks, and also is running under a
> non-realtime
> >> operating system.
> >>
> >> If you're talking about drift between the clock on your receiver and the
> >> real world, that's normal and you have to find ways to deal with it.
> >>
> >> - Jeff
> >>
> >> On 10/08/2014 07:33 AM, Carlos Alberto Ruiz Naranjo wrote:
> >>
> >>> Yes, it is not a real time clock. This "clock" tracks the current time
> >>> of the signal in GNURadio.clock2 and clock1 have a drift because the
> >>> number of counted samples are different.
> >>>
> >>> For example, if it pass 1023 samples the delay block is entering
> the
> >>> delay in signal time = 1 second.
> >>> 1 second in the real world (later I replay the signal with a USRP).
> >>>
> >>> 2014-10-08 13:18 GMT+02:00 Martin Braun  >>> >:
> >>>
> >>> If you don't have hardware involved, you have no 'clock'. And as
> such,
> >>> it can't drift.
> >>>
> >>> M
> >>>
> >>> On 10/08/2014 12:29 PM, Carlos Alberto Ruiz Naranjo wrote:
> >>> > Sorry, I have explained bad: S
> >>> > I have the signal saved in a file and 1023 samples are one
> >>> second
> >>> > (in the real world).
> >>> >
> >>> > In the first graph I have two clocks (counters samples). When
> >>> passing
> >>> > 102300 samples it increase0.01 seconds.
> >>>  > In the first watchthis time controls the position of the
> >>> satellite and
> >>>  > hisdelay in this time. It allows to know what signal time is
> >>> passing in
> >>> > the delay block.
> >>> >
> >>> >
> >>> > But I have a problem: clock 2 (a test clock) and clock 1 haven't
> the
> >>> > same time; it has a drift.
> >>> >
> >>> >
> >>> > Then, I must use clock 2 (
> >>> > count the samples in the delay block output, not input). But it
> >>> creates
> >>> > a loop.
> >>> >
> >>> >
> >>> >
> >>> > 2014-10-08 12:07 GMT+02:00 Marcus Müller <
> marcus.muel...@ettus.com
> >>> 
> >>>  >  >> :
> >>> >
> >>> > Hello Carlos,
> >>> > On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:
> >>> > > I generate the signal from a file (1023 samples/s) to a
> >>> file. My
> >>> > > sampling clock drifts significantly :S
> >>> > No. Unless I misunderstood you, you have a big misconception:
> >>> > "sampling clock" is *not* the rate at which your samples pass
> >>> through
> >>> > your processing chain (ie. GNU Radio). It is the time base at
> >>> which they
> >>> > are measured, or simulated to, mathematically.
> >>> > The device/software that actually captures the samples and
> >>> saves them
> >>> > has a fixed clock. If that clock changes too much a)
> compensate
> >>> that in
> >>> > software, if possible or b) get a better device.
> >>> > This is digital signal processing. Real world time has *no*
> >>> meaning
> >>> > here, everything is measured relative to the interval between
> >>> two
> >>> > sampling times. You can process the signal as fast or slow as
> >>> you want
> >>> > to (as long as that doesn't lead to things like overflows),
> and
> >>> nothing
> >>> > i

Re: [Discuss-gnuradio] Delay block controlled by input

[Carlos Alberto Ruiz Naranjo]

And a question. In:

uint64_t

gr::block::nitems_read ( unsigned int  *which_input*)

How I know wich_input?

2014-10-08 15:08 GMT+02:00 Carlos Alberto Ruiz Naranjo <
carlosruiznara...@gmail.com>:

> OK !! Thank you very much for the tips. Next week I will use it in my PC
> of the lab. ;)
>
> The delay is in the data, not in the modulated signal. And I insert the
> average between the previous and the next sample.
>
> Greetings
>
> 2014-10-08 14:53 GMT+02:00 Marcus Müller :
>
>> Hi,
>>
>> On 08.10.2014 14:38, Carlos Alberto Ruiz Naranjo wrote:
>> > Delay Block is controlled by Satellite Orbit and Satellite Orbit by
>> > "simulated clock". The output of Satellite Orbit is the delay (samples).
>> > Can I know the nitems_read of Delay Block from other block (Satellite
>> > Orbit)?
>> Yes. It's a public function, as you can see in the documentation I linked.
>> >
>> > Maybe a solution is to introduce Orbit Satellite in Delay block, but
>> this
>> > is really inefficient to do tests.
>> Good point, but you should be able to test your "calculate transmission
>> delay from an integer" functionality externally; also, there's no reason
>> to have something like a class "delay_calculator", with methods you call
>> from your modified delay block. You can test that very easily isolated.
>> >  And a problem if I want to change the
>> > Delay block for your solution (FFT).
>> Well, yes, if you change approaches, the old approach will no longer
>> apply. That's a design decision you'll have to make.
>>
>> >
>> > Really the delay is in the non-modulated signal.
>> I don't understand this sentence, sorry.
>>
>> Greetings,
>> Marcus
>>
>> >
>> >
>> >
>> > 2014-10-08 13:43 GMT+02:00 Jeff Long :
>> >
>> >> If you're comparing real time (system clock) to your sample stream,
>> you'll
>> >> get jitter, not drift, using a throttle. Throttle maintains a sample
>> rate
>> >> over time, but operates on blocks, and also is running under a
>> non-realtime
>> >> operating system.
>> >>
>> >> If you're talking about drift between the clock on your receiver and
>> the
>> >> real world, that's normal and you have to find ways to deal with it.
>> >>
>> >> - Jeff
>> >>
>> >> On 10/08/2014 07:33 AM, Carlos Alberto Ruiz Naranjo wrote:
>> >>
>> >>> Yes, it is not a real time clock. This "clock" tracks the current time
>> >>> of the signal in GNURadio.clock2 and clock1 have a drift because the
>> >>> number of counted samples are different.
>> >>>
>> >>> For example, if it pass 1023 samples the delay block is entering
>> the
>> >>> delay in signal time = 1 second.
>> >>> 1 second in the real world (later I replay the signal with a USRP).
>> >>>
>> >>> 2014-10-08 13:18 GMT+02:00 Martin Braun > >>> >:
>> >>>
>> >>> If you don't have hardware involved, you have no 'clock'. And as
>> such,
>> >>> it can't drift.
>> >>>
>> >>> M
>> >>>
>> >>> On 10/08/2014 12:29 PM, Carlos Alberto Ruiz Naranjo wrote:
>> >>> > Sorry, I have explained bad: S
>> >>> > I have the signal saved in a file and 1023 samples are one
>> >>> second
>> >>> > (in the real world).
>> >>> >
>> >>> > In the first graph I have two clocks (counters samples). When
>> >>> passing
>> >>> > 102300 samples it increase0.01 seconds.
>> >>>  > In the first watchthis time controls the position of the
>> >>> satellite and
>> >>>  > hisdelay in this time. It allows to know what signal time is
>> >>> passing in
>> >>> > the delay block.
>> >>> >
>> >>> >
>> >>> > But I have a problem: clock 2 (a test clock) and clock 1
>> haven't the
>> >>> > same time; it has a drift.
>> >>> >
>> >>> >
>> >>> > Then, I must use clock 2 (
>> >>> > count the samples in the delay block output, not input). But it
>> >>> creates
>> >>> > a loop.
>> >>> >
>> >>> >
>> >>> >
>> >>> > 2014-10-08 12:07 GMT+02:00 Marcus Müller <
>> marcus.muel...@ettus.com
>> >>> 
>> >>>  >  marcus.muel...@ettus.com
>> >> :
>> >>> >
>> >>> > Hello Carlos,
>> >>> > On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:
>> >>> > > I generate the signal from a file (1023 samples/s) to
>> a
>> >>> file. My
>> >>> > > sampling clock drifts significantly :S
>> >>> > No. Unless I misunderstood you, you have a big
>> misconception:
>> >>> > "sampling clock" is *not* the rate at which your samples
>> pass
>> >>> through
>> >>> > your processing chain (ie. GNU Radio). It is the time base
>> at
>> >>> which they
>> >>> > are measured, or simulated to, mathematically.
>> >>> > The device/software that actually captures the samples and
>> >>> saves them
>> >>> > has a fixed clock. If that clock changes too much a)
>> compensate
>> >>> that in
>> >>> > so

Re: [Discuss-gnuradio] GRC 3.6 / 802.11 a/g test signal

[Ernest Szczepaniak]

Ok fixed. Now giving correct results :) Ill try with your frame once more and
hit you up later.

Thanks for your amazing feedback Bastian. 

Best, 

Ernest



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50690.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Using volk

[Tom Rondeau]

On Tue, Oct 7, 2014 at 3:49 PM, Mostafa Alizadeh 
wrote:

> Hello all,
>
> I wondered about volk. I want it to compute mean to peak value of a
> complex array. How could I do this?
> Besides, I really need to know is there any example of using volk? The
> code itself, doesn't reflect input and output parameters explicitly.
>
> Best,
> Mostafa
>


Marcus gave you a far more complete answer. Just a few words here. First,
VOLK is used all over the place in GNU Radio. So look for blocks that use
VOLK. Second, the name scheme of VOLK is incredibly explicit as to the
input and output parameters. See the manual page and wiki page describing
VOLK:

http://gnuradio.org/doc/doxygen/volk_guide.html
http://gnuradio.org/redmine/projects/gnuradio/wiki/VOLK

There also my talk on VOLK recorded for the IEEE Signal Processing Society:

http://www.trondeau.com/blog/2013/6/12/nearly-50-minutes-of-volk.html

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

Re: [Discuss-gnuradio] Delay block controlled by input

[Carlos Alberto Ruiz Naranjo]

Really the question is:

How can I call
gr::block::nitems_read (unsigned int *which_input*)
from a block to know the nitems_read of another block?

2014-10-08 15:10 GMT+02:00 Carlos Alberto Ruiz Naranjo <
carlosruiznara...@gmail.com>:

> And a question. In:
>
> uint64_t
> 
> gr::block::nitems_read ( unsigned int  *which_input*)
>
> How I know wich_input?
>
> 2014-10-08 15:08 GMT+02:00 Carlos Alberto Ruiz Naranjo <
> carlosruiznara...@gmail.com>:
>
>> OK !! Thank you very much for the tips. Next week I will use it in my PC
>> of the lab. ;)
>>
>> The delay is in the data, not in the modulated signal. And I insert the
>> average between the previous and the next sample.
>>
>> Greetings
>>
>> 2014-10-08 14:53 GMT+02:00 Marcus Müller :
>>
>>> Hi,
>>>
>>> On 08.10.2014 14:38, Carlos Alberto Ruiz Naranjo wrote:
>>> > Delay Block is controlled by Satellite Orbit and Satellite Orbit by
>>> > "simulated clock". The output of Satellite Orbit is the delay
>>> (samples).
>>> > Can I know the nitems_read of Delay Block from other block (Satellite
>>> > Orbit)?
>>> Yes. It's a public function, as you can see in the documentation I
>>> linked.
>>> >
>>> > Maybe a solution is to introduce Orbit Satellite in Delay block, but
>>> this
>>> > is really inefficient to do tests.
>>> Good point, but you should be able to test your "calculate transmission
>>> delay from an integer" functionality externally; also, there's no reason
>>> to have something like a class "delay_calculator", with methods you call
>>> from your modified delay block. You can test that very easily isolated.
>>> >  And a problem if I want to change the
>>> > Delay block for your solution (FFT).
>>> Well, yes, if you change approaches, the old approach will no longer
>>> apply. That's a design decision you'll have to make.
>>>
>>> >
>>> > Really the delay is in the non-modulated signal.
>>> I don't understand this sentence, sorry.
>>>
>>> Greetings,
>>> Marcus
>>>
>>> >
>>> >
>>> >
>>> > 2014-10-08 13:43 GMT+02:00 Jeff Long :
>>> >
>>> >> If you're comparing real time (system clock) to your sample stream,
>>> you'll
>>> >> get jitter, not drift, using a throttle. Throttle maintains a sample
>>> rate
>>> >> over time, but operates on blocks, and also is running under a
>>> non-realtime
>>> >> operating system.
>>> >>
>>> >> If you're talking about drift between the clock on your receiver and
>>> the
>>> >> real world, that's normal and you have to find ways to deal with it.
>>> >>
>>> >> - Jeff
>>> >>
>>> >> On 10/08/2014 07:33 AM, Carlos Alberto Ruiz Naranjo wrote:
>>> >>
>>> >>> Yes, it is not a real time clock. This "clock" tracks the current
>>> time
>>> >>> of the signal in GNURadio.clock2 and clock1 have a drift because the
>>> >>> number of counted samples are different.
>>> >>>
>>> >>> For example, if it pass 1023 samples the delay block is entering
>>> the
>>> >>> delay in signal time = 1 second.
>>> >>> 1 second in the real world (later I replay the signal with a USRP).
>>> >>>
>>> >>> 2014-10-08 13:18 GMT+02:00 Martin Braun >> >>> >:
>>> >>>
>>> >>> If you don't have hardware involved, you have no 'clock'. And as
>>> such,
>>> >>> it can't drift.
>>> >>>
>>> >>> M
>>> >>>
>>> >>> On 10/08/2014 12:29 PM, Carlos Alberto Ruiz Naranjo wrote:
>>> >>> > Sorry, I have explained bad: S
>>> >>> > I have the signal saved in a file and 1023 samples are one
>>> >>> second
>>> >>> > (in the real world).
>>> >>> >
>>> >>> > In the first graph I have two clocks (counters samples). When
>>> >>> passing
>>> >>> > 102300 samples it increase0.01 seconds.
>>> >>>  > In the first watchthis time controls the position of the
>>> >>> satellite and
>>> >>>  > hisdelay in this time. It allows to know what signal time is
>>> >>> passing in
>>> >>> > the delay block.
>>> >>> >
>>> >>> >
>>> >>> > But I have a problem: clock 2 (a test clock) and clock 1
>>> haven't the
>>> >>> > same time; it has a drift.
>>> >>> >
>>> >>> >
>>> >>> > Then, I must use clock 2 (
>>> >>> > count the samples in the delay block output, not input). But it
>>> >>> creates
>>> >>> > a loop.
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > 2014-10-08 12:07 GMT+02:00 Marcus Müller <
>>> marcus.muel...@ettus.com
>>> >>> 
>>> >>>  > > marcus.muel...@ettus.com
>>> >> :
>>> >>> >
>>> >>> > Hello Carlos,
>>> >>> > On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:
>>> >>> > > I generate the signal from a file (1023 samples/s)
>>> to a
>>> >>> file. My
>>> >>> > > sampling clock drifts significantly :S
>>> >>> > No. Unless I misunderstood you, you have a big
>>> misconception:
>>> >>> > "sampling clock" is *not* the rate at which your samples
>>> pass
>>>

Re: [Discuss-gnuradio] Delay block controlled by input

[Marcus Müller]

You call
another_block->nitems_read(number)
with number being the number of the input stream (ie. 0 for the first, 1
for the second and so on).
Remember, GNU Radio is C++, and blocks are built as classes.

Greetings,
Marcus

On 08.10.2014 15:24, Carlos Alberto Ruiz Naranjo wrote:
> Really the question is:
>
> How can I call
> gr::block::nitems_read (unsigned int *which_input*)
> from a block to know the nitems_read of another block?
>
> 2014-10-08 15:10 GMT+02:00 Carlos Alberto Ruiz Naranjo <
> carlosruiznara...@gmail.com>:
>
>> And a question. In:
>>
>> uint64_t
>> 
>> gr::block::nitems_read ( unsigned int  *which_input*)
>>
>> How I know wich_input?
>>
>> 2014-10-08 15:08 GMT+02:00 Carlos Alberto Ruiz Naranjo <
>> carlosruiznara...@gmail.com>:
>>
>>> OK !! Thank you very much for the tips. Next week I will use it in my PC
>>> of the lab. ;)
>>>
>>> The delay is in the data, not in the modulated signal. And I insert the
>>> average between the previous and the next sample.
>>>
>>> Greetings
>>>
>>> 2014-10-08 14:53 GMT+02:00 Marcus Müller :
>>>
 Hi,

 On 08.10.2014 14:38, Carlos Alberto Ruiz Naranjo wrote:
> Delay Block is controlled by Satellite Orbit and Satellite Orbit by
> "simulated clock". The output of Satellite Orbit is the delay
 (samples).
> Can I know the nitems_read of Delay Block from other block (Satellite
> Orbit)?
 Yes. It's a public function, as you can see in the documentation I
 linked.
> Maybe a solution is to introduce Orbit Satellite in Delay block, but
 this
> is really inefficient to do tests.
 Good point, but you should be able to test your "calculate transmission
 delay from an integer" functionality externally; also, there's no reason
 to have something like a class "delay_calculator", with methods you call
 from your modified delay block. You can test that very easily isolated.
>  And a problem if I want to change the
> Delay block for your solution (FFT).
 Well, yes, if you change approaches, the old approach will no longer
 apply. That's a design decision you'll have to make.

> Really the delay is in the non-modulated signal.
 I don't understand this sentence, sorry.

 Greetings,
 Marcus

>
>
> 2014-10-08 13:43 GMT+02:00 Jeff Long :
>
>> If you're comparing real time (system clock) to your sample stream,
 you'll
>> get jitter, not drift, using a throttle. Throttle maintains a sample
 rate
>> over time, but operates on blocks, and also is running under a
 non-realtime
>> operating system.
>>
>> If you're talking about drift between the clock on your receiver and
 the
>> real world, that's normal and you have to find ways to deal with it.
>>
>> - Jeff
>>
>> On 10/08/2014 07:33 AM, Carlos Alberto Ruiz Naranjo wrote:
>>
>>> Yes, it is not a real time clock. This "clock" tracks the current
 time
>>> of the signal in GNURadio.clock2 and clock1 have a drift because the
>>> number of counted samples are different.
>>>
>>> For example, if it pass 1023 samples the delay block is entering
 the
>>> delay in signal time = 1 second.
>>> 1 second in the real world (later I replay the signal with a USRP).
>>>
>>> 2014-10-08 13:18 GMT+02:00 Martin Braun >> >:
>>>
>>> If you don't have hardware involved, you have no 'clock'. And as
 such,
>>> it can't drift.
>>>
>>> M
>>>
>>> On 10/08/2014 12:29 PM, Carlos Alberto Ruiz Naranjo wrote:
>>> > Sorry, I have explained bad: S
>>> > I have the signal saved in a file and 1023 samples are one
>>> second
>>> > (in the real world).
>>> >
>>> > In the first graph I have two clocks (counters samples). When
>>> passing
>>> > 102300 samples it increase0.01 seconds.
>>>  > In the first watchthis time controls the position of the
>>> satellite and
>>>  > hisdelay in this time. It allows to know what signal time is
>>> passing in
>>> > the delay block.
>>> >
>>> >
>>> > But I have a problem: clock 2 (a test clock) and clock 1
 haven't the
>>> > same time; it has a drift.
>>> >
>>> >
>>> > Then, I must use clock 2 (
>>> > count the samples in the delay block output, not input). But it
>>> creates
>>> > a loop.
>>> >
>>> >
>>> >
>>> > 2014-10-08 12:07 GMT+02:00 Marcus Müller <
 marcus.muel...@ettus.com
>>> 
>>>  > >> marcus.muel...@ettus.com
>> :
>>> >
>>> > Hello Carlos,
>>> > On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:
>>>

Re: [Discuss-gnuradio] Delay block controlled by input

[Martin Braun]

On 10/08/2014 03:24 PM, Carlos Alberto Ruiz Naranjo wrote:
> Really the question is:
> 
> How can I call
> gr::block::nitems_read(   unsigned int/which_input/   )   
> 
> from a block to know the nitems_read of another block?

You call 'nitems_read()'?

Not sure you should be calling it from other blocks, though.

Cheers,
M
> 
> 2014-10-08 15:10 GMT+02:00 Carlos Alberto Ruiz Naranjo
> mailto:carlosruiznara...@gmail.com>>:
> 
> And a question. In:
> 
> uint64_t
> 
> 
> gr::block::nitems_read(   unsigned int/which_input/   )   
> 
> 
> How I know wich_input?
> 
> 2014-10-08 15:08 GMT+02:00 Carlos Alberto Ruiz Naranjo
> mailto:carlosruiznara...@gmail.com>>:
> 
> OK !! Thank you very much for the tips. Next week I will use it
> in my PC of the lab. ;)
> 
> The delay is in the data, not in the modulated signal. And I
> insert the average between the previous and the next sample.
> 
> Greetings
> 
> 2014-10-08 14:53 GMT+02:00 Marcus Müller
> mailto:marcus.muel...@ettus.com>>:
> 
> Hi,
> 
> On 08.10.2014 14:38, Carlos Alberto Ruiz Naranjo wrote:
> > Delay Block is controlled by Satellite Orbit and Satellite 
> Orbit by
> > "simulated clock". The output of Satellite Orbit is the delay 
> (samples).
> > Can I know the nitems_read of Delay Block from other block 
> (Satellite
> > Orbit)?
> Yes. It's a public function, as you can see in the
> documentation I linked.
> >
> > Maybe a solution is to introduce Orbit Satellite in Delay 
> block, but this
> > is really inefficient to do tests.
> Good point, but you should be able to test your "calculate
> transmission
> delay from an integer" functionality externally; also,
> there's no reason
> to have something like a class "delay_calculator", with
> methods you call
> from your modified delay block. You can test that very
> easily isolated.
> >  And a problem if I want to change the
> > Delay block for your solution (FFT).
> Well, yes, if you change approaches, the old approach will
> no longer
> apply. That's a design decision you'll have to make.
> 
> >
> > Really the delay is in the non-modulated signal.
> I don't understand this sentence, sorry.
> 
> Greetings,
> Marcus
> 
> >
> >
> >
> > 2014-10-08 13:43 GMT+02:00 Jeff Long  >:
> >
> >> If you're comparing real time (system clock) to your
> sample stream, you'll
> >> get jitter, not drift, using a throttle. Throttle
> maintains a sample rate
> >> over time, but operates on blocks, and also is running
> under a non-realtime
> >> operating system.
> >>
> >> If you're talking about drift between the clock on your
> receiver and the
> >> real world, that's normal and you have to find ways to
> deal with it.
> >>
> >> - Jeff
> >>
> >> On 10/08/2014 07:33 AM, Carlos Alberto Ruiz Naranjo wrote:
> >>
> >>> Yes, it is not a real time clock. This "clock" tracks
> the current time
> >>> of the signal in GNURadio.clock2 and clock1 have a drift
> because the
> >>> number of counted samples are different.
> >>>
> >>> For example, if it pass 1023 samples the delay block
> is entering the
> >>> delay in signal time = 1 second.
> >>> 1 second in the real world (later I replay the signal
> with a USRP).
> >>>
> >>> 2014-10-08 13:18 GMT+02:00 Martin Braun
> mailto:martin.br...@ettus.com>
> >>>  >>:
> >>>
> >>> If you don't have hardware involved, you have no
> 'clock'. And as such,
> >>> it can't drift.
> >>>
> >>> M
> >>>
> >>> On 10/08/2014 12:29 PM, Carlos Alberto Ruiz Naranjo
> wrote:
> >>> > Sorry, I have explained bad: S
> >>> > I have the signal saved in a file and 1023
> samples are one
> >>> second
> >>> > (in the real world).
> >>> >
> >>> > In the first graph I have two clocks (counters
> sam

[Discuss-gnuradio] How to access UHD from within my own OOT block?

[Boschma, J.J. (Jeroen)]

Dear all,

In the Companion GUI I use the UHD source- and sink-blocks, together with my 
own OOT blocks. Now I want to control the UHD blocks from within my own blocks, 
for example changing the center frequency. So in my own block I would like to 
write something like:

usrp->set_center_freq(whatever);

I there an easy interface/API available to do this? Or do I have to download 
the gr-uhd, modify it (maybe add a method to get a pointer to the USRP out of 
it?) and rebuild? Unfortunately I just could not find a starting point yet.

Regards,

  Jeroen



Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet 
de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u 
verzocht dat aan de afzender te melden en het bericht te verwijderen. TNO 
aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze 
waarop u deze gebruikt en voor schade, van welke aard ook, die verband houdt 
met risico's verbonden aan het elektronisch verzenden van berichten.

 

This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. TNO accepts no liability 
for the content of this e-mail, for the manner in which you use it and for 
damage of any kind resulting from the risks inherent to the electronic 
transmission of messages.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to access UHD from within my own OOT block?

[Marcus Müller]

Hi Jeroen,

the usrp blocks have public methods to do exactly that. It really looks
like what you've proposed :)

Not so long ago, Martin added support for doing things like that by
sending messages or stream tags to the block, too.

As you haven't found a starting point yet: Here's GNU Radio's official
API documentation:
http://gnuradio.org/doc/doxygen/
and the gr-uhd blocks are here:
http://gnuradio.org/doc/doxygen/group__uhd__blk.html
http://gnuradio.org/doc/doxygen/namespacegr_1_1uhd.html

Quite straightforward :)

Greetings,
Marcus

On 08.10.2014 16:01, Boschma, J.J. (Jeroen) wrote:
> Dear all,
>
> In the Companion GUI I use the UHD source- and sink-blocks, together with my 
> own OOT blocks. Now I want to control the UHD blocks from within my own 
> blocks, for example changing the center frequency. So in my own block I would 
> like to write something like:
>
> usrp->set_center_freq(whatever);
>
> I there an easy interface/API available to do this? Or do I have to download 
> the gr-uhd, modify it (maybe add a method to get a pointer to the USRP out of 
> it?) and rebuild? Unfortunately I just could not find a starting point yet.
>
> Regards,
>
>   Jeroen
>
>
>
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet 
> de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt 
> u verzocht dat aan de afzender te melden en het bericht te verwijderen. TNO 
> aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze 
> waarop u deze gebruikt en voor schade, van welke aard ook, die verband houdt 
> met risico's verbonden aan het elektronisch verzenden van berichten.
>
>  
>
> This message may contain information that is not intended for you. If you are 
> not the addressee or if this message was sent to you by mistake, you are 
> requested to inform the sender and delete the message. TNO accepts no 
> liability for the content of this e-mail, for the manner in which you use it 
> and for damage of any kind resulting from the risks inherent to the 
> electronic transmission of messages.
>
>
>
> ___
> 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 access UHD from within my own OOT block?

[Martin Braun]

Regardless of the application, UHD or otherwise, this is not what you
should be doing. Use the message interface for this, it is described on the
gr-uhd manual page.

M
On 8 Oct 2014 16:02, "Boschma, J.J. (Jeroen)"  wrote:

>  Dear all,
>
>
>
> In the Companion GUI I use the UHD source- and sink-blocks, together with
> my own OOT blocks. Now I want to control the UHD blocks from within my own
> blocks, for example changing the center frequency. So in my own block I
> would like to write something like:
>
>
>
> usrp->set_center_freq(whatever);
>
>
>
> I there an easy interface/API available to do this? Or do I have to
> download the gr-uhd, modify it (maybe add a method to get a pointer to the
> USRP out of it?) and rebuild? Unfortunately I just could not find a
> starting point yet.
>
>
>
> Regards,
>
>
>
>   Jeroen
>
>
>
>
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u
> niet de geadresseerde bent of dit bericht abusievelijk aan u is
> toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht
> te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van
> deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke aard
> ook, die verband houdt met risico's verbonden aan het elektronisch
> verzenden van berichten.
>
>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
> ___
> 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] GNURadio Installation with Hydra

[Zhang, Jiayi]

Dear all,

I'm a beginner of GNURadio but I'm familiar with some basis of Linux when I
use C++ & IT++. Currently I'm trying to test the Hydra-0.4 package for
evaluation under the last ubuntu ver 14.04.1 32bit. During the installation
of gnuradio-3.2.2, there is an error which I cannot find the solution on
internet.

gnuradio-3.2.2$ ./bootstrap && ./configure --prefix=$GR
…
checking for boost >= 1.35... yes
checking whether the boost::thread includes are available... yes
configure: error: Could not link against libboost_thread!

‘libboost-all-dev’ has already installed, including ‘libboost-thread-dev’,
I tried both version 1.54 and 1.55 of libboost. I've also searched the
error message in Google, even after I installed the 'build-essential'
package, the error remains the same.

I will be much appreciated if any of you have such an experience and would
feedback some solutions.

Regards,
Jiayi (Vincent)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNURadio Installation with Hydra

[Marcus Müller]

Hello Jiayi,

3.2.2 is *very* ancient. In fact, it's older than my involvement with
GNU Radio, and I think it will be very hard to find someone how's still
using it, so asking for experience, I'm afraid, is not going to yield a
lot of responses in 2014.
Therefore, it will be nearly impossible to recreate an environment with
all the GNU Radio dependencies that match the needs of GNU Radio 3.2.2.

I'm not familiar with Hydra itself; but if it uses GR 3.2.2 you won't be
able to use it with modern USRPs, you won't have much fun developing new
applications for it, and in total it might be wise to look if you can
either find a suitable substitute or port it to a modern GNU Radio.

However, I'm optimistic that someone else here has used Hydra, and maybe
he has some more specific hints than I do.

Greetings,
Marcus

On 08.10.2014 16:50, Zhang, Jiayi wrote:
> Dear all,
>
> I'm a beginner of GNURadio but I'm familiar with some basis of Linux when I
> use C++ & IT++. Currently I'm trying to test the Hydra-0.4 package for
> evaluation under the last ubuntu ver 14.04.1 32bit. During the installation
> of gnuradio-3.2.2, there is an error which I cannot find the solution on
> internet.
>
> gnuradio-3.2.2$ ./bootstrap && ./configure --prefix=$GR
> ...
> checking for boost >= 1.35... yes
> checking whether the boost::thread includes are available... yes
> configure: error: Could not link against libboost_thread!
>
> 'libboost-all-dev' has already installed, including 'libboost-thread-dev',
> I tried both version 1.54 and 1.55 of libboost. I've also searched the
> error message in Google, even after I installed the 'build-essential'
> package, the error remains the same.
>
> I will be much appreciated if any of you have such an experience and would
> feedback some solutions.
>
> Regards,
> Jiayi (Vincent)
>
>
>
> ___
> 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] CC encoder definition (variable_cc_encoder_def)

[Tom Rondeau]

On Tue, Oct 7, 2014 at 12:08 PM, David Halls 
wrote:

>
> 
> From: trond...@trondeau.com [trond...@trondeau.com] on behalf of Tom
> Rondeau [t...@trondeau.com]
> Sent: 07 October 2014 16:27
> To: David Halls
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] CC encoder definition
> (variable_cc_encoder_def)
>
> On Tue, Oct 7, 2014 at 10:40 AM, David Halls  > wrote:
> The problem appears to be using  and  in the xml
> files.
>
> Presumably this is a new(ish) additional functionality in GNU Radio, which
> my old version can’t parse?
>
> Yes, those are new in 3.7 (3.7.4, I think but would have to check to
> verify). It's a way of letting us build objects within GRC and use them as
> such in other areas of the flowgraph. So you can define an FEC variable and
> call methods on it, like cc.K() to get the CC's constraint length.
>
> You can probably remove these from the .xml files and lose that
> functionality. It's a nice convenience but not necessary. You can replace
> it by having another variable, say for K, and use that in any place you
> might require it instead of pulling it straight from the CC variable itself.
>
> Tom
>
>
> Thanks Tom, that is a useful piece of functionality indeed. I commented
> out the  and  and have instead
>
> "self.$(id) = $(id) = fec.cc_encoder_make($framebits, $k, $rate,
> $polys, $state_start, $mode, $padding)"
>
> Is that OK? I can also manually create the Encoder Objects variable as
>
> fec.cc_encoder_make(frame_size*8, k, rate, (polys), start_state,
> fec.CC_TERMINATED, padding)
>
> how would I add the parallelism
>
> (fec.cc_encoder_make(frame_size*8, k, rate, (polys), start_state,
> fec.CC_TERMINATED, padding);fec.cc_encoder_make(frame_size*8, k, rate,
> (polys), start_state, fec.CC_TERMINATED, padding))
>
> or similar?
>


Plus or minus syntax, yes, either way should work for you.

The parallelism is just a list, like you've put here or a list of lists if
you're doing multiple levels of parallelism (generally only used with the
BER curve generator example).

Tom




> From: discuss-gnuradio-bounces+david.halls=toshiba-trel@gnu.org
>  [mailto:
> discuss-gnuradio-bounces+david.halls discuss-gnuradio-bounces%2Bdavid.halls>=toshiba-trel@gnu.org toshiba-trel@gnu.org>] On Behalf Of David Halls
> Sent: 07 October 2014 15:21
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] CC encoder definition (variable_cc_encoder_def)
>
> Dear All,
>
> I am trying to get the latest gr-fec code running in an older version of
> GNU Radio. I know this sounds like a terrible idea, and I don’t expect any
> sympathy but there is a reason why we can’t upgrade to the newest GNU
> Radio, due to some legacy issues.
>
> If you are still reading…
>
> I can’t get the CC Encoder Definition block to appear in GNU Radio, we are
> using 3.7.2. I have copied the whole of the gr-fec folder from the latest
> install including the grc folder which contains
> ‘variable_cc_encoder_def_list.xml’. Is there something else fundamentally
> missing from older version of GNU Radio to support this kind of definition
> block?
>
> Thanks!
>
> David
>
> ---
> David Halls Ph.D.
> Research Engineer
> Toshiba Research Europe Limited
> 32 Queen Square, Bristol, BS1 4ND, UK
> Tel: +44 (0) 117 906 0790
>
>
> 
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read, copied
> and used only by the intended recipient. If you are not the intended
> recipient, please destroy this message, delete any copies held on your
> system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web:
> www.toshiba.eu/research/trl
> 
>
>
> 
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> 
>
> 
>
> NOTE: The information in this email and any attachments may be
> confidential and/or legally privileged. This message may be read, copied
> and used only by the intended recipient. If you are not the intended
> recipient, please destroy this message, delete any copies held on your
> system and notify the sender immediately.
>
> Toshiba Research Europe Limited, registered in England and Wales
> (2519556). Registered Office 208 Cambridge Science Park, Milton Road,
> Cambridge CB4 0GZ, England. Web:
> www.toshiba.eu/research/trl

Re: [Discuss-gnuradio] Packet Encoder-Decoder

[Charles Alberton Herdt]

I am seeing the same problem here while running some tests.
Anyone else has any thoughts?

Running gnuradio 3.7.5, installed with the build-gnuradio script on Ubuntu
14.04.

Gnuradio

On Tue, Oct 7, 2014 at 6:18 AM, Thanasis Balafoutis 
wrote:

> Hi,
> In the followning basic setup:
> File Source (Byte) > Packet Encoder (Byte) -> File Sink (byte)
>
> My input file is just a "Hello World" message
> If the Repeat property of my file source is set to "No" the File Sink
> remains empty Why? Do I have buffering issues?
> If I set Repeat="yes" file sink seems to work, But when I insert a Packet
> Decoder:
>
> File Source > Packet Encoder ->Packet Decoder -> File Sink
>
> The output file is empty again!
>
> Thanks
>
> ___
> 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] Packet Encoder-Decoder

[Jeff Long]

Hi Thanasis,

1. The flow you showed could not have worked because Packet Decoder 
takes unpacked bytes. The graph should be:


File Source -> Encoder -> Packed-to-Unpacked -> Decoder -> File Sink

2. The payload length defaults to 512 if you leave it at 0, so a short 
file won't fill a packet.


Encoder:
1 Sample/Symbol, 1 Bit/Symbol, Payload length 1

Packed-to-Unpacked:
1 Bit/Chunk, MSB

That worked for me.

General question for others ... the encoder/decoder are part of GRC and 
haven't had any substantial work in a long time. Is this code meant to 
be used, or should people look at other blocks, or gr-mac?


- Jeff

On 10/08/2014 06:26 PM, Charles Alberton Herdt wrote:

I am seeing the same problem here while running some tests.
Anyone else has any thoughts?

Running gnuradio 3.7.5, installed with the build-gnuradio script on
Ubuntu 14.04.

Gnuradio

On Tue, Oct 7, 2014 at 6:18 AM, Thanasis Balafoutis
mailto:abalafou...@gmail.com>> wrote:

Hi,
In the followning basic setup:
File Source (Byte) > Packet Encoder (Byte) -> File Sink (byte)

My input file is just a "Hello World" message
If the Repeat property of my file source is set to "No" the File
Sink remains empty Why? Do I have buffering issues?
If I set Repeat="yes" file sink seems to work, But when I insert a
Packet Decoder:

File Source > Packet Encoder ->Packet Decoder -> File Sink

The output file is empty again!

Thanks

___
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] Saving PMTs as Python Dictionaries to .Mat File

[Jonathan Fox]

I have a series of collected metadata files. I have taken both the
gr_read_file_metadata.py and parse_file_metadata.py scripts and hacked them
to my own needs. What I would like to do is convert the PMT to python
dictionary (already done in the vanilla files) and save the dicitonary as a
Matlab .mat file format. SciPy has the necessary libraries and functions to
save with the savemat command, the problem is, at least I believe it is the
PMTs are being problematic.

For example I convert all headers to a dictionary and try to save just that
and I get this error:

/usr/lib64/python2.6/site-packages/scipy/io/matlab/mio.py:165:
FutureWarning: Using oned_as default value ('column') This will change to
'row' in future versions
  oned_as=oned_as)
Traceback (most recent call last):
  File "./parser_mat.py", line 71, in 
main(filename, options.savefile, options.detached, options.computer)
  File "./parser_mat.py", line 51, in main
scipy.io.savemat(savefile, dict(info))
  File "/usr/lib64/python2.6/site-packages/scipy/io/matlab/mio.py", line
168, in savemat
MW.put_variables(mdict)
  File "/usr/lib64/python2.6/site-packages/scipy/io/matlab/mio5.py", line
1217, in put_variables
mat_writer.write()
  File "/usr/lib64/python2.6/site-packages/scipy/io/matlab/mio5.py", line
897, in write
self._write_items()
  File "/usr/lib64/python2.6/site-packages/scipy/io/matlab/mio5.py", line
941, in _write_items
MW = MWG.matrix_writer_factory(self.file_stream, el[f])
  File "/usr/lib64/python2.6/site-packages/scipy/io/matlab/mio5.py", line
1094, in matrix_writer_factory
% (arr, type(arr)))
TypeError: Could not convert
_30320b02_p_boost__intrusive_ptrT_pmt__pmt_base_t (type ) to array

The snippet of code to save is this:

scip.io.savemat(savefile, dict(info))

savefile is a string that is a user set arguement. info is the dictionary.

I don't know if anyone on this list has tried to do what I am doing but I
would appreciate any insight on where this is going wrong, especially if
the problem is on my end.

Thanks

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

[Discuss-gnuradio] FEC gnuradio 3.7.6 error

[Hoang Ngo-Khac]

Dear all,
I am checking FEC Extended Encoder/Decoder in gnuradio-3.7.6 and would like to 
embed it in my OFDM transmission. 
First, I run the flowgraph below. It works and I can see how FEC improve the 
results.
  However, when I change some blocks, for example, using BPSK 
Mapper (as below), it throws me the error: 
terminate called after throwing an instance of 'std::invalid_argument'  what(): 
 destination already in use by edge deinterleave0:0->fec_encoder0:0
  
When I modify the flow graph, this error happen regularly even when the new 
inserted block is not connected dirrectly to Encoder or Decoder block.  To make 
FEC work with my OFDM transmission, I need to make the Encoder and Decoder work 
compatibly with my blocks. But as you can see, it stops working with when I 
insert BPSK Mapper to the flow graph, let alone more complicated blocks like 
OFDM Modulation. 
Please help me to figure out the problem and fix it. Any clue would be 
appreciated.
Best,Hoang Ngo 
Hoang Ngo-KhacResearch Assistant - Lab. of Signal and System, FET, UET, Vietnam 
National University-Hanoi (VNU-H)Alternative email:  khachoang1...@gmail.com, 
hoangnk...@vnu.edu.vnMobilephone:  +84.163.682.7874 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Delay block controlled by input

[Carlos Alberto Ruiz Naranjo]

I generate the signal from a file (1023 samples/s) to a file. My
sampling clock drifts significantly :S

- Picture one: Counter Clock 2 is correct but Counter Clock 1 no.
Then I should use the second configuration, but it is not allowed because I
have a loop, right?


​
I'll try the method you say ;)






2014-10-07 14:13 GMT+02:00 Marcus Müller :

>  Ok, you'll have to explain why you'd need throttle, as this is almost
> never the case, especially not when a) working in a simulation or b)
> working with "real" hardware, as that usually enforces a sampling rate.
> If you know the physical sampling rate, counting samples *must* work,
> unless your sampling clock drifts significantly, or you have *really* fast
> moving satellites for which relativity is a concern at such low frequencies.
>
> Anyway, as an advisor told me once, if you want something done
> mathematically right, do it mathematically right (that was on the subject
> on simulating delay for radar targets):
> Transform your signal to frequency domain, multiply it with a complex sine
> of the frequency representing your time shift, and transform it back to
> time domain. This allows you (within numerical precision of the complex
> float and the length of your FFT) to have arbitrary accurate shifts, to
> dynamically update the frequency (depending on how you generate the complex
> sinusoid) and costs only moderately many ressources (OK, at roughly 10MS/s,
> this might still be relevant).
>
> Greetings,
> Marcus
>
> On 07.10.2014 12:48, Carlos Alberto Ruiz Naranjo wrote:
>
> I am having problems with the clock.
> I need to track the real time of the signal. I have tried to get it with a
> sample counter and a throttle (to maintain the rate), but it doesn't work.
> The clock is faster or slower than the current signal time.
>
> Any idea? ;)
>
> 2014-09-23 20:13 GMT+02:00 Tom Rondeau  
> :
>
>
>  On Tue, Sep 23, 2014 at 9:25 AM, Carlos Alberto Ruiz Naranjo 
>  wrote:
>
>
>  - SIGNAL: 1023 samples/s
>
> - CLOCK: Counter that increments +0.001 when passing 10230 samples.
>
> - SATELLITE ORBIT: Calculate the satellite orbit and delay.
>
>
> ​
>
>
>  Ok. My problem with this is that we're trying to get away from using
> streaming data ports for control like this. Changing the state of a block
> should be left to stream tags or messages.
>
> For your application, it might make sense if each data input to the block
> matches to a very quickly-changing delay difference. In that case, though,
> I would suggest that you keep an OOT module with your own implementation of
> the delay block that does this for you.
>
> Tom
>
>
>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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

Re: [Discuss-gnuradio] GRC 3.6 / 802.11 a/g test signal

[Bastian Bloessl]

On 10/07/2014 04:57 PM, Ernest Szczepaniak wrote:

Nope,

Any way to get it? Is it downloadable?

Should be helpfull indeed.



As far as I know it is not downloadable. You would have to extract (copy 
- paste) the data from the pdf.


Bastian


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

Re: [Discuss-gnuradio] Gnuradio DCS Module

[Jeff Long]

On 10/07/2014 07:16 PM, Jeff Long wrote:

Martin,

Some ideas inline ... hope some of this is useful.

On 10/07/2014 03:30 PM, Martin Holst Swende wrote:

Hi list,

I am pretty new to Gnuradio / SDR, experimenting with a HackRF. As a
startup experiment, I wanted to communicate with simple handheld radio
devices (toy radios). These radios used DCS, and in order for my
computer to bypass their squelch, I need to
1) Determine DCS-code
2) Add DCS to my transmissions

Since I didn't find any suitable tools for that (?), I have now
implemented a gnuradio module to decode DCS. The source code is at
bitbucket [1].

I started out by implementing the DCS decoder via a message block in
python. This seemed a bit hacky, so I decided to implement it in C++
instead following the "Out-of-tree modules" tutorial [2]. In the end, I
implemented it as a Stream Tag block. My thought was that it would add
tags to an audio stream, and a UI component somewhere would pick up the
tags and display to the user (needless to say, a DCS-squelch could be
built using the tagged stream).

I now have a few question, both regarding the digital signal processing
in general, and regarding gnuradio.

1. Currently, my block takes digital input. Here [3] you can see a
picture of how I go from 960 hz sampled audio stream via DC-blocker,
thresholding , interpolation and decimation into a digital signal (to
the 'old' message sink). In the next stage, I'd like to take an audio
source (with a few selectable common audion samplerates) instead, which
means that my block must do all those things within the block itself.
How is this normally done? Do I create a hierarchical block containing
these blocks "under the hood", plus my new digital-in-DCS-decode block?


There's no right way. You can make a hier block in GRC, Python, C++, or
leave it in the top level flow graph. GRC hier block is the easiest if
it works for you.



2. Does it make sense to have DCS as a tagged stream? Should I chose
some other type to communicate DCS ?


The choice of messages or tagged streams has to do with how you want to
process the data downstream. If a downstream block needs the info
associated with a sample (like a squelch) then tags are good. If it's
thought of more as data (like for logging) then messages are good. There
is also a tag-to-message block, so you can have it both ways.


Oh, tag-to-message is part of gr-baz, not gnuradio proper.





3. Are there better ways to extract the digital signal from the audio
source than my schematic above? Am I doing something stupid?


A low pass filter should be used to cut out voice. A rational resampler
can replace the interpolate and 1-in-N blocks. You could combine the LPF
and DC blocker into the taps for the resampler if you want to get fancy.
The threshold can go after the resampler.

I'm not familiar with DCS, but typically a synchronizer block of some
sort is used before the bits are processed. Otherwise, your bit
alignment is due to luck (or short sequences).



4. Are there any suitable UI-components I can use to display DCS
information - e.g. something which show information from streamed tags ,
or mechanisms to modify variables based on tag info?


The QT time sink will display tags.



Grateful for suggestions and ideas.
Martin Holst Swende


[1] https://bitbucket.org/holiman/gnuradio-dcs
[2] http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules
[3] http://martin.swende.se/graph_part.png

___
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] GRC 3.6 / 802.11 a/g test signal

[Ernest Szczepaniak]

Ok. After couple of days trying to decode your frame i decided to check my
receiver with real samples.
Could it be possible that after demodulation (de-interleaving,
de-convolutional, de-scrambling) im getting over 40x0's in correct positions
(9 reserved bits, 16x0s in duration, correct pads) and still cant work out
your frames? Such amount of correct data couldnt be a coincidence :(

That test frame from Annex L is fully coded (scrambled, interleaved and conv
coded)?

Best, 
Ernest



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50672.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Using volk

[Marcus Müller]

Hi Mostafa,

VOLK is but an accelerated Library of Vector Optimized Kernels.
What you want is basically three operations:
a) finding maximum absolute
b) finding average absolute
c) dividing these two values

Now, looking closer at a) and b), one notices that both require the
samples to be converted to their magnitudes, first. And because we're in
the business of optimizing things, let's just use the squared magnitude,
because that's faster to compute by one sqrt, usually. So this boils down to
a) take mag_squared of input (length N)
b1) find maximum of a)
b2) find sum of a)
c) sqrt(b2/b1)/N

As you can see, c) is not a vector operation, and thus not a case for volk.
For a) ("Complex to Mag ^ 2") there is a GNU Radio block that uses VOLK.
That's the example for using VOLK that I would have recommended to read,
anyway :)

In other terms: If you don't have to write your own highly optimized
block, don't use VOLK directly, use the standard GNU Radio blockset.
It's rather optimized ;)

Now, for the maximum search b1, things are a bit more complicated.
Searching for a maximum is not *easily* vectorizable, because it is a
inherently sequential operation (think of it as the first step of a
bubble sort).
Now, you can achieve *awesome* performance by basically turning your
linear search into a N-ary tree, with N being the order of parallelism
you can achieve by using a maximum-finding SIMD instruction. But that
requires the size of the problem to be a power of N. That just doesn't
fly well with the usually more "multiple of 64 bit"-typey alignment
restrictions.
You're however, highly encouraged to try just that: use the existing
volk_32f_x2_max_32f, which compares two vectors, and stores the
element-wise maximum in a third one, to compare the first with the
second half of your mag_squared vector, and repeat the same with the
first and second half of the result (and so on) until you have a single
maximum value. That's the comparison tree from above for the N=2 case.
You can employ clever overlapping to use as many values twice in the
input to virtually extend your input's length to a power of two, and
then just waltz on.

For b2) you can simply use the "integrate" block, which is not VOLK
optimized (possibly because it's a gengen template and these are *so
much fun* to specialize). But seeing as it is simply an accumulating for
loop, I kind of expect your compiler to make the best of the situation.
However, you can also use the volk_32f_accumulator_s32f VOLK kernel. I
kind of want to use that in integrate, because for my machine, the SSE
VOLK kernel is 4 times as fast as the generic implementation, which
nicely matches the 4-operand SSE SIMD instruction behind it.

Greetings,
Marcus

On 07.10.2014 21:49, Mostafa Alizadeh wrote:
> Hello all,
>
> I wondered about volk. I want it to compute mean to peak value of a complex
> array. How could I do this?
> Besides, I really need to know is there any example of using volk? The code
> itself, doesn't reflect input and output parameters explicitly.
>
> Best,
> Mostafa
>
>
>
> ___
> 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] GRC 3.6 / 802.11 a/g test signal

[Bastian Bloessl]

On 10/08/2014 11:54 AM, Ernest Szczepaniak wrote:

Ok. After couple of days trying to decode your frame i decided to check my
receiver with real samples.
Could it be possible that after demodulation (de-interleaving,
de-convolutional, de-scrambling) im getting over 40x0's in correct positions
(9 reserved bits, 16x0s in duration, correct pads) and still cant work out
your frames? Such amount of correct data couldnt be a coincidence :(



As I already mentioned, it is very hard to help you without the code...


That test frame from Annex L is fully coded (scrambled, interleaved and conv
coded)?



Yes, it is. And it's clearly stated. But for your convenience I can copy 
paste from the standard.


The encoding illustration goes through the following stages:
a) Generating the short training sequence section of the preamble;
b) Generating the long preamble sequence section of the preamble;
c) Generating the SIGNAL field bits;
d) Coding and interleaving the SIGNAL field bits;
e) Mapping the SIGNAL field into frequency domain;
f) Pilot insertion;
g) Transforming into time domain;
h) Delineating the data octet stream into a bit stream;
i) Prepending the SERVICE field and adding the pad bits, thus forming 
the DATA;

j) Scrambling and zeroing the tail bits;
k) Encoding the DATA with a convolutional encoder and puncturing;
l) Mapping into complex 16-QAM symbols;
m) Pilot insertion;
n) Transforming from frequency to time and adding a circular prefix;
o) Concatenating the OFDM symbols into a single, time-domain signal.

Bastian

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

Re: [Discuss-gnuradio] Delay block controlled by input

[Marcus Müller]

Hello Carlos,
On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:
> I generate the signal from a file (1023 samples/s) to a file. My
> sampling clock drifts significantly :S
No. Unless I misunderstood you, you have a big misconception:
"sampling clock" is *not* the rate at which your samples pass through
your processing chain (ie. GNU Radio). It is the time base at which they
are measured, or simulated to, mathematically.
The device/software that actually captures the samples and saves them
has a fixed clock. If that clock changes too much a) compensate that in
software, if possible or b) get a better device.
This is digital signal processing. Real world time has *no* meaning
here, everything is measured relative to the interval between two
sampling times. You can process the signal as fast or slow as you want
to (as long as that doesn't lead to things like overflows), and nothing
in the processing chain should care.
>
> - Picture one: Counter Clock 2 is correct but Counter Clock 1 no.
> Then I should use the second configuration, but it is not allowed because I
> have a loop, right?
I don't understand your graph, sorry :(

Greetings,
Marcus

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

Re: [Discuss-gnuradio] GRC 3.6 / 802.11 a/g test signal

[Bastian Bloessl]

On 10/08/2014 11:54 AM, Ernest Szczepaniak wrote:

Ok. After couple of days trying to decode your frame i decided to check my
receiver with real samples.
Could it be possible that after demodulation (de-interleaving,
de-convolutional, de-scrambling) im getting over 40x0's in correct positions
(9 reserved bits, 16x0s in duration, correct pads) and still cant work out
your frames? Such amount of correct data couldnt be a coincidence :(
One last idea: If groups of bits are correct, then most likely you 
forgot to invert the pilot patter according to the sequence given in 
Equation 18-25 of the standard.


Bastian

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

Re: [Discuss-gnuradio] GRC 3.6 / 802.11 a/g test signal

[Ernest Szczepaniak]

Got the pilot sequence but ill check it once more. I also got Annex L so not
neccesary to post it but thanks. Ill check everything once more, according
to L.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50678.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Delay block controlled by input

[Carlos Alberto Ruiz Naranjo]

Sorry, I have explained bad: S
I have the signal saved in a file and 1023 samples are one second (in
the real world).

In the first graph I have two clocks (counters samples). When passing 102300
samples it increase 0.01 seconds.
In the first watch this time controls the position of the satellite and his
delay in this time. It allows to know what signal time is passing in the
delay block.


But I have a problem: clock 2 (a test clock) and clock 1 haven't the same
time; it has a drift.


Then, I must use clock 2 (
count the samples in the delay block output, not input). But it creates a
loop.



2014-10-08 12:07 GMT+02:00 Marcus Müller :

> Hello Carlos,
> On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:
> > I generate the signal from a file (1023 samples/s) to a file. My
> > sampling clock drifts significantly :S
> No. Unless I misunderstood you, you have a big misconception:
> "sampling clock" is *not* the rate at which your samples pass through
> your processing chain (ie. GNU Radio). It is the time base at which they
> are measured, or simulated to, mathematically.
> The device/software that actually captures the samples and saves them
> has a fixed clock. If that clock changes too much a) compensate that in
> software, if possible or b) get a better device.
> This is digital signal processing. Real world time has *no* meaning
> here, everything is measured relative to the interval between two
> sampling times. You can process the signal as fast or slow as you want
> to (as long as that doesn't lead to things like overflows), and nothing
> in the processing chain should care.
> >
> > - Picture one: Counter Clock 2 is correct but Counter Clock 1 no.
> > Then I should use the second configuration, but it is not allowed
> because I
> > have a loop, right?
> I don't understand your graph, sorry :(
>
> Greetings,
> Marcus
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Delay block controlled by input

[Martin Braun]

If you don't have hardware involved, you have no 'clock'. And as such,
it can't drift.

M

On 10/08/2014 12:29 PM, Carlos Alberto Ruiz Naranjo wrote:
> Sorry, I have explained bad: S
> I have the signal saved in a file and 1023 samples are one second
> (in the real world).
> 
> In the first graph I have two clocks (counters samples). When passing
> 102300 samples it increase0.01 seconds.
> In the first watchthis time controls the position of the satellite and
> hisdelay in this time. It allows to know what signal time is passing in
> the delay block.
> 
> 
> But I have a problem: clock 2 (a test clock) and clock 1 haven't the
> same time; it has a drift.
> 
> 
> Then, I must use clock 2 (
> count the samples in the delay block output, not input). But it creates
> a loop.
> 
> 
> 
> 2014-10-08 12:07 GMT+02:00 Marcus Müller  >:
> 
> Hello Carlos,
> On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:
> > I generate the signal from a file (1023 samples/s) to a file. My
> > sampling clock drifts significantly :S
> No. Unless I misunderstood you, you have a big misconception:
> "sampling clock" is *not* the rate at which your samples pass through
> your processing chain (ie. GNU Radio). It is the time base at which they
> are measured, or simulated to, mathematically.
> The device/software that actually captures the samples and saves them
> has a fixed clock. If that clock changes too much a) compensate that in
> software, if possible or b) get a better device.
> This is digital signal processing. Real world time has *no* meaning
> here, everything is measured relative to the interval between two
> sampling times. You can process the signal as fast or slow as you want
> to (as long as that doesn't lead to things like overflows), and nothing
> in the processing chain should care.
> >
> > - Picture one: Counter Clock 2 is correct but Counter Clock 1 no.
> > Then I should use the second configuration, but it is not allowed 
> because I
> > have a loop, right?
> I don't understand your graph, sorry :(
> 
> Greetings,
> Marcus
> 
> 
> 
> 
> ___
> 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] Delay block controlled by input

[Martin Braun]

See also
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-does-sample-rate-mean-in-GNU-Radio.

M

On 10/08/2014 01:18 PM, Martin Braun wrote:
> If you don't have hardware involved, you have no 'clock'. And as such,
> it can't drift.
> 
> M
> 
> On 10/08/2014 12:29 PM, Carlos Alberto Ruiz Naranjo wrote:
>> Sorry, I have explained bad: S
>> I have the signal saved in a file and 1023 samples are one second
>> (in the real world).
>>
>> In the first graph I have two clocks (counters samples). When passing
>> 102300 samples it increase0.01 seconds.
>> In the first watchthis time controls the position of the satellite and
>> hisdelay in this time. It allows to know what signal time is passing in
>> the delay block.
>>
>>
>> But I have a problem: clock 2 (a test clock) and clock 1 haven't the
>> same time; it has a drift.
>>
>>
>> Then, I must use clock 2 (
>> count the samples in the delay block output, not input). But it creates
>> a loop.
>>
>>
>>
>> 2014-10-08 12:07 GMT+02:00 Marcus Müller > >:
>>
>> Hello Carlos,
>> On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:
>> > I generate the signal from a file (1023 samples/s) to a file. My
>> > sampling clock drifts significantly :S
>> No. Unless I misunderstood you, you have a big misconception:
>> "sampling clock" is *not* the rate at which your samples pass through
>> your processing chain (ie. GNU Radio). It is the time base at which they
>> are measured, or simulated to, mathematically.
>> The device/software that actually captures the samples and saves them
>> has a fixed clock. If that clock changes too much a) compensate that in
>> software, if possible or b) get a better device.
>> This is digital signal processing. Real world time has *no* meaning
>> here, everything is measured relative to the interval between two
>> sampling times. You can process the signal as fast or slow as you want
>> to (as long as that doesn't lead to things like overflows), and nothing
>> in the processing chain should care.
>> >
>> > - Picture one: Counter Clock 2 is correct but Counter Clock 1 no.
>> > Then I should use the second configuration, but it is not allowed 
>> because I
>> > have a loop, right?
>> I don't understand your graph, sorry :(
>>
>> Greetings,
>> Marcus
>>
>>
>>
>>
>> ___
>> 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] Delay block controlled by input

[Carlos Alberto Ruiz Naranjo]

Yes, it is not a real time clock. This "clock" tracks the current time of
the signal in GNURadio. clock2 and clock1 have a drift because the number of
counted samples are different.

For example, if it pass 1023 samples the delay block is entering the
delay in signal time = 1 second.
1 second in the real world (later I replay the signal with a USRP).

2014-10-08 13:18 GMT+02:00 Martin Braun :

> If you don't have hardware involved, you have no 'clock'. And as such,
> it can't drift.
>
> M
>
> On 10/08/2014 12:29 PM, Carlos Alberto Ruiz Naranjo wrote:
> > Sorry, I have explained bad: S
> > I have the signal saved in a file and 1023 samples are one second
> > (in the real world).
> >
> > In the first graph I have two clocks (counters samples). When passing
> > 102300 samples it increase0.01 seconds.
> > In the first watchthis time controls the position of the satellite and
> > hisdelay in this time. It allows to know what signal time is passing in
> > the delay block.
> >
> >
> > But I have a problem: clock 2 (a test clock) and clock 1 haven't the
> > same time; it has a drift.
> >
> >
> > Then, I must use clock 2 (
> > count the samples in the delay block output, not input). But it creates
> > a loop.
> >
> >
> >
> > 2014-10-08 12:07 GMT+02:00 Marcus Müller  > >:
> >
> > Hello Carlos,
> > On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:
> > > I generate the signal from a file (1023 samples/s) to a file.
> My
> > > sampling clock drifts significantly :S
> > No. Unless I misunderstood you, you have a big misconception:
> > "sampling clock" is *not* the rate at which your samples pass through
> > your processing chain (ie. GNU Radio). It is the time base at which
> they
> > are measured, or simulated to, mathematically.
> > The device/software that actually captures the samples and saves them
> > has a fixed clock. If that clock changes too much a) compensate that
> in
> > software, if possible or b) get a better device.
> > This is digital signal processing. Real world time has *no* meaning
> > here, everything is measured relative to the interval between two
> > sampling times. You can process the signal as fast or slow as you
> want
> > to (as long as that doesn't lead to things like overflows), and
> nothing
> > in the processing chain should care.
> > >
> > > - Picture one: Counter Clock 2 is correct but Counter Clock 1 no.
> > > Then I should use the second configuration, but it is not allowed
> because I
> > > have a loop, right?
> > I don't understand your graph, sorry :(
> >
> > Greetings,
> > Marcus
> >
> >
> >
> >
> > ___
> > 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

Re: [Discuss-gnuradio] Delay block controlled by input

[Marcus Müller]

In that case, just use nitems_read() [1] in your delay block to
inherently calculate "simulated time".

However, I'm a bit curious about the effects of using delay to do this:
Because, as long as the satellite is approaching you, you're
occasionally dropping samples, whereas you're inserting zeros while it
moves away from the observer. Unless your 10.23MHz signal contains only
a oversampled signal you care about and then decimated after delay [2]
this potentially really differs from what you'd be seeing in a real
world receiver.

Greetings,
Marcus

[1]
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a2279d1eb421203bc5b0f100a6d5dc263
[2] in which case that kind of has a doppler-y touch to it...
On 08.10.2014 13:33, Carlos Alberto Ruiz Naranjo wrote:
> Yes, it is not a real time clock. This "clock" tracks the current time of
> the signal in GNURadio. clock2 and clock1 have a drift because the number of
> counted samples are different.
>
> For example, if it pass 1023 samples the delay block is entering the
> delay in signal time = 1 second.
> 1 second in the real world (later I replay the signal with a USRP).
>
> 2014-10-08 13:18 GMT+02:00 Martin Braun :
>
>> If you don't have hardware involved, you have no 'clock'. And as such,
>> it can't drift.
>>
>> M
>>
>> On 10/08/2014 12:29 PM, Carlos Alberto Ruiz Naranjo wrote:
>>> Sorry, I have explained bad: S
>>> I have the signal saved in a file and 1023 samples are one second
>>> (in the real world).
>>>
>>> In the first graph I have two clocks (counters samples). When passing
>>> 102300 samples it increase0.01 seconds.
>>> In the first watchthis time controls the position of the satellite and
>>> hisdelay in this time. It allows to know what signal time is passing in
>>> the delay block.
>>>
>>>
>>> But I have a problem: clock 2 (a test clock) and clock 1 haven't the
>>> same time; it has a drift.
>>>
>>>
>>> Then, I must use clock 2 (
>>> count the samples in the delay block output, not input). But it creates
>>> a loop.
>>>
>>>
>>>
>>> 2014-10-08 12:07 GMT+02:00 Marcus Müller >> >:
>>>
>>> Hello Carlos,
>>> On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:
>>> > I generate the signal from a file (1023 samples/s) to a file.
>> My
>>> > sampling clock drifts significantly :S
>>> No. Unless I misunderstood you, you have a big misconception:
>>> "sampling clock" is *not* the rate at which your samples pass through
>>> your processing chain (ie. GNU Radio). It is the time base at which
>> they
>>> are measured, or simulated to, mathematically.
>>> The device/software that actually captures the samples and saves them
>>> has a fixed clock. If that clock changes too much a) compensate that
>> in
>>> software, if possible or b) get a better device.
>>> This is digital signal processing. Real world time has *no* meaning
>>> here, everything is measured relative to the interval between two
>>> sampling times. You can process the signal as fast or slow as you
>> want
>>> to (as long as that doesn't lead to things like overflows), and
>> nothing
>>> in the processing chain should care.
>>> >
>>> > - Picture one: Counter Clock 2 is correct but Counter Clock 1 no.
>>> > Then I should use the second configuration, but it is not allowed
>> because I
>>> > have a loop, right?
>>> I don't understand your graph, sorry :(
>>>
>>> Greetings,
>>> Marcus
>>>
>>>
>>>
>>>
>>> ___
>>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Delay block controlled by input

[Jeff Long]

If you're comparing real time (system clock) to your sample stream, 
you'll get jitter, not drift, using a throttle. Throttle maintains a 
sample rate over time, but operates on blocks, and also is running under 
a non-realtime operating system.


If you're talking about drift between the clock on your receiver and the 
real world, that's normal and you have to find ways to deal with it.


- Jeff

On 10/08/2014 07:33 AM, Carlos Alberto Ruiz Naranjo wrote:

Yes, it is not a real time clock. This "clock" tracks the current time
of the signal in GNURadio.clock2 and clock1 have a drift because the
number of counted samples are different.

For example, if it pass 1023 samples the delay block is entering the
delay in signal time = 1 second.
1 second in the real world (later I replay the signal with a USRP).

2014-10-08 13:18 GMT+02:00 Martin Braun mailto:martin.br...@ettus.com>>:

If you don't have hardware involved, you have no 'clock'. And as such,
it can't drift.

M

On 10/08/2014 12:29 PM, Carlos Alberto Ruiz Naranjo wrote:
> Sorry, I have explained bad: S
> I have the signal saved in a file and 1023 samples are one second
> (in the real world).
>
> In the first graph I have two clocks (counters samples). When passing
> 102300 samples it increase0.01 seconds.
 > In the first watchthis time controls the position of the
satellite and
 > hisdelay in this time. It allows to know what signal time is
passing in
> the delay block.
>
>
> But I have a problem: clock 2 (a test clock) and clock 1 haven't the
> same time; it has a drift.
>
>
> Then, I must use clock 2 (
> count the samples in the delay block output, not input). But it creates
> a loop.
>
>
>
> 2014-10-08 12:07 GMT+02:00 Marcus Müller mailto:marcus.muel...@ettus.com>
 > >>:
>
> Hello Carlos,
> On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:
> > I generate the signal from a file (1023 samples/s) to a file. My
> > sampling clock drifts significantly :S
> No. Unless I misunderstood you, you have a big misconception:
> "sampling clock" is *not* the rate at which your samples pass through
> your processing chain (ie. GNU Radio). It is the time base at which 
they
> are measured, or simulated to, mathematically.
> The device/software that actually captures the samples and saves them
> has a fixed clock. If that clock changes too much a) compensate that 
in
> software, if possible or b) get a better device.
> This is digital signal processing. Real world time has *no* meaning
> here, everything is measured relative to the interval between two
> sampling times. You can process the signal as fast or slow as you want
> to (as long as that doesn't lead to things like overflows), and 
nothing
> in the processing chain should care.
> >
> > - Picture one: Counter Clock 2 is correct but Counter Clock 1 no.
> > Then I should use the second configuration, but it is not allowed 
because I
> > have a loop, right?
> I don't understand your graph, sorry :(
>
> Greetings,
> Marcus
>
>
>
>
 > ___
 > 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC 3.6 / 802.11 a/g test signal

[Ernest Szczepaniak]

So... After going deep into Annex L i found that my scrambler fails. Also
MATLAB built-in scrambler gives wrong results. Could you pls check this code
fragment?

Asumme that we have 20 data bits to scramble. Initial scrambler state is [1
0 1 1 1 0 1] (bit nr 7 left side).

scrambler_register=[1 0 1 1 1 0 1];   %
scrambler seed
data_bits=randi([0 1],1,20); %
data to be scrambled

for i=1:20
   temp=xor(scrambler_register(1),scrambler_register(4));  % x7 and x4 xor
operation
   data_scrambled(i)=xor(data_bits(i),temp);  % output
bit
   register=circshift(scrambler_register',-1,1)';% shift
left register
   register(7)=data_scrambled(i);   %
insert data to register
end

To clarify, left side of register has index (1), right side has index (7).

Best, 
Ernest



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50685.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] GRC 3.6 / 802.11 a/g test signal

[Bastian Bloessl]

On 08 Oct 2014, at 14:23, Ernest Szczepaniak  wrote:

> So... After going deep into Annex L i found that my scrambler fails. Also
> MATLAB built-in scrambler gives wrong results. Could you pls check this code
> fragment?
> 
> Asumme that we have 20 data bits to scramble. Initial scrambler state is [1
> 0 1 1 1 0 1] (bit nr 7 left side).
> 
> scrambler_register=[1 0 1 1 1 0 1];   %
> scrambler seed
> data_bits=randi([0 1],1,20); %
> data to be scrambled
> 
> for i=1:20
>   temp=xor(scrambler_register(1),scrambler_register(4));  % x7 and x4 xor
> operation
>   data_scrambled(i)=xor(data_bits(i),temp);  % output
> bit
>   register=circshift(scrambler_register',-1,1)';% shift
> left register
>   register(7)=data_scrambled(i); 

the scrambler is independent from the data. you want to feedback temp and not 
data_scrambled.

Maybe you want to have a look at Figure 1 in

http://www.ccs-labs.org/bib/bloessl2015scrambler/

Bastian



> end
> 
> To clarify, left side of register has index (1), right side has index (7).
> 
> Best, 
> Ernest
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50685.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

--
Dipl.-Inform. Bastian Bloessl
Distributed Embedded Systems Group
University of Paderborn, Germany
http://www.ccs-labs.org/~bloessl/


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

Re: [Discuss-gnuradio] Delay block controlled by input

[Carlos Alberto Ruiz Naranjo]

Delay Block is controlled by Satellite Orbit and Satellite Orbit by
"simulated clock". The output of Satellite Orbit is the delay (samples).
Can I know the nitems_read of Delay Block from other block (Satellite
Orbit)?

Maybe a solution is to introduce Orbit Satellite in Delay block, but this
is really inefficient to do tests. And a problem if I want to change the
Delay block for your solution (FFT).


Really the delay is in the non-modulated signal.



Jeff, it is a "simulated clock". And it doesn't run with throttle because the
samples in the output of Delay block are different that the samples in the
input.



2014-10-08 13:43 GMT+02:00 Jeff Long :

> If you're comparing real time (system clock) to your sample stream, you'll
> get jitter, not drift, using a throttle. Throttle maintains a sample rate
> over time, but operates on blocks, and also is running under a non-realtime
> operating system.
>
> If you're talking about drift between the clock on your receiver and the
> real world, that's normal and you have to find ways to deal with it.
>
> - Jeff
>
> On 10/08/2014 07:33 AM, Carlos Alberto Ruiz Naranjo wrote:
>
>> Yes, it is not a real time clock. This "clock" tracks the current time
>> of the signal in GNURadio.clock2 and clock1 have a drift because the
>> number of counted samples are different.
>>
>> For example, if it pass 1023 samples the delay block is entering the
>> delay in signal time = 1 second.
>> 1 second in the real world (later I replay the signal with a USRP).
>>
>> 2014-10-08 13:18 GMT+02:00 Martin Braun > >:
>>
>> If you don't have hardware involved, you have no 'clock'. And as such,
>> it can't drift.
>>
>> M
>>
>> On 10/08/2014 12:29 PM, Carlos Alberto Ruiz Naranjo wrote:
>> > Sorry, I have explained bad: S
>> > I have the signal saved in a file and 1023 samples are one
>> second
>> > (in the real world).
>> >
>> > In the first graph I have two clocks (counters samples). When
>> passing
>> > 102300 samples it increase0.01 seconds.
>>  > In the first watchthis time controls the position of the
>> satellite and
>>  > hisdelay in this time. It allows to know what signal time is
>> passing in
>> > the delay block.
>> >
>> >
>> > But I have a problem: clock 2 (a test clock) and clock 1 haven't the
>> > same time; it has a drift.
>> >
>> >
>> > Then, I must use clock 2 (
>> > count the samples in the delay block output, not input). But it
>> creates
>> > a loop.
>> >
>> >
>> >
>> > 2014-10-08 12:07 GMT+02:00 Marcus Müller > 
>>  > > >>>:
>> >
>> > Hello Carlos,
>> > On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:
>> > > I generate the signal from a file (1023 samples/s) to a
>> file. My
>> > > sampling clock drifts significantly :S
>> > No. Unless I misunderstood you, you have a big misconception:
>> > "sampling clock" is *not* the rate at which your samples pass
>> through
>> > your processing chain (ie. GNU Radio). It is the time base at
>> which they
>> > are measured, or simulated to, mathematically.
>> > The device/software that actually captures the samples and
>> saves them
>> > has a fixed clock. If that clock changes too much a) compensate
>> that in
>> > software, if possible or b) get a better device.
>> > This is digital signal processing. Real world time has *no*
>> meaning
>> > here, everything is measured relative to the interval between
>> two
>> > sampling times. You can process the signal as fast or slow as
>> you want
>> > to (as long as that doesn't lead to things like overflows), and
>> nothing
>> > in the processing chain should care.
>> > >
>> > > - Picture one: Counter Clock 2 is correct but Counter Clock 1
>> no.
>> > > Then I should use the second configuration, but it is not
>> allowed because I
>> > > have a loop, right?
>> > I don't understand your graph, sorry :(
>> >
>> > Greetings,
>> > Marcus
>> >
>> >
>> >
>> >
>>  > ___
>>  > 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
>>
>>
>
> _

Re: [Discuss-gnuradio] Delay block controlled by input

[Marcus Müller]

Hi,

On 08.10.2014 14:38, Carlos Alberto Ruiz Naranjo wrote:
> Delay Block is controlled by Satellite Orbit and Satellite Orbit by
> "simulated clock". The output of Satellite Orbit is the delay (samples).
> Can I know the nitems_read of Delay Block from other block (Satellite
> Orbit)?
Yes. It's a public function, as you can see in the documentation I linked.
>
> Maybe a solution is to introduce Orbit Satellite in Delay block, but this
> is really inefficient to do tests.
Good point, but you should be able to test your "calculate transmission
delay from an integer" functionality externally; also, there's no reason
to have something like a class "delay_calculator", with methods you call
from your modified delay block. You can test that very easily isolated.
>  And a problem if I want to change the
> Delay block for your solution (FFT).
Well, yes, if you change approaches, the old approach will no longer
apply. That's a design decision you'll have to make.

>
> Really the delay is in the non-modulated signal.
I don't understand this sentence, sorry.

Greetings,
Marcus

>
>
>
> 2014-10-08 13:43 GMT+02:00 Jeff Long :
>
>> If you're comparing real time (system clock) to your sample stream, you'll
>> get jitter, not drift, using a throttle. Throttle maintains a sample rate
>> over time, but operates on blocks, and also is running under a non-realtime
>> operating system.
>>
>> If you're talking about drift between the clock on your receiver and the
>> real world, that's normal and you have to find ways to deal with it.
>>
>> - Jeff
>>
>> On 10/08/2014 07:33 AM, Carlos Alberto Ruiz Naranjo wrote:
>>
>>> Yes, it is not a real time clock. This "clock" tracks the current time
>>> of the signal in GNURadio.clock2 and clock1 have a drift because the
>>> number of counted samples are different.
>>>
>>> For example, if it pass 1023 samples the delay block is entering the
>>> delay in signal time = 1 second.
>>> 1 second in the real world (later I replay the signal with a USRP).
>>>
>>> 2014-10-08 13:18 GMT+02:00 Martin Braun >> >:
>>>
>>> If you don't have hardware involved, you have no 'clock'. And as such,
>>> it can't drift.
>>>
>>> M
>>>
>>> On 10/08/2014 12:29 PM, Carlos Alberto Ruiz Naranjo wrote:
>>> > Sorry, I have explained bad: S
>>> > I have the signal saved in a file and 1023 samples are one
>>> second
>>> > (in the real world).
>>> >
>>> > In the first graph I have two clocks (counters samples). When
>>> passing
>>> > 102300 samples it increase0.01 seconds.
>>>  > In the first watchthis time controls the position of the
>>> satellite and
>>>  > hisdelay in this time. It allows to know what signal time is
>>> passing in
>>> > the delay block.
>>> >
>>> >
>>> > But I have a problem: clock 2 (a test clock) and clock 1 haven't the
>>> > same time; it has a drift.
>>> >
>>> >
>>> > Then, I must use clock 2 (
>>> > count the samples in the delay block output, not input). But it
>>> creates
>>> > a loop.
>>> >
>>> >
>>> >
>>> > 2014-10-08 12:07 GMT+02:00 Marcus Müller >> 
>>>  > > :
>>> >
>>> > Hello Carlos,
>>> > On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:
>>> > > I generate the signal from a file (1023 samples/s) to a
>>> file. My
>>> > > sampling clock drifts significantly :S
>>> > No. Unless I misunderstood you, you have a big misconception:
>>> > "sampling clock" is *not* the rate at which your samples pass
>>> through
>>> > your processing chain (ie. GNU Radio). It is the time base at
>>> which they
>>> > are measured, or simulated to, mathematically.
>>> > The device/software that actually captures the samples and
>>> saves them
>>> > has a fixed clock. If that clock changes too much a) compensate
>>> that in
>>> > software, if possible or b) get a better device.
>>> > This is digital signal processing. Real world time has *no*
>>> meaning
>>> > here, everything is measured relative to the interval between
>>> two
>>> > sampling times. You can process the signal as fast or slow as
>>> you want
>>> > to (as long as that doesn't lead to things like overflows), and
>>> nothing
>>> > in the processing chain should care.
>>> > >
>>> > > - Picture one: Counter Clock 2 is correct but Counter Clock 1
>>> no.
>>> > > Then I should use the second configuration, but it is not
>>> allowed because I
>>> > > have a loop, right?
>>> > I don't understand your graph, sorry :(
>>> >
>>> > Greetings,
>>> > Marcus
>>> >
>>> >
>>> >
>>> >
>>>  > ___
>>>  > Discuss-gnuradio mailing list
>>>  > Discu