Re: [Discuss-gnuradio] benchmark_tx(rx).py throughput as modulation

[Marcus Müller]

Hi,

> I think it is up to bit rate, but I don't know exactly what it is.

The number of bit per second you're going to be transmitting/receiving.
It's (symbol rate) *  (bits per symbol). "bits per symbol" is of course
log2(constellation points).

> Is there unlimited bit rate option for check to modulation throughput ?

No, a given modulation with a given sample rate and a given samples per
second must result in a fixed transmission rate.

Best regards,
Marcus

On 02.03.2016 06:47, SangHyuk Kim wrote:
> Hi all.
>
> I'm using benchmark_tx.py and rx (/digital/example/narrowband)
>
> As I know, ex) QAM modulation is faster than BPSK one.
>
> However, when I used both of modulation schemes, I couldn't measure
> throughput.
>
> I think it is up to bit rate, but I don't know exactly what it is.
>
> Is there unlimited bit rate option for check to modulation throughput ?
>
> Thanks.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Discuss-gnuradio] benchmark_tx(rx).py throughput as modulation

[SangHyuk Kim]

Hi all.

I'm using benchmark_tx.py and rx (/digital/example/narrowband)

As I know, ex) QAM modulation is faster than BPSK one.

However, when I used both of modulation schemes, I couldn't measure
throughput.

I think it is up to bit rate, but I don't know exactly what it is.

Is there unlimited bit rate option for check to modulation throughput ?

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

Re: [Discuss-gnuradio] UHD Source Block and N210/SBX Synchronisation

[Marcus D. Leech]

On 03/01/2016 10:43 AM, Marcus D. Leech wrote:
The only thing really missing in gr-uhd is the ability to do timed 
commands.   You can force integer-N mode by constructing your own
  tune_request that includes the integer-N option.  You'd use a 
feature from the latest Gnu Radio to help you with this, because it 
involves
  getting into the internal structure of a tune_request blob. So, use 
the "Python module" block, and in that Python do something like:


def integer_N_tune_me(freq):
r = uhd.tune_request(freq)
r.args = {"mode_n" : "integer"}
return r

Then, in your UHD source/sink block, instead of using your target 
frequency directly, use:


your_module_name.integer_N_tune_me(desired_freq)



Martin could probably comment on the feasibility of adding timed 
commands to gr-uhd.


What I actually meant wasn't that gr-uhd doesn't have timed-command 
support, but rather, the GRC scaffolding for this doesn't really
  exist.  If you write your own Python, you can of course use 
timed-commands with gr-uhd, and in fact if you're willing to edit the
  output of GRC (generated Python) you can wire-in timed-commands 
fairly easily, it's just that there's no way to set this up with

  the existing UHD blocks for GRC (yet).







___
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-ieee 802.11 Wifi Transceiver Issue

[Bastian Bloessl]

> On 01 Mar 2016, at 16:04, Abhinav Jadon  wrote:
> 
> Hi, 
> Updated the module, the same problem persists although this time the 
> transmitter took longer than usual to turn off. 


I’m running a bit out of ideas :-/

Since I cannot reproduce the problem, it would be great if you could compile 
GNU Radio and the module with debug symbols and run the code in the debugger 
again.
Also is the memory usage growing over time, i.e., are you really running out of 
memory? As far as I understand, that’s what bad_alloc means.

If you send me your transmit flow graph, I can test your exact configuration 
and check for any obvious errors.


Best,
Bastian


> 
> 
> Cheers
> 
> Abhinav PS  Jadon 
> 2012122
> Electronics and Communication Engineering Undergraduate
> IIIT - Delhi 
> IASc Summer Research Fellow 2015
> E: jadonabhi...@gmail.com 
> M: +919650936845
> 
> 
> 
> 
> On Wed, Mar 2, 2016 at 5:09 AM, Bastian Bloessl  > wrote:
> Hi,
> 
> I just pushed a commit to github.
> 
> Would be great, if  you could update the module and let me know if that fixes 
> your problem.
> 
> Best,
> Bastian
> 
>> On 01 Mar 2016, at 15:25, Abhinav Jadon > > wrote:
>> 
>> Hi , 
>> Sorry for the delay in following up. Had mid semester exams to prepare for. 
>> I have a 8GB RAM Core i7 PC. Just to be sure that this wasn't a PC issue. I 
>> ran it on a 16GB RAM Core i5 PC. Same issue propped up. So that leaves out 
>> the memory leak option. 
>> 
>> Abhinav PS  Jadon 
>> 2012122
>> Electronics and Communication Engineering Undergraduate
>> IIIT - Delhi 
>> IASc Summer Research Fellow 2015
>> E: jadonabhi...@gmail.com 
>> M: +919650936845
>> 
>> 
>> 
>> 
>> On Sun, Feb 21, 2016 at 3:34 AM, Bastian Bloessl > > wrote:
>> Hi,
>> 
>>> On 20 Feb 2016, at 12:05, Abhinav Jadon >> > wrote:
>>> 
>>> 
>>> new mac frame  (length 10)
>>> =
>>> frame too short to parse (<20)
>>> thread[thread-per-block[3]: ]: std::bad_alloc
>>> [Thread 0x7fffad60d700 (LWP 4907) exited]
>> 
>> 
>> Looks like you run out of memory :-/
>> 
>> How much memory does your PC have?
>> 
>> If it’s not your PC, it’s a memory leak. Unfortunately, I’ve never had 
>> memory problems (for simulations, I often start up to 10 instances in 
>> parallel…)
>> 
>> If you have a decent PC and still have problems, you could try valgrind to 
>> debug potential memory leaks or compile the module with debug symbols. Maybe 
>> this reveals more information about what’s going wrong.
>> 
>> Best,
>> Bastian
>> 
>> 
>>> 
>>> 
>>> 
>>> On Thu, Feb 18, 2016 at 4:44 AM, Bastian Bloessl >> > wrote:
>>> Hi,
>>> 
 On 17 Feb 2016, at 11:45, Abhinav Jadon > wrote:
>>> 
 Upon running the transceiver code on a single X310, the transceiver shuts 
 down after few seconds of action (the LED ceases to blink) while the RX 
 continues to be up and decodes the packets. 
>>> 
>>> I can’t tell you much about the LEDs of the X310, but is there an error 
>>> message, a seg fault, output from UHD (like ‘O's, ’T's, ‘D’s printed on the 
>>> console), or any other indicator that something went wrong?
>>> Maybe start the flow graph in a debugger to get more information.
>>> 
>>> If you use my Packet Pad block, try disabling the delay.
>>> 
 If I run only the RX ( replacing the UHD sink with a null sink), it 
 continues to decode the packet. 
 If I run only the TX ( replacing the UHD source with a null source), it 
 continues to transmit, the LED stays on until I stop the flow graph.
>>> 
>>> What happens if you use just one transceiver flow graph (it has RX and TX)?
>>> 
 
 I also ran simple tests (single tone transmission and reception) on the 
 same device. The TX and RX LEDs remain up until the flowgraph is stopped. 
 This was done at the behest of James Humpheris of Ettus Research. 
 I raised the issue on the Ettus mailing list and they asked me to put this 
 up on the GNURadio Mailing List. 
