How to get average execution time of a block?
I'm using the 'Lowpass Filter Block'. Is there a way to get the average execution time for that block? Per sample or per 1000 samples, for example? The sample rate is 2 MHz. thanks
Re: Message to Var - modify different variables using one ZMQ Sub Message Source
在 2023年9月11日星期一 CST 下午7:22:44，Bogdan Reshetnikov 写道：
> Good day everyone! I hope you are doing well.
>
> I am an EE undergrad intern at an RF design company's software
> department, currently tasked with controlling a HackRF One SDR with a
> touchscreen display and a Raspberry Pi Zero (flashed with PiSDR because
> it has gnuradio3.9) running Python 3.9. I am a total beginner in GNU
> Radio, but I have intermediate knowledge of writing various interfaces
> in Python.
>
> The RPI runs a threaded script that receives UART a command from the
> display, parses it, and sends a {"parameter": value} PMT pair through
> ZMQ PUB socket.
> It also runs a GNU Radio flowchart script in parallel that receives the
> packet through ZMQ SUB Message source and passes it onto a Message to
> Variable block.
> This setup works great for modifying a single variable that's specified
> in the MesgToVar block, but it breaks down for multiple variables, since
> the from the message pair is ignored.
>
> My current idea is to write an Embedded Python Block that would act as a
> "message multiplexer": it would parse the part and issue a
> message from an according output port. This would mean updating the EPB
> code for every new variable, but that doesn't sound problematic.
>
> Does this sound like a nice approach? Are there any better alternatives
> already present? Let me know what you think. Stay safe!
>
> Bogdan
>
>
I have a similar project, modify multiple parameters with one block. But it's a
different case: I need to change variable with python block, so the solution is
simple to me: just write multiple message output port and use separate message
to var block and it works fine. For your situation, writing a "message
multiplexer" is by far the best idea I can think. BTW, my project address is
https://github.com/Bob0111/HackRF-mutiple-freqeuncy-FM-transmitter if you have
any interest, welcome to view that.
Bob
Som problems about the messaging system
Hello everyone, Now I'm using python embedded module and message system trying to change the value of a variable. And I use the self.message_port_pub function. But the function requires the first one to be the output port, and the second one must be a pmt variable. But when I just do that convert, message pair to var will give me the error like: warning: Input message X is not a simple pair, dropping, so how can I send out the simple pair with the python module just like the QT GUI Toggle do? I search the Internet and get no luck. Also, I also can't find any document related to the self function. Where can I get the document related to that? In the attachment is the grc file I made. Thanks. music_tx_hackrf.grc Description: application/gnuradio-grc
Change variable within the python module
Hello! I now want to build a timer to calculate the transmission time of Osmocom Sink and store it in two variables(minutes and seconds), how can I do that? I search the mailing list and find that it is advised to use the message but in this case, I cannot use a message since I just want to change the value of a variable. And next, I need to send the time value to another python module to control whether to transmit it or not at a specific time with a multiply const with variable value set 1 or 0. Again, I cannot use message since the module doesn't have a port for that. How can I achieve both of them? I search the Internet but still couldn't figure out how to achieve that goal. And in the attachment is the grc file. Best Regards, Bob music_tx_hackrf.grc Description: application/gnuradio-grc
Re: How can I alter install script to bypass dead link causing install to fail on OS X10.6.8?
To try to make a long gnuradio installation on iMac9,1 story short, I'll cut to the chase: My solution was to install OSX 10.14 Mojave on my unsupported iMac9,1 using Dosdude1 Patcher and then skipping mac ports entirely by using the resources at https://github.com/ktemkin/gnuradio-for-mac-without-macports where I installed 3.7 (not 3.8) python and xquartz. It also was required to change my location in settings to United States, otherwise there was an xserver error when launching gnuradio companion. There's probably a way to work around that, but for the simple user, which I proudly consider myself to be, this is fine. If anyone else is using Dosdude1 Patcher, be sure to set the date in Terminal to 2017 with "Date 01017" after booting the install USB, but BEFORE proceeding with the disk preparation or the OS installation. I had various errors on various versions of OS X before I learned to set the date back to a time when the OS versions were still valid. Given the various compile failures I had on 10.6.8 and 10.12 (I did not try 10.13), I would say it would be best to use 10.14 as it did not give any compile errors using Macports nor did it have any problems using the non-ports solution. Thank you Michael for your help! -Bob > On December 29, 2019 at 11:36 PM Michael Dickens > wrote: > > Hi Bob - I can't help you with the Brew issue ... so what I'm wondering > is if you've looked into using MacPorts. It should be able to install GNU > Radio 3.7 latest release on OSX 10.6.8 (and back to 10.4 PPC and forward to > 10.15; I think it can't install on 10.4 Intel, but I'll admit that's a bit > esoteric -- even more so than 10.4/5 PPC these days!). If you run into issues > I can help you out! NP either way ... just offering an alternative. Good > luck! - MLD > > On Sun, Dec 29, 2019 at 5:25 PM Bob < b...@bobcov.com > mailto:b...@bobcov.com > wrote: > > > > > > I am not an expert in OS X. I likely am missing an easy work > > around for a gnuradio install missing file problem. > > > > I tried brew edit gnuradio, but there is no mention in the that > > script of icu4c, which is what is failing when dependencies are being > > addressed after I run brew install gnuradio: > > > > Downloading https://fossies.org/linux/misc/icu4c-55_1-src.tgz > > #=#=-# # > > curl: (22) The requested URL returned error: 410 Gone > > Error: Failed to download resource "icu4c" > > Download failed: https://fossies.org/linux/misc/icu4c-55_1-src.tgz > > > > What is valid is "icu4c-65_1-src.tgz" at the same address (instead > > of 55_1). How can I find the script and run it locally after editing it? > > I also downloaded the icu4c-55 file from a valid link and installed it > > manually, but the brew install gnuradio process apparently does not see > > this installation and goes ahead with the outdated https request. > > > > Is there a way I can alter my host file so that when it looks in > > the wrong place for the 55 version, I can point it to a new place for the > > 55 version? > > > > This is an old iMac9,1 on 10.6.8 which i am trying also to upgrade > > to 10.15, but that is a slow process and in the meantime i want to see if I > > can complete gnuradio so that I can play with my new rtl-sdr dongle. > > > > I googled for this problem and did not find anything. > > > > thanks... > > > > > > > -- > Michael Dickens > Ettus Research Technical Support > Email: supp...@ettus.com mailto:supp...@ettus.com > Web: https://ettus.com/ >
How can I alter install script to bypass dead link causing install to fail on OS X10.6.8?
I am not an expert in OS X. I likely am missing an easy work around for a gnuradio install missing file problem. I tried brew edit gnuradio, but there is no mention in the that script of icu4c, which is what is failing when dependencies are being addressed after I run brew install gnuradio: Downloading https://fossies.org/linux/misc/icu4c-55_1-src.tgz #=#=-# # curl: (22) The requested URL returned error: 410 Gone Error: Failed to download resource "icu4c" Download failed: https://fossies.org/linux/misc/icu4c-55_1-src.tgz What is valid is "icu4c-65_1-src.tgz" at the same address (instead of 55_1). How can I find the script and run it locally after editing it? I also downloaded the icu4c-55 file from a valid link and installed it manually, but the brew install gnuradio process apparently does not see this installation and goes ahead with the outdated https request. Is there a way I can alter my host file so that when it looks in the wrong place for the 55 version, I can point it to a new place for the 55 version? This is an old iMac9,1 on 10.6.8 which i am trying also to upgrade to 10.15, but that is a slow process and in the meantime i want to see if I can complete gnuradio so that I can play with my new rtl-sdr dongle. I googled for this problem and did not find anything. thanks...
[Discuss-gnuradio] GNUradio and external electronic relay switching?
Hi, Pretty new to GNUradio, GRC and Linux. Does anyone have experience with or know if possible to create a flow graph or block to switch a USB relay (as in the kind used for home automation)? What I am interested in is a block or flowgraph which examines output which also goes to the the monitor window. If a specific string is not observed, a signal will be sent to switch the relay for a defined period. The goal is some sort of automated antenna polarity switching depending on what is (or is not) received. Suggestions welcome. Thanks, Bob N6RFM ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about tagged_stream_block
Martin thanks for you reply. I was looking at things wrongly. Now, I ask the scheduler for atleast 1000 samples at a time, using set_output_multiple() and I adjust the tag value if overflow occurs.Thanks again for correction. -- Bob > If you change the size of a tagged stream without changing the tag, > you're producing invalid data. (This may change on 3.8, we haven't > finalized any decisions yet). > > However, how are you dropping samples in software? Or are you dropping > them in hardware, in which case why are you not tagging the streams > correctly? > > M > > On 06/22/2016 12:10 AM, bob wole wrote: > > Thanks Martin, > > > > I know the packet size a priori but samples may drop due to overflows > > while flowgraph is running and could result in different packet size. Is > > there a way to solve this issue while using tagged_stream_block? > > > > -- > > Bob > > > > > > It'll crash. If you know your packet size a priori, you can tell the > > scheduler to only provide multiples of a 1000 samples. > > > > Cheers, > > M > > > > On 06/20/2016 07:17 AM, bob wole wrote: > > > Hi, > > > My flowgraph contains a tagged_stream_block, B, and it has a > > > length_tag_key, say "pkt_len". Each packet has a length of 1000 > > samples. > > > The upstream block (A-->B) tags first sample with key "pkt_len" and > > > value 1000 and then the upstream block tags sample number 901 with > key > > > "pkt_len" and value 1000 instead of tagging sample number 1001. > This > > > could happen in case of overflow and I know using receive tags > > that 100 > > > samples has been lost. So, samples from 901 to 1900 contains a new > > > packet. Will the flowgraph work or will it crash? > > > > > > I want to write a block that processes exactly only 1000 samples, > one > > > packet, in a call to work. And the packets start from a specific > time > > > for example when the rx_time of the sample is mid of any second. > > > > > > > > > -- > > > Bob > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about tagged_stream_block
Thanks Martin, I know the packet size a priori but samples may drop due to overflows while flowgraph is running and could result in different packet size. Is there a way to solve this issue while using tagged_stream_block? -- Bob > It'll crash. If you know your packet size a priori, you can tell the > scheduler to only provide multiples of a 1000 samples. > > Cheers, > M > > On 06/20/2016 07:17 AM, bob wole wrote: > > Hi, > > My flowgraph contains a tagged_stream_block, B, and it has a > > length_tag_key, say "pkt_len". Each packet has a length of 1000 samples. > > The upstream block (A-->B) tags first sample with key "pkt_len" and > > value 1000 and then the upstream block tags sample number 901 with key > > "pkt_len" and value 1000 instead of tagging sample number 1001. This > > could happen in case of overflow and I know using receive tags that 100 > > samples has been lost. So, samples from 901 to 1900 contains a new > > packet. Will the flowgraph work or will it crash? > > > > I want to write a block that processes exactly only 1000 samples, one > > packet, in a call to work. And the packets start from a specific time > > for example when the rx_time of the sample is mid of any second. > > > > > > -- > > Bob > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about tagged_stream_block
Hi, My flowgraph contains a tagged_stream_block, B, and it has a length_tag_key, say "pkt_len". Each packet has a length of 1000 samples. The upstream block (A-->B) tags first sample with key "pkt_len" and value 1000 and then the upstream block tags sample number 901 with key "pkt_len" and value 1000 instead of tagging sample number 1001. This could happen in case of overflow and I know using receive tags that 100 samples has been lost. So, samples from 901 to 1900 contains a new packet. Will the flowgraph work or will it crash? I want to write a block that processes exactly only 1000 samples, one packet, in a call to work. And the packets start from a specific time for example when the rx_time of the sample is mid of any second. -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] Switching and high spike in spectrum
Hi, Sorry for late reply. I was running out of time, so I used the offset tune future of UHD to handle that spike. See the following link, hope it helps, http://files.ettus.com/manual/structuhd_1_1tune__request__t.html -- Bob On Sat, Apr 2, 2016 at 7:41 AM, hanwen wrote: > Hi Bob, > > I came up with the same issue and I hope the DC leakage from Tx should > disappear right after the Tx burst is finished, but acturally I still saw > the strong DC during the pure Rx time lot. > Have you got a solution for that? Thanks. > > Br, Hanwen > > 2014-10-31 7:31 GMT+01:00 bob wole : > >> >> >> >> On 10/29/2014 01:54 PM, bob wole via USRP-users wrote: >>> > >>> > USRPN210r4 with SBX >>> > >>> > I am observing a strong spike at the center of the receive spectrum >>> > when I start burst transmission. >>> > >>> > My top flowgraph contains following two hierarchical blocks >>> > 1) A transmitter flow graph with (tx_time, tx_sob, tx_eob) >>> > 2) A receiver flow graph >>> > >>> > When I run top flowgrpah (without transmitting anything) and observe >>> > the FFT of the received signal the spectrum does not contain high >>> > spike in the center. >>> > >>> > But as soon as I start transmitting in burst mode I see a very high >>> > spike in center of the received signal FFT spectrum. It looks like LO >>> > (transmitter or receiver ) is being received? Which one is it ? And >>> > why is it happening? How can I avoid it because it is affecting my >>> > packets. >>> > >>> > When I apply the offset in digital using DDC/DUC, the spike moves out >>> > of the band. >>> > >>> > >>> > -- >>> > Bob >>> > >>> > >>> > ___ >>> > USRP-users mailing list >>> > usrp-us...@lists.ettus.com >>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> That spike in the middle is a consequence of using direct conversion in >>> both the RX and TX paths--it'll be there in both to some degree. >>> >>> You can use offset-tuning to move the DC offset outside your passband: >>> >>> http://files.ettus.com/manual/page_general.html >>> >>> >>> In built-for-a-particular-purpose radios, there will also be undesired >>> LO leakage and mixing products--those are generally dealt with using an >>>application/band-specific filter to eliminate them. For >>> general-purpose SDRs, that isn't possible to do "as manufactured", you >>> have to deal >>>with RF hygiene and plumbing issues yourself. >>> >>> So, moving the LO leakage outside your passband is part of the >>> picture--use offset tuning for that. Then, if you have "this won't meet >>>our hygiene requirements", you have to look at filtering. >>> >>> Another thing you really should do is to run the calibration utilities, >>> which will attempt to balance I/Q amplitude and phase, which can improve >>>some of these issues, but not, usually, eliminate them entirely. >>> >>> >>> >> Yes, I know that LO leakage/DC offset is an issue present in direct >> conversion receiver. But as I mentioned earlier, the received spectrum >> looks fine (a very little spike at DC around -70dB) while the burst >> transmission is not running. The spike becomes much more significant ( high >> spike at DC -20dB) when burst transmission (tx_time,tx_eob, tx_sob ) >> starts and all the spectrum just shifts up and down with it. I am using >> TX/RX antenna in both usrp source and usrp sink. I want to know why the >> burst transmission is affecting the received spectrum on the same node. >> >> >> ___ >> 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] gmsk+fec
Ekko, Add a Tag debug block after your packet encoder and see if there are any tags coming out of it. I think packet encoder is not passing your tag. If that is the case, move your stream to tagged stream block after the packet encoder just before the FEC extended tagged encoder. Hope it helps. -- Bob > > this is the address of picture > > http://imgur.com/2EQiY6O > > sorry to send two e-mails > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mailing list archive looks broken
> > > The ML archive here looks like it has stopped updating: > > http://lists.gnu.org/archive/html/discuss-gnuradio/2015-10/index.html > > Regards, > Andy > > > I am also unable to see recent threads. Only one email for this month. -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 155, Issue 4
> > The ML archive here looks like it has stopped updating: > > http://lists.gnu.org/archive/html/discuss-gnuradio/2015-10/index.html > > Regards, > Andy > > > I am also unable to see recent threads. Only one email for this month. -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about correlate_access_code_bb_impl
On Mon, Sep 21, 2015 at 7:38 PM, Tom Rondeau wrote:
> On Mon, Sep 21, 2015 at 6:40 AM, bob wole wrote:
>
>> I am studying the code of correlate_access_code_bb_impl.cc for
>> understanding its working. I see that the block is derive from "block"
>> class of gr as written in correlate_access_code_bb_ts.h file
>>
>>
>> class DIGITAL_API correlate_access_code_bb_ts : virtual public block
>>
>>
>> I read earlier that blocks derived from "block"/"gr::block" should
>> implement forecast() method, but I did not see any implementation of
>> forecast() in code of correlate_access_code_bb_impl.cc.
>>
>> Can somebody please tell me why ?
>>
>> --
>> Bob
>>
>
>
> First, you have a misunderstanding of the header/source relationship.
> There are a number of correlate* blocks in GNU Radio (and an unwritten plan
> to organize them better in the future). The correlate_access_code_bb is one
> block, and this is a gr::sync_block. The correlate_access_code_bb_ts is
> another block, and this one is a gr::block.
>
> If you look at the code for block.cc, you'll see it implements a forecast
> function already:
>
> void
> block::forecast(int noutput_items, gr_vector_int &ninput_items_required)
> {
> unsigned ninputs = ninput_items_required.size ();
> for(unsigned i = 0; i < ninputs; i++)
> ninput_items_required[i] = noutput_items + history() - 1;
> }
>
>
> That means that any block that derives from gr::block gets this behavior,
> which tells the scheduler that given noutput_items, the block needs this
> many input items to produce that output amount. This is a satisfactory
> condition for many blocks, so no, you don't /have/ to overload forecast in
> your derived block if this condition meets your block's behavior.
>
> Tom
>
>
Hi Tom,
Sorry, actually there were typos in my email. I was talking about the block
"correlate_access_code_bb_ts" all the time instead of
"correlate_access_code_bb". Thanks for clearing things and being helpful as
always.
--
Bob
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about correlate_access_code_bb_impl
I am studying the code of correlate_access_code_bb_impl.cc for understanding its working. I see that the block is derive from "block" class of gr as written in correlate_access_code_bb_ts.h file class DIGITAL_API correlate_access_code_bb_ts : virtual public block I read earlier that blocks derived from "block"/"gr::block" should implement forecast() method, but I did not see any implementation of forecast() in code of correlate_access_code_bb_impl.cc. Can somebody please tell me why ? -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Convolutional Code output does not match polynomial
I have opened an issue on the gnuradio.org. See the link below http://gnuradio.org/redmine/issues/841 -- Bob On Sat, Sep 12, 2015 at 1:36 PM, bob wole wrote: > Okay. I registered my self at gnuradio.org. Do I have to open a new Issue > on the website? > > -- > Bob > > > >> Jan, Bob, >> >> might be worth opening a ticket for this. >> >> M >> On 10.09.2015 00:22, bob wole wrote: >> > Hey Jan, >> > >> > Thanks for your reply, you are correct about the bit shift being LSB. >> > So, I reversed the bit order of polynomials 1101101 to 1011011 and >> > 100 to 001 in MATLAB, Now the output of gnuradio and MATLAB and >> > my dry run matches. I am wondering why they did implementation like >> > this? Any advantages? >> > >> > Yeah, I too was hoping for a reply from Tom and Nick on this. >> > >> > >> > -- >> > Bob >> > >> > >> > On Tue, Sep 8, 2015 at 12:37 PM, Jan Kr?mer > > <mailto:kraemer...@gmail.com>> wrote: >> > >> > Also I think Tom and Nick Foster for sure know more about it than I >> do. >> > >> > Cheers, >> > Jan >> > >> > 2015-09-08 8:44 GMT+02:00 Jan Kr?mer > > <mailto:kraemer...@gmail.com>>: >> > >> > Hey Bob, >> > >> > I have the same issues with my SSE Viterbi, works with >> > gr-trellis but not with cc_encoder in gr-fec. The output of the >> > cc_encoder is legit though. >> > I talked to a couple of guys about this at last year's GRCON. It >> > seems that in most implementations, the bit order of the >> > polynomials is reversed when compared to the textbook approach. >> > Therefor also the bit shifting in the encoding process (and the >> > viterbi chainback) is also reversed. I think textbook is MSB >> > while cc_encoder is LSB but I always mix them up xD. >> > But you can check >> > >> https://github.com/gnuradio/gnuradio/blob/master/gr-fec/lib/cc_encoder_impl.cc >> > beginning from line 166. >> > >> > Hope that helps, >> > Jan >> > >> > 2015-09-08 8:12 GMT+02:00 bob wole > > <mailto:bnw...@gmail.com>>: >> > >> > >> > >> > On Tue, Sep 1, 2015 at 2:55 PM, bob wole > > <mailto:bnw...@gmail.com>> wrote: >> > >> > I am trying channel coding in gnuradio. I am using >> > convolutional encoder with K=7 and R=1/2 with >> > polynomials [109, 79] (default). However I am not >> > getting the expected result. I input a known bit >> > sequence, single frame using head block, and observe the >> > output of the encoder using file sink. The output I >> > think is not correct according to the given polynomials. >> > Input bit stream is >> > >> > http://pastebin.com/thsYtLFG >> > >> > I am getting this output >> > >> > http://pastebin.com/P42QNjiE >> > >> > However, I am expecting (in hex) >> > >> > 0000E33263D74BFAD3 >> .. >> > >> > >> > I have attached the flowgraph I am using for this >> > purpose. I did a dry run by drawing a diagram of the >> > encoder and inputing initial two bytes. Diagram of the >> > encoder is also attached. I also used MATLAB script to >> > test and found that my dry run output matches with >> > MATLAB but not with Gnuradio output. I also played with >> > the endianness but could not get the desired result. >> > Maybe I am doing something wrong in configuring the >> encoder? >> > >> > >> > Also another thing I noticed is that in QA codes of >> > gr-fec I found >> > >> > import fec_swig as fec >> > import blocks_swig as blocks >> > >> > I think this should be >> > >> > from gnuradio import fec, blocks >> > >> > Am I right? I am using gnuradio 3.7.8. >> > >> > -- >> > Bob >> > >> > >> > >> > I am still waiting to get a reply on this. Anyone else >> > verified the output of the convolutional encoder? >> > >> > >> > -- >> > Bob >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Convolutional Code output does not match polynomial
Okay. I registered my self at gnuradio.org. Do I have to open a new Issue on the website? -- Bob > Jan, Bob, > > might be worth opening a ticket for this. > > M > On 10.09.2015 00:22, bob wole wrote: > > Hey Jan, > > > > Thanks for your reply, you are correct about the bit shift being LSB. > > So, I reversed the bit order of polynomials 1101101 to 1011011 and > > 100 to 001 in MATLAB, Now the output of gnuradio and MATLAB and > > my dry run matches. I am wondering why they did implementation like > > this? Any advantages? > > > > Yeah, I too was hoping for a reply from Tom and Nick on this. > > > > > > -- > > Bob > > > > > > On Tue, Sep 8, 2015 at 12:37 PM, Jan Kr?mer > <mailto:kraemer...@gmail.com>> wrote: > > > > Also I think Tom and Nick Foster for sure know more about it than I > do. > > > > Cheers, > > Jan > > > > 2015-09-08 8:44 GMT+02:00 Jan Kr?mer > <mailto:kraemer...@gmail.com>>: > > > > Hey Bob, > > > > I have the same issues with my SSE Viterbi, works with > > gr-trellis but not with cc_encoder in gr-fec. The output of the > > cc_encoder is legit though. > > I talked to a couple of guys about this at last year's GRCON. It > > seems that in most implementations, the bit order of the > > polynomials is reversed when compared to the textbook approach. > > Therefor also the bit shifting in the encoding process (and the > > viterbi chainback) is also reversed. I think textbook is MSB > > while cc_encoder is LSB but I always mix them up xD. > > But you can check > > > https://github.com/gnuradio/gnuradio/blob/master/gr-fec/lib/cc_encoder_impl.cc > > beginning from line 166. > > > > Hope that helps, > > Jan > > > > 2015-09-08 8:12 GMT+02:00 bob wole > <mailto:bnw...@gmail.com>>: > > > > > > > > On Tue, Sep 1, 2015 at 2:55 PM, bob wole > <mailto:bnw...@gmail.com>> wrote: > > > > I am trying channel coding in gnuradio. I am using > > convolutional encoder with K=7 and R=1/2 with > > polynomials [109, 79] (default). However I am not > > getting the expected result. I input a known bit > > sequence, single frame using head block, and observe the > > output of the encoder using file sink. The output I > > think is not correct according to the given polynomials. > > Input bit stream is > > > > http://pastebin.com/thsYtLFG > > > > I am getting this output > > > > http://pastebin.com/P42QNjiE > > > > However, I am expecting (in hex) > > > > 0000E33263D74BFAD3 .. > > > > > > I have attached the flowgraph I am using for this > > purpose. I did a dry run by drawing a diagram of the > > encoder and inputing initial two bytes. Diagram of the > > encoder is also attached. I also used MATLAB script to > > test and found that my dry run output matches with > > MATLAB but not with Gnuradio output. I also played with > > the endianness but could not get the desired result. > > Maybe I am doing something wrong in configuring the > encoder? > > > > > > Also another thing I noticed is that in QA codes of > > gr-fec I found > > > > import fec_swig as fec > > import blocks_swig as blocks > > > > I think this should be > > > > from gnuradio import fec, blocks > > > > Am I right? I am using gnuradio 3.7.8. > > > > -- > > Bob > > > > > > > > I am still waiting to get a reply on this. Anyone else > > verified the output of the convolutional encoder? > > > > > > -- > > Bob > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Convolutional Code output does not match polynomial
Hey Jan, Thanks for your reply, you are correct about the bit shift being LSB. So, I reversed the bit order of polynomials 1101101 to 1011011 and 100 to 001 in MATLAB, Now the output of gnuradio and MATLAB and my dry run matches. I am wondering why they did implementation like this? Any advantages? Yeah, I too was hoping for a reply from Tom and Nick on this. -- Bob On Tue, Sep 8, 2015 at 12:37 PM, Jan Krämer wrote: > Also I think Tom and Nick Foster for sure know more about it than I do. > > Cheers, > Jan > > 2015-09-08 8:44 GMT+02:00 Jan Krämer : > >> Hey Bob, >> >> I have the same issues with my SSE Viterbi, works with gr-trellis but not >> with cc_encoder in gr-fec. The output of the cc_encoder is legit though. >> I talked to a couple of guys about this at last year's GRCON. It seems >> that in most implementations, the bit order of the polynomials is reversed >> when compared to the textbook approach. >> Therefor also the bit shifting in the encoding process (and the viterbi >> chainback) is also reversed. I think textbook is MSB while cc_encoder is >> LSB but I always mix them up xD. >> But you can check >> https://github.com/gnuradio/gnuradio/blob/master/gr-fec/lib/cc_encoder_impl.cc >> beginning from line 166. >> >> Hope that helps, >> Jan >> >> 2015-09-08 8:12 GMT+02:00 bob wole : >> >>> >>> >>> On Tue, Sep 1, 2015 at 2:55 PM, bob wole wrote: >>> >>>> I am trying channel coding in gnuradio. I am using convolutional >>>> encoder with K=7 and R=1/2 with polynomials [109, 79] (default). However I >>>> am not getting the expected result. I input a known bit sequence, single >>>> frame using head block, and observe the output of the encoder using file >>>> sink. The output I think is not correct according to the given polynomials. >>>> Input bit stream is >>>> >>>> http://pastebin.com/thsYtLFG >>>> >>>> I am getting this output >>>> >>>> http://pastebin.com/P42QNjiE >>>> >>>> However, I am expecting (in hex) >>>> >>>> 0000E33263D74BFAD3 .. >>>> >>>> >>>> I have attached the flowgraph I am using for this purpose. I did a dry >>>> run by drawing a diagram of the encoder and inputing initial two bytes. >>>> Diagram of the encoder is also attached. I also used MATLAB script to test >>>> and found that my dry run output matches with MATLAB but not with Gnuradio >>>> output. I also played with the endianness but could not get the desired >>>> result. Maybe I am doing something wrong in configuring the encoder? >>>> >>>> >>>> Also another thing I noticed is that in QA codes of gr-fec I found >>>> >>>> import fec_swig as fec >>>> import blocks_swig as blocks >>>> >>>> I think this should be >>>> >>>> from gnuradio import fec, blocks >>>> >>>> Am I right? I am using gnuradio 3.7.8. >>>> >>>> -- >>>> Bob >>>> >>> >>> >>> I am still waiting to get a reply on this. Anyone else verified the >>> output of the convolutional encoder? >>> >>> >>> -- >>> Bob >>> >>> ___ >>> 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] Convolutional Code output does not match polynomial
On Tue, Sep 1, 2015 at 2:55 PM, bob wole wrote: > I am trying channel coding in gnuradio. I am using convolutional encoder > with K=7 and R=1/2 with polynomials [109, 79] (default). However I am not > getting the expected result. I input a known bit sequence, single frame > using head block, and observe the output of the encoder using file sink. > The output I think is not correct according to the given polynomials. Input > bit stream is > > http://pastebin.com/thsYtLFG > > I am getting this output > > http://pastebin.com/P42QNjiE > > However, I am expecting (in hex) > > 0000E33263D74BFAD3 .. > > > I have attached the flowgraph I am using for this purpose. I did a dry > run by drawing a diagram of the encoder and inputing initial two bytes. > Diagram of the encoder is also attached. I also used MATLAB script to test > and found that my dry run output matches with MATLAB but not with Gnuradio > output. I also played with the endianness but could not get the desired > result. Maybe I am doing something wrong in configuring the encoder? > > > Also another thing I noticed is that in QA codes of gr-fec I found > > import fec_swig as fec > import blocks_swig as blocks > > I think this should be > > from gnuradio import fec, blocks > > Am I right? I am using gnuradio 3.7.8. > > -- > Bob > I am still waiting to get a reply on this. Anyone else verified the output of the convolutional encoder? -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Better approach for FEC
> > > > I think many of the folks who would have comments on this are at the Gnu > > Radio conference this week > > > > > > > > On 08/26/2015 02:09 PM, bob wole wrote: > > > > > > > > On Tue, Aug 25, 2015 at 11:36 PM, bob wole wrote: > > > >> Hi, > >> > >> I have a burst system in gnuradio which is working fine with usrps. I > >> have used tags (tx_time, tx_eob and tx_sob) to define packet boundaries > and > >> transmission time. Tags are inserted by a block which is connected > before > >> the usrp sink. I did not use any "tagged stream block" in the burst > system. > >> All the blocks used are streaming blocks. > >> > >> Now I want to insert FEC in my system. After going through the FEC API, > I > >> realized that I can use any of FEC deployments (Streaming, Tagged > stream, > >> Asynchronus). Are there any difference(s) performance wise? Which one > >> should is better for my system? > >> > >> I have attached a picture of my current system and identified where I > >> want to insert FEC in tx and rx. > >> > >> Comments are appreciated. > >> > >> -- > >> Bob > >> > > > > Comments please ? > > > > -- > > Bob > > > > > > Bob, > > The various models of handling packets through a GNU Radio system are > dependent on a few things, none of which are easy black/white issues to > describe or offer support on. Partly, it can just be your opinion on where > the lines are between the different models; or based on what blocks are > available in the different models. You don't want to go back and forth, > though, so when you move from a stream into a PDU-based system, you'll want > to stay there. > > Performance is going to be dependent on the rest of your system as well. We > can't tell you one is better than the other, but we've put in a lot of > hooks into the system to help you understand those issues for yourself, > like using the performance counters and naming each thread with the block > name so top/htop can help. > > Tom > Hi Tom, Thanks for your detailed comment. You are always helpful. I'll learn about performance counters and will try to use them in the flowgrpahs. -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Convolutional Code output does not match polynomial
I am trying channel coding in gnuradio. I am using convolutional encoder with K=7 and R=1/2 with polynomials [109, 79] (default). However I am not getting the expected result. I input a known bit sequence, single frame using head block, and observe the output of the encoder using file sink. The output I think is not correct according to the given polynomials. Input bit stream is http://pastebin.com/thsYtLFG I am getting this output http://pastebin.com/P42QNjiE However, I am expecting (in hex) 0000E33263D74BFAD3 .. I have attached the flowgraph I am using for this purpose. I did a dry run by drawing a diagram of the encoder and inputing initial two bytes. Diagram of the encoder is also attached. I also used MATLAB script to test and found that my dry run output matches with MATLAB but not with Gnuradio output. I also played with the endianness but could not get the desired result. Maybe I am doing something wrong in configuring the encoder? Also another thing I noticed is that in QA codes of gr-fec I found import fec_swig as fec import blocks_swig as blocks I think this should be from gnuradio import fec, blocks Am I right? I am using gnuradio 3.7.8. -- Bob fecapi_tagged_decoders_mod.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Better approach for FEC
On Tue, Aug 25, 2015 at 11:36 PM, bob wole wrote: > Hi, > > I have a burst system in gnuradio which is working fine with usrps. I have > used tags (tx_time, tx_eob and tx_sob) to define packet boundaries and > transmission time. Tags are inserted by a block which is connected before > the usrp sink. I did not use any "tagged stream block" in the burst system. > All the blocks used are streaming blocks. > > Now I want to insert FEC in my system. After going through the FEC API, I > realized that I can use any of FEC deployments (Streaming, Tagged stream, > Asynchronus). Are there any difference(s) performance wise? Which one > should is better for my system? > > I have attached a picture of my current system and identified where I want > to insert FEC in tx and rx. > > Comments are appreciated. > > -- > Bob > Comments please ? -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Better approach for FEC
Hi, I have a burst system in gnuradio which is working fine with usrps. I have used tags (tx_time, tx_eob and tx_sob) to define packet boundaries and transmission time. Tags are inserted by a block which is connected before the usrp sink. I did not use any "tagged stream block" in the burst system. All the blocks used are streaming blocks. Now I want to insert FEC in my system. After going through the FEC API, I realized that I can use any of FEC deployments (Streaming, Tagged stream, Asynchronus). Are there any difference(s) performance wise? Which one should is better for my system? I have attached a picture of my current system and identified where I want to insert FEC in tx and rx. Comments are appreciated. -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] hier_blocks2 error
> > On 08/13/2015 08:38 AM, bob wole wrote: > > I am using gnruadio 3.7.8. I have a module (python) which is working > > well for version 3.6.3. In made necessary changes so that it can work > > with gnuradio 3.7.8. However I am getting following error > > > > File > > "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", > > line 92, in __getattr__ > > return getattr(self._impl, name) > > AttributeError: 'hier_block2_sptr' object has no attribute '_hb' > > > > > > I spent a lot of time to figure out this but could not resolve it, so > > I thought to get help from mailing list. > > > > Is this a bug or I am doing something wrong? > > What your seeing is the interface wrapper looking for an attribute in > the wrapped instance 'self._impl' which used to be called 'self._hb'. So > it tries to lookup that first - and fails. Since both _impl and _hb are > marked protected they should not be accessed from outside the wrapper > directly (I remember some WXGUI code did that, but that has been fixed). > In the gnuradio tree I can't seem to find anything like this. > > Can you check and see from where this Exception is raised from? > > Sebastian > The issue was in my python code that I derived from packet.py file. I was using this with 3.6.3 gr.io_signature(1, 1, packet_source._hb.output_signature().sizeof_stream_item(0)) # Output signature) I replaced it with gr.io_signature(1, 1, packet_source.output_signature().sizeof_stream_item(0)) # Output signature) GRC flowgraph is working fine. Thanks, Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] hier_blocks2 error
I am using gnruadio 3.7.8. I have a module (python) which is working well for version 3.6.3. In made necessary changes so that it can work with gnuradio 3.7.8. However I am getting following error File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py", line 92, in __getattr__ return getattr(self._impl, name) AttributeError: 'hier_block2_sptr' object has no attribute '_hb' I spent a lot of time to figure out this but could not resolve it, so I thought to get help from mailing list. Is this a bug or I am doing something wrong? -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ControlPort 3.7.8rc1
On Tue, Aug 11, 2015 at 11:54 AM, Johnathan Corgan wrote: > On Tue, Aug 11, 2015 at 4:24 AM, bob wole wrote: > > >> Anyone successful in applying that patch to thrift 0.9.2 ? Thoughts ? >> > > In the mastering of the live SDR image, I had to create a new patch that > was slightly different from the original one; I suspect the original one > was based on a different version of thrift than 0.9.2. > > In any case, you can try this one, it applies cleanly to the 0.9.2 tag in > the thrift repository: > > > https://github.com/gnuradio/gnuradio-livesdr/blob/livesdr/custom/gnuradio/thrift-shutdown-fix.diff > > > Johnathan Corgan > Corgan Labs - SDR Training and Development Services > Intro to SDR Class - Aug. 31-Sep. 1, Columbia, MD > Intro to SDR Class - Sep. 3-4, Santa Clara, CA > http://corganlabs.com > Thanks for sharing the patch. Applied it and patched successfully. -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ControlPort 3.7.8rc1
On Sat, Aug 8, 2015 at 11:20 AM, bob wole wrote: > > > On Fri, Aug 7, 2015 at 9:51 AM, bob wole wrote: > >> >> >> On Thu, Aug 6, 2015 at 6:36 PM, Tom Rondeau wrote: >> >>> On Thu, Aug 6, 2015 at 1:24 AM, bob wole wrote: >>> >>>> >>>> >>>> On Wed, Aug 5, 2015 at 6:46 PM, Tom Rondeau wrote: >>>> >>>>> On Wed, Aug 5, 2015 at 1:21 AM, bob wole wrote: >>>>> >>>>>> >>>>>> > There is a directory >>>>>>> > gnuradio-runtime/python/gnuradio/ctrlport >>>>>>> > >>>>>>> > >>>>>>> > where you in controlport related stuff. >>>>>>> > >>>>>>> > - - Volker >>>>>>> > >>>>>>> > >>>>>>> > Am 04.08.2015 um 10:09 schrieb Jeon: >>>>>>> > >>>>>>> > Dear Bob, >>>>>>> > >>>>>>> > A few months ago, I've asked a similar question ( >>>>>>> > < >>>>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html >>>>>>> > >>>>>>> > >>>>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html >>>>>>> ) >>>>>>> > >>>>>>> > and Tom gave me his paper in SIGCOMM. >>>>>>> > >>>>>>> > Inspecting GNU Radio Applications with ControlPort and Performance >>>>>>> Counters >>>>>>> > Thomas Rondeau, Tim O?Shea, and Nathan Goergen >>>>>>> > >>>>>>> > You can get one in >>>>>>> http://conferences.sigcomm.org/sigcomm/2013/srif.php >>>>>>> > >>>>>>> > It does not fully describe how it can be used, though, through >>>>>>> this you >>>>>>> > can get a hint. >>>>>>> > >>>>>>> > Regards, >>>>>>> > Jeon. >>>>>>> > >>>>>>> > 2015-08-04 16:36 GMT+09:00 bob wole : >>>>>>> > >>>>>>> >> Ubuntu 14.04 64-bit >>>>>>> >> >>>>>>> >> I just installed frest gnuradio 3.7.8rc1 with control port >>>>>>> enabled. I >>>>>>> >> fetched gnuradio using >>>>>>> >> >>>>>>> >> git clone --recursive https://github.com/gnuradio/gnuradio.git >>>>>>> >> >>>>>>> >> >>>>>>> >> Gnuradio enabled component shows >>>>>>> >> >>>>>>> >> * gr-ctrlport >>>>>>> >> * * thrift >>>>>>> >> >>>>>>> >> However, I do not see any *gr-ctrlport directory *inside the >>>>>>> gnuradio >>>>>>> >> directory. Where is the source code for control port? Also there >>>>>>> are no >>>>>>> >> examples for using control port. >>>>>>> >> >>>>>>> >> -- >>>>>>> >> Bob >>>>>>> >> >>>>>>> > >>>>>>> You can find more information on these two pages: >>>>>>> >>>>>>> http://jenkins.gnuradio.org/manual/doxygen/page_ctrlport.html >>>>>>> >>>>>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort >>>>>>> >>>>>>> >>>>>>> ControlPort was reintroduced just after the 3.7.7 release so we had >>>>>>> time to >>>>>>> test it, but it will be available in the upcoming 3.7.8 release. The >>>>>>> manual >>>>>>> page linked above is from our weekly development builds. >>>>>>> >>>>>>> This points you to two apps that are installed with ControlPort: >>>>>>> gr-perf-monitorx and gr-ctrlport-monitor. Other good places to look >>>>>>> for >>>>>>> usage is in our QA code. Look in gr-blocks >>>>>>> for qa_cpp_py_binding.py, qa_cpp_py_binding_set.py,
Re: [Discuss-gnuradio] ControlPort 3.7.8rc1
On Fri, Aug 7, 2015 at 9:51 AM, bob wole wrote: > > > On Thu, Aug 6, 2015 at 6:36 PM, Tom Rondeau wrote: > >> On Thu, Aug 6, 2015 at 1:24 AM, bob wole wrote: >> >>> >>> >>> On Wed, Aug 5, 2015 at 6:46 PM, Tom Rondeau wrote: >>> >>>> On Wed, Aug 5, 2015 at 1:21 AM, bob wole wrote: >>>> >>>>> >>>>> > There is a directory >>>>>> > gnuradio-runtime/python/gnuradio/ctrlport >>>>>> > >>>>>> > >>>>>> > where you in controlport related stuff. >>>>>> > >>>>>> > - - Volker >>>>>> > >>>>>> > >>>>>> > Am 04.08.2015 um 10:09 schrieb Jeon: >>>>>> > >>>>>> > Dear Bob, >>>>>> > >>>>>> > A few months ago, I've asked a similar question ( >>>>>> > < >>>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html >>>>>> > >>>>>> > >>>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html >>>>>> ) >>>>>> > >>>>>> > and Tom gave me his paper in SIGCOMM. >>>>>> > >>>>>> > Inspecting GNU Radio Applications with ControlPort and Performance >>>>>> Counters >>>>>> > Thomas Rondeau, Tim O?Shea, and Nathan Goergen >>>>>> > >>>>>> > You can get one in >>>>>> http://conferences.sigcomm.org/sigcomm/2013/srif.php >>>>>> > >>>>>> > It does not fully describe how it can be used, though, through this >>>>>> you >>>>>> > can get a hint. >>>>>> > >>>>>> > Regards, >>>>>> > Jeon. >>>>>> > >>>>>> > 2015-08-04 16:36 GMT+09:00 bob wole : >>>>>> > >>>>>> >> Ubuntu 14.04 64-bit >>>>>> >> >>>>>> >> I just installed frest gnuradio 3.7.8rc1 with control port >>>>>> enabled. I >>>>>> >> fetched gnuradio using >>>>>> >> >>>>>> >> git clone --recursive https://github.com/gnuradio/gnuradio.git >>>>>> >> >>>>>> >> >>>>>> >> Gnuradio enabled component shows >>>>>> >> >>>>>> >> * gr-ctrlport >>>>>> >> * * thrift >>>>>> >> >>>>>> >> However, I do not see any *gr-ctrlport directory *inside the >>>>>> gnuradio >>>>>> >> directory. Where is the source code for control port? Also there >>>>>> are no >>>>>> >> examples for using control port. >>>>>> >> >>>>>> >> -- >>>>>> >> Bob >>>>>> >> >>>>>> > >>>>>> You can find more information on these two pages: >>>>>> >>>>>> http://jenkins.gnuradio.org/manual/doxygen/page_ctrlport.html >>>>>> >>>>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort >>>>>> >>>>>> >>>>>> ControlPort was reintroduced just after the 3.7.7 release so we had >>>>>> time to >>>>>> test it, but it will be available in the upcoming 3.7.8 release. The >>>>>> manual >>>>>> page linked above is from our weekly development builds. >>>>>> >>>>>> This points you to two apps that are installed with ControlPort: >>>>>> gr-perf-monitorx and gr-ctrlport-monitor. Other good places to look >>>>>> for >>>>>> usage is in our QA code. Look in gr-blocks >>>>>> for qa_cpp_py_binding.py, qa_cpp_py_binding_set.py, >>>>>> and qa_ctrlport_probes.py. >>>>>> >>>>>> Tom >>>>>> >>>>>> >>>>>> >>>>> ControlPort is written in python ? >>>>> >>>>> When I ran qa_ctrlport_probes.py. I got a segmentation fault first >>>>> time. Then I ran the other two qa codes they passed successfully without >>>
Re: [Discuss-gnuradio] ControlPort 3.7.8rc1
On Thu, Aug 6, 2015 at 6:36 PM, Tom Rondeau wrote: > On Thu, Aug 6, 2015 at 1:24 AM, bob wole wrote: > >> >> >> On Wed, Aug 5, 2015 at 6:46 PM, Tom Rondeau wrote: >> >>> On Wed, Aug 5, 2015 at 1:21 AM, bob wole wrote: >>> >>>> >>>> > There is a directory >>>>> > gnuradio-runtime/python/gnuradio/ctrlport >>>>> > >>>>> > >>>>> > where you in controlport related stuff. >>>>> > >>>>> > - - Volker >>>>> > >>>>> > >>>>> > Am 04.08.2015 um 10:09 schrieb Jeon: >>>>> > >>>>> > Dear Bob, >>>>> > >>>>> > A few months ago, I've asked a similar question ( >>>>> > < >>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html >>>>> > >>>>> > >>>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html >>>>> ) >>>>> > >>>>> > and Tom gave me his paper in SIGCOMM. >>>>> > >>>>> > Inspecting GNU Radio Applications with ControlPort and Performance >>>>> Counters >>>>> > Thomas Rondeau, Tim O?Shea, and Nathan Goergen >>>>> > >>>>> > You can get one in >>>>> http://conferences.sigcomm.org/sigcomm/2013/srif.php >>>>> > >>>>> > It does not fully describe how it can be used, though, through this >>>>> you >>>>> > can get a hint. >>>>> > >>>>> > Regards, >>>>> > Jeon. >>>>> > >>>>> > 2015-08-04 16:36 GMT+09:00 bob wole : >>>>> > >>>>> >> Ubuntu 14.04 64-bit >>>>> >> >>>>> >> I just installed frest gnuradio 3.7.8rc1 with control port enabled. >>>>> I >>>>> >> fetched gnuradio using >>>>> >> >>>>> >> git clone --recursive https://github.com/gnuradio/gnuradio.git >>>>> >> >>>>> >> >>>>> >> Gnuradio enabled component shows >>>>> >> >>>>> >> * gr-ctrlport >>>>> >> * * thrift >>>>> >> >>>>> >> However, I do not see any *gr-ctrlport directory *inside the >>>>> gnuradio >>>>> >> directory. Where is the source code for control port? Also there >>>>> are no >>>>> >> examples for using control port. >>>>> >> >>>>> >> -- >>>>> >> Bob >>>>> >> >>>>> > >>>>> You can find more information on these two pages: >>>>> >>>>> http://jenkins.gnuradio.org/manual/doxygen/page_ctrlport.html >>>>> >>>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort >>>>> >>>>> >>>>> ControlPort was reintroduced just after the 3.7.7 release so we had >>>>> time to >>>>> test it, but it will be available in the upcoming 3.7.8 release. The >>>>> manual >>>>> page linked above is from our weekly development builds. >>>>> >>>>> This points you to two apps that are installed with ControlPort: >>>>> gr-perf-monitorx and gr-ctrlport-monitor. Other good places to look for >>>>> usage is in our QA code. Look in gr-blocks >>>>> for qa_cpp_py_binding.py, qa_cpp_py_binding_set.py, >>>>> and qa_ctrlport_probes.py. >>>>> >>>>> Tom >>>>> >>>>> >>>>> >>>> ControlPort is written in python ? >>>> >>>> When I ran qa_ctrlport_probes.py. I got a segmentation fault first >>>> time. Then I ran the other two qa codes they passed successfully without >>>> any core dump. When I ran qa_ctrlport_probes.py again it passed >>>> successfully. >>>> >>>> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py >>>> INFO: Apache Thrift: -h sdr-dev -p 57403 >>>> . >>>> -- >>>> Ran 5 tests in 0.509s >>>> >>>> OK >>>> *Segmentation fault (core dumped)* >>&
Re: [Discuss-gnuradio] gr-perf-monitorx Error
On Thu, Aug 6, 2015 at 6:36 PM, Tom Rondeau wrote: > On Thu, Aug 6, 2015 at 1:12 AM, bob wole wrote: > >> >> >> On Wed, Aug 5, 2015 at 6:44 PM, Tom Rondeau wrote: >> >>> On Wed, Aug 5, 2015 at 4:47 AM, bob wole wrote: >>> >>>> >>>> I am here again. I ran "fecapi_async_decoders.grc" with controlport >>>> performance moniter on. I made a new config.conf file in ~/.gnuradio and >>>> added following lines to it >>>> >>>> [ControlPort] >>>> on = True >>>> edges_list = True >>>> [PerfCounters] >>>> on = True >>>> export = True >>>> >>>> >>>> >>>> When I ran the flowgraph I got the following error >>>> Executing: >>>> "/home/sdr/gr_examples/gr_fec_def_ex/fecapi_async_decoders.py" >>>> >>>> Using Volk machine: avx_64_mmx_orc >>>> ControlPort Monitor running. >>>> INFO: Apache Thrift: -h sdr-dev -p 50883 >>>> monitor::endpoints() = -h sdr-dev -p 50883 >>>> running: ['gr-perf-monitorx', 'sdr-dev', '50883'] >>>> Traceback (most recent call last): >>>> File "/usr/local/bin/gr-perf-monitorx", line 902, in >>>> MyApp(sys.argv) >>>> File "/usr/local/bin/gr-perf-monitorx", line 897, in __init__ >>>> GNURadioControlPortClient(args, 'thrift', self.run, >>>> QtGui.QApplication(sys.argv).exec_) >>>> File >>>> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GNURadioControlPortClient.py", >>>> line 125, in __init__ >>>> callback(self.client) >>>> File "/usr/local/bin/gr-perf-monitorx", line 900, in run >>>> MAINWindow(client).show() >>>> File "/usr/local/bin/gr-perf-monitorx", line 70, in __init__ >>>> self.newCon(radioclient) >>>> File "/usr/local/bin/gr-perf-monitorx", line 84, in newCon >>>> child = MForm(self.radioclient, len(self.conns), self, dialogprompt >>>> = not csomeBool) >>>> File "/usr/local/bin/gr-perf-monitorx", line 776, in __init__ >>>> self.pos = nx.graphviz_layout(self.G); >>>> File >>>> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py", >>>> line 257, in graphviz_layout >>>> return pydot_layout(G=G,prog=prog,root=root,**kwds) >>>> File >>>> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py", >>>> line 271, in pydot_layout >>>> pydot = load_pydot() >>>> File >>>> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py", >>>> line 47, in load_pydot >>>> raise ImportError(msg) >>>> ImportError: pydot could not be loaded: http://code.google.com/p/pydot/ >>>> >>>> I have gnruadio 3.7.8rc1 with networkx1.10 and matplotlib. Also I am on >>>> ubuntu 14.04. >>>> >>>> >>>> -- >>>> Bob >>>> >>> >>> Did you try to install pydot? >>> >>> sudo apt-get install python-pydot >>> >>> Tom >>> >>> >> >> Hi, >> >> Thanks, after installing pydot, the flowgraph is working fine. A warning >> though, but I think that can be ignored? >> >> WARN: asynchronous message buffer overflowing, dropping message >> > > Right, that's just a warning. > > >> There is one thing more. I clicked somewhere in the graph view of >> performance monitor and following error came, I tried to replicate it but I >> was not successful. >> >> Traceback (most recent call last): >> File "/usr/lib/pymodules/python2.7/matplotlib/backends/backend_qt4.py", >> line 299, in resizeEvent >> self.draw() >> File >> "/usr/lib/pymodules/python2.7/matplotlib/backends/backend_qt4agg.py", line >> 155, in draw >> self.update() >> RuntimeError: wrapped C/C++ object of type FigureCanvasQTAgg has been >> deleted >> ctrlport.monitor received shutdown signal >> calling stop on shutdown >> calling stop on shutdown >> pure virtual method called >> terminate called without an active exception >> >> -- >> Bob >> > > I've worked on this problem, but it only affected me on the Runtime or > Buffer graphs, not the main canvas. I think something changed in the > plotting tools since we last had this running. But I can no longer > replicate the problem, so hopefully it's rare and we can nail down the > problem later. > > Tom > > > Right, I too couldn't replicate it. Thanks -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FEC GnuRadio 3.7.8rc1 Error
On Thu, Aug 6, 2015 at 12:44 AM, Tom Rondeau wrote: > On Wed, Aug 5, 2015 at 2:07 AM, bob wole wrote: > >> Ubuntu 14.04 64-bit >> Gnuradio 3.7.8rc1 >> >> >> I am running this flowgraph "fecapi_async_to_stream.grc" that comes with >> gr-fec. After running for a while following error always show up >> >> >> >> DEBUG: 16384, 560, 272 >> DEBUG: 16384, 560, 272 >> FATAL: Missing a required length tag on port 0 at item #14965440 >> thread[thread-per-block[7]: ]: Missing >> length tag. >> >> The only thing that changes is the item#. >> Testing further >> >> >> -- >> Bob >> > > Bob, > > You led us down a buggy path on that one. This, I'm pretty sure, is > related to Richard Bell's problem for a few weeks ago where adding a time > sink caused problems in his data stream. I have to say, I kind of dismissed > that as impossible, but nope, it's a real problem. > > The problem isn't with the GUI sinks; you can replace them with null sinks > and you get the same problem. It's a race condition in our tag pruning > method that was changed in 3.7.6. We have a patch that we're putting in now > that will be part of 3.7.8. > > The patch goes backwards a bit to how tag pruning was originally done. > However, with the map, we no longer have to restart the iterator at begin() > like we used to, and we can terminate early, so this should still be much > faster than the original. > > Tom > > > Tom, Thanks for the update. Which block exactly is causing this? Should I wait for version 3.7.8 then? -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ControlPort 3.7.8rc1
On Wed, Aug 5, 2015 at 6:46 PM, Tom Rondeau wrote: > On Wed, Aug 5, 2015 at 1:21 AM, bob wole wrote: > >> >> > There is a directory >>> > gnuradio-runtime/python/gnuradio/ctrlport >>> > >>> > >>> > where you in controlport related stuff. >>> > >>> > - - Volker >>> > >>> > >>> > Am 04.08.2015 um 10:09 schrieb Jeon: >>> > >>> > Dear Bob, >>> > >>> > A few months ago, I've asked a similar question ( >>> > < >>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html >>> > >>> > >>> http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html >>> ) >>> > >>> > and Tom gave me his paper in SIGCOMM. >>> > >>> > Inspecting GNU Radio Applications with ControlPort and Performance >>> Counters >>> > Thomas Rondeau, Tim O?Shea, and Nathan Goergen >>> > >>> > You can get one in >>> http://conferences.sigcomm.org/sigcomm/2013/srif.php >>> > >>> > It does not fully describe how it can be used, though, through this you >>> > can get a hint. >>> > >>> > Regards, >>> > Jeon. >>> > >>> > 2015-08-04 16:36 GMT+09:00 bob wole : >>> > >>> >> Ubuntu 14.04 64-bit >>> >> >>> >> I just installed frest gnuradio 3.7.8rc1 with control port enabled. I >>> >> fetched gnuradio using >>> >> >>> >> git clone --recursive https://github.com/gnuradio/gnuradio.git >>> >> >>> >> >>> >> Gnuradio enabled component shows >>> >> >>> >> * gr-ctrlport >>> >> * * thrift >>> >> >>> >> However, I do not see any *gr-ctrlport directory *inside the gnuradio >>> >> directory. Where is the source code for control port? Also there are >>> no >>> >> examples for using control port. >>> >> >>> >> -- >>> >> Bob >>> >> >>> > >>> You can find more information on these two pages: >>> >>> http://jenkins.gnuradio.org/manual/doxygen/page_ctrlport.html >>> >>> http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort >>> >>> >>> ControlPort was reintroduced just after the 3.7.7 release so we had time >>> to >>> test it, but it will be available in the upcoming 3.7.8 release. The >>> manual >>> page linked above is from our weekly development builds. >>> >>> This points you to two apps that are installed with ControlPort: >>> gr-perf-monitorx and gr-ctrlport-monitor. Other good places to look for >>> usage is in our QA code. Look in gr-blocks >>> for qa_cpp_py_binding.py, qa_cpp_py_binding_set.py, >>> and qa_ctrlport_probes.py. >>> >>> Tom >>> >>> >>> >> ControlPort is written in python ? >> >> When I ran qa_ctrlport_probes.py. I got a segmentation fault first time. >> Then I ran the other two qa codes they passed successfully without any core >> dump. When I ran qa_ctrlport_probes.py again it passed successfully. >> >> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py >> INFO: Apache Thrift: -h sdr-dev -p 57403 >> . >> -- >> Ran 5 tests in 0.509s >> >> OK >> *Segmentation fault (core dumped)* >> >> sdr@sdr-dev:~/gr_examples$ ./qa_cpp_py_binding.py >> INFO: Apache Thrift: -h sdr-dev -p 35595 >> .. >> -- >> Ran 2 tests in 0.105s >> >> OK >> >> sdr@sdr-dev:~/gr_examples$ ./qa_cpp_py_binding_set.py >> INFO: Apache Thrift: -h sdr-dev -p 38301 >> .. >> -- >> Ran 2 tests in 0.134s >> >> OK >> >> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py >> INFO: Apache Thrift: -h sdr-dev -p 38644 >> . >> -- >> Ran 5 tests in 0.511s >> >> OK >> sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py >> INFO: Apache Thrift: -h sdr-dev -p 48394 >> . >> -- >> Ran 5 tests in 0.510s >> >> OK >> >> >> What could be the cause? I thought I should share because it is a new >> release and is in testing stage. >> >> >> -- >> Bob >> > > There is a bug in Thrift 0.9.2 that I'm going to guess is the cause of > that seg fault. See our notes on building Thrift and the patch that we have > for it: > > http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort > > I believe that patch has been accepted, but after the 0.9.2 release. > > Tom > > I am going to apply the patch to thrift. Should I remove and reinstall gnruadio too after applying patch. -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-perf-monitorx Error
On Wed, Aug 5, 2015 at 6:44 PM, Tom Rondeau wrote: > On Wed, Aug 5, 2015 at 4:47 AM, bob wole wrote: > >> >> I am here again. I ran "fecapi_async_decoders.grc" with controlport >> performance moniter on. I made a new config.conf file in ~/.gnuradio and >> added following lines to it >> >> [ControlPort] >> on = True >> edges_list = True >> [PerfCounters] >> on = True >> export = True >> >> >> >> When I ran the flowgraph I got the following error >> >> Executing: "/home/sdr/gr_examples/gr_fec_def_ex/fecapi_async_decoders.py" >> >> Using Volk machine: avx_64_mmx_orc >> ControlPort Monitor running. >> INFO: Apache Thrift: -h sdr-dev -p 50883 >> monitor::endpoints() = -h sdr-dev -p 50883 >> running: ['gr-perf-monitorx', 'sdr-dev', '50883'] >> Traceback (most recent call last): >> File "/usr/local/bin/gr-perf-monitorx", line 902, in >> MyApp(sys.argv) >> File "/usr/local/bin/gr-perf-monitorx", line 897, in __init__ >> GNURadioControlPortClient(args, 'thrift', self.run, >> QtGui.QApplication(sys.argv).exec_) >> File >> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GNURadioControlPortClient.py", >> line 125, in __init__ >> callback(self.client) >> File "/usr/local/bin/gr-perf-monitorx", line 900, in run >> MAINWindow(client).show() >> File "/usr/local/bin/gr-perf-monitorx", line 70, in __init__ >> self.newCon(radioclient) >> File "/usr/local/bin/gr-perf-monitorx", line 84, in newCon >> child = MForm(self.radioclient, len(self.conns), self, dialogprompt = >> not csomeBool) >> File "/usr/local/bin/gr-perf-monitorx", line 776, in __init__ >> self.pos = nx.graphviz_layout(self.G); >> File >> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py", >> line 257, in graphviz_layout >> return pydot_layout(G=G,prog=prog,root=root,**kwds) >> File >> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py", >> line 271, in pydot_layout >> pydot = load_pydot() >> File >> "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py", >> line 47, in load_pydot >> raise ImportError(msg) >> ImportError: pydot could not be loaded: http://code.google.com/p/pydot/ >> >> I have gnruadio 3.7.8rc1 with networkx1.10 and matplotlib. Also I am on >> ubuntu 14.04. >> >> >> -- >> Bob >> > > Did you try to install pydot? > > sudo apt-get install python-pydot > > Tom > > Hi, Thanks, after installing pydot, the flowgraph is working fine. A warning though, but I think that can be ignored? WARN: asynchronous message buffer overflowing, dropping message There is one thing more. I clicked somewhere in the graph view of performance monitor and following error came, I tried to replicate it but I was not successful. Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/matplotlib/backends/backend_qt4.py", line 299, in resizeEvent self.draw() File "/usr/lib/pymodules/python2.7/matplotlib/backends/backend_qt4agg.py", line 155, in draw self.update() RuntimeError: wrapped C/C++ object of type FigureCanvasQTAgg has been deleted ctrlport.monitor received shutdown signal calling stop on shutdown calling stop on shutdown pure virtual method called terminate called without an active exception -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-perf-monitorx Error
I am here again. I ran "fecapi_async_decoders.grc" with controlport performance moniter on. I made a new config.conf file in ~/.gnuradio and added following lines to it [ControlPort] on = True edges_list = True [PerfCounters] on = True export = True When I ran the flowgraph I got the following error Executing: "/home/sdr/gr_examples/gr_fec_def_ex/fecapi_async_decoders.py" Using Volk machine: avx_64_mmx_orc ControlPort Monitor running. INFO: Apache Thrift: -h sdr-dev -p 50883 monitor::endpoints() = -h sdr-dev -p 50883 running: ['gr-perf-monitorx', 'sdr-dev', '50883'] Traceback (most recent call last): File "/usr/local/bin/gr-perf-monitorx", line 902, in MyApp(sys.argv) File "/usr/local/bin/gr-perf-monitorx", line 897, in __init__ GNURadioControlPortClient(args, 'thrift', self.run, QtGui.QApplication(sys.argv).exec_) File "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GNURadioControlPortClient.py", line 125, in __init__ callback(self.client) File "/usr/local/bin/gr-perf-monitorx", line 900, in run MAINWindow(client).show() File "/usr/local/bin/gr-perf-monitorx", line 70, in __init__ self.newCon(radioclient) File "/usr/local/bin/gr-perf-monitorx", line 84, in newCon child = MForm(self.radioclient, len(self.conns), self, dialogprompt = not csomeBool) File "/usr/local/bin/gr-perf-monitorx", line 776, in __init__ self.pos = nx.graphviz_layout(self.G); File "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py", line 257, in graphviz_layout return pydot_layout(G=G,prog=prog,root=root,**kwds) File "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py", line 271, in pydot_layout pydot = load_pydot() File "/usr/local/lib/python2.7/dist-packages/networkx-1.10-py2.7.egg/networkx/drawing/nx_pydot.py", line 47, in load_pydot raise ImportError(msg) ImportError: pydot could not be loaded: http://code.google.com/p/pydot/ I have gnruadio 3.7.8rc1 with networkx1.10 and matplotlib. Also I am on ubuntu 14.04. -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FEC GnuRadio 3.7.8rc1 Error
Ubuntu 14.04 64-bit Gnuradio 3.7.8rc1 I am running this flowgraph "fecapi_async_to_stream.grc" that comes with gr-fec. After running for a while following error always show up DEBUG: 16384, 560, 272 DEBUG: 16384, 560, 272 FATAL: Missing a required length tag on port 0 at item #14965440 thread[thread-per-block[7]: ]: Missing length tag. The only thing that changes is the item#. Testing further .... -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ControlPort 3.7.8rc1
> > There is a directory > > gnuradio-runtime/python/gnuradio/ctrlport > > > > > > where you in controlport related stuff. > > > > - - Volker > > > > > > Am 04.08.2015 um 10:09 schrieb Jeon: > > > > Dear Bob, > > > > A few months ago, I've asked a similar question ( > > < > http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html> > > http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00197.html > ) > > > > and Tom gave me his paper in SIGCOMM. > > > > Inspecting GNU Radio Applications with ControlPort and Performance > Counters > > Thomas Rondeau, Tim O?Shea, and Nathan Goergen > > > > You can get one in http://conferences.sigcomm.org/sigcomm/2013/srif.php > > > > It does not fully describe how it can be used, though, through this you > > can get a hint. > > > > Regards, > > Jeon. > > > > 2015-08-04 16:36 GMT+09:00 bob wole : > > > >> Ubuntu 14.04 64-bit > >> > >> I just installed frest gnuradio 3.7.8rc1 with control port enabled. I > >> fetched gnuradio using > >> > >> git clone --recursive https://github.com/gnuradio/gnuradio.git > >> > >> > >> Gnuradio enabled component shows > >> > >> * gr-ctrlport > >> * * thrift > >> > >> However, I do not see any *gr-ctrlport directory *inside the gnuradio > >> directory. Where is the source code for control port? Also there are no > >> examples for using control port. > >> > >> -- > >> Bob > >> > > > You can find more information on these two pages: > > http://jenkins.gnuradio.org/manual/doxygen/page_ctrlport.html > > http://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort > > > ControlPort was reintroduced just after the 3.7.7 release so we had time to > test it, but it will be available in the upcoming 3.7.8 release. The manual > page linked above is from our weekly development builds. > > This points you to two apps that are installed with ControlPort: > gr-perf-monitorx and gr-ctrlport-monitor. Other good places to look for > usage is in our QA code. Look in gr-blocks > for qa_cpp_py_binding.py, qa_cpp_py_binding_set.py, > and qa_ctrlport_probes.py. > > Tom > > > ControlPort is written in python ? When I ran qa_ctrlport_probes.py. I got a segmentation fault first time. Then I ran the other two qa codes they passed successfully without any core dump. When I ran qa_ctrlport_probes.py again it passed successfully. sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py INFO: Apache Thrift: -h sdr-dev -p 57403 . -- Ran 5 tests in 0.509s OK *Segmentation fault (core dumped)* sdr@sdr-dev:~/gr_examples$ ./qa_cpp_py_binding.py INFO: Apache Thrift: -h sdr-dev -p 35595 .. -- Ran 2 tests in 0.105s OK sdr@sdr-dev:~/gr_examples$ ./qa_cpp_py_binding_set.py INFO: Apache Thrift: -h sdr-dev -p 38301 .. -- Ran 2 tests in 0.134s OK sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py INFO: Apache Thrift: -h sdr-dev -p 38644 . -- Ran 5 tests in 0.511s OK sdr@sdr-dev:~/gr_examples$ ./qa_ctrlport_probes.py INFO: Apache Thrift: -h sdr-dev -p 48394 . -- Ran 5 tests in 0.510s OK What could be the cause? I thought I should share because it is a new release and is in testing stage. -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ControlPort 3.7.8rc1
Ubuntu 14.04 64-bit I just installed frest gnuradio 3.7.8rc1 with control port enabled. I fetched gnuradio using git clone --recursive https://github.com/gnuradio/gnuradio.git Gnuradio enabled component shows * gr-ctrlport * * thrift However, I do not see any *gr-ctrlport directory *inside the gnuradio directory. Where is the source code for control port? Also there are no examples for using control port. -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Memory issues
Marcus, Certainly a type. Since Maricus did not mention any hardware sink I was just reminding him to add a throttle block if it is not there :) -- Bob On Thu, Jul 30, 2015 at 11:13 AM, Marcus Müller wrote: > Hi Bob, > > Sorry I have to contradict here: when working with hardware, you should > generally *never* use a throttle block. Maybe that was just a typo in your > mail? > > The reason is that the throttle blocks sole job is to call sleep functions > for long enough to press the average rate of samples going through the > throttle block is the set rate. Now, in a world where latency doesn't count > and all clocks are identical, that's not a problem. However, in practice, > this means that throttle might block for a relatively long time, when the > numbers of samples it got in one work iteration are large. In the meantime, > the downstream hardware might have run dry on samples, even if the throttle > rate is higher than the sink's sampling rate! > > Also, with rates produced by your computer's clock and the oscillator of a > hardware sink, one has to be a little faster than the other, which leads to > under or overflow problems sooner or later. > > However, in the pure simulation case, I agree, you should add a throttle > and see whether it helps. > > Best regards, > Marcus > > Am 30. Juli 2015 07:10:13 MESZ, schrieb bob wole : > >> Maricus, >> >> Does your flowgraph involves aany hardware sink e.g USRP, audio ? If try >> adding a throttle if you are not already doing it. >> >> -- >> Bob >> >> >> >>> Hi Marius, >>> >>> good question! >>> Now, typically, you'd use tools like valgrind to figure that out. I >>> haven't noticed a memory leak in GNU Radio itself, but it's absolutely >>> possible that something like PMTs do not get freed etc, and we didn't >>> notice how this could happen. >>> If you need additional things to look for: >>> * do you have something like a vector that stores e.g. messages that >>> come in? >>> * what's the failure mode of your application? Is it killed by the >>> Out-of-Memory killer, or do you get into a situation where it crashes >>> because of e.g. stack overflow? >>> >>> Best regards, >>> Marcus >>> >>> On 29.07.2015 15:57, Marius Cachelin wrote: >>> > Hi all, >>> > >>> > I am writing because I have some misunderstood concerning how memory >>> > is used in GNURadio. >>> > >>> > I developed a transmitter which can be split into 5 parts : >>> >- MAC Encoder : read PDU data from TUNTAP >>> >- HEADER Prefixer : add header before each PDU Data >>> >- PREAMBLE prefixer : add preamble before each PDU Data >>> >- MODULATOR : Performing BPSK/QPSK >>> >- FIR Interp : Pulse shape >>> > >>> > My question is : when I run my transmitter, I can see in HTOP that the >>> > memory (%MEM) used by my transmitter increase. The increasing is >>> > relatively slow, but the is an issue because I can't keep using my >>> > transmitter after a while. >>> > >>> > I have checked all my blocks. All memory allocations are freed, and >>> > all my objetcs (new...) are deleted. >>> > >>> > So, how the memory can increase if I do not allocate extra memory and >>> > free all memory? >>> > >>> > Thanks you in advance. >>> > >>> > -- >>> > *CACHELIN Marius* >>> > /Ing?nieur Syst?mes, R?seaux et T?l?communications/ >>> > marius.cache...@gmail.com <mailto:marius.cache...@gmail.com >>> >> -- >> >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Memory issues
Maricus, Does your flowgraph involves aany hardware sink e.g USRP, audio ? If try adding a throttle if you are not already doing it. -- Bob > Hi Marius, > > good question! > Now, typically, you'd use tools like valgrind to figure that out. I > haven't noticed a memory leak in GNU Radio itself, but it's absolutely > possible that something like PMTs do not get freed etc, and we didn't > notice how this could happen. > If you need additional things to look for: > * do you have something like a vector that stores e.g. messages that > come in? > * what's the failure mode of your application? Is it killed by the > Out-of-Memory killer, or do you get into a situation where it crashes > because of e.g. stack overflow? > > Best regards, > Marcus > > On 29.07.2015 15:57, Marius Cachelin wrote: > > Hi all, > > > > I am writing because I have some misunderstood concerning how memory > > is used in GNURadio. > > > > I developed a transmitter which can be split into 5 parts : > >- MAC Encoder : read PDU data from TUNTAP > >- HEADER Prefixer : add header before each PDU Data > >- PREAMBLE prefixer : add preamble before each PDU Data > >- MODULATOR : Performing BPSK/QPSK > >- FIR Interp : Pulse shape > > > > My question is : when I run my transmitter, I can see in HTOP that the > > memory (%MEM) used by my transmitter increase. The increasing is > > relatively slow, but the is an issue because I can't keep using my > > transmitter after a while. > > > > I have checked all my blocks. All memory allocations are freed, and > > all my objetcs (new...) are deleted. > > > > So, how the memory can increase if I do not allocate extra memory and > > free all memory? > > > > Thanks you in advance. > > > > -- > > *CACHELIN Marius* > > /Ing?nieur Syst?mes, R?seaux et T?l?communications/ > > marius.cache...@gmail.com <mailto:marius.cache...@gmail.com > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Errors in FEC gnruadio
On Sat, Jul 4, 2015 at 8:35 PM, bob wole wrote: > Hi list, > > I was not getting reply on the previous thread so I though to start a new > thread. > > 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 > > Hi, Can I get any reply/feedback on this please??? -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Errors in FEC gnruadio
Hi list, I was not getting reply on the previous thread so I though to start a new thread. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FEC in gnruadio
On Thu, Jul 2, 2015 at 8:10 PM, bob wole wrote: > > > On Tue, Jun 30, 2015 at 2:00 PM, bob wole wrote: > >> >> >> 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, >>>>
Re: [Discuss-gnuradio] FEC in gnruadio
On Tue, Jun 30, 2015 at 2:00 PM, bob wole wrote: > > > 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, > > gnura
Re: [Discuss-gnuradio] FEC in gnruadio
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
Re: [Discuss-gnuradio] FEC in gnruadio
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FEC in gnruadio
> > 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FEC in gnruadio
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Python block help
Hi list, I am writing a custom python block that should take complex input, check magnitude of incoming samples and if the magnitude is greater than a threshold value, the block should pass that sample otherwise the block just drop the samples. As this is an arbitrary ratio block I derived it from gr.block and set_auto_consume(False). However I get intermittent zeros in output stream of my custom block. Below is the code from gnuradio import gr import gnuradio.extras import math import numpy as np class sdr_pass_valid(gr.block): """ """ def __init__(self,threshold): gr.block.__init__( self, name = "VALID", in_sig = [np.complex64], out_sig = [np.complex64], ) self.set_auto_consume(False) self.threshold = threshold def forecast (self,noutput_items,ninput_items_required): for i in range(len(ninput_items_required)): ninput_items_required[i] = noutput_items def work(self, input_items, output_items): in0 = input_items[0][:len(output_items[0])] out0= output_items[0] nread = self.nitems_read(0) #number of items read on port 0 ninput_items = len(in0) j=0 for i in range(0,ninput_items): if np.absolute(in0[i]) >= self.threshold : out0[j] = in0[i] j = j + 1 self.consume(0,ninput_items) self.produce(0,len(out0)) return 0 -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] Switching and high spike in spectrum
On 10/29/2014 01:54 PM, bob wole via USRP-users wrote: > > > > USRPN210r4 with SBX > > > > I am observing a strong spike at the center of the receive spectrum > > when I start burst transmission. > > > > My top flowgraph contains following two hierarchical blocks > > 1) A transmitter flow graph with (tx_time, tx_sob, tx_eob) > > 2) A receiver flow graph > > > > When I run top flowgrpah (without transmitting anything) and observe > > the FFT of the received signal the spectrum does not contain high > > spike in the center. > > > > But as soon as I start transmitting in burst mode I see a very high > > spike in center of the received signal FFT spectrum. It looks like LO > > (transmitter or receiver ) is being received? Which one is it ? And > > why is it happening? How can I avoid it because it is affecting my > > packets. > > > > When I apply the offset in digital using DDC/DUC, the spike moves out > > of the band. > > > > > > -- > > Bob > > > > > > ___ > > USRP-users mailing list > > usrp-us...@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > That spike in the middle is a consequence of using direct conversion in > both the RX and TX paths--it'll be there in both to some degree. > > You can use offset-tuning to move the DC offset outside your passband: > > http://files.ettus.com/manual/page_general.html > > > In built-for-a-particular-purpose radios, there will also be undesired > LO leakage and mixing products--those are generally dealt with using an >application/band-specific filter to eliminate them. For > general-purpose SDRs, that isn't possible to do "as manufactured", you > have to deal >with RF hygiene and plumbing issues yourself. > > So, moving the LO leakage outside your passband is part of the > picture--use offset tuning for that. Then, if you have "this won't meet >our hygiene requirements", you have to look at filtering. > > Another thing you really should do is to run the calibration utilities, > which will attempt to balance I/Q amplitude and phase, which can improve >some of these issues, but not, usually, eliminate them entirely. > > > Yes, I know that LO leakage/DC offset is an issue present in direct conversion receiver. But as I mentioned earlier, the received spectrum looks fine (a very little spike at DC around -70dB) while the burst transmission is not running. The spike becomes much more significant ( high spike at DC -20dB) when burst transmission (tx_time,tx_eob, tx_sob ) starts and all the spectrum just shifts up and down with it. I am using TX/RX antenna in both usrp source and usrp sink. I want to know why the burst transmission is affecting the received spectrum on the same node. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Switching and high spike in spectrum
USRPN210r4 with SBX I am observing a strong spike at the center of the receive spectrum when I start burst transmission. My top flowgraph contains following two hierarchical blocks 1) A transmitter flow graph with (tx_time, tx_sob, tx_eob) 2) A receiver flow graph When I run top flowgrpah (without transmitting anything) and observe the FFT of the received signal the spectrum does not contain high spike in the center. But as soon as I start transmitting in burst mode I see a very high spike in center of the received signal FFT spectrum. It looks like LO (transmitter or receiver ) is being received? Which one is it ? And why is it happening? How can I avoid it because it is affecting my packets. When I apply the offset in digital using DDC/DUC, the spike moves out of the band. -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bypass work function
Well, in my case the tx/rx would not be stationary, so the channel is not quite. -- Bob > If you can tolerate the stream stopping, use Power Squelch. Otherwise, > time to dive in and follow Tom's advice from May - disable the CMA taps > update loop when there's no signal. This whole idea assumes you have a > mostly quiet channel, stationary tx/rx, etc. Interested to hear what you > come up with. > > - Jeff > > On 10/01/2014 11:24 PM, bob wole wrote: > > I applied this and this is useful in condition when you do not want to > > process noise, because it is being multiplied by zero when there is no > > signal. But I want that CMA taps remain unchanged when there is no > > signal or just noise. In the above scenario CMA taps change due to > > presence of noise, because it tries to equalize noise as well. Thanks > > for your comment. > > > > -- > > Bob > > > > On Mon, Sep 29, 2014 at 7:19 PM, Jeff Long > <mailto:willco...@gmail.com>> wrote: > > > > Try using a "threshold" off the "mag squared" and feed that into a > > multiplier after block2 (with appropriate type adapters). As long as > > block2 doesn't have a huge delay or do rate changes, this should > work. > > > > - Jeff > > > > On 09/29/2014 10:23 AM, bob wole wrote: > > > Hi thanks for your comment. block2 is the gnuradio "CMA equalizer > > > block". I want the CMA block to remain quiet when there is no > signal of > > > interest. > > > > > > Bob > > > > > > > > > Bob, > > > > > > Saw this the other day, but there isn't a lot to go on here. > If block2 > > > is your own, you can make it do the bypass. You can also use > some of the > > > logic blocks and a multiplier depending on what you're doing. > There > > > isn't really a concept of on-the-fly switching in GNU Radio. > > > > > > - Jeff > > > > > > On 09/26/2014 01:02 PM, bob wole wrote: > > > > > > > > People, any ideas on it? > > > > > > > > -- > > > > Bob > > > > > > > > On Wed, Sep 24, 2014 at 12:04 PM, bob wole < > bnw...@gmail.com <mailto:bnw...@gmail.com> > > > <mailto:bnw...@gmail.com <mailto:bnw...@gmail.com>> > > > > <mailto:bnw...@gmail.com <mailto:bnw...@gmail.com> > > <mailto:bnw...@gmail.com <mailto:bnw...@gmail.com>>>> wrote: > > > > > > > > I have following flowgraph: > > > > > > > > > > > > > > usrp_source--->>probe_mag_squared_block>block2--->block3 > > > > > > > > What I want to do is that I want to bypass the "work" > > function of > > > > block2 when the threshold level of probe_mag_squared > > reaches. > > > I do > > > > not want to stop(), lock(), disconnect the flow graph. > > Is this > > > > possible using stream tags, or message passing etc ? > > Any example > > > > code would be nice. > > > > > > > > -- > > > > Bob > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bypass work function
I applied this and this is useful in condition when you do not want to process noise, because it is being multiplied by zero when there is no signal. But I want that CMA taps remain unchanged when there is no signal or just noise. In the above scenario CMA taps change due to presence of noise, because it tries to equalize noise as well. Thanks for your comment. -- Bob On Mon, Sep 29, 2014 at 7:19 PM, Jeff Long wrote: > Try using a "threshold" off the "mag squared" and feed that into a > multiplier after block2 (with appropriate type adapters). As long as > block2 doesn't have a huge delay or do rate changes, this should work. > > - Jeff > > On 09/29/2014 10:23 AM, bob wole wrote: > > Hi thanks for your comment. block2 is the gnuradio "CMA equalizer > > block". I want the CMA block to remain quiet when there is no signal of > > interest. > > > > Bob > > > > > > Bob, > > > > Saw this the other day, but there isn't a lot to go on here. If > block2 > > is your own, you can make it do the bypass. You can also use some of > the > > logic blocks and a multiplier depending on what you're doing. There > > isn't really a concept of on-the-fly switching in GNU Radio. > > > > - Jeff > > > > On 09/26/2014 01:02 PM, bob wole wrote: > > > > > > People, any ideas on it? > > > > > > -- > > > Bob > > > > > > On Wed, Sep 24, 2014 at 12:04 PM, bob wole > <mailto:bnw...@gmail.com> > > > <mailto:bnw...@gmail.com <mailto:bnw...@gmail.com>>> wrote: > > > > > > I have following flowgraph: > > > > > > > > > usrp_source--->>probe_mag_squared_block>block2--->block3 > > > > > > What I want to do is that I want to bypass the "work" > function of > > > block2 when the threshold level of probe_mag_squared reaches. > > I do > > > not want to stop(), lock(), disconnect the flow graph. Is this > > > possible using stream tags, or message passing etc ? Any > example > > > code would be nice. > > > > > > -- > > > Bob > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bypass work function
Hi thanks for your comment. block2 is the gnuradio "CMA equalizer block". I want the CMA block to remain quiet when there is no signal of interest. Bob Bob, > > Saw this the other day, but there isn't a lot to go on here. If block2 > is your own, you can make it do the bypass. You can also use some of the > logic blocks and a multiplier depending on what you're doing. There > isn't really a concept of on-the-fly switching in GNU Radio. > > - Jeff > > On 09/26/2014 01:02 PM, bob wole wrote: > > > > People, any ideas on it? > > > > -- > > Bob > > > > On Wed, Sep 24, 2014 at 12:04 PM, bob wole > <mailto:bnw...@gmail.com>> wrote: > > > > I have following flowgraph: > > > > > > usrp_source--->>probe_mag_squared_block>block2--->block3 > > > > What I want to do is that I want to bypass the "work" function of > > block2 when the threshold level of probe_mag_squared reaches. I do > > not want to stop(), lock(), disconnect the flow graph. Is this > > possible using stream tags, or message passing etc ? Any example > > code would be nice. > > > > -- > > Bob > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bypass work function
People, any ideas on it? -- Bob On Wed, Sep 24, 2014 at 12:04 PM, bob wole wrote: > I have following flowgraph: > > > usrp_source--->>probe_mag_squared_block>block2--->block3 > > What I want to do is that I want to bypass the "work" function of block2 > when the threshold level of probe_mag_squared reaches. I do not want to > stop(), lock(), disconnect the flow graph. Is this possible using stream > tags, or message passing etc ? Any example code would be nice. > > -- > Bob > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bypass work function
I have following flowgraph: usrp_source--->>probe_mag_squared_block>block2--->block3 What I want to do is that I want to bypass the "work" function of block2 when the threshold level of probe_mag_squared reaches. I do not want to stop(), lock(), disconnect the flow graph. Is this possible using stream tags, or message passing etc ? Any example code would be nice. -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_time tag accuraccy
On 06/09/2014 06:05 AM, bob wole wrote: > > Can I have a comment on it? > > Bob, > > we've given you a lot of information on this (see Tom's posts as a > start). If you still have questions, I recommend you start a new thread > and post exactly what you need to know and what your requirements are. > > M > Marting, I got the answer from Tom, clock resolution for checking *tx_time* tag is 10ns (100MHz clock). Thanks -- Bob > > > > > -- > > Bob > > > > On Thu, Jun 5, 2014 at 11:02 AM, bob wole > <mailto:bnw...@gmail.com>> wrote: > > > > Sorry for not stating the hardware earlier. I am using USRP N210, > > with RFX2400 and WBX boards. > > > > -- > > Bob > > > > On Wed, Jun 4, 2014 at 11:07 PM, Marcus Leech > <mailto:mle...@ripnet.com>> wrote: > > > > I don't know the detailed answer, but any such answer will > > depend very much on which USRP hardware you're talking about. > > > > One of the R&D people who deals with the FPGA codebase may be > > able to give a precise answer, given stated hardware. > > > > > > > > on Jun 04, 2014, *bob wole* > <mailto:bnw...@gmail.com>> wrote: > > > > Marcus! Thanks for you comment. > > > > I think that USRP transmit FIFO is at the start of the DSP > > chain in FPGA i.e it is prior to both of the interpolation > > filters? right? I am not talking about when the burst will > > be over the air, I want to know when the first sample of the > > burst will leave the transmit FIFO if it has been tagged as > > tx_time=X. > > > > > > > > -- > > Bob > > > > > > On Wed, Jun 4, 2014 at 10:51 PM, Marcus Leech > > mailto:mle...@ripnet.com>> wrote: > > > > It will depend some on the effective group delay of both > > the interpolation filters in the the FPGA and the analog > > group delay of the analog bits of whatever daughtercard > > you're using. > > > > The only way to be sure is to measure... > > > > > > on Jun 04, 2014, *bob wole via USRP-users* > > > <mailto:usrp-us...@lists.ettus.com>> wrote: > > > > I am using stream tags for the transmission control. > > I want to know what is the accuracy/precision of the > > tx_time tag? E.g if I tag a burst A with tx_time=X, > > then the burst A will come out of the USRP transmit > > FIFO at X+delta, how large the value of delta could > > be? > > > > > > -- > > Bob > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_time tag accuraccy
Hi Tom, Thanks for your comment. I do not think if I tag a burst with time X, it'll go out of USRP transmit FIFO at exactly X, there would be some small delta involved depending on the clock resolution, and I want to know that delta. I know that there would be some DSP delays, depending on sample rate, and analog delays *AFTER* the burst leave transmit buffer. -- Bob On Mon, Jun 9, 2014 at 10:05 AM, Tom Tsou wrote: > On Wed, Jun 4, 2014 at 2:01 PM, bob wole wrote: > > I think that USRP transmit FIFO is at the start of the DSP chain in FPGA > i.e > > it is prior to both of the interpolation filters? right? I am not > talking > > about when the burst will be over the air, I want to know when the first > > sample of the burst will leave the transmit FIFO if it has been tagged as > > tx_time=X. > > If you tag a burst with time X, that burst will be released from the > device buffer at time X - assuming the burst arrives at the device > before time X. After time X, there will be a sample rate dependent > delay and a fixed analog group delay before the burst can be observed > at the antenna output. > > In other words, a burst tagged to transmit at time X will leave the > buffer at time X. > > -TT > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_time tag accuraccy
Can I have a comment on it? -- Bob On Thu, Jun 5, 2014 at 11:02 AM, bob wole wrote: > Sorry for not stating the hardware earlier. I am using USRP N210, with > RFX2400 and WBX boards. > > -- > Bob > > On Wed, Jun 4, 2014 at 11:07 PM, Marcus Leech wrote: > >> I don't know the detailed answer, but any such answer will depend very >> much on which USRP hardware you're talking about. >> >> One of the R&D people who deals with the FPGA codebase may be able to >> give a precise answer, given stated hardware. >> >> >> >> on Jun 04, 2014, *bob wole* wrote: >> >> Marcus! Thanks for you comment. >> >> I think that USRP transmit FIFO is at the start of the DSP chain in FPGA >> i.e it is prior to both of the interpolation filters? right? I am not >> talking about when the burst will be over the air, I want to know when the >> first sample of the burst will leave the transmit FIFO if it has been >> tagged as tx_time=X. >> >> >> >> -- >> Bob >> >> >> On Wed, Jun 4, 2014 at 10:51 PM, Marcus Leech wrote: >> >>> It will depend some on the effective group delay of both the >>> interpolation filters in the the FPGA and the analog group delay of the >>> analog bits of whatever daughtercard you're using. >>> >>> The only way to be sure is to measure... >>> >>> >>> on Jun 04, 2014, *bob wole via USRP-users* >>> wrote: >>> >>> I am using stream tags for the transmission control. I want to know >>> what is the accuracy/precision of the tx_time tag? E.g if I tag a burst A >>> with tx_time=X, then the burst A will come out of the USRP transmit FIFO at >>> X+delta, how large the value of delta could be? >>> >>> >>> -- >>> Bob >>> -- >>> >>> ___ >>> USRP-users mailing list >>> usrp-us...@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_time tag accuraccy
Sorry for not stating the hardware earlier. I am using USRP N210, with RFX2400 and WBX boards. -- Bob On Wed, Jun 4, 2014 at 11:07 PM, Marcus Leech wrote: > I don't know the detailed answer, but any such answer will depend very > much on which USRP hardware you're talking about. > > One of the R&D people who deals with the FPGA codebase may be able to give > a precise answer, given stated hardware. > > > > on Jun 04, 2014, *bob wole* wrote: > > Marcus! Thanks for you comment. > > I think that USRP transmit FIFO is at the start of the DSP chain in FPGA > i.e it is prior to both of the interpolation filters? right? I am not > talking about when the burst will be over the air, I want to know when the > first sample of the burst will leave the transmit FIFO if it has been > tagged as tx_time=X. > > > > -- > Bob > > > On Wed, Jun 4, 2014 at 10:51 PM, Marcus Leech wrote: > >> It will depend some on the effective group delay of both the >> interpolation filters in the the FPGA and the analog group delay of the >> analog bits of whatever daughtercard you're using. >> >> The only way to be sure is to measure... >> >> >> on Jun 04, 2014, *bob wole via USRP-users* >> wrote: >> >> I am using stream tags for the transmission control. I want to know >> what is the accuracy/precision of the tx_time tag? E.g if I tag a burst A >> with tx_time=X, then the burst A will come out of the USRP transmit FIFO at >> X+delta, how large the value of delta could be? >> >> >> -- >> Bob >> -- >> >> ___ >> USRP-users mailing list >> usrp-us...@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_time tag accuraccy
Marcus! Thanks for you comment. I think that USRP transmit FIFO is at the start of the DSP chain in FPGA i.e it is prior to both of the interpolation filters? right? I am not talking about when the burst will be over the air, I want to know when the first sample of the burst will leave the transmit FIFO if it has been tagged as tx_time=X. -- Bob On Wed, Jun 4, 2014 at 10:51 PM, Marcus Leech wrote: > It will depend some on the effective group delay of both the interpolation > filters in the the FPGA and the analog group delay of the analog bits of > whatever daughtercard you're using. > > The only way to be sure is to measure... > > > on Jun 04, 2014, *bob wole via USRP-users* > wrote: > > I am using stream tags for the transmission control. I want to know what > is the accuracy/precision of the tx_time tag? E.g if I tag a burst A with > tx_time=X, then the burst A will come out of the USRP transmit FIFO at > X+delta, how large the value of delta could be? > > > -- > Bob > > -- > > ___ > USRP-users mailing list > usrp-us...@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tx_time tag accuraccy
I am using stream tags for the transmission control. I want to know what is the accuracy/precision of the tx_time tag? E.g if I tag a burst A with tx_time=X, then the burst A will come out of the USRP transmit FIFO at X+delta, how large the value of delta could be? -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Equalization class help
Thanks for your reply Tom. Could I have some more explanation on it? if a training sequence at start of each burst could help in fast convergence for burst modem? -- Bob On Mon, May 12, 2014 at 6:01 AM, Tom Rondeau wrote: > On Mon, May 12, 2014 at 5:59 AM, bob wole wrote: > >> I want to work on equalization for ISI removal due to multipaths for >> burst frequency shift keying system. I found equalizer class in gnruadio, I >> want to know if somebody used cma_equalizer for the task with success or if >> I can use it for equalization of burst frequency shift keying system before >> continuing with it? >> >> >> Thanks >> >> -- >> Bob >> > > It'll conceivably work, but the challenge with the CMA equalizer (and the > LMS-DD equalizer as well) is the long convergence time. Between every > burst, you're going to lose tracking of the taps, so you might want to > think of a way to shut down the tap update loop when you're not receiving a > packet (which involves knowing when that's happening in time to send the > info to the equalizer). For starters, just use a few taps in the equalizer > and a gain higher than you would expect to see if you can get it to > converge to "close enough" early in the burst. > > Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Equalization class help
I want to work on equalization for ISI removal due to multipaths for burst frequency shift keying system. I found equalizer class in gnruadio, I want to know if somebody used cma_equalizer for the task with success or if I can use it for equalization of burst frequency shift keying system before continuing with it? Thanks -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD Asyn Msg source help!
I am trying to use the UHD Asyn Msg source but I am not getting any thing out of this block. How can I use it? Can somebody please share any existing flow-graph that demonstrates the block usage. Thanks, Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to best use new GR features for TDMA systems ?
> I think GNU Radio apps should look a bit like this:
> At the top (think "MAC") blocks pass data as PDUs. The further down you go
> ("PHY"), you'll eventually need regular blocks. Here, tagged streams will
> do what you want.
> I guess gr-easymac was an early demo of this principle, although its
> functionality can now be reproduced with pure GNU Radio. At CEL, we've
> developed a FHSS network using pure GNU Radio, which works quite well
> (someone still needs to release some code, and I hope they're reading this
> :). There will be a presentation on this at FOSDEM, btw.
>
> Also, I've been working on a way to do TDMA using the OFDM blocks (on one
> of my lower-priority branches, though, so don't get too excited right now).
> In principle, the idea is:
> * At MAC level, create a package with a tx time stamp as a PDU
> * Pass this to the OFDM mod. The time stamp will propagate along with the
> length tag, and stay at the front of the streamed packet (this feature was
> merged into GNU Radio a while back and is available in the latest release).
> * The hardware driver should take the streamed packet and the metadata in
> the tags (the tx time, though it could also be *the centre frequency for
> FH*)
> and tx accordingly.
>
Hi MB,
I am using tags (tx_time, tx_eob, tx_sob) for burst transmission. You
mentioned above that tags can also be used to tell the centre frequency for
FH? Which tag does so ? Is it a custom tag you implemented ?
Thanks,
Bob
> * At the receive side, all we need to do is remember the rx time of samples
> when we do a packet modulation.
>
> There's a couple of things that are hard here: On the TX side, we just hope
> that the packet will reach the hardware in time. What if it doesn't? Well,
> bad luck.
>
> Bottom line: GNU Radio has only recently become capable of doing these
> things. This means we are still in the process of figuring out of how
> exactly to write TDMA PHYs with corresponding MACs, which is a feature that
> we've always wanted and now seems achievable. I guess the more we try out,
> the more we will identify what's missing in order to do this.
>
> MB
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] test correlate and sync block
I installed a fresh verison of gnuradio 3.7.2.1 and was testing some of the new features including the "correlate and sync"- A must from burst modems. I am using the "test_corr_and_sync.grc" example. Constellation and rest of the output looks fine. However, when I plot the "phase" output of "polyphase clock sync" its look like during burst time phase does not get lock. Phase output just keep on changing, please see the attached picture of phase output. Well, real performance test should include a packet encoder and decoder etc to evaluate BER. But before trying that I thought I should try the example that comes with gnuradio, is the phase outputlooks ok? -- Bob <>___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Installation issue
On Sun, Dec 15, 2013 at 10:57 PM, Tom Rondeau wrote: > On Sun, Dec 15, 2013 at 12:36 PM, bob wole wrote: > > I installed gnuradio and UHD using instruction on > > > > > http://gnuradio.org/redmine/projects/gnuradio/wiki/BinaryPackages#Binaries-from-Ettus-Research-Linux-Windows > > > > UHD programs are running fine e.g uhd_find _devices. But when I run > > $ gnuradio-config-info > > I get following > > gnuradio-config-info: error while loading shared libraries: > liblog4cpp.so.5: > > cannot open shared object file: No such file or directory > > > > I have also done sudo ldconfig and my paths are set properly. What could > be > > the issue ? > > > > > > Can I use 'build gnuradio' script to install a specific version of > gnuradio > > and UHD? If yes, how? What is the recommended way to do this? > > > > -- > > bob > > > Do you have log4cpp installed? You can do it using 'apt-get install > liblog4cpp5-dev". That should sort you out. > > It looks like that package might be built with the logger but log4cpp > is not defined as a dependency. I'll check with our package maintainer > on this. > > Tom > Thanks Tom for reply. sudo apt-get install liblog4cpp5-dev worked for me. I downloaded deb file from http://files.ettus.com/binaries/gnuradio/latest_stable/ I am unable to find the source code i.e .cc files for gnuradio blocks. Where I can find them? Installing from "deb" does not download the source code as well? Also, Its mention on the gnuradio page that build gnuradio script should be used for newer ubuntu versions. How can I use 'build gnuradio' script to install a specific version of gnuradio and UHD? -- Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Installation issue
I am using Ubuntu 12.04 LTS 64 bit. On Sun, Dec 15, 2013 at 9:36 AM, bob wole wrote: > I installed gnuradio and UHD using instruction on > > > http://gnuradio.org/redmine/projects/gnuradio/wiki/BinaryPackages#Binaries-from-Ettus-Research-Linux-Windows > > UHD programs are running fine e.g uhd_find _devices. But when I run > $ gnuradio-config-info > I get following > gnuradio-config-info: error while loading shared libraries: > liblog4cpp.so.5: cannot open shared object file: No such file or directory > > I have also done sudo ldconfig and my paths are set properly. What could > be the issue ? > > > Can I use 'build gnuradio' script to install a specific version of > gnuradio and UHD? If yes, how? What is the recommended way to do this? > > -- > bob > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Installation issue
I installed gnuradio and UHD using instruction on http://gnuradio.org/redmine/projects/gnuradio/wiki/BinaryPackages#Binaries-from-Ettus-Research-Linux-Windows UHD programs are running fine e.g uhd_find _devices. But when I run $ gnuradio-config-info I get following gnuradio-config-info: error while loading shared libraries: liblog4cpp.so.5: cannot open shared object file: No such file or directory I have also done sudo ldconfig and my paths are set properly. What could be the issue ? Can I use 'build gnuradio' script to install a specific version of gnuradio and UHD? If yes, how? What is the recommended way to do this? -- bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Looking for DSSS demodulator
Thanks Achilleas for explanation, I'll try with gnuradio 3.7.2 and report back. -- bob On Fri, Nov 22, 2013 at 8:30 PM, Achilleas Anastasopoulos wrote: > Bob, > > As I mentioned in my email, the only application that currently > runs is the > > timing_test.grc > > For it to run you need to load the block > > chopper_correlator.grc > > and compile it in grc so that it gets to your custom grc directory. > > Please let me know if you have any issues with this. > This application contains all the essentials for the cdma system, but it is > not THE cdma system... > > The whole project is built on gnuradio 3.7.2 > > The remaining apps/blocks for cdma are work-in-progress. > > best, > Achilleas > > > > On Fri, Nov 22, 2013 at 10:19 AM, bob wole wrote: > >> Great share Achilleas. But I am having problem running it. Quite a few >> blocks are missing. Please share on what version of GnuRadio was it built >> against? Did you use custom blocks too? >> >> -- >> Bob >> >> >>> >>> Outstanding! Thanks for putting in the time to make this happen! >>> >>> What version of gnuRadio was it built against? >>> >>> @(^.^)@ Ed >>> >>> >>> >>> On 11/20/13 4:05 PM, Achilleas Anastasopoulos wrote: >>> > I have been working on a DSSS system for some time now. >>> > You can find our work-in-progress here: >>> > >>> > https://github.com/anastas/gr-cdma.git >>> > >>> > A few comments: >>> > >>> > this project grew out of the DARPA spectrum challenge: >>> > our team eventually dropped out of the race because of other time >>> > commitments but >>> > I decided to finish up the design and make it publicly available >>> > since DARPA was generous enough to send us USRPs for testing etc. >>> >>> >>> >>> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Looking for DSSS demodulator
Great share Achilleas. But I am having problem running it. Quite a few blocks are missing. Please share on what version of GnuRadio was it built against? Did you use custom blocks too? -- Bob > > Outstanding! Thanks for putting in the time to make this happen! > > What version of gnuRadio was it built against? > > @(^.^)@ Ed > > > On 11/20/13 4:05 PM, Achilleas Anastasopoulos wrote: > > I have been working on a DSSS system for some time now. > > You can find our work-in-progress here: > > > > https://github.com/anastas/gr-cdma.git > > > > A few comments: > > > > this project grew out of the DARPA spectrum challenge: > > our team eventually dropped out of the race because of other time > > commitments but > > I decided to finish up the design and make it publicly available > > since DARPA was generous enough to send us USRPs for testing etc. > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] HELP! - Problem with radio application deploy
Thanks Tom and Marcus for taking time out and explaining things on the list. -- Bob > > > How do you determine the size of taps? How much of a difference does > > setting the transition width from 1MHz to 10MHz make? > > > Generally, the wider the transition width, the fewer taps. > > You can use the "firdes" functions, which is what the low-pass filter > blocks call in gnuradio, then take their output into a variable and >have another variable be len(filter). > > > > > > On Tue, Nov 19, 2013 at 6:40 PM, Marcus D. Leech > <mailto:mle...@ripnet.com>> wrote: > > > > I really appreciate the detailed explanation. I tried running > > gr_filter_design last night and it asked me to install SciPy, > > which I did not feel like doing at that time. I will try using > > 1MHz for my band, which may help get rid of the real-time > > running issue. > > > > Again, I appreciate your help with this matter. > > > > Let's say you get a filter that's, oh, I dunno, 100 taps long. > > That filter has to process every sample, so, that's 5e7 X 100 taps, > or > > roughly 5e9 FLOP/second. Just for that one filter. And your > > flow-graph is likely doing other things *and* it's having to get > > samples > > all the way through your network or USB stacks into the > > application layer as well, call that 100 instructions/sample. So, > > that's > > 5e7 x 100 = 5e9 OPS/second just to get your samples into the > > application. You're going to burn-up the cycles on your CPU pretty > > quickly at 50Msps, even for doing "trivial" things. > > > > > > > > > > > > -- > > Marcus Leech > > Principal Investigator > > Shirleys Bay Radio Astronomy Consortium > > http://www.sbrac.org > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_firdes.cc/firdes.cc - window functions - flawe
Hi Tom and Chris,
Thanks for your detailed guidance on this. I'll try this out.
Bob
On Mon, Oct 7, 2013 at 9:49 PM, KB3CS - Chris wrote:
> $ git diff v3.6.3 HEAD gr-filter/lib/firdes.cc (but modified since you
> remain @ v3.6.3)
>
> diff --git a/gr-filter/lib/firdes.cc b/gr-filter/lib/firdes.cc
> index 5c3320d..d55a4ba 100644
> --- a/gr-filter/lib/firdes.cc
> +++ b/gr-filter/lib/firdes.cc
> @@ -746,6 +746,7 @@ namespace gr {
>case WIN_RECTANGULAR:
> for(int n = 0; n < ntaps; n++)
>taps[n] = 1;
> +break;
>
>case WIN_HAMMING:
> for(int n = 0; n < ntaps; n++)
> @@ -774,16 +775,13 @@ namespace gr {
> double IBeta = 1.0/Izero(beta);
> double inm1 = 1.0/((double)(ntaps));
> double temp;
> - //fprintf(stderr, "IBeta = %g; inm1 = %g\n", IBeta, inm1);
>
> - for(int i=0; i - temp = i * inm1;
> - //fprintf(stderr, "temp = %g\n", temp);
> - taps[i] = Izero(beta*sqrt(1.0-temp*temp)) * IBeta;
> - //fprintf(stderr, "taps[%d] = %g\n", i, taps[i]);
> - }
> + for(int i= 0; i +temp = 2*i*inm1 - 1;
> +taps[i] = Izero(beta*sqrt(1.0-temp*temp)) * IBeta;
> + }
> }
> - break;
> + break;
>
>default:
> throw std::out_of_range("firdes:window: type out of range");
> @@ -804,7 +802,7 @@ namespace gr {
> throw std::out_of_range("firdes check failed: 0 < fa <=
> sampling_freq / 2");
>
>if(transition_width <= 0)
> - throw std::out_of_range("gr_dirdes check failed: transition_width
> > 0");
> + throw std::out_of_range("gr_firdes check failed: transition_width
> > 0");
> }
>
> void
>
> .. but don't make the #include file changes in your v3.6.3 and you should
> change the version number (VERSION_INFO_MAINT_VERSION) in CMakeLists.txt
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_firdes.cc/firdes.cc - window functions - flawe
We installed gnuradio 3.6.3 using gnruadio build script. We can't
change the gnuradio version currently. How can we apply this patch to
our installation. What commands should we run? We don't use git.
--
Bob
On Sun, Oct 6, 2013 at 12:39 PM, KB3CS - Chris wrote:
>* (If you just want to cut to the chase, the diff against 3.6.5.1 is attached)*
>
>* How i got here: Contemplating some filters using gnuradio-companion with a*
>* simple flowgraph (simple enough to describe in words alone). Noticed the*
>* frequency response with a Rectangular filter was exactly the same as with a*
>* Hamming filter and also the response with a Kaiser filter (while varying*
>* Beta) seemed quite wrong.*
>
>* The flowgraph: noise source -> throttle -> filter -> FFT*
>* really basic. used the "convenience" blocks which are wrappers for firdes.*
>
>* After quite a while of scratching my head at the odd results observed, then*
>* checking (and double-checking) Oppenheim[1999] and others, I wrote a little*
>* python to have a direct look at the window function coefficients:*
>
>* #!/usr/bin/env python*
>* from gnuradio import gr, audio*
>* from math import pi*
>
>* sample_rate = 192000*
>* ntaps = 16*
>
>* #channel_coeffs =*
>* gr.firdes.low_pass(1.0,sample_rate,50e3,4e3,gr.firdes.WIN_HAMMING,beta)*
>
>* #print channel_coeffs*
>
>* #channel_coeffs = gr.firdes.low_pass(1.0,10,1,1,gr.firdes.WIN_HAMMING,beta)*
>
>* #print channel_coeffs*
>
>* print "\n\nRectangular window function for {} samples\n".format(ntaps)*
>
>* win_coeffs = gr.firdes.window(gr.firdes.WIN_RECTANGULAR,ntaps,0)*
>
>* print win_coeffs*
>
>* print "\n\nHamming window function for {} samples\n".format(ntaps)*
>
>* win_coeffs = gr.firdes.window(gr.firdes.WIN_HAMMING,ntaps,0)*
>
>* print win_coeffs*
>
>* print "\n\nKaiser window function for {} samples\n".format(ntaps)*
>
>* alpha = 1.0*
>* print "Alpha = {}\n".format(alpha)*
>* win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)*
>
>* print win_coeffs*
>
>* alpha = 2.5*
>* print "\nAlpha = {}\n".format(alpha)*
>* win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)*
>
>* print win_coeffs*
>
>* alpha = 8.0*
>* print "\nAlpha = {}\n".format(alpha)*
>* win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)*
>
>* print win_coeffs*
>
>* alpha = 20.0*
>* print "\nAlpha = {}\n".format(alpha)*
>* win_coeffs = gr.firdes.window(gr.firdes.WIN_KAISER,ntaps,alpha*pi)*
>
>* print win_coeffs*
>
>* print "\nDone\n"*
>
>* .. and here's the essential extract of output from unmodified v3.6.5.1*
>* source:*
>
>* Rectangular window function for 16 samples*
>
>* (0.0799821186066, 0.11976908892393112, 0.23219992220401764,*
>* 0.39785218238830566, 0.5880830883979797, 0.769809265137,*
>* 0.9121478199958801, 0.9899479150772095, 0.9899479150772095,*
>* 0.9121478199958801, 0.769809265137, 0.5880830883979797,*
>* 0.39785218238830566, 0.23219992220401764, 0.11976908892393112,*
>* 0.0799821186066)*
>
>
>* Hamming window function for 16 samples*
>
>* (0.0799821186066, 0.11976908892393112, 0.23219992220401764,*
>* 0.39785218238830566, 0.5880830883979797, 0.769809265137,*
>* 0.9121478199958801, 0.9899479150772095, 0.9899479150772095,*
>* 0.9121478199958801, 0.769809265137, 0.5880830883979797,*
>* 0.39785218238830566, 0.23219992220401764, 0.11976908892393112,*
>* 0.0799821186066)*
>
>
>* Kaiser window function for 16 samples*
>
>* Alpha = 1.0*
>
>* (1.0, 0.9949779510498047, 0.9800193309783936, 0.9554436802864075,*
>* 0.9217740297317505, 0.8797227740287781, 0.8301725387573242,*
>* 0.7741525173187256, 0.712824038696, 0.6473857760429382,*
>* 0.5791705250740051, 0.5094824433326721, 0.43962839245796204,*
>* 0.3708721101284027, 0.3044034540653229, 0.241310253739357)*
>
>
>* ... the Rectangular coefficients aren't right. And sure, it's really weird*
>* the coefficients are the same as for the Hamming window. But look at the*
>* Kaiser coefficients! (this was giving me an awful headache and bothering me*
>* to no end).*
>
>* With a little help from octave and some quick cut-n-pastes, I was now*
>* contemplating graphs of window functions. The Kaiser window function didn't*
>* look right at all. It started a 1.0 and tapered toward zero. No starting*
>* near zero and tapering -up- toward 1.0 present. That can't be right, can it?*
>* Well, no, it can't. Hmm!*
>
>* Glossing over the many hours it took from the start of this journey to its*
>* conclusion, I present the essential extra
Re: [Discuss-gnuradio] AGC and Dynamic Range of ADC
On 09/23/2013 11:07 PM, bob wole wrote: Can somebody please guide me on this ? Bob On Fri, Sep 20, 2013 at 4:44 PM, bob wole wrote: > I have USRPN210 with WBX and RFX2400. Is there any AGC chip on N210 > motherboard or WBX, RFX2400 before ADC to utilize the dynamic range of ADC > ? if yes, which one? If not, then won't the varying input signal (for > example signal from moving object) to ADC affect the performance of ADC ? > > Bob > >>The ADC on an N210 has over 80dB of dynamic range. If that >>isn't enough, then your application can adjust the RF gain to taste. >>Only a subset of applications actually benefit from the usual >>hardware AGC schemes, and such schemes are invariably >>application-specific, so there's >>no *automatic* gain control. But your application can >>dynamically make gain adjustments as it goes. Hi Marcus thanks for response, If there is no automatic gain control then how does it is ensured that ADC doesn't saturate ? I mean what if there is a signal whose amplitude is greater that ADC's highest input level ? Won't it saturate the ADC ? Also what if the signal is too weak to span much of the ADC input voltage, then again we are not using all bits effectively. Guide please. Thanks, Bob >>-- >>Marcus Leech >>Principal Investigator >>Shirleys Bay Radio Astronomy Consortium >>http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AGC and Dynamic Range of ADC
Can somebody please guide me on this ? Bob On Fri, Sep 20, 2013 at 4:44 PM, bob wole wrote: > I have USRPN210 with WBX and RFX2400. Is there any AGC chip on N210 > motherboard or WBX, RFX2400 before ADC to utilize the dynamic range of ADC > ? if yes, which one? If not, then won't the varying input signal (for > example signal from moving object) to ADC affect the performance of ADC ? > > Bob > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] AGC and Dynamic Range of ADC
I have USRPN210 with WBX and RFX2400. Is there any AGC chip on N210 motherboard or WBX, RFX2400 before ADC to utilize the dynamic range of ADC ? if yes, which one? If not, then won't the varying input signal (for example signal from moving object) to ADC affect the performance of ADC ? Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Discussion topics in one folder
Hello, I currently receive discussion topics individually. I would now like to receive them in a single folder. Thank you. bob mensah___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Wanted: used USRP 1, 2 etc.
Hello, I am a student in need of a USRP. I'd like the USRP2 or the N200, but they're probably too expensive. I can probably still use the old USRP1. I think I have the radios I need, but if you've got them or accessories to sell, I'd be interested in hearing about it. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sample rate vs. symbol time issue & E100 "Flexible Clocking" (more info please)
I'm currently confronted with a sample rate vs. symbol time issue. I noticed that the E100 announcement mentioned a "flexible clocking" feature to deal with exactly this type of thing. I've been looking on the Ettus site for more information, but haven't been able to locate any. Is there any more info to be had here? Also, will the N210 incorporate this feature? And on a different but related front, sample rate wise it looks like the Crystek CVHD-950-122.880 would be a good candidate for use as a replacement oscillator on the USRP2. Has anyone had any luck with this part? Any timing issues I should be aware of? It looks as though the clock generator chip shouldn't have a problem with it. Thanks much, --Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DQPSK bug or incorrect settings?
In a word, NEVER. No self respecting communication systems designer would allow that much excess bandwidth on the air or any realistic transmission medium. Typically 2-3 samples per baud is more than enough. You then use a polyphase filter bank based clock recovery tool to FIND the correct upsampled phase (at SAY, 6-10 samples per baud) but you never operate the demodulator at that much oversampling. I think Tom has finished and checked in the PFB based clock recovery based on the work by fred harris last summer-ish. Am I right? If not, if I may be off assistance in finishing, I will. Bob On 8/8/2010 5:00 PM, Tom Rondeau wrote: On Sun, Aug 8, 2010 at 1:41 PM, Thunder87 wrote: Thunder87 wrote: If so, what is maximal and minimal safe "samples/symbol" to "samp_rate" rates? Minimal "samples/symbol" is 2. Is there a maximal ? 215 is a pretty outrageous number to use; you should never need to oversample that much. 2 to 4 is typical, 6-10 is about the highest you probably want to go. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- (Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. “Be yourself, because the people who mind don't matter. And the people that matter don't mind." -Dr. Seuss Active: Facebook,Twitter,LinkedIn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] complex multiplication question
The SECOND ORDER Costas loop produces foptr(n) and poptr(n) which is the
frequency and phase estimate for the carrier.
sin(poptr(n)) is the estimated carrier.
If S(n)*sin(poptr(n) is the spreading code modulating the estimated
carrier, then
S(n)*P(n) * complex_conjugate(S(n)*sin(poptr(n)) should be approximately
P(n) up to error in
a) your estimate of the carrier
BUT ALSO
b) the clock of the transmit system and its initial phase offset for the
complex spreading code MUST ALSO be estimated to close this system and
track. My little equation above ASSUMES perfect knowledge of S(n) which
is NEVER the case in a real system.
Bob
On 8/3/2010 9:45 PM, John Andrews wrote:
Hi,
can someone guide me a little here please. I have a complex signal S(n)
that I multiply with a sequence P(n) of length N (the sequence consists
of {-1,1} ). I pass the product into a Costas Loop to track the carrier.
Btw, the complex_input signal a spread signal spread using the sequence
P(n) and BPSK modulated.
S(n)*P(n) ---> Costas Loop
Then I want to remove the carrier from the original signal which can be
done by multiplying the frequency output of the costas loop which is
foptr[i] with S(n). Is that right? I want to do this in GRC. Can someone
guide me a little here and tell me if I am understanding it right.
Will be eagerly waiting for a reply. I am not good at Communications
stuff as this is not my major but I am trying hard. :) A little help
will greatly appreciated.
Thanks
John
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
(Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio
Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats,
NJQRP, QRP ARCI, QCWA, FRC.
“Be yourself, because the people who mind don't
matter. And the people that matter don't mind."
-Dr. Seuss
Active: Facebook,Twitter,LinkedIn
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] improper WBX transmission of tone in center of spectrum
That is an awesome amount of LO suppression in an SSB mixer based system (I mean the power 1/33-th of the LO). A more interesting number given this level of LO suppression would be the introduction of a tone (say) above the LO at LO+F and to see what the power is at LO-F (the image). Bob On 8/3/2010 4:55 PM, Matt Ettus wrote: The WBX can put out about 20dBm at 520 MHz. -55dBm would be 75dB below the desired signal, which is quite a good amount of LO suppression. If you need more, you'll need to actively calibrate the DC offset to null it out. Matt On 08/03/2010 12:55 PM, George Nychis wrote: The power of the tone comes in to the spectrum analyzer at -55.6dBm -- (Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. “Be yourself, because the people who mind don't matter. And the people that matter don't mind." -Dr. Seuss Active: Facebook,Twitter,LinkedIn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 2nd Edition
The 2nd edition of the REALLY expensive ($29.95) SDR book by friend and colleague, Behrouz Farhang-Beroujeny, has been released from lulu. It contains important additions (OFDM, more filtering, all known errata fixed) and I recommend it highly. http://bit.ly/cTU2cm Enjoy Bob McGwier (ARS N4HY) -- (Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. “Be yourself, because the people who mind don't matter. And the people that matter don't mind." -Dr. Seuss Active: Facebook,Twitter,LinkedIn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help wanted with building a block
Hi I have a question on how best to organise the software for this device. I've looked at how usrp2 organises things with its hierarchy of classes. This device has two input streams and one output stream with in-band signaling on the output stream and in-band status on one of the input streams. My question is that the control and status are nothing to do with the streams specifically. It's not quite like the usrp where the input has the rx controls and the output the tx controls (if I read the code correctly). Is it possible to have classes for control and status that are not part of a source or sink, i.e. don't inherit from gr_sync_block or is there some other way to organise that. Regards Bob On 12/07/2010 20:17, Eric Blossom wrote: > On Mon, Jul 12, 2010 at 02:18:43PM +0100, Bob Cowdery wrote: >> Hi, >> >> I've just started investigating the possibility of building a >> source/sink to a USB device. I've read the 'How to Write a Signal >> Processing Block', built GNURadio on Ubuntu 10.04 and played around a >> bit with building the example gr-how -to-write-a -block. I've also had a >> cursory look at the usrp directories. I'm looking for a little bit of a >> leg-up to kick me off. I'm assuming that the structure of the usrp2 >> directories would be the best place to start. I have noticed that the >> document 'How to Write a Signal Processing Block' shows a different >> directory structure to that in the code example and the usrp directories >> are different again. There is also a gr-usrp2 and usrp2 and it's not >> immediately obvious to me how they are split up and why. > usrp2 provides a non-GNU Radio specific interface to the usrp2. > gr-usrp2 builds on usrp2 and implements the actual sources and sinks. > >> 1. Which would be the best structure to take as a template and do I need >> both structures as in usrp2. > Easiest way to get the build framework started is to run > > $ create-gnuradio-out-of-tree-project > > It will create a directory tree starting with > >> 2. Most of the documentation talks about processing blocks, sources and >> sinks. Is there anything that talks about a device which is both a >> source and a sink or do I need to trawl through the usrp code to see how >> to handle that. > The usrp code is a reasonable place to start your study. It's > probably more complicated than you need, but then the USRP is really > flexible. You should be able to use the fast usb classes as is. > > Good luck! > Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help wanted with building a block
Thanks Eric, that makes sense. I expect to go around the houses a bit on this but I have working C code so essentially first off I just need to code the interfaces. I guess therefore I have the equivalent of usrp2 and need to do a somewhat simplified version of gr-usrp2. Bob On 12/07/2010 20:17, Eric Blossom wrote: > On Mon, Jul 12, 2010 at 02:18:43PM +0100, Bob Cowdery wrote: >> Hi, >> >> I've just started investigating the possibility of building a >> source/sink to a USB device. I've read the 'How to Write a Signal >> Processing Block', built GNURadio on Ubuntu 10.04 and played around a >> bit with building the example gr-how -to-write-a -block. I've also had a >> cursory look at the usrp directories. I'm looking for a little bit of a >> leg-up to kick me off. I'm assuming that the structure of the usrp2 >> directories would be the best place to start. I have noticed that the >> document 'How to Write a Signal Processing Block' shows a different >> directory structure to that in the code example and the usrp directories >> are different again. There is also a gr-usrp2 and usrp2 and it's not >> immediately obvious to me how they are split up and why. > usrp2 provides a non-GNU Radio specific interface to the usrp2. > gr-usrp2 builds on usrp2 and implements the actual sources and sinks. > >> 1. Which would be the best structure to take as a template and do I need >> both structures as in usrp2. > Easiest way to get the build framework started is to run > > $ create-gnuradio-out-of-tree-project > > It will create a directory tree starting with > >> 2. Most of the documentation talks about processing blocks, sources and >> sinks. Is there anything that talks about a device which is both a >> source and a sink or do I need to trawl through the usrp code to see how >> to handle that. > The usrp code is a reasonable place to start your study. It's > probably more complicated than you need, but then the USRP is really > flexible. You should be able to use the fast usb classes as is. > > Good luck! > Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Help wanted with building a block
Hi, I've just started investigating the possibility of building a source/sink to a USB device. I've read the 'How to Write a Signal Processing Block', built GNURadio on Ubuntu 10.04 and played around a bit with building the example gr-how -to-write-a -block. I've also had a cursory look at the usrp directories. I'm looking for a little bit of a leg-up to kick me off. I'm assuming that the structure of the usrp2 directories would be the best place to start. I have noticed that the document 'How to Write a Signal Processing Block' shows a different directory structure to that in the code example and the usrp directories are different again. There is also a gr-usrp2 and usrp2 and it's not immediately obvious to me how they are split up and why. 1. Which would be the best structure to take as a template and do I need both structures as in usrp2. 2. Most of the documentation talks about processing blocks, sources and sinks. Is there anything that talks about a device which is both a source and a sink or do I need to trawl through the usrp code to see how to handle that. Regards Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Go New Zealand (Slashdot article through bit.ly)
http://bit.ly/bpwfa9 -- (Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. “One must be a fox in order to recognize traps, and a lion to frighten off wolves" -Machiavelli Active: Facebook,Twitter,LinkedIn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Rohde and Schwarz ridiculous patent app. Sorry Ulrich
This patent must be fought tooth and nail. It is loaded with art which has been done MANY times before. I will be personally taking this on as a battle for my employers but we need all guns blazing at the patent office. Lockheed, General Dynamics, and more have done SDR units with red side/black side in it for JTRS but we just don't want R&S to be able to patent something so basic as this in a communications system. This should be on the radar for cellular telephone companies and more. Bob http://www.faqs.org/patents/app/20100027782 Inventors: Ingo Voll Boyd Buchin Dieter Soergel Agents: MARSHALL, GERSTEIN & BORUN LLP Assignees: Rohde & Schwarz GmbH & Co. KG Origin: CHICAGO, IL US IPC8 Class: AH04L918FI USPC Class: 380 42 Patent application number: 20100027782 Abstract: The invention relates to a device for processing datastreams in a communications unit with two mutually-separate data-processing regions, which provide at least two separate message paths. The message paths are connected respectively to a message transmitter and a message receiver, wherein, in each message path, an encoding module is provided, which is connected both to a first data-processing region and also to a second data-processing region. Furthermore, in the second data-processing region, a distribution unit is provided, which is connected to the message paths of the first data-processing region and to all encoding modules of the corresponding message paths in order to distribute given messages in a targeted manner. Claims: 1. Device for processing datastreams in a communications unit with two mutually-separate data-processing regions, which provide at least two separate message paths, which are connected respectively to a message transmitter and respectively to a message receiver,comprising,an encoding module in each message path connected both to a first data-processing region and to a second data-processing region, anda distribution unit connected to the message paths of the second data-processing region and to all encoding modules of the corresponding message paths for the targeted distribution of given messages. 2. Device according to claim 1, whereinthe first data-processing region is provided for processing of sensitive data, and the second data-processing region is provided for a processing of non-sensitive data. 3. Device according to claim 1, whereintest rules for data exchange between the various message paths of the first data-processing region are provided in each encoding module. 4. Device according to claim 1, whereinin a relay operating mode, a selective distribution of the datastream to the various message paths is provided. 5. Device according to claim 4, whereinthe selective distribution of the datastream is provided on the basis of different domains with an addressing and/or different classification with regard to confidentiality. 6. Device according to claim 1, whereintest rules for a configurable data exchange between the first data-processing region and the second data-processing region of a message path are provided in each encoding module. 7. Device according to claim 6, whereinthe test rules are address lists and/or other confidentiality tables. 8. Device according to claim 1, whereinin the case of an error, a data leakage from the first data-processing region is prevented. 9. Device according to claim 1, whereinan automatic testing of the incoming and/or outgoing communication between the message paths is provided in the encoding modules. 10. Device according to claim 1, whereina differentiation of the datastreams on the basis of a degree of confidentiality is provided. 11. Device according to claim 1, whereinthe distribution unit is connected to a configuration unit. 12. Device according to claim 6, whereinthe test rules are selectively configurable in the encoding modules. 13. Device according to claim 1, whereinat least one key capable of being read in from externally is stored in each encoding module. 14. Device according to claim 13, whereinthe key can be read in by a memory element. 15. Device according to claim 1, whereinthe various message paths meet different and/or the same communications standards. 16. Device according to claim 1, whereinthe communications unit is a radio device. 17. Device according to claim 1, whereineach message path is connected at a first end to an antenna and at a second end to a user interface. 18. Device according to claim 1, whereina bi-directional operating mode is provided at least for a subset of the message paths. 19. Method for processing datastreams in a communications unit, comprising processing the datastreams in two separate data-processing regions, and transporting the datastreams in at least two separate message paths between respectively a message transmitter and respectively a message receiver and are encoded or decoded in each
[Discuss-gnuradio] Ettus Research, Inc purchase by NI
The endeavors of the those I work with has involved applying serious research in SDR with the aid of people at Ettus and other GNURadio developers. We have applied serious funding to Ettus Research, Inc. in particular and GNURadio in general. We have every intention of continuing this and expanding it. We write GPL v3 code and we insist on the openness continuing. We have given code back to the repository for years and this will continue. A recent example is the new polyphase filter bank and arbitrary rate resampler code checked in by one of the developers for GNURadio. The amount of money and people time involved is significant to anyone's way of thinking and has directly impacted, in my view for the better, the quality and the quantity of the code currently in the repository. This too will continue. Companies, governments, scientists, engineers and even those that don't know it yet, NEED open source and open hardware and are supporting it and using it because of their need. Many in older stodgier communities have been slow to follow but are now really getting into the act. It is as simple as that. This trend will continue and you are seeing this trend reported about openly in various media. One needs only to decide to pay attention to see it. I would say for now, fear not, and congratulation to Matt. In my conversations with him, he feels that NI has left him in charge (he is the president of the new Ettus) and that while Ettus is a wholly owned subsidiary, it is not a small office inside the megalith of immovable bureaucracy. Ettus is a maker as are many of the rest of the developers in GNURadio. I think NI does not want to foul up what is working. In my mind, knowing something of Matt for years, he would not compromise his idealism for a buck. I have personal knowledge of at least one incident where he turned away enough money to satisfy dream's of avarice for most of us in a stand in defense of his idealism. I am proud to know him. The maker mentality's time has come and while USRP is not yet in the ideal "maker format" (no 3d printers are involved YET) it is moving that way with the inexpensive plug in cards. Hopefully you won't mind me plugging my favorite ex-EFF employee and favorite current syfy author's book on the subject. http://craphound.com/makers/makers_tor_big.jpg Bob (P.S. I was not informed before it the NI deal was a fait d'accompli and after I spent some time having contracting officers and project managers deal with it all, I am personally feeling this will work for us) -- (Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. “Our beds are empty two-thirds of the time. Our living rooms are empty seven-eighths of the time. Our office buildings are empty one-half of the time. It’s time we gave this some thought.” -- R. Buckminster Fuller Active: Facebook,Twitter,LinkedIn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NO KNOBS, An interesting piece on army web site
http://www.twitpic.com/105rzu I wonder why it disappeared? Maybe coincidence. This was mentioned at the recent SDR Forum technical conference. SDR Forum has become the newest buzz word in town, Wireless Innovation Forum (you have to stay relevant right? You cannot believe how many times I hear at work that RF is dead but Wireless is in!). Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-pager build issue
Whenever this comes up, I need to do sudo make uninstall for whatever reason. Something that is in /usr/local/lib/gnuradio ... etc. gets in the way of the build. It is just too easy to do the uninstall for me to take time to figure it out. Bob On 1/15/2010 8:54 PM, Johnathan Corgan wrote: On Fri, Jan 15, 2010 at 17:44, Veljko Pejovic wrote: I got the same error: make[4]: *** No rule to make target `/../lib/libgnuradio-pager.la', needed by `_pager_swig.la'. Stop. Did anyone find out what is the source of this error is? I just did a from-scratch rebuild of the current git revision on Ubuntu 9.10, no issues. I suspect this may have to do with a build tree left over from a prior compile. Did you just upgrade from 9.04 to 9.10 perhaps? In any case, the complete nuke-it-all-to-pristine-state command in git is: $ git clean -d -x -f Then you can bootstrap, configure, make, etc. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- (Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. "the only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn like fabulous yellow roman candles" Kerouac Twitter:rwmcgwier Active: Facebook,Myspace,LinkedIn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Cygwin major upgrade
There is now available a major upgrade to cygwin, so much so that it issues a warning when you try and upgrade to read the documentation. One of the most significant changes seems to be the swapover to gcc4 and some other significant changes to libcygwin, cygserver, etc. I am not an expert, but those running gnuradio and other things under cygwin, the move to gcc4 and some of the other stated improvements seem to me to be a win. Bob -- (Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. "the only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn like fabulous yellow roman candles" Kerouac Twitter:rwmcgwier Active: Facebook,Myspace,LinkedIn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] git
The web site server serves git. We are all down. Andreas Fink wrote: can someone give me the exact command to check out gnuradio via git? as the website is down, I'm stuck. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Linux Journal covers amateur radio
ARRL Website refers to Linux Journal: http://bit.ly/4Xce6q 73's Bob N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OT: WARNING! My trouble maker gene is firing
I am wondering if anyone in receipt of this note is friends with or knows the name of a good high level contact at the ACLU. I have a first amendment case I would like to discuss with them. Please contact me OFF LIST. Bob McGwier -- (Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. "You don't need to see the whole staircase, just take the first step.", MLK. Twitter:rwmcgwier Active: Facebook,Myspace,LinkedIn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP and radios for sale
I've got a USRP board and several radio boards which I wish to sell. USRP, compatible USB cable and original power supply: $585 LFRX DC-50 Mhz receiver (two available): $60 each LFTX (two available): $60 each FLEX 1800 transciever: $229 SMA 1.8 Ghz a"rubber duck" antennas (three available): $10 each Other wifi equipment, embedded system boards, antennas cables and accessories also for sale. All of this is in working condition. the FLEX 1800 hardly used as all. Price does not include shipping. Can be paid for in cash, money order, or paypal. Paypal fees at buyer's expense. Local pickup in Boston area can be arranged. Why am I selling it? I'd rather not. I am just short of money. If there's anyone who would hire me to work on USRP and wifi mesh & sensor projects, please email me. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Tracking a Carrier Frequency
The FFT divides the frequency range into bins. While you can do some computation based on the window function you use and how much power is in adjacent bins based on this knowledge and get a refined offset, from your proposal that sounds like it might be a step or two down the road for you rather than your first step. The gist of this is that the FFT will not be any more accurate than the bin width allows. A better plan is to allow the FFT to "get you close" , and then use the FFT bin center as the initial condition for a PLL, and then use the actual phase locked loop based carrier routines with a noise bandwidth smaller than the bin width in the FFT. This will refine the estimate of the frequency nicely by using phase lock. Bob Don Latham wrote: Hi Thomas: What you propose might work; it's a simple bang-bang servo frequency control. It's success depends a lot on the frequency characteristics of the drift you are trying to track. I have absolutely no idea about the difficulty of implementation in Gnuradio, I'm sure that depends a lot on the rest of your app. Don Thomas Hello everyone, I have an application in which I need the USRP to track a carrier frequency being received. What I mean by "tracking the carrier" is I need the USRP to stay tuned to the carrier frequency even if the carrier frequency drifts (or if the USRP's frequency reference drifts). I was thinking that I could peridically (perhaps once per second) take the FFT, find the frequency of the greatest magnitude, and re-tune the USRP to this frequency. Is there any reason why this wouldn't work, and is there a better way? It seems to me this would be a common problem, and there would already be a good solution, but I haven't been able to find one. Thanks, Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- (Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. "You don't need to see the whole staircase, just take the first step.", MLK. Twitter:rwmcgwier Active: Facebook,Myspace,LinkedIn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why not use matched filter in GMSK demodulator
This is NOT optimal. CPM and FM detector is a noncoherent detection of MSK/GMSK. The near optimal receiver for MSK and GMSK does two things: 1) it does a coherent detection of the received symbols and 2) it does something like a trellis/viterbi decode for the correct phase path through the symbols using the fact that at each symbol time the phase transition is +/- pi/2. Should you follow this type of construction, the performance of coherent detection/with "viterbi error correction" for the paths, the performance is approximately the same as QPSK with the same bit rate. Bob Shizheng Li wrote: Thank you for your reply! I think the generic receiver for CPM you mentioned is the optimal receiver for CPM and the projection onto basis functions (correlation with basis functions) is equivalent to the matched filters, am I right? Go back to the GMSK transceiver I mentioned in the file http://gnuradio.org/trac/browser/gnuradio/branches/releases/3.2/gnuradio-core/src/python/gnuradio/blks2impl/gmsk.py The modulator structure is NRZ mapping --> Gaussian filter --> FM modulator And the demodulator structure is FM demodulator --> Timing recovery --> detector I think after the FM demodulator the signal can be viewed as a PAM modulated signal and what if I add a matched filter before the timing recovery? Can I improve the BER performance? I think the matched filter can maximize the output SNR. Will it make the detector work better? Best regards, Shizheng Li On Thu, Jul 30, 2009 at 2:07 PM, Achilleas Anastasopoulos mailto:anas...@umich.edu>> wrote: There is no reason why you should not use a matched filter. However make sure you understand that a symbol-spaced MF generates sufficient statistics only for detection, ie, not for (epoch) synchronization. Also note that in the case of GMSK (CPM in general) a bank of MFs will generate colored noise. Another appropriate implementation of a front end projects the entire oversampled signal to a set of orthonormal basis functions which has the advantage of generating white noise samples for (simpler) further processing. Take a look at how a generic receiver for an arbitrary CPM is developed in http://gnuradio.org/svn/gnuradio/trunk/gr-trellis/src/examples/test_cpm.py There, the signal is first projected to its basis functions (which is calculated by a helper python application in "fsm_utils.py") to generate a sufficient statistic which is then used in conjunction with trellis decoding to do soft-decision sequence detection. What is missing though is epoch and phase syncronization (to do at some point...) Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Best Regards, Shizheng Li Ph.D. Student and Research Assistant Department of Electrical and Computer Engineering Iowa State University ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- (Co)Author: DttSP, Quiktrak, PowerSDR, GnuRadio Member: ARRL, AMSAT, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. "You don't need to see the whole staircase, just take the first step.", MLK. Twitter:rwmcgwier Active: Facebook,Myspace,LinkedIn ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
