[Discuss-gnuradio] gr-sounder in GNU Radio 3.5
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/discuss-gnuradio
Re: [Discuss-gnuradio] Added functionality for pre and post samples to burst tagger
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 response. If you find any bugs or "things" I could make better in my GR code, just tell me. Daniel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Added functionality for pre and post samples to burst tagger
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 Maybe this additions are useful for somebody on the list. It would be a pleasure for me :-). Best regards, Daniel > 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.com/bartel/gnuradio-bartel.git > > > Since this is my first work with Git and my first direct change to the GNU > Radio source code, I would be glad for any advise on improving my > code/changes. > > I have also tested my code locally, since I am not quite sure, how to add a > QA > code for a C++ block to GNU Radio. Should it be with cppunit or pyunit? > Thank's for helping. > > Best regards, > Daniel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Added functionality for pre and post samples to burst tagger
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.com/bartel/gnuradio-bartel.git Since this is my first work with Git and my first direct change to the GNU Radio source code, I would be glad for any advise on improving my code/changes. I have also tested my code locally, since I am not quite sure, how to add a QA code for a C++ block to GNU Radio. Should it be with cppunit or pyunit? Thank's for helping. Best regards, Daniel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bug in 'gr_tagged_file_sink.cc'
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 (&inbuf[idx], d_itemsize,
noutput_items-idx, d_handle);
204 if (count == 0) {
205 if(ferror(d_handle)) {
206 perror("gr_tagged_file_sink: error writing file");
207 }
208 }
209 idx = noutput_items;
210 }
Daniel
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] QAM demodulation state
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 so in the past. So my question is, what is the current state of QAM demodulation blocks for GNU Radio? Thanks and best regards, Daniel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 25 MS/s at 16 bits I/Q vs. gr.sizeof_gr_complex
Hello Alexander,
in fact my question was only a theoretical one, because I read in the
mailinglist about the ethernet connection and that 2 x 16Bit x 25MS/s =
800Mbit/s are used.
Concerning my hardware setup I've to look tomorrow, because it's not actually
my pc.
Am 15.05.2011 um 16:07 schrieb Marcus D. Leech:
> UHD converts the incoming samples to complex float, scaled into {-1.0,1.0}.
Does this mean, that there is a loss in accuracy, because a 32 bit data type
(one pair of gr_complex) is converted to a 16 bit data type (float)?
Best regards,
Daniel
Am 16.05.2011 um 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,
>>
>> 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 looked for some documentation of UHD, but I wasn't were lucky.
>>
>> Best regards,
>> Daniel
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> --
> Regards,
> Alexander Chemeris.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 25 MS/s at 16 bits I/Q vs. gr.sizeof_gr_complex
>> 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 looked for some documentation of UHD, but I wasn't were lucky.
>>
>> Best regards,
>> Daniel
>>
> UHD converts the incoming samples to complex float, scaled into {-1.0,1.0}.
Thanks for your answer, I wasn't sure if it's "only" a raw convertion.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 25 MS/s at 16 bits I/Q vs. gr.sizeof_gr_complex
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 looked for some documentation of UHD, but I wasn't were lucky. Best regards, Daniel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Assertion "imu >= 0" failed on random times
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 error > values that are resulting in mu being driven negative. You're right, it's the M&M clock recovery block, which calls the interpolator. What do you mean with "that the amplitude your input signal is too high"? Are there any restricts concerning amplitudes inside the flowgraph? Kind regards, Daniel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BER in bert- example
>>> 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) >>> >>> The reason I ask is that if I want to change the scrambler and/or the >>> modulation, I assume that this "magic number" will change as well. >> >> If you want a good BER measurement, I wouldn't use the method that you >> describe here. > >You are correct. The scrambler introduces three output errors per >input error for single channel errors that are farther apart than the >length of the shift register. This is the case once the shift >register has already achieved self-synchronization and at low channel >error rates. For the purposes of the simple BERT example, this was >sufficient. (The number 3 comes from the number of taps in the >scrambler polynomial.) I know this thread is a bit old, but is it possible that there is an mistake in the text? I think it should be written, that 1 bit error in the scramber input introduces 4 errors in the output, because 1 error is passed directly through and 3 feedback errors are introduced by the taps in the scrambler polynomial of: self._descrambler = gr.descrambler_bb(0x8A, 0x7F, 7) # CCSDS 7-bit descrambler If I'm wrong, don't hesitate to correct me. Thanks. Daniel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] anyone know sine wave or square wave external clock is better for usrp
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Assertion "imu >= 0" failed on random times
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 assertion "imu >= 0" failed.
The strange thing is, that the message behaves completely non-deterministic.
e.g. When I start the program 4 times, on the first 3 runs I get the error
message and suddenly at the 4th try, it runs without an error.
The assertion comes from the following method, which is located in the
gri_mmse_fir_interpolator_cc.cc file.
gr_complex
gri_mmse_fir_interpolator_cc::interpolate (const gr_complex input[], float mu)
{
int imu = (int) rint (mu * NSTEPS);
assert (imu >= 0);
assert (imu <= NSTEPS);
gr_complex r = filters[imu]->filter (input);
return r;
}
Does anyone has an explanation for this behavior or for what "imu >= 0" stands
for?
Thanks for your help,
Daniel
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Implementing digital-bert with UHD
On 14.04.2011 at 16:29 Tachwali, Yahia wrote: > Hello Daniel, > > Do you mind sharing the modified benchmark-examples that you got them to work > on UHD. I am trying to do the same thing using DQPSK but I am getting a > continuous failed to receive packets. It seems to me that the packet format > expected by the receiver is different from that in the transmitter. I would > appreciate sharing the code with me. Thank you. > > > Kind regards, > Yahia Tachwali Thanks for the interest in my source code, but I still need a few weeks to finish the code 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
Re: [Discuss-gnuradio] Implementing digital-bert with UHD
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 the power is actually changing? It actually turned out, that I've forgotten to specify the right antenna on my UHD sink/soure and therefore was receiving cross talk from the second channel. I'm still a freshman on GNUradio :-). > Also, the SNR estimator in gr_probe_mpsk_snr_c is not the most robust > estimator at low SNR. It gets biased when calculating the mean by any samples > over the decision boundaries with the effect of having an "irreducible" SNR > (that's not really the right word for it, but I'm relating it to being the > opposite of an irreducible BER in multipath channels). But I think this point > is around 3 - 4 dB, but it's been a while since I've looked at it. > > This reminds me that I have three other SNR estimators that do an excellent > job at low SNR (theoretically, in the mythical AWGN channels) that I really > need to put into GNU Radio. They are increasingly better at their estimates > at the expense of computational complexity (e.g., one uses the skewness while > another uses the kurtosis). Would be a nice move... Daniel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
