Re: [Discuss-gnuradio] FEC in gnruadio

[bob wole]

On Tue, Jun 16, 2015 at 11:45 PM, bob wole  wrote:

>
>
> On Tue, Jun 16, 2015 at 11:41 PM, Tom Rondeau  wrote:
>
>> On Tue, Jun 16, 2015 at 1:03 PM, bob wole  wrote:
>>
>>>
>>>
 On 16.06.2015 08:26, bob wole wrote:
 > Hi,
 >
 > I just stared working on FEC in gnuradio. I found that there is
 > gr-fec.  I want to know that which literature , books/papers, was
 > followed during the implementation of the gr-fec so that I can go
 > through the c++ implementation more productively and add
 > something.
 >
 >
 > -- Bob
 >
 -

 > Hi,
 >
 > I just stared working on FEC in gnuradio. I found that there is
 gr-fec.  I
 > want to know that which literature , books/papers, was followed
 during the
 > implementation of the gr-fec so that I can go through the c++
 > implementation more productively and add something.
 >
 >
 > --
 > Bob
 >

 Hi Bob,

 Have a look at the manual. The API itself is quite well described I
 think:

 http://gnuradio.org/doc/doxygen/page_fec.html

 It doesn't cover the very recently added TPC and LDPC implementations.
 http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1ldpc__decoder.html
 http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1ldpc__decoder.html
 http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1tpc__encoder.html
 http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1tpc__decoder.html

 Those could use work on their documentation.

 We're also about to merge in another approach to LDPC encoding and
 decoding
 based on Tracie Perez's GSoC work. You can see the wip branch here:

 https://github.com/trondeau/gnuradio/tree/fec/ldpc_methods

 And the GSoC presentations:
 http://www.trondeau.com/grcon2013-presentations#gsoc-perez
 http://www.trondeau.com/grcon2013-presentations#gsoc-manu

 Johannes Demel is working on polar codes this summer.

 What's your particular interest in FEC? Are you looking to use it or
 implement other codes not already in gr-fec? For the FEC API itself,
 there
 is no other reference than the manual page and a presentation from the
 original author at our GRCons:

 http://www.trondeau.com/grcon14-presentations#tut-mccarthy
 http://www.trondeau.com/grcon2013-presentations#tut-mccarthy

 Tom

>>>
>>> Hi Tom,
>>>
>>> Thanks for the links. I am targeting Turbo Codes mainly for short frame
>>> size. I found one presentation on turbo codes
>>>
>>>
>>> http://gnuradio.squarespace.com/storage/grcon14/presentations/Sep18_02_Karra_TurboCodes.pdf
>>>
>>> but I could not find its source code in gnuradio. Are Turbo codes
>>> implemented in gnuradio? if yes, in which version can I find it? One more
>>> question, I am targeting short frame length burst, currently which FEC in
>>> gnuradio can give me best gain in this case?
>>>
>>> --
>>> Bob
>>>
>>
>> Bob,
>>
>> Yes, Kiran's TPC work has been integrated as of 3.7.7.1. (I even pointed
>> out the links to the manual pages for the tpc_encoder and tpc_decoder
>> above.)
>>
>> Tom
>>
>>
> Thanks Tom,
>
> I am going to test them soon for my bursty system :) Lets see how it works.
>
> --
> Bob
>

Hi list,

gnuradio version 3.7.7.1
ubunutu 14.04 32-bit

I am trying to use gr-fec and I am having issues running examples located
in gnuradio/gr-fec/examples/


When I run ber_test.grc I get following error

Using Volk machine: avx_32_mmx_orc
Traceback (most recent call last):
  File "/home/gnuradio/gr-fec/examples/ber_test.py", line 267, in 
tb = ber_test()
  File "/home/gnuradio/gr-fec/examples/ber_test.py", line 159, in __init__
self.fec_extended_encoder_0 =
fec.extended_encoder(encoder_obj_list=enc, threading='capillary',
puncpat="puncpat")
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/fec/extended_encoder.py",
line 64, in __init__
self.blocks.append(fec.puncture_bb(len(puncpat), read_bitlist(puncpat),
0))
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/fec/bitflip.py",
line 47, in read_bitlist
if int(bitlist[i]) == 1:
ValueError: invalid literal for int() with base 10: 'p'

>>> Done (return code 1)


When I run tpc_ber_curve_gen.grc I get following error

Using Volk machine: avx_32_mmx_orc
Traceback (most recent call last):
  File "/home/gnuradio/gr-fec/examples/tpc_ber_curve_gen.py", line 450, in

tb.start()
  File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
