Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

[Cinaed Simson]

You have a plumbing problem.

On 02/18/2017 08:29 AM, Robin A. Jensen wrote:
> Hello all of you.
> 
> I've just recieved my RTL-SDR dongle and is all new to this sdr-stuff,
> so please bear over with me, if i'm at the wrong place.
> I'm using GNU Radio Companion on a RPi 3 and no mather what i'll do, i
> can't get the sound to work.
> If a'im using rtl_fm and aplay, i'll get sound but it won't set on the
> radiostation. I'll take on that later.
> I've createt a small FM Reciever in GNU Radio companion and everytime
> i'll execute the script i'll get an error:
> 
> RuntimeError.audio.alsa.sink
> 
> I've been all over the internet to find a solution but with no luck.
> So now i'm have a hope that this mailling list can help me?
> 
> My setup is:
> RTL-SDR Source: samplerate:  2M, frequency 96.5 MHz ->
> Rationel Sampler: Interpolation 4, Decimation: 1 ->

At this point, the sampling rate is 8 MHz.

If the interpolation was 1 and decimation 4 then the sampling rate would
be 500 kHz.

> Low Pass Filter: Sample rate: 2M, Cutoff freq: 100K, Transition Width:
> 100k ->

No indication of any decimation in the low pass filter - assuming a
decimation of 1 - or none.

> WBFM Recive: Quadrature: 500K, Audio Decimation: 1 ->
> Rationel Sampler: Interpolation: 500
> Decimation: 48 ->

Assuming a decimation of 1 in your low pass filter, the audio sampling
rate would now be 83 MHz.

Again, you need to reverse things - decimate at 500 kHz and interpolate
at 48 kHz.

I'd recommend deleting the first rational sample and decimating by 4 in
the low pass filter.

In short, interpolation up samples and decimation down samples.


> Audio Sink: Sample Rate: 48 KHz, Device Name: HW:0,0
> 
> I've found that recipie on a Hack5 video and there it's working
> 
> With best regards
> Robin.
> 
> 
> ___
> 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] Multiport delay block

[Marcus D. Leech]

Is there a way to arrange for each stream in a multi-port delay block to 
have a different delay?  The setter function seems to take an
  int, but ideally, if it could take a list of ints, that would make 
the block (in the multi-port) case much more useful.


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

[Discuss-gnuradio] Suggestions on GSoC project idea for HTML-based GUI

[Kartik Patel]

Hello all,

I was thinking on the project for HTML Based GUI for GNU Radio Applications. I
have developed the probable workflow of the final OOT. I want some
comments/suggestions/feedback on this flow. The details of the project is
available here.
--First of all, I have gone through the Plotly library and Bokeh
library. I believe Bokeh library is a perfect choice for the task. Plotly has
excellent charts, but all other tasks like Socket creation, data flow, serving
the data etc. is needed to be done manually using other frameworks. On the other
hand, serving the python app is among the main features of Bokeh library.

Currently GNU Radio generates a Python filetop_block.py. It has all config
options of QtGui Sinks and input tools. Similarly, in the HTML based GUI, it
will have all config options related to HTML based GUI just like the current
one. Also,bokehhas input tools which can be used as the inputs on HTML page. So,
basically instances of sinks and input tools will be defined intop_block.py
Upon executing it, a Bokeh server will start at some port. The Bokeh server
takes care of frontend and backend socket connections. Hence, the task is to
create instances corresponding to each sink/inputs of the Bokeh plots/input and
then simply serve through the Bokeh server. It should be noted that, all the
calculations for plots will remain same as done in QtGUI.
During the execution:top_block.start()starts the simulation.top_block.show()will
serve the Bokeh application.---Also, I have some doubts related to
current implementation of QTGUI and in proposed workflow: 1. Theblock::work 
function returns new data. It should be received in a python
file and it should accordingly redefine the structure of the new data to
send to Bokeh server. Am I correct?
 2. I am unable to
understand is, where exactly it is written that the plots should be
continuous updated? I see thetrigger_mode is doing the task. But even with
trigger_mode=FREE, how is it continuously updating? According to our design,
there should be a similar flow, which will stream the data to Bokeh server.
 3. This is most