>>> 
>>> Just read the thread… I see...
>>> How about piping the samples to the UHD Sink also in a Tag Debug block or 
>>> something to check whether samples are generated at all.
>>> 
>>> Best,
>>> Bastian
>>> 
 Regards 
 
 
 Abhinav PS  Jadon 
 2012122
 Electronics and Communication Engineering Undergraduate
 IIIT - Delhi 
 IASc Summer Research Fellow 2015
 E: jadonabhi...@gmail.com 
 M: +919650936845
 
 
 
 
 On Mon, Feb 15, 2016 at 9:51 AM, Bastian Bloessl 

Re: [Discuss-gnuradio] gr-ieee 802.11 Wifi Transceiver Issue

[Abhinav Jadon]

Hi,
Updated the module, the same problem persists although this time the
transmitter took longer than usual to turn off.


Cheers

Abhinav PS  Jadon
2012122
Electronics and Communication Engineering Undergraduate
IIIT - Delhi
IASc Summer Research Fellow 2015
*E*: jadonabhi...@gmail.com
*M*: +919650936845



On Wed, Mar 2, 2016 at 5:09 AM, Bastian Bloessl 
wrote:

> Hi,
>
> I just pushed a commit to github.
>
> Would be great, if  you could update the module and let me know if that
> fixes your problem.
>
> Best,
> Bastian
>
> On 01 Mar 2016, at 15:25, Abhinav Jadon  wrote:
>
> Hi ,
> Sorry for the delay in following up. Had mid semester exams to prepare
> for.
> I have a 8GB RAM Core i7 PC. Just to be sure that this wasn't a PC issue.
> I ran it on a 16GB RAM Core i5 PC. Same issue propped up. So that leaves
> out the memory leak option.
>
> Abhinav PS  Jadon
> 2012122
> Electronics and Communication Engineering Undergraduate
> IIIT - Delhi
> IASc Summer Research Fellow 2015
> *E*: jadonabhi...@gmail.com
> *M*: +919650936845
>
>
>
> On Sun, Feb 21, 2016 at 3:34 AM, Bastian Bloessl 
> wrote:
>
>> Hi,
>>
>> On 20 Feb 2016, at 12:05, Abhinav Jadon  wrote:
>>
>>
>> new mac frame  (length 10)
>> =
>> frame too short to parse (<20)
>> thread[thread-per-block[3]: ]: std::bad_alloc
>> [Thread 0x7fffad60d700 (LWP 4907) exited]
>>
>>
>>
>> Looks like you run out of memory :-/
>>
>> How much memory does your PC have?
>>
>> If it’s not your PC, it’s a memory leak. Unfortunately, I’ve never had
>> memory problems (for simulations, I often start up to 10 instances in
>> parallel…)
>>
>> If you have a decent PC and still have problems, you could try valgrind
>> to debug potential memory leaks or compile the module with debug symbols.
>> Maybe this reveals more information about what’s going wrong.
>>
>> Best,
>> Bastian
>>
>>
>>
>>
>>
>> On Thu, Feb 18, 2016 at 4:44 AM, Bastian Bloessl 
>> wrote:
>>
>>> Hi,
>>>
>>> On 17 Feb 2016, at 11:45, Abhinav Jadon 
>>> wrote:
>>>
>>>
>>> Upon running the transceiver code on a single X310, the transceiver
>>> shuts down after few seconds of action (the LED ceases to blink) while the
>>> RX continues to be up and decodes the packets.
>>>
>>>
>>> I can’t tell you much about the LEDs of the X310, but is there an error
>>> message, a seg fault, output from UHD (like ‘O's, ’T's, ‘D’s printed on the
>>> console), or any other indicator that something went wrong?
>>> Maybe start the flow graph in a debugger to get more information.
>>>
>>> If you use my Packet Pad block, try disabling the delay.
>>>
>>> If I run only the RX ( replacing the UHD sink with a null sink), it
>>> continues to decode the packet.
>>> If I run only the TX ( replacing the UHD source with a null source), it
>>> continues to transmit, the LED stays on until I stop the flow graph.
>>>
>>>
>>> What happens if you use just one transceiver flow graph (it has RX and
>>> TX)?
>>>
>>>
>>> I also ran simple tests (single tone transmission and reception) on the
>>> same device. The TX and RX LEDs remain up until the flowgraph is stopped.
>>> This was done at the behest of James Humpheris of Ettus Research.
>>> I raised the issue on the Ettus mailing list and they asked me to put
>>> this up on the GNURadio Mailing List.
>>>
>>>
>>> Just read the thread… I see...
>>> How about piping the samples to the UHD Sink also in a Tag Debug block
>>> or something to check whether samples are generated at all.
>>>
>>> Best,
>>> Bastian
>>>
>>> Regards
>>>
>>>
>>> Abhinav PS  Jadon
>>> 2012122
>>> Electronics and Communication Engineering Undergraduate
>>> IIIT - Delhi
>>> IASc Summer Research Fellow 2015
>>> *E*: jadonabhi...@gmail.com
>>> *M*: +919650936845
>>>
>>>
>>>
>>> On Mon, Feb 15, 2016 at 9:51 AM, Bastian Bloessl 
>>> wrote:
>>>
 Hi,


 On 14 Feb 2016, at 14:46, Abhinav Jadon 
 wrote:


 There are no overruns and the connections to the antenna ports are
 correct.
 The frame detection is working


 Note, that this also means that frame detection is only triggered once
 per frame. Sometimes, it can be triggered all the time (if there is a DC
 offset or LO leakage for example).
 Since you connected the devices via cable I would try to change LO
 offset of sender and receiver.
 (Btw, I guess you use attenuators)


 I tried all the stuff you told me to try ie I tried LMS ansd LO offset,
 they worked as in I saw some packets being decoded by the wireshark
 connector. But the packet content was incorrect . Each packet decoded
 looked like this



 new mac frame  (length 10)
 =
 frame too short to parse (<20)
 WIRESHARK: received new message
 

Re: [Discuss-gnuradio] polar code example

[Jose Ruvalcaba]

I used the new pybombs to install gnuradio and it installed gr-polar
automatically. So any error I am seeing is built into that flow.


> On Tue, Mar 1, 2016 at 1:34 PM, Johnathan Corgan  > wrote:
>
>> If it isn't working with 3.7.9.1, it's not the bug I was thinking of.
>> You can try reinstalling gr-polar as a "might work" thing, but without
>> knowing the reason for the initial problem, it is only guessing.
>>
>> On Tue, Mar 1, 2016 at 1:20 PM, Jose Ruvalcaba 
>> wrote:
>>
>>> Hi All,
>>>
>>> Thanks for the reply. I am currently using version 3.7.9.1.  Would you
>>> recommend retry  installing gr-polar?
>>>
>>> Thanks,
>>> Jose
>>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ieee 802.11 Wifi Transceiver Issue

