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

[Sylvain Munaut]

Hi,

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

?!?

Cellphones made in the last 10+ years are all SDRs. Same thing for the
network equipment (probably even more so).
Pretty much all test equipment with signals analysis has an SDR inside

Not really sure how much more common place you can get.

The fact that there are more and more cheap devices where you can
extract the IQ data and use with other apps than just the vendor
provided stuff is recent-ish. But SDR's themselves are insanely
common.


Cheers,

Sylvain Munaut

___
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

[Kelvin Augustin]

Hi Bastian,



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

Exactly. The dynamic channel in GNURadio models the Doppler spectrum
accurately.

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.
>
> To answer this, I would consider of the correspondence (via a Fourier
Transform) of a Doppler shift in the time domain; A shift in frequency
corresponds to a "time" dependant phase shift in the time domain. Thus a
Doppler shift of Fd in the time domain corresponds to exp(j*2*pi*Fd*t). And
since Dynamic channel model(flat_fader to be precise) in GNURadio models
the Doppler in the time domain, the d_m could be a way to model the time.

I would also ask a supplementing question that I am having problems
understanding. I would expect the Doppler shift to be modelled by a complex
exponential(cos[2*pi*Fd*t*cos(alpha)] + i sin [2*pi*Fd*t*cos(alpha)]) which
corroborates what we know from the Fourier correspondence of a Doppler
shift. Why then, in the Dynamic channel model in GNURadio (flat_fader to be
precise), the Doppler is modelled by (cos[2*pi*Fd*t*cos(alpha)] + i cos
[2*pi*Fd*t*sin(alpha)]) ?? I.e why is the imaginary part a cos ? Any hints?


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


-- 
Ph.D. scholar: Kelvin Chelli
OFDM based wireless systems
Telecommunications Lab, Uni Saarland
Campus C6 3, Room  10.07
66123 Saarbrücken, Germany. 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] FOSDEM videos

[jean-michel . friedt]

The videos of the FOSDEM talks are now available at
https://video.fosdem.org/2016/aw1125/

Status:
OK: 'Building Self-Optimizing Radios using DEAP'
OK: 'Embedded SDR'
OK: 'News from the OAI Community'
OK: 'Prototyping the 5G Air Interface in GNU Radio: An FBMC Primer'
OK: 'Radio Machine Learning with FOSS'
OK: 'RFNoC -- Evolving SDR toolkits to the FPGA platform'
OK: 'SDR Track Panel'
OK: 'srsUE: A high-performance software radio LTE UE'
OK: 'Synchronization in distributed SDR for localization applications'
OK: 'The GNU Radio Companion Changelog'
OK: 'The rad1o badge'
OK: 'Using Red Pitaya for radio applications (from LF to HF)'
OK: 'Wideband measurement strategies: from RADAR to passive wireless
sensors' 
PARTIAL: (no slides) 'Introduction to the SDR Track'
PARTIAL: (no slides) 'The GNU Radio Toolkit'
PARTIAL: 'Signal Intelligence Challenges'

JM

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

Sorry for my ignorance, I was only talking from my personal experience.
On Feb 23, 2016 01:34, "Sylvain Munaut" <246...@gmail.com> wrote:

> Hi,
>
> > 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.
>
> ?!?
>
> Cellphones made in the last 10+ years are all SDRs. Same thing for the
> network equipment (probably even more so).
> Pretty much all test equipment with signals analysis has an SDR inside
>
> Not really sure how much more common place you can get.
>
> The fact that there are more and more cheap devices where you can
> extract the IQ data and use with other apps than just the vendor
> provided stuff is recent-ish. But SDR's themselves are insanely
> common.
>
>
> Cheers,
>
> Sylvain Munaut
>
___
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]