line 106, in start
top_block_start_unlocked(self._impl, max_noutput_items)
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py", line
4860, in top_block_start_unlocked
return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
RuntimeError: boost::thread_resource_error: Resource temporarily unavailable

>>> Done

fecapi_async_decoders.grc runs without any errors.

Any Ideas what could be wrong ?

--
Bob

Re: [Discuss-gnuradio] Generate a specific wave form

[Antonny Caesar]

Jeon wrote in post #1175836:
> If those overshoots are unwanted but inevitable due to hardware
> characteristics and limitations,
>
> you can generate a wave form with vector source with input sequence
> 101001111...
>
> Then, the output will be HLHLLHHHH... (H = HIGH, LOW = LOW)
>
> Regards,
> Jeon.
>
> 2015-06-29 23:23 GMT+09:00 Antonny Caesar :

Well, I don't think this solution using vector works (I might be wrong,
of course). I tried to build it in the latest version of Gnuradio which
is 3.7.2.1 (Ubuntu 14.04 LTS). The prints are shown below:

The blocks:
http://i62.tinypic.com/i2ppjl.png

Input signal:
http://i61.tinypic.com/29zy7ft.png

Output Signal:
http://i60.tinypic.com/rjjy9u.png

Vector created:
http://i57.tinypic.com/2efru6o.png

What I need to do is a kind of "switch". With this vector in the Ctrl
Port of the Sample & Hold, I want the same wave of the input in the
output, but appearing and desappearing according to the Vector Source (0
- no signal, 1 - entire signal).

If the signal in the Input Port is a square wave, then I want the same
wave but appearing and desappearing in a random way according to the
vector I created, but It isn't happening.

I don't know if I was clear enough. Please, help me and tell me if you
need more details about my problem.

Sorry and thank you.

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] Problems installing gr-foo and gr-ieee802-11

[Gabriele Galiero]

Hello, thanks for your help. I tried the command but again it is not 
working I guess that parameter after --hard is different for each 
individual case, because this message appears now.

fatal: Could not parse object 
'00beec517d096e4f2f6a45250750369db90dc104'.

Thanks anyways for your reply.
Best regards.

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] Problems installing gr-foo and gr-ieee802-11

[Alta Alta]

The reply from Bastian Bloessl to correspond with him about this error 
was as follow:

you need GNU Radio 3.7.6 for this. I will adapt the CMakeLists.txt file 
to produce a better error message.

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] Problems installing gr-foo and gr-ieee802-11

[Gabriele Galiero]

I actually introduced the command you sent to me after>

cd gr-foo

and it worked. Now everything is working. Thanks so much for your help. 
I should have tried more before posting.

BR

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] Problems installing gr-foo and gr-ieee802-11

[Bastian Bloessl]

On 06/30/2015 03:02 PM, Alta Alta wrote:

The reply from Bastian Bloessl to correspond with him about this error
was as follow:

you need GNU Radio 3.7.6 for this. I will adapt the CMakeLists.txt file
to produce a better error message.



I did that yesterday:

https://github.com/bastibl/gr-foo/commit/2f71946215255e77847dcb1054ab2615818953c0

Recently, Sylvain added a timeout parameter to delete_head_blocking of 
basic_block. This avoids busy-wating for new messages. One block uses 
this timeout parameters. Thus, you need 3.7.6.


https://github.com/gnuradio/gnuradio/commit/2d755af9cd2668a3a8f55bd14c8b598234729957

I guess with some cmake magic and preprocessor directives it's possible 
to compile this also with older GNU Radio versions.


Best,
Bastian

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

[Discuss-gnuradio] Is there a project which implements half-duplex communications?

[Jeon]

Hello, GNU Radio users,

Very long time ago, USRP 1 was not suitable for half-duplex communications
because USB 2.0 interface is too slow to achieve it.
But now, there are USRP embedded and gigabit ethernet supporting USRP
series.
In my opinion, thus, half-duplex communications might be achievable
nowadays.

I am curious that there is a project which implements half-duplex
communications.
If there is, how many USRPs, daughterboards and antennas are used for each
node?
Can I find such a project in pybombs?

In my guess, a half-duplex communication application can be built from both
USRP sink and source being placed in one flow graph.
But I have no idea of the rest of the flow graph. Should the flow graph
open loop or closed loop?
Is there a special configuration or tweak on USRP or GNU Radio required to
achieve half-duplex communications?

I apologize if my question sounds quite vague.

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

Re: [Discuss-gnuradio] Generate a specific wave form

[Marcus Müller]

Why do you use the sample and hold block?
You could use
vector_source->(throttle)->QT time sink


Best regards,
Marcus