important: Where exactly the GUI is turned on? Which file/class/function
iterates through all sinks in flowgraph? I think, that should be the point
where the Bokeh server turns on. I see that thetop_block.show()calls the
function and there is ascheduler that plans out the task. But I couldn't
understand the connection betweentop_blockandgr-qtgui.

Thank you very much for your help. If you are unable to understand any specific
detail, kindly ping me.
Regards,Kartik Patel___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Companion - ALSA

[Marcus Müller]

Hi Robin,

first of all: Welcome to the GNU Radio community!


On 02/18/2017 05:29 PM, Robin A. Jensen wrote:
> Hello all of you.
>
> I've just recieved my RTL-SDR dongle and is all new to this sdr-stuff,
> so please bear over with me, if i'm at the wrong place.
> I'm using GNU Radio Companion on a RPi 3 and no mather what i'll do, i
> can't get the sound to work.
> If a'im using rtl_fm and aplay, i'll get sound but it won't set on the
> radiostation.
aha, so that's good, the sound system as it does work.
You'll probably want to use "aplay -L" to find the possible ALSA device
names that you can use in the GNU Radio Audio sink.
> I'll take on that later.
> I've createt a small FM Reciever in GNU Radio companion and everytime
> i'll execute the script i'll get an error:
>
> RuntimeError.audio.alsa.sink
Hm, I've never seen a GNU Radio error being printed like this; but that
might just be me. However, I can't reproduce this error printing shape
as hard as I try.
>
> I've been all over the internet to find a solution but with no luck.
> So now i'm have a hope that this mailling list can help me?
>
My suspicion is that your audio device doesn't like the sampling rate
your trying to use, or you need to specify a device name (or both). Can
you make things work on the PC you use to design these flow graphs?

I'd start with a signal source (sampling rate == the sampling rate that
you set in your Audio sink), configured to produce a "float" output sine
of 1 kHz, directly connected to an Audio sink. If that works, move on.



What I say about the flow graph in the following has, as far as I can
tell, nothing to do with the error you're getting. Still, there's
mistakes in the flow graph that would make it impossible to successfully
run it, and thus I'd like to avoid frustration later on by pointing them
out know:


So, the main issue with your flow graph is that the sampling rate at the
audio sink must be what you configured your audio sink for (48 kHz).
But: that rate is the result of your SDR's sampling rate (2MS/s),
multiplied with all interpolations, divided by all decimations in the
path between.

> My setup is:
> RTL-SDR Source: samplerate:  2M, frequency 96.5 MHz ->
> Rationel Sampler: Interpolation 4, Decimation: 1 ->
Uh, that means that you have now 8MS/s. That seems unnecessary, since to
capture a <100 kHz wide FM channel, you wouldn't even need the 2MS/s you get
> Low Pass Filter: Sample rate: 2M, Cutoff freq: 100K, Transition Width:
> 100k ->
Which contradicts the 2MS/s used here, so you're actually getting 400kHz
passband width, 400kHz transition width. Also, this feels like a prime
candidate for including decimation in the filter (because the resulting
bandwidth is 200 kHz (if you overlap the two transition widths), and for
that you'd only need 200 kS/s of complex digital signal).
> WBFM Recive: Quadrature: 500K, Audio Decimation: 1 ->
This is now off by a factor of 16; are you sure you should be using
"interpolation=4,decimation=1" instead of the inverse?
> Rationel Sampler: Interpolation: 500
Certainly not :) 8 MS/s · 500 = 4 GS/s
> Decimation: 48 
Aside from that not even having greatest common denominator of 1 with
500 (you can't know that this is important, not blaming you), this would
give you an output sampling rate of 4GS/s/48 = 1 GS/s / 12 = 83.333
MS/s. Which isn't even a multiple of 48 kHz, which you use in the audio
sink:
> ->
> Audio Sink: Sample Rate: 48 KHz, Device Name: HW:0,0
>
> I've found that recipie on a Hack5 video and there it's working
I think there's some error in the way you configured these resamplers. I
don't know the Video you're referring to, but the amount of rational
resamplers used here alone, paired with the fact that you don't decimate
in the WBFM receiver makes me kind of suspicious this might not have
been the optimal video to take reference designs from!



Best regards,
Marcus
>
> With best regards
> Robin.
>
>
> ___
> 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] 答复: Power control for QAM demodulate