[Bastian Bloessl]

Hi,

I just pushed a commit to github.

Would be great, if  you could update the module and let me know if that fixes 
your problem.

Best,
Bastian

> On 01 Mar 2016, at 15:25, Abhinav Jadon  wrote:
> 
> Hi , 
> Sorry for the delay in following up. Had mid semester exams to prepare for. 
> I have a 8GB RAM Core i7 PC. Just to be sure that this wasn't a PC issue. I 
> ran it on a 16GB RAM Core i5 PC. Same issue propped up. So that leaves out 
> the memory leak option. 
> 
> Abhinav PS  Jadon 
> 2012122
> Electronics and Communication Engineering Undergraduate
> IIIT - Delhi 
> IASc Summer Research Fellow 2015
> E: jadonabhi...@gmail.com 
> M: +919650936845
> 
> 
> 
> 
> On Sun, Feb 21, 2016 at 3:34 AM, Bastian Bloessl  > wrote:
> Hi,
> 
>> On 20 Feb 2016, at 12:05, Abhinav Jadon > > wrote:
>> 
>> 
>> new mac frame  (length 10)
>> =
>> frame too short to parse (<20)
>> thread[thread-per-block[3]: ]: std::bad_alloc
>> [Thread 0x7fffad60d700 (LWP 4907) exited]
> 
> 
> Looks like you run out of memory :-/
> 
> How much memory does your PC have?
> 
> If it’s not your PC, it’s a memory leak. Unfortunately, I’ve never had memory 
> problems (for simulations, I often start up to 10 instances in parallel…)
> 
> If you have a decent PC and still have problems, you could try valgrind to 
> debug potential memory leaks or compile the module with debug symbols. Maybe 
> this reveals more information about what’s going wrong.
> 
> Best,
> Bastian
> 
> 
>> 
>> 
>> 
>> On Thu, Feb 18, 2016 at 4:44 AM, Bastian Bloessl > > wrote:
>> Hi,
>> 
>>> On 17 Feb 2016, at 11:45, Abhinav Jadon >> > wrote:
>> 
>>> Upon running the transceiver code on a single X310, the transceiver shuts 
>>> down after few seconds of action (the LED ceases to blink) while the RX 
>>> continues to be up and decodes the packets. 
>> 
>> I can’t tell you much about the LEDs of the X310, but is there an error 
>> message, a seg fault, output from UHD (like ‘O's, ’T's, ‘D’s printed on the 
>> console), or any other indicator that something went wrong?
>> Maybe start the flow graph in a debugger to get more information.
>> 
>> If you use my Packet Pad block, try disabling the delay.
>> 
>>> If I run only the RX ( replacing the UHD sink with a null sink), it 
>>> continues to decode the packet. 
>>> If I run only the TX ( replacing the UHD source with a null source), it 
>>> continues to transmit, the LED stays on until I stop the flow graph.
>> 
>> What happens if you use just one transceiver flow graph (it has RX and TX)?
>> 
>>> 
>>> I also ran simple tests (single tone transmission and reception) on the 
>>> same device. The TX and RX LEDs remain up until the flowgraph is stopped. 
>>> This was done at the behest of James Humpheris of Ettus Research. 
>>> I raised the issue on the Ettus mailing list and they asked me to put this 
>>> up on the GNURadio Mailing List. 
>> 
>> Just read the thread… I see...
>> How about piping the samples to the UHD Sink also in a Tag Debug block or 
>> something to check whether samples are generated at all.
>> 
>> Best,
>> Bastian
>> 
>>> Regards 
>>> 
>>> 
>>> Abhinav PS  Jadon 
>>> 2012122
>>> Electronics and Communication Engineering Undergraduate
>>> IIIT - Delhi 
>>> IASc Summer Research Fellow 2015
>>> E: jadonabhi...@gmail.com 
>>> M: +919650936845
>>> 
>>> 
>>> 
>>> 
>>> On Mon, Feb 15, 2016 at 9:51 AM, Bastian Bloessl >> > wrote:
>>> Hi,
>>> 
>>> 
 On 14 Feb 2016, at 14:46, Abhinav Jadon > wrote:
>>> 
 There are no overruns and the connections to the antenna ports are 
 correct. 
 The frame detection is working
>>> 
>>> Note, that this also means that frame detection is only triggered once per 
>>> frame. Sometimes, it can be triggered all the time (if there is a DC offset 
>>> or LO leakage for example).
>>> Since you connected the devices via cable I would try to change LO offset 
>>> of sender and receiver.
>>> (Btw, I guess you use attenuators)
>>> 
 
 I tried all the stuff you told me to try ie I tried LMS ansd LO offset, 
 they worked as in I saw some packets being decoded by the wireshark 
 connector. But the packet content was incorrect . Each packet decoded 
 looked like this 
 
 
 new mac frame  (length 10)
 =
 frame too short to parse (<20)
 WIRESHARK: received new message
 message length 10
 WIRESHARK: d_msg_offset: 0   to_copy: 43   d_msg_len 43
 WIRESHARK: output size: 32768   produced items: 43
>>> 
>>> You should check in 

Re: [Discuss-gnuradio] gr-ieee 802.11 Wifi Transceiver Issue

[Abhinav Jadon]

Hi ,
Sorry for the delay in following up. Had mid semester exams to prepare for.
I have a 8GB RAM Core i7 PC. Just to be sure that this wasn't a PC issue. I
ran it on a 16GB RAM Core i5 PC. Same issue propped up. So that leaves out
the memory leak option.

Abhinav PS  Jadon
2012122
Electronics and Communication Engineering Undergraduate
IIIT - Delhi
IASc Summer Research Fellow 2015
*E*: jadonabhi...@gmail.com
*M*: +919650936845



On Sun, Feb 21, 2016 at 3:34 AM, Bastian Bloessl 
wrote:

> Hi,
>
> On 20 Feb 2016, at 12:05, Abhinav Jadon  wrote:
>
>
> new mac frame  (length 10)
> =
> frame too short to parse (<20)
> thread[thread-per-block[3]: ]: std::bad_alloc
> [Thread 0x7fffad60d700 (LWP 4907) exited]
>
>
>
> Looks like you run out of memory :-/
>
> How much memory does your PC have?
>
> If it’s not your PC, it’s a memory leak. Unfortunately, I’ve never had
> memory problems (for simulations, I often start up to 10 instances in
> parallel…)
>
> If you have a decent PC and still have problems, you could try valgrind to
> debug potential memory leaks or compile the module with debug symbols.
> Maybe this reveals more information about what’s going wrong.
>
> Best,
> Bastian
>
>
>
>
>
> On Thu, Feb 18, 2016 at 4:44 AM, Bastian Bloessl 
> wrote:
>
>> Hi,
>>
>> On 17 Feb 2016, at 11:45, Abhinav Jadon  wrote:
>>
>>
>> Upon running the transceiver code on a single X310, the transceiver shuts
>> down after few seconds of action (the LED ceases to blink) while the RX
>> continues to be up and decodes the packets.
>>
>>
>> I can’t tell you much about the LEDs of the X310, but is there an error
>> message, a seg fault, output from UHD (like ‘O's, ’T's, ‘D’s printed on the
>> console), or any other indicator that something went wrong?
>> Maybe start the flow graph in a debugger to get more information.
>>
>> If you use my Packet Pad block, try disabling the delay.
>>
>> If I run only the RX ( replacing the UHD sink with a null sink), it
>> continues to decode the packet.
>> If I run only the TX ( replacing the UHD source with a null source), it
>> continues to transmit, the LED stays on until I stop the flow graph.
>>
>>
>> What happens if you use just one transceiver flow graph (it has RX and
>> TX)?
>>
>>
>> I also ran simple tests (single tone transmission and reception) on the
>> same device. The TX and RX LEDs remain up until the flowgraph is stopped.
>> This was done at the behest of James Humpheris of Ettus Research.
>> I raised the issue on the Ettus mailing list and they asked me to put
>> this up on the GNURadio Mailing List.
>>
>>
>> Just read the thread… I see...
>> How about piping the samples to the UHD Sink also in a Tag Debug block or
>> something to check whether samples are generated at all.
>>
>> Best,
>> Bastian
>>
>> Regards
>>
>>
>> Abhinav PS  Jadon
>> 2012122
>> Electronics and Communication Engineering Undergraduate
>> IIIT - Delhi
>> IASc Summer Research Fellow 2015
>> *E*: jadonabhi...@gmail.com
>> *M*: +919650936845
>>
>>
>>
>> On Mon, Feb 15, 2016 at 9:51 AM, Bastian Bloessl 
>> wrote:
>>
>>> Hi,
>>>
>>>
>>> On 14 Feb 2016, at 14:46, Abhinav Jadon 
>>> wrote:
>>>
>>>
>>> There are no overruns and the connections to the antenna ports are
>>> correct.
>>> The frame detection is working
>>>
>>>
>>> Note, that this also means that frame detection is only triggered once
>>> per frame. Sometimes, it can be triggered all the time (if there is a DC
>>> offset or LO leakage for example).
>>> Since you connected the devices via cable I would try to change LO
>>> offset of sender and receiver.
>>> (Btw, I guess you use attenuators)
>>>
>>>
>>> I tried all the stuff you told me to try ie I tried LMS ansd LO offset,
>>> they worked as in I saw some packets being decoded by the wireshark
>>> connector. But the packet content was incorrect . Each packet decoded
>>> looked like this
>>>
>>>
>>>
>>> new mac frame  (length 10)
>>> =
>>> frame too short to parse (<20)
>>> WIRESHARK: received new message
>>> message length 10
>>> WIRESHARK: d_msg_offset: 0   to_copy: 43   d_msg_len 43
>>> WIRESHARK: output size: 32768   produced items: 43
>>>
>>>
>>> You should check in Wireshark if the content makes sense. I just
>>> implemented a very minimal parser for demo purposes.
>>>
>>>
>>> While the packet that is being transmitted has the following
>>> characteristics
>>>
>>> WIRESHARK: received new message
>>> message length 624
>>> WIRESHARK: d_msg_offset: 0   to_copy: 657   d_msg_len 657
>>> WIRESHARK: output size: 32768   produced items: 657
>>>
>>> Is the signal field being wrongly interpreted ?
>>>
>>>
>>> That would be one thing to find out. The easiest way is to enable the
>>> log option of the Decode Signal block (not the Wireshark block) to print
>>> what it decoded.
>>>
>>> In 

Re: [Discuss-gnuradio] polar code example

[Johnathan Corgan]

On Tue, Mar 1, 2016 at 11:42 AM, Jose Ruvalcaba  wrote:


> I was wondering if anyone has seen this issue I am encountering when
> trying to run polar_code_example.grc. Whenever I open the file my POLAR
> code configurator block shows:
>
> Value "polar.load_frozen_bits_info(True, "polar.CHANNEL_TYPE_BEC",
> block_size, n_info_bits, 0.0, 32)" cannot be evaluated:
> name 'polar' is not defined
>
> I was looking online for information on this issue but was not successful
> in finding any information. Does anyone have any insight on this?
>

​This is possibly an existing GRC bug that was fixed in 3.7.9.1.  What
version are you using?​

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

Re: [Discuss-gnuradio] polar code example

[Marcus Müller]

Dear Jose,

I'm not very experienced with gr-polar, but: did you successfully build
& install gr-polar?

Best regards,
Marcus

On 03/01/2016 08:42 PM, Jose Ruvalcaba wrote:
> Hello All,
>
> I was wondering if anyone has seen this issue I am encountering when
> trying to run polar_code_example.grc. Whenever I open the file my
> POLAR code configurator block shows:
>
> Value "polar.load_frozen_bits_info(True, "polar.CHANNEL_TYPE_BEC",
> block_size, n_info_bits, 0.0, 32)" cannot be evaluated:
> name 'polar' is not defined
>
> I was looking online for information on this issue but was not
> successful in finding any information. Does anyone have any insight on
> this?
>
>
> Thanks in advance,
>
> Jose
>
>
>
>
>
>
> ___
> 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] polar code example

[Jose Ruvalcaba]

Hello All,

I was wondering if anyone has seen this issue I am encountering when trying
to run polar_code_example.grc. Whenever I open the file my POLAR code
configurator block shows:

Value "polar.load_frozen_bits_info(True, "polar.CHANNEL_TYPE_BEC",
block_size, n_info_bits, 0.0, 32)" cannot be evaluated:
name 'polar' is not defined

I was looking online for information on this issue but was not successful
in finding any information. Does anyone have any insight on this?


Thanks in advance,

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

Re: [Discuss-gnuradio] UHD Source Block and N210/SBX Synchronisation

[Marcus D. Leech]

On 03/01/2016 10:53 AM, Nigel Steed wrote:


Thanks Marcus,

I have now implemented the tune request with a python module. Integer 
N mode really helps with eliminating the spurs.


I have also added timed commands within the python file, but when I 
read the N210 timer, all the fractional values are fixed at .9998.



That's just floating-point rounding error in the Python print function.

I have therefore re-compiled the UHD Source Block C Code to output to 
the console the time which is correct and all the fractional values 
are counting. Does this mean implementing time commands in python does 
not work ?


Thanks,

*From:*discuss-gnuradio-bounces+nigel.steed=xenint@gnu.org 
[mailto:discuss-gnuradio-bounces+nigel.steed=xenint@gnu.org] *On 
Behalf Of *Marcus D. Leech

*Sent:* 01 March 2016 15:44
*To:* discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] UHD Source Block and N210/SBX 
Synchronisation


On 03/01/2016 04:57 AM, Nigel Steed wrote:

Hi All,

Has anyone managed to use/modify the UHD Source Block to phase
synchronise multiple N210/SBX ?

From what I have read I must perform the following