On 06/30/2015 02:53 PM, Antonny Caesar wrote:
> Jeon wrote in post #1175836:
>> If those overshoots are unwanted but inevitable due to hardware
>> characteristics and limitations,
>>
>> you can generate a wave form with vector source with input sequence
>> 101001111...
>>
>> Then, the output will be HLHLLHHHH... (H = HIGH, LOW = LOW)
>>
>> Regards,
>> Jeon.
>>
>> 2015-06-29 23:23 GMT+09:00 Antonny Caesar :
> Well, I don't think this solution using vector works (I might be wrong,
> of course). I tried to build it in the latest version of Gnuradio which
> is 3.7.2.1 (Ubuntu 14.04 LTS). The prints are shown below:
>
> The blocks:
> http://i62.tinypic.com/i2ppjl.png
>
> Input signal:
> http://i61.tinypic.com/29zy7ft.png
>
> Output Signal:
> http://i60.tinypic.com/rjjy9u.png
>
> Vector created:
> http://i57.tinypic.com/2efru6o.png
>
> What I need to do is a kind of "switch". With this vector in the Ctrl
> Port of the Sample & Hold, I want the same wave of the input in the
> output, but appearing and desappearing according to the Vector Source (0
> - no signal, 1 - entire signal).
>
> If the signal in the Input Port is a square wave, then I want the same
> wave but appearing and desappearing in a random way according to the
> vector I created, but It isn't happening.
>
> I don't know if I was clear enough. Please, help me and tell me if you
> need more details about my problem.
>
> Sorry and thank you.
>


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

Re: [Discuss-gnuradio] Is there a project which implements half-duplex communications?

[Marcus Müller]

Hi Jeon,

Yes, of course these things have been doable for quite some time -- not
very much because the latency of the buses went down, but more because
the USRPs learned to use command times, which means that you could
instruct the USRP to start to receive and transmit at sample-accurate
times, so to hide the latencies.

By now, there's quite some standards implemented. gr-mac, formerly
pre-cog, is one of the frameworks you could build upon.
Bastian Bloessl has actually developed multiple working transceivers:
Have a look at gr-iee802-11 (working WiFi implementation) an
gr-iee802-15-4 (Zigbee); they do work pretty well.

Best regards,
Marcus

On 06/30/2015 03:30 PM, Jeon wrote:
> Hello, GNU Radio users,
>
> Very long time ago, USRP 1 was not suitable for half-duplex
> communications because USB 2.0 interface is too slow to achieve it.
> But now, there are USRP embedded and gigabit ethernet supporting USRP
> series.
> In my opinion, thus, half-duplex communications might be achievable
> nowadays.
>
> I am curious that there is a project which implements half-duplex
> communications.
> If there is, how many USRPs, daughterboards and antennas are used for
> each node?
> Can I find such a project in pybombs?
>
> In my guess, a half-duplex communication application can be built from
> both USRP sink and source being placed in one flow graph.
> But I have no idea of the rest of the flow graph. Should the flow
> graph open loop or closed loop?
> Is there a special configuration or tweak on USRP or GNU Radio
> required to achieve half-duplex communications?
>
> I apologize if my question sounds quite vague.
>
> Regards,
> Jeon.
>
>
> ___
> 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] Is there a project which implements half-duplex communications?

[Tim]

Jeon,
Also check out
http://wp.me/p55sJw-2v
software based half duplex burst PSK modem which can operate using a
single USRP, file loopback, or other SDR
-Tim

On 06/30/2015 09:30 AM, Jeon wrote:
> Hello, GNU Radio users,
>
> Very long time ago, USRP 1 was not suitable for half-duplex
> communications because USB 2.0 interface is too slow to achieve it.
> But now, there are USRP embedded and gigabit ethernet supporting USRP
> series.
> In my opinion, thus, half-duplex communications might be achievable
> nowadays.
>
> I am curious that there is a project which implements half-duplex
> communications.
> If there is, how many USRPs, daughterboards and antennas are used for
> each node?
> Can I find such a project in pybombs?
>
> In my guess, a half-duplex communication application can be built from
> both USRP sink and source being placed in one flow graph.
> But I have no idea of the rest of the flow graph. Should the flow
> graph open loop or closed loop?
> Is there a special configuration or tweak on USRP or GNU Radio
> required to achieve half-duplex communications?
>
> I apologize if my question sounds quite vague.
>
> Regards,
> Jeon.
>
>
> ___
> 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] QT scope block?

[numeric]

Thank you Marcus. 
I tried again to implement your suggestion. This time I had success! Thank
you!
However, I had to make changes. I set the constellation sink for 2 inputs
and added a second float to complex block. This provides a Y (or vertical)
scope input representing the waveform R + J*X. Where R is the "real"
component of the VNA reflection component and X is the "imaginary" component
of the reflection component. They are both plotted on the same axis. The
orthogonal scope axis is the driving VNA VCO waveform (used a sawtooth) and
is the same waveform for R and X reflection parts.
 