[Marcus Müller]

Hi Sangqing,


I'm taking the mailing list back into the people who receive your email
(it's always a good idea to reply to the list in whole, not to the
individual people), so that someone who has a compact example can help
you. I'd first of all encourage you to investigate where the problem
exactly lies; does it look like synchronization fails, or is it really
just an SNR problem that hinders successful equalization, or is maybe
the equalizer not up to your channel?


A specific description of your setup (carriers, bandwidth/sampling rate,
…) would be helpful.


Thanks!

Marcus


On 02/18/2017 05:43 PM, Zhao Shangqing wrote:
>
> Hi Marcus,
>
>
> Thanks so much for your recommendation. Yes, it's my mistake, I just
> noticed your suggestions and post the same question here. Sorry about
> that. Again, thanks for your explanation. 
>
>
> I have read the document about the "OFDM PAPR". I modified the Tx and
> Rx gain at both transmitter and receiver but still haven't got the
> correct demodulation. In addition, I also test the signal carrier
> communication system, rather than OFDM, 16 QAM still not works. At the
> receiver, I have corrected the phase distortion. But I don't know how
> to correct the amplitude offset. I know 16 QAM is more like to get
> errors, but actually, I cannot even get one correct symbol. If you can
> provide me some existing gnuradio examples about this? 
>
>
> Best regards,
>
> Shangqing
>
>
> 
> *发件人:* Discuss-gnuradio
>  代表 Marcus Müller
> 
> *发送时间:* 2017年2月18日 10:22
> *收件人:* discuss-gnuradio@gnu.org
> *主题:* Re: [Discuss-gnuradio] Power control for QAM demodulate
>  
>
> Hi Shangqing,
>
>
> I think you forgot to mention that you've already gotten answers to
> this on usrp-users:
>
> I wrote:
>>
>> Anyway, yes, 16 QAM is of course a lot more prone to noise than QPSK,
>> when using the same average power. (that's kind of logical – the 16
>> QAM constellation points are a lot closer together than the four QPSK
>> points)
>>
>>
>> With any modulation, you'd set the RX gain as high as possible
>> without clipping – and that is a real problem with OFDM. I recommend
>> you google "OFDM PAPR". So, you'd use the same RX gain for QPSK as
>> for QAM modulation.
>>
>>
>> You'd of course also use the highest possible distortion-free TX
>> gain, for both modulations, again, the same.
>>
>>
>> So, what you see is exactly what you've learned in digital comms 101
>> – the closer constellation points are, the more likely it is you get
>> a symbol error. What did you expect?
> And Kevin wrote:
>> Also keep in mind that in case of QPSK, the receiver does not need to
>> correct for amplitude. The receiver only needs to correct the phase
>> distortion caused by the channel since all information is encoded in
>> the phase of the QPSK symbols. 
>>
>> However, in 16-QAM modulation, information is encoded in both
>> amplitude and phase of the 16-QAM symbols. Now receiver needs to
>> correct both amplitude and phase distortion caused by the channel.
>>
>> So I am not sure if the receiver algorithm can handle QAM.
>
> So, instead of asking the same question here, I'd recommend you
> address what you did not understand in the answers you've gotten this
> far! It'll make it much easier for us to help you.
>
> Sadly, you haven't addressed any of the points we made – neither that
> the average power is, in contrast to what you claim, the same for QAM
> and QPSK, nor the additional hardness in demodulating these
> finer-grained constellations.
>
> Best regards,
> Marcus
>
>
>
> On 02/18/2017 04:23 PM, Zhao Shangqing wrote:
>>
>> Hi all,
>>
>>
>> I am using Gnuradio and USRP X300. I am implementing OFDM
>> communication using 16 or 64 QAM modulation scheme. I am using the
>> example of OFDM given by Gnuradio, and just changing the payload
>> modulation to 16QAM. I cannot correctly demodulate all the samples,
>> but QPSK works fine. I know QAM has the different signal power. I
>> wish to know if I wish to demodulate the M-QAM signal, how to control
>> the receiving power to calibrate different signals to different powers. 
>>
>>
>> Best regards,
>>
>> Shangqing
>>
>>
>>
>>
>> ___
>> 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] GNU Radio Companion - ALSA