> On 23 Feb 2016, at 02:35, Kelvin Augustin  wrote:
> 
> Hi Bastian
> 
> 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.
> 
> To answer this, I would consider of the correspondence (via a Fourier 
> Transform) of a Doppler shift in the time domain; A shift in frequency 
> corresponds to a "time" dependant phase shift in the time domain. Thus a 
> Doppler shift of Fd in the time domain corresponds to exp(j*2*pi*Fd*t). And 
> since Dynamic channel model(flat_fader to be precise) in GNURadio models the 
> Doppler in the time domain, the d_m could be a way to model the time. 

Yes, I understand that d_m is like time here, and it would be perfectly fine if 
fD would stay constant during the whole simulation.

But as fD changes over time, the phase change from one sample to another (due 
to the same change in dopplers shift) will be amplified over time. AFAIS, this 
changes the autocorrelation properties over time.

I would have expected something like

tap[n+1] = tap[n] exp(2*pi*i*fD*cos(alpha))

Best,
Bastian

> 
> I would also ask a supplementing question that I am having problems 
> understanding. I would expect the Doppler shift to be modelled by a complex 
> exponential(cos[2*pi*Fd*t*cos(alpha)] + i sin [2*pi*Fd*t*cos(alpha)]) which 
> corroborates what we know from the Fourier correspondence of a Doppler shift. 
> Why then, in the Dynamic channel model in GNURadio (flat_fader to be 
> precise), the Doppler is modelled by (cos[2*pi*Fd*t*cos(alpha)] + i cos 
> [2*pi*Fd*t*sin(alpha)]) ?? I.e why is the imaginary part a cos ? Any hints?
>  
> 
> 
>> On 22 Feb 2016, at 06:41, Nasi mailto: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 
>> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 
> 
> 
> 
> 
> 
> -- 
> Ph.D. scholar: Kelvin Chelli
> OFDM based wireless systems
> Telecommunications Lab, Uni Saarland
> Campus C6 3, Room  10.07
> 66123 Saarbrücken, Germany.

___
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 Martin,

just checking here: Do you understand the full design of the rx_ofdm and 
tx_ofdm flow graphs
I do understand the overall design (at least for my uses)


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. 
Is there a way to limit the buffer size or something like that? What I would 
like is to avoid a situation where the Random Source produced 10**6 bytes while 
only 10**3 bytes were produced and the end.



Best Regards.


On February 22, 2016 at 15:06:57, Martin Braun (martin.br...@ettus.com) wrote:

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  
-- 
Maicon Kist
___
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

[Mabel Pita]

Hi,

Thank you so much for your answers.
Maybe i did not express myself correctly in my original mail.
I am taking a course on SDRs at my university, and an assignment is to do
some research about SDRs, especially on the state of the art of SDR, by
this i mean, the most cutting edge technology that is available nowadays on
the field. I have not been able to found information about this on the
internet, just different frameworks used for developing SDRs. However, i
have  to justify somehow, that gnu radio is useful for serious academical
research and not a program for modest projects (not that i think that is
this way but i have to justify it somehow). For example, quote some
important projects developed in gnuradio, or important companies working
with gnu radio, etc.

Are there any books or papers that investigate this matter, and explain
thoroughly what is the most advanced technology to perform virtualization
of signal processing and why gnu radio is a good choice for this task?


Thanks in advance.

2016-02-22 18:22 GMT-03:00 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] gnuradios place in the state of the art of SDR

[Maicon Kist]

You probably will want to look at the papers published in this call for papers:

http://www.comsoc.org/commag/cfp/software-defined-radio-20-years-later



On February 23, 2016 at 17:05:49, Mabel Pita (mabel.pita2...@gmail.com) wrote:

Hi,

Thank you so much for your answers.
Maybe i did not express myself correctly in my original mail.
I am taking a course on SDRs at my university, and an assignment is to do some 
research about SDRs, especially on the state of the art of SDR, by this i mean, 
the most cutting edge technology that is available nowadays on the field. I 
have not been able to found information about this on the internet, just 
different frameworks used for developing SDRs. However, i have  to justify 
somehow, that gnu radio is useful for serious academical research and not a 
program for modest projects (not that i think that is this way but i have to 
justify it somehow). For example, quote some important projects developed in 
gnuradio, or important companies working with gnu radio, etc.