The ambiguous part: 
The float to complex provides two float input ports and one complex output
port. I believe the top float port is the "in-phase" and the bottom float
port is the "quadrature-phase" port. I need to document further what I did,
a picture, as they say, is worth a 1000 words. I have a screen shot of the
waveform and GRC flow diagram. I transferred the png file to windows but the
file name causes problems in windows. However, at this time I have another
project  to complete first. 
Thank you for your help,
Rob
 



Marcus Müller-3 wrote
> I don't know how you want to trigger your Oscilloscope in X/Y mode --
> hence I used the "Free" trigger mode, to generate the lissajous figures
> I sent you. What's wrong about them? If you describe what you're
> expecting, we might find a solution together. 





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/QT-scope-block-tp54482p54524.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] QT scope block?

[Marcus Müller]

Hi Rob,
> The float to complex provides two float input ports and one complex output
> port. I believe the top float port is the "in-phase" and the bottom float
> port is the "quadrature-phase" port.

if you hover above these ports you'll see that the upper is "re" (real)
and the other is "im" (imaginary), which, typically, maps to I and Q.

> I transferred the png file to windows but the
> file name causes problems in windows.
Um, I think renaming a file shouldn't be that hard :) make sure you
attach .png; many file managers on Linux autodetect the content of a
file, no matter what the extension is (or if it's missing), but Windows
Explorer might be stuck in the 80s, feature-wise. Also, Unix filesystems
typically support UTF-8, but if you e.g. use a FAT32-formatted USB
drive, you might encounter problems...

Best regards,
Marcus

On 06/30/2015 04:52 PM, numeric wrote:
> Thank you Marcus. 
> I tried again to implement your suggestion. This time I had success! Thank
> you!
> However, I had to make changes. I set the constellation sink for 2 inputs
> and added a second float to complex block. This provides a Y (or vertical)
> scope input representing the waveform R + J*X. Where R is the "real"
> component of the VNA reflection component and X is the "imaginary" component
> of the reflection component. They are both plotted on the same axis. The
> orthogonal scope axis is the driving VNA VCO waveform (used a sawtooth) and
> is the same waveform for R and X reflection parts.
>  
> The ambiguous part: 
> The float to complex provides two float input ports and one complex output
> port. I believe the top float port is the "in-phase" and the bottom float
> port is the "quadrature-phase" port. I need to document further what I did,
> a picture, as they say, is worth a 1000 words. I have a screen shot of the
> waveform and GRC flow diagram. I transferred the png file to windows but the
> file name causes problems in windows. However, at this time I have another
> project  to complete first. 
> Thank you for your help,
> Rob
>  
>
>
>
> Marcus Müller-3 wrote
>> I don't know how you want to trigger your Oscilloscope in X/Y mode --
>> hence I used the "Free" trigger mode, to generate the lissajous figures
>> I sent you. What's wrong about them? If you describe what you're
>> expecting, we might find a solution together. 
>
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/QT-scope-block-tp54482p54524.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


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

[Discuss-gnuradio] hierarchical polyphase channelizer vs polyphase channelizer blocks in GRC

[ben Gee]

Does anyone have any knowledge of how the parameters need to be set in the
hierarchical pfb channelizer? There's no documentation that I can find.

I HAVE gotten the regular channelizer to work and it's awesome (screenshots
included), I was just hoping to use a hierarchical version that would be
able to use multiple blocks and therefore utilize multiple processors.

otherwise I have to design my own, which is not on my 'fun list'.


thanks,
-b

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

Re: [Discuss-gnuradio] hierarchical polyphase channelizer vs polyphase channelizer blocks in GRC

[Marcus Müller]

Hi ben,
> otherwise I have to design my own, which is not on my 'fun list'.
What? that sounds like such an awesome project!

The point is that polyphase channelizers inherently make use of the fact
that you can a) split the sample stream into multiple polyphase
components, b) do the same with the filter taps, c) run the individual
filters at the lower rate and d) use the FFT amongst a lot of
permutations. This complexity makes it desirable to do this in one block.

Looking at pfb_channelizer_ccf:

189 while(i >= 0) {
190   in = (gr_complex*)input_items[j];
191   d_fft->get_inbuf()[d_idxlut[j]] = 
d_fir_filters[i]->filter(&in[n]);
192   j++;
193   i--;
194 }
195
196 i = d_nfilts-1;
197 while(i > last) {
198   in = (gr_complex*)input_items[j];
199   d_fft->get_inbuf()[d_idxlut[j]] = 
d_fir_filters[i]->filter(&in[n-1]);
200   j++;
201   i--;
202 }