[Robin A. Jensen]

Hello all of you.

I've just recieved my RTL-SDR dongle and is all new to this sdr-stuff, 
so please bear over with me, if i'm at the wrong place.
I'm using GNU Radio Companion on a RPi 3 and no mather what i'll do, i 
can't get the sound to work.
If a'im using rtl_fm and aplay, i'll get sound but it won't set on the 
radiostation. I'll take on that later.
I've createt a small FM Reciever in GNU Radio companion and everytime 
i'll execute the script i'll get an error:


RuntimeError.audio.alsa.sink

I've been all over the internet to find a solution but with no luck.
So now i'm have a hope that this mailling list can help me?

My setup is:
RTL-SDR Source: samplerate:  2M, frequency 96.5 MHz ->
Rationel Sampler: Interpolation 4, Decimation: 1 ->
Low Pass Filter: Sample rate: 2M, Cutoff freq: 100K, Transition Width: 
100k ->

WBFM Recive: Quadrature: 500K, Audio Decimation: 1 ->
Rationel Sampler: Interpolation: 500
Decimation: 48 ->
Audio Sink: Sample Rate: 48 KHz, Device Name: HW:0,0

I've found that recipie on a Hack5 video and there it's working

With best regards
Robin.


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

Re: [Discuss-gnuradio] Power control for QAM demodulate

[Marcus Müller]

To ease answering, I'll add more of the conversation in this separate mail:


You wrote:

> Thanks so much for your advice. I have read the PAPR OFDM document and
> set the higher RX and TX gain at both transmitter and receiver. But I
> still cannot demodulate the signal.
Yes, because it's intrinsically harder to demodulate 16QAM compared to
QPSK, as I tried to explain.
> So my question is do I need to change some parameters or adding some
> algorithms to control the USRP to intelligently receive different
> signal with different power.
These signals do *not* have a different power per se. SNR should be the
same.
> Has anyone achieved such function before?
yes.
> Or we can not use the USRP to receive the QAM signal.
Of course you can! It's really just a question of choosing transmission
parameters so that things work
> I actually don't exactly know how USRP works to receive the signal and
> convert it to the complex number.
You pretty much said it: USRPs (in general) are direct mixing complex
baseband receivers. There's a lot of literature on how these work!
> I actually also tested the signal carrier system,  but 16QAM still not
> works.
I'm afraid you'll have to dig into what noise is, how it affects
demodulation, and where symbol errors come from. This is theory that
you'll need to know when modifying/implementing digital transceiver systems!


Best regards,

Marcus



On 02/18/2017 05:22 PM, Marcus Müller wrote:
>
> Hi Shangqing,
>
>
> I think you forgot to mention that you've already gotten answers to
> this on usrp-users:
>
> I wrote:
>>
>> Anyway, yes, 16 QAM is of course a lot more prone to noise than QPSK,
>> when using the same average power. (that's kind of logical – the 16
>> QAM constellation points are a lot closer together than the four QPSK
>> points)
>>
>>
>> With any modulation, you'd set the RX gain as high as possible
>> without clipping – and that is a real problem with OFDM. I recommend
>> you google "OFDM PAPR". So, you'd use the same RX gain for QPSK as
>> for QAM modulation.
>>
>>
>> You'd of course also use the highest possible distortion-free TX
>> gain, for both modulations, again, the same.
>>
>>
>> So, what you see is exactly what you've learned in digital comms 101
>> – the closer constellation points are, the more likely it is you get
>> a symbol error. What did you expect?
> And Kevin wrote:
>> Also keep in mind that in case of QPSK, the receiver does not need to
>> correct for amplitude. The receiver only needs to correct the phase
>> distortion caused by the channel since all information is encoded in
>> the phase of the QPSK symbols. 
>>
>> However, in 16-QAM modulation, information is encoded in both
>> amplitude and phase of the 16-QAM symbols. Now receiver needs to
>> correct both amplitude and phase distortion caused by the channel.
>>
>> So I am not sure if the receiver algorithm can handle QAM.
>
> So, instead of asking the same question here, I'd recommend you
> address what you did not understand in the answers you've gotten this
> far! It'll make it much easier for us to help you.
>
> Sadly, you haven't addressed any of the points we made – neither that
> the average power is, in contrast to what you claim, the same for QAM
> and QPSK, nor the additional hardness in demodulating these
> finer-grained constellations.
>
> Best regards,
> Marcus
>
>
>
> On 02/18/2017 04:23 PM, Zhao Shangqing wrote:
>>
>> Hi all,
>>
>>
>> I am using Gnuradio and USRP X300. I am implementing OFDM
>> communication using 16 or 64 QAM modulation scheme. I am using the
>> example of OFDM given by Gnuradio, and just changing the payload
>> modulation to 16QAM. I cannot correctly demodulate all the samples,
>> but QPSK works fine. I know QAM has the different signal power. I
>> wish to know if I wish to demodulate the M-QAM signal, how to control
>> the receiving power to calibrate different signals to different powers. 
>>
>>
>> Best regards,
>>
>> Shangqing
>>
>>
>>
>>
>> ___
>> 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] Power control for QAM demodulate