(1)Configure to use external references (10MHz and 1PPS) using the
options in the UHD Source Block

(2)Use integer N mode for the PLL

(3)Re-tune the frequency of the PLL’s on multiple N210/SBX at the
same using a time command

(4)Align the CORDIC’s at initialisation and after a re-tune from
(2) above by stopping and starting a stream disciplined to a time
command which issues a reset to the CORDIC’s at the same time

Thanks,

Nigel

The only thing really missing in gr-uhd is the ability to do timed 
commands.   You can force integer-N mode by constructing your own
  tune_request that includes the integer-N option.  You'd use a 
feature from the latest Gnu Radio to help you with this, because it 
involves
  getting into the internal structure of a tune_request blob.   So, 
use the "Python module" block, and in that Python do something like:


def integer_N_tune_me(freq):
r = uhd.tune_request(freq)
r.args = {"mode_n" : "integer"}
return r

Then, in your UHD source/sink block, instead of using your target 
frequency directly, use:


your_module_name.integer_N_tune_me(desired_freq)



Martin could probably comment on the feasibility of adding timed 
commands to gr-uhd.





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

Re: [Discuss-gnuradio] UHD Source Block and N210/SBX Synchronisation

[Nigel Steed]

Thanks Marcus,

I have now implemented the tune request with a python module. Integer N mode 
really helps with eliminating the spurs.

I have also added timed commands within the python file, but when I read the 
N210 timer, all the fractional values are fixed at .9998.

I have therefore re-compiled the UHD Source Block C Code to output to the 
console the time which is correct and all the fractional values are counting. 
Does this mean implementing time commands in python does not work ?

Thanks,

From: discuss-gnuradio-bounces+nigel.steed=xenint@gnu.org 
[mailto:discuss-gnuradio-bounces+nigel.steed=xenint@gnu.org] On Behalf Of 
Marcus D. Leech
Sent: 01 March 2016 15:44
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UHD Source Block and N210/SBX Synchronisation

On 03/01/2016 04:57 AM, Nigel Steed wrote:
Hi All,

Has anyone managed to use/modify the UHD Source Block to phase synchronise 
multiple N210/SBX ?

>From what I have read I must perform the following


(1)Configure to use external references (10MHz and 1PPS) using the options 
in the UHD Source Block

(2)Use integer N mode for the PLL

(3)Re-tune the frequency of the PLL's on multiple N210/SBX at the same 
using a time command

(4)Align the CORDIC's at initialisation and after a re-tune from (2) above 
by stopping and starting a stream disciplined to a time command which issues a 
reset to the CORDIC's at the same time

Thanks,

Nigel

The only thing really missing in gr-uhd is the ability to do timed commands.   
You can force integer-N mode by constructing your own
  tune_request that includes the integer-N option.  You'd use a feature from 
the latest Gnu Radio to help you with this, because it involves
  getting into the internal structure of a tune_request blob.   So, use the 
"Python module" block, and in that Python do something like:

def integer_N_tune_me(freq):
r = uhd.tune_request(freq)
r.args = {"mode_n" : "integer"}
return r

Then, in your UHD source/sink block, instead of using your target frequency 
directly, use:

your_module_name.integer_N_tune_me(desired_freq)



Martin could probably comment on the feasibility of adding timed commands to 
gr-uhd.


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

Re: [Discuss-gnuradio] UHD Source Block and N210/SBX Synchronisation

[Marcus D. Leech]

On 03/01/2016 04:57 AM, Nigel Steed wrote:


Hi All,

Has anyone managed to use/modify the UHD Source Block to phase 
synchronise multiple N210/SBX ?


From what I have read I must perform the following

(1)Configure to use external references (10MHz and 1PPS) using the 
options in the UHD Source Block


(2)Use integer N mode for the PLL

(3)Re-tune the frequency of the PLL’s on multiple N210/SBX at the same 
using a time command


(4)Align the CORDIC’s at initialisation and after a re-tune from (2) 
above by stopping and starting a stream disciplined to a time command 
which issues a reset to the CORDIC’s at the same time


Thanks,

Nigel

The only thing really missing in gr-uhd is the ability to do timed 
commands.   You can force integer-N mode by constructing your own
  tune_request that includes the integer-N option.  You'd use a feature 
from the latest Gnu Radio to help you with this, because it involves
  getting into the internal structure of a tune_request blob.   So, use 
the "Python module" block, and in that Python do something like:


def integer_N_tune_me(freq):
r = uhd.tune_request(freq)
r.args = {"mode_n" : "integer"}
return r

Then, in your UHD source/sink block, instead of using your target 
frequency directly, use:


your_module_name.integer_N_tune_me(desired_freq)



Martin could probably comment on the feasibility of adding timed 
commands to gr-uhd.




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

Re: [Discuss-gnuradio] gr-ieee802-11

[Bastian Bloessl]

Hi,

> On 01 Mar 2016, at 05:34, Fujiwara  wrote:
> 
> Hi everyone! 
>  I am a beginner of GNU Radio. I found a very nice work in
> https://github.com/bastibl/gr-ieee802-11/tree/master and it does me a great
> favor. I connected two USRP N210,one run wifi_tx.grc, the other run
> wifi_rx.grc, it worked. But when I want to use cellphone to receive the WiFi
> signal transmitting by wifi_tx.grc, it didn't work. The cell phone couldn't
> find SSID or other signal.
>  What shall i do? Could the cellphone recognize and receive the wifi
> signal from wifi_tx.grc? Is there someone attempt to do this project also?
> Thanks in advance! Any advice will be welcome!
> 

Note that you will not be able to associate to the SDR as it does not implement 
a complete network stack, but mainly the physical layer.

You can, however, send beacons that can be picked up by your cell phone.
You have to adapt the data format and assemble a standard compliant beacon 
frame (currently it’s sending data frames).
It should be straightforward to implement and debug, just pipe your output to 
Wireshark (locally, without actually sending it) and check the format.

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

[Discuss-gnuradio] gr-ieee802-11

[Fujiwara]

Hi everyone! 
  I am a beginner of GNU Radio. I found a very nice work in
https://github.com/bastibl/gr-ieee802-11/tree/master and it does me a great
favor. I connected two USRP N210,one run wifi_tx.grc, the other run
wifi_rx.grc, it worked. But when I want to use cellphone to receive the WiFi
signal transmitting by wifi_tx.grc, it didn't work. The cell phone couldn't
find SSID or other signal.
  What shall i do? Could the cellphone recognize and receive the wifi
signal from wifi_tx.grc? Is there someone attempt to do this project also?
 Thanks in advance! Any advice will be welcome!



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/gr-ieee802-11-tp58402.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] How to change the SNR through gnuradio

[Marcus Müller]

Zs,

SNR is something that depends on your signal. We can't tell you what
signal you have.
The number I can give you is the Noise Figure of the SBX at room
temperature. It's something that depends on both gain and frequency. You
can find the measurement data under [1]. Together with the normal
thermal noise power spectral density and your receiver bandwidth, you
can calculate a maximum SNR.
Also take quantization noise into account, and don't forget that you're
oversampling.