both while loops could lend themself to parallelization, if d_idxlut has
j unique elements; but that's the case (for this particular
implementation, this might be different for channelizers that map the
same stream to multiple frequencies):

 87   for(unsigned int i = 0; i < d_nfilts; i++) {
 88 d_idxlut[i] = d_nfilts - ((i + d_rate_ratio) % d_nfilts) - 1;
 89   }

The easiest solution would be modifying polyphase_filterbank.cc, and
adding something like d_thread_workers. I'd recommend not overdoing
parallelization, a single filter(float) step doesn't really justify the
synchronization overhead. I'd start with just wrapping the two while
loops in two separate threads.

Best regards,
Marcus

On 06/30/2015 07:14 PM, ben Gee wrote:
> Does anyone have any knowledge of how the parameters need to be set in
> the hierarchical pfb channelizer? There's no documentation that I can
> find. 
>
> I HAVE gotten the regular channelizer to work and it's awesome
> (screenshots included), I was just hoping to use a hierarchical
> version that would be able to use multiple blocks and therefore
> utilize multiple processors. 
>
> otherwise I have to design my own, which is not on my 'fun list'. 
>
>
> thanks,
> -b
>
> http://imgur.com/nh53Ryw
>
>
>
> ___
> 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] Generate a specific wave form

[Antonny Caesar]

Marcus, I'm using it because the vector isn't the signal I want. The 
vector is just to control when a signal goes to the output and when it 
doesn't. Like I said: 0 - no signal, 1 - entire signal.

The sample and Hold block should pass the signal to the output when ctrl 
= 1 and hold the output when ctrl = 0, but it doesn't happen and I don't 
know why.

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] Generate a specific wave form

[Rafael Acurcio]

Have you tried to miltuply the signals?
Because your vector source outputs ones and zeros it will not change the
shape of the signal but it will enable (.1) or disable (.0) the original
signal.

On Tue, 30 Jun 2015 at 10:49 Antonny Caesar  wrote:

> Marcus, I'm using it because the vector isn't the signal I want. The
> vector is just to control when a signal goes to the output and when it
> doesn't. Like I said: 0 - no signal, 1 - entire signal.
>
> The sample and Hold block should pass the signal to the output when ctrl
> = 1 and hold the output when ctrl = 0, but it doesn't happen and I don't
> know why.
>
> --
> Posted via http://www.ruby-forum.com/.
>
> ___
> 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] OFDM example from gr-digital with UHD

[Jose Perez]

Hi Marcus,

Thanks so much for the answer. But like in the screenshots of Gabriele, the
blocks OFDM Transmitter e OFDM Receiver are off. And I can't visualize four
symbols (QPSK) or 2 symbols (BPSK) in the output of QT Constellation just a
big one (see the screenshot), is this correct?

Thanks again.


 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/OFDM-example-from-gr-digital-with-UHD-tp54446p54530.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] Generate a specific wave form

[Antonny Caesar]

Rafael,

Yes, I have... It didn't work either and I don't know why. The first 
thing I tried was multiply the signals. It's really strange.

There are some blocks in GNURadio that don't do what they say they do, 
like this Sample and Hold block. This block don't "hold" the samples, 
like it should do.

The implementation of Sample and Hold, for example, in another softwares 
work perfectly, but in GNURadio it doesn't and it is a standard block. 
It's very strange.

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] OFDM example from gr-digital with UHD

[Martin Braun]

On 30.06.2015 10:41, Jose Perez wrote:
> Hi Marcus,
> 
> Thanks so much for the answer. But like in the screenshots of Gabriele, the
> blocks OFDM Transmitter e OFDM Receiver are off. And I can't visualize four
> symbols (QPSK) or 2 symbols (BPSK) in the output of QT Constellation just a
> big one (see the screenshot), is this correct?

Are you plotting the output of the IFFT by any chance?

M


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

Re: [Discuss-gnuradio] OFDM example from gr-digital with UHD

[Jose Perez]

I am plotting the signal after the Multiply Const Block ... the signal that I
will transmitt with USRP.
Isn't correct? 

 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/OFDM-example-from-gr-digital-with-UHD-tp54446p54534.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] OFDM example from gr-digital with UHD

[Martin Braun]

On 30.06.2015 11:06, Jose Perez wrote:
> I am plotting the signal after the Multiply Const Block ... the signal that I
> will transmitt with USRP.
> Isn't correct? 
> 

If what you want to plot is your constellation, then no, it's not. This
is all modulated, pulse shaped and all.