Are there any books or papers that investigate this matter, and explain 
thoroughly what is the most advanced technology to perform virtualization of 
signal processing and why gnu radio is a good choice for this task?


Thanks in advance.

2016-02-22 18:22 GMT-03:00 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  
-- 
Maicon Kist
___
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

[mleech]

 

Also, the question is somewhat bifurcated. There are two aspects: 

 (a) Which parameters in the hardware end of things have advanced, and
at what rate, and what is considered "state of the art". This gets
broken down into a few sub-categories: 

 o ADC/DAC speeds 

 o FPGA gate-counts and speed 

 o frequency-range of the analog front-ends, and analog performance
(noise figure, OIP3, etc) 

 (b) Advances in GPP hardware that support high-speed DSP on a regular
computer, and somewhat orthogonal to that, what "kewl new stuff" has
been implemented, and at what rate does that happen, and where can we
expect the "art" to evolve. 

On 2016-02-23 15:09, Maicon Kist wrote: 

> You probably will want to look at the papers published in this call for 
> papers: 
> 
> http://www.comsoc.org/commag/cfp/software-defined-radio-20-years-later [1] 
> 
> On February 23, 2016 at 17:05:49, Mabel Pita (mabel.pita2...@gmail.com) 
> wrote: 
> 
> Hi, 
> 
> Thank you so much for your answers. 
> Maybe i did not express myself correctly in my original mail. 
> I am taking a course on SDRs at my university, and an assignment is to do 
> some research about SDRs, especially on the state of the art of SDR, by this 
> i mean, the most cutting edge technology that is available nowadays on the 
> field. I have not been able to found information about this on the internet, 
> just different frameworks used for developing SDRs. However, i have to 
> justify somehow, that gnu radio is useful for serious academical research and 
> not a program for modest projects (not that i think that is this way but i 
> have to justify it somehow). For example, quote some important projects 
> developed in gnuradio, or important companies working with gnu radio, etc. 
> 
> Are there any books or papers that investigate this matter, and explain 
> thoroughly what is the most advanced technology to perform virtualization of 
> signal processing and why gnu radio is a good choice for this task? 
> 
> Thanks in advance. 
> 
> 2016-02-22 18:22 GMT-03:00 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 t

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

[Maria Christopoulou]

Hello,

The output of "lspci|grep -i ether" is:

*00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-V*
*02:00.0 Ethernet controller: Qualcomm Atheros AR8161 Gigabit Ethernet (rev
10) (this is eth0)*

I am doing the following: *sudo ifconfig eth0 192.168.10.1 netmask
255.255.255.0*

I have also configured* /etc/network/interfaces* like this:

*# interfaces(5) file used by ifup(8) and ifdown(8)*
*auto lo*
*iface lo inet loopback*

*auto eth0*
*iface eth0 inet static*
*address 192.168.10.1*
*netmask 255.255.255.0*
*gateway 0.0.0.0*


However, in the Network Connections menu, the IPv4 settings are:
Address: 192.168.10.3
Netmask: 255.255.255.0
Gateway: 0.0.0.0

and the Method is set to "Manual", for static IP addressing.

It seems that the Network Manager doesn't take into account the ifconfig
command.
Do you think that this could cause the problem?

Regarding the netmask of the USRP, it seems like a default value. Could it
be related to this?


Thank you,
Maria

2016-02-23 8:41 GMT+02:00 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 
>> 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
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Subject: Re: Expresscard

[Nathan Dehnel]

-- Forwarded message --
>From: "Marcus Müller" 
>To: discuss-gnuradio@gnu.org
>Cc:
>Date: Mon, 22 Feb 2016 22:24:27 +0100
>Subject: Re: [Discuss-gnuradio] Expresscard
>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?