All these effects depend on how you parameterize your transmission.

Best regards,
Marcus

[1] http://files.ettus.com/performance_data/sbx/

On 03/01/2016 01:58 PM, w xd wrote:
> Hi,
>
> And I want to know the "phase noise variance" of our instrument?Thanks
> so much.
>
>
> 2016-03-01 20:50 GMT+08:00 w xd  >:
>
> Hi,
>
> I used the USRP N210 and sbx board.What is the dynamic range of
> the instrument?Namely the maximum SNR?Thanks so much.
>
> Best Regards,
> zs 
>
> 2016-03-01 19:58 GMT+08:00 Marcus Müller  >:
>
> I think that question answers itself if you consider what SNR is.
>
> Best regards,
> Marcus
>
>
> On 01.03.2016 12:34, w xd wrote:
>> Thanks so much.
>>
>> In this case,I just change the gain of the transmitter,will
>> be change the snr of the receiver?
>>
>> Thanks. 
>>
>> 2016-03-01 19:02 GMT+08:00 Marcus Müller
>> >:
>>
>> Dear zs,
>>
>> > I want to change the ratio of power of the received
>> signal to power of the noise.
>>
>> well, improving receiver SNR is the *core* problem of all
>> wireless communication. Unless you just add noise (on the
>> receiver or the transmitter side, depending on whether
>> you want your noise to be channel-shaped or not), there's
>> your whole digital communication knowledge you can apply
>> (matched filtering, oversampling, coding gain,
>> preselection filtering...).
>>
>> > And I want to change the gain of the transmitter.
>> Well, then do that. The usrp_sink block has a TX gain
>> setting, and all daughterboards (aside from the Basic*,
>> LF* and TVRX* boards) have adjustable gain: use the
>> set_tx_gain(gain) method, or if you're using GRC, look
>> into the "RF settings" tab.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 01.03.2016 09:56, w xd wrote:
>>> Sorry for that.
>>>
>>> I'm now using the USRP N210,one transmitter and one
>>> receiver.I want to change the ratio of power of the
>>> received signal to power of the noise.And I want to
>>> change the gain of the transmitter.
>>>
>>> 2016-03-01 16:45 GMT+08:00 Marcus Müller
>>> >> >:
>>>
>>> Dear zs,
>>>
>>> your question is absolutely unclear. SNR of what?
>>> What instrument? TX or RX, or simulation?
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 01.03.2016 07:06, w xd wrote:
 Hi,

I want to change the SNR through gnuradio.Can I
 realize it by just change the gain of the
 gnuradio?Or the instrument is fixed,and the snr
 can't be change?

   Thanks so much.

 Best Regards,
 zs 


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

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

Re: [Discuss-gnuradio] Saving Waterfall to Video File

[Stephen Berger]

Dan,

 

That sounds like a useful approach but isn’t something I have any experience 
with.  Can you go into more detail on how you prepared the file with the 
decimated vectors and then what the process is to plot it?

 

Best Regards,





Stephen Berger

TEM Consulting, LP

Web Site -   www.temconsulting.com 
E-MAIL -   stephen.ber...@ieee.org
Phone - (512) 864-3365
Mobile - (512) 466-0833
FAX - (512) 869-8709

From: Dan CaJacob [mailto:dan.caja...@gmail.com] 
Sent: Monday, February 29, 2016 4:48 PM
To: stephen.ber...@ieee.org; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Saving Waterfall to Video File

 

In the past, I have saved decimated vectors of the signal to a file and used 
that to recreate a long, static waterfall plot for debug of satellite passes.

 

On Sun, Feb 28, 2016 at 2:19 PM Stephen Berger 
 > wrote:

I would like to save a waterfall plot (spectrograph) to a video file so that I 
can share it and cut out portions of interest for presentation.  Has anyone 
found a way to directly save the output to an MP4 or some other video format?  

 

I have been using a screen recorder but that takes a good time of time and the 
process ends up requiring 2 to 4 different programs by the time you record, 
edit and have your file ready for presentation.  It would be a time savings to 
save it directly.

 

Best Regards,




Stephen Berger

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

-- 

Very Respectfully,

 

Dan CaJacob

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

Re: [Discuss-gnuradio] How to change the SNR through gnuradio

[w xd]

Hi,

And I want to know the "phase noise variance" of our instrument?Thanks so
much.


2016-03-01 20:50 GMT+08:00 w xd :

> Hi,
>
> I used the USRP N210 and sbx board.What is the dynamic range of the
> instrument?Namely the maximum SNR?Thanks so much.
>
> Best Regards,
> zs
>
> 2016-03-01 19:58 GMT+08:00 Marcus Müller :
>
>> I think that question answers itself if you consider what SNR is.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 01.03.2016 12:34, w xd wrote:
>>
>> Thanks so much.
>>
>> In this case,I just change the gain of the transmitter,will be change the
>> snr of the receiver?
>>
>> Thanks.
>>
>> 2016-03-01 19:02 GMT+08:00 Marcus Müller :
>>
>>> Dear zs,
>>>
>>> > I want to change the ratio of power of the received signal to power of
>>> the noise.
>>>
>>> well, improving receiver SNR is the *core* problem of all wireless
>>> communication. Unless you just add noise (on the receiver or the
>>> transmitter side, depending on whether you want your noise to be
>>> channel-shaped or not), there's your whole digital communication knowledge
>>> you can apply (matched filtering, oversampling, coding gain, preselection
>>> filtering...).
>>>
>>> > And I want to change the gain of the transmitter.
>>> Well, then do that. The usrp_sink block has a TX gain setting, and all
>>> daughterboards (aside from the Basic*, LF* and TVRX* boards) have
>>> adjustable gain: use the set_tx_gain(gain) method, or if you're using GRC,
>>> look into the "RF settings" tab.
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 01.03.2016 09:56, w xd wrote:
>>>
>>> Sorry for that.
>>>
>>> I'm now using the USRP N210,one transmitter and one receiver.I want to
>>> change the ratio of power of the received signal to power of the noise.And
>>> I want to change the gain of the transmitter.
>>>
>>> 2016-03-01 16:45 GMT+08:00 Marcus Müller < 
>>> marcus.muel...@ettus.com>:
>>>
 Dear zs,

 your question is absolutely unclear. SNR of what? What instrument? TX
 or RX, or simulation?

 Best regards,
 Marcus


 On 01.03.2016 07:06, w xd wrote:

 Hi,

I want to change the SNR through gnuradio.Can I realize it by just
 change the gain of the gnuradio?Or the instrument is fixed,and the snr
 can't be change?

   Thanks so much.

 Best Regards,
 zs


 ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio



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


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

Re: [Discuss-gnuradio] How to change the SNR through gnuradio

[w xd]

Hi,

I used the USRP N210 and sbx board.What is the dynamic range of the
instrument?Namely the maximum SNR?Thanks so much.

Best Regards,
zs

2016-03-01 19:58 GMT+08:00 Marcus Müller :