[Marcus Müller]

Hi Shangqing,


I think you forgot to mention that you've already gotten answers to this
on usrp-users:

I wrote:
>
> Anyway, yes, 16 QAM is of course a lot more prone to noise than QPSK,
> when using the same average power. (that's kind of logical – the 16
> QAM constellation points are a lot closer together than the four QPSK
> points)
>
>
> With any modulation, you'd set the RX gain as high as possible without
> clipping – and that is a real problem with OFDM. I recommend you
> google "OFDM PAPR". So, you'd use the same RX gain for QPSK as for QAM
> modulation.
>
>
> You'd of course also use the highest possible distortion-free TX gain,
> for both modulations, again, the same.
>
>
> So, what you see is exactly what you've learned in digital comms 101 –
> the closer constellation points are, the more likely it is you get a
> symbol error. What did you expect?
And Kevin wrote:
> Also keep in mind that in case of QPSK, the receiver does not need to
> correct for amplitude. The receiver only needs to correct the phase
> distortion caused by the channel since all information is encoded in
> the phase of the QPSK symbols. 
>
> However, in 16-QAM modulation, information is encoded in both
> amplitude and phase of the 16-QAM symbols. Now receiver needs to
> correct both amplitude and phase distortion caused by the channel.
>
> So I am not sure if the receiver algorithm can handle QAM.

So, instead of asking the same question here, I'd recommend you address
what you did not understand in the answers you've gotten this far! It'll
make it much easier for us to help you.

Sadly, you haven't addressed any of the points we made – neither that
the average power is, in contrast to what you claim, the same for QAM
and QPSK, nor the additional hardness in demodulating these
finer-grained constellations.

Best regards,
Marcus



On 02/18/2017 04:23 PM, Zhao Shangqing wrote:
>
> Hi all,
>
>
> I am using Gnuradio and USRP X300. I am implementing OFDM
> communication using 16 or 64 QAM modulation scheme. I am using the
> example of OFDM given by Gnuradio, and just changing the payload
> modulation to 16QAM. I cannot correctly demodulate all the samples,
> but QPSK works fine. I know QAM has the different signal power. I wish
> to know if I wish to demodulate the M-QAM signal, how to control the
> receiving power to calibrate different signals to different powers. 
>
>
> Best regards,
>
> Shangqing
>
>
>
>
> ___
> 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] Power control for QAM demodulate

[Zhao Shangqing]

Hi all,


I am using Gnuradio and USRP X300. I am implementing OFDM communication using 
16 or 64 QAM modulation scheme. I am using the example of OFDM given by 
Gnuradio, and just changing the payload modulation to 16QAM. I cannot correctly 
demodulate all the samples, but QPSK works fine. I know QAM has the different 
signal power. I wish to know if I wish to demodulate the M-QAM signal, how to 
control the receiving power to calibrate different signals to different powers.


Best regards,

Shangqing

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