[Discuss-gnuradio] Avoid "U"nderflow Techniques

[Simone Ciccia S210664]

Goodmorning Community,

In the following situation

| Software |  |RF|
| Code | ---> |Front End |
|  |  |(Sample_Rate) |

Underflow occurs when the software code does not provide
samples at a constant rate as required by the RF-Front End.
The known solution, able to eliminate Underflows, is clearly speed up
the software code. However, in this discussion I want to understant
if there exist alternative methods, keeping the software as it is.
One thing that comes in my mind is to collect a certain number of 
processed samples

in a FIFO before starting the RF-front end transmission, ensuring that
there are always samples in the FIFO buffer (clearly for a limited 
period).


| Software |  | Implement  |  |RF|
| Code | ---> | FIFO   | ---> |Front End |
|  |  |(synch with FE) |  |(Sample_Rate) |

Could it be implemented (if it make sense)?
Can you guide me to implement such block?
(in particular the Forecast, I think it will a general block)

Thank you very much,
simone

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

Re: [Discuss-gnuradio] Problem with RX OFDM through the network

[Maicon Kist]

Hi Andy, 
first of all, thanks for you reply.

I'd start simple. Use the lastest gnuradio with the fixed gr-zeromq 
blocks. Just put in 1 PUSH/PULL pair; not the 4 or 6 pairs you have 
now. 
The version installed in the machines is the 3.7.9. 

As for the number of pairs, even if I use the original rx_ofdm.grc (provided by 
the installer), I notice that the Random Source is generating way more numbers 
than what is received in the end of the flowgraph (I created an OOT module that 
prints the total of numbers it receives and added one right before the Random 
Source and one after the CRC check blocks).



Best regards,



On February 19, 2016 at 15:41:03, Andy Walls (a...@silverblocksystems.net) 
wrote:

On Fri, 2016-02-19 at 12:01 -0500, discuss-gnuradio-requ...@gnu.org  
wrote:  

> Date: Fri, 19 Feb 2016 14:14:34 -0200  
> From: Maicon Kist  
> To: discuss-gnuradio@gnu.org  
> Subject: Re: [Discuss-gnuradio] Problem with RX OFDM through the  
> network  

> Hello,  
>  
> I?m having similar problems executing the original rx_ofdm.grc file  
> (in?gnuradio/examples/digital/ofdm), which is: the quantity of numbers  
> generated by the Random Source is way higher than the quantity  
> received in the Tag Debug at the end of the flowgraph.  
>  
> Is it possible to limit the quantity of items in the blocks  
> output/input queue? This way I could ?force the flograph to have at  
> max 1 item in the output/input queue of each block.  


You don't want to do that. The overhead is terrible and it likely won't  
help find the problem.  

First, make sure you're using the latest gnuradio (3.7.9.1?) release.  
The gr-zmq blocks in any prior gnuradio release are broken, in they can  
drop arbitrary numbers of samples due to improper message payload  
handling; plus they chew a lot of CPU doing unneeded copies.  

Switching to PUSH/PULL from REQ/REP was the right thing to do.  

The random number source block isn't being favored by the scheduler,  
it's just using a CPU intensive algorithm to produce samples, so it  
needs more CPU time to do so.  

Under certain circumstances ZeroMQ is allowed to drop messages. If your  
flowgraph blocks downstream aren't keeping up, ZeroMQ will drop whole  
zeromq messages full of samples. The default ZeroMQ high watermark is  
1000 messages in later versions of ZeroMQ. In very old versions it was  
infinite, causing a paging thrash to/from disk, if you didn't keep up.  


I'd start simple. Use the lastest gnuradio with the fixed gr-zeromq  
blocks. Just put in 1 PUSH/PULL pair; not the 4 or 6 pairs you have  
now.  

Regards,  
Andy  

> Best Regards,  
>  
> On February 18, 2016 at 10:58:26, Maicon Kist (maiconk...@gmail.com)  
> wrote:  
>  
> Well, Im trying to figure out why the quantity of numbers received is  
> way smaller than the quantity generated.  
>  
> So, I did something more simples:  
> - I modified the ?rx_ofdm.grc file  
> (in?gnuradio/examples/digital/ofdm). I simple added a ?Tag Debug?  
> right before the second block in the chain (Stream to Tagged Stream).?  
> - Even in this example the quantity of numbers generated is 10x the  
> quantity of numbers recoved in the end of the flowgraph.  
>  
> It seems to me that the scheduler prioritizes the ?Random Source?,  
> calling it several times more than the other blocks in the flowgraph.  
> Is there a way to fix this?  
>  
> Best Regards.  
>  
> On February 18, 2016 at 09:09:32, Maicon Kist (maiconk...@gmail.com)  
> wrote:  
>  
> Hello  
>  
> I manage to solve the problem ?of  
> gr::log :INFO: packet_headerparser_b0 - Detected an invalid packet at  
> item 2112  
> gr::log :INFO: header_payload_demux0 - Parser returned #f  
> by replacing all ZMQ REP/REQ by ZMQ PUSH/PULL blocks.?  
>  
> Now, my only problem is that the Random Source Generator is generating  
> (d?) way more numbers that are being received in the final part of the  
> flowgraph (Tag Debug).  
>  
> ?Any hints about this too ?  


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

[Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Nasi]

 Hello,

The question is about how does the given Doppler shift progress, or how is the 
Doppler induced phase shift implemented.

I select a simple frequency selective fading block and feed in it some 
gr_complex(1, 0) values. For simplicity I run one fader (num of sinusoids).
in file:
https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/flat_fader_impl.cc
  
in the code below,
# elif FASTSINCOS == 2
  float s_i = scale_sin*d_table. cos ( 2 *M_PI*d_fDTs*d_m*d_table. cos 
(alpha_n)+d_psi[n+ 1 ]);
  float s_q = scale_sin*d_table. cos ( 2 *M_PI*d_fDTs*d_m*d_table. sin 
(alpha_n)+d_phi[n+ 1 ]);
   
  # else   d_m shows that the Doppler shift must progress sequencially. 
However, the value of " 2 *M_PI*d_fDTs*d_m*d_table. cos (alpha_n) " as a whole, 
produces floating point numbers which results in kind of random values out of  
d_table. cos () function in file 
https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/sincostable.h

Some more explanation:
the value:  2 *M_PI*d_fDTs*d_m*d_table. cos (alpha_n) gets in as x below (in 
file .../ lib/sincostable.h )
((( int )(x*d_scale)) + d_sz) % d_sz; - this is a random integer value (may be 
not, can you please help me with that?)
therefore it returns a random cos value as: return d_cos[idx];

The issue arises when that floating point values inside cos() function is 
converted to integers as given above.

Now, my question is, did you do that random phase shift/Doppler shift on 
purpose? If yes, what is the reasoning behind that.
As far as I know, the Doppler shift should be somehow linear progressive.

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

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Bastian Bloessl]

Hi,

I posted a question about the very same lines of code four days ago, but did 
not get a reply yet

http://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00254.html 


I’m not sure whats going on there, but some wild guesses:

The Doppler Frequency per sinusoid is distributed according to that U-shaped 
thing you see everywhere.
Now, instead of rolling the dice once during initialisation and sticking to 
that Doppler frequency forever, this implementation is doing something like a 
random walk through the Doppler Spectrum.

alpha_n is going back and forth between -pi and pi (plus some initial phase 
offset), so fDTs * cos(alpha_n), the normalised Doppler Frequency, follows this 
U-distribution.

This has the advantage that you can start the block once and your results will 
converge to the mean. (Otherwise, you would have to do a lot of repetitions to 
get a lot of random initialisations.)

What I don’t get (and what I asked in the other thread) is why this is 
multiplied with d_m. I think that, per sample, the current Doppler Frequency 
should be used to calculate an incremental angle to the previous value.

(I guess the sincostable is just a lookup table for sin and cos values for 
speed optimisation.)

I hope that didn’t confuse even more...

Best,
Bastian



> On 22 Feb 2016, at 06:41, Nasi  wrote:
> 
> Hello,
> 
> The question is about how does the given Doppler shift progress, or how is 
> the Doppler induced phase shift implemented.
> 
> I select a simple frequency selective fading block and feed in it some 
> gr_complex(1, 0) values. For simplicity I run one fader (num of sinusoids).
> in file:
> https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/flat_fader_impl.cc
>  
> 
>  
> in the code below,
> #elif FASTSINCOS == 2
>   float s_i = 
> scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)+d_psi[n+1]);
>   float s_q = 
> scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.sin(alpha_n)+d_phi[n+1]);
>
>   #else
>  d_m shows that the Doppler shift must progress sequencially. However, the 
> value of "2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)" as a whole, produces 
> floating point numbers which results in kind of random values out of 
> d_table.cos() function in file 
> https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/sincostable.h
> 
> Some more explanation:
> the value: 2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n) gets in as x below (in file 
> .../lib/sincostable.h)
> (((int)(x*d_scale)) + d_sz) % d_sz; - this is a random integer value (may be 
> not, can you please help me with that?)
> therefore it returns a random cos value as: return d_cos[idx];
> 
> The issue arises when that floating point values inside cos() function is 
> converted to integers as given above.
> 
> Now, my question is, did you do that random phase shift/Doppler shift on 
> purpose? If yes, what is the reasoning behind that.
> As far as I know, the Doppler shift should be somehow linear progressive.
> 
> -- 
> NE
> ___
> 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] Avoid "U"nderflow Techniques

[Martin Braun]

Simone,

first of all, FIFOs of this sort already exist (both on the device and
in host, in form of the buffer between the upstream block and the USRP
block).

Now, if you're SW is too slow, your FIFO will always run out of samples
and eventually you'll have U's again. This can only help to avoid
transient underruns, i.e. when your SW is *on average* fast enough, but
sometimes falls behind. In this case, large buffers can help, but come
at the cost of latency.

You might have enough buffering if you simply start transmitting with a
delay. This will force buffers to fill up. Timed commands will help you
with this.

Cheers,
Martin