> I think that question answers itself if you consider what SNR is.
>
> Best regards,
> Marcus
>
>
> On 01.03.2016 12:34, w xd wrote:
>
> Thanks so much.
>
> In this case,I just change the gain of the transmitter,will be change the
> snr of the receiver?
>
> Thanks.
>
> 2016-03-01 19:02 GMT+08:00 Marcus Müller :
>
>> Dear zs,
>>
>> > I want to change the ratio of power of the received signal to power of
>> the noise.
>>
>> well, improving receiver SNR is the *core* problem of all wireless
>> communication. Unless you just add noise (on the receiver or the
>> transmitter side, depending on whether you want your noise to be
>> channel-shaped or not), there's your whole digital communication knowledge
>> you can apply (matched filtering, oversampling, coding gain, preselection
>> filtering...).
>>
>> > And I want to change the gain of the transmitter.
>> Well, then do that. The usrp_sink block has a TX gain setting, and all
>> daughterboards (aside from the Basic*, LF* and TVRX* boards) have
>> adjustable gain: use the set_tx_gain(gain) method, or if you're using GRC,
>> look into the "RF settings" tab.
>>
>> Best regards,
>> Marcus
>>
>>
>> On 01.03.2016 09:56, w xd wrote:
>>
>> Sorry for that.
>>
>> I'm now using the USRP N210,one transmitter and one receiver.I want to
>> change the ratio of power of the received signal to power of the noise.And
>> I want to change the gain of the transmitter.
>>
>> 2016-03-01 16:45 GMT+08:00 Marcus Müller < 
>> marcus.muel...@ettus.com>:
>>
>>> Dear zs,
>>>
>>> your question is absolutely unclear. SNR of what? What instrument? TX or
>>> RX, or simulation?
>>>
>>> Best regards,
>>> Marcus
>>>
>>>
>>> On 01.03.2016 07:06, w xd wrote:
>>>
>>> Hi,
>>>
>>>I want to change the SNR through gnuradio.Can I realize it by just
>>> change the gain of the gnuradio?Or the instrument is fixed,and the snr
>>> can't be change?
>>>
>>>   Thanks so much.
>>>
>>> Best Regards,
>>> zs
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing 
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to change the SNR through gnuradio

[Marcus Müller]

I think that question answers itself if you consider what SNR is.

Best regards,
Marcus

On 01.03.2016 12:34, w xd wrote:
> Thanks so much.
>
> In this case,I just change the gain of the transmitter,will be change
> the snr of the receiver?
>
> Thanks. 
>
> 2016-03-01 19:02 GMT+08:00 Marcus Müller  >:
>
> Dear zs,
>
> > I want to change the ratio of power of the received signal to
> power of the noise.
>
> well, improving receiver SNR is the *core* problem of all wireless
> communication. Unless you just add noise (on the receiver or the
> transmitter side, depending on whether you want your noise to be
> channel-shaped or not), there's your whole digital communication
> knowledge you can apply (matched filtering, oversampling, coding
> gain, preselection filtering...).
>
> > And I want to change the gain of the transmitter.
> Well, then do that. The usrp_sink block has a TX gain setting, and
> all daughterboards (aside from the Basic*, LF* and TVRX* boards)
> have adjustable gain: use the set_tx_gain(gain) method, or if
> you're using GRC, look into the "RF settings" tab.
>
> Best regards,
> Marcus
>
>
> On 01.03.2016 09:56, w xd wrote:
>> Sorry for that.
>>
>> I'm now using the USRP N210,one transmitter and one receiver.I
>> want to change the ratio of power of the received signal to power
>> of the noise.And I want to change the gain of the transmitter.
>>
>> 2016-03-01 16:45 GMT+08:00 Marcus Müller
>> >:
>>
>> Dear zs,
>>
>> your question is absolutely unclear. SNR of what? What
>> instrument? TX or RX, or simulation?
>>
>> Best regards,
>> Marcus
>>
>>
>> On 01.03.2016 07:06, w xd wrote:
>>> Hi,
>>>
>>>I want to change the SNR through gnuradio.Can I realize
>>> it by just change the gain of the gnuradio?Or the instrument
>>> is fixed,and the snr can't be change?
>>>
>>>   Thanks so much.
>>>
>>> Best Regards,
>>> zs 
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org 
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>

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

Re: [Discuss-gnuradio] How to change the SNR through gnuradio

[w xd]

Thanks so much.

In this case,I just change the gain of the transmitter,will be change the
snr of the receiver?

Thanks.

2016-03-01 19:02 GMT+08:00 Marcus Müller :

> Dear zs,
>
> > I want to change the ratio of power of the received signal to power of
> the noise.
>
> well, improving receiver SNR is the *core* problem of all wireless
> communication. Unless you just add noise (on the receiver or the
> transmitter side, depending on whether you want your noise to be
> channel-shaped or not), there's your whole digital communication knowledge
> you can apply (matched filtering, oversampling, coding gain, preselection
> filtering...).
>
> > And I want to change the gain of the transmitter.
> Well, then do that. The usrp_sink block has a TX gain setting, and all
> daughterboards (aside from the Basic*, LF* and TVRX* boards) have
> adjustable gain: use the set_tx_gain(gain) method, or if you're using GRC,
> look into the "RF settings" tab.
>
> Best regards,
> Marcus
>
>
> On 01.03.2016 09:56, w xd wrote:
>
> Sorry for that.
>
> I'm now using the USRP N210,one transmitter and one receiver.I want to
> change the ratio of power of the received signal to power of the noise.And
> I want to change the gain of the transmitter.
>
> 2016-03-01 16:45 GMT+08:00 Marcus Müller :
>
>> Dear zs,
>>
>> your question is absolutely unclear. SNR of what? What instrument? TX or
>> RX, or simulation?
>>
>> Best regards,
>> Marcus
>>
>>
>> On 01.03.2016 07:06, w xd wrote:
>>
>> Hi,
>>
>>I want to change the SNR through gnuradio.Can I realize it by just
>> change the gain of the gnuradio?Or the instrument is fixed,and the snr
>> can't be change?
>>
>>   Thanks so much.
>>
>> Best Regards,
>> zs
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UHD Source Block and N210/SBX Synchronisation

[Nigel Steed]

Hi All,

Has anyone managed to use/modify the UHD Source Block to phase synchronise 
multiple N210/SBX ?

>From what I have read I must perform the following


(1)Configure to use external references (10MHz and 1PPS) using the options 
in the UHD Source Block

(2)Use integer N mode for the PLL

(3)Re-tune the frequency of the PLL's on multiple N210/SBX at the same 
using a time command

(4)Align the CORDIC's at initialisation and after a re-tune from (2) above 
by stopping and starting a stream disciplined to a time command which issues a 
reset to the CORDIC's at the same time

Thanks,

Nigel

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

Re: [Discuss-gnuradio] Aliasing on USRP N210

[Marcus Müller]

Dear Roee,

I'd like to illustrate a bit how the USRP generates spectrum from the
signal you provide

1. get baseband samples from host with $f_\text{sample}$
2. upsample to $f_\text{master clock rate}$, suppressing aliases
3. shift digitally in frequency by multiplication with a complex
sinusoid $f_\text{offset}$: $y[n] = x[n] \cdot e^{n\,2\pi
\frac{f_\text{offset}}{f_\text{master clock rate}}}$
4. Digital-to-analog convert
(5. on daughterboard, mix with local oscillator generated by the
daughterboard.)

On Basic and LF, 5. doesn't happen -- these daughterboards don't have an
LO or a mixer. Hence, all the carrier frequency "mixing" happens in the
FPGA in step 3.

Your 26.5MHz sine happens in 2.:
Upsampling from $f_\text{sample}=\SI{25}{\mega\hertz}$ to
$f_\text{master clock rate}=\SI{100}{\mega\hertz}$ simply is padding the
incoming complex sample stream with three zeros after each sample
(resulting in (1+3) * 25 = 100 MHz rate); the result is very similar to
what you know as imaging from Digital-to-Analog-conversion:
$\frac{1}{4}$ of the spectrum represented at $f_\text{master clock
rate}$ is the original spectrum, the rest is images of it. Since we
don't want these images, we need to suppress them with a low pass
filter, ideally with a cut-off frequency exactly at the $\frac{1}{4}$ of
the output rate, infinite suppression above that frequency, and a
perfectly ripple-free, constant gain below.

Now, real-world filters that behave like that don't exist. Instead, the
USRP uses a cascade of three interpolators including anti-imaging
filters that are used/disabled as required by the upsampling factor,
which are concatenated in the following order:

 1. one large half band FIR interpolator (first factor of 2)
 2. one smaller half band FIR interpolator (second factor of 2)
 3. a CIC (cascaded integrator comb), which is a flexible
filter/interpolator that has a FIR-like frequency response, but due
to its adjustable IIR interpolation allows for nearly arbitrary factors

Since we're interpolating by 4, the CIC is disabled.
Filter 1 has the "best" (read: sharpest and flattest) frequency
response, and 2. is not so much worse [1].

For the first halfband interpolator, which interpolates from 25 to 50
MHz, the 11 MHz tone and its image are $\pm 0.06$ of
$\frac{f_\text{sample,higher side}}{2}$, for the second, it's only 0.03.
I hence take the freedom to claim that regarding that tone, the
difference of magnitude response for the second filter is insignificant
(it being "flatter" in that region, and the frequency distance being
half as large).

Now, roughly read from [1], the "passband-side" suppression of your tone
is -1.5dB, and the stopband side is approximately -18dB, leaving us with
a magnitude suppression of -16.5dB, which is pretty close to your
observed spectrum (-17.2dB). The remainder might just be measurement
error or the slight frequency selectivity of the analog components on
the LFTX.

Hope that explains this reasonably well!

As a recommendation: Don't try to work too close to your Nyquist band
edge. If necessary/applicable, just use the digital frequency shifter
(step 3. from my TX chain description above) to get your desired
frequency closer to what you want to see alias-free.

Best regards,
Marcus

[1] Ian Buckley's plots:
http://witestlab.poly.edu/~ffund/el9043/labs/images/lab2-filters.png
(which he made for the RX chain, but at least for the first halfband, I
know that the filter coefficients should be identical, and hence, the
response should be the same, too. I think the same applies for the small
half band filter.)


On 29.02.2016 22:31, Roee Bar wrote:
> I am observing aliasing on the spectrum analyzer in the following
> simple transmission scenario:
> sampling freq=25M, carrier freq=12.5MHz, and a sine wave freq=-11MHz
> at baseband.
> I use the following command:
>> uhd_siggen -s 25e6 -f 12.5e6 --sine -x -11e6
>
> I expect to see a delta at freq=1.5MHz, but there is another one
> freq=26.5MHz (see attached jpeg).
>
> It occurs on LFTX or BasicTX doughterboards. When I move the sine wave
> from -11MHz toward zero, the aliasing gradually disappears. It appears
> again when moving up toward +10MHz.
>
> Why does it happen? Can I avoid it?
>
> 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] How to change the SNR through gnuradio

[Marcus Müller]

Dear zs,

> I want to change the ratio of power of the received signal to power of
the noise.

well, improving receiver SNR is the *core* problem of all wireless
communication. Unless you just add noise (on the receiver or the
transmitter side, depending on whether you want your noise to be
channel-shaped or not), there's your whole digital communication
knowledge you can apply (matched filtering, oversampling, coding gain,
preselection filtering...).

> And I want to change the gain of the transmitter.
Well, then do that. The usrp_sink block has a TX gain setting, and all
daughterboards (aside from the Basic*, LF* and TVRX* boards) have
adjustable gain: use the set_tx_gain(gain) method, or if you're using
GRC, look into the "RF settings" tab.

Best regards,
Marcus

On 01.03.2016 09:56, w xd wrote:
> Sorry for that.
>
> I'm now using the USRP N210,one transmitter and one receiver.I want to
> change the ratio of power of the received signal to power of the
> noise.And I want to change the gain of the transmitter.
>
> 2016-03-01 16:45 GMT+08:00 Marcus Müller  >:
>
> Dear zs,
>
> your question is absolutely unclear. SNR of what? What instrument?
> TX or RX, or simulation?
>
> Best regards,
> Marcus
>
>
> On 01.03.2016 07:06, w xd wrote:
>> Hi,
>>
>>I want to change the SNR through gnuradio.Can I realize it by
>> just change the gain of the gnuradio?Or the instrument is
>> fixed,and the snr can't be change?
>>
>>   Thanks so much.
>>
>> Best Regards,
>> zs 
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

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

Re: [Discuss-gnuradio] How to change the SNR through gnuradio

[w xd]

Sorry for that.

I'm now using the USRP N210,one transmitter and one receiver.I want to
change the ratio of power of the received signal to power of the noise.And
I want to change the gain of the transmitter.

2016-03-01 16:45 GMT+08:00 Marcus Müller :

> Dear zs,
>
> your question is absolutely unclear. SNR of what? What instrument? TX or
> RX, or simulation?
>
> Best regards,
> Marcus
>
>
> On 01.03.2016 07:06, w xd wrote:
>
> Hi,
>
>I want to change the SNR through gnuradio.Can I realize it by just
> change the gain of the gnuradio?Or the instrument is fixed,and the snr
> can't be change?
>
>   Thanks so much.
>
> Best Regards,
> zs
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to change the SNR through gnuradio

[Marcus Müller]

Dear zs,

your question is absolutely unclear. SNR of what? What instrument? TX or
RX, or simulation?

Best regards,
Marcus

On 01.03.2016 07:06, w xd wrote:
> Hi,
>
>I want to change the SNR through gnuradio.Can I realize it by just
> change the gain of the gnuradio?Or the instrument is fixed,and the snr
> can't be change?
>
>   Thanks so much.
>
> Best Regards,
> zs 
>
>
> ___
> 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