Hello,
I was just asking myself, why gr-sounder isn't contained in GNU Radio 3.5 any
more.
Does anybody know the reason?
Thanks.
Best regards,
Daniel
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/disc
Am 23.12.2011 um 17:04 schrieb Tom Rondeau:
> Hi Daniel,
> Sorry for not responding before; just lost track. I really wanted to thank
> you for putting this together and offering it to the community. That's really
> great! I plan on looking this over soon.
>
> Tom
Hi Tom,
thanks for your resp
Hi,
I have made some improvements to my code at GitHub:
- Created GRC xml files for the modified burst tagger and the existing tagged
file sink
- Added a tagged message sink, which is based on the existing tagged file sink
- Added Python QA code for the burst tagger and the tagged message sink
Hi,
I have made some modifications to the existing burst tagger in the GNU Radio
source code.
It is now able to specify an amount of pre and post samples, which are
additionally tagged before and after the tag signal.
I have put my changes on my GitHub account, which is:
https://bar...@github
Hi,
I found a bug in the 'gr_tagged_file_sink.cc' file during my work on a burst
detection.
Line 203 should be changed to:
203 int count = fwrite (&inbuf[d_itemsize*idx], d_itemsize, noutput_items-idx,
d_handle);
The original code was:
202 if(d_state == IN_BURST) { 203 int count = fwrite
Hi.
I would like to use the Python package "packet_utils" for packet-oriented
transmission in combination with a QAM modulation scheme.
I figured out, that currently in GNU Radio no QAM demodulation is implemented.
However I read in this mailing list, that a few people are working on it or did
16:24 schrieb Alexander Chemeris:
> Daniel,
>
> What hardware setup do you use to achieve 25MS/s? I wasn't able to
> get stable connection with more then 16MS/s, and even at 16MS/s I had
> drops.
>
> On Sun, May 15, 2011 at 17:04, Daniel Bartel
> wrote:
>> Hello
>> Hello,
>>
>> I was wondering about a little conflict concerning the sizes of the data
>> types in GNU Radio.
>>
>> The UHD driver sends 16 bits I, 16 bits Q samples over the ethernet
>> interface at 25 MS/s and the return value of "gr.sizeof_gr_complex" is 8
>> bytes (64 bits).
>> How does
Hello,
I was wondering about a little conflict concerning the sizes of the data types
in GNU Radio.
The UHD driver sends 16 bits I, 16 bits Q samples over the ethernet interface
at 25 MS/s and the return value of "gr.sizeof_gr_complex" is 8 bytes (64 bits).
How does this actually work?
I have
Hi Tom,
thanks for your explanation and sorry for my late reply.
> What block are you using to call the interpolator? What values is the block
> working off? If it's the M&M clock recovery block, it's possible that the
> amplitude your input signal is too high, which is causing overly-large er
>>> But from my tests I see that
>>> 1 bit error in -> 7 bit errors out
>>> 2 consecutive bit errors in -> 2 errors in the output
>>> 3 consecutive bit errors in -> 7 errors in the output
>>> 4 consecutive bit errors in -> 4 errors in the output
>>> ...
>>> And so forth up to 7 (Length of the lfsr)
Hello.
> I need to use external clock on usrp, there are two kinds of clock: sine wave
> and square wave. which
> is better for usrp?
I used for my N210 a square wave signal, because it was suggested on
http://www.ettus.com/uhd_docs/manual/html/index.html
Daniel
___
Hello,
in the program I am currently working on, I sometimes get the following error
messsage:
python: gri_mmse_fir_interpolator_cc.cc:66: gr_complex
gri_mmse_fir_interpolator_cc::interpolate(const gr_complex*, float):
Zusicherung »imu >= 0« nicht erfüllt.
Abgebrochen
It seems like the assert
and make it a little bit 'cleaner'.
Afterwards I will put it in a public repository, so at this moment I can only
post some code pieces, if needed.
Kind regards,
Daniel Bartel
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Thanks for your reply...
> Perhaps you are in a particularly bad multipath environment? Although I agree
> that changing the power should have more than a tenth of a dB effect on the
> SNR. Have you tried turning it down? Or really, can your plot the spectrum at
> the receiver and verify that t
15 matches
Mail list logo