I'm just getting into this, so I'm sorry if I don't know much, but I was
just looking for some sort of SDR equipment to experiment with that I could
put in a laptop expresscard slot and forget about. Something that could be
carried around in the laptop. I've been reading about RTL-SDR, so something
with similar capabilities to that would be nice, or if something better
exists, that would be fine too, as long as it's not thousands of dollars or
something.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] message ports

[Dennis Glatting]

I'm having a problem with message ports. I am trying to have a separate
thread within within the block periodically post messages.

The block is defined as:


  GenAudio
  acars_GenAudio_x
  acars
  import acars

  acars.GenAudio($rate,$rounding,$fake)
  set_rate($rate)
  set_rounding($rounding)
  set_fake($fake)
...
  
in
message
1
  
  
  
out
complex
  


Within the constructor of my block is the code:


      d_port_id = pmt::mp( "in" );
  message_port_register_in( d_port_id );
  set_msg_handler( d_port_id,
   boost::bind( &GenAudio_impl::_msgh, this, _1 ));
...
      d_faker = std::thread([this](){ this->_thread_faker();});

The goal is other blocks may be connected to this block's input message
port to encode messages but for testing the periodic thread sends
messages to itself.

Within the periodic thread is the code:

    void
GenAudio_impl::_thread_faker( void ) {
...
          pmt::pmt_t target = pmt::PMT_NIL;

  message_port_sub(   d_port_id, target );
  message_port_pub(   d_port_id, m );
  message_port_unsub( d_port_id, target );
...

The problem is the run time is throwing an exception with the message:

 what(): Port does not exist: "in" on block: ()


I dumped the block's message ports and there is one named "in" so I
don't understand the error message. Is my code snippet NOT how messages
work?







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

[Discuss-gnuradio] WBX Dual Receiver

[Justyn]

Hello,

I'm experimenting with the MIMO capabilities of the N210s with WBX 
daughter cards and seeing how far I can get before I need the MIMO 
breakout cable or GPSDO.


One of the first things I'd like to see is if both receivers on the WBX 
daughter card can run at the same time (TX/RX and RX2).


Unfortunately, if I add two USRP source blocks with the same IP to my 
flow graph and try it out, I get D's on the output.


According to 
http://files.ettus.com/manual/page_general.html#general_ounotes, it 
seems that I'm getting "discontinuous packets" and are subsequently 
dropping data (which I can confirm).  I assume it's because I'm 
receiving data packets with the same source address, and probably 
duplicated sequence numbers which GNU Radio thinks are discontinuous.


Is there a way around this? Is this a bug?  It seems if I have the 
bandwidth and physical hardware, I should be able to leverage those 
capabilities, no?


This USRP and my workstation are connected through a switch, but if I 
add a separate identical N210 with WBX to the switch, I get both sets of 
data, so it's not a bandwidth issue.


--
Justyn

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

Re: [Discuss-gnuradio] WBX Dual Receiver

[Marcus D. Leech]

On 02/23/2016 11:22 PM, Justyn wrote:

Hello,

I'm experimenting with the MIMO capabilities of the N210s with WBX 
daughter cards and seeing how far I can get before I need the MIMO 
breakout cable or GPSDO.


One of the first things I'd like to see is if both receivers on the 
WBX daughter card can run at the same time (TX/RX and RX2).


Unfortunately, if I add two USRP source blocks with the same IP to my 
flow graph and try it out, I get D's on the output.


According to 
http://files.ettus.com/manual/page_general.html#general_ounotes, it 
seems that I'm getting "discontinuous packets" and are subsequently 
dropping data (which I can confirm).  I assume it's because I'm 
receiving data packets with the same source address, and probably 
duplicated sequence numbers which GNU Radio thinks are discontinuous.


Is there a way around this? Is this a bug?  It seems if I have the 
bandwidth and physical hardware, I should be able to leverage those 
capabilities, no?


This USRP and my workstation are connected through a switch, but if I 
add a separate identical N210 with WBX to the switch, I get both sets 
of data, so it's not a bandwidth issue.


--
Justyn
There is only a single receive chain on a WBX card--there are, granted, 
two ANTENNA PORTS that may be selected that the receive chain

  attaches to, but there really is only one receive chain on a WBX card.

The fact that you have two distinct UHD/USRP objects trying to 
communicate with the same physical USRP is going to create a fair amount
  of confusion in the lower layers which will result in unpredictable 
behaviour.




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

Re: [Discuss-gnuradio] WBX Dual Receiver

[Marcus D. Leech]

On 02/23/2016 11:34 PM, Justyn wrote:

Makes sense.

If I can ask a follow up here:

1) If I instead use 2 USRPs connected via an external reference clock 
and an Ethernet switch for receiving data, will they be 
phase-aligned?  If I understand what's going on in the context of the 
ref clock, I think this is a yes.
Assuming that you have an external reference, and 1PPS to 
time-synchronize them, and you use timed-commands to properly assert
  the phase-resynch logic in the synthesizers, then yes, with the 
proviso that WBX in particular uses a 2XLO mixer, which has a
  180 deg phase ambiguity--since there's no way to predict or control 
the start state of the flip-flop inside the mixer that's used as

  a phase-splitter.  So they'll either be aligned, or 180deg out-of-phase.



However,

2)  On the TX end, if I use two USRPs connected to an Ethernet switch, 
and synchronized by an external clock connected to the ref clock port, 
is there any way I can guarantee that the first samples of each are 
sent out at the same "time" (I don't know what the appropriate term 
would be here, time, clock cycle, ref clock tick, etc)?  I suspect 
that unless there's a mechanism that does this, this is a no.
If you have both USRPs in a common multi_usrp object, then their outputs 
will be time-aligned.  The same comments above about
  using timed-commands for tuning, and the 180deg phase-ambiguity 
continue to apply here.


Now the issue is that with GRC, there's no way to use timed-commands 
directly, so you end up either coding in naked python/C++ yourself,
  or modifying the code generated by GRC to wrap the tuning functions 
in UHD timed commands.





--
Justyn

On 02/23/2016 08:26 PM, Marcus D. Leech wrote:

On 02/23/2016 11:22 PM, Justyn wrote:

Hello,

I'm experimenting with the MIMO capabilities of the N210s with WBX 
daughter cards and seeing how far I can get before I need the MIMO 
breakout cable or GPSDO.


One of the first things I'd like to see is if both receivers on the 
WBX daughter card can run at the same time (TX/RX and RX2).


Unfortunately, if I add two USRP source blocks with the same IP to 
my flow graph and try it out, I get D's on the output.


According to 
http://files.ettus.com/manual/page_general.html#general_ounotes, it 
seems that I'm getting "discontinuous packets" and are subsequently 
dropping data (which I can confirm).  I assume it's because I'm 
receiving data packets with the same source address, and probably 
duplicated sequence numbers which GNU Radio thinks are discontinuous.


Is there a way around this? Is this a bug?  It seems if I have the 
bandwidth and physical hardware, I should be able to leverage those 
capabilities, no?


This USRP and my workstation are connected through a switch, but if 
I add a separate identical N210 with WBX to the switch, I get both 
sets of data, so it's not a bandwidth issue.


--
Justyn
There is only a single receive chain on a WBX card--there are, 
granted, two ANTENNA PORTS that may be selected that the receive chain

  attaches to, but there really is only one receive chain on a WBX card.

The fact that you have two distinct UHD/USRP objects trying to 
communicate with the same physical USRP is going to create a fair amount
  of confusion in the lower layers which will result in unpredictable 
behaviour.




___
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] WBX Dual Receiver

[Justyn]

Forgive me because I'm a software engineer with little theoretical comms 
experience, but I'm having a difficult time understanding what a 180 
phase shift at RF would mean for my baseband signal.  If anything.


Now the issue is that with GRC, there's no way to use timed-commands 
directly, so you end up either coding in naked python/C++ yourself,
  or modifying the code generated by GRC to wrap the tuning functions 
in UHD timed commands. 


Timed commands are the mechanism for time synchronization I was looking 
for, I think.  I have a sample C++ application that I've written a while 
ago to directly interface with the UHD.  Although if there's a more 
complete example, I would like to see that.


If I get a MIMO cable, can I avoid these timed events, and possibly use 
GRC?  The application I'm working on serves a primary purpose, but is 
also meant as a learning experience for a group of students so keeping 
it within GRC would be ideal for future development.


--
Justyn

On 02/23/2016 08:46 PM, Marcus D. Leech wrote:

On 02/23/2016 11:34 PM, Justyn wrote:

Makes sense.

If I can ask a follow up here:

1) If I instead use 2 USRPs connected via an external reference clock 
and an Ethernet switch for receiving data, will they be 
phase-aligned?  If I understand what's going on in the context of the 
ref clock, I think this is a yes.
Assuming that you have an external reference, and 1PPS to 
time-synchronize them, and you use timed-commands to properly assert
  the phase-resynch logic in the synthesizers, then yes, with the 
proviso that WBX in particular uses a 2XLO mixer, which has a
  180 deg phase ambiguity--since there's no way to predict or control 
the start state of the flip-flop inside the mixer that's used as
  a phase-splitter.  So they'll either be aligned, or 180deg 
out-of-phase.




However,

2)  On the TX end, if I use two USRPs connected to an Ethernet 
switch, and synchronized by an external clock connected to the ref 
clock port, is there any way I can guarantee that the first samples 
of each are sent out at the same "time" (I don't know what the 
appropriate term would be here, time, clock cycle, ref clock tick, 
etc)?  I suspect that unless there's a mechanism that does this, this 
is a no.
If you have both USRPs in a common multi_usrp object, then their 
outputs will be time-aligned.  The same comments above about
  using timed-commands for tuning, and the 180deg phase-ambiguity 
continue to apply here.


Now the issue is that with GRC, there's no way to use timed-commands 
directly, so you end up either coding in naked python/C++ yourself,
  or modifying the code generated by GRC to wrap the tuning functions 
in UHD timed commands.





--
Justyn

On 02/23/2016 08:26 PM, Marcus D. Leech wrote:

On 02/23/2016 11:22 PM, Justyn wrote:

Hello,

I'm experimenting with the MIMO capabilities of the N210s with WBX 
daughter cards and seeing how far I can get before I need the MIMO 
breakout cable or GPSDO.


One of the first things I'd like to see is if both receivers on the 
WBX daughter card can run at the same time (TX/RX and RX2).


Unfortunately, if I add two USRP source blocks with the same IP to 
my flow graph and try it out, I get D's on the output.


According to 
http://files.ettus.com/manual/page_general.html#general_ounotes, it 
seems that I'm getting "discontinuous packets" and are subsequently 
dropping data (which I can confirm).  I assume it's because I'm 
receiving data packets with the same source address, and probably 
duplicated sequence numbers which GNU Radio thinks are discontinuous.


Is there a way around this? Is this a bug?  It seems if I have the 
bandwidth and physical hardware, I should be able to leverage those 
capabilities, no?


This USRP and my workstation are connected through a switch, but if 
I add a separate identical N210 with WBX to the switch, I get both 
sets of data, so it's not a bandwidth issue.


--
Justyn
There is only a single receive chain on a WBX card--there are, 
granted, two ANTENNA PORTS that may be selected that the receive chain
  attaches to, but there really is only one receive chain on a WBX 
card.


The fact that you have two distinct UHD/USRP objects trying to 
communicate with the same physical USRP is going to create a fair 
amount
  of confusion in the lower layers which will result in 
unpredictable behaviour.




___
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