Cheers,
M

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

Re: [Discuss-gnuradio] Generate a specific wave form

[Marcus Müller]

0= no signal, 1 = full signal:
then just use a multiplier!

Best regards,
Marcus

On 06/30/2015 07:48 PM, Antonny Caesar wrote:
> Marcus, I'm using it because the vector isn't the signal I want. The 
> vector is just to control when a signal goes to the output and when it 
> doesn't. Like I said: 0 - no signal, 1 - entire signal.
>
> The sample and Hold block should pass the signal to the output when ctrl 
> = 1 and hold the output when ctrl = 0, but it doesn't happen and I don't 
> know why.
>


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

Re: [Discuss-gnuradio] OFDM example from gr-digital with UHD

[Jose Perez]

So ... Is it possible to see the Constellation points like QPSK in this
flowgraph?
Sorry for so many questions!

Thanks Martin!



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/OFDM-example-from-gr-digital-with-UHD-tp54446p54537.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] OFDM example from gr-digital with UHD

[Marcus Müller]

Jose,

we're talking about this flow graph, right?
http://gnuradio.4.n7.nabble.com/file/n54534/ofdm_tx.png

In this flow graph, you're trying to find the individual symbols in time
domain; that's not possible, they only exist clearly distinguishable in
frequency. That is why there is an DFT (in this implementation, the FFT)
in OFDM!

Best regards,
Marcus

On 06/30/2015 09:12 PM, Jose Perez wrote:
> So ... Is it possible to see the Constellation points like QPSK in this
> flowgraph?
> Sorry for so many questions!
>
> Thanks Martin!
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/OFDM-example-from-gr-digital-with-UHD-tp54446p54537.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


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

[Discuss-gnuradio] HRPT receiver

[Daniel Marlow]

Hello,

   In the gnuradio/gr-noaa/README file under usrp_rx_hrpt.py, there is a 
comment that 
reads as follows:

"The present HRPT demodulator is only tested at decimation 16.The only other
valid decimation rates are 24 and 32, which may work, but with more bit errors. 
 No
other decimation rates will work."

My (perhaps naive) question is whether the important parameter is the 
decimation 
rate, or the sampling rate.   For example, with 64 MHz USRP, a decimation of 16 
would 
give 4 MHz sampling, whereas with a higher rate USRP, the same decimation would 
yield a higher sampling rate.   

I would appreciate it if someone could clarify this point for me.

Sincerely,
Dan Marlow



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

Re: [Discuss-gnuradio] HRPT receiver

[Marcus Müller]

Hi Daniel,
that README refers to things of the past (when you specified a
decimation rather than the sampling rate you want), and "USRP" refered
to what we nowadays call the USRP1.

In the version of the usrp_rx_hrpt.grc, from which the .py gets
generated, the USRP source is just configured to 4MS/s.

The question is whether 4MS/s is really the optimum rate; I haven't
studied the HRPT signal enough to answer this. In principle, for the
100MHz devices (N210/N200), 4MS/s is a suboptimal rate, since the
decimation (25) is odd, and I'd try with something less strange, like 5MS/s.

Best regards,
Marcus

On 06/30/2015 10:49 PM, Daniel Marlow wrote:
> Hello,
>
>In the gnuradio/gr-noaa/README file under usrp_rx_hrpt.py, there is
> a comment that 
> reads as follows:
>
> "The present HRPT demodulator is only tested at decimation 16.The
> only other
> valid decimation rates are 24 and 32, which may work, but with more
> bit errors.  No
> other decimation rates will work."
>
> My (perhaps naive) question is whether the important parameter is
> the decimation 
> rate, or the sampling rate.   For example, with 64 MHz USRP, a
> decimation of 16 would 
> give 4 MHz sampling, whereas with a higher rate USRP, the same
> decimation would 
> yield a higher sampling rate.   
>
> I would appreciate it if someone could clarify this point for me.
>
> Sincerely,
> Dan Marlow
>
>
>
>
>
> ___
> 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] HRPT receiver

[Daniel Marlow]

Hi Marcus,

   Thanks.   That explains it.   Will try 5 MHz with our N200.

Cheers,
Dan

On Jun 30, 2015, at 4:56 PM, Marcus Müller wrote:

> Hi Daniel,
> that README refers to things of the past (when you specified a decimation 
> rather than the sampling rate you want), and "USRP" refered to what we 
> nowadays call the USRP1.
> 
> In the version of the usrp_rx_hrpt.grc, from which the .py gets generated, 
> the USRP source is just configured to 4MS/s.
> 
> The question is whether 4MS/s is really the optimum rate; I haven't studied 
> the HRPT signal enough to answer this. In principle, for the 100MHz devices 
> (N210/N200), 4MS/s is a suboptimal rate, since the decimation (25) is odd, 
> and I'd try with something less strange, like 5MS/s.
> 
> Best regards,
> Marcus
> 
> On 06/30/2015 10:49 PM, Daniel Marlow wrote:
>> Hello,
>> 
>>In the gnuradio/gr-noaa/README file under usrp_rx_hrpt.py, there is a 
>> comment that 
>> reads as follows:
>> 
>> "The present HRPT demodulator is only tested at decimation 16.The only 
>> other
>> valid decimation rates are 24 and 32, which may work, but with more bit 
>> errors.  No
>> other decimation rates will work."
>> 
>> My (perhaps naive) question is whether the important parameter is the 
>> decimation 
>> rate, or the sampling rate.   For example, with 64 MHz USRP, a decimation of 
>> 16 would 
>> give 4 MHz sampling, whereas with a higher rate USRP, the same decimation 
>> would 
>> yield a higher sampling rate.   
>> 
>> I would appreciate it if someone could clarify this point for me.
>> 
>> Sincerely,
>> Dan Marlow
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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] OFDM example from gr-digital with UHD

[Martin Braun]

On 30.06.2015 12:12, Jose Perez wrote:
> 
> So ... Is it possible to see the Constellation points like QPSK in this
> flowgraph?
> Sorry for so many questions!

On TX, you can plot the complex symbols before they go into the carrier
allocator. On the receive side, you can do the same after the carrier
serializer. This won't exactly plot 1 OFDM symbol at a time, if that is
what you want.

Also, in both cases, the output will be pretty boring. On TX, it's just
your constellation; on RX, it's already equalized, so it's also just the
constellation.

M


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

[Discuss-gnuradio] OSX 10.10

[Ed Criscuolo]

Michael,

A few months ago, I upgraded to OSX 10.10.1  Yosemite.
My existing install of GnuRadio 3.7.5 continued to work,
but today I tried to recompile an OOT module and it
failed.  Something about a library incompatibility
change between Mountain Lion and Mavericks.

So I did a port selfupdate and tried to upgrade to
3.7.7.1.  The build failed, with:

--->  Computing dependencies for swig
--->  Building swig
Error: org.macports.build for port swig returned: command execution failed

The log file shows:

...
:info:build In file included from /usr/local/include/sys/file.h:26:
:info:build /usr/local/include/sys/Conf.h:28:12: fatal error: 'iosfwd' 
file not found

:info:build #  include 
:info:build^
...

Is this a known problem?

@(^.^)@  Ed

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

Re: [Discuss-gnuradio] Generate a specific wave form

[Antonny Caesar]

Marcus, I see what you mean, but you didn't understand what I wanna do. 
Using a multiplier you are modificating the original signal. I don't 
want to multiply the samples, I want nothing or the entire signal.

What I mean is:
0 = no signal at all, everything is 0 and not only a piece of the 
signal. The entire sine wave times 0 -> sine x 0 = 0.
1 = the entire signal, but not only a sample x 1, like you showed. I 
need to multiply the everything by 1 and leave the signal pass.

Abstract:

"Nothing" if the control is 0, and "EVERYTHING" if the control is 1. I 
don't need pieces of wave times 0 or 1, I need the whole signal times 0 
or 1, like a switch. Did you get it? It's hard to build it here.

Thanks a lot.

-- 
Posted via http://www.ruby-forum.com/.

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

Re: [Discuss-gnuradio] Generate a specific wave form

[Jeon]

Dear Caesar,

If there's a certain purpose of this work but that is not explained this
post, it's better for us to know the purpose.
But, you might not want to explain that if it is confidential.

Anyway,
The original signal stays unmodified. You can get the original signal by
connecting the original source block to another block.
And you can get the whole part of the the original signal or nothing by
setting duration, repetition or interpolation of each bit from a vector
stream, which will be a multiplier.



You can easily set a length/duration of each sample from a vector source by
using repeat block.
The figure above will generates  200 zeros, 200 ones, 200 zeros and 200
ones.
It is equivalent to a vector source with (0, 0, 0, ..., 1, 1, 1, ..., 0, 0,
0, ..., 1, 1, 1, ...)

But, if you want something different,
for example, if you want to pause/stop the signal source block (or USRP
source block, etc.) temporarily when the switch block (the vector source
block or other trigger blocks) give zero
and resume the source block when the switch block gives one,
it seems you need to approach the problem in a different way.

As I read your question again, it seems that you want a flow graph to
output literally 'nothing' not even zero, is it right?
In other words, you want to drop a part of the original signal when the
switch value is zero.
In that case, a valve block might help you. But I doubt that a vector
source can be an argument of the valve block.
(I might be wrong. There can be a block can do what you want, but not sure
about it.)