On 02/22/2016 12:47 AM, Simone Ciccia S210664 wrote:
> Goodmorning Community,
> 
> In the following situation
> 
> | Software |  |RF  |
> | Code   | ---> |Front End |
> |  |  |(Sample_Rate) |
> 
> Underflow occurs when the software code does not provide
> samples at a constant rate as required by the RF-Front End.
> The known solution, able to eliminate Underflows, is clearly speed up
> the software code. However, in this discussion I want to understant
> if there exist alternative methods, keeping the software as it is.
> One thing that comes in my mind is to collect a certain number of
> processed samples
> in a FIFO before starting the RF-front end transmission, ensuring that
> there are always samples in the FIFO buffer (clearly for a limited period).
> 
> | Software |  | Implement  |  |RF  |
> | Code   | ---> | FIFO   | ---> |Front End |
> |  |  |(synch with FE) |  |(Sample_Rate) |
> 
> Could it be implemented (if it make sense)?
> Can you guide me to implement such block?
> (in particular the Forecast, I think it will a general block)
> 
> Thank you very much,
> simone
> 
> ___
> 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] QPSK demodulation using GRC constellation decoder not working

[Martin Braun]

You're not resolving the \pi/2 ambiguities. I guess that's what's wrong
here.

Cheers,
M

On 02/20/2016 03:33 PM, Damindra Bandara wrote:
> Hi,
> 
> I am trying to transmit and receive a file using Ettus USRP and GNU
> Radio Companion. The modulation scheme used is QPSK. I followed the "gnu
> radio tutorial 7:PSK Symbol recovery" . That worked fine and I was able
> to recover the file at the receiver end. That tutorial uses a out of
> tree module "my_qpsk_demod" as the QPSK demodulator. I am trying to
> replace the "my_qpsk_demod" with "constellation decoder" block. I did
> that as  shown in the attached figure. After I did this modification, I
> was not able to receive the file properly. 
> 
> When I observe the constellation plot after the costas loop, I can
> clearly see the four constellation. I really appreciate if you could
> help me to understand what I am doing wrong and get the code working. 
> 
> Thank you very much
> Damindra
> 
> -- 
> Damindra Savithri Bandara,
> PhD in Information Technology (Candidate)
> George Mason University,
> Fairfax,
> Virginia
> 
> 
> ___
> 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] Problem with RX OFDM through the network

[Martin Braun]

Maicon,

just checking here: Do you understand the full design of the rx_ofdm and
tx_ofdm flow graphs?
Also, you never want to limit the number of items. The Random Source
does not get prioritized, it simply will produce data until its output
buffer is filled. Because there can never be more data consumed
downstream than are produced upstream, at any given time the expected
number of bursts at the top of the flow graph is bigger than that at the
end.

Cheers,
M

On 02/19/2016 08:14 AM, Maicon Kist wrote:
> Hello,
> 
> I’m having similar problems executing the original rx_ofdm.grc file
> (in gnuradio/examples/digital/ofdm), which is: the quantity of numbers
> generated by the Random Source is way higher than the quantity received
> in the Tag Debug at the end of the flowgraph.
> 
> Is it possible to limit the quantity of items in the blocks output/input
> queue? This way I could  force the flograph to have at max 1 item in the
> output/input queue of each block.
> 
> Best Regards,
> 
> On February 18, 2016 at 10:58:26, Maicon Kist (maiconk...@gmail.com
> ) wrote:
> 
>> Well, Im trying to figure out why the quantity of numbers received is
>> way smaller than the quantity generated.
>>
>> So, I did something more simples:
>> - I modified the  rx_ofdm.grc file
>> (in gnuradio/examples/digital/ofdm). I simple added a “Tag Debug”
>> right before the second block in the chain (Stream to Tagged Stream). 
>> - Even in this example the quantity of numbers generated is 10x the
>> quantity of numbers recoved in the end of the flowgraph.
>>
>> It seems to me that the scheduler prioritizes the ‘Random Source’,
>> calling it several times more than the other blocks in the flowgraph.
>> Is there a way to fix this?
>>
>> Best Regards.
>>
>> On February 18, 2016 at 09:09:32, Maicon Kist (maiconk...@gmail.com
>> ) wrote:
>>
>>> Hello
>>>
>>> I manage to solve the problem  of
>>> gr::log :INFO: packet_headerparser_b0 - Detected an invalid packet at
>>> item 2112
>>> gr::log :INFO: header_payload_demux0 - Parser returned #f
>>> by replacing all ZMQ REP/REQ by ZMQ PUSH/PULL blocks. 
>>>
>>> Now, my only problem is that the Random Source Generator is
>>> generating (dã) way more numbers that are being received in the final
>>> part of the flowgraph (Tag Debug).
>>>
>>>  Any hints about this too ?
>>>
>>> On February 17, 2016 at 10:01:39, Maicon Kist (maiconk...@gmail.com
>>> ) wrote:
>>>
 Hello list,
 one more thing that I observed:

 The Random Source Generator is generating (dã) way more numbers that
 are being received in the final part of the flowgraph (Tag Debug).
 Any hints about this too ?
>>> -- 
>>> Maicon Kist
>> -- 
>> Maicon Kist
> -- 
> Maicon Kist
> 
> 
> ___
> 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 does Doppler shift increment in flat fading channel GNU radio

[Nasi]

 Hi,

(I was not in the mailing list for a long time) yes, you are right.
d_m is incrementation or index after initialization, which is correct thing 
there. Yes, as you also said that is per sample.
cos(alpha_n) is constant there, I checked that. cos table looks like just 
cosine values, which must be there somehow.

But the value are selected out of cos table kind of randomly. I think there is 
a "bug" in the code. Otherwise, let someone explain it better. The Doppler 
shift cannot jump from sample to sample randomly. If I make a mistake please 
correct it.


P.S.: In matlab that thing is not random. After some samples that changes a 
little bit depending on the max Doppler shift.

-
Nasimi

>Понедельник, 22 февраля 2016, 9:54 -08:00 от Bastian Bloessl 
>:
>
>Hi,
>
>I posted a question about the very same lines of code four days ago, but did 
>not get a reply yet
>
>http://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00254.html
>
>I’m not sure whats going on there, but some wild guesses:
>
>The Doppler Frequency per sinusoid is distributed according to that U-shaped 
>thing you see everywhere.
>Now, instead of rolling the dice once during initialisation and sticking to 
>that Doppler frequency forever, this implementation is doing something like a 
>random walk through the Doppler Spectrum.
>
>alpha_n is going back and forth between -pi and pi (plus some initial phase 
>offset), so fDTs * cos(alpha_n), the normalised Doppler Frequency, follows 
>this U-distribution.
>
>This has the advantage that you can start the block once and your results will 
>converge to the mean. (Otherwise, you would have to do a lot of repetitions to 
>get a lot of random initialisations.)
>
>What I don’t get (and what I asked in the other thread) is why this is 
>multiplied with d_m. I think that, per sample, the current Doppler Frequency 
>should be used to calculate an incremental angle to the previous value.
>
>(I guess the sincostable is just a lookup table for sin and cos values for 
>speed optimisation.)
>
>I hope that didn’t confuse even more...
>
>Best,
>Bastian
>
>
>
>>On 22 Feb 2016, at 06:41, Nasi < nesaz...@mail.ru > wrote:
>>Hello,
>>
>>The question is about how does the given Doppler shift progress, or how is 
>>the Doppler induced phase shift implemented.
>>
>>I select a simple frequency selective fading block and feed in it some 
>>gr_complex(1, 0) values. For simplicity I run one fader (num of sinusoids).
>>in file:
>>https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/flat_fader_impl.cc
>>  
>>in the code below,
>># elif FASTSINCOS == 2
>>  float s_i = scale_sin*d_table. cos ( 2 *M_PI*d_fDTs*d_m*d_table. cos 
>>(alpha_n)+d_psi[n+ 1 ]);
>>  float s_q = scale_sin*d_table. cos ( 2 *M_PI*d_fDTs*d_m*d_table. sin 
>>(alpha_n)+d_phi[n+ 1 ]);
>>   
>>  # else   d_m shows that the Doppler shift must progress sequencially. 
>>However, the value of " 2 *M_PI*d_fDTs*d_m*d_table. cos (alpha_n) " as a 
>>whole, produces floating point numbers which results in kind of random values 
>>out of  d_table. cos () function in file 
>>https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/sincostable.h
>>
>>Some more explanation:
>>the value:  2 *M_PI*d_fDTs*d_m*d_table. cos (alpha_n) gets in as x below (in 
>>file .../ lib/sincostable.h )
>>((( int )(x*d_scale)) + d_sz) % d_sz; - this is a random integer value (may 
>>be not, can you please help me with that?)
>>therefore it returns a random cos value as: return d_cos[idx];
>>
>>The issue arises when that floating point values inside cos() function is 
>>converted to integers as given above.
>>
>>Now, my question is, did you do that random phase shift/Doppler shift on 
>>purpose? If yes, what is the reasoning behind that.
>>As far as I know, the Doppler shift should be somehow linear progressive.
>>
>>-- 
>>NE ___
>>Discuss-gnuradio mailing list
>>Discuss-gnuradio@gnu.org
>>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>


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

Re: [Discuss-gnuradio] how does Doppler shift increment in flat fading channel GNU radio

[Bastian Bloessl]

Hi,

> On 22 Feb 2016, at 10:54, Nasi  wrote:
> 
> d_m is incrementation or index after initialization, which is correct thing 
> there.

This is what I don’t get. d_m is the absolute sample index. Let’s say you have 
a slight change in Doppler Frequency, then, from the first to the second sample 
this results in a slight phase change d_m * delta_f.
Now assume the same delta_f after the 10e6 sample. AFAIS, this will just go 
crazy and maybe result in seemingly random accesses to your sincostable.

> Yes, as you also said that is per sample.
> cos(alpha_n) is constant there,

alpha_n is not constant. It depends on d_theta, which is updated after each 
sample
https://github.com/gnuradio/gnuradio/blob/master/gr-channels/lib/flat_fader_impl.cc#L67
 


Best,
Bastian


> I checked that. cos table looks like just cosine values, which must be there 
> somehow.
> 
> But the value are selected out of cos table kind of randomly. I think there 
> is a "bug" in the code. Otherwise, let someone explain it better. The Doppler 
> shift cannot jump from sample to sample randomly. If I make a mistake please 
> correct it.
> 
> 
> P.S.: In matlab that thing is not random. After some samples that changes a 
> little bit depending on the max Doppler shift.
> 
> -
> Nasimi
> 
> Понедельник, 22 февраля 2016, 9:54 -08:00 от Bastian Bloessl 
> :
> 
> Hi,
> 
> I posted a question about the very same lines of code four days ago, but did 
> not get a reply yet
> 
> http://lists.gnu.org/archive/html/discuss-gnuradio/2016-02/msg00254.html 
> 
> 
> I’m not sure whats going on there, but some wild guesses:
> 
> The Doppler Frequency per sinusoid is distributed according to that U-shaped 
> thing you see everywhere.
> Now, instead of rolling the dice once during initialisation and sticking to 
> that Doppler frequency forever, this implementation is doing something like a 
> random walk through the Doppler Spectrum.
> 
> alpha_n is going back and forth between -pi and pi (plus some initial phase 
> offset), so fDTs * cos(alpha_n), the normalised Doppler Frequency, follows 
> this U-distribution.
> 
> This has the advantage that you can start the block once and your results 
> will converge to the mean. (Otherwise, you would have to do a lot of 
> repetitions to get a lot of random initialisations.)
> 
> What I don’t get (and what I asked in the other thread) is why this is 
> multiplied with d_m. I think that, per sample, the current Doppler Frequency 
> should be used to calculate an incremental angle to the previous value.
> 
> (I guess the sincostable is just a lookup table for sin and cos values for 
> speed optimisation.)
> 
> I hope that didn’t confuse even more...
> 
> Best,
> Bastian
> 
> 
> 
>> On 22 Feb 2016, at 06:41, Nasi > > wrote:
>> 
>> Hello,
>> 
>> The question is about how does the given Doppler shift progress, or how is 
>> the Doppler induced phase shift implemented.
>> 
>> I select a simple frequency selective fading block and feed in it some 
>> gr_complex(1, 0) values. For simplicity I run one fader (num of sinusoids).
>> in file:
>> https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/flat_fader_impl.cc
>>  
>> 
>>  
>> in the code below,
>> #elif FASTSINCOS == 2
>>  float s_i = 
>> scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)+d_psi[n+1]);
>>  float s_q = 
>> scale_sin*d_table.cos(2*M_PI*d_fDTs*d_m*d_table.sin(alpha_n)+d_phi[n+1]);
>>   
>>  #else
>>  d_m shows that the Doppler shift must progress sequencially. However, the 
>> value of "2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n)" as a whole, produces 
>> floating point numbers which results in kind of random values out of 
>> d_table.cos() function in file 
>> https://github.com/osh/gnuradio.old/blob/master/gr-channels/lib/sincostable.h
>>  
>> 
>> 
>> Some more explanation:
>> the value: 2*M_PI*d_fDTs*d_m*d_table.cos(alpha_n) gets in as x below (in 
>> file .../lib/sincostable.h)
>> (((int)(x*d_scale)) + d_sz) % d_sz; - this is a random integer value (may be 
>> not, can you please help me with that?)
>> therefore it returns a random cos value as: return d_cos[idx];
>> 
>> The issue arises when that floating point values inside cos() function is 
>> converted to integers as given above.
>> 
>> Now, my question is, did you do that random phase shift/Doppler shift on 
>> purpose? If yes, what is the reasoning behind that.
>> As far as I know, the Doppler shift should be somehow linear progressive.
>> 
>> -- 
>> NE
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 
>> 

[Discuss-gnuradio] gnuradios place in the state of the art of SDR

[Mabel Pita]

Hello,

I am just starting to get into the world of SDRs, and i have been looking
for information about SDRs state of the art, and this is when i found
GNURadio and SDRsharp as the top contenders.
I know that i am writing to the gnuradio mailing list so i wont talk about
its competitors, but can someone tell me in an objective way whether
gnuradio is considered state of the art in the matter of sdrs?

Are there any books / sites that treat this subject in a thorough manner? I
am doing this for a course at my college and it requires as a first step to
get a good knowledge of the state of the art in sdrs.

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

Re: [Discuss-gnuradio] gnuradios place in the state of the art of SDR

[Marcus Müller]

Hi Mabel,

SDRsharp and GNU Radio are fundamentally different. SDRsharp is a
single-purpose application for reception of a single class of signals.
GNU Radio is a framework for developing SDR and other DSP applications.
You should really read our intro to GNU Radio to get a feeling for
things [1]!

Of course, you're asking the GNU Radio people whether GNU Radio is state
of the art. It is[0]; the question is just: for what?

Can you narrow down your question a bit?

Best regards,
Marcus

[0] https://scholar.google.de/scholar?hl=de&q=%22GNU+Radio%22&btnG=&lr=
[1]
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_Introduction

On 02/22/2016 09:48 PM, Mabel Pita wrote:
> Hello,
>
> I am just starting to get into the world of SDRs, and i have been
> looking for information about SDRs state of the art, and this is when
> i found GNURadio and SDRsharp as the top contenders. 
> I know that i am writing to the gnuradio mailing list so i wont talk
> about its competitors, but can someone tell me in an objective way
> whether gnuradio is considered state of the art in the matter of sdrs? 
>
> Are there any books / sites that treat this subject in a thorough
> manner? I am doing this for a course at my college and it requires as
> a first step to get a good knowledge of the state of the art in sdrs.
>
> Thanks in advance.
>
>
> ___
> 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] Expresscard

[Nathan Dehnel]

Is there any GNURadio-compatible hardware that fits in an expresscard/54
slot?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradios place in the state of the art of SDR

[Michael Berman]

Mabel,

I am kind of confused as to what you mean by "state of the art".  I
personally would consider any SDR to be pretty state of the art; it has
been around for some years, but it is by no means common place.

Being unfamiliar with SDRsharp, a quick google search and read through of
their website seems that the software is tuned fairly narrowly towards
their custom hardware which would be quite lacking in many more advanced
applications due to its USB 2.0 interface.  From this, you can only take a
look at up to 10 MHz of spectrum at a time, and the overall bandwidth of
the product seems like it may be a nuance for some applications as it will
only go from 20 MHz to 1.8 GHz.  Also, the SDRsharp software states it can
be used "with their partner hardware".  If you are setting up a learning
environment, this may be restrictive in terms of capabilities of testing
and system designs by their and their partners hardware limitations.  One
last thing, their software seems to be closed source.  You cannot make
changes or see how things are done internally, all you have is the API.

GNURadio is 100% open sourced and will work with a myriad of just about any
SDR hardware out there.  All that needs to be done is a small interface set
of code be written to conform the hardware with GNURadio's code structure.
With this, as long as there is even an API for a hardware device, it is
feasible that any hardware could be interface with and use GNURadio (there
is already such code available for the airspy which is the base hardware
for SDRsharp).  Also, with GNURadio being open source, if you wonder the
exact algorithm that something is using, you can go look at the source
code.  Also, if there is something extremely custom that would be much
better off with a custom code block than piecing it together with
pre-defined blocks.

>From my point of view (having used GNURadio for an academic project) I
would much prefer GNURadio.  Being open source and having a community
backing it as it does let's you actually learn what's going on, instead of
taking it at as a black box, and never really knowing how things work at a
lower level.


Hope my rant finds some use.


Michael Berman

On Mon, Feb 22, 2016 at 12:48 PM, Mabel Pita 
wrote:

> Hello,
>
> I am just starting to get into the world of SDRs, and i have been looking
> for information about SDRs state of the art, and this is when i found
> GNURadio and SDRsharp as the top contenders.
> I know that i am writing to the gnuradio mailing list so i wont talk about
> its competitors, but can someone tell me in an objective way whether
> gnuradio is considered state of the art in the matter of sdrs?
>
> Are there any books / sites that treat this subject in a thorough manner?
> I am doing this for a course at my college and it requires as a first step
> to get a good knowledge of the state of the art in sdrs.
>
> Thanks in advance.
>
> ___
> 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] Expresscard

[Marcus Müller]

What kind of hardware are you referring to?

Generally, the Ettus USRP X3x0 can be connected via a special external
PCIe cable through an expresscard adapter, but that's kind of a costly
thing if you don't need that much bandwidth.

Also, Expresscard carries USB lines, too, and there's many USB software
defined radio devices, from Ettus and other suppliers.

Can you try to specify your requirements?

Best regards,
Marcus

On 02/22/2016 10:22 PM, Nathan Dehnel wrote:
> Is there any GNURadio-compatible hardware that fits in an
> expresscard/54 slot?
>
>
> ___
> 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] uhd_fft.grc: fifo ctrl timed out looking for acks

[Maria Christopoulou]

Hello,

I have the following system configuration:

Ubuntu 14.04, 64-bit, 3.17.0-lowlatency
Gnuradio v3.7.8
and a USRP N2930, with UHD_003.009 version installed.

The script uhd_find_devices works properly and the output of uhd_usrp_probe
is the following:

https://drive.google.com/file/d/0B9y0kqNk6AFgNnpFLWcwZ2E4WDQ/view?usp=sharing


When I execute the uhd_fft.grc flowgraph, the program runs for a few
seconds but suddenly freezes, showing the following output in the terminal:

https://drive.google.com/file/d/0B9y0kqNk6AFgY2NpdW0yS2sxMDA/view?usp=sharing

Could you please give me some guidelines to solve this issue?


Best regards,
Maria Christopoulou
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] uhd_fft.grc: fifo ctrl timed out looking for acks

[Marcus Müller]

Hello Maria,

the reason I most often encountered for this is that in the middle of
operation, Ubuntu decided to reconfigure the network interface. Make
sure you set the network interface to a valid address from the
19.168.10.XXX network (except .2), and configure the network manager for
"static" addressing.

also, for some reason, your USRP's subnet mask as reported by
uhd_usrp_probe seems wrong; it should be something like 255.255.255.0,
not 255.255.255.255.

By the way, what is your network card? (you can find out by doing
"lspci|grep -i ether", usually)

Best regards,
Marcus

On 02/22/2016 10:36 PM, Maria Christopoulou wrote:
> Hello,
>
> I have the following system configuration:
>
> Ubuntu 14.04, 64-bit, 3.17.0-lowlatency
> Gnuradio v3.7.8
> and a USRP N2930, with UHD_003.009 version installed.
>
> The script uhd_find_devices works properly and the output of
> uhd_usrp_probe is the following:
>
> https://drive.google.com/file/d/0B9y0kqNk6AFgNnpFLWcwZ2E4WDQ/view?usp=sharing
>
>
> When I execute the uhd_fft.grc flowgraph, the program runs for a few
> seconds but suddenly freezes, showing the following output in the
> terminal:
>
> https://drive.google.com/file/d/0B9y0kqNk6AFgY2NpdW0yS2sxMDA/view?usp=sharing
>
> Could you please give me some guidelines to solve this issue?
>
>
> Best regards,
> Maria Christopoulou
>
>
> ___
> 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] gr-channel: adding ETSI/3GPP channel model taps

[Bastian Bloessl]

Hi,

I’m working on something similar. I’m also trying to map channel parameters to 
input parameters for the gr-channel blocks and validate the results.

I wondered whether there were any news on that and whether the python code is 
available somewhere.

Best,
Bastian

> On 30 Dec 2015, at 02:33, Marcus Müller  wrote:
> 
> I must admit I did that, but feel unsure about how many sines I'd need to use 
> to simulate spread.
> The result I got with 8 and standard doppler spread don't look overly 
> healthy, and osmocore/gr-gsm has a hard time understanding noise-free 
> synthetic bcch bursts after going through the fading model.
> Any advice on that?
> 
> Best regards,
> Marcus
> 
> Am 29. Dezember 2015 22:16:53 MEZ, schrieb Johnathan Corgan 
> :
> On Tue, Dec 29, 2015 at 11:50 AM, Marcus Müller  > wrote:
>  
> ETSI TS 145 005 V[1] specifies the relevant GSM channel models.
> 
> I do have a bit of python code that converts those to 10MS/s sampled
> FIRs. Should I just add something to gr-channels python code that gives
> you FIR taps for different of these models?
> 
> ​It would be useful to see how well the Annex C tables can be mapped to the 
> Frequency Selective Fading Model block parameters and do some resulting 
> simulations with these.  The block simulates the time-varying effects of 
> doppler and Rician/Rayleigh fading given a power delay profile and other 
> relevant parameters.​ 
> 

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

Re: [Discuss-gnuradio] uhd_fft.grc: fifo ctrl timed out looking for acks

[Gregory Ratcliff]

Marcus,

Just so that Maria doesn't get too confused, I think you meant:
> 192.168.10.XXX network (except .2), and configure the network manager for 
> "static" addressing.

Greg

> On Feb 22, 2016, at 4:53 PM, Marcus Müller  wrote:
> 
> Hello Maria,
> 
> the reason I most often encountered for this is that in the middle of 
> operation, Ubuntu decided to reconfigure the network interface. Make sure you 
> set the network interface to a valid address from the 19.168.10.XXX network 
> (except .2), and configure the network manager for "static" addressing.
> 
> also, for some reason, your USRP's subnet mask as reported by uhd_usrp_probe 
> seems wrong; it should be something like 255.255.255.0, not 255.255.255.255.
> 
> By the way, what is your network card? (you can find out by doing "lspci|grep 
> -i ether", usually)
> 
> Best regards,
> Marcus
> 
>> On 02/22/2016 10:36 PM, Maria Christopoulou wrote:
>> Hello,
>> 
>> I have the following system configuration:
>> 
>> Ubuntu 14.04, 64-bit, 3.17.0-lowlatency
>> Gnuradio v3.7.8
>> and a USRP N2930, with UHD_003.009 version installed.
>> 
>> The script uhd_find_devices works properly and the output of uhd_usrp_probe 
>> is the following: 
>> 
>> https://drive.google.com/file/d/0B9y0kqNk6AFgNnpFLWcwZ2E4WDQ/view?usp=sharing
>> 
>> 
>> When I execute the uhd_fft.grc flowgraph, the program runs for a few seconds 
>> but suddenly freezes, showing the following output in the terminal:
>> 
>> https://drive.google.com/file/d/0B9y0kqNk6AFgY2NpdW0yS2sxMDA/view?usp=sharing
>> 
>> Could you please give me some guidelines to solve this issue?
>> 
>> 
>> Best regards,
>> Maria Christopoulou
>> 
>> 
>> ___
>> 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] (no subject)

[Don Latham]

OK, I was dumb enough to do upgrades to my Ubuntu 15.1. I had UHD and grc
running nicely, with B200, and suddenly, after update, :

djl@CRUNCHER4:~$ grc -s
Generic Colouriser 1.9
grc [options] command [args]
Options:")
-e --stderrredirect stderr. If this option is selected,
   do not automatically redirect stdout
-s --stdoutredirect stdout, even if -e is selected
-c name --config=nameuse name as configuration file for grcat
--colour=word  word is one of: on, off, auto

\
NOW WHAT THE HECK

-- 
Felix qui potuit rerum cognoscere causas.
Lucky is he who has been able to understand the causes of things.
Virgil
---
"Noli sinere nothos te opprimere"

Dr. Don Latham, AJ7LL
Six Mile Systems LLC, 17850 Six Mile Road
Huson, MT, 59846
mailing address:  POBox 404
Frenchtown MT 59834-0404

VOX 406-626-4304
CEL 406-241-5093
Skype: buffler2
www.lightningforensics.com
www.sixmilesystems.com



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

Re: [Discuss-gnuradio] (no subject)

[Marcus D. Leech]

On 02/22/2016 09:47 PM, Don Latham wrote:

OK, I was dumb enough to do upgrades to my Ubuntu 15.1. I had UHD and grc
running nicely, with B200, and suddenly, after update, :

djl@CRUNCHER4:~$ grc -s
Generic Colouriser 1.9
grc [options] command [args]
Options:")
-e --stderrredirect stderr. If this option is selected,
do not automatically redirect stdout
-s --stdoutredirect stdout, even if -e is selected
-c name --config=nameuse name as configuration file for grcat
--colour=word  word is one of: on, off, auto

\
NOW WHAT THE HECK

The actual command-name for "grc" was changed to "gnuradio-companion" 
quite some time ago (years), due to a naming conflict.




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

[Discuss-gnuradio] grc

[Don Latham]

So, per my last, apparently anybody can just assign a name to anything
regardless of previous use? I was able to run gnuradio GRC by using an already
saved grc example. So  I guess there is a way around the problem.
thanks. No more updates!



-- 
Felix qui potuit rerum cognoscere causas.
Lucky is he who has been able to understand the causes of things.
Virgil
---
"Noli sinere nothos te opprimere"

Dr. Don Latham, AJ7LL
Six Mile Systems LLC, 17850 Six Mile Road
Huson, MT, 59846
mailing address:  POBox 404
Frenchtown MT 59834-0404

VOX 406-626-4304
CEL 406-241-5093
Skype: buffler2
www.lightningforensics.com
www.sixmilesystems.com



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

Re: [Discuss-gnuradio] grc

[Marcus D. Leech]

On 02/22/2016 09:59 PM, Don Latham wrote:

So, per my last, apparently anybody can just assign a name to anything
regardless of previous use? I was able to run gnuradio GRC by using an already
saved grc example. So  I guess there is a way around the problem.
thanks. No more updates!



Actually, the previous "grc" pre-dates GnuRadio Companion by several 
years.   And, it's a very-large open-source Universe, and
  name collisions, particularly for 3-character names, are nearly 
inevitable.   There is no  "controlling authority".


If you find yourself wanting to started Gnu Radio Companion manually, 
just type:


gnuradio-companion

Into a terminal window.



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

Re: [Discuss-gnuradio] uhd_fft.grc: fifo ctrl timed out looking for acks

[Marcus Müller]

Indeed! Thanks for jumping in!

Am 23. Februar 2016 00:04:10 MEZ, schrieb Gregory Ratcliff :
>Marcus,
>
>Just so that Maria doesn't get too confused, I think you meant:
>> 192.168.10.XXX network (except .2), and configure the network manager
>for "static" addressing.
>
>Greg
>
>> On Feb 22, 2016, at 4:53 PM, Marcus Müller 
>wrote:
>> 
>> Hello Maria,
>> 
>> the reason I most often encountered for this is that in the middle of
>operation, Ubuntu decided to reconfigure the network interface. Make
>sure you set the network interface to a valid address from the
>19.168.10.XXX network (except .2), and configure the network manager
>for "static" addressing.
>> 
>> also, for some reason, your USRP's subnet mask as reported by
>uhd_usrp_probe seems wrong; it should be something like 255.255.255.0,
>not 255.255.255.255.
>> 
>> By the way, what is your network card? (you can find out by doing
>"lspci|grep -i ether", usually)
>> 
>> Best regards,
>> Marcus
>> 
>>> On 02/22/2016 10:36 PM, Maria Christopoulou wrote:
>>> Hello,
>>> 
>>> I have the following system configuration:
>>> 
>>> Ubuntu 14.04, 64-bit, 3.17.0-lowlatency
>>> Gnuradio v3.7.8
>>> and a USRP N2930, with UHD_003.009 version installed.
>>> 
>>> The script uhd_find_devices works properly and the output of
>uhd_usrp_probe is the following: 
>>> 
>>>
>https://drive.google.com/file/d/0B9y0kqNk6AFgNnpFLWcwZ2E4WDQ/view?usp=sharing
>>> 
>>> 
>>> When I execute the uhd_fft.grc flowgraph, the program runs for a few
>seconds but suddenly freezes, showing the following output in the
>terminal:
>>> 
>>>
>https://drive.google.com/file/d/0B9y0kqNk6AFgY2NpdW0yS2sxMDA/view?usp=sharing
>>> 
>>> Could you please give me some guidelines to solve this issue?
>>> 
>>> 
>>> Best regards,
>>> Maria Christopoulou
>>> 
>>> 
>>> ___
>>> 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

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