[Discuss-gnuradio] performnace monitor runtime usage to the whole system
I've learned that sum of runtime usage values of all blocks should be and is one. But I don't think that GNU Radio uses 100 percent (= one) of CPU capability. And I think that 'one' is a portion to the capability which is allowed and allocated to the GNU Radio. In order to calculate runtime usage of each block, therefore, it can be done by multiplying usage of GNU Radio process. That is, if python running the flow graph is occupying 10 percent capability of CPU and a demodulator block is indicating 20 percent in performance monitor, actual runtime usage of the block would be 0.1 * 0.2 = 2 percent of CPU. (How to know usage of python? Maybe, `top` command in POSIX) Is what I think is correct? Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] performnace monitor runtime usage to the whole system
Daer Marcus, Thank you for your detailed answer. Now I feel I am getting to it... But, not fully, yet :) What I've said 'one' in the previous post is, you can understand with the figure: http://i.imgur.com/QG5uryH.png I've posted the same figure in another thread some days ago. Anyway, 'one' I meant is, the total sum of percent runtime. That is one and should be. Regards, Jeon. 2015-08-27 2:09 GMT+09:00 Marcus Müller : > Hi Jeon, > > But I don't think that GNU Radio uses 100 percent (= one) of CPU > capability. > > Well, that obviously depends on what you *do *with GNU Radio. > Generally, GNU Radio scales pretty well, so I'm going to reply with: > GNU Radio tries to consume as much CPU as possible. There's limiting > factors, mainly RAM access and IO that limit how much CPU can get consumed. > > As you seem to be running a receiver: There's the upper limit on how much > CPU can get used of samples coming in. You can only process as much signal > as there is. Also, things that are out of the scope of the GNU Radio > process tend to play an important rule here: The kernel has to talk to your > radio hardware, etc. > > I'm not quite sure what you refer to with "one"; do you mean the 1 that > tools like "top" would display (namely: one fully occupied CPU core > according to a more or less useful statistic; single processes can in that > metric actually have CPU loads > 1)? > > In order to calculate runtime usage of each block, therefore, it can be > done by multiplying usage of GNU Radio process. > > No. GNU Radio is a heavily multi-threaded architecture, so each block runs > in its own thread. Assuming you have a multi-core CPU, multiple threads > will run at once; one core of your CPU might be 100% occupied by the GNU > Radio block thread(s) running on it, whereas another is only 80% busy etc. > This does not allow direct mapping of "percentage of CPU load" to actual > time. > > However, the performance counters offer exactly what you seem to need: The > percentages your looking at are computed from the microseconds that each > block spends in its work function. So just look at these total times. > > I think it would be interesting to hear what you want to do, maybe we have > an idea how to measure what is of interest to you. > > Best regards, > Marcus > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] What factor determines input_item size (ninput_items)?
I am testing my OOT module in various condition of different machines. A certain block implementing a state machine requires a certain number of items or more. Thus, I've stated it in forecast(): https://gist.github.com/gsongsong/9ba1cb974a57a0861678#file-forecast-my_block-cpp In general work(), the block determines how many items it should be consume: https://gist.github.com/gsongsong/9ba1cb974a57a0861678#file-general_work-my_block-cpp With these codes, it works find with my own machinie. Ubuntu 14.04, 2 CPUs and 4 GB RAM allocated virtual machine. The host has i7-3770 and 16 GB RAM. But it fails on machine that my school gave to me for educational and research purposes. I can't tell you the exact spec. of the machine, but it apparently has a poor CPU and a lower memory space. Do these difference on machines' specs affect on ninput_items? I think they have a certain relation to each other... since GNU Radio scheduler allocates available memory over all blocks...? If so, can it be resolved if I manually set a larger memory/buffer size to GNU Radio? (If my memory is correct, I remember there's a configuration file to do it...) Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What factor determines input_item size (ninput_items)?
Dear, Marcus Sorry for telling it. It is just my mistake. The Gist codes that I've referred on the previous post were wrong. I've forgot editting codes related with the second input stream (input_items[1] and ninput_items[1]) after I removed the second input stream from a block. So, `ninput = min(ninput_items[0], ninput_items[1])` was doing some undefined behavior. And my own machine reads garbage value of ninput_items[1] as 32767, so the equation is simplified to `ninput = ninput_items[0]`. But the machine that the school gave me reads garbage value as something smaller than 240, 480, etc..., so the `to_consume` will be zero according to my state machine. After fixing the codes, I can get the same and correct behaviors and results on both machines. In short, it has nothing to do with spec. of a machine. It's just all my fault. Regards, Jeon. 2015-08-29 2:34 GMT+09:00 Marcus Müller : > Hi Jeon, > > What factor determines input_item size (ninput_items)? > > > these are two things: the input item size is the size of a single item, > and ninput_items is the amount of items that your (general_)work call sees. > > You are referring to the second thing: > > Consider this flow graph: > > A -> B -> C > > A is the upstream block (e.g. USRP source), B is your block, and C is a > downstream block (e.g. Vector sink). > > ninput_items is determined by how many samples are available. Your block B > has no influence on it; whenever the upstream block A finishes doing its > (general_)work, GNU Radio updates the number of items available in the > buffer between A and B. It then asks B whether it wants to work on this > amount of input samples. > > I see your forecast method, and it seems to do the right thing: If your > block is in the SYNC state, to output anything, it needs 480 items. If > there's no 480 input items, GNU Radio won't call your general_work, > usually. You should try printing ninput_items, to see if that's correct. > > Now, your block has two input streams. If they are somehow related, timing > and buffer sizes might actually lead to a deadlock situation. Can you give > us an overview over the whole flowgraph? > > Best regards, > Marcus > > > On 28.08.2015 19:00, Jeon wrote: > > I am testing my OOT module in various condition of different machines. > > A certain block implementing a state machine requires a certain number of > items or more. > > Thus, I've stated it in forecast(): > > https://gist.github.com/gsongsong/9ba1cb974a57a0861678#file-forecast-my_block-cpp > > In general work(), the block determines how many items it should be > consume: > > https://gist.github.com/gsongsong/9ba1cb974a57a0861678#file-general_work-my_block-cpp > > With these codes, it works find with my own machinie. > Ubuntu 14.04, 2 CPUs and 4 GB RAM allocated virtual machine. The host has > i7-3770 and 16 GB RAM. > > But it fails on machine that my school gave to me for educational and > research purposes. I can't tell you the exact spec. of the machine, but it > apparently has a poor CPU and a lower memory space. > > Do these difference on machines' specs affect on ninput_items? I think > they have a certain relation to each other... since GNU Radio scheduler > allocates available memory over all blocks...? If so, can it be resolved if > I manually set a larger memory/buffer size to GNU Radio? (If my memory is > correct, I remember there's a configuration file to do it...) > > Regards, > Jeon. > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gain and Sample Rate Setting
Note before the text: my answer might have some incorrect terminologies. I am unable to know how to set the sample rate and sps for my device. > 1. DSP rate should be an integer multiple of sampling rate You can check XCVR2450's dsp rate by `uhd_usrp_probe` command. Let's say it is 100M (not a true value!) If you set sampling rate to 30k, 100M/30k = 3.333k, not an integer 2. There is some lower limit of sampling rate Since I've never used XCVR2450, I don't know the exact value of it. But in case of LFTX, LFRX, it is 200k. If 50k that you've set is below such lower limit, you can see warning message on the console. Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Possible typos in a GRCon15 presentation?
In a presentation 'Stream Tags, PDUs, and Message Passing' by Tom Rondeau, it seems some minor typos in pp. 14-18 Assuming my knowledge is correct, add_item_tag() should use offset of output buffer, not input buffer. And get_tags_in_*() use offset of input buffer. 1. Page 16 is referring nitems_read() for add_item_tag(). 2. add_item_tag() slides contain figures of input buffer and get_items_in_*() slides contain figures of output buffer. Since I've not attended GRCon15 and judge a presentation without any speech nor context, I might just point wrong thing. Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to add a new block
Dear Bala, I'd like to know what lots of errors in basic square block are. Anyway, if you want to add a new block, please refer: http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules and gr_modtool in http://static1.squarespace.com/static/543ae9afe4b0c3b808d72acd/t/55dc8a33e4b0ab4821199b21/1440516659004/5.+braun_martin-GR_from_Scratch+2015-08-24.pdf Regards, Jeon. 2015-09-03 15:06 GMT+09:00 Bala V. : > I am getting lots of error in basic square block itself. so please give > me a step by step procedure to add a new block. > > -- > Posted via http://www.ruby-forum.com/. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Throttle block form wav files
Dear Murray Thomson, Which value did you set as a throttle. Typically 48 kHz or something... But I asked this just in case. Or this thread might help ( https://lists.gnu.org/archive/html/discuss-gnuradio/2013-08/msg00517.html ) Regards, Jeon. 2015-09-03 23:22 GMT+09:00 Murray Thomson : > Hi, > > I'm using a flow graph with no GUI to demodulate a signal. I have a > selector block that allows me to select the source of the signal between > the audio card and a wav file. I can change the source using an xmlrpc > server/client. > > If I don't use a throttle block with the wav file, the flow graph takes > all the CPU and the server/client is very slow. > If I put a throttle, I get audio underruns when using the audio card. Same > problem for a constant source. > > Can anyone please recommend a better way to do this? > > Cheers, > Murray > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] On the convolutional code performance of gr-ieee802-11
I've measured time taken by convolutional decoding in gr-ieee802-11. The module is using Punctured Convolutional Code class from IT++ library ( http://itpp.sourceforge.net/4.3.0/classitpp_1_1Punctured__Convolutional__Code.html ) I've used chrono (chrono.h, chrono) to measure time taken. You can see how I made it from the following page ( https://gist.github.com/gsongsong/7c4081f44e88a7f4407a#file-ofdm_decode_mac-cc-L252-L257 ) I've measure time with a loopback flow graph (w/o USRP; examples/wifi_loopback.grc) The result says that it takes from 5,000 to 30,000 us, which is 5 to 30 ms to decode a signal with a length of 9,000 samples (samples are either 1 or -1.) * Test environment: Ubuntu 14.04 on VMWare, 2 CPUs and 4 GB RAM allocated * Host environmetn: Windows 7 with i7-3770 3.7 GHz Since I am not familiar with error correcting codes, I have no idea how large the order of time taken is. But I think that one of the most efficient decoding algorithm is Viterbi and that IT++ must use it.' Then I can deduce that CC decoding takes a quite long time even though the algorithm (Viterbi) is very efficient. And is it a natural limitation of software decoding and SDR? Another question comes that, the commercial off the shelf (COTS) Wi-Fi device achieves really high throughput and that must be based on super faster CC decoding. Is that because COTS is using heaviliy optimized FPGA and dedicated decoding chips? Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] On the convolutional code performance of gr-ieee802-11
Thanks for your answers, Ron and Marcus. I posted this question since my module is using both Reed Solomon ( https://github.com/pjkundert/ezpwd-reed-solomon) and Convolutional Code (IT++). And I saw that CC is extremely slower than RS. Thus, I posted this question, but I made a question too short and lack some information. (Of course, this is because mechanism of RS is much much simpler than that of CC. Or it could be because ezpwd RS which I am using is optimized well, but IT++ CC is not.) To improve my OOT's performance, thus, I need to replace IT++ with other some heavily optimized library or module. I remember that...one of gr-fec, gr-dtv, gr-trellis can do this for me. Now I wonder which gr module supports some arbitrary polynomials and code rate. Specifically, I want one of three set of polynomials: - Polynomial 1 (g0 = 133, g1 = 171, g2 = 165) - Polynomial 2 (g0 = 131, g1 = 145, g2 = 133) - Polynomial 3 (g0 = 131, g1 = 171, g2 = 133) (Common: Code rate 1/4, 2/3 and 1/3, where 1/4 = repeat of code rate 1/2) The reason that I try to implement one of three is, document describing specification has some wrong points. Text says polynomial 1, but figure shows polynomial 2. One thing is hopeful: I think that polynomial 3 seems a sort of widely used one and that it has been already implemented by someone in GNU Radio, which has been heavily optimized... I hope... (While I am writing this, I've checked that gr-fec can do CC with arbitrary polynomials. gnuradio/gr-fec/examples/fecapi_cc_decodres.grc I still don't know optimization.) I will keep looking into those gr-fec, dtv, trellis modules. If someone have suggestions, I will appreciate it. Thanks a lot. Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] On the convolutional code performance of gr-ieee802-11
Thank you all of you who have answered to my questions. I am sorry for anwering too late. I'll try as many solutions as you suggested and will let you know how I will have implemented it. Regards, Jeon. 2015-09-22 23:31 GMT+09:00 Jan Krämer : > Hi all, > > my repo is here https://github.com/SpectreJan. > Though the decoder that I presented last year at GRCON is not in > there...long and shitty story. There is an optimized version of the > gr-trellis decoder in gr-celec. You have to clone gr-celec and volk-fec > from my repo. Then build volk-fec and then gr-celec. I renewed my fork of > GNURadio and am starting implementing a generic version of cc_decoder that > is cc_encoder compatible but to be honest, work is pretty slow. > > cheers and happy hacking, > Jan > > 2015-09-22 15:24 GMT+02:00 Tom Rondeau : > >> On Tue, Sep 22, 2015 at 1:52 AM, Jeon wrote: >> >>> Thanks for your answers, Ron and Marcus. >>> >>> I posted this question since my module is using both Reed Solomon ( >>> https://github.com/pjkundert/ezpwd-reed-solomon) and Convolutional Code >>> (IT++). >>> And I saw that CC is extremely slower than RS. Thus, I posted this >>> question, but I made a question too short and lack some information. >>> (Of course, this is because mechanism of RS is much much simpler than >>> that of CC. >>> Or it could be because ezpwd RS which I am using is optimized well, but >>> IT++ CC is not.) >>> >>> To improve my OOT's performance, thus, I need to replace IT++ with other >>> some heavily optimized library or module. >>> I remember that...one of gr-fec, gr-dtv, gr-trellis can do this for me. >>> >>> Now I wonder which gr module supports some arbitrary polynomials and >>> code rate. >>> Specifically, I want one of three set of polynomials: >>> >>> - Polynomial 1 (g0 = 133, g1 = 171, g2 = 165) >>> - Polynomial 2 (g0 = 131, g1 = 145, g2 = 133) >>> - Polynomial 3 (g0 = 131, g1 = 171, g2 = 133) >>> >>> (Common: Code rate 1/4, 2/3 and 1/3, where 1/4 = repeat of code rate 1/2) >>> >>> The reason that I try to implement one of three is, >>> document describing specification has some wrong points. >>> Text says polynomial 1, but figure shows polynomial 2. >>> >>> One thing is hopeful: >>> >>> I think that polynomial 3 seems a sort of widely used one >>> and that it has been already implemented by someone in GNU Radio, >>> which has been heavily optimized... I hope... >>> >>> (While I am writing this, I've checked that gr-fec can do CC with >>> arbitrary polynomials. >>> gnuradio/gr-fec/examples/fecapi_cc_decodres.grc >>> I still don't know optimization.) >>> >>> I will keep looking into those gr-fec, dtv, trellis modules. >>> If someone have suggestions, I will appreciate it. >>> >>> Thanks a lot. >>> >>> Regards, >>> Jeon. >>> >> >> >> Jeon, >> >> No, as the docs say, this block is only designed to handle rate 1/2, K=7 >> codes: >> http://gnuradio.org/doc/doxygen/classgr_1_1fec_1_1code_1_1cc__decoder.html >> >> We had some work done for GSoC last year to improve the speed of the >> Viterbi algorithm for other cases, but we have not yet merged that into the >> code. This was Jan Kramer's work, though I'm having trouble finding a link >> to his repo. >> >> Tom >> >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Is it possible to export ctrlport measurements to some text formats?
ControlPort and Performance Monitor are very good tools to measure performance of modules. But one thing that I want is, it would be perfect if I could export measurements displayed in either ControlPort or Performance Monitor in some text formats, e.g., plain text or CSV. The reason is simple. When we want to keep looking into it detail or to draw a plot with other tools, measurements in readable, editable formats are needed. Or, it might be some functionalities to print values in stdout, which I can redirect to somewhere. And I couldn't find it or enable it... Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] I am looking for uPHYLA and has anyone heard about it?
In some articles, they are referring uPHYLA which is a SDR framework like GNU Radio. But I don't see anything that tells download, installation, or documents. It first appears here. http://upcommons.upc.edu/bitstream/handle/2117/16551/110803-1569470189-45171.pdf?sequence=1 They say uPHYLA stands for universal PHY layer, well. I think it is a sort of commercial framework built by CCTTC so there's little information opened. Anyway, are there someone who have used it, or heard about it? And if you have, how do you evaluate it against GNU Radio? Regards, Jeon. P.S. I am not going to use uPHYLA even if I find a way to use it. I am just... curious about it. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Pad 'idle' items when an upstream block gives nothing
Consider a flow graph like: http://i.imgur.com/bNa6YuQ.png Message source produces a short message. Period is quite long. Thus, There should be a long idle time. I'd like to build a block 'pad idle'. The block pad a predefined sequence if the upstream block gives nothing. I think a prototype would be: https://gist.github.com/gsongsong/d40b85a76ab8e80ae468#file-gistfile1-txt-L11 By setting the number of required items to zero in forecast(), general_work() will be called even there is no items received. And general work() checks the ninput_items and if it is zero, generates some idle-padding samples/patterns. Otherwise, it just handles and passess a message/samples to downstream. But it's just my thought. There may be a couple of considerations. 1. Is it allowed to forecast zero item? And does it behave as I expect? 2. If forecasting zero item is possible, willl general_work() be called extremely frequently so that other blocks are prevented from being called? Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Pad 'idle' items when an upstream block gives nothing
Dear Marcus, Thank you for quick and detailed answer. I'll check that gr-eventstream as well as fundamentals of GNU Radio you've described. Regards, Jeon. 2015-10-21 22:23 GMT+09:00 Marcus Müller : > Hi Jeon, > > with gr-eventstream, there's something that already does the "idle time > padding": > https://github.com/osh/gr-eventstream/ > Read Tim's articles, too: > http://oshearesearch.com/tag/gr-eventstream/ > > To answer your question: > > 1. Is it allowed to forecast zero item? And does it behave as I expect? > > Well, yes, and no :) > First: your Pad Idle block is a stream source (It doesn't have a stream > input, only a message input); you don't have to implement a forecast, just > use a sync block type (or the source block type that gr_modtool offers you > to generate). > Generally, it's right to tell GNU Radio you can't produce anything with > the current input, but: > stream sources are a little special, as they *never* get input, so from > GNU Radio's perspective, the input situation can't ever change. So telling > GNU Radio you can't produce anything will make your flow graph stop. As a > side note, I've never thought about whether forecast ever gets called on a > source -- basically, what should that do? There's not ninput_required array > with nonzero length to be filled with values on a block with no inputs! > > 2. If forecasting zero item is possible, willl general_work() be called > extremely frequently so that other blocks are prevented from being called? > > There's no "preventing other blocks from being called". GNU Radio is > multithreaded, and as long as there's stuff to be done, the other blocks > will be called until all buffers have run dry. > > The point here is that you should just block in your work function if > you're a source. However, with the modern message passing alone, that's > impossible, because messages are always delivered when your work is > currently *not* running. Hence, gr-eventstream takes a queue approach, > and that works pretty well. > > Best regards, > Marcus > > > > > On 10/21/2015 02:53 PM, Jeon wrote: > > Consider a flow graph like: http://i.imgur.com/bNa6YuQ.png > > > > Message source produces a short message. Period is quite long. Thus, There > should be a long idle time. > > I'd like to build a block 'pad idle'. The block pad a predefined sequence > if the upstream block gives nothing. > > I think a prototype would be: > https://gist.github.com/gsongsong/d40b85a76ab8e80ae468#file-gistfile1-txt-L11 > > By setting the number of required items to zero in forecast(), > general_work() will be called even there is no items received. And general > work() checks the ninput_items and if it is zero, generates some > idle-padding samples/patterns. Otherwise, it just handles and passess a > message/samples to downstream. > > But it's just my thought. There may be a couple of considerations. > > 1. Is it allowed to forecast zero item? And does it behave as I expect? > 2. If forecasting zero item is possible, willl general_work() be called > extremely frequently so that other blocks are prevented from being called? > > Regards, > Jeon. > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Pad 'idle' items when an upstream block gives nothing
Dear Seth, Also thanks to your answer. To be clear, is HDLC the same thing what I've searched in google? High-Level Data Link Control (HDLC) is a bit-oriented code-transparent synchronous data link layer protocol developed by the International Organization for Standardization (ISO). The original ISO standards for HDLC are ... - Wikipedia https://en.wikipedia.org/wiki/High-Level_Data_Link_Control Anyway, thanks again. I'll get that repo and see how it works. :) Regards, Jeon. 2015-10-22 5:43 GMT+09:00 Seth Hitefield : > Jeon, > > I was talking with a co-worker and I think I got the stock HDLC > framer/deframer confused with the ones available in gr-framers on the gr-vt > repo: > https://github.com/gr-vt/gr-framers/tree/master/lib > > The framers in gr-framers do produce idle flags when there are no input > messages; I’m not sure about the stock ones. > > — Seth > > > On Oct 21, 2015, at 12.48, Seth Hitefield wrote: > > Jeon, > > You could also possibly use the HDLC framer/deframer blocks. That block > produces an idle flag when there are no message inputs. > > -- Seth > > > On 10/21/2015 11:39 AM, Jeon wrote: > > Dear Marcus, > > Thank you for quick and detailed answer. > > I'll check that gr-eventstream as well as fundamentals of GNU Radio you've > described. > > Regards, > Jeon. > > 2015-10-21 22:23 GMT+09:00 Marcus Müller : > >> Hi Jeon, >> >> with gr-eventstream, there's something that already does the "idle time >> padding": >> https://github.com/osh/gr-eventstream/ >> Read Tim's articles, too: >> http://oshearesearch.com/tag/gr-eventstream/ >> >> To answer your question: >> >> 1. Is it allowed to forecast zero item? And does it behave as I expect? >> >> Well, yes, and no :) >> First: your Pad Idle block is a stream source (It doesn't have a stream >> input, only a message input); you don't have to implement a forecast, just >> use a sync block type (or the source block type that gr_modtool offers you >> to generate). >> Generally, it's right to tell GNU Radio you can't produce anything with >> the current input, but: >> stream sources are a little special, as they *never* get input, so from >> GNU Radio's perspective, the input situation can't ever change. So telling >> GNU Radio you can't produce anything will make your flow graph stop. As a >> side note, I've never thought about whether forecast ever gets called on a >> source -- basically, what should that do? There's not ninput_required array >> with nonzero length to be filled with values on a block with no inputs! >> >> 2. If forecasting zero item is possible, willl general_work() be called >> extremely frequently so that other blocks are prevented from being called? >> >> There's no "preventing other blocks from being called". GNU Radio is >> multithreaded, and as long as there's stuff to be done, the other blocks >> will be called until all buffers have run dry. >> >> The point here is that you should just block in your work function if >> you're a source. However, with the modern message passing alone, that's >> impossible, because messages are always delivered when your work is >> currently *not* running. Hence, gr-eventstream takes a queue approach, >> and that works pretty well. >> >> Best regards, >> Marcus >> >> >> >> >> On 10/21/2015 02:53 PM, Jeon wrote: >> >> Consider a flow graph like: <http://i.imgur.com/bNa6YuQ.png> >> http://i.imgur.com/bNa6YuQ.png >> >> >> >> Message source produces a short message. Period is quite long. Thus, >> There should be a long idle time. >> >> I'd like to build a block 'pad idle'. The block pad a predefined sequence >> if the upstream block gives nothing. >> >> I think a prototype would be: >> <https://gist.github.com/gsongsong/d40b85a76ab8e80ae468#file-gistfile1-txt-L11> >> https://gist.github.com/gsongsong/d40b85a76ab8e80ae468#file-gistfile1-txt-L11 >> >> By setting the number of required items to zero in forecast(), >> general_work() will be called even there is no items received. And general >> work() checks the ninput_items and if it is zero, generates some >> idle-padding samples/patterns. Otherwise, it just handles and passess a >> message/samples to downstream. >> >> But it's just my thought. There may be a couple of considerations. >> >> 1. Is it allowed to forecast zero item? And does it behave as I expect? &g
Re: [Discuss-gnuradio] Obtaining the original (source) samples at the end of the chain (sink)
Dear Veljko Pejovic, My thought is, when you detect a certain beginning of transmission, get the offset of it. And add tag whose value is the offset. At the end of the chain, sink block has two ports, and one receives the original one, and the other receives the processed one. And compare original[offset:] with processed[:] Stream Tags: https://gnuradio.org/doc/doxygen/page_stream_tags.html Regards, Jeon. 2015-10-26 23:26 GMT+09:00 Veljko Pejovic : > Hi, > > I would like to process samples from a USRP (let's use FM > demodulation, for example) and then identify which of the original > samples correspond to a particular result at the end of the chain > (say, a beginning of a stereo transmission, a beginning of a song, > etc.). > > The problem is, in the process of filtering, demodulation and > evaluation I lose the original samples. If, at the point of detection > I go back and fetch samples from USRP, those won't be the exact > samples corresponding to the generated result. Moreover, since the > delay the original samples take to go through the processing chain is > varying and unpredictable (I learnt that in my last experiment, and > thank you Macus for explaining this), I can't just build a parallel > chain that will merely delay the samples, and then fetch those delayed > samples. > > So, what is the solution? One idea I have is to extend each block in > the processing chain with another input/output port and carry along > the original samples. Then, in the end, when I evaluate the result, I > can just take the piggybacked samples, and be sure that those are the > ones that generated the result. However, this means I have to modify > each block in the chain. Is there a more elegant solution to the > problem? > > Thanks, > > > Veljko > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Has anyone implemented your own module into real hardware?
I am sorry for posting some irrelevant question to GR, USRP nor programming. Just curious. No matter which applications, technologies, standards, (Ham, GPS, cellular, Wi-Fi, customed RF Tx/Rx, etc.) has anyone implemented your own module into real hardware? That is, transforming GNU radio flow graph into chips and circuits? As far as GNU Radio is concerned, we don't need to focus much on circuit things. We only need to focus on digital signal processing and logic/algorithm design based on C++ and Python. (Of course, some fundamental analog RF knowledge is required) However, when hardware implementation is concerned, we would get new challenges, PCB design, looking for DSP chips (from TI, etc.). Even worse, you have to design your chips, in some cases. (But I think it may never happen since lots of chips have various purposes and functionalities already) It can be easier if you co-work with others with different fields of knowledge (+ some basic and common backgrounds). But if you are a one(or a few)-man team, getting a deep and wide knowledge would be a great obstacle. Thus, I'd like to hear your experiences, difficulties, challenges and advices who have turned your GR module into a real machine. Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How can I find the cc-Files of GNU-Radio to modify or edit them?
In short, CC files are under git-cloned directory. If you modify them, re-building and installing are required. Regards, Jeon. 2015-11-04 12:48 GMT+09:00 jenspen2 : > Hello everybody, > > I'm new to Linux and GNU-Radio but I've searched the archives and faq but > I cannot find a proper answer. > I want to modify a flowchart e.g. the audio sink and want to enter the > cc-files. > > I've installed GNU-Radio following the instruction below: > http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall > > But I cannot find the cc-files. I've only found the Header-Files (.h) in > the /usr/local/include path. > > I thank you in advance. > > With best regards > Jenspen > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Compatibility with Mac OS X
With some struggles, I've finally installed GNU Radio (from the source) on Mac OS X 10.11 El Captian. Lots of things including Python and UHD were installed via Homebrew. Thrift for ControlPort, this is installed from the source. Some quick test, 1. make test It says 4 among 201 tests failed: qa_test_all qa_polar_decoder_sc qa_polar_decoder_sc_list qa_polar_encoder The rest of the tests, all passed. 2. uhd_usrp_probe I can successfully probe USRP N210 with one LFTX and one LFRX. 3. gnuradio-companion I can execute gnuradio-companion. Although it's not ready for Retina display, that's okay. I don't care. (But, I didn't run some flow graphs, yet.) Then, I think GNU Radio will work fine in the most of cases. However, I still wonder if there is a case that GNU Radio fails to run on Mac OS X 10.11. If someone having trouble with Mac OS X El Capitan, I'd like to hear your case. *Problems of OOT modules are not my concern Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Un- Subscribe
You can do that in here: https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Unsubscribe at the bottom 2015. 12. 12. 오전 6:04에 "Michael Jay Klass" 님이 작성: > please stop sending me any messages or posts > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] TypeError of enum type in my OOT module. Just one block not the others.
Dear GNU Radio Users I am building my own module but having difficulties on dealing with C++ headers and Python SWIG. I have declared my own enum type (including CMakeLists.txt and swig file) [1] and made a working block with this enum type [2]. This works fine when I test the block. On the other hand, another block [3] fails to pass test with error [4]. The key of the error is: "TypeError: in method 'encode_PSDU_make', argument 1 of type 'OP_MODE'. It's not a logical error nor an error in general_work(). It is an erroro when creating an instance (I am not sure this terminology is correct). I am very confused that both [2] and [3] have the almost same structure, but one is OK and another is problematic. Currently, I am bypassing this probleme with a workaround by declaring enum OP_MODE explicitly once again in encode_PSDU.h. But it is not looking good and I need to edit source codes two times whenever change on enum OP_MODE happens. Since these GIST codes are simplified version for brevity, if you need more information please let me know about it. Regards, Jeon. [1]: https://gist.github.com/gsongsong/3ce84f94da4d1cf6db5b6f2972d7d90c "include/myOOTmodule/utils.h, CMakeLists.txt and swig file" [2]: https://gist.github.com/gsongsong/f16582b0bc2fbedde3b3b48c75e2b3dc "An example of working block" [3]: https://gist.github.com/gsongsong/85d540823c802eaa20496a8a500c1d19 "An example of not-working block" [4] https://gist.github.com/gsongsong/913e9231aa20064a6391fe56e0caa844 "TypeError log" ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TypeError of enum type in my OOT module. Just one block not the others.
Dear Martin Braun Thanks for response enum OP_MODE is in utils.h [1]. And both working and non-working block include utils.h. Regards, Jeon. [1]: https://gist.github.com/gsongsong/3ce84f94da4d1cf6db5b6f2972d7d90c#file-utils-h 2016-06-23 1:11 GMT+09:00 Martin Braun : > Where is the enum defined? > > M > > On 06/22/2016 12:13 AM, Jeon wrote: > > Dear GNU Radio Users > > > > I am building my own module but having difficulties on dealing with C++ > > headers and Python SWIG. > > > > I have declared my own enum type (including CMakeLists.txt and swig > > file) [1] and made a working block with this enum type [2]. This works > > fine when I test the block. > > > > On the other hand, another block [3] fails to pass test with error [4]. > > The key of the error is: "TypeError: in method 'encode_PSDU_make', > > argument 1 of type 'OP_MODE'. It's not a logical error nor an error in > > general_work(). It is an erroro when creating an instance (I am not sure > > this terminology is correct). > > > > I am very confused that both [2] and [3] have the almost same structure, > > but one is OK and another is problematic. Currently, I am bypassing this > > probleme with a workaround by declaring enum OP_MODE explicitly once > > again in encode_PSDU.h. But it is not looking good and I need to edit > > source codes two times whenever change on enum OP_MODE happens. > > > > Since these GIST codes are simplified version for brevity, if you need > > more information please let me know about it. > > > > Regards, > > Jeon. > > > > [1]: https://gist.github.com/gsongsong/3ce84f94da4d1cf6db5b6f2972d7d90c > > "include/myOOTmodule/utils.h, CMakeLists.txt and swig file" > > [2]: https://gist.github.com/gsongsong/f16582b0bc2fbedde3b3b48c75e2b3dc > > "An example of working block" > > [3]: https://gist.github.com/gsongsong/85d540823c802eaa20496a8a500c1d19 > > "An example of not-working block" > > [4] https://gist.github.com/gsongsong/913e9231aa20064a6391fe56e0caa844 > > "TypeError log" > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TypeError of enum type in my OOT module. Just one block not the others.
Dear Tom, Thanks for your response. Actually, I had tried a similar approach, but that didn't work. (This may because I have too little knowledge about swig.) But this time, your advice helped me. Regards, Jeon. 2016-06-24 9:19 GMT+09:00 Tom Rondeau : > On Thu, Jun 23, 2016 at 1:39 PM, Jeon wrote: > >> Dear Martin Braun >> >> Thanks for response >> >> enum OP_MODE is in utils.h [1]. And both working and non-working block >> include utils.h. >> >> Regards, >> Jeon. >> >> [1]: >> https://gist.github.com/gsongsong/3ce84f94da4d1cf6db5b6f2972d7d90c#file-utils-h >> > > > Check the .i files. I think that enums are one thing swig won't > auto-import from the public .h files. > > Tom > > > > >> 2016-06-23 1:11 GMT+09:00 Martin Braun : >> >>> Where is the enum defined? >>> >>> M >>> >>> On 06/22/2016 12:13 AM, Jeon wrote: >>> > Dear GNU Radio Users >>> > >>> > I am building my own module but having difficulties on dealing with C++ >>> > headers and Python SWIG. >>> > >>> > I have declared my own enum type (including CMakeLists.txt and swig >>> > file) [1] and made a working block with this enum type [2]. This works >>> > fine when I test the block. >>> > >>> > On the other hand, another block [3] fails to pass test with error [4]. >>> > The key of the error is: "TypeError: in method 'encode_PSDU_make', >>> > argument 1 of type 'OP_MODE'. It's not a logical error nor an error in >>> > general_work(). It is an erroro when creating an instance (I am not >>> sure >>> > this terminology is correct). >>> > >>> > I am very confused that both [2] and [3] have the almost same >>> structure, >>> > but one is OK and another is problematic. Currently, I am bypassing >>> this >>> > probleme with a workaround by declaring enum OP_MODE explicitly once >>> > again in encode_PSDU.h. But it is not looking good and I need to edit >>> > source codes two times whenever change on enum OP_MODE happens. >>> > >>> > Since these GIST codes are simplified version for brevity, if you need >>> > more information please let me know about it. >>> > >>> > Regards, >>> > Jeon. >>> > >>> > [1]: >>> https://gist.github.com/gsongsong/3ce84f94da4d1cf6db5b6f2972d7d90c >>> > "include/myOOTmodule/utils.h, CMakeLists.txt and swig file" >>> > [2]: >>> https://gist.github.com/gsongsong/f16582b0bc2fbedde3b3b48c75e2b3dc >>> > "An example of working block" >>> > [3]: >>> https://gist.github.com/gsongsong/85d540823c802eaa20496a8a500c1d19 >>> > "An example of not-working block" >>> > [4] https://gist.github.com/gsongsong/913e9231aa20064a6391fe56e0caa844 >>> > "TypeError log" >>> > >>> > >>> > ___ >>> > Discuss-gnuradio mailing list >>> > Discuss-gnuradio@gnu.org >>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> > >>> >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] When to use message vs stream ?
Primer: http://gnuradio.org/doc/doxygen/page_msg_passing.html Though GNU Radio is 'stream' based, lots of communication systems have well-defined concepts of packet and frame. For those cases, it is sometimes useful to use message passing rather than stream. Say, publishing and subscribing a message seems easier and more convenient than passing a stream with a tag 'packet_length' and building a state machine. But then one question comes up. 'Why is stream used more frequently and widely than message passing?' Though I am not sure if it is correct, but I can guess reasons: maximum length limitation of message, scheduler, memory and handling overhead, compatibility with the built-in and existing blocks. A link for primer doesn't tell some pros and cons about stream and message. I wonder how far I can use message passing. To tell straight, I can build all my own OOT blocks using message passing and unpack it into stream to feed to USRP sink. But I think there are some reasons for not doing this. Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Getting values from external program.
Just get to the point.
I have a Bluetooth dongle connected to my PC. I can read a MAC address and
internal clock value by typing `hcitool dev` and `hcitool clock` in command
line. You can see demo in link below:
http://i.imgur.com/hbQcBQq.png
What I want is to make GNU Radio get those values/contents.
Currently, I've planned to make a source block expressed in pseudocode:
work(args) {
file_pointer = popen("hcitool dev"); // or "hcitool clock"
buf = read(fp);
val = some_char_array_manipulation(buf);
publish_message(val);
pclose(file_pointer);
}
Recently, I found that ControlPort can bridge GNU Radio and other programs.
Well, however, I am new to ControlPort (just used for PerfMonitor) and
seems more complicated than the pseudocode above.
Which would you recommend? One condition is, I need to retrieve contents
from "hcitool clock" as fast as the system (GNU Radio) can.
Regards,
Jeon.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting values from external program.
Thank you, Marcus.
I've implemented code to get MAC address(hcitool dev) in a black class
constructor.
On the other hand, implementing code to get device's clock (hcitool clock)
in start() did not work well, maybe due to my little knowledge. Anyway,
since I have to get clocks repeatedly, I think it's good to implement in
[general_]work().
Ah, my aim is to build a system that takes Bluetooth device's MAC address
and clock, and calculates frequency hopping sequence. And finally I want to
make GNU Radio react to the calculated hop sequence. (Not only sticking on
simulation).
I'll post again if further progress.
Regards,
Jeon.
On Wed, Oct 12, 2016 at 9:36 PM, Marcus Müller
wrote:
> Hi Jeon,
>
> Your use case is not what you'd use controlport for; I think you've got it
> right: use modtool to create a sync block, but set its number of in- and
> outputs to zero; override the start() method to spawn a new thread that
> contains a function which has a loop that executes the external command,
> publishes a message, and repeat.
>
> Anyway, your requirement:
>
> > One condition is, I need to retrieve contents from "hcitool clock" as
> fast as the system (GNU Radio) can.
>
> conflicts with the idea of message passing – message passing doesn't allow
> backpressure, so you'll just flood the message receiver's message input,
> and that would be useless.
>
> What do you want to do with that data? If it's something that makes sense
> to be understood as stream of samples, go for the classical GNU Radio
> source block and write the data to the output stream.
>
>
> Best regards,
>
> Marcus
> On 12.10.2016 14:16, Jeon wrote:
>
> Just get to the point.
>
> I have a Bluetooth dongle connected to my PC. I can read a MAC address and
> internal clock value by typing `hcitool dev` and `hcitool clock` in command
> line. You can see demo in link below:
>
> http://i.imgur.com/hbQcBQq.png
>
> What I want is to make GNU Radio get those values/contents.
>
> Currently, I've planned to make a source block expressed in pseudocode:
>
> work(args) {
> file_pointer = popen("hcitool dev"); // or "hcitool clock"
> buf = read(fp);
> val = some_char_array_manipulation(buf);
> publish_message(val);
> pclose(file_pointer);
> }
>
> Recently, I found that ControlPort can bridge GNU Radio and other
> programs. Well, however, I am new to ControlPort (just used for
> PerfMonitor) and seems more complicated than the pseudocode above.
>
> Which would you recommend? One condition is, I need to retrieve contents
> from "hcitool clock" as fast as the system (GNU Radio) can.
>
> Regards,
> Jeon.
>
>
> ___
> Discuss-gnuradio mailing
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting values from external program.
Not a problem, just an idea came into my head.
Since MAC address (48 bits) can be contained in one long long-type
variable, and BT clock (28 bits) can be contained in one integer-type
variable in C++, I can just send those values along a stream. If an offset
is considered, a smaller data type can be used.
Regards,
Jeon.
On Wed, Oct 12, 2016 at 9:36 PM, Marcus Müller
wrote:
> Hi Jeon,
>
> Your use case is not what you'd use controlport for; I think you've got it
> right: use modtool to create a sync block, but set its number of in- and
> outputs to zero; override the start() method to spawn a new thread that
> contains a function which has a loop that executes the external command,
> publishes a message, and repeat.
>
> Anyway, your requirement:
>
> > One condition is, I need to retrieve contents from "hcitool clock" as
> fast as the system (GNU Radio) can.
>
> conflicts with the idea of message passing – message passing doesn't allow
> backpressure, so you'll just flood the message receiver's message input,
> and that would be useless.
>
> What do you want to do with that data? If it's something that makes sense
> to be understood as stream of samples, go for the classical GNU Radio
> source block and write the data to the output stream.
>
>
> Best regards,
>
> Marcus
> On 12.10.2016 14:16, Jeon wrote:
>
> Just get to the point.
>
> I have a Bluetooth dongle connected to my PC. I can read a MAC address and
> internal clock value by typing `hcitool dev` and `hcitool clock` in command
> line. You can see demo in link below:
>
> http://i.imgur.com/hbQcBQq.png
>
> What I want is to make GNU Radio get those values/contents.
>
> Currently, I've planned to make a source block expressed in pseudocode:
>
> work(args) {
> file_pointer = popen("hcitool dev"); // or "hcitool clock"
> buf = read(fp);
> val = some_char_array_manipulation(buf);
> publish_message(val);
> pclose(file_pointer);
> }
>
> Recently, I found that ControlPort can bridge GNU Radio and other
> programs. Well, however, I am new to ControlPort (just used for
> PerfMonitor) and seems more complicated than the pseudocode above.
>
> Which would you recommend? One condition is, I need to retrieve contents
> from "hcitool clock" as fast as the system (GNU Radio) can.
>
> Regards,
> Jeon.
>
>
> ___
> Discuss-gnuradio mailing
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting values from external program.
Dear Kelly,
Your suggestion seems very helpful to me. Actually, I am having
difficulties in unstable offset between PC clock and BT clock with jitters.
I am planning to mitigate jitters by approaching it in statistical manner.
However, your suggestion seems to solve the problem from more fundamental
point.
Regards,
Jeon.
On Mon, Oct 17, 2016 at 11:16 PM, devin kelly wrote:
> Jeon,
>
> If you're just trying to get the results from 'hcitool clock', I'd look at
> the source code for hcitool and just copy that code. You'll probably have
> to add some extra #includes and link to a few extra libraries. This way
> you won't get any extra latency that's added when you create new processes.
>
> You can start looking here:
>
> http://git.kernel.org/cgit/bluetooth/bluez.git/tree/tools/hcitool.c
>
> Hope this helps,
> Devin
>
> On Sat, Oct 15, 2016 at 9:26 AM, Jeon wrote:
>
>> Thank you, Marcus.
>>
>> I've implemented code to get MAC address(hcitool dev) in a black class
>> constructor.
>>
>> On the other hand, implementing code to get device's clock (hcitool
>> clock) in start() did not work well, maybe due to my little knowledge.
>> Anyway, since I have to get clocks repeatedly, I think it's good to
>> implement in [general_]work().
>>
>> Ah, my aim is to build a system that takes Bluetooth device's MAC address
>> and clock, and calculates frequency hopping sequence. And finally I want to
>> make GNU Radio react to the calculated hop sequence. (Not only sticking on
>> simulation).
>>
>> I'll post again if further progress.
>>
>> Regards,
>> Jeon.
>>
>> On Wed, Oct 12, 2016 at 9:36 PM, Marcus Müller
>> wrote:
>>
>>> Hi Jeon,
>>>
>>> Your use case is not what you'd use controlport for; I think you've got
>>> it right: use modtool to create a sync block, but set its number of in- and
>>> outputs to zero; override the start() method to spawn a new thread that
>>> contains a function which has a loop that executes the external command,
>>> publishes a message, and repeat.
>>>
>>> Anyway, your requirement:
>>>
>>> > One condition is, I need to retrieve contents from "hcitool clock" as
>>> fast as the system (GNU Radio) can.
>>>
>>> conflicts with the idea of message passing – message passing doesn't
>>> allow backpressure, so you'll just flood the message receiver's message
>>> input, and that would be useless.
>>>
>>> What do you want to do with that data? If it's something that makes
>>> sense to be understood as stream of samples, go for the classical GNU Radio
>>> source block and write the data to the output stream.
>>>
>>>
>>> Best regards,
>>>
>>> Marcus
>>> On 12.10.2016 14:16, Jeon wrote:
>>>
>>> Just get to the point.
>>>
>>> I have a Bluetooth dongle connected to my PC. I can read a MAC address
>>> and internal clock value by typing `hcitool dev` and `hcitool clock` in
>>> command line. You can see demo in link below:
>>>
>>> http://i.imgur.com/hbQcBQq.png
>>>
>>> What I want is to make GNU Radio get those values/contents.
>>>
>>> Currently, I've planned to make a source block expressed in pseudocode:
>>>
>>> work(args) {
>>> file_pointer = popen("hcitool dev"); // or "hcitool clock"
>>> buf = read(fp);
>>> val = some_char_array_manipulation(buf);
>>> publish_message(val);
>>> pclose(file_pointer);
>>> }
>>>
>>> Recently, I found that ControlPort can bridge GNU Radio and other
>>> programs. Well, however, I am new to ControlPort (just used for
>>> PerfMonitor) and seems more complicated than the pseudocode above.
>>>
>>> Which would you recommend? One condition is, I need to retrieve contents
>>> from "hcitool clock" as fast as the system (GNU Radio) can.
>>>
>>> Regards,
>>> Jeon.
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Does OFDM Carrier Allocator add input tags to sync word?
I am modifying OFDM Carrier Allocator block for my project.
I put the source code below and also in the link: https://gist.github.com/
gsongsong/c78dfe2de979aa9a7f61e36f0eee5ba6#file-gistfile1-txt-L26-L37
int
ofdm_carrier_allocator_cvc_impl::work (int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const gr_complex *in = (const gr_complex *) input_items[0];
gr_complex *out = (gr_complex *) output_items[0];
std::vector tags;
memset((void *) out, 0x00, sizeof(gr_complex) * d_fft_len *
noutput_items);
// Copy Sync word
for (unsigned i = 0; i < d_sync_words.size(); i++) {
memcpy((void *) out, (void *) &d_sync_words[i][0], sizeof(gr_complex) *
d_fft_len);
out += d_fft_len;
}
// Copy data symbols
long n_ofdm_symbols = 0; // Number of output items
int curr_set = 0;
int symbols_to_allocate = d_occupied_carriers[0].size();
int symbols_allocated = 0;
for (int i = 0; i < ninput_items[0]; i++) {
if (symbols_allocated == 0) {
// Copy all tags associated with these input symbols onto this OFDM
symbol
get_tags_in_range(tags, 0,
nitems_read(0)+i,
nitems_read(0)+std::min(i+symbols_to_allocate, (int)
ninput_items[0])
);
for (unsigned t = 0; t < tags.size(); t++) {
add_item_tag(
0,
nitems_written(0) + n_ofdm_symbols + (n_ofdm_symbols == 0 ? 0 :
d_sync_words.size()),
tags[t].key,
tags[t].value
);
}
n_ofdm_symbols++;
}
In short: input tags are put into the position `k = nitems_written(0) +
n_ofdm_symbols + (n_ofdm_symbols == 0 ? 0 : d_sync_words.size())`
As I understand, at first run (n_ofdm_symbols = 0), it reads `n =
symbols_to_allocate` tags from input and puts it into `k =
nitems_written(0)`, which is the starting position of sync word. At second
run (n_ofdm_symbols = 1), it reads tags again, and puts it into `k =
nitems_written(0) + 1 + d_sync_words.size()`. Hence, the first group and
the second group of tags are apart by offset `d_sync_words.size()`
Is it my understanding of source code correct? If so, I wonder whether
there is a reason for placing the first group of tags onto sync word, not
onto the first data ofdm symbol. If I miss something in interpreting the
code, please let me know it.
Regards,
Jeon.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Dropped data when changing frequency dynamically using an Ettus B200
Though I am not sure about it, is https://en.wikipedia.org/wiki/Switching_time related to your problem? If it is, my suggestion is to listen to the signal with a very large bandwidth (sum of frequencies in interest), downconvert and pass it to pass filter in GNU Radio. (If USRP can support such large bandwidth) Regards, Jeon. On Wed, Dec 21, 2016 at 12:14 AM, Tom Golden wrote: > Hi All, > > I am connecting my flowgraph to a doppler prediction tool. My block > currently modifies a variable that is used to specify the center frequency > of the USRP Source block. The variable is updated every second. > > When the variable updates, I see blank data (looks like all zeros) for a > short blip when this occurs. My QT FFT and Scope sinks flatline for a > short period (subsecond). Has anyone else seen this? > > I've changed my flowgraph to leave the USRP Source alone and shift the > frequency using a signal generator and multiply block. I'm concerned about > doing this for TX. My concern is reduced performance because I'm not > transmitting at the center frequency for the USRP Sink. Is my concern > unfounded? Does anyone know if the same discontinuity for USRP Source is > present for USRP Sink? > > Thanks in advance, > -Tom > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to link an external libraries to solve ImportError: undefined symbol problem?
In my OOT module, I am using `libbluetooth-dev` library by BlueZ. I am
using a couple of APIs of it such as `hci_read_clock`. I am using
FindBluetooth cmake module (https://github.com/greatscottgadgets/ubertooth/
blob/master/host/cmake/modules/FindBLUETOOTH.cmake) and I thought that I
correctly linked the library.
find_package(Bluetooth REQUIRED)
if(NOT LIBBLUETOOTH_FOUND)
message(FATAL_ERROR "bluez (libbluetooth-dev) required")
endif()
include_directories(
${CMAKE_SOURCE_DIR}/lib
${CMAKE_SOURCE_DIR}/include
${CMAKE_BINARY_DIR}/lib
${CMAKE_BINARY_DIR}/include
${Boost_INCLUDE_DIRS}
${CPPUNIT_INCLUDE_DIRS}
${GNURADIO_ALL_INCLUDE_DIRS}
${LIBBLUETOOTH_INCLUDE_DIR}B
)
link_directories(
${Boost_LIBRARY_DIRS}
${CPPUNIT_LIBRARY_DIRS}
${GNURADIO_RUNTIME_LIBRARY_DIRS}
${LIBBLUETOOTH_LIBRARIES}
)
And I successfully built and installed my OOT module. To test it, I made a
simple flow graph but it fails to run. After some debugging, It seems that
I reached at the dead end.
Debug log:
$ /usr/local/lib/python2.7/dist-packages/my_oot_module
$ python my_oot_module_swig.py
Traceback (most recent call last):
File "my_oot_module_swig.py", line 28, in
_my_oot_module_swig = swig_import_helper()
File "my_oot_module_swig.py", line 24, in swig_import_helper
_mod = imp.load_module('_my_oot_module_swig', fp, pathname, description)
ImportError: /usr/local/lib/libgnuradio-my_oot_module.so: undefined symbol:
hci_read_clock
I wonder that the above error is C++ level error or Python level error. And
how can I fix it?
If infromation given in this post is not sufficient, please let me know it.
Regards,
Jeon.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to link an external libraries to solve ImportError: undefined symbol problem?
Dear Marcus Muller,
Your suggestion sovled my problem.
Thanks for your quick response.
Regards,
Jeon.
On Thu, Dec 22, 2016 at 1:00 AM, Marcus Müller
wrote:
> Hi Jeon,
>
> There's a "B" at the end of your "include_directories", but I guess that's
> just a copy&paste problem here – otherwise, compilation would've failed.
>
> I think you need to use "${LIBBLUETOOTH_LIBRARIES}" in the
> target_link_libraries directive in your lib/CMakeLists.txt, not in
> link_directories in your main CMakeLists.txt.
>
> Best regards,
>
> Marcus
>
> On 21.12.2016 16:48, Jeon wrote:
>
> In my OOT module, I am using `libbluetooth-dev` library by BlueZ. I am
> using a couple of APIs of it such as `hci_read_clock`. I am using
> FindBluetooth cmake module (https://github.com/greatscott
> gadgets/ubertooth/blob/master/host/cmake/modules/FindBLUETOOTH.cmake) and
> I thought that I correctly linked the library.
>
> find_package(Bluetooth REQUIRED)
> if(NOT LIBBLUETOOTH_FOUND)
> message(FATAL_ERROR "bluez (libbluetooth-dev) required")
> endif()
>
> include_directories(
> ${CMAKE_SOURCE_DIR}/lib
> ${CMAKE_SOURCE_DIR}/include
> ${CMAKE_BINARY_DIR}/lib
> ${CMAKE_BINARY_DIR}/include
> ${Boost_INCLUDE_DIRS}
> ${CPPUNIT_INCLUDE_DIRS}
> ${GNURADIO_ALL_INCLUDE_DIRS}
> ${LIBBLUETOOTH_INCLUDE_DIR}B
> )
>
> link_directories(
> ${Boost_LIBRARY_DIRS}
> ${CPPUNIT_LIBRARY_DIRS}
> ${GNURADIO_RUNTIME_LIBRARY_DIRS}
> ${LIBBLUETOOTH_LIBRARIES}
> )
>
> And I successfully built and installed my OOT module. To test it, I made a
> simple flow graph but it fails to run. After some debugging, It seems that
> I reached at the dead end.
>
> Debug log:
>
> $ /usr/local/lib/python2.7/dist-packages/my_oot_module
> $ python my_oot_module_swig.py
> Traceback (most recent call last):
> File "my_oot_module_swig.py", line 28, in
> _my_oot_module_swig = swig_import_helper()
> File "my_oot_module_swig.py", line 24, in swig_import_helper
> _mod = imp.load_module('_my_oot_module_swig', fp, pathname,
> description)
> ImportError: /usr/local/lib/libgnuradio-my_oot_module.so: undefined
> symbol: hci_read_clock
>
> I wonder that the above error is C++ level error or Python level error.
> And how can I fix it?
>
> If infromation given in this post is not sufficient, please let me know it.
>
> Regards,
> Jeon.
>
>
> ___
> Discuss-gnuradio mailing
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] trap divide error in using OFDM carrier allocator
I made a simple flow graph using OFDM Carrier Allocator. Please see the attachment. If the attachment is not available, screenshot of it can be found at http://imgur.com/v7aPL7J (Almost same as http://gnuradio.org/doc/doxygen-3.7/page_ofdm.html#ofdm_tx) When I run the flow graph, it immediately stops running. To debug, I look into `dmesg`, and it shows: *[12785.433257] traps: ofdm_carrier_al[23633] trap divide error ip:7fe08fb3f375 sp:7fe073ffe610 error:0 in libgnuradio-digital-3.7.10git.* *so.0.0.0[7fe08faa2000+f4000]* It's somewhat frustrating because I didn't modify the OFDM Carrier Allocator block. Could anyone suggest a starting point to debug it? OS is Ubuntu 14.04, kernel 3.13.0-96, 64-bit GNU Radio version is v3.7.9.2 If more information is required, please let me know it. Regards, Jeon. untitled.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] trap divide error in using OFDM carrier allocator
Ah, never mind. I declared occupied/pilot carriers and sync words incorrectly. For example, it must not be ((-3, -1, 1, 3)) but must be (-3, -1, 1, 3),). I forgot putting a comma. Regards, Jeon. On Thu, Dec 22, 2016 at 5:14 PM, Jeon wrote: > I made a simple flow graph using OFDM Carrier Allocator. Please see the > attachment. If the attachment is not available, screenshot of it can be > found at http://imgur.com/v7aPL7J > (Almost same as http://gnuradio.org/doc/doxygen-3.7/page_ofdm.html#ofdm_tx > ) > > When I run the flow graph, it immediately stops running. To debug, I look > into `dmesg`, and it shows: > > *[12785.433257] traps: ofdm_carrier_al[23633] trap divide error > ip:7fe08fb3f375 sp:7fe073ffe610 error:0 in libgnuradio-digital-3.7.10git.* > *so.0.0.0[7fe08faa2000+f4000]* > > It's somewhat frustrating because I didn't modify the OFDM Carrier > Allocator block. Could anyone suggest a starting point to debug it? > > OS is Ubuntu 14.04, kernel 3.13.0-96, 64-bit > GNU Radio version is v3.7.9.2 > If more information is required, please let me know it. > > Regards, > Jeon. > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Reed-Solomon en/decoder
I need Reed-Solomon encoder and decoder to perform RS(15, 2/4/7/11). I found that there are RS codes in *gr-fec/lib/reed-solomon.* But, I couldn't find some grc blocks implementing the library codes. In addition, I don't see *work()* function which is generally implemented in other blocks. On the other hand, I found *ccsds* keyword in *decode_rs_ccsds.c *and *encode_rs_ccsds.c* and I can find that keyword in some grc blocks, *fec_encode_ccsds, fec_decode_ccsds, ccsds_encoder_def.* But, I don't think such blocks can do what I want. Are there encoder and decoder which have been already implemented? Do I not understand how to use RS blocks which have been already implemented? Or should I implement them? Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reed-Solomon en/decoder
Thanks, Ron and Tom. But I couldn't find atsc_rs_encoder_impl.cc. Only I can find decoder. I'm using version 3.7.6.1 One thing is, I can find rs en/decoder in gnuradio/gr-atsc. Are these irrelevant with gr-dtv? When I look into repository, gr-dtv/lib/ has both encoder and decoder Currently, I am installing the newer version. Reagrds, Jeon. 2015-03-10 23:10 GMT+09:00 Tom Rondeau : > On Tue, Mar 10, 2015 at 3:35 AM, Ron Economos wrote: > >> Take a look in: >> >> gnuradio/gr-dtv/lib/atsc/atsc_rs_encoder_impl.cc >> gnuradio/gr-dtv/lib/atsc/atsc_rs_decoder_impl.cc >> >> Ron >> >> >> On 03/10/2015 12:30 AM, Jeon wrote: >> >> I need Reed-Solomon encoder and decoder to perform RS(15, 2/4/7/11). >> >> I found that there are RS codes in >> *gr-fec/lib/reed-solomon. * >> But, I couldn't find some grc blocks implementing the library codes. >> In addition, I don't see *work()* function which is generally >> implemented in other blocks. >> >> On the other hand, I found *ccsds* keyword in *decode_rs_ccsds.c *and >> *encode_rs_ccsds.c* >> and I can find that keyword in some grc blocks, >> *fec_encode_ccsds, fec_decode_ccsds, ccsds_encoder_def. * >> But, I don't think such blocks can do what I want. >> >> Are there encoder and decoder which have been already implemented? >> Do I not understand how to use RS blocks which have been already >> implemented? >> Or should I implement them? >> >> Regards, >> Jeon. >> >> > What Ron points out will probably get you going fastest. The FEC API > doesn't yet fully support the structure needed for RS coding schemes, > though it's on the to-do list. > > Tom > > > ___ > 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] Reed-Solomon en/decoder
Thank you all Bogdan and Ron. I wil try your codes. It's not important, but one general question. Why do the most of Reed-Solomon implentations exist under digital TV or broadcasting? I can guess that DVB is the typical application of RS. But, how about other wireless communications? I can see a list of wireless applications with some googling. (I'm not sure they are standards or just proposal) Regards, Jeon. 2015-03-11 14:42 GMT+09:00 Bogdan Diaconescu : > HI Jeon, you might try the RS encoder/decoder in my gr-dvbt > implementation. There are grc blocks that you can use directly after > installing gr-dvbt. > > > https://github.com/BogdanDIA/gr-dvbt > > Regards, > Bogdan > > > On Tuesday, March 10, 2015 9:33 AM, Jeon > wrote: > > > I need Reed-Solomon encoder and decoder to perform RS(15, 2/4/7/11). > > I found that there are RS codes in > *gr-fec/lib/reed-solomon.* > But, I couldn't find some grc blocks implementing the library codes. > In addition, I don't see *work()* function which is generally implemented > in other blocks. > > On the other hand, I found *ccsds* keyword in *decode_rs_ccsds.c *and > *encode_rs_ccsds.c* > and I can find that keyword in some grc blocks, > *fec_encode_ccsds, fec_decode_ccsds, ccsds_encoder_def.* > But, I don't think such blocks can do what I want. > > Are there encoder and decoder which have been already implemented? > Do I not understand how to use RS blocks which have been already > implemented? > Or should I implement them? > > Regards, > Jeon. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reed-Solomon en/decoder
Dear Bogdan, Thanks again for your answers. I am currently looking into your gr-dvbt for RS and CC. I have a couple of questions as I am not familiar with GNU Radio or Cpp. First, is it possible to use reed_solomon class in your gr-dvbt in my codes which will be written outside from gr-dvbt? I think it is possible since you've included which is outside from gr-dvbt. And I can do something very similar to it. But, will it requires some additional things. For example, should I tell something to CMakeLists.txt? Second question is, convolutional interleaver and deinterleaver are same as pure convolutional encoder and decoder? Or are they specially designed for DVB-T? Regards, Jeon. 2015-03-11 14:42 GMT+09:00 Bogdan Diaconescu : > HI Jeon, you might try the RS encoder/decoder in my gr-dvbt > implementation. There are grc blocks that you can use directly after > installing gr-dvbt. > > > https://github.com/BogdanDIA/gr-dvbt > > Regards, > Bogdan > > > On Tuesday, March 10, 2015 9:33 AM, Jeon > wrote: > > > I need Reed-Solomon encoder and decoder to perform RS(15, 2/4/7/11). > > I found that there are RS codes in > *gr-fec/lib/reed-solomon.* > But, I couldn't find some grc blocks implementing the library codes. > In addition, I don't see *work()* function which is generally implemented > in other blocks. > > On the other hand, I found *ccsds* keyword in *decode_rs_ccsds.c *and > *encode_rs_ccsds.c* > and I can find that keyword in some grc blocks, > *fec_encode_ccsds, fec_decode_ccsds, ccsds_encoder_def.* > But, I don't think such blocks can do what I want. > > Are there encoder and decoder which have been already implemented? > Do I not understand how to use RS blocks which have been already > implemented? > Or should I implement them? > > Regards, > Jeon. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to use other modules in my out-of-tree module?
In my out-of-tree module (in develop) I want to use Reed-Solomon encoder and decoder from [gr-dvbt]( https://github.com/BogdanDIA/gr-dvbt) I've successfully installed gr-dvbt. In my code, it contains: #include #include #include and variable declaration: reed_solomon::reed_solomon d_rs(rs_p, rs_m, gfpoly, phy.rs_n, phy.rs_k, phy.rs_t2 / 2, phy.rs_s, blocks); and so on. When I build my module with `make` command, the following errors appear: gr-mymodule/lib/utils.cc: In function ‘void outer_encode(char*, char*, tx_param&, phy_param&)’: gr-mymodule/lib/utils.cc:170:3: error: ‘reed_solomon’ has not been declared reed_solomon::reed_solomon d_rs(rs_p, rs_m, gfpoly, phy.rs_n, phy.rs_k, phy.rs_t2 / 2, phy.rs_s, blocks); // gr-dvbt ^ I think I need to modify CMakeLists.txt in somewhere and somehow to tell 'I will be using gr-dvbt', but I have no idea to do it. Does anyone have an idea for my problem? Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to use other modules in my out-of-tree module?
Thanks, TOm. Answer to my question. gr::dvbt::reed_solomon d_rs(...) works. No CMakeLists modification and other stuffs are needed. Regards, Jeon. 2015-03-20 22:36 GMT+09:00 Tom Rondeau : > On Fri, Mar 20, 2015 at 4:07 AM, Jeon wrote: > >> In my out-of-tree module (in develop) >> >> I want to use Reed-Solomon encoder and decoder from [gr-dvbt]( >> https://github.com/BogdanDIA/gr-dvbt) >> >> I've successfully installed gr-dvbt. >> >> In my code, it contains: >> >> #include >> #include >> #include >> >> and variable declaration: >> >> reed_solomon::reed_solomon d_rs(rs_p, rs_m, gfpoly, phy.rs_n, >> phy.rs_k, phy.rs_t2 / 2, phy.rs_s, blocks); >> >> and so on. >> >> When I build my module with `make` command, the following errors appear: >> >> gr-mymodule/lib/utils.cc: In function ‘void outer_encode(char*, >> char*, tx_param&, phy_param&)’: >> gr-mymodule/lib/utils.cc:170:3: error: ‘reed_solomon’ has not been >> declared >>reed_solomon::reed_solomon d_rs(rs_p, rs_m, gfpoly, phy.rs_n, >> phy.rs_k, phy.rs_t2 / 2, phy.rs_s, blocks); // gr-dvbt >>^ >> >> I think I need to modify CMakeLists.txt in somewhere and somehow to tell >> 'I will be using gr-dvbt', but I have no idea to do it. >> >> Does anyone have an idea for my problem? >> >> Regards, >> Jeon. >> > > I haven't tested this, just looked at the code, so not sure this is the > full answer. You're using reed_solomon as the namespace, which it's not; > it's the class name under the dvbt namespace. Try calling it like: > > dvbt::reed_solomon d_rs(...) > > You will have to link against the dvbt library in the CMakeLists.txt file > (in the lib/ directory), but this is a compiler error, not a linker error. > > Tom > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Looking for old BBN 802.11 codes
I'm looking for old BBN 802.11 codes. But, links in gnuradio.org ( http://gnuradio.org/redmine/projects/gnuradio/wiki/BBN_Technologies_Internetwork_Research_ADROIT_Project) may not seem to work. Does anyone know where I can get the codes, or does anyone have the back ups? Regrads, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Switching flow between two paths.
I will be using either Manchester code or 4B6B (something like 8B10B) coding. Only one of them should be used at a time. What I ama thinking can be drawn like the following: By using a certain variable that indicates it is Manchster or 4B6B, I think the flow works. Do you think this flow makes sense? Or is it recommended to write a cpp code that selects one of Manchester and 4B6B? Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Switching flow between two paths.
After thinking about it for a couple of days, I've decided not to use two
separated RLL blocks.
Instead, I made a block as below:
In work() function:
get_tags_in_range(tags, 0, nitems_read(0),
nitems_read(0) + ninput_items[0],
pmt::mp("rll_coding"));
RLL_CODE rll_code = (RLL_CODE)pmt::to_long(tags[0].value);
// ... omitted trivial things
switch (rll_code) {
case RLLMANCHESTER:
for(int i = 0; i < ninput_items[0]; i++) {
out[2 * i] = !!in[i];
out[2 * i + 1] = !in[i];
}
break;
case RLL4B6B:
for(int i = 0; i < ninput_items[0] / 4; i += 4) {
int rll4B = 0;
for (int j = 0; j < 4; j++) {
// make four bits into one bytes
rll4B |= (in[i + j] & 1) << j;
}
for (int j = 0; j < 6; j++) {
// put six bits corresponding to rll4B
out[6 * i + j] = !!(rll4B6B[rll4B] & (1 << j));
}
}
break;
}
// mapping definition
const char rll4B6B[16] = {
0b011100,0b101100,0b110010,0b011010,
0b101010,0b110001,0b011001,0b101001,
0b100110,0b010110,0b001110,0b100011,
0b010011,0b100101,0b010101,0b001101
};
If the code are not formatted well and hard to read, please refer:
https://gist.github.com/gsongsong/f3e34991a55f29dac5d2
There might be some syntax violation and variable definitions missing, I
apologize for that.
And please note that each in[i] is either 0b or 0b0001.
By using a tag, RLL coding scheme are not changing during the stream.
Currently, I haven't built it and tested yet.
What do you think of it?
I will make some notes after build and test the entire system.
Regrads,
Jeon.
2015-03-26 23:17 GMT+09:00 Kevin Reid :
> On Mar 25, 2015, at 2:15, Marcus Müller wrote:
>
> > source -+--> custom_block0 ---> encoder0 ---> add -->
> > +--> custom_block1 ---> encoder1 --^
> >
> > you'd need to implement custom_block in python or C++, that would either
> > pass through items, just like the block does that comes out of
> > gr_modtool add -l python -t sync
> > or set the output items to 0. You'd toggle that behavior exactly at the
> > sample that you get a tag.
>
> Note that if you don't actually need the switch to happen at a specific
> point in the stream, but you still want the switch to be atomic (guaranteed
> not to drop or repeat any items), the existing multiply_matrix block can do
> the switching in this flowgraph: it would be configured with one input and
> two outputs, and setting the matrix to either [[0, 1]] or [[1, 0]].
>
> (Of course, the disadvantage of either of these strategies is that you're
> paying the CPU cost of both encoders all of the time.)
>
> --
> Kevin Reid <http://switchb.org/kpreid/>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Specifying build dependencies of other OOT modules in my OOT module
I am writing my own module. In the module, I am using gr-dvbt (https://github.com/BogdanDIA/gr-dvbt) to perform Reed-Solomon en/decoding. In this situation, how to tell 'I am using gr-dvbt' to cmake and make? I've found some clues in other OOT modules: set(GR_REQUIRED_COMPONENTS RUNTIME FILTER FFT PMT DIGITAL) Keywords FFT, DIGITAL seems to indicate gr-fft, gr-digital, respectively. However, I have no idea where the keywords FFT and DIGITAL come from which part of gr-fft and gr-digital. I am suspecting that two files, include/api.h and swig/_swig.i. (But I might be wrong.) is either FFT or DIGITAL In include/api.h: #define _API In _swig.i: #define _API According to my guess, I put: set(GR_REQUIRED_COMPONENTS ... omitted ... DVBT) But after building and installing, I got an error in the following step: $ python >>> import myOOTmodule ImportError: /usr/local/lib/libgnuradio-myOOTmodule.so: undefined symbol: _ZN2gr4dvbt12reed_solomonC1E Am I guessing wrong? Or, gr-dvbt are not available to be used by other OOT modules? Can it be solved by modifying 1) my code or 2) gr-dvbt? Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Switching flow between two paths.
Dear, Marcus
Here's my codes
include/rll.h: https://gist.github.com/gsongsong/07e28c797bb65572982b
lib/rll_impl.h: https://gist.github.com/gsongsong/615649f628262c44c8cf
lib/rll_impl.cc: https://gist.github.com/gsongsong/14e7bdab27216bbe7a17
Please excuses some typos and syntax violation if any.
Regards,
Jeon.
2015-03-27 16:30 GMT+09:00 Marcus Müller :
> Hi Jeon,
>
> could you paste the whole C++ file to the gist?
> Basically, what I suspect is that you're not checking whether
> get_tags_in_range() produced a tag at all, or/and might have an error in
> your state machine that stores the "current" coder.
>
> Greetings,
> Marcus
>
>
> On 03/27/2015 06:23 AM, Jeon wrote:
>
> After thinking about it for a couple of days, I've decided not to use
> two separated RLL blocks.
> Instead, I made a block as below:
>
> In work() function:
>
> get_tags_in_range(tags, 0, nitems_read(0),
> nitems_read(0) + ninput_items[0],
> pmt::mp("rll_coding"));
> RLL_CODE rll_code = (RLL_CODE)pmt::to_long(tags[0].value);
>
> // ... omitted trivial things
>
> switch (rll_code) {
> case RLLMANCHESTER:
> for(int i = 0; i < ninput_items[0]; i++) {
> out[2 * i] = !!in[i];
> out[2 * i + 1] = !in[i];
> }
> break;
> case RLL4B6B:
> for(int i = 0; i < ninput_items[0] / 4; i += 4) {
> int rll4B = 0;
> for (int j = 0; j < 4; j++) {
> // make four bits into one bytes
> rll4B |= (in[i + j] & 1) << j;
> }
> for (int j = 0; j < 6; j++) {
> // put six bits corresponding to rll4B
> out[6 * i + j] = !!(rll4B6B[rll4B] & (1 << j));
> }
> }
> break;
> }
>
> // mapping definition
>
> const char rll4B6B[16] = {
> 0b011100,0b101100,0b110010,0b011010,
> 0b101010,0b110001,0b011001,0b101001,
> 0b100110,0b010110,0b001110,0b100011,
> 0b010011,0b100101,0b010101,0b001101
> };
>
> If the code are not formatted well and hard to read, please refer:
> https://gist.github.com/gsongsong/f3e34991a55f29dac5d2
> There might be some syntax violation and variable definitions missing, I
> apologize for that.
> And please note that each in[i] is either 0b or 0b0001.
>
> By using a tag, RLL coding scheme are not changing during the stream.
> Currently, I haven't built it and tested yet.
>
> What do you think of it?
>
> I will make some notes after build and test the entire system.
>
> Regrads,
> Jeon.
>
> 2015-03-26 23:17 GMT+09:00 Kevin Reid :
>
>> On Mar 25, 2015, at 2:15, Marcus Müller wrote:
>>
>> > source -+--> custom_block0 ---> encoder0 ---> add -->
>> > +--> custom_block1 ---> encoder1 --^
>> >
>> > you'd need to implement custom_block in python or C++, that would either
>> > pass through items, just like the block does that comes out of
>> > gr_modtool add -l python -t sync
>> > or set the output items to 0. You'd toggle that behavior exactly at the
>> > sample that you get a tag.
>>
>> Note that if you don't actually need the switch to happen at a specific
>> point in the stream, but you still want the switch to be atomic (guaranteed
>> not to drop or repeat any items), the existing multiply_matrix block can do
>> the switching in this flowgraph: it would be configured with one input and
>> two outputs, and setting the matrix to either [[0, 1]] or [[1, 0]].
>>
>> (Of course, the disadvantage of either of these strategies is that you're
>> paying the CPU cost of both encoders all of the time.)
>>
>> --
>> Kevin Reid <http://switchb.org/kpreid/>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
>
> ___
> Discuss-gnuradio mailing
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Switching flow between two paths.
Dear, Marcus
Thank you for your advice.
I will test it as soon as possible after fixing another problem in the
entire module (not related with RLL.)
And will report the result on the discuss-gnuradio.
Regards,
Jeon.
2015-03-28 21:50 GMT+09:00 Marcus Müller :
> Hi Jeon,
>
> this looks like good code; it's an excellent design choice to use a tagged
> stream block here, where you'd want GNU Radio to make sure you get the
> whole "packet" that you need to encode into a single work call.
>
> I think it should work; of course, I'm not your computer ;) . With the
> existing tagged stream block framework, it should be quite straightforward
> to define a python test case for this, so I'd encourage you to actually
> test it!
>
> Best regards,
> Marcus
>
>
> On 03/27/2015 04:16 PM, Jeon wrote:
>
>Dear, Marcus
>
> Here's my codes
>
> include/rll.h: https://gist.github.com/gsongsong/07e28c797bb65572982b
> lib/rll_impl.h: https://gist.github.com/gsongsong/615649f628262c44c8cf
> lib/rll_impl.cc: https://gist.github.com/gsongsong/14e7bdab27216bbe7a17
>
> Please excuses some typos and syntax violation if any.
>
> Regards,
> Jeon.
>
> 2015-03-27 16:30 GMT+09:00 Marcus Müller :
>
>> Hi Jeon,
>>
>> could you paste the whole C++ file to the gist?
>> Basically, what I suspect is that you're not checking whether
>> get_tags_in_range() produced a tag at all, or/and might have an error in
>> your state machine that stores the "current" coder.
>>
>> Greetings,
>> Marcus
>>
>>
>> On 03/27/2015 06:23 AM, Jeon wrote:
>>
>> After thinking about it for a couple of days, I've decided not to use
>> two separated RLL blocks.
>> Instead, I made a block as below:
>>
>> In work() function:
>>
>> get_tags_in_range(tags, 0, nitems_read(0),
>> nitems_read(0) + ninput_items[0],
>> pmt::mp("rll_coding"));
>> RLL_CODE rll_code = (RLL_CODE)pmt::to_long(tags[0].value);
>>
>> // ... omitted trivial things
>>
>> switch (rll_code) {
>> case RLLMANCHESTER:
>> for(int i = 0; i < ninput_items[0]; i++) {
>> out[2 * i] = !!in[i];
>> out[2 * i + 1] = !in[i];
>> }
>> break;
>> case RLL4B6B:
>> for(int i = 0; i < ninput_items[0] / 4; i += 4) {
>> int rll4B = 0;
>> for (int j = 0; j < 4; j++) {
>> // make four bits into one bytes
>> rll4B |= (in[i + j] & 1) << j;
>> }
>> for (int j = 0; j < 6; j++) {
>> // put six bits corresponding to rll4B
>> out[6 * i + j] = !!(rll4B6B[rll4B] & (1 << j));
>> }
>> }
>> break;
>> }
>>
>> // mapping definition
>>
>> const char rll4B6B[16] = {
>> 0b011100,0b101100,0b110010,0b011010,
>> 0b101010,0b110001,0b011001,0b101001,
>> 0b100110,0b010110,0b001110,0b100011,
>> 0b010011,0b100101,0b010101,0b001101
>> };
>>
>> If the code are not formatted well and hard to read, please refer:
>> https://gist.github.com/gsongsong/f3e34991a55f29dac5d2
>> There might be some syntax violation and variable definitions missing, I
>> apologize for that.
>> And please note that each in[i] is either 0b or 0b0001.
>>
>> By using a tag, RLL coding scheme are not changing during the stream.
>> Currently, I haven't built it and tested yet.
>>
>> What do you think of it?
>>
>> I will make some notes after build and test the entire system.
>>
>> Regrads,
>> Jeon.
>>
>> 2015-03-26 23:17 GMT+09:00 Kevin Reid :
>>
>>> On Mar 25, 2015, at 2:15, Marcus Müller
>>> wrote:
>>>
>>> > source -+--> custom_block0 ---> encoder0 ---> add -->
>>> > +--> custom_block1 ---> encoder1 --^
>>> >
>>> > you'd need to implement custom_block in python or C++, that would
>>> either
>>> > pass through items, just like the block does that comes out of
>>> > gr_modtool add -l python -t sync
>>> > or set the output items to 0. You'd toggle that behavior exactly at the
>>> > sample that you get a tag.
>>>
>>> Note that if you don't actually need the switch to happen at a specific
>>> point in the stream, but you still want the switc
[Discuss-gnuradio] Swig and python import problem due to other out-of-tree modules used in my out-of-tree module
I've asked this question before. But there are lots of ambiguity and
uncertainty. Thus, this is the clarification.
I am using Reed-Solomon En/decoder in my own OOT module sources. The
Reed-Solomon en/decoder are implemented in [gr-dvbt](
https://github.com/BogdanDIA/gr-dvbt).
Important codes are:
[include/reed_solomon.h](
https://github.com/BogdanDIA/gr-dvbt/blob/master/include/dvbt/reed_solomon.h
)
[include/reed_solomon_enc.h](
https://github.com/BogdanDIA/gr-dvbt/blob/master/include/dvbt/reed_solomon_enc.h
)
[lib/reed_solomon.cc](
https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon.cc)
[lib/reed_solomon_end_impl.h](
https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon_enc_impl.h
)
[lib/reed_solomon_end_impl.cc](
https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon_enc_impl.cc
)
I've built and installed my module. But when I import my module in Python
for tests, error occurs:
>>> import myOOTmodule
Traceback (most recent call last):
File "", line 1, in
File
"/usr/local/lib/python2.7/dist-packages/myOOTmodule/__init__.py", line 51,
in
from myOOTmodule_swig import *
File
"/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
line 28, in
_myOOTmodule_swig = swig_import_helper()
File
"/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
line 24, in swig_import_helper
_mod = imp.load_module('_myOOTmodule_swig', fp, pathname,
description)
ImportError: /usr/local/lib/libgnuradio-myOOTmodule.so: undefined
symbol: _ZN2gr4dvbt12reed_solomonC1E
You can also see the error above in [gist](
https://gist.github.com/gsongsong/e07883959f6a339b5d78)
The problem is that the above error occurs since I am using
gr:dvbt::reed_solomon, which is neither in GNU Radio source tree nor in my
module.
I don't know the exact reason for this. But in my guess...
It seems that myOOTmodule thinks gr::dvbt::reed_solomon is a part of
myOOTmodule itself. But there is no declaration and implementation and it
causes the error.
Or myOOTmodule has no idea where to import gr:dvbt:reed_solomon.
Another hypothesis is that, an OOT module cannot use other OOT modules (in
swig-python?). I'm not sure about it. Or, there is a way to do this, but I
just don't know about it.
Regards,
Jeon.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Swig and python import problem due to other out-of-tree modules used in my out-of-tree module
Dear Douglas,
Thank you for your answer.
Unfortunately, I couldn't find other modules and projects that use gr-dvbt
in their codes. Thus, I feel sort of being frustrated :(
Or maybe I can handle it if you give me some details about CMakeLists. As
you know, there are a number of CmakeLists in the project. Can it be done
by modifying and fixing CMakeLists.txt under swig, python or project root
directory?
As I am searching the web and archives, I've just found [this thread](
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-12/msg00223.html).
Though I've not read carefully it yet and it's been two years since that
thread was posted, I think it might be relevant with my case.
If you have any better suggestions, I will be very thankful to it.
Also, I will report my progress as soon as possible.
Regards,
Jeon.
2015-03-31 0:22 GMT+09:00 Anderson, Douglas J. :
> Jeon,
>
> I've recently dealt with a similar problem. Chances are that if things
> are building and installing correctly but the error is in the SWIG import,
> the actual problem lies in your CMakeLists.txt... seems like the C++ linker
> is being smart enough to get things linked correctly but SWIG needs you to
> be a bit more explicit.
>
> Is there another project that includes Reed-Solomon that you can
> reference? See what changes they made to their CMakesLists.txt to get SWIG
> to be happy.
>
> -Doug
>--
> *From:* discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org
> [discuss-gnuradio-bounces+danderson=its.bldrdoc@gnu.org] on behalf of
> Jeon [sjeon87+gnura...@gmail.com]
> *Sent:* Sunday, March 29, 2015 10:25 PM
> *To:* Discuss GNU Radio mailing list
> *Subject:* [Discuss-gnuradio] Swig and python import problem due to other
> out-of-tree modules used in my out-of-tree module
>
>I've asked this question before. But there are lots of ambiguity and
> uncertainty. Thus, this is the clarification.
>
> I am using Reed-Solomon En/decoder in my own OOT module sources. The
> Reed-Solomon en/decoder are implemented in [gr-dvbt](
> https://github.com/BogdanDIA/gr-dvbt).
>
> Important codes are:
>
> [include/reed_solomon.h](
> https://github.com/BogdanDIA/gr-dvbt/blob/master/include/dvbt/reed_solomon.h
> )
> [include/reed_solomon_enc.h](
> https://github.com/BogdanDIA/gr-dvbt/blob/master/include/dvbt/reed_solomon_enc.h
> )
> [lib/reed_solomon.cc](
> https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon.cc)
> [lib/reed_solomon_end_impl.h](
> https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon_enc_impl.h
> )
> [lib/reed_solomon_end_impl.cc](
> https://github.com/BogdanDIA/gr-dvbt/blob/master/lib/reed_solomon_enc_impl.cc
> )
>
> I've built and installed my module. But when I import my module in Python
> for tests, error occurs:
>
> >>> import myOOTmodule
> Traceback (most recent call last):
> File "", line 1, in
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/__init__.py", line 51,
> in
> from myOOTmodule_swig import *
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
> line 28, in
> _myOOTmodule_swig = swig_import_helper()
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
> line 24, in swig_import_helper
> _mod = imp.load_module('_myOOTmodule_swig', fp, pathname,
> description)
> ImportError: /usr/local/lib/libgnuradio-myOOTmodule.so: undefined
> symbol: _ZN2gr4dvbt12reed_solomonC1E
>
> You can also see the error above in [gist](
> https://gist.github.com/gsongsong/e07883959f6a339b5d78)
>
> The problem is that the above error occurs since I am using
> gr:dvbt::reed_solomon, which is neither in GNU Radio source tree nor in my
> module.
>
> I don't know the exact reason for this. But in my guess...
> It seems that myOOTmodule thinks gr::dvbt::reed_solomon is a part of
> myOOTmodule itself. But there is no declaration and implementation and it
> causes the error.
> Or myOOTmodule has no idea where to import gr:dvbt:reed_solomon.
>
> Another hypothesis is that, an OOT module cannot use other OOT modules
> (in swig-python?). I'm not sure about it. Or, there is a way to do this,
> but I just don't know about it.
>
> Regards,
> Jeon.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Swig and python import problem due to other out-of-tree modules used in my out-of-tree module
Dear, Marcus.
Thanks, it's very helpful. But, stil somethings unresolved.
What I've done is:
In CMakeLists.txt of root:
find_package(DVBT)
if (NOT DVBT_FOUND) /* ommited */ endif()
include_directories(
/* omitted */
${DVBT_INCLUDE_DIR}
)
Add cmake/Modules/[FindDVBT.cmake](
https://gist.github.com/gsongsong/49ec2cf84d7907c7ceb0). It's quite long.
And I found that shared object (so) is libgnuradio-dvbt.so.
In lib/CMakeLists.txt:
target_link_libraries(gnuradio-mymodule ${DVBT_LIBRARIES})
A result of build and installation is:
pkg_check_modules(PC_DVBT gnuradio-dvbt): returns package
'gnuradio-dvbt' not found
Although I've changed gnuradio-dvbt to gr-dvbt, dvbt gnuradio_dvbt,
gr_dvbt, libgnuradio-dvbt and other possible combinations, nothings
different.
But DVBT_LIBRARY returns /usr/local/lib/libgnuradio-dvbt.so and
DVBT_INCLUDE_DIR returns /usr/local/include.
I think this part is correct.
And in python:
>>> import mymodule
Traceback (most recent call last):
File "", line 1, in
File
"/usr/local/lib/python2.7/dist-packages/myOOTmodule/__init__.py", line 51,
in
from myOOTmodule_swig import *
File
"/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
line 28, in
_myOOTmodule_swig = swig_import_helper()
File
"/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
line 24, in swig_import_helper
_mod = imp.load_module('_myOOTmodule_swig', fp, pathname,
description)
ImportError: /usr/local/lib/libgnuradio-myOOTmodule.so: undefined
symbol: _ZN2gr4dvbt12reed_solomonC1E
It is the same as the previous.
.
After some googling and searching, I found that gr-dvbt is not present in
'pkg-config --list-all'.
I think it would be a bit relevant to this problem.
If it is the case, I'd better think to use IT++ Reed Solomon.
I'll let you know if I have further progress.
Regards,
Jeon.
2015-03-31 18:32 GMT+09:00 Marcus Müller :
> Hi Jeon,
>
> typically, you'd call a FindSomething function in the root CMakeList
>
> find_library(GR_DVBT_LIBRARY
> NAMES
> gnuradio-dvbt
> PATHS
> /usr/lib
> /usr/local/lib
> /opt/local/lib
> /sw/lib
> )
> or so. I guess "gnuradio-dvbt.so" should be the name of the installed
> gr-dvbt library -- please verify that this is correct.
>
> Then add the resulting library name to the target_link_libraries
> directive in lib/CMakeList.txt:
>
> target_link_libraries( ${Boost_LIBRARIES}
> ${GNURADIO_ALL_LIBRARIES} ${GR_DVBT_LIBRARY})
> and
> target_link_libraries(test- ${Boost_LIBRARIES}
> ${GNURADIO_ALL_LIBRARIES} ${GR_DVBT_LIBRARY} )
>
> How is CMake able to find the headers you need to compile your module?
> If you have written functionality to detect these headers, you can
> probably do the same for the compiled gr-dvbt libraries.
>
> Greetings,
> Marcus
>
>
>
> On 03/31/2015 08:11 AM, Jeon wrote:
> >
> > Or maybe I can handle it if you give me some details about CMakeLists.
> > As you know, there are a number of CmakeLists in the project. Can it
> > be done by modifying and fixing CMakeLists.txt under swig, python or
> > project root directory?
>
>
> ___
> 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] Swig and python import problem due to other out-of-tree modules used in my out-of-tree module
Dear, Marcus.
Struggling for this, but still the problem is not solved.
AND ONE THING I'VE FOUND IS:
>>> import dvbt
>>> dir(dvbt)
There are no reed_solomon, reed_solomon_make, reed_solomon_sptr,
reed_solomon_sptr_swigregister and reed_solomon_swigregister. But, there
are reed_solomon_end_XX and reed_solomon_dec_XX. (XX is _make, _sptr things)
Do you think this has something to do with my probelm? I think there is no
reed_solomon_(...) module, thus I can't use gr:dvbt::reed_solomon in
MYMODULE.
Can it be solved if I modify gr-dvbt to have _make, _sptr, _swigregister
things? But, I wonder if it is a good way to modify other's sources. On the
contrary, it might be good if I can contribute to the gr-dvbt sources.
Or is it irrelevant with my problem?
Anyway, I'll try what I am thinking til some respones recevied.
Regards,
Jeon.
2015-03-31 23:50 GMT+09:00 Marcus Müller :
> Hi Jeon,
>
> This looks very proper, but since gr-dvbt doesn't supply a pkgconfig (.pc)
> file, you can't use pkg_check_modules; the raw find_library call you use
> should work, though.
>
> also, you set DVBT_LIBRARY, so you'll have to use
> target_link_libraries(gnuradio-mymodule ${DVBT_LIBRARY})
> (notice the singular LIBRARY).
>
> Greetings,
> Marcus
>
> On 03/31/2015 04:37 PM, Jeon wrote:
>
> Dear, Marcus.
>
> Thanks, it's very helpful. But, stil somethings unresolved.
>
> What I've done is:
>
> In CMakeLists.txt of root:
>
> find_package(DVBT)
> if (NOT DVBT_FOUND) /* ommited */ endif()
> include_directories(
> /* omitted */
> ${DVBT_INCLUDE_DIR}
> )
>
> Add cmake/Modules/[FindDVBT.cmake](
> https://gist.github.com/gsongsong/49ec2cf84d7907c7ceb0). It's quite long.
> And I found that shared object (so) is libgnuradio-dvbt.so.
>
> In lib/CMakeLists.txt:
>
> target_link_libraries(gnuradio-mymodule ${DVBT_LIBRARIES})
>
> A result of build and installation is:
>
> pkg_check_modules(PC_DVBT gnuradio-dvbt): returns package
> 'gnuradio-dvbt' not found
>
> Although I've changed gnuradio-dvbt to gr-dvbt, dvbt gnuradio_dvbt,
> gr_dvbt, libgnuradio-dvbt and other possible combinations, nothings
> different.
>
> But DVBT_LIBRARY returns /usr/local/lib/libgnuradio-dvbt.so and
> DVBT_INCLUDE_DIR returns /usr/local/include.
> I think this part is correct.
>
> And in python:
>
> >>> import mymodule
> Traceback (most recent call last):
> File "", line 1, in
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/__init__.py", line 51,
> in
> from myOOTmodule_swig import *
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
> line 28, in
> _myOOTmodule_swig = swig_import_helper()
> File
> "/usr/local/lib/python2.7/dist-packages/myOOTmodule/myOOTmodule_swig.py",
> line 24, in swig_import_helper
> _mod = imp.load_module('_myOOTmodule_swig', fp, pathname,
> description)
> ImportError: /usr/local/lib/libgnuradio-myOOTmodule.so: undefined
> symbol: _ZN2gr4dvbt12reed_solomonC1Eiiii
>
> It is the same as the previous.
>
> .....
>
> After some googling and searching, I found that gr-dvbt is not present
> in 'pkg-config --list-all'.
> I think it would be a bit relevant to this problem.
> If it is the case, I'd better think to use IT++ Reed Solomon.
>
> I'll let you know if I have further progress.
>
> Regards,
> Jeon.
>
>
>
> 2015-03-31 18:32 GMT+09:00 Marcus Müller :
>
>> Hi Jeon,
>>
>> typically, you'd call a FindSomething function in the root CMakeList
>>
>> find_library(GR_DVBT_LIBRARY
>> NAMES
>> gnuradio-dvbt
>> PATHS
>> /usr/lib
>> /usr/local/lib
>> /opt/local/lib
>> /sw/lib
>> )
>> or so. I guess "gnuradio-dvbt.so" should be the name of the installed
>> gr-dvbt library -- please verify that this is correct.
>>
>> Then add the resulting library name to the target_link_libraries
>> directive in lib/CMakeList.txt:
>>
>> target_link_libraries( ${Boost_LIBRARIES}
>> ${GNURADIO_ALL_LIBRARIES} ${GR_DVBT_LIBRARY})
>> and
>> target_link_libraries(test- ${Boost_LIBRARIES}
>> ${GNURADIO_ALL_LIBRARIES} ${GR_DVBT_LIBRARY} )
>>
>> How is CMake able to find the headers you need to compile your module?
>> If you have written functionality to detect these headers, you can
>> probably do the same for the compiled gr-dvbt libraries.
>
[Discuss-gnuradio] Why are malloc_ in gr::fft?
It's not a big deal, but I'm just curious. Why are malloc functions, malloc_complex, malloc_double, malloc_float in gr::fft ? I think memory allocating functions can be used in various purposes, not only in FFT. Is it just a workaround that there are no more proper places (gr::analog, gr::digital, gr::blocks...) for malloc? Or, is it not just a simple memory allocated array, but a special array that something happens when items are put into the array? Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why are malloc_ in gr::fft?
Marcus, Thank you for your detailed explanation. Now, I can see that I can use an ordinary malloc if there is no specially aligned memory. Thanks. 2015-04-23 17:53 GMT+09:00 Marcus Müller : > Hi Jeon, > > you just `malloc(...)` when you need to; why would you, in general, need > GNU Radio to wrap that simple libc call, especially since there's calloc? > > Or, is it not just a simple memory allocated array, > but a special array that something happens when items are put into the > array? > > It's special. > gr::fft needs these fftw_mallocs because FFTW (which is the FFT library > underneath) expects specially aligned memory, and therefore offers it's own > fftwf_malloc; thus, we need to wrap this up. It's an FFTW-speciality, and > shouldn't be used for different things than memory that FFTW works on. > When you work with fftw (which is a C library) in C++, you'll notice that > C++ is a bit more strict than C when it comes to pointer types, and you > have to cast around the pointer type just to get it working. Since that is > a bit ugly to do in-line, there's these malloc abstractions that you've > mentioned. > > Generally, as we try to write beautiful C++, we don't malloc much -- new[] > might be your friend if you actually want to work with arrays. > However, GNU Radio is a bit doomed when it comes to having beautiful, > type-safe code, because the core concept of gr_buffer basically is that > buffers between blocks are just memory regions, not data of a specific type > -- hence all the "ugly" pointer casting that happens in about every work(). > > There's a lot of places where `malloc` is really handy in our code, for > example in the DVB decoders, where structures for decoding need to > dynamically be allocated, or in the GUIs, where you often just want to have > a bit of memory representing your framebuffer. But as a rule of thumb, you > should try to avoid dynamically allocating memory manually (using malloc) > as much as possible -- it's just one of the most popular causes for > hard-to-debug bugs. > > It's often practical to use `std::vector > myvector(number_of_elements)` instead -- it does the allocation for you, > allows for resizing, and you can, just like with malloc, get the address of > the first element ( `&(myvector[0])` ) . As a bonus, `myvector[x]` always > actually has the right type, and you don't need to first cast the return > value of malloc to a pointer of whatever you want to have. > If you don't need the resizing of `std::vector`, just the dynamic > allocation, `std::array` is also awesome; both being STL containers offer a > great deal of functionality that you'd have to implement yourself if you > just go a C-style array in some malloc'ed memory. > > Best regards, > Marcus > > > On 04/23/2015 10:18 AM, Jeon wrote: > > It's not a big deal, but I'm just curious. > > Why are malloc functions, malloc_complex, malloc_double, malloc_float in > gr::fft ? > I think memory allocating functions can be used in various purposes, not > only in FFT. > > Is it just a workaround that > there are no more proper places (gr::analog, gr::digital, gr::blocks...) > for malloc? > > Or, is it not just a simple memory allocated array, > but a special array that something happens when items are put into the > array? > > > Regards, > Jeon. > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Detecting unipolar and repeating preamble on wired communications?
I am trying to implement a preamble detection. A couple of things that, I'm not using wireless communication but wired communication. And also, I'm not using a bipolar signal, but a unipolar signal. (Bipolar: a signal swings between +A volts (or amperes) and -A volts; Ethernet, USB, Wi-Fi, ... are using bipolar signals, Unipolar: a signal swings between +A volts and 0 volts) Using a unipolar signal, I am having a difficulties on determining whether a signal has a repetition. A preamble has a typical form of 1, 0, 1, 0, 1, 0, 1, 0, (and data payload follows) and it is mapped into a real signal and received at a receiver: +A+n, n, +A+n, n, +A+n, n, +A+n, n, (and data payload follows) (n is very small noise and fluctuation, n can be either negative or positive) I think an optical fiber communication might use unipolar signalling, but I'm not sure. Is there anyone already implemented unipolar preamble detection succesffully, or could anyone give me some hints on mathematical approach or something? Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Detecting unipolar and repeating preamble on wired communications?
Dear, Sylvain Munaut, Thanks.I got a hint from your answer. What about using moving average instead LPF? I think moving average (MA) is much simpler than LPF if computational cost is considered. But, another issue is, precision on estimation A and A/2. In that case, LPF would be better. Anyway, I will do applying either LPF and MA on my flow graph. Thanks. Regards, Jeon. 2015-05-05 16:27 GMT+09:00 Sylvain Munaut <246...@gmail.com>: > Hi, > > > (Bipolar: a signal swings between +A volts (or amperes) and -A volts; > > Ethernet, USB, Wi-Fi, ... are using bipolar signals, > > Unipolar: a signal swings between +A volts and 0 volts) > > There is no difference ... "0 volt" is just an arbitrary reference point. > > 0 <-> +A swing is the same as > -A/2 <-> A/2 swing if you shift your reference ... > > Ethernet and USB are _differential_ but that's just to improve signal > integrity / noise immunity and such. At the receiver end, the > differential input buffer essentially compares both and see which one > is higher. (a bit simplified, but that's the gist of it). > > > Is there anyone already implemented unipolar preamble detection > > succesffully, or could anyone give me some hints on mathematical > approach or > > something? > > If 'A' is known, just remove -A/2 from your input signal. > If it is unknown,you can use a very long time constant low pass to > find it. (assuming your signal doesn't have long runs of 0 or 1). > > Cheers, > >Sylvain > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] points in scope sink are missing when zooming in and out
For debugging or other purposes, sometimes I use time domain scope sink. When I zoom in and out, points in the scope are missing. For instance, flow graph generates a stream: 11001100 (ten ones and zereos are repeating) After hitting buttons zooming in and out, the scope shows: ..1..1..1...0..0..0...1..1..1...0..0..0...1..1..1.. (n ones and m zeros are repeating, n, m < 10) I think this issue related with some graphic interface. Is it a know issue? Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] points in scope sink are missing when zooming in and out
I am using WX. I miss some details in the previous post. It doesn't happen when I hit zoom in and out one or two times. It happens after hitting zoom in and out 4, 5, 6, ... times. Not sure exact value. Also, it seems the duration of each bits are unchanged. i.e., ten ones before zooming and several ones after zooming have same duration. For additional information, I am using GRC 3.7.6 on Ubuntu 14.04 (kernel 3.13) on VMWare assigned 2 CPUs (i7 3770) and 4 GB ram. Regards, Jeon. 2015-05-08 21:09 GMT+09:00 Marcus Müller : > Hi Jeon, > > is this QT or WX Gui? > > Greetings, > Marcus > > > On 05/08/2015 01:45 PM, Jeon wrote: > > For debugging or other purposes, sometimes I use time domain scope sink. > > When I zoom in and out, points in the scope are missing. > > For instance, flow graph generates a stream: > > 11001100 (ten ones and zereos are > repeating) > > After hitting buttons zooming in and out, the scope shows: > > ..1..1..1...0..0..0...1..1..1...0..0..0...1..1..1.. (n ones and m zeros > are repeating, n, m < 10) > > I think this issue related with some graphic interface. Is it a know > issue? > > Regards, > Jeon. > > > > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] points in scope sink are missing when zooming in and out
Dear, Marcus That's OK. It's not a problem related with actual communication behavior or something. I was just curious about that :) Regards, Jeon. 2015-05-08 21:49 GMT+09:00 Marcus Müller : > Hi Jeon, > sorry, I really can't reproduce that. Can you provide a minimal flowgraph > that we can use to test? > Generally, GNU Radio slowly moves away from WX towards QT, so if that's an > option, use QT. > > Best regards, > Marcus > > > On 05/08/2015 02:36 PM, Jeon wrote: > > I am using WX. > > I miss some details in the previous post. > > It doesn't happen when I hit zoom in and out one or two times. > It happens after hitting zoom in and out 4, 5, 6, ... times. Not sure > exact value. > > Also, it seems the duration of each bits are unchanged. > i.e., ten ones before zooming and several ones after zooming have same > duration. > > For additional information, > I am using GRC 3.7.6 on Ubuntu 14.04 (kernel 3.13) on VMWare assigned 2 > CPUs (i7 3770) and 4 GB ram. > > Regards, > Jeon. > > 2015-05-08 21:09 GMT+09:00 Marcus Müller : > >> Hi Jeon, >> >> is this QT or WX Gui? >> >> Greetings, >> Marcus >> >> >> On 05/08/2015 01:45 PM, Jeon wrote: >> >> For debugging or other purposes, sometimes I use time domain scope >> sink. >> >> When I zoom in and out, points in the scope are missing. >> >> For instance, flow graph generates a stream: >> >> 11001100 (ten ones and zereos are >> repeating) >> >> After hitting buttons zooming in and out, the scope shows: >> >> ..1..1..1...0..0..0...1..1..1...0..0..0...1..1..1.. (n ones and m zeros >> are repeating, n, m < 10) >> >> I think this issue related with some graphic interface. Is it a know >> issue? >> >> Regards, >> Jeon. >> >> >> >> >> >> ___ >> Discuss-gnuradio mailing >> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about ofdm_sync_long block of gr-ieee802-11 module
I am looking gr-ieee802-11 module. a part of the source code is pasted here ( https://gist.github.com/gsongsong/3df4553fe96e2d62b83e) I have a question on the following statement: `if(rel >= 0 && (rel < 128 || ((rel - 128) % 80) > 15))` in `case COPY` `if(((d_count + o) % 64) == 0)` in `case RESET` I am wonder what do these numbers(128, 80, 15, 64) and modulo operation have logical meaning in IEEE 802.11p PHY frame? I've read 802.11 OFDM specification, thus I have knowledge about it, but I have no idea what are roles of these things in implementation. Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about ofdm_sync_long block of gr-ieee802-11 module
Dear Marcus and Bastian, Thank you for your detailed answers. Also, thank you for useful usage of gist. :) Regards, Jeon. 2015-05-09 21:42 GMT+09:00 Bastian Bloessl : > Hi, > > > > On 09 May 2015, at 13:23, Marcus Müller > wrote: > > > > So, looking at this, it's taking the delayed input samples and copies > them (offset-corrected) to the output, considering parts of the samples, > > x = ignore, o = copy, starting at the frame start: > > > > |xx¦oo|xx¦oo|... > >128 |16¦128-16|16¦128-16|… > > > > Exactly, it’s to remove the cyclic prefix (remove the first 16 samples of > every 80 samples). Unfortunately, the first 128 samples (the long training > sequence) don’t fit into the same scheme. Therefore the special case here. > > Best, > Bastian > > > > > > I'm not too familiar with 802.11p frames, but that looks like Basti's > leaving out some pilots in between the data, probably only copying the > preamble and data payload. But I could be wrong. > > > > Greetings, > > Marcus > > > > [1] > https://github.com/bastibl/gr-ieee802-11/blob/master/lib/ofdm_sync_long.cc#L128 > > > > On 05/09/2015 12:06 PM, Jeon wrote: > >> I am looking gr-ieee802-11 module. > >> > >> a part of the source code is pasted here ( > https://gist.github.com/gsongsong/3df4553fe96e2d62b83e) > >> > >> I have a question on the following statement: > >> > >> `if(rel >= 0 && (rel < 128 || ((rel - 128) % 80) > 15))` in `case COPY` > >> `if(((d_count + o) % 64) == 0)` in `case RESET` > >> > >> I am wonder what do these numbers(128, 80, 15, 64) and modulo operation > have logical meaning in IEEE 802.11p PHY frame? > >> > >> I've read 802.11 OFDM specification, thus I have knowledge about it, > >> but I have no idea what are roles of these things in implementation. > >> > >> Regards, > >> Jeon. > >> > >> > >> ___ > >> Discuss-gnuradio mailing list > >> > >> Discuss-gnuradio@gnu.org > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- > Dipl.-Inform. Bastian Bloessl > Distributed Embedded Systems Group > University of Paderborn, Germany > http://www.ccs-labs.org/~bloessl/ > > > ___ > 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] Question about ofdm_sync_long block of gr-ieee802-11 module
Dear Bastian, I missed one another thing. `if(((d_count + o) % 64) == 0)` statement in https://github.com/bastibl/gr-ieee802-11/blob/master/lib/ofdm_sync_long.cc#L141 Is this because of a length of an OFDM signal being a multiple of 64, which is the number of subcarriers? (Except cyclic prefix) Regards, Jeon. 2015-05-09 22:32 GMT+09:00 Jeon : > Dear Marcus and Bastian, > > Thank you for your detailed answers. > > Also, thank you for useful usage of gist. :) > > Regards, > Jeon. > > > 2015-05-09 21:42 GMT+09:00 Bastian Bloessl : > >> Hi, >> >> >> > On 09 May 2015, at 13:23, Marcus Müller >> wrote: >> > >> > So, looking at this, it's taking the delayed input samples and copies >> them (offset-corrected) to the output, considering parts of the samples, >> > x = ignore, o = copy, starting at the frame start: >> > >> > |xx¦oo|xx¦oo|... >> >128 |16¦128-16|16¦128-16|… >> > >> >> Exactly, it’s to remove the cyclic prefix (remove the first 16 samples of >> every 80 samples). Unfortunately, the first 128 samples (the long training >> sequence) don’t fit into the same scheme. Therefore the special case here. >> >> Best, >> Bastian >> >> >> > >> > I'm not too familiar with 802.11p frames, but that looks like Basti's >> leaving out some pilots in between the data, probably only copying the >> preamble and data payload. But I could be wrong. >> > >> > Greetings, >> > Marcus >> > >> > [1] >> https://github.com/bastibl/gr-ieee802-11/blob/master/lib/ofdm_sync_long.cc#L128 >> > >> > On 05/09/2015 12:06 PM, Jeon wrote: >> >> I am looking gr-ieee802-11 module. >> >> >> >> a part of the source code is pasted here ( >> https://gist.github.com/gsongsong/3df4553fe96e2d62b83e) >> >> >> >> I have a question on the following statement: >> >> >> >> `if(rel >= 0 && (rel < 128 || ((rel - 128) % 80) > 15))` in `case >> COPY` >> >> `if(((d_count + o) % 64) == 0)` in `case RESET` >> >> >> >> I am wonder what do these numbers(128, 80, 15, 64) and modulo >> operation have logical meaning in IEEE 802.11p PHY frame? >> >> >> >> I've read 802.11 OFDM specification, thus I have knowledge about it, >> >> but I have no idea what are roles of these things in implementation. >> >> >> >> Regards, >> >> Jeon. >> >> >> >> >> >> ___ >> >> Discuss-gnuradio mailing list >> >> >> >> Discuss-gnuradio@gnu.org >> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > >> > ___ >> > Discuss-gnuradio mailing list >> > Discuss-gnuradio@gnu.org >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> -- >> Dipl.-Inform. Bastian Bloessl >> Distributed Embedded Systems Group >> University of Paderborn, Germany >> http://www.ccs-labs.org/~bloessl/ >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] What if noutput_itmes is too short?
I am trying to remove `preamble` and `start frame delimiter` from a frame and only the payload will be passed to the next block. While in debugging, `ninput_items` is 7742, and `noutput_items` is 4096, for instance. An offset where the frame starts is 790. Simple calculation gives me that 7742 - 790 = 6952 samples should be passed to the next block. But output space given is only 4096. Thus, I can only pass 4096 samples and 6952 - 4096 = 2856 samples will be discarded. But, I need them to be passed, too. Even worse, a stream of samples are coming continuously from a previous block. Will it be helpful if I have some very long buffer in a block? I don't think it works since `noutput_items` is always smaller than `ninput_items` every time the block runs `general_work()`. In this case, I think the buffer will be overflowed. The link below is the log that shows `i`/`ninput_itmes` and `o`/`noutput_items`, where `i` and `o` are input and output indices. When `ninput_itmes` and `noutput_items` change, it means a new `general_work` is called. Log (it's quite long...): https://bitbucket.org/snippets/gsongsong/By8x Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What if noutput_itmes is too short?
After posting the previous thread, I've searched APIs from GNU Radio doxygen. Several candidates have been found. 1. [`produce()`]( http://gnuradio.org/doc/doxygen/classgr_1_1block.html#aa5581727d057bdd8113f8b2a3fc5bd66 ) 2. [`set_min_noutput_items()`]( http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a65cfc579150dc4d10c6180d3365aa9a8 ) 3. [`set_min_output_buffer()`]( http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a9d10e3f6747f91b215abe81b60a003d5 ) 4. [`expand_minmax_buffer()`]( http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a9bbf96f6a81d5c289934a68ef44dd1b4 ) I think I can combine `produce()` and `set_min_noutput_items()` to **enlarge** the `noutput_items` If I get wrong, please let me know. Regards, Jeon. 2015년 5월 29일 (금) 오후 8:47, Jeon 님이 작성: > I am trying to remove `preamble` and `start frame delimiter` from a frame > and only the payload will be passed to the next block. > > While in debugging, `ninput_items` is 7742, and `noutput_items` is 4096, > for instance. An offset where the frame starts is 790. > > Simple calculation gives me that 7742 - 790 = 6952 samples should be > passed to the next block. But output space given is only 4096. Thus, I can > only pass 4096 samples and 6952 - 4096 = 2856 samples will be discarded. > But, I need them to be passed, too. > > Even worse, a stream of samples are coming continuously from a previous > block. > > Will it be helpful if I have some very long buffer in a block? I don't > think it works since `noutput_items` is always smaller than `ninput_items` > every time the block runs `general_work()`. In this case, I think the > buffer will be overflowed. > > The link below is the log that shows > > `i`/`ninput_itmes` and `o`/`noutput_items`, > > where `i` and `o` are input and output indices. When `ninput_itmes` and > `noutput_items` change, it means a new `general_work` is called. > > Log (it's quite long...): https://bitbucket.org/snippets/gsongsong/By8x > > Regards, > Jeon. > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What if noutput_itmes is too short?
Thank you for your reply, Marcus. Now I'm getting a little bit more. As I understand, if I consume(0, n), where n is less than ninput_items, then only n samples at the front of input_items[] are consumed and unconsumed part remains. And then, at the next call of general_work(), incoming samples are appended at the end of input_item[]. Is this right? If it is right, I can get a single whole payload by not consuming input samples after some time passed... However, I am still doubtful that input_items[] will not be appended as I think since output buffer at the previous block isn't cleared enough as `consume()` is not called. Well... Does `forecast()` which you've mentioned make the previous block can send more streams and the current block can received them? So far, I understand `forecast()` acts as just a blocker unless enough samples are given. In the developing stage, I am using fixed length payload. But, I want to make it work with arbitrary length (but not too long). Regards, Jeon. On Fri, May 29, 2015 at 9:52 PM Marcus Müller wrote: > Hi Jeon, > > > > On 05/29/2015 01:46 PM, Jeon wrote: > > I am trying to remove `preamble` and `start frame delimiter` from a frame > and only the payload will be passed to the next block. > > While in debugging, `ninput_items` is 7742, and `noutput_items` is 4096, > for instance. An offset where the frame starts is 790. > > Simple calculation gives me that 7742 - 790 = 6952 samples should be > passed to the next block. But output space given is only 4096. Thus, I can > only pass 4096 samples and 6952 - 4096 = 2856 samples will be discarded. > But, I need them to be passed, too. > > > There's no reason not to pass through your payload in parts, if you > implement a state machine with a counter for remaining items to pass > through in your block. > However, there's an advantage to waiting for the whole payload to be on > your input at once, which I'll explain further down. > Does your payload always have the same length? In that case, your forecast > should always demand payload_length input items to produce any amount of > output items -- that way, you can make sure that at *one point*, you get > the whole payload into your input buffer. > > No matter what you really do, you will need to use a state machine of some > kind. > In your case, that's comparatively easy: Just check, at the beginning of > each general_work call, whether you're in pass-through mode, or in "search > preamble mode", etc, and let your work act based upon that. For example, > assume you're in search preamble mode, you find a preamble, so you consume > all items up to the end of that preamble, and set your state to "pass > through", and then return from general_work. Before GNU Radio calls you > next time, it will ask forecast() how many input items you need. Forecast > always says it needs payload_length items, so at the point where work is > actually called in "pass through" mode, you *should* have at least > payload_length input items; let your block consume and produce these items, > switch to "search preamble mode", and return. > > > Even worse, a stream of samples are coming continuously from a previous > block. > > Lucky you! You have GNU Radio, which makes sure there's only one instance > of your general_work being run at once, and presenting you with all the > items you did not consume in the previous general_work calls. > > > Will it be helpful if I have some very long buffer in a block? I don't > think it works since `noutput_items` is always smaller than `ninput_items` > every time the block runs `general_work()`. > > That's not generally the case. It might be the case here, but that simply > means that the downstream block isn't consuming the whole buffer, or your > upstream items are larger, or your upstream block is just much faster at > producing items than you and your downstream blocks are at consuming them. > > If you just try to rely on GNU Radio's buffers, you would be safe from > something like buffer overflows happening -- GNU Radio will only call the > upstream's general_work function if there is enough space in its output > buffer (which is your input buffer). > > Personally, I think what you're doing is a complicated task, so I have a > lot of respect for the effort you're putting into this. > I'd try to avoid the complexity by *not* doing this in one block -- use a > preamble correlator to mark the beginning of your frame with a stream tag. > Then, use a state-machine block to only copy the payload_length items after > such a tag (a whole payload at a time), adding a tag on the first item > containing the length of t
Re: [Discuss-gnuradio] What if noutput_itmes is too short?
Thanks to Sylvain and Marcus. I think I've solved problem. Regards, Jeon. 2015-05-30 11:26 GMT+09:00 Sylvain Munaut <246...@gmail.com>: > Hi, > > > As I understand, if I consume(0, n), where n is less than ninput_items, > then > > only n samples at the front of input_items[] are consumed and unconsumed > > part remains. And then, at the next call of general_work(), incoming > samples > > are appended at the end of input_item[]. Is this right? > > > > If it is right, I can get a single whole payload by not consuming input > > samples after some time passed... > > Not really. Because the buffers are allocated only once at the start > and not resized and not really under your control. > > So if you leave the sample in there, and the buffer fills up and you > still don't have a full payload, the graph will stall forever. > It's annoying and a pattern that comes up quite often but it's the way > it works ATM. > > > Cheers, > > Sylvain > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PSK demod
Hi Agam I have no idea about details on PSK mod/demod blocks, BUT... one simple thing... Did you check the output right after the `PSK demod`, `Packed to Unpacked`, `Packet Decoder`? Bytes can be plotted after converted to float with `char to float` Regards, Jeon. 2015-06-01 19:01 GMT+09:00 Surya Agam : > Hello everyone, > > I try to simulate PSK modulation and demodulation without channel model to > calculate BER. The flow graph as shown below. > > > > > From File Source to PSK Mod is working, I can see the constellation even > with ISI. But after PSK demod there's no output. > > Is there's anything wrong with my fg? > > > -- > Sincerely, > > Surya Agam > University Al Azhar of Indonesia, Jakarta > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] filename in file source from GRC and automatic clear reports?
It's not a critical issue. 1. How could I put filename which contains variables? After I define a variable `time` with a value of `20150609`. I want to use a file `/my/file/path/sample20150609` as a file source. In `file` field (filename) in file source block, how can I refer such a variable? I put variable name in the field, but it seems the GRC regards it as a string literal. 2. Every time before I run the GRC flow graph, I want to clear the reports (console log). I think it is possible if I put something in `.grc` file in the home directory. But, I have no idea about that `something`. Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] filename in file source from GRC and automatic clear reports?
Dear Marcus.
Thanks for your answers.
I've tried and seen that `str(var)` appears as it is. And I thought it
didn't work. But according to your answer, it is converted to a string
properly when py file was generated and executed. Is it right?
And for clearing reports, your suggestion is to modify source code of GRC
app itself. I'll try it later.
Again thank you for your kind answers
Regards,
Jeon.
2015-06-09 16:13 GMT+09:00 Marcus Müller :
> Hi Jeon,
>
> the input fields just take "normal" python, so
>
> "/my/file/path"+ str(time)
>
> should just work; for more complex things, try python's (quite frankly
> awesome) string formatting language
>
> "/home/marcus/{dir}/{date}-{hour:02d}-{minute:02d}-{seconds:02.6f}.dat".format(dir="/samples",
> date=20150609,hour=8,minute=59,seconds=25.33212324)
>
> will give you
> /home/marcus//samples/20150609-08-59-25.332123.dat
>
> notice the length of each number and the padding with zero of the hour.
>
> Possibly, GRC tries to figure out whether what you've entered into the
> text field is just text (and must be surrounded by " ) or python code, and
> goes wrong.
>
> 2. There's no setting I'd know of that would enable that; the only way I
> can find in the source code is View->Clear Reports, which triggers the
> CLEAR_REPORT GRC Action; if you feel like it, you could add a "clear
> reports on flow graph launch" checkbox there and modify the Action that
> happens when you click on "run" to include conditional clearing of the
> reports.
>
> Greetings,
> Marcus
>
>
> On 06/09/2015 06:08 AM, Jeon wrote:
>
> It's not a critical issue.
>
> 1. How could I put filename which contains variables?
>
> After I define a variable `time` with a value of `20150609`. I want to
> use a file `/my/file/path/sample20150609` as a file source.
>
> In `file` field (filename) in file source block, how can I refer such a
> variable? I put variable name in the field, but it seems the GRC regards it
> as a string literal.
>
> 2. Every time before I run the GRC flow graph, I want to clear the
> reports (console log).
>
> I think it is possible if I put something in `.grc` file in the home
> directory. But, I have no idea about that `something`.
>
> Regards,
> Jeon.
>
>
> ___
> Discuss-gnuradio mailing
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Measuring performance of module
My OOT module seems to be almost done in implementation. I am wondering that which and how performance metric can be measured. I am considering the basic communication performance metrics such as throughput, BER/PER vs SNR. And such metrics are rather easy to measure. So there are not what I have difficulties to measure. As an SDR platform, I think memory(buffer) usage and processing time per block can be importatnt metrics. Thus, the question is... How can I measure such GNU Radio-related metircs? Should I put codes which calculate metrics inside each block? Or can it be done in other ways? Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Measuring performance of module
Dear Tom and Marcus Thank you for very detailed explanations. Regards, Jeon. 2015-06-12 22:24 GMT+09:00 Tom Rondeau : > On Fri, Jun 12, 2015 at 2:24 AM, Marcus Müller > wrote: > >> Have a look at the performance counters, and especially the graphical >> monitor, gr-perf-monitorx. It does quite exactly what you describe. >> >> Best regards, >> Marcus >> > > Here's a paper that I wrote on it: > http://conferences.sigcomm.org/sigcomm/2013/srif.php > > And some more inf on the wiki: > https://gnuradio.org/redmine/projects/gnuradio/wiki/PerformanceCounters > > Note that to use Performance Monitor, you'll need the master branch of GNU > Radio after we reintroduced ControlPort: > https://gnuradio.org/redmine/projects/gnuradio/wiki/ControlPort > > Tom > > > > >> On 06/12/2015 05:01 AM, Jeon wrote: >> >> My OOT module seems to be almost done in implementation. >> >> I am wondering that which and how performance metric can be measured. >> >> I am considering the basic communication performance metrics such as >> throughput, BER/PER vs SNR. And such metrics are rather easy to measure. So >> there are not what I have difficulties to measure. >> >> As an SDR platform, I think memory(buffer) usage and processing time >> per block can be importatnt metrics. Thus, the question is... How can I >> measure such GNU Radio-related metircs? Should I put codes which calculate >> metrics inside each block? Or can it be done in other ways? >> >> Regards, >> Jeon. >> >> >> ___ >> Discuss-gnuradio mailing >> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > ___ > Discuss-gnuradio 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] variable type while creating a block
Dear Marbelly, unpack_k_bits with k = 1 means, for instance, a byte sample 0x0F (0b ) in a stream is unpacked to 0x00 0x00 0x00 0x00 0x01 0x01 0x01 0x01 (MSB first) and only the first insignificant sample is taken and the rest 7 samples are discarded. So if you want to process 8 bits in a byte individually, use unpack_k_bits with k = 8. Regards, Jeon. 2015-06-17 11:49 GMT+09:00 Marbellys : > Thank you. > > > > -- > View this message in context: > http://gnuradio.4.n7.nabble.com/variable-type-while-creating-a-block-tp54226p54232.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question on tags - offsets
Dear Anil,
Not every 64 items,but work() function is called if there are more than 64
items in the input stream (buffer).
Regards,
Jeon.
2015-06-19 11:51 GMT+09:00 Anil Kumar Yerrapragada :
> Hi,
>
> A quick question on tags.
>
> I'm coding a custom block in python and my forecast function is like so:
>
> def forecast(self, noutput_items, ninput_items_required):
> #setup size of input_items[i] for work call
> for i in range(len(ninput_items_required)):
> ninput_items_required[i] = 64
>
> If my understanding is correct, every 64 items, the block's work function
> is called.
>
> Each time work is called, I want to add a tag to the first of the 64
> elements that come in (the *value* of my tag is a list). So I used:
>
> lst = (1, 2, 3, 4) #example
>
> item_index = 0
> offset = self.nitems_written(0) + item_index
> key = pmt.string_to_symbol("example")
> value = pmt.to_pmt(lst)
>
> self.add_item_tag(0, offset, key, value)
>
> This works. I can see the tag being added when I use a QT time sink.
>
> But when I add some print statements and check what I noticed is that tags
> are being added at indicies 0, 8192, 16384 etc. Basically multiples of 8192
> which is the full length of the input buffer in0 = input_items[0].
>
> Shouldn't self.nitems_written(0) be 64 each time?
>
> What I really want is tags being added at 0, 64, 128 etc. I'm sure I'm
> missing something pretty silly.
>
> Thanks
> Anil
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NO UHD devices found for E100
(This message was also posted on USRP-users mailing list.) I am trying to connect USRP E100 to my PC, ubuntu 14.04 But I am having a difficulty on finding uhd device. The followings what I have done til now: $ sudo ethtool eth0 # check if ethernet is gigabit Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: external Auto-negotiation: on Supports Wake-on: g Wake-on: g Current message level: 0x00ff (255) drv probe link timer ifdown ifup rx_err tx_err Link detected: yes $ ifconfig # check if PC and E100 is in a network eth0 Link encap:Ethernet HWaddr 00:25:64:c2:16:be inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0 inet6 addr: fe80::225:64ff:fec2:16be/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:251 errors:0 dropped:0 overruns:0 frame:0 TX packets:1943 errors:4 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:254997 (254.9 KB) TX bytes:193482 (193.4 KB) Interrupt:16 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:839 errors:0 dropped:0 overruns:0 frame:0 TX packets:839 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:66205 (66.2 KB) TX bytes:66205 (66.2 KB) $ uhd_find_devices # check if there is USRP connected linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.009.git-189-g6b64d9bb NO UHD Devices Found Could you suggest anything else what I haven't done yet? I use Cat 5 ethernet cable to connect USRP and PC (not sure it is 5e, I'll check it.) Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NO UHD devices found for E100
Thanks Marcus :) 2015-06-25 16:42 GMT+09:00 Marcus Müller : > Hi Jeon, > > In my case, my OOT module use IT++ (for convolutional code) and > [ezpwd-reed-solomon](https://github.com/pjkundert/ezpwd-reed-solomon) > Isn't it the case that I can port it easily? > > Since the E100 runs a "normal" linux, yes, it should be relatively easy. > > And is there no way to use E100 as a peripheral? But only to use it as an > embedded machine? > > No, no way. You can of course use something like a network sink in GNU > Radio, but that won't be fun (100Mbit/s means even for 8 bit samples 5MS/s > max, and that's more than the CPU on the E100 can feed from the Radio to > the network). > > Then, I have to consider using USRP 1 or N200. I have both :) > > Use the N200. It's the right device for that job! > > Best regards, > Marcus > > > > On 06/25/2015 09:26 AM, Jeon wrote: > >Dear Marcus, > > Thanks for reply. > > In my case, my OOT module use IT++ (for convolutional code) and > [ezpwd-reed-solomon](https://github.com/pjkundert/ezpwd-reed-solomon) > Isn't it the case that I can port it easily? > > And is there no way to use E100 as a peripheral? But only to use it as > an embedded machine? > Then, I have to consider using USRP 1 or N200. I have both :) > > Regards, > Jeon. > > 2015-06-25 15:33 GMT+09:00 Marcus Müller : > >> Hi Jeon, >> >> (This message was also posted on USRP-users mailing list.) >> >> Ah! While I was writing my answer for that, this email came in. >> Point is the same, gr-uhd on your PC can't detect the E100 because it's >> not a peripheral (like e.g. the N200), but an embedded linux computer of >> its own. >> >> What I didn't know in my reply was that you were planning to use GNU >> Radio. >> The good thing is: GNU Radio python flow graphs are perfectly portable, >> so if you have a GNU Radio application that doesn't need any custom C++ >> blocks, you can get away without cross-compiling software on your PC for >> the E100, but will just have to copy over the python files to your E100. >> >> Best regards, >> Marcus >> >> >> On 06/25/2015 08:25 AM, Jeon wrote: >> >> (This message was also posted on USRP-users mailing list.) >> >> I am trying to connect USRP E100 to my PC, ubuntu 14.04 >> >> But I am having a difficulty on finding uhd device. >> >> The followings what I have done til now: >> >> $ sudo ethtool eth0 # check if ethernet is gigabit >> Settings for eth0: >> Supported ports: [ TP MII ] >> Supported link modes: 10baseT/Half 10baseT/Full >> 100baseT/Half 100baseT/Full >> 1000baseT/Half 1000baseT/Full >> Supported pause frame use: Symmetric Receive-only >> Supports auto-negotiation: Yes >> Advertised link modes: 10baseT/Half 10baseT/Full >> 100baseT/Half 100baseT/Full >> 1000baseT/Half 1000baseT/Full >> Advertised pause frame use: Symmetric Receive-only >> Advertised auto-negotiation: Yes >> Speed: 100Mb/s >> Duplex: Full >> Port: MII >> PHYAD: 1 >> Transceiver: external >> Auto-negotiation: on >> Supports Wake-on: g >> Wake-on: g >> Current message level: 0x00ff (255) >>drv probe link timer ifdown ifup rx_err tx_err >> Link detected: yes >> >> $ ifconfig # check if PC and E100 is in a network >> eth0 Link encap:Ethernet HWaddr 00:25:64:c2:16:be >> inet addr:192.168.10.1 Bcast:192.168.10.255 >> Mask:255.255.255.0 >> inet6 addr: fe80::225:64ff:fec2:16be/64 Scope:Link >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:251 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:1943 errors:4 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:1000 >> RX bytes:254997 (254.9 KB) TX bytes:193482 (193.4 KB) >> Interrupt:16 >> >> loLink encap:Local Loopback >> inet addr:127.0.0.1 Mask:255.0.0.0 >> inet6 addr: ::1/128 Scope:Host >> UP LOOPBACK RUNNING MTU:65536 Metric:1 >> RX packets:839 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:839 e
[Discuss-gnuradio] USRP RF output frequency is much faster than intended.
I build a flow graph like an image in the following link: http://i.imgur.com/PpXck09.jpg After then, I connect the USRP and an oscilloscope and see output, which yields: http://i.imgur.com/JEKhnfx.jpg As you see, both are square waves, but the frequency, the above is 1k and the below is 7.8 kHz. If I set a frequency of signal source to 2k, the below says 16.6 kHz. (Of course, there are some deviation) How could I understand this? If the oscilloscope shows a frequency slower than the GNU radio, I think that is acceptable since there are latency and processing time and something. But the output is 7.8 times faster than what I inteded. The only thing I can guess is... 7.8 is rounded up to 8, and 8 indicates '8' bits. But it seems a bit unnatural and weird... Could anyone give me a hint? If you think it is more appropriate to be posted on USRP-users, I'll post it there later. :) Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP RF output frequency is much faster than intended.
Dear all, Mleech, Marcus and Nathan Thanks for all your advices. I've set the samp_rate to 250k and it works perfectly. Marcus, I've checked your answer on USRP users mailing list a few minutes ago. Some settings were set wrong, so the mail was not delivered to me. Sorry for late. Nathan, LFTX and LFRX can use center frequnecy of 0 Hz (maybe) which are what I am using now. Regards, Jeon. 2015-06-25 22:58 GMT+09:00 West, Nathan : > Hi Jeon, > > I stared at this over my morning coffee. I can't quite explain why you're > getting 7.8kHz output on a scope, but there's some other considerations. > > 1) Your UHD block has a center frequency of 0Hz. When you run your > flowgraph do you get messages from UHD? You should see something about not > being able to set a center frequency of 0Hz and using x Hz instead. > > 2) 32 kHz is not a good sampling rate for USRPs. You should see something > similar to #1 about setting the clock. The signal you are seeing is > probably a result of generating a signal with some expected sampling > frequency and looking at with another. If you compare the actual USRP clock > rate to 32kHz and do some math I wouldn't be surprised if it comes out to > be a factor of 8 different. > > 3) Imagine an even simpler case with just a sine wave. You have a sine > wave of 1kHz at complex baseband going in to an upconverter (imagine this > as multiplying your signal by an oscillator at your center frequency). What > would you expect on the scope? If you don't know, then do the math; it's > fairly simple trig. > > Good luck, > Nathan > > On Thu, Jun 25, 2015 at 9:38 AM, Jeon wrote: > >> I build a flow graph like an image in the following link: >> http://i.imgur.com/PpXck09.jpg >> >> >> >> >> After then, I connect the USRP and an oscilloscope and see output, which >> yields: http://i.imgur.com/JEKhnfx.jpg >> >> >> >> As you see, both are square waves, but the frequency, the above is 1k and >> the below is 7.8 kHz. >> If I set a frequency of signal source to 2k, the below says 16.6 kHz. (Of >> course, there are some deviation) >> >> How could I understand this? >> If the oscilloscope shows a frequency slower than the GNU radio, >> I think that is acceptable since there are latency and processing time >> and something. >> >> But the output is 7.8 times faster than what I inteded. >> The only thing I can guess is... 7.8 is rounded up to 8, and 8 indicates >> '8' bits. >> But it seems a bit unnatural and weird... >> >> Could anyone give me a hint? >> >> If you think it is more appropriate to be posted on USRP-users, I'll post >> it there later. :) >> >> Regards, >> Jeon. >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Generate a specific wave form
If those overshoots are unwanted but inevitable due to hardware characteristics and limitations, you can generate a wave form with vector source with input sequence 101001111... Then, the output will be HLHLLHHHH... (H = HIGH, LOW = LOW) Regards, Jeon. 2015-06-29 23:23 GMT+09:00 Antonny Caesar : > Hello, guys. > > I need a help, please. I need to generate the kind of wave showned in > the picture, but I don't know which are the proper blocks. > Can anyone help me, please? > > Attachments: > http://www.ruby-forum.com/attachment/10893/fsk2level.png > > > -- > Posted via http://www.ruby-forum.com/. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Is there a project which implements half-duplex communications?
Hello, GNU Radio users, Very long time ago, USRP 1 was not suitable for half-duplex communications because USB 2.0 interface is too slow to achieve it. But now, there are USRP embedded and gigabit ethernet supporting USRP series. In my opinion, thus, half-duplex communications might be achievable nowadays. I am curious that there is a project which implements half-duplex communications. If there is, how many USRPs, daughterboards and antennas are used for each node? Can I find such a project in pybombs? In my guess, a half-duplex communication application can be built from both USRP sink and source being placed in one flow graph. But I have no idea of the rest of the flow graph. Should the flow graph open loop or closed loop? Is there a special configuration or tweak on USRP or GNU Radio required to achieve half-duplex communications? I apologize if my question sounds quite vague. Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Generate a specific wave form
Dear Caesar, If there's a certain purpose of this work but that is not explained this post, it's better for us to know the purpose. But, you might not want to explain that if it is confidential. Anyway, The original signal stays unmodified. You can get the original signal by connecting the original source block to another block. And you can get the whole part of the the original signal or nothing by setting duration, repetition or interpolation of each bit from a vector stream, which will be a multiplier. You can easily set a length/duration of each sample from a vector source by using repeat block. The figure above will generates 200 zeros, 200 ones, 200 zeros and 200 ones. It is equivalent to a vector source with (0, 0, 0, ..., 1, 1, 1, ..., 0, 0, 0, ..., 1, 1, 1, ...) But, if you want something different, for example, if you want to pause/stop the signal source block (or USRP source block, etc.) temporarily when the switch block (the vector source block or other trigger blocks) give zero and resume the source block when the switch block gives one, it seems you need to approach the problem in a different way. As I read your question again, it seems that you want a flow graph to output literally 'nothing' not even zero, is it right? In other words, you want to drop a part of the original signal when the switch value is zero. In that case, a valve block might help you. But I doubt that a vector source can be an argument of the valve block. (I might be wrong. There can be a block can do what you want, but not sure about it.) I recommend you to build a pass-or-drop, pass-or-block block. Regard, Jeon. 2015-07-01 11:59 GMT+09:00 Antonny Caesar : > Marcus, I see what you mean, but you didn't understand what I wanna do. > Using a multiplier you are modificating the original signal. I don't > want to multiply the samples, I want nothing or the entire signal. > > What I mean is: > 0 = no signal at all, everything is 0 and not only a piece of the > signal. The entire sine wave times 0 -> sine x 0 = 0. > 1 = the entire signal, but not only a sample x 1, like you showed. I > need to multiply the everything by 1 and leave the signal pass. > > Abstract: > > "Nothing" if the control is 0, and "EVERYTHING" if the control is 1. I > don't need pieces of wave times 0 or 1, I need the whole signal times 0 > or 1, like a switch. Did you get it? It's hard to build it here. > > Thanks a lot. > > -- > Posted via http://www.ruby-forum.com/. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Is there a project which implements half-duplex communications?
Dear Tim and Marcus, Thank you very much. I'll take a look at those projects. Regards, Jeon. 2015-07-01 0:03 GMT+09:00 Tim : > Jeon, > Also check out > http://wp.me/p55sJw-2v > software based half duplex burst PSK modem which can operate using a > single USRP, file loopback, or other SDR > -Tim > > > On 06/30/2015 09:30 AM, Jeon wrote: > > Hello, GNU Radio users, > > Very long time ago, USRP 1 was not suitable for half-duplex communications > because USB 2.0 interface is too slow to achieve it. > But now, there are USRP embedded and gigabit ethernet supporting USRP > series. > In my opinion, thus, half-duplex communications might be achievable > nowadays. > > I am curious that there is a project which implements half-duplex > communications. > If there is, how many USRPs, daughterboards and antennas are used for each > node? > Can I find such a project in pybombs? > > In my guess, a half-duplex communication application can be built from > both USRP sink and source being placed in one flow graph. > But I have no idea of the rest of the flow graph. Should the flow graph > open loop or closed loop? > Is there a special configuration or tweak on USRP or GNU Radio required > to achieve half-duplex communications? > > I apologize if my question sounds quite vague. > > Regards, > Jeon. > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Is a unipolar signal bad as an input for a USRP receiver?
I am using LFTX and LFRX to transmit and receive data between two nodes. I am modulating a bit stream with on-off keying (OOK) in which bit 1 is modulated into HIGH voltage and bit 0 is modulated into LOW voltage close to zero. What I concern is, USRP can process bipolar signal, has a low noise amplifier (LNA) and an ADC at the receiving end. I've heard that LNA and ADC take a heavy stress if they process a unipolar, a DC biased signal.I want the statement to be clear. I have a particular condition that I can't make a transmitted signal a bipolar NRZ signal instead of OOK... PS. I make a thread in discuss-gnuradio since I've got no reply on USRP-users several days or weeks ago (I don't remember exactly...). Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Is a unipolar signal bad as an input for a USRP receiver?
Dear Marcus. Thank you for your answer. Yes, I mean daughterboards, not USRP. I made an expression too short :) And I am happy to hear that I don't need to worry about what I've been concerning. Regards, Jeon. 2015-07-03 0:27 GMT+09:00 Marcus Müller : > Hi Jeon, > > What I concern is, USRP can process bipolar signal, has a low noise > amplifier (LNA) and an ADC at the receiving end. > > That's not true. The USRP motherboard itself doesn't have an amplifier; > amplifiers are, if they exist, on the daughterboards. > The LFRX doesn't have an LNA -- it just has an OpAmp configured as a > voltage follower. > > I've heard that LNA and ADC take a heavy stress if they process a > unipolar, a DC biased signal > > The ADC doesn't mind static signals (in fact, signals are always presented > to the ADC as differential), and the OpAmp is speced to withstand any > signal within its input range. So you don't have to worry :) > > NRZ might be a good idea for other reasons, but these depend solely on > your application. > > Best regards, > Marcus > > PS: I'll try to locate your thread on usrp-users. Normally we strive to > not miss anything on that mailing list. > > > On 07/02/2015 05:03 PM, Jeon wrote: > > I am using LFTX and LFRX to transmit and receive data between two nodes. > > I am modulating a bit stream with on-off keying (OOK) in which bit 1 is > modulated into HIGH voltage and bit 0 is modulated into LOW voltage close > to zero. > > What I concern is, USRP can process bipolar signal, has a low noise > amplifier (LNA) and an ADC at the receiving end. I've heard that LNA and > ADC take a heavy stress if they process a unipolar, a DC biased signal.I > want the statement to be clear. I have a particular condition that I can't > make a transmitted signal a bipolar NRZ signal instead of OOK... > > PS. I make a thread in discuss-gnuradio since I've got no reply on > USRP-users several days or weeks ago (I don't remember exactly...). > > Regards, > Jeon. > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph locking up with Stream Mux
whileni didnt look into null source block code, but the basic behavior of null source block is, it outputs nothing. So stream mux waits until input blocks pass a given number of samples and it takes forever Regards Jeon 2015. 7. 9. 오전 11:27에 "Nowlan, Sean" 님이 작성: > I’m somehow getting a simple flowgraph to lock up GNU Radio. It locks up > every time I run it, after roughly the same amount of time. As you can see > in the attached image and GRC file, I’m feeding two inputs of a Stream Mux > block from the same upstream block. Do you imagine why that might cause > problems? > > > > I know there are other ways to do what I’ve shown here, but locking up > seems like a bug. > > > > Thanks, > > Sean > > ___ > 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] Flowgraph locking up with Stream Mux
Oh I didnt know it.
Thanks for correcting it
Regards
Jeon
2015. 7. 9. 오전 11:51에 "Nowlan, Sean" 님이 작성:
> Null source just sets all outputs to zero, so it’s equivalent to a
> constant source with the scalar=0.
>
>
>
> …
>
> for(size_t n = 0; n < input_items.size(); n++) {
>
> optr = (void*)output_items[n];
>
> memset(optr, 0, noutput_items *
> output_signature()->sizeof_stream_item(n));
>
> }
>
> …
>
>
>
> I think this is some subtle issue with Stream Mux’s forecast function and
> how it interacts with the scheduler knowing when to advance read pointers
> from the upstream block. This is just a wild guess, though. Also, I’ve seen
> an upstream block connect to two inputs of a Multiply block to create a
> squaring device, and that seems to work just fine. But in Stream Mux’s
> case, it’s only copying from one input at a time.
>
>
>
> Sean
>
>
>
> *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On
> Behalf Of *Jeon
> *Sent:* Wednesday, July 08, 2015 10:46 PM
> *To:* Discuss GNU Radio mailing list
> *Subject:* Re: [Discuss-gnuradio] Flowgraph locking up with Stream Mux
>
>
>
> whileni didnt look into null source block code,
>
> but the basic behavior of null source block is,
>
> it outputs nothing.
>
> So stream mux waits until input blocks pass a given number of samples and
> it takes forever
>
> Regards
> Jeon
>
> 2015. 7. 9. 오전 11:27에 "Nowlan, Sean" 님이 작성:
>
> I’m somehow getting a simple flowgraph to lock up GNU Radio. It locks up
> every time I run it, after roughly the same amount of time. As you can see
> in the attached image and GRC file, I’m feeding two inputs of a Stream Mux
> block from the same upstream block. Do you imagine why that might cause
> problems?
>
>
>
> I know there are other ways to do what I’ve shown here, but locking up
> seems like a bug.
>
>
>
> Thanks,
>
> Sean
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sampling rate mismatch and rational resampler vs Repeat
I am building a certain system whose clock rates can be 200k, 400k, 3.75M, 7.5M, 15M, 30M, 60M and 120 MHz.(It's not an RF communication system, but a wired communication system using a square wave on-off keying.) First of all, I've tested a USRP with only available rates for USRP (i.e. 200k, 400k, 3.75M, 7.5M and 15 MHz). But, when I ran a flow graph, clock rates of 3.75M, 7.5M and 15 MHz are tuned to 3.703704M, 7.692308M and 14.285714 MHz. I see that it's because of dsp rate should be divisible by sampling rate. So, the GNU Radio, or USRP tunes sampling rate as close as one given by a user. What I concern is, will such differences between given sampling rate and tuned sampling rate make a big difference on a waveform, throughput and performance? I don't think it would make a big difference since ratio of differences are less than 5 percent. But it would be better to know about it before I run a real experiment. For the second, I want to fix the sampling rate of USRP as the common multiple of clock rates, 15 MHz. And I am thinkinkg about using a rational resampler block or a repeat block to make a low clock rate signal fit 15 MHz clock. For example, 1. 200 kHz signal -> rational resampler (interp: 15M, decim: 200k) -> USRP (15 MHz) 2. 200 kHz signal -> rational resampler (interp: 75, decim: 1) -> USRP (15 MHz) 3. 200 kHz signal -> repeat (interp:75) -> USRP (15 MHz) When I run those three, first two using rational resampler blocks gave me ugly waveforms. I think it's because band limiting filter is applied to the original signal or something like that. (Forgot to take a picutre of FFT, sorry.) In this situation, I think I don't have to use rational resampler and it's okay to use a repeat block because a clock rate of USRP (15 MHz) is a multiple of every given clock rates (200k, 400 kHz, ...) and because it's not a sinusoid, but a simple on-off keying. So, how do you think of it? Are there something that I am missing in a real implementation? Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sampling rate mismatch and rational resampler vs Repeat
Thanks you Tom and Marcus. Yes, well... I meant that I've also checked FFT but a picture of it was in another PC so I couldn't attach it when I was writing the previous post. Sorry about that. And I am currently using N210. Today, carrying on from the yesterday, I've replaced a square wave signal source block with either a random source with a range of [0, 2) block or a custom source block from my module and made In the figure above, I've marked a timing difference between them with arrows. Although I adjust a timing difference between them, a waveform after the resampler seems ugly. Yesterday, a waveform was quite acceptable since it's not a (pseudo-)random signal, but an alternating square wave. In this situation, a decision maker may make a false decision, I think. But it can be different if I connect USRP at the end of the flow graph. So I'll try both of them with various parameters, see the results/differences and post something if I make some progress. Regards, Jeon. 2015-07-24 23:00 GMT+09:00 Marcus Müller : > Hi Jeon, > what USRP are you using? > > You're right: The point is that only integer factor of the USRP's master > clock rate can be used. > So for example, if you're using the USRP2 or N210, the master clock rate > would be fixed at 100MHz. > That would explain the rates you're seeing. (3.703..MS/s = 100MHz/27, > 7.692...MS/s = 100MHz/13, 14.2857 = 100MHz/7) > > > What I concern is, will such differences between given sampling rate and > tuned sampling rate make a big difference on a waveform, throughput and > performance? I don't think it would make a big difference since ratio of > differences are less than 5 percent. > > Well, obviously: If you expect e.g. a 3.75MHz signal sampled at 15MS/s to > have a period of 4 samples, and it has a period of 3.8something samples, > you will see a frequency offset. Whether your application can correct that > is up to the design of the application. > > But it would be better to know about it before I run a real experiment. > > Well, frequency offset is relatively easy to model, so you might even be > able to translate that directly into error probabilities based on theory > alone. > > 1. 200 kHz signal -> rational resampler (interp: 15M, decim: 200k) -> USRP > (15 MHz) > 2. 200 kHz signal -> rational resampler (interp: 75, decim: 1) -> USRP (15 > MHz) > 3. 200 kHz signal -> repeat (interp:75) -> USRP (15 MHz) > > When I run those three, first two using rational resampler blocks gave me > ugly waveforms. > > These waveforms look perfectly normal to me! I can't imagine a digital > receiver that would have problems with that little overshoot at each > transition. > > (Forgot to take a picutre of FFT, sorry.) > > That's actually sad, because you would have noticed that the waveforms you > think look ugly actually look more beautiful in frequency domain: (don't > interpret x-Axis as Hz, but as numbers (-pi; pi)) > [image: Spectra of an interpolated and a repeated square wave] > > That's just basic DSP, hapening here: > All these strong red peaks outside the original signal's bandwidth > shouldn't be there -- after all, the signal you fed in had 1/75th of the > output nyquist bandwidth! > > Interpolation needs an anti-imaging filter to suppress the spectral images > -- in DSP, you seldom really want to have the sharp transitions when you > interpolate something. That interpolated signal should only occupy its > original's bandwidth, usually. Hence, you filter to b_nyquist/interpolation. > Finite filters can't have infinitely sharp passband edges, so you'll see > attenuation for the frequencies that are very close to the nyquist > frequency of the input signal. In your case, the abrupt change from 0 to 1 > is exactly that, a signal with all the input bandwidth as spectrum, so > there's the highest frequency parts of that attenuated a little bit, and > you see these oscillations near the edge. > > Since every physical system has low pass characteristics, you can > typically find high tolerance against this in baseband transceivers; most > of them just care about whether the signal has passed the threshold or not. > Overshoot is ignored, or even "slightly welcome" because it antagonizes > capacity-caused slowness (ie. the low pass characteristics of the signal > fits the low pass characteristics of the device). > > So, long story short: this is good, and normally, you'd just go with it. > The implementation GNU Radio uses for the fractional resampler is a minimum > mean square error interpolator FIR, and unless you'd have a specific metric > that mathematically makes that a bad choice, I&
[Discuss-gnuradio] About physcially acceptable, applicable signal input range for GNU Radio.
I am building a communication system which uses light. For the system, I've buiult a custom analog circuit and connected it to LFRX with SMA-BNC-Alligator clip. A simple dry run gives the following: As you can see, data is transmitted with on off keying. (Please ignore some ripples and fluctuation, it's due to 60 Hz fluorscent light interference. I'll fix it later.) I wonder that such input range (+- 50 mV) is quite acceptable for GNU Radio to manipulate. Since it's my first time to physically implement a communication system, I only have mathematical and theoretical knowledge, but have little experience and sense about dBm, rx sensitivity and so. But as I can see the waveform not so bad, I think I can manipulate it by equalizing or something... PS: In addition, that 60 Hz interference, would it be better if I filter out that at the analog circuit with high pass filter? Or is it just ok to use high pass filter block in GNU Radio. I think the former is better to reduce the computational cost of GNU Radio. And it is more proper to filter out before it passes through the ADC... Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About physcially acceptable, applicable signal input range for GNU Radio.
Dear all of you helping me, Marcus, Tom and Marcus Thanks for all of your answers. I've successfully receive frames and decode it. There are some physical and practical issues and glitches that I haven't thought about when writing source codes. But it's not what should be handled in this thread. I will let you know when I finish implementing GNU Radio OOT module and analog circuit front end, if there are someone interested in. :) One small question is, is there no way to guess a value of voltage, given that ADC sampled value? I think it's quite impossible to guess both values of DC component and AC component. It's because time sink figure in the original post,there's no DC component, but I fed a DC biased signal into the LFRX. At least for AC component, however, I think it is possible to guess... If we know ADC resolution, impedance (of course 50 ohms) and so... It's just curiosity. I'm not going to use such things right now. So if it is hard to tell in short time, YES or NO is sufficient. or you can just ignore this question. Thanks again. Regards, Jeon. 2015-07-30 23:40 GMT+09:00 : > Jeon: > > Gnu Radio, per se, knows nothing of voltage. It just sees digital samples > as delivered by the hardware. What those samples mean in terms of voltage > amplitude as delivered to the antenna port is completely opaque to Gnu > Radio. > > The LFRX will easily tolerate an input signal with a voltage swing up to > +/- 1V. You would have to see what amplitude, in terms of floating-point, > is produced in your flow-graph. > > > > > On 2015-07-30 01:37, Jeon wrote: > > I am building a communication system which uses light. For the system, > I've buiult a custom analog circuit and connected it to LFRX with > SMA-BNC-Alligator clip. > > A simple dry run gives the following: > > > > As you can see, data is transmitted with on off keying. > (Please ignore some ripples and fluctuation, it's due to 60 Hz fluorscent > light interference. I'll fix it later.) > > I wonder that such input range (+- 50 mV) is quite acceptable for GNU > Radio to manipulate. > > Since it's my first time to physically implement a communication system, I > only have mathematical and theoretical knowledge, but have little > experience and sense about dBm, rx sensitivity and so. > > But as I can see the waveform not so bad, I think I can manipulate it by > equalizing or something... > > PS: In addition, that 60 Hz interference, would it be better if I filter > out that at the analog circuit with high pass filter? Or is it just ok to > use high pass filter block in GNU Radio. I think the former is better to > reduce the computational cost of GNU Radio. And it is more proper to filter > out before it passes through the ADC... > > Regards, > Jeon. > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] cannot import name GNURadio when launching perf-monitorx and ctrlport-monitor
I am trying to measure performance of my OOT module with performance counter and control port. When I execute a command line `gr-perf-monitorx` or `gr-ctrlport-monitor`, an error below occurred: File "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GrDataPlotter.py", line 26, in from gnuradio.ctrlport import GNURadio ImportError: cannot import name GNURadio Could anyone give me a hint for this? For detail information, I've installed GNU Radio with `build-gnuradio` script. The last commit of cloned git repository in my PC is `d5cea6e4( https://gnuradio.org/redmine/projects/gnuradio/repository/revisions/d5cea6e44e29db6b62fabe2b1e5ec16e91b41e68)` in Jun 22 2015. I can't remember exactly, but I think this commit was used to install the GNU Radio. Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ControlPort 3.7.8rc1
Dear Bob, A few months ago, I've asked a similar question ( 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 > > ___ > 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] gnuradio-core missing / UCLA Zigbee PHY in gnuradio version 3.6.5.1
Dear Jaeho, It seems that you didn't install gr-ieee802_15_4 yet. In IEEE802.15.4 category, there is no blocks at all. CSS PHY and OQPSK PHY blocks are just generated after you build flow graphs which are configure as hierarchy blocks. Back to the original post of this thread, in short, Run commands: ./bootstrap ./configure make [sudo] make install [sudo] ldconfig (Assuming you have the proper version of GNU Radio, gr-ieee802_15_4) Regards, Jeon. 2015-08-05 0:27 GMT+09:00 Jaeho : > i am sorry, i have more question about your advice. > > 1. i opened ieee802_15_4_OQPSK_PHY.grc and transceiver_OQPSK.grc. > < > http://gnuradio.4.n7.nabble.com/file/n55254/Screenshot_from_2015-08-05_00_43_10.png > > > < > http://gnuradio.4.n7.nabble.com/file/n55254/Screenshot_from_2015-08-05_00_43_00.png > > > > like this images, there are some missing blocks. i guessed these blocks > came > from gr-foo. > But i installed gr-foo following install instruction in git main page and > there were no error messages during install processing. > please give me advice what can i do? what is the problem of this situation? > > 2. Actually, i generated python files (ieee802_15_4_oqpsk_phy.py and > transceiver_oqpsk.py) from .grc files, using F5(hot key), although there > are > some error. But i could not find any hints from these python code to > replace > my old code, which is /*self.packet_transmitter = > ieee802_15_4_pkt.ieee802_15_4_mod_pkts(self, spb=self._spb, > msgq_limit=2).*/ > Can you give me some more hints or advice to solve it? > > > > > -- > View this message in context: > http://gnuradio.4.n7.nabble.com/gnuradio-core-missing-UCLA-Zigbee-PHY-in-gnuradio-version-3-6-5-1-tp55093p55254.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio-core missing / UCLA Zigbee PHY in gnuradio version 3.6.5.1
No, it's not the old one. If you installed gr-ieee802-15-4 successfully, with the commands following: git clone https://github.com/bastibl/gr-ieee802-15-4 cd gr-ieee802-15-4 mkdir build cd build cmake .. make [sudo] make install [sudo] ldconfig you should be able to see lots of blocks in IEEE802.15.4 category: But in your case, you have only two blocks which are generated from hierarchy blocks. Which are not present in my case since I didn't build hierarchy block, yet. So, my suggestion is, double check whether intallation is successful or not. Regards, Jeon. 2015-08-05 9:15 GMT+09:00 Jaeho : > Thank you for your advice. > > but i think, your advice is for about old version gr-ieee802_15_4 which > name > was UCLA Zigbee PHY. > > it supported only until gnuradio version 3.5, and i am now using gnuradio > version 3.7. > > so i downloaded new version of gr-ieee802_15_4, it's way to install is as > below > > git clone git://github.com/bastibl/gr-ieee802-15-4.git > cd gr-ieee802-15-4 > mkdir build > cd build > cmake .. > make > sudo make install > sudo ldconfig > > so i already run it, and installed with any error message. > > so, i hope ask one more, same question with additional question. > > the figure that i insert as below, some files has comment that "compile on > mac" > > is this comments mean that those file works on only Apple Mac? or mean MAC > layer? > > <http://gnuradio.4.n7.nabble.com/file/n55259/mac.png> > > = > i am sorry, i have more question about your advice. > > 1. i opened ieee802_15_4_OQPSK_PHY.grc and transceiver_OQPSK.grc. > < > http://gnuradio.4.n7.nabble.com/file/n55259/Screenshot_from_2015-08-05_00_43_00.png > > > < > http://gnuradio.4.n7.nabble.com/file/n55259/Screenshot_from_2015-08-05_00_43_10.png > > > > like this images, there are some missing blocks. i guessed these blocks > came > from gr-foo. > But i installed gr-foo following install instruction in git main page and > there were no error messages during install processing. > please give me advice what can i do? what is the problem of this situation? > > 2. Actually, i generated python files (ieee802_15_4_oqpsk_phy.py and > transceiver_oqpsk.py) from .grc files, using F5(hot key), although there > are > some error. But i could not find any hints from these python code to > replace > my old code, which is /*self.packet_transmitter = > ieee802_15_4_pkt.ieee802_15_4_mod_pkts(self, spb=self._spb, > msgq_limit=2).*/ > Can you give me some more hints or advice to solve it? > > > > > -- > View this message in context: > http://gnuradio.4.n7.nabble.com/gnuradio-core-missing-UCLA-Zigbee-PHY-in-gnuradio-version-3-6-5-1-tp55093p55259.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cannot import name GNURadio when launching perf-monitorx and ctrlport-monitor
Dear Tom, Thanks for your advice. Actually, I've got a trouble for days installing Thrift and enabling it from GNU Radio. This is just a simple wrap-up for readers who are not familiar with compiling and building things.) Installing thrift: 1. Get Thrift 0.9.2 0.9.2 release tag of git repository have some buggy stuff. So get the stable release from https://thrift.apache.org/download 2. Extract it and build. Make sure that you have all of pre-requisites. $ tar xf thrift-0.9.2.tar.bz2 $ cd thrift-0.9.2 $ ./configure $ make $ sudo make install $ sudo ldconfig # just in case 3. Check python can import Thrift $ python >>> import thrift 3-1. If python can't, do the followings: $ cd thrift-0.9.2/lib/py $ sudo python setup.py install Go back step 3. And check again. 4. Build GNU Radio. $ cd gnuradio $ mkdir build $ cd build $ cmake .. $ make $ sudo make isntall 4-1. One important thing is, I recommend you to delete everythink inside build directory. At least, I recommend you to remove CMakeCache.txt: $ cd build $ rm -rf ./ # or $ rm CMakeCache.txt This file can help executing cmake, but sometimes it makes cmake get wrong variables. I've spent days to figure out this. cmakek gives me a wrong thrift binary path /usr/bin/thrift. Actually, I have thrift under /usr/local/bin. I think it's a quite unusual case since I have been messing around my PC. If you have a system with some fresh installation and configuration, it won't be a problem. Regards, Jeon. 2015-08-04 0:05 GMT+09:00 Tom Rondeau : > On Sat, Aug 1, 2015 at 1:41 AM, Volker Schroer wrote: > >> The same error happens in the 3.7.8 release candidate. >> >> -- Volker >> >> >> >> I am trying to measure performance of my OOT module with performance >> counter and control port. >> >> When I execute a command line `gr-perf-monitorx` or >> `gr-ctrlport-monitor`, an error below occurred: >> >> File >> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/GrDataPlotter.py", >> line 26, in >> from gnuradio.ctrlport import GNURadio >> ImportError: cannot import name GNURadio >> >> Could anyone give me a hint for this? >> >> For detail information, I've installed GNU Radio with `build-gnuradio` >> script. The last commit of cloned git repository in my PC is `d5cea6e4( >> https://gnuradio.org/redmine/projects/gnuradio/repository/revisions/d5cea6e44e29db6b62fabe2b1e5ec16e91b41e68)` >> in Jun 22 2015. I can't remember exactly, but I think this commit was used >> to install the GNU Radio. >> >> Regards, >> Jeon. >> >> > This sounds as if Thrift wasn't found when running cmake. Our cmake > scripts use thrift to compile our gnuradio.thrift file into C++ and Python > code that is installed with GNU Radio. > > The output of cmake will tell you if it found Thrift or not. Look under > the list of enabled components for: > > -- * gr-ctrlport > -- * * thrift > > Tom > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] extremely low buffer usage on perf monitor
I am looking into CPU and buffer usage of my OOT module via CtrlPort Performance Monitor. I have two flow graphs, a transmitter and a receiver. I can see a quite reasonable performance measures on the receiver side: However, on the transmitter side, buffer usage shows very weird values: It says, the transmitter of my OOT module rarely uses buffer. But, i don't think so, and actually it uses buffers! At least, I think encoders on the transmitter should use buffers as much as decoders on the receiver does. (Of course, it's not true that encoder and decoder require same computational cost. But, what I mean is that such tiny value is ridiculous.) I've executed the transmitter flow graph several times again and again, that number (1.52...e-5) never changes. My guess is, that number is a floating point representation of 1/(2^16). And 2^16 is 64k. But I have no idea what it means. Can anyone give me a tiny hint of it? Regards Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] extremely low buffer usage on perf monitor
I'm sorry for something that I didn't write on the previous post. Comparing runtime and buffer, runtime and buffer have different number of blocks. In many cases of mine, buffer shows a fewer blocks than runtime. My guess is that, it's because buffer of sink blocks don't have to be monitored. Is what I guess is correct? If so, this might be a problem when I want to monitor a certain block which has an optional output signature so that it is recognized as a sink block. Is there a way to monitor a such block? Regards, Jeon. 2015-08-06 19:31 GMT+09:00 Jeon : > I am looking into CPU and buffer usage of my OOT module via CtrlPort > Performance Monitor. > > I have two flow graphs, a transmitter and a receiver. > > I can see a quite reasonable performance measures on the receiver side: > > > > However, on the transmitter side, buffer usage shows very weird values: > > > > It says, the transmitter of my OOT module rarely uses buffer. But, i don't > think so, and actually it uses buffers! At least, I think encoders on the > transmitter should use buffers as much as decoders on the receiver does. > (Of course, it's not true that encoder and decoder require same > computational cost. But, what I mean is that such tiny value is ridiculous.) > > I've executed the transmitter flow graph several times again and again, > that number (1.52...e-5) never changes. > > My guess is, that number is a floating point representation of 1/(2^16). > And 2^16 is 64k. But I have no idea what it means. > > Can anyone give me a tiny hint of it? > > Regards > Jeon. > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Dealing with `divide 0` or `Inf` in GNU Radio C++ code.
Let's think about the following auto/cross correlator: http://i.imgur.com/Fy5hdVj.png I've placed `divide` because I need to normalize the correlation result. If we place `null source`, or `constant source with value of zero` right before the `pad source`, the simplified form of the correlator becomes 0 divided by 0. I've placed `time sink` right after the `pad sink` then, I can see the line hit the infinity. With a simplified flow graph: http://i.imgur.com/Msx9EQj.png Back to the my correlator, how can I handle such `infinity` value coming into the next block? My guess is that if a source block is a type of float, then `infinity` might have a maximum value of float. So, I think I can reject `infinity` value with `if (in[i] > threshold)`, where `threshold` is big enough, for correlator it is fine to have a value just larger than one. Do you think what I guess is right? Or can some boost numeric types, or PMT help somehow to deal with it? In addition, not important. In pages http://en.cppreference.com/w/cpp/types/numeric_limits/infinity and http://en.cppreference.com/w/cpp/numeric/math/INFINITY, non floating point numeric types can't handle infinity. Is it also applied to GNU Radio? Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] subdev_spec index
Please Is there anyone who could tell me what do those subdev_spec index stans for in thefollowing statement?: subdev_spec = (0, 1) I did some googling and there are lots of examples about it But i couldnt find the meanings of those indexes Thank you Sent from my iPad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