I recommend you to build a pass-or-drop, pass-or-block block.

Regard,
Jeon.

2015-07-01 11:59 GMT+09:00 Antonny Caesar :

> Marcus, I see what you mean, but you didn't understand what I wanna do.
> Using a multiplier you are modificating the original signal. I don't
> want to multiply the samples, I want nothing or the entire signal.
>
> What I mean is:
> 0 = no signal at all, everything is 0 and not only a piece of the
> signal. The entire sine wave times 0 -> sine x 0 = 0.
> 1 = the entire signal, but not only a sample x 1, like you showed. I
> need to multiply the everything by 1 and leave the signal pass.
>
> Abstract:
>
> "Nothing" if the control is 0, and "EVERYTHING" if the control is 1. I
> don't need pieces of wave times 0 or 1, I need the whole signal times 0
> or 1, like a switch. Did you get it? It's hard to build it here.
>
> Thanks a lot.
>
> --
> Posted via http://www.ruby-forum.com/.
>
> ___
> 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] Is there a project which implements half-duplex communications?

[Jeon]

Dear Tim and Marcus,

Thank you very much.

I'll take a look at those projects.

Regards,
Jeon.

2015-07-01 0:03 GMT+09:00 Tim :

>  Jeon,
> Also check out
> http://wp.me/p55sJw-2v
> software based half duplex burst PSK modem which can operate using a
> single USRP, file loopback, or other SDR
> -Tim
>
>
> On 06/30/2015 09:30 AM, Jeon wrote:
>
>   Hello, GNU Radio users,
>
> Very long time ago, USRP 1 was not suitable for half-duplex communications
> because USB 2.0 interface is too slow to achieve it.
>  But now, there are USRP embedded and gigabit ethernet supporting USRP
> series.
>  In my opinion, thus, half-duplex communications might be achievable
> nowadays.
>
>  I am curious that there is a project which implements half-duplex
> communications.
> If there is, how many USRPs, daughterboards and antennas are used for each
> node?
>  Can I find such a project in pybombs?
>
>  In my guess, a half-duplex communication application can be built from
> both USRP sink and source being placed in one flow graph.
>  But I have no idea of the rest of the flow graph. Should the flow graph
> open loop or closed loop?
>  Is there a special configuration or tweak on USRP or GNU Radio required
> to achieve half-duplex communications?
>
>  I apologize if my question sounds quite vague.
>
>  Regards,
>  Jeon.
>
>
> ___
> 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] Correlation Estimator Bugs

[Richard Bell]

Hi all,

I was just looking through the code in corr_est_cc_impl.cc because it is
behaving unexpectedly and I think I have spotted a few bugs.

1) If you look at line 203 inside _set_threshold and line 240 inside work,
the correlation output is being squared in both cases. The output of the
correlation operation is already proportional to the voltage squared, so
squaring it again makes it proportional to the fourth of voltage. These
extra squares are likely a bug. I don't think this has a big effect on
function, but it's not optimal and is extra calculations nonetheless. It is
also the case that the phase_est and time_est values are being calculated
on mag^4 data instead of mag^2 data. Because they are both monotonically
increasing, again there is probably not a functional effect, but once again
not optimal.

2) The peak value of the correlation peak is being reported as twice as big
as they should be able to get, given a known input length with no noise
added. For example, given a length 10 sequence which we correlate against,
when they align perfect, you expect to see a peak value of 100 (1 or -1
times itself summed 10 times = 10 and then squared because of the current
code implementation is 100). Yet, the peak values reported by the
corr_start tag value are 200, which shouldn't be achievable. I can't figure
out where this factor of two is being introduced in the code.

3) This may be intended, but doesn't feel right. When you look at the
correlation output port (port 1), the values of the y-axis seem to have
been square rooted, so that they appear to be in the range you would
expect, though the corr_start tag shows the squared peak value that is
proportional to the 4th of voltage. It's confusing and the fact that these
two values are being sent to the user makes me think this is unintentional.

4) I have noticed that when I start my receiver first, with a power squelch
gate up front, and then start my transmitter, the correlator places
thousands of tags on the initial output of the squelch. While the input
data is very low, the values of the mag^2 being reported in the corr_start
tag value are very high, well above threshold. I don't know how this could
happen. It's causing thousands of false tags to be placed in the stream
that should not be there. I have not figured out anything concrete about
this bug. It's possible it could be my setup, but I don't see how yet. This
is an over the air test.

I'm hoping the original block designers can provide some feedback that
might help me understand what the intentions were.

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