Seeking RF ML Demos for IEEE's new ICMLCN Conference in May 2024
Dear Fellow GNU Radio Hackers, If you’re working in the RF ML space and have a relatively recent demo of applied work in this area (possibly even using GNU Radio!), please consider submitting it to IEEE’s first ever flagship ComSoc conference focused on the intersection of ML and communications systems (ICMLCN), where we’ve extended our call for demo proposals below through Nov 30th! Apologies if you have already seen or received this, I wouldn't normally post CFP's to this list, but this is potentially highly aligned with some folks building cool things in the community! Thanks & Cheers, Tim IEEE International Conference on Machine Learning for Communication and Networking (ICMLCN) 2024 solicits proposals for demonstrations at the first ever IEEE ComSoc flagship conference dedicated to machine learning and communications networks, to be held in Stockholm, May 2024. While ICMLCN will host a wide range of activities focusing on the intersection of machine learning and communications networks from theory to practice, there is no better place to demonstrate new data-driven methods and ideas than in the real world. As such, we would like to invite the submission of abstracts for proposed demonstrations from industry, academia, and elsewhere, which bring concepts from machine learning communications networks into live demonstrations, prototypes, and which can be shown and measured. The demo proposals will be reviewed based on its novelty; significance of implementation; relevance to ICMLCN scope; potential impact on the audience; quality of implementation. Please submit an extended abstract (2 pages) on your proposed demonstration to https://edas.info/N31472 Abstracts must be received by November 30th, 2023. Please see additional details at https://icmlcn2024.ieee-icmlcn.org/authors/call-demo-proposals if this is of interest!
Re: Using Fractional or Rational resampler to simulate Doppler
Hi Jose, I would take a look at gr_sattelite. The work described here https://destevez.net/2022/07/real-time-doppler-correction-with-gnu-radio/ was integrated. A true doppler correction would need to also resample, but the time varying frequency correction may be enough for your use case. Tim On Thu, Jul 27, 2023 at 1:19 PM Jose Ruvalcaba wrote: > > Hello, > > I am trying to simulate an accurate representation of Doppler Shift in a > channel and I was told that to do this I would have to multiply a complex > signal with a cosine and implement a resampler block to simulate the signal > samples that are coming closer or farther away from each other. > > My question is this, can I use either the rational resampler or fractional > resampler block in GNU Radio to dynamically simulate samples moving closer or > farther than each other? Or would I need to make my own OOT block to do this? > > I tried using a QT GUI Range block to change the resampling ratio of a > fractional resampler but my flowgraph froze. > > Any suggestions? > > Thanks, > Jose
SPAWC21: ML for Multi-Domain Localization and Signal Recognition Data Competition Call for Participation!
Call for IEEE SPAWC Data Competition Paper Submissions & Competitors! === IEEE Workshop on Signal Processing Advances in Wireless Communications (SPAWC) 2021 September 27 – 30, 2021 -- Lucca, Italy (And Online Hybrid Event) === SPAWC is hosting two exciting data competition this year at the intersection of wireless communications and machine learning and soliciting competitors both through paper submissions on approaches to these problems and through direct participation in the competitions through submission of scored results. We will accept the submission of full papers with proposed approaches and solutions to the data competition problem statements and datasets through July 5th and will accept competition solution entries through the beginning of the conference on September 27th through the data competition sites hosted on Kaggle and eval.ai. Full details for the data competition event may be found at the official conference website at https://www.spawc2021.com/data-competition/ Challenge #1 (Industrial Multi-Domain Localization) focuses on Industry 4.0 centric robust and versatile positioning of robotic devices using a combination of Camera-based, IMU-Based and ultra-wideband (UWB) based data observations requiring the fusion of multiple domains of observation to maximize precision. As robust and precise radio emitter localization is a key component in future industry and factory applications, we are excited to launch this data-driven challenge as part of SPAWC 21. https://www.kaggle.com/c/ieeespawc21localization/data Challenge #2 (Wideband Signal Recognition) focuses on rapid spectrum awareness and signal recognition to enable radio spectrum access coordination, anomaly detection, spectrum sharing, spectrum analytics and spectrum monitoring applications. As real-time spectrum awareness and spectrum aware decision making may be key components to beyond-5G and 6G communications systems, we are excited to launch this data-driven signal recognition competition as part of SPAWC this year to compare and contrast new promising approaches to the problem. https://eval.ai/web/challenges/challenge-page/1057/overview Both address key challenge areas where machine learning has demonstrated extremely promising initial results in related areas, but where we believe these datasets provide an exciting new step in expanding these results to multi-domain and to broad recognition challenges beyond what has been the principal focus in research publications thus far. Thus, we hope by posing these two challenges we can excite new researchers to propose, compare and publish new approaches to these problems which can help accelerate and mature these domains at the intersection of communications systems and machine learning. We’re soliciting full workshop papers via EDAS (https://edas.info/newPaper.php?c=28267) from competitors wishing to publish their approaches and ideas as well as competition submissions via Kaggle and eval.ai which may be submitted directly via the competition websites above until the beginning of the Conference event. Best Regards, Tim O’Shea Data Competition Chair, SPAWC21
Re: How to set variable number of inputs/outputs in Python OOT modules
I do not believe that you want to encapsulate the call with [ ], even so there may be an issue with that command. I am unsure what the issue is but when I make the call: in_sig = gr.io_signature(3,3, gr.sizeof_gr_complex) The error message is: Can't create an instance of your block: object of type 'io_signature_sptr' has no len() Instead try this: in_sig = 3*[np.complex64], Where 3 will end up being your variable for number of inputs. Tim On Thursday, February 4, 2021, 1:23:35 PM EST, George Edwards wrote: Hi Tim, Thanks for your suggestion! I just tried it and it does not work. The Python OOT def __init__(self, ) method requires that one fills in in_sig = xxx and out_sig = xxx.I tried your suggestion above for variable number of inputs and set:in_sig = [gr.io_signature(1, -1, gr.sizeof_gr_complex)] and I leave the yml file as is when I had the static number of inputs (in_sig = [complex64, complex64, complex64]) shown below inputs:- domain: stream dtype: complex multiplicity: '3'It gives a TypeError: data type not understoodI tried a bunch of combinations based on the above change you suggested, but GRC kept failing when I tried to run it.! Thanks again for your suggestion!Regards,George On Thu, Feb 4, 2021 at 8:01 AM Tim Huggins wrote: George, I would recommend taking a look at some of the existing blocks that have variable inputs to accomplish this (especially for the YML file). A YML example for a variable input can be found here: https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/grc/blocks_multiply_xx.block.yml I haven't run a test using this line in a python block yet, but two different examples are shown below that I believe should work (or should with some minor tweaks). The first doesn't limit the number of inputs while the second one does (at 8). gr.io_signature(1, -1, gr.sizeof_gr_complex)) gr.io_signature(1, 8, gr.sizeof_float)I don't know if there is a complete python reference for GNURadio 3.8, but this should be helpful to get you close as well: https://www.gnuradio.org/doc/sphinx-v3.7.9.2/ Good luck, Tim On Thursday, February 4, 2021, 12:01:07 AM EST, George Edwards wrote: Hi Gavin, Thanks for the information! Does this mean that if I wanted 3 inputs and 5 outputs and all floating point values, then inside the Python code, I simply set in_sig = [numpy.float32] out_sign = [numpy.float32] And, in the yml file I set:inputs:- domain: stream dtype: float multiplicity: '3' outputs: - domain: stream dtype: float multiplicity: '5' Would this be correct?Thanks again for your help! Regards,George On Wed, Feb 3, 2021 at 5:26 PM Gavin Jacobs wrote: In 3.7, you would use the tag, but in 3.8 the trick to setting multiple ins/outs in the YML file, is the keyword "multiplicity". You can see the details of how to configure here:https://wiki.gnuradio.org/index.php/YAML_GRC | YAML GRC - GNU RadioStarting with release 3.8, YAML replaces XML as the file format for GNU Radio Companion. This is triggered by switching from Cheetah to Mako as the templating engine, since Cheetah does not support Python 3.wiki.gnuradio.org |
Re: Problem with Python OOT
George, That should be correct; I was more referring to keeping your coding clean so you don't accidentally make a mistake (I've been bit before :-). You could conceivably start consuming inputs at different rates but by then you are probably getting into some more complex signal processing. Tim On Wednesday, January 20, 2021, 1:29:46 PM EST, George Edwards wrote: Hi Tim, Thanks for your help and for sending the links. One final question, I was under the impression that length of data in each input was the same because the data to each input is streamed in in lock-step sample by sample. Therefore, len(input_items[0] = len(input_items[1] = len(input_items[2], is this not correct? Thanks again for your help and patience. I appreciate it very much! Regards,George , , use the appropriate length for each input On Wed, Jan 20, 2021 at 10:51 AM Tim Huggins wrote: George, I'm not completely certain exactly why that doesn't result in a 1 to 1 (you might be able to look at the code for the basic sync block to see if there is anything you could add: https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/sync_block.cc (this would be an instance to use the sync block instead of a general block which forces the 1:1 relationship). That being said, take a look here: https://wiki.gnuradio.org/index.php/Types_of_Blocks Mainly the implementation using a general block at the very bottom. You can see how the input is limited to be no bigger than the output buffer in the work implementation: in0 = input_items[0][:len(output_items[0])] Also, be careful about your consumes - instead of using len(input_items[0]) for each, use the appropriate length for each input to get into good habits. Tim On Tuesday, January 19, 2021, 9:07:00 PM EST, George Edwards wrote: Hi Tim, I thought I had it working. However, it is dropping the last output sample. In the QA file, there are 5 complex samples going into each of the 3-inputs to the module. When the general_work() method runs with the for loop, it throws an exception error stating that index 4 (meaning out[4]) is out of bounds. If I comment out the for loop and run the program with the line commented out below: output_items[0][:]= v2it results in 4 out of 5 samples going to the output. I am using the documented default approach in coding for a 1:1 input/output sample relationship as you can see in the forecast() and general_work() methods below, please let me know if you see something that is wrong. 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] = noutput_items def general_work(self, input_items, output_items): global v1, v2 if self.scale == True: v1 = self.v1 v2 = self.v2 self.scale = False in0 = input_items[0] in1 = input_items[1] in2 = input_items[2] out = output_items[0] v2 = 1.0+1.0*1j for ii in range(0,len(in0)): out[ii] = v2 # output_items[0][:] = v2 self.consume(0, len(input_items[0])) self.consume(1, len(input_items[0])) self.consume(2, len(input_items[0])) return len(output_items]) Thank you very much!George On Tue, Jan 19, 2021 at 3:50 PM George Edwards wrote: Hi Tim, Thank you very much for your help! The problem was with the QA file. I tried to input the 3 source streams as:src = blocks.vector_source_c(np.array([src0, src1, src2])) where each srcX was defined as a complex array. Based on the link into the github QA files that you sent me, it showed that each srcX must be connected individually to the processing block. Also, I overlooked the fact that when I ran the QA, it pointed to that line in the code as a problem. I will now try to see if I can get the output to provide a stream of 8 samples (maybe do 3 as a start) based on one sample from each of the 3-input streams. Thanks again for the help! Regards,George On Tue, Jan 19, 2021 at 2:05 PM Tim Huggins wrote: George, Unfortunately I'll still not seeing anything wrong with what you have (and I realized that the QA code caused the issue so it is probably not in your yml file). I'd probably have too see your entire code to try to reproduce the error as all my tests to create the error didn't. Regarding your other questions:1. There isn't really a correct/incorrect as the answer can depend on the work that you want the block to do but general will work. I mainly use general or sync.2. Yes, as you have a 1 to 1 stream.3. This doesn't look quite correct. Are you planning on working with vector inputs or steams to your block? if you are using streams then there is no need to change vlen in the yml file. Also it sounds like whatever computations are basically doing an interpolation
Re: Problem with Python OOT
George, I have made several OOT Python blocks with variable numbers of inputs and outputs and while I could very easily be overlooking something the error does not, at first glance, appear to be in the code that you have sent out. Can you send the rest of your yml file (and potentially the rest of the python)? I am curious if there is something missing in either the templates or parameters sections of your yml file. Tim On Friday, January 15, 2021, 2:56:48 PM EST, George Edwards wrote: Hello, I am trying to make a Python OOT block which accepts a stream of 3 inputs complex valued data and for each single input sample (one on each input line) the block will output 8 complex samples. For my first cut, I am simply trying to get the module to work outputting one complex sample (rather than 8). Below are the essential parts of my program. 1. In the def __init__ (self.), I set the inner method gr.basic_block.__init__(self, name="my_block_name_py_cc", in_sig = [numpy.complex64,numpy.complex64, numpy.complex64 ], out_sig = [numpy.complex64]) # with 3 inputs and one output 2. In the general_work() method for now I set the output to a constant complex value as follows out_items[0][:] = 1.0+1.0*1j 3. In the *.yml file, the input is set as: inputs: - domain: stream dtype: complex multiplicity: '3' The module compiles. However, when I run the QA file, it gives an error stating something is wrong in File "..blocks_swig1.py at line 8354.TypeError: in method 'vector_source_c_make', argument 2 of type 'bool' I went to the file and the line stated, but I have not seen anything to help me make corrections. As far as a TypeError of 'bool', I do not see where I would have made such an error. I have an input parameter in the def __init__(self, start = True) method, 'start', which comes in as bool, but that is the only bool variable I am using. The documentation I read for the method states "This block produces a stream of samples based on an input vector" (which is my goal if I can get it to work). I will appreciate any help to get me on the right track. Regards,George
Embedded Python Block - Variable Input Vector
I created an embedded python block (using version 3.9 from git) successfully but I need the input vector to be variable size based on the parameters. For example: in_sig=[(np.byte, a*b)], out_sig=[(np.byte, a*b)] However, the parameters have defaults and defaults appear to set the vector. I can't change the preceding stream to vector block or else the grc has an error, but when I run the grc there is an input error because I was not able to update the steam to vector block. A block that does this similarly is a Reed Solomon block whose yml file is: https://github.com/gnuradio/gnuradio/blob/master/gr-dtv/grc/dtv_dvbt_reed_solomon_enc.block.yml However as far as I can tell there is no way to add a yml file for an embedded python block so I tried to create a python OOT module. However I must be making a mistake because when I go to build the block I error with: make[2]: *** No rule to make target '../python/bindings/gnuradio-test', needed by 'python/bindings/extracted_docstrings.json'. Stop. make[1]: *** [CMakeFiles/Makefile2:377: python/bindings/CMakeFiles/extracted_docstrings.dir/all] Error 2 make: *** [Makefile:141: all] Error 2 I think I need to do something from this guide: https://wiki.gnuradio.org/index.php/GNU_Radio_3.9_OOT_Module_Porting_Guide but I haven't figured out the right process. Can anyone help steer me in the right direction? Thanks, Tim
[Deadline Extended!] Re: Open Workshop on Machine Learning in Communications @ IEEE ICC 2020 (Call for Contributions)
Dear GR Community, This deadline has been extended until Feb 1! Please consider contributing your work to this workshop! Hoping to see GNU Radio making an appearance & impact here! I apologize for the repeated announcement :-) Best, Tim > On Jan 25, 2020, at 10:20 AM, West, Nathan > wrote: > > Hi all, > > Please consider contributing your work or demonstration proposals to the > workshop at IEEE ICC if you are working at the intersection of communications > systems and machine learning. Please see the CFP below for details. > > -Nathan > > Call for Papers: > > IEEE ICC 2020 Open Workshop on Machine Learning in Communications > > 7-11 June 2020, Dublin, Ireland > > ** Submission deadline: January 27, 2020 ** > > https://icc2020.ieee-icc.org/workshop/ws-19-open-workshop-machine-learning-communications/ > > <https://icc2020.ieee-icc.org/workshop/ws-19-open-workshop-machine-learning-communications/> > > === > Call For Papers > === > Machine Learning in Communications is a rapidly growing field within > networking and communications with the potential to substantially transform > wireless, optical, and other modes of networking and communications > engineering in a wide range of future systems by leveraging measurement, > data, feedback, domain knowledge, and learning to achieve optimality for a > wide range of performance metrics. By directly exploiting real data, > representation learning, end-to-end learning, reinforcement learning, > concurrent neuromorphic processing, and a wide range of concepts which have > advanced rapidly in the machine learning community in recent years, ML-Comms > holds the promise to discover alternative and superior ways for information > processing in practical application scenarios where deficient or inaccurate > models limit present development. ` > Openness and Reproducibility are two essential components in conducting > rigorous machine learning driven research, and this workshop seeks to > highlight and encourage both of these to help further increase the maturity > of communications as a data science. > · Authors are strongly encouraged to utilize open tools such as > pre-publication (e.g. ArXiv), providing reference code, data, simulations, > GNU Radio modules, etc. openly (e.g. Github), and fully describe their > methodologies in an open and re-producible way such that others can easily > validate, leverage and build upon their work. > · For accepted workshop papers meeting such criterion, IEEE ComSoc is willing > to provide as Open-Access publications at no additional fee to the authors! > > MLC Dataset Challenge: In this year’s ICC 2020 Open Workshop, we are also > excited to announce an open-dataset challenge focused on the unique task of > Vision-Aided Beam Tracking for mmWave Systems. This challenge will adopt the > recently developed ViWi dataset. Additional details of the competition and > submission will be provided in early February 2020 via the workshop webpage: > https://icc2020.ieee-icc.org/workshop/ws-19-open-workshop-machine-learning-communications > > <https://icc2020.ieee-icc.org/workshop/ws-19-open-workshop-machine-learning-communications>. > The workshop expects to announce results at the ICC’2020 on a hold-out test > set and invite competitors to share their approaches and experiences. > > We invite submissions of unpublished works on the application and theory of > machine learning to communications. The workshop shall not restrict the type > of machine learning techniques and applications but does provide the > following list is a non-exhaustive list of suggested topics. > · Machine learning driven design and optimization of modulation and coding > schemes > · Machine learning techniques for channel estimation, channel modeling, and > channel prediction. > · Machine learning based enhancements for difficult to model communications > channels such as molecular, biological, multi-scale, and other > non-traditional communications mediums > · Transceiver design and channel decoding using deep learning > · Machine learning driven techniques for radio environment awareness and > decision making > · Machine learning for Internet of things (IoT) and massive connectivity. > · Machine learning for ultra-reliable and low latency communications (URLLC). > · Machine learning for Massive MIMO, active and passive Large Intelligent > Surfaces (LIS). > · Distributed learning approaches for distributed communications problems > · (Deep) Reinforcement Learning and Policy learning for resource management & > optimization > · Reinforcement Learning for self-organized networks and AP/BTS optimization > · Mach
Re: [Discuss-gnuradio] gr-eventstream OOT module
On 04/17/2017 05:26 PM, Cinaed Simson wrote: Hi - anyone using gr-eventstream? If I recall correctly, gr-eventstream depends upon gr-mapper gr-framers gr-burst python-bitarray it does not depend on any of these ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] flow graph reconfiguration when using tagged streams
Use async message blocks, whatever you are doing is probably a bad idea On 02/12/2017 04:29 PM, Damindra Bandara wrote: > Hi, > > I am trying to reconfigure a flow graph that uses tagged streams. When > I lock() and unlock() the flow graph(or stop()--> wait() and start()) > the blocks that uses tagged streams produce 'Missing length tag key' > error. The problem does not appear if I reinitiate all the blocks that > use tagged streams. Is there a way to reconfigure a flow graph that > uses tagged streams with out reinitiating all the blocks? I appreciate > if you could help. > > Thank you, > Damindra > > -- > Damindra Savithri Bandara, > Ph.D. in Information Technology (Candidate) > George Mason University, > Fairfax, > Virginia > > > ___ > 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] Keep M in N
I'd venture to say M>N is living in dangerous territory On 10/06/2016 10:56 AM, Marcus Müller wrote: > > Hi Steve, > > The first M of each N. :) (I don't really understand 100% what "every > N/M" would be in general for arbitrary N>=M, integers). > > If you dare to venture into the GNU Radio source code (which I'd > encourage you to do, it's just that this isn't the most > beautiful/interesting block), you'll find that the implementation [1] > simply memcopys the first m items of every n-chunk from in- to output. > > Best regards, > > Marcus > > [1] > https://github.com/gnuradio/gnuradio/blob/master/gr-blocks/lib/keep_m_in_n_impl.cc#L111 > > On 06.10.2016 16:22, Steve Gough wrote: >> Hi mailing list, >> >> I have a question regarding the Keep M in N block, which keeps M out >> of every N samples. Is this the first M samples in every N which it >> retains (or) is it every N/M ? >> >> Thanks! >> Steve >> >> >> ___ >> 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] GNU Radio Conference 2016 Technical Proceedings Now Available!
The technical proceedings / papers from this year's GNU Radio Conference are now available online! This is the first year we have had a technical proceedings to accompany the conference, participation by speakers was optional but offered a chance to provide a thorough long term reference for their work! Proceedings are open-access and may be viewed at http://pubs.gnuradio.org We are still working on getting google scholar to also index them ... To Authors, Thank you for taking the time to write a number of valuable contributions for the community to refer to your work in depth, and for making the proceedings a success this year! Please don't hesitate to send any updates or revisions you may wish to have included -- Regards, Tim http://pubs.gnuradio.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PSK31 (from audio to radio)
Hey hey! Glad to see someone using this. (And that it's apparently still working! Goodness... I need to clean this up...) I'm giving advice freehand right now, as I don't have my radios with me to test this. There are definitely more elegant ways for this solution, this is just the quickest I could think of without reverse engineering what I wrote forever ago. Since this is AM, I think you'll only need the Real port on your "Float to Complex" block. You can attach the "Null Source" to the Imaginary port. Do a quick check to make sure the real signal's not exceeding +/- 1... you might want to attenuate it to +/- 0.7 for now, someone else should comment. As far as the transmit side goes, I'd leave everything up to the "Multiply" block untouched. Consider that your "audio input" to the radio. After that... - Multiply Const (set to 0.7 for safety) - Polyphase Resampler (float/float) set to (1e6 / 48e3) - This gets your sample rate up to radio speeds - Float to Complex (in the Real port, Null Source to the Imag port) - This makes your signal "complex AM" - Send the Complex stream into your Osmocom Sink (set to 1e6 sps) - And transmit! If I remember correctly, some radios don't like working at non-integer sample rates. (The hackRF may be ok though...) Play gently with your TX gain until you can see it on another radio. (IIRC the HackRF is simplex... perhaps an RTL?) Use AM to demodulate. I've been meaning to do a write up on this for a while. If I ever get around to it, I'll make sure to CC you. - Tim On Fri, Sep 2, 2016 at 11:55 PM, pen tester <testerofp...@gmail.com> wrote: > Hi, > I am trying to get a simple working example of PSk31 working (transmitting > with a hackrf and receiving with a rtlsdr dongle). Here is what I have so > far. > > > Working PSK31 tx and rx with a sound card > == > Transmit: https://github.com/tkuester/gr-psk31/ (examples/psk31_tx.grc) > Receive: https://github.com/tkuester/gr-psk31/ (examples/psk31_rx.grc) > > These work great for sending a PSK31 message over audio card and receiving > with the audio card. > > I just slightly modified them to take input from the "Audio Source" block > instead of a "Wav File Source" to use the sound card directly: > > Transmit Graph: http://www.megafileupload.com/7sm9/psk31_tx.grc > Transmit Image: http://pasteboard.co/giNm3kNzC.png or > http://www.megafileupload.com/7smc/psk31_tx-audiocard.png > > Receive Graph: http://www.megafileupload.com/7sma/psk31_rx.grc > Receive Image: http://pasteboard.co/giOlxtWUf.png or > http://www.megafileupload.com/7smb/psk31_rx-audiocard.png > > Turning up the audio a little and tuning to 2003 approx on the rx graph > results in reception of the sent message "Hello World!" > > > > Reference version for using hackrf instead of sound card > == > Next, I wanted to modify these to audio versions to work over Radio using > a HackRF and RTLSDR dongle. > > These graphs seems very useful but I couldn't get it working end to end > for some reason. > > Transmit: https://github.com/argilo/sdr-examples (multi_tx.grc) > Receive: https://github.com/argilo/sdr-examples (tutorial/6_psk.grc) > > I made some changes to the freq to be in range for RTLSDR .e.g changed > freq from 441e6 in ref graph, changed to 841e6. > > > > My merged attempt > = > The attempt I am currently trying to get working is based on the audio > soundcard flies for the transmit: > > Transmit: Using audio tx (psk31_tx_attempt2): where I just replaced the > audio sink with the Osmocom sink (not sure what else is needed here for > transmission over hackrf) > > Transmit Graph: http://www.megafileupload.com/7smi/psk31_tx-attempt2.grc > Transmit Image: http://pasteboard.co/giOMGNqD9.png or > http://www.megafileupload.com/7sme/psk31_tx-attempt2.png > > Receive Graph: http://www.megafileupload.com/7smh/6_psk-hackrf.grc > Receive Image: http://pasteboard.co/giPflR4TI.png or > http://www.megafileupload.com/7smf/6_psk_hackrf.png > > For the receive, I just left radio rx part in and replaced the decoder > parts with decoding logic from https://github.com/tkuester/gr-psk31/ > (examples/psk31_rx.grc). I made other minor changes such as freq and sample > rates. > > > > My question > > So in summary, just looking for a little guidance on my merged attempt to > get psk31 out over a hackrf and received using a RTLSDR. Any advice for a > learner would be great :-) > > > > ___ > 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] gr-psk31
Hey there! Boy, it's been a long time since I touched that code. It's very "hacked together", and needs some love! I'd recommend trying psk31_rx.grc with this video[1]. If you have youtube-dl, you can save it to a wav file. For the TX side, I didn't really get that flushed out properly. The audio sink doesn't like it when you stop sending samples to it, and I couldn't figure out a tidy way to clean things up. In the mean time, look at the vector source in psk31_tx.grc. \x80 is the "preamble" byte, and everything else is just plain ASCII. That should get you up and running! Maybe if I have some time later, I can get a transmitter block up and running with the osmocom sink. It's just a simple AM transmitter. - Tim [1] https://www.youtube.com/watch?v=qHNvp7FfP6E On Sun, Jul 10, 2016 at 1:12 AM, Eoin 0w3n <eoin.0...@gmail.com> wrote: > Hi, > I've been having some fun with gr-psk32 ( > https://github.com/tkuester/gr-psk31). > > The aim is to be able to send ascii with a hackrf nd then receive with > an rtlsdr. > >For now, I would just like to get the rx and tx examples working over > audio/soundcard. > >I just added an audio source block to the "psk_rx.grc" and left the > "psk_tx.grc" example as-is. > >When trying to tune on the right hand wide waterfall, I seem to get > something close around 1850. I end up receiving "holmoewnrmg\n" which looks > to be something related to the transmitted "hello world!\n" vector in the > example. > >Has anyone got the tx and rx working for gr-psk32? Im sure its just a > small setting somewhere. > >Thank you :-) > > > ___ > 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] Process for relinquishing driver control in a flowgraph before starting a new one
I found a workaround that's not so pretty, but it works. Setting the flowgraph to None does not work for me because it makes my other python threads that are running throw errors. The problem turns out is more of a low level hardware problem, or at least that's the case for when I use my specific hardware driver. The file descriptor my hardware was open on was closed, but an error occurred when restarting the flowgraph in closing and reopening the file descriptor. I cannot track down what exactly is causing the error, but instead of fixing it, I just took out the close(fileDescriptor) line in my code. This doesn't harm the system because the same file descriptor is use anyway when the flowgraph is restarted. I also realized that having a global flowgraph will be difficult to change within python, so I made a wrapper class that holds the flowgraph as a member variable, and made the class global instead. On top of this, when I restart the flowgraph, I change the wrappers flowgraph, and then set a member variable flowgraph in the socket class to be equal to the wrapper's flowgraph. This might be overkill, but it works. #I import that object into my server code import flowgraphInit from flowgraph #I can also import my other flowgraph import newFlowgraphConstructor from flowgraph2 class wrapper(): __init__(self): self.flowgraph = flowgraph #At global level flowgraph = flowgraphInit() flowgraph.start() wr = wrapper() class ClientSocketConnection __init__(self): self.flowgraph = wr.flowgraph #other functions def onMessage(payload): #Parse message #If we need to change to a different flowgraph wr.flowgraph.stop() wr.flowgraph.wait() time.sleep(5) self.resetFlowgraph() def resetFlowgraph(self): wr.flowgraph = newFlowgraphConstructor() wr.flowgraph.start() self.flowgraph = wr.flowgraph def main(): #create socket factory so we can allow many connections On Fri, Jul 8, 2016 at 10:35 AM, Dave NotTelling <dmp250...@gmail.com> wrote: > Tim, > > One thing I have found with the Python stuff is that you need to set > the flow graph variable to None for resource to be released. moo = > myGraph(); moo.start(); time.sleep(10); moo.stop(); moo.wait(); moo = None; > moo = myGraph(); moo.start() . > > -Dave > > On Thu, Jul 7, 2016 at 6:14 PM, Tim Castiglia <cas...@rpi.edu> wrote: > >> First I should give some context on my project. What we are trying to >> build is a python server that utilizes gnuradio's blocks to get information >> from hardware and send it outbound, as well as receiving requests from >> clients to the server about configuration of flowgraph. More specifically, >> right now, I have: >> >> Oscom Source -->Log Power FFT --> Vector Probe >> >> For simplicity, I am using the RTL-SDR for testing purposes. In the >> future, we will be using our own device driver created within the SoapySDR >> framework, hence why we are using the oscom block. >> >> The problem starts with the fact that this may not be the only flowgraph >> we utilize. The hardware we are using may start pumping out FFT values >> instead of IQ values. Which means we would need a flowgraph that looks more >> like: >> >> Oscom Source --> Vector Probe >> (Ignore the fact that this is not possible with the oscom block >> currently, we will cross that bridge in the future) >> >> So I need to be able to stop my current running flowgraph, and start a >> new one. This is where I run into trouble. I can stop my flowgraph >> perfectly fine with: >> >> flowgraph.stop() >> flowgraph.wait() >> time.sleep(5) >> >> But I would like to keep the variable the same in my python code even >> when I change the flowgraph. So I try: >> >> flowgraph = newFlowgraphConstructor() >> >> But this causes a python error at the flowgraph.stop() line: "variable >> mentioned before instantiated" >> >> To get around this, I made a resetFlowgraph function: >> def resetFlowgraph(): >> flowgraph = newFlowgraphConstructor() >> flowgraph.start() >> >> and call things in this order: >> flowgraph.stop() >> flowgraph.wait() >> time.sleep(5) >> resetFlowgraph() >> >> The flowgraph starts successfully, but fails to "claim" the RTL-SDR from >> the old flowgraph. I have also tried the same with only my device plugged >> in, and a similar problem occurs. Is there a way to force the flowgraph to >> relinquish its hold on the hardware? Our python server code needs to >> continue running, so I need to be able to do this restart without ending >> the program (The id
[Discuss-gnuradio] Process for relinquishing driver control in a flowgraph before starting a new one
First I should give some context on my project. What we are trying to build is a python server that utilizes gnuradio's blocks to get information from hardware and send it outbound, as well as receiving requests from clients to the server about configuration of flowgraph. More specifically, right now, I have: Oscom Source -->Log Power FFT --> Vector Probe For simplicity, I am using the RTL-SDR for testing purposes. In the future, we will be using our own device driver created within the SoapySDR framework, hence why we are using the oscom block. The problem starts with the fact that this may not be the only flowgraph we utilize. The hardware we are using may start pumping out FFT values instead of IQ values. Which means we would need a flowgraph that looks more like: Oscom Source --> Vector Probe (Ignore the fact that this is not possible with the oscom block currently, we will cross that bridge in the future) So I need to be able to stop my current running flowgraph, and start a new one. This is where I run into trouble. I can stop my flowgraph perfectly fine with: flowgraph.stop() flowgraph.wait() time.sleep(5) But I would like to keep the variable the same in my python code even when I change the flowgraph. So I try: flowgraph = newFlowgraphConstructor() But this causes a python error at the flowgraph.stop() line: "variable mentioned before instantiated" To get around this, I made a resetFlowgraph function: def resetFlowgraph(): flowgraph = newFlowgraphConstructor() flowgraph.start() and call things in this order: flowgraph.stop() flowgraph.wait() time.sleep(5) resetFlowgraph() The flowgraph starts successfully, but fails to "claim" the RTL-SDR from the old flowgraph. I have also tried the same with only my device plugged in, and a similar problem occurs. Is there a way to force the flowgraph to relinquish its hold on the hardware? Our python server code needs to continue running, so I need to be able to do this restart without ending the program (The idea is to have the server always be running and not be manned most of the time). Here's some pseudo code to give you an idea of how the code is structured: #First I have a premade object generated from gnuradio-companion #I import that object into my server code import flowgraphInit from flowgraph #I can also import my other flowgraph import newFlowgraphConstructor from flowgraph2 #At global level flowgraph = flowgraphInit() flowgraph.start() class ClientSocketConnection ...#init and other functions def onMessage(payload): #Parse message #If we need to change to a different flowgraph flowgraph.stop() flowgraph.wait() time.sleep(5) resetFlowgraph() def resetFlowgraph(): flowgraph = newFlowgraphConstructor() flowgraph.start() def main(): #create socket factory so we can allow many connections #So there is only one flowgraph, but many people can see it and potentially change it (I have seen this question asked before here https://lists.gnu.org/archive/html/discuss-gnuradio/2014-01/msg00411.html but there was no solution in the thread) Any help is appreciated! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio Conference 2016 Technical Proceedings Call for Papers (extended date: now July 18)
We are excited to be including our first ever GNU Radio Conference Technical Proceedings this year at GRCon16! Proceedings provide a great format in which talks and ideas can be documented and explained in great detail, easily found, referenced and built upon by attendees and non-attendees in the future! So far we have had a very positive reception to this addition to GRCon, and have received a number of excellent submissions. However, due to the extension of the talk abstract submission deadline, generally busy summertime happenings, and the hope to give more people time to participate, *we are extending the draft paper submission date to July 18, 2016*. We hope that everyone planning to give a talk at GRCon this year will *strongly consider submitting a technical article* to accompany their talk as well and to help leave a more lasting impact on the community! As a reminder, information for authors along with our template can be found at http://gnuradio.org/grcon-2016/call-for-submissions/ Regards, Tim O'Shea Chair, GRCon16 Technical Proceedings ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] disabling UHD OOOOO... messages
It may be nice to have this as an option to disable, in case the user wants to reserve stderr for their own purposes. On Wed, May 11, 2016 at 9:28 PM, Marcus D. Leechwrote: > On 05/11/2016 06:24 PM, Engin Karabulut wrote: > >> loosing samples isn't important for my application, my sample rate is 4 >> Msps but my CPU is weak(Intel N3150I). so I only want to disable these >> annoying messages. >> >> If your application doesn't also use stderr, you can just: > > your-application 2>/dev/null > > > > > > ___ > 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] Tutorial on BPSK bursts
It's not terrifically designed, but you might find my PSK31 repo helpful. According to Balint though, the PLL is supposed to go after clock recovery, not before. https://github.com/tkuester/gr-psk31 - Tim On Fri, Mar 4, 2016 at 8:56 PM, Jesse Reich <jrre...@gmail.com> wrote: > So I've been playing with GNU Radio for about 2 months and trying to learn > about signals and signal processing in general. Mostly out of curiosity > that has sprung up from my profession. I am an Aerospace engineer by > training and I work as a satellite ground systems engineer for the > Cospas-Sarsat program. > > I've started with what I thought should be an easy task with aspirations > of more complex tasks. The first task, decode a BPSK signal modulated on a > 406 MHz carrier. The signals consist of a 160 ms carrier, 24 sync bits and > then 120 data bits at 400 bits/sec. I'm just trying to decode and write the > bits. Sounded to me to be an easy problem to tackle. Unfortunately I can't > seem to even get off of the ground. Does anyone know of any tutorials that > would be good. > > I've tried the gnuradio tutorials and honestly they don't really seem to > help. Any help would be greatly appreciated. > > Thanks, > Jesse > > ___ > 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] An End-to-End working example for GNU Radio on Zedboard
Very cool. I'd be interested in looking into this further. Am I correct in thinking that you didn't have the FPGA pass from QD to the filters? That is to say, each block went into the FPGA, and back to the computer? - Tim On Tue, Jan 26, 2016 at 2:08 PM, Alireza Khodamoradi < ar.khodamor...@gmail.com> wrote: > Hi everyone, > > I like to share our source code and some tutorials on how to implement and > use GR on ZedBoard. You also can find custom blocks in GR designed to > interact with XIllybus that you can use as drag and drop in GRC. > > https://bitbucket.org/maswes/gnuradio_on_fpga-cohort3/wiki/Home > > Cheers, > Alireza > > ___ > 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] Asynchronous source with zeros in between
You may want to look at gr-eventstream source block, this is exactly what it is intended to do, precisely timed if desired On Mon, Nov 30, 2015, 2:38 PM Francisco Albaniwrote: > Hi to all. > > (this email subject may be inaccurate) > > I need a block with the following characteristics: > > * Input port for messages. > * Output port for complex/float/byte/etc. stream. > * Forecast always answers 0. > * Work function first check the message queue. If there are no messages, > emits zeros; if there are, it emits the samples inside the message. > > I'm willing to write it, but first I want to hear from the people in the > list in case this can be crafted using existing blocks or if this idea is > deemed to fail for some reason I can't see. > > I need this in order to transmit N parallel burst radios using something > like Polyphase Channel Synthesizer. The problem emerges when not all the > transmitters have data to send and stop the other transmitters flows. > > Many thanks! > > Bye. > ___ > 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] Working with Tags
Hey all, I just saw Tom has a patch for a similar bug I had relating to tags and resampling. Just bringing this to the discussion in case it helps anyone else! http://gnuradio.org/redmine/issues/831#change-2511 - Tim On Mon, Jan 4, 2016 at 8:55 AM, <mark.w.christian...@l-3com.com> wrote: > My tag generator takes data packets that are time stamped for the first > sample of each packet and needs to tag the stream produced in the work > function. I tag starting m_tag_offset = 0 and then increment by the number > of samples from my packets after each time I add_item_tag(). > > > > I wouldn’t care so much about the tags stopping except that I sometimes > have a dropped packet and the timing is off from then on. > > > > *From:* discuss-gnuradio-bounces+mark.w.christiansen=l-3com@gnu.org > [mailto:discuss-gnuradio-bounces+mark.w.christiansen=l-3com@gnu.org] *On > Behalf Of *Paul David > *Sent:* Thursday, December 31, 2015 6:47 PM > *To:* Tom Rondeau > > *Cc:* GNURadio Discussion List > *Subject:* Re: [Discuss-gnuradio] Working with Tags > > > > Weird. I don't see a problem between strobe_tags -> moving average -> > vector sink with my test. How is m_tag_offset getting set? > > > > On Thu, Dec 31, 2015 at 7:43 PM, Paul David <pudda...@gmail.com> wrote: > > I'm gonna check this out. I may have fixed this according to the tests we > were looking at, but introduced a bug elsewhere. > > A QA test involving the moving average blocks and stream tags might help > clear things up. > > > > On Thu, Dec 31, 2015 at 10:38 AM, Tom Rondeau <t...@trondeau.com> wrote: > > On Wed, Dec 30, 2015 at 3:32 PM, <mark.w.christian...@l-3com.com> wrote: > > It’s a tag generator that goes through several other blocks before getting > to the tag receiver. > > > > tag generator - mag^2 - moving average --- divide - add > constant - tag receiver > >\- moving average -/ > > > > Basically I’m computing the ration of a fast average to a slow average and > sending that to a threshold detector sink (tag receiver) to watch for the > signal to go above threshold. It then sends a message with the time stamp > of that event to another block for other processing. I wrote the tag > generator and tag receiver. > > > > Mark. > > > > > > I'd recommend plugging the tag generator directly into the tag receiver > just to make sure both of those are handling the tags properly. If they > are, then we can dive into the rest of the chain to see where things might > be having problems. My guess is that it'll be related to the different > delays of the moving average filters. > > > > This also might be related to a bug that we recently patched: > > > https://github.com/gnuradio/gnuradio/commit/ae2e24f86b562a5bdcb9f5170e0abb1cd15838cf > > > > Tom > > > > > > > > > > *From:* trond...@trondeau.com [mailto:trond...@trondeau.com] *On Behalf > Of *Tom Rondeau > *Sent:* Wednesday, December 30, 2015 9:36 AM > *To:* Christiansen, Mark W. @ CSG - CSW > *Cc:* GNURadio Discussion List > *Subject:* Re: [Discuss-gnuradio] Working with Tags > > > > On Wed, Dec 30, 2015 at 11:15 AM, <mark.w.christian...@l-3com.com> wrote: > > I wrote a block that writes the rx_time tag and another block that reads > it. After reading them for a 20 to thirty calls to the work function, it > stops getting any. The amount it reads varies from run to run. Any ideas? > > This code snippet is from the work function my block that writes the tag. > The cerr statement continues to print to the console until I stop execution. > > > > > > VITA49_packet_info packet_info = p_packet->get_VITA49_packet_info(); > > if (m_do_send_tags) > > { > > double timestamp_in_seconds = > > static_cast(p_packet->get_integer_seconds()) + > > static_cast(p_packet->get_fraction_seconds()) * 1e-12; > > const pmt::pmt_t timestamp = pmt::make_tuple( > > pmt::from_uint64(static_cast long>(floor(timestamp_in_seconds))), > > pmt::from_double(timestamp_in_seconds - > floor(timestamp_in_seconds))); > > std::cerr << "SEND (" << d_id << ") " > > << " tag_offset=" << m_tag_offset > > << std::setprecision(std::numeric_limits::digits10 > + 1) > > << " timesamp_in_seconds=" << timestamp_in_seconds << > std::endl; > > add_item_tag(0, m_tag_offset, TIME_KEY, timestamp, d_id); > &g
Re: [Discuss-gnuradio] Message inputs and hierachical block: incompatibility introduced in GNU Radio 3.7.9
Hi Piotr, Hier message ports were actually not working at all prior to this fix - - since the logic had been changed from the originally functioning pub/sub based message connection data structures into the more traditional digraph flattening structure incorrectly please see: http://gnuradio.org/redmine/issues/862#change-2460 This change was needed to correct the hier port flattening logic and was the originally intended API that got reversed somewhere along the way - GRC was updated to correspond -- Have you tested your hier message ports actually function with 3.7.8 successfully prior to this? I would be kind of surprised - Perhaps if you are writing python code, some kind of conditional check work around might be in order, or just dropping support for old versions as they did not function correctly -Tim On Sat, Jan 2, 2016 at 4:12 AM Piotr Krysik <per...@o2.pl> wrote: > Hi all, > > In GNU Radio version 3.7.8 message inputs of hierarchical blocks were > created from python level with: >self.message_port_register_hier_out("msg_in") > > Starting (most probably) from GNU Radio 3.7.9 message inputs are created > with: >self.message_port_register_hier_in("msg_in") > > This leads to incompatibility. I can't now distribute to the users > python code of hierarchical blocks generated with GRC because for some > of them it won't work (if they don't use the same GNU Radio version as I > do). Compilation of GRC files to python with grcc during building is not > an option as it doesn't work reliably yet and it will lead to higher > level of problems. > > Currently I manually added this code to my hierarchical blocks in order > to make them work on with GNU Radio earlier than 3.7.9: > > from distutils.version import LooseVersion as version > > if version(gr.version()) >= version('3.7.9'): > self.message_port_register_hier_in("msg_in") > else: > self.message_port_register_hier_out("msg_in") > > Is it possible to fix this problem for example on the level GRC - so it > generate code that is compatible with GNU Radio versions < 3.7.9 and > >=3.7.9? > > Best Regards, > Piotr Krysik > > ___ > 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] OOT module authors, please update your cmake
Could there be perhaps a `gr_modtool update_cfiles`? On Tue, Dec 29, 2015 at 8:55 PM, Michael Dickenswrote: > On Tue, Dec 29, 2015, at 08:30 PM, Johnathan Corgan wrote: > > On Tue, Dec 29, 2015 at 5:08 PM, Philip Balister > wrote: > > Dunno, but gr-newmod (or whatever it is called) in gnuradio has a copy > of the files. I had to fix the issue twice. > > > This is good opportunity then to see what we can now remove from gr-newmod. > > > Yes! Or, whatever the name ends up being. +1 from me! > > ___ > 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] Help decoding Bell 202
En, Ah! Sitting and playing with it greatly helped my understanding of the problem. 1. Your capture seems to have some distortion on it. Fortunately, this doesn't affect FM too bad, but you may want to crank your gain back. 2. Remember, Bell 202 uses 1200 Hz and 2200 Hz. You probably don't want 1200 Hz as the corner for your LPF. FSK Demod already has one as well, I just removed it. 3. I listened to the transmissions, and looked at the data. It does sound like Bell 202, and appears to have HDLC frames... but it doesn't sound like APRS. May I ask where you got this? What I got after removing the LPF: http://i.imgur.com/Z3EbIgU.png - Tim On Mon, Dec 28, 2015 at 12:07 AM, En Shih <seanstone5...@gmail.com> wrote: > Thanks, Tim. That really clarified a lot of confusion that I had! > > I have uploaded the files here: > > https://drive.google.com/folderview?id=0B5T4PFVUKZgmcXlTWnV0VzZFQTg=sharing > < > https://drive.google.com/folderview?id=0B5T4PFVUKZgmcXlTWnV0VzZFQTg=sharing > > > -"bell202new.grc" is the current flow graph. > -"dump" is how the input signal I'm trying to decode looks like. > -"decoded" is the bytes of a successfully decoded signal, which was decoded > previously using some hardware equipment. (some parts of the data may be > corrupted) > -"imet.pdf" explains the data packet. > -"tcp.py" explains the data packet. > > As far as I know, at the physical layer the data is modulated using Bell > 202. The data framing is not AX.25, but conforms to UART, although I'm > unsure about the parity and stop bits. I tried looking for the data frames > by looking for start/stop bits, the header. I've also tried flipping the > bits. However, it still doesn't look quite right. > > Correct me if I'm wrong: your FSK demod block uses tone detection to > demodulate, which is passing the signal through two band pass filters in > parallel, and determine which comes through (as in p.9 of > http://edge.rit.edu/edge/P09141/public/FSK.pdf) > > Regards, > En Shih > > > > > -- > View this message in context: > http://gnuradio.4.n7.nabble.com/Help-decoding-Bell-202-tp57483p57503.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] Help decoding Bell 202
Just some obsesrvations... - Why do WBFM to Audio? Shouldn't that be NBFM? - Your post NBFM receive looks good. - Your QD output looks a little strange. Perhaps look at the FFT of your signal before the QD? - In my experience the MM Clock Recovery block likes using ~4 sps. Perhaps use the Rational Resampler to decimate by 10 first? - 2 MHz / 40 = 50 kbps... did you mean to be working with 1200 baud? I've done my own "1200 baud AFSK" receiver, you may be interested in it. https://github.com/tkuester/gr-bruninga - Tim On Sun, Dec 27, 2015 at 7:52 AM, En Shih <seanstone5...@gmail.com> wrote: > Hi all, > > I am trying to decode a Bell 202 signal from a RTL dongle source using GNU > Radio Companion 3.7.8.1. > I am new to GNU Radio and signal processing, and constructed this flow > graph > by searching previous topics on AFSK: > > <http://gnuradio.4.n7.nabble.com/file/n57483/2015-12-27_20-51-40.png> > first by passing through a NBFM and then a quadrature demod, but I can't > recover the expected signal, which should have bytes 01 04 or 01 01 at the > start of a packet. > > This is how the signal looks like: > > 1. RTL-SDR source > <http://gnuradio.4.n7.nabble.com/file/n57483/signal1.png> > > 2. After NBFM receive > <http://gnuradio.4.n7.nabble.com/file/n57483/3.png> > > 3. After quadrature demod > <http://gnuradio.4.n7.nabble.com/file/n57483/5.png> > > 4. Final > <http://gnuradio.4.n7.nabble.com/file/n57483/6.png> > > Does it look like I am on the right track? > > The grc file, a dump of the original signal, and a decoded file is stored > here: > > https://drive.google.com/folderview?id=0B5T4PFVUKZgmcXlTWnV0VzZFQTg=sharing > < > https://drive.google.com/folderview?id=0B5T4PFVUKZgmcXlTWnV0VzZFQTg=sharing > > > The decoded file was done using a physical modem, and its contents does not > match the dump but is in the same format. > > I have also tried using multimon-ng > <https://github.com/EliasOenal/multimon-ng> with the following command: > rtl_fm -f 40200 -s 22050 | multimon-ng -a AFSK1200 -t raw /dev/stdin > but to no avail. > > Thanks. > > Regards, > En Shih > > > > -- > View this message in context: > http://gnuradio.4.n7.nabble.com/Help-decoding-Bell-202-tp57483.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] Help decoding Bell 202
En, It's hard to judge exactly from your screen shots... if I had your .grc files and sample inputs, I might be able to do a little better! You may find the APRS test CD [1] useful, if you haven't used it already. Here's what I get using the test CD, and aprs-wav.grc. I happened to take the screenshot just at a good moment! You can consider the bottom graph to be the output of the QD block, though in this implementation it's measuring the difference in amplitude of the 1200 and 2200 Hz tones. First, I should note, people use Bell 202, AFSK, AX.25, and APRS interchangeably... but they are not! - Bell 202 is the physical layer spec, which sends data 1200 baud with 2FSK. The "tones" used are 1200 Hz and 2200 Hz. - AFSK is a term I don't like very much... audio frequency shift keying? It often refers to Bell 202, although wouldn't P.25 C4FM be audio frequency shift keying as well? Either way, I digress! - AX.25 is a protocol which specifies a packet format and communication standard. Interestingly enough, it does not specify the physical layer at all. - APRS is an application of AX.25 which almost exclusively uses Bell 202 and NBFM VHF radios to send packets with position reports. (Much to the designer's chagrin, I might add... but when you only have UDP style frames, ensuring receipt is rather difficult...) Most of what I'm writing focuses on a generic APRS application. Anyways, with that out of the way! I'll start my discussion at the end of the receiver, and work my way back to the "audio waveform" itself. http://i.imgur.com/KOBLLDz.png The top graph shows the recovered "bits". Note how there is nice separation between the 1's and 0's, and how the waveform is nicely centered around 0. This should lead to good data recovery. The bottom graph (although not aligned with the top graph) shows the data waveform just before clock recovery. You can see the distinctive "HDLC frame sync byte" of 0x7e (ASCII ~) being repeated over and over again. This is in contrast to other radios that use (0x55) and a sync word. You can read more about it here: https://en.wikipedia.org/wiki/High-Level_Data_Link_Control http://i.imgur.com/HV3EjTE.png In the bottom graph, you can see the original audio signal. If you look very closely, you might even be able to see the sync byte being repeated (0x7e, or 0110). Unlike your application which uses the QD block to demodulate the FSK, I'm doing a receiver more like the one you can find here on page 9. ( http://edge.rit.edu/edge/P09141/public/FSK.pdf) That's why there's a red and blue waveform that are near compliments of each other. You may find this paper interesting as well, as it explains many of the troublesome points of APRS. http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=2449=theses - Tim On Sun, Dec 27, 2015 at 10:00 AM, En Shih <seanstone5...@gmail.com> wrote: > Thanks for the reply, Tim. > > - The WBFM is a remnant I've never corrected. I now have the audio from > NBFM. > - The baudrate is 1200. > > This is the Fourier after Hilbert before QD: > <http://gnuradio.4.n7.nabble.com/file/n57488/13.png> > <http://gnuradio.4.n7.nabble.com/file/n57488/11.png> > and the corresponding time plot: > <http://gnuradio.4.n7.nabble.com/file/n57488/10.png> > <http://gnuradio.4.n7.nabble.com/file/n57488/12.png> > I am unsure if that looks right or not. > > Is it so that the signal after QD should look something like this? > <http://gnuradio.4.n7.nabble.com/file/n57488/demod_timedomain.png> > (image taken from > > http://www.indigresso.com/wiki/lib/exe/fetch.php?media=opentag:radios:demod_timedomain.png > ) > > I have tried your FSK demodulator block, and the initial result looks nice. > <http://gnuradio.4.n7.nabble.com/file/n57488/2015-12-27_23-35-40.png> > <http://gnuradio.4.n7.nabble.com/file/n57488/2015-12-27_23-40-37.png> > <http://gnuradio.4.n7.nabble.com/file/n57488/2015-12-27_23-38-51.png> > However, I haven't been able to identify the characteristic preamble for > each data packet. Am I using the block correctly, or is there some > tweaking/synchronization that I should do? > > Regards, > En Shih > > > > > -- > View this message in context: > http://gnuradio.4.n7.nabble.com/Help-decoding-Bell-202-tp57483p57488.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] asynchronous messaging frameworks
For most applications, I would suggest building a python native GNU Radio message block to interact with a graph -- and *not* jumping to thrift or zmq without a reason -- bridging messages and streams over zmq IPC is doable but more work -- in this case PMT serialization and JSON are the most used message formats - valid reasons might be if gnu radio is secondary to your app and you want a large layer of separation, process separation, or remote message passing -Tim On 12/27/2015 11:42 AM, Marcus Müller wrote: > Hi Daniel, > > On 12/27/2015 03:10 PM, Daniel Pocock wrote: >> Is there any generic documentation about the use of GNU Radio with >> asynchronous messaging and integration frameworks or would it be useful >> to build up a wiki page about the topic? > There's internal asynq messaging in GR (the "light grey" connections > between blocks); message passing is relatively well-documented in the > doxygen [1], and there's a bit on it in the guided tutorials[2]. > As everything, it could be better documented :) Documentation patches > for the doxygen are always as welcome as wiki extensions. > For the RPC beneath the controlport interface[3] we use Apache Thrift. > There's also the XMLRPC, but I'm not experienced with that. I hear you > can develop web-style applications with it easily. > > For network and IPC, we basically support zeroMQ, UDP, and of course > simple Unix mechanisms like FIFOs and everything that can get a file > descriptor. >> I came across some pages referring to ZeroMQ support[1], I was also >> curious about support for Qpid Proton[2] and other AMQP[3] systems. >> There were some comments elsewhere about people using OpenMAMA[4] >> (designed for low-latency financial messaging) to transport radar data, >> among other things. >> >> Another possibility that comes to mind is D-Bus[5] support, either at a >> low-level (other desktop applications controlling the radio or receiving >> data from the radio) or high level (e.g. a Telepathy Connection >> Manager[6] implementing one of the various digital messaging >> solutions[7] or even Morse code) > I personally don't know of any implementation of adapters for any of > these; however, writing e.g. a dbus to message passing adapter won't be > too hard. In fact, it should be but a couple of lines of python, unless > things get overly involved with business logic etc. > > For your App-to-GNU Radio adaption, ZeroMQ pretty much sounds like a > perfect match. It's leightweight, multi-language, easy to learn. >> This could be a good way to further empower people familiar with other >> systems, e.g. there was some question a while ago about how gpredict >> could integrate with GNU Radio for real-time doppler shift >> correction[8]. Doing such things over an asynchronous message bus leads >> to looser coupling, so it is easier to swap components for >> test/simulation or add more components to the architecture. > I really cannot stress enough how right you are: GNU Radio definitely > needs to get as "usable" from an application developer's perspective. > Easy solutions for sending information to and from applications are most > of the times sufficient; ZeroMQ definitely has become my tool of choice > for that. However, at some level of complexity, you start to implement > remote procedure calling. > RPC, however, isn't easy. You might really want to stick with > controlport, which is deeply integrated in GNU Radio, and its thrift > foundation, if you have the choice. > > Best regards, > Marcus > > [1] http://gnuradio.org/doc/doxygen/page_msg_passing.html > [2] > https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_Programming_Topics#53-Message-Passing > [3] http://gnuradio.org/doc/doxygen/page_ctrlport.html > > ___ > 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] ham/amateur getting started
Hey Dan, you may be interested in this app! https://github.com/madengr/ham2mon - Tim On Wed, Dec 23, 2015 at 3:47 PM, Daniel Pocock <dan...@pocock.pro> wrote: > > > Hi all, > > I did a quick search for resources for ham/amateur operators getting > started with GNU Radio, I came across these: > > http://gnuradio.org/redmine/projects/gnuradio/wiki/HamRadio > http://www.oz9aec.net/index.php/grc-examples > > Both of them refer to receivers, the latter has an SSB transmitter as well. > > Is there any more getting started documentation about full transmit and > receive solutions for popular amateur bands like 2m and 70cm narrow band > FM? > > Regards, > > Daniel > > ___ > 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] Renaming PyBOMBS
Most new users should be installing gnu radio binaries via their os package manager repos or ppa. Pybombs should be used for 1. Helping get up to date oot modules set up and deployed ( like pip ) and 2. Helping developers set up their development environment. So I'm not sure installer is the right idea to impart on new users at all On Wed, Dec 23, 2015, 1:23 PM Richard Bellwrote: > I'd like to throw in another point from an entry level perspective. Those > people who might need pybombs most, are those who need names that tell them > what it's for the most. Even if it is incorrect to call pybombs an > installer, it would really help the entry level folks (which I would claim > without support is the largest population of the community at any given > time) understand what it's for and how they should use it. I think we all > have the experience of learning new tools and running into tool names, > which even though the description is spot on for what its for, at the time > carried zero value for the new guy using it (thinking mostly about Xilinx > tool names here). > > With that said, I think it would be good for the community to use the word > installer in the tool that makes gnuradio and uhd really easy to install, > and is what the vast majority of people I'm guessing would use it for. > > On Wed, Dec 23, 2015 at 10:02 AM, Martin Braun > wrote: > >> On 23.12.2015 09:28, Stefan Wunsch wrote: >> > I don't want to destroy your idea, but GRAB sounds like CRAP as well and >> > you can think of the associated sentences ;) >> >> 'grab' is also a very common english verb, so I think people would be >> able to distinguish. It also sounds like 'crab' if you like :) >> >> M >> >> > >> > On 12/22/2015 09:31 PM, Richard Bell wrote: >> >> GRAB = Gnu RAdio Basic installer >> >> >> >> Then we can say things like "Go GRAB it" when referring to a needed >> module >> >> >> >> On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun > > >> >> wrote: >> >> >> >>> There's been some demand to rename PyBOMBS, and now that we're >> >>> re-releasing it, this is a good time to think about it. Complaints >> about >> >>> the name include: >> >>> >> >>> - It may or may not be true that people have been detained by TSA for >> >>> working on PyBOMBS at the airport[1] >> >>> - The name suggests a Python-related packages (like Pylint, PyPI...) >> >>> rather than a GNU Radio-related tool >> >>> - People can't agree on a capitalization >> >>> - No one can remember what the acronym stands for >> >>> >> >>> Sure, this is not a critical thing, but now's a good chance to bring >> it >> >>> up and also, this is not a joke :) >> >>> >> >>> Here's how we're going to do this: >> >>> >> >>> - Please suggest new names in this thread. >> >>> - I will choose from those names based on 'can I live with this name', >> >>> 100% subjectively. >> >>> - New names will be put up for a vote. This will include an option to >> >>> keep the old name. >> >>> - Finally, the result of the vote will be used as a strong suggestion >> on >> >>> what the new name will be. >> >>> >> >>> There already have been some suggestions: >> >>> >> >>> - gromit -- the GNU Radio out-of-tree module installation tool >> >>> - the groot >> >>> - grpm -- the GNU Radio package manager >> >>> >> >>> >> >>> OK guys, bring up the ideas! >> >>> >> >>> Cheers, >> >>> Martin >> >>> >> >>> [1] It's not. >> >>> >> >>> ___ >> >>> 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 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] Renaming PyBOMBS
Ubuntu packages uhd Assuming other oses do too I'm sure there are up to date ppas somewhere too On Wed, Dec 23, 2015, 1:34 PM Richard Bell <richard.be...@gmail.com> wrote: > Is there a way for a new user to get uhd installed from the package > manager though? A lot of people want to dive right into gnu radio with > hardware, doing simple things like spectrum analysis. I'm not aware of a > way of getting the uhd + gnuradio setup running that's easier then pybombs. > I very well could be wrong here. > > On Wed, Dec 23, 2015 at 10:31 AM, Tim O'Shea <tim.oshea...@gmail.com> > wrote: > >> Most new users should be installing gnu radio binaries via their os >> package manager repos or ppa. Pybombs should be used for 1. Helping get >> up to date oot modules set up and deployed ( like pip ) and 2. Helping >> developers set up their development environment. >> So I'm not sure installer is the right idea to impart on new users at all >> >> >> On Wed, Dec 23, 2015, 1:23 PM Richard Bell <richard.be...@gmail.com> >> wrote: >> >>> I'd like to throw in another point from an entry level perspective. >>> Those people who might need pybombs most, are those who need names that >>> tell them what it's for the most. Even if it is incorrect to call pybombs >>> an installer, it would really help the entry level folks (which I would >>> claim without support is the largest population of the community at any >>> given time) understand what it's for and how they should use it. I think we >>> all have the experience of learning new tools and running into tool names, >>> which even though the description is spot on for what its for, at the time >>> carried zero value for the new guy using it (thinking mostly about Xilinx >>> tool names here). >>> >>> With that said, I think it would be good for the community to use the >>> word installer in the tool that makes gnuradio and uhd really easy to >>> install, and is what the vast majority of people I'm guessing would use it >>> for. >>> >>> On Wed, Dec 23, 2015 at 10:02 AM, Martin Braun <martin.br...@ettus.com> >>> wrote: >>> >>>> On 23.12.2015 09:28, Stefan Wunsch wrote: >>>> > I don't want to destroy your idea, but GRAB sounds like CRAP as well >>>> and >>>> > you can think of the associated sentences ;) >>>> >>>> 'grab' is also a very common english verb, so I think people would be >>>> able to distinguish. It also sounds like 'crab' if you like :) >>>> >>>> M >>>> >>>> > >>>> > On 12/22/2015 09:31 PM, Richard Bell wrote: >>>> >> GRAB = Gnu RAdio Basic installer >>>> >> >>>> >> Then we can say things like "Go GRAB it" when referring to a needed >>>> module >>>> >> >>>> >> On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun < >>>> martin.br...@ettus.com> >>>> >> wrote: >>>> >> >>>> >>> There's been some demand to rename PyBOMBS, and now that we're >>>> >>> re-releasing it, this is a good time to think about it. Complaints >>>> about >>>> >>> the name include: >>>> >>> >>>> >>> - It may or may not be true that people have been detained by TSA >>>> for >>>> >>> working on PyBOMBS at the airport[1] >>>> >>> - The name suggests a Python-related packages (like Pylint, PyPI...) >>>> >>> rather than a GNU Radio-related tool >>>> >>> - People can't agree on a capitalization >>>> >>> - No one can remember what the acronym stands for >>>> >>> >>>> >>> Sure, this is not a critical thing, but now's a good chance to >>>> bring it >>>> >>> up and also, this is not a joke :) >>>> >>> >>>> >>> Here's how we're going to do this: >>>> >>> >>>> >>> - Please suggest new names in this thread. >>>> >>> - I will choose from those names based on 'can I live with this >>>> name', >>>> >>> 100% subjectively. >>>> >>> - New names will be put up for a vote. This will include an option >>>> to >>>> >>> keep the old name. >>>> >>> - Finally, the result of the vote will be used as a strong >>>>
Re: [Discuss-gnuradio] Renaming PyBOMBS
IMO it is generally nice to have a unique googleable name for an application which doesn't result in five trillion unrelated Google results. While short acronyms will have false positives, names like "grab" or any standard English words are generally bad choices from this point of view Grpm and the like seem fairly unique - pybombs was a win by this measure On Wed, Dec 23, 2015, 1:02 PM Martin Braunwrote: > On 23.12.2015 09:28, Stefan Wunsch wrote: > > I don't want to destroy your idea, but GRAB sounds like CRAP as well and > > you can think of the associated sentences ;) > > 'grab' is also a very common english verb, so I think people would be > able to distinguish. It also sounds like 'crab' if you like :) > > M > > > > > On 12/22/2015 09:31 PM, Richard Bell wrote: > >> GRAB = Gnu RAdio Basic installer > >> > >> Then we can say things like "Go GRAB it" when referring to a needed > module > >> > >> On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun > >> wrote: > >> > >>> There's been some demand to rename PyBOMBS, and now that we're > >>> re-releasing it, this is a good time to think about it. Complaints > about > >>> the name include: > >>> > >>> - It may or may not be true that people have been detained by TSA for > >>> working on PyBOMBS at the airport[1] > >>> - The name suggests a Python-related packages (like Pylint, PyPI...) > >>> rather than a GNU Radio-related tool > >>> - People can't agree on a capitalization > >>> - No one can remember what the acronym stands for > >>> > >>> Sure, this is not a critical thing, but now's a good chance to bring it > >>> up and also, this is not a joke :) > >>> > >>> Here's how we're going to do this: > >>> > >>> - Please suggest new names in this thread. > >>> - I will choose from those names based on 'can I live with this name', > >>> 100% subjectively. > >>> - New names will be put up for a vote. This will include an option to > >>> keep the old name. > >>> - Finally, the result of the vote will be used as a strong suggestion > on > >>> what the new name will be. > >>> > >>> There already have been some suggestions: > >>> > >>> - gromit -- the GNU Radio out-of-tree module installation tool > >>> - the groot > >>> - grpm -- the GNU Radio package manager > >>> > >>> > >>> OK guys, bring up the ideas! > >>> > >>> Cheers, > >>> Martin > >>> > >>> [1] It's not. > >>> > >>> ___ > >>> 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Renaming PyBOMBS
I agree with Tim, the tool is not gnuradio specific, and I personally dont think it needs to be locked to gnuradio and have a "gr" in the name anywhere and uniquely searchable is a must. I'm a big fan of the original name. Otherwise: PySIS - Pybombs Software Installer System. On Wed, Dec 23, 2015 at 1:43 PM, Richard Bell <richard.be...@gmail.com> wrote: > Yeah I should have clarified that. I tried the full package manager route > of install about 2 years ago for gnuradio and uhd. It didn't work. I > installed uhd through apt-get and gnuradio through apt-get with no success. > > I'm just bringing that up so we don't assume that is an easy possibility > for someone to do. As far as I know from my stab at it two years ago, it's > not viable. Someone should try that route now to see if it is before we > assume anything. > > On Wed, Dec 23, 2015 at 10:38 AM, Tim O'Shea <tim.oshea...@gmail.com> > wrote: > >> Ubuntu packages uhd >> Assuming other oses do too >> I'm sure there are up to date ppas somewhere too >> >> >> On Wed, Dec 23, 2015, 1:34 PM Richard Bell <richard.be...@gmail.com> >> wrote: >> >>> Is there a way for a new user to get uhd installed from the package >>> manager though? A lot of people want to dive right into gnu radio with >>> hardware, doing simple things like spectrum analysis. I'm not aware of a >>> way of getting the uhd + gnuradio setup running that's easier then pybombs. >>> I very well could be wrong here. >>> >>> On Wed, Dec 23, 2015 at 10:31 AM, Tim O'Shea <tim.oshea...@gmail.com> >>> wrote: >>> >>>> Most new users should be installing gnu radio binaries via their os >>>> package manager repos or ppa. Pybombs should be used for 1. Helping get >>>> up to date oot modules set up and deployed ( like pip ) and 2. Helping >>>> developers set up their development environment. >>>> So I'm not sure installer is the right idea to impart on new users at >>>> all >>>> >>>> >>>> On Wed, Dec 23, 2015, 1:23 PM Richard Bell <richard.be...@gmail.com> >>>> wrote: >>>> >>>>> I'd like to throw in another point from an entry level perspective. >>>>> Those people who might need pybombs most, are those who need names that >>>>> tell them what it's for the most. Even if it is incorrect to call pybombs >>>>> an installer, it would really help the entry level folks (which I would >>>>> claim without support is the largest population of the community at any >>>>> given time) understand what it's for and how they should use it. I think >>>>> we >>>>> all have the experience of learning new tools and running into tool names, >>>>> which even though the description is spot on for what its for, at the time >>>>> carried zero value for the new guy using it (thinking mostly about Xilinx >>>>> tool names here). >>>>> >>>>> With that said, I think it would be good for the community to use the >>>>> word installer in the tool that makes gnuradio and uhd really easy to >>>>> install, and is what the vast majority of people I'm guessing would use it >>>>> for. >>>>> >>>>> On Wed, Dec 23, 2015 at 10:02 AM, Martin Braun <martin.br...@ettus.com >>>>> > wrote: >>>>> >>>>>> On 23.12.2015 09:28, Stefan Wunsch wrote: >>>>>> > I don't want to destroy your idea, but GRAB sounds like CRAP as >>>>>> well and >>>>>> > you can think of the associated sentences ;) >>>>>> >>>>>> 'grab' is also a very common english verb, so I think people would be >>>>>> able to distinguish. It also sounds like 'crab' if you like :) >>>>>> >>>>>> M >>>>>> >>>>>> > >>>>>> > On 12/22/2015 09:31 PM, Richard Bell wrote: >>>>>> >> GRAB = Gnu RAdio Basic installer >>>>>> >> >>>>>> >> Then we can say things like "Go GRAB it" when referring to a >>>>>> needed module >>>>>> >> >>>>>> >> On Tue, Dec 22, 2015 at 12:10 PM, Martin Braun < >>>>>> martin.br...@ettus.com> >>>>>> >> wrote: >>>>>> >> >>>>>> >>> There's been some demand to rename PyBOMBS, and now t
Re: [Discuss-gnuradio] Renaming PyBOMBS
Martin, Excited to see pybombs2 emerging as stable ! A few thoughts on the naming below -- -Tim On 12/22/2015 03:10 PM, Martin Braun wrote: > There's been some demand to rename PyBOMBS, and now that we're > re-releasing it, this is a good time to think about it. Complaints about > the name include: > > - It may or may not be true that people have been detained by TSA for > working on PyBOMBS at the airport[1] > - The name suggests a Python-related packages (like Pylint, PyPI...) > rather than a GNU Radio-related tool it doesn’t really need to be gnu radio specific -- it was written to work with any such light weight recipes that follow standard git/cmake or other common or custom format > - People can't agree on a capitalization > - No one can remember what the acronym stands for > > Sure, this is not a critical thing, but now's a good chance to bring it > up and also, this is not a joke :) > > Here's how we're going to do this: > > - Please suggest new names in this thread. > - I will choose from those names based on 'can I live with this name', > 100% subjectively. > - New names will be put up for a vote. This will include an option to > keep the old name. > - Finally, the result of the vote will be used as a strong suggestion on > what the new name will be. > > There already have been some suggestions: > > - gromit -- the GNU Radio out-of-tree module installation tool this name makes me cringe horribly "installation tool" isn't really a fair characterization since it is setting up a development environment apt-get or standard binary installs are more "installation tool" > - the groot also - horrible cringe factor, > - grpm -- the GNU Radio package manager I like grpm -- other similar possibilities: rmm - radio module manager grmm - gnu radio module manager gmm - gnuradio module manager spm - SDR Packager Manager spm - spm package manager personally in favour of something short and functional vs cutesy and contrived (we already have one of those names) three letter package managers seem to be relatively common practice in FOSS examples:apt, rpm, pip, gpm, npm, ... > > > OK guys, bring up the ideas! > > Cheers, > Martin > > [1] It's not. > > ___ > 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] Renaming PyBOMBS
Python build overlay managed bundle system On Tue, Dec 22, 2015, 4:47 PM Donald Pupeckiwrote: > I like GRPM - GnuRadio Package Manager. > > Can never remember what pybombs stands for anyway. > On Dec 22, 2015 3:10 PM, "Martin Braun" wrote: > >> There's been some demand to rename PyBOMBS, and now that we're >> re-releasing it, this is a good time to think about it. Complaints about >> the name include: >> >> - It may or may not be true that people have been detained by TSA for >> working on PyBOMBS at the airport[1] >> - The name suggests a Python-related packages (like Pylint, PyPI...) >> rather than a GNU Radio-related tool >> - People can't agree on a capitalization >> - No one can remember what the acronym stands for >> >> Sure, this is not a critical thing, but now's a good chance to bring it >> up and also, this is not a joke :) >> >> Here's how we're going to do this: >> >> - Please suggest new names in this thread. >> - I will choose from those names based on 'can I live with this name', >> 100% subjectively. >> - New names will be put up for a vote. This will include an option to >> keep the old name. >> - Finally, the result of the vote will be used as a strong suggestion on >> what the new name will be. >> >> There already have been some suggestions: >> >> - gromit -- the GNU Radio out-of-tree module installation tool >> - the groot >> - grpm -- the GNU Radio package manager >> >> >> OK guys, bring up the ideas! >> >> Cheers, >> Martin >> >> [1] It's not. >> >> ___ >> 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] Renaming PyBOMBS
Cutesy acronym grumblings aside on this one, If all you wanted to do was install gnu radio, apt, rpm, our emerge would do. IMO pybombs seems more about indexing, installing, setting up development environments, and updating out of tree modules - "grin" implied scope is a small subset thereof On Tue, Dec 22, 2015, 10:02 PM Neel Pandeya <neel.pand...@ettus.com> wrote: > Also perhaps: > > GRIN = Gnu Radio INstaller > > > > On 22 December 2015 at 15:37, Martin Braun <martin.br...@ettus.com> wrote: > >> Another suggestion from #gnuradio was 'grapple'. >> >> M >> On 22 Dec 2015 15:12, "Neel Pandeya" <neel.pand...@ettus.com> wrote: >> >>> My vote would be for one of these: >>> >>> GRPM = GnuRadio Package Manager >>> >>> GRAB = Gnu RAdio Basic installer >>> >>> GRBI = >>> >>> Gnu Radio Basic Installer >>> >>> I agree with Tim O'Shea, the name should be something short and >>> functional, and give an idea of what it does, instead of being cutesy and >>> contrived. >>> >>> --Neel >>> >>> >>> >>> >>> On 22 December 2015 at 12:10, Martin Braun <martin.br...@ettus.com> >>> wrote: >>> >>>> There's been some demand to rename PyBOMBS, and now that we're >>>> re-releasing it, this is a good time to think about it. Complaints about >>>> the name include: >>>> >>>> - It may or may not be true that people have been detained by TSA for >>>> working on PyBOMBS at the airport[1] >>>> - The name suggests a Python-related packages (like Pylint, PyPI...) >>>> rather than a GNU Radio-related tool >>>> - People can't agree on a capitalization >>>> - No one can remember what the acronym stands for >>>> >>>> Sure, this is not a critical thing, but now's a good chance to bring it >>>> up and also, this is not a joke :) >>>> >>>> Here's how we're going to do this: >>>> >>>> - Please suggest new names in this thread. >>>> - I will choose from those names based on 'can I live with this name', >>>> 100% subjectively. >>>> - New names will be put up for a vote. This will include an option to >>>> keep the old name. >>>> - Finally, the result of the vote will be used as a strong suggestion on >>>> what the new name will be. >>>> >>>> There already have been some suggestions: >>>> >>>> - gromit -- the GNU Radio out-of-tree module installation tool >>>> - the groot >>>> - grpm -- the GNU Radio package manager >>>> >>>> >>>> OK guys, bring up the ideas! >>>> >>>> Cheers, >>>> Martin >>>> >>>> [1] It's not. >>>> >>>> ___ >>>> 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
Re: [Discuss-gnuradio] SSB/CW/FM tranceiver
Hi folks, I've just spent a couple days reading a lot in here. Finding this thread, a recent one, talking ham radio gives me an excellent opportunity to join in - my first post here. I'm in the process of putting together receive & transmit capability based on gnuradio. Not a transceiver exactly, but a full station from soup to nuts. Currently I'm receive-only using a Ham-It-Up converter, an rtlsdr dongle, Gqrx and a newly constructed mag loop antenna. My plans include generating SSB via gnuradio and bringing the I & Q signals out to homebrew balanced modulators, a DDS and a QRP linear. I was a ham back in 1955-60, let my license lapse & was inactive for several decades, then just last summer went & got my General. Returning to the hobby now I find radio just as magical & exciting as when I was a kid. Since I prefer homebrewing & gadgeteering more than operating on air, I'm building stuff on the cheap like I did back then but now it's $20 rtl dongles instead of WWII surplus ARC-5 command sets. Still chewing gum & rubber bands tho. Actually I may get involved with grc/gnuradio before I tackle making a transmitter. What brought me to this list was pursuing articles on folks using two or more rtlsdr dongles for phasing applications. My interests aren't so much in passive radar or beamforming. I'm sticking with HF bands for now (mainly 40 meters). I've been researching two-antenna phase cancellation techniques for RFI noise reduction. Hams have been doing this with antenna-level RF signals for years. A currently available product is the MFJ-1026. But I got to thinking about doing the nulling at the IQ signal level via twin receivers, i.e. dual dongles. Coherent clocking. Much discussion I've read involves precision measurements but my use case is, I believe, much more modest. All I'm looking for is letting a 2nd noise antenna reduce the receive noise floor on an HF ham band. Anyway, I'm interested in giving this a try. One more thing: I'm already helping to spread the word about gnuradio. The graphic art at the top of my YouTube channel has a grc flowgraph along with other radio items both old & new. I'm working on telling my story about building up my station via YouTube videos (only a couple up there right now). If the "diversity" noise cancellation scheme works out that'll be another video. Tim KK6VQQ YouTube channel: www.youtube.com/channel/UCCRh9a5sQKd5h8VAfZ_OtWA -- View this message in context: http://gnuradio.4.n7.nabble.com/SSB-CW-FM-tranceiver-tp56800p57121.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Frequency discriminator using a frequency to voltage converter
Per chance, are you looking for the quadrature demodulator? - Tim On Wed, Nov 4, 2015 at 7:15 AM, larry ho <larryhorui...@hotmail.com> wrote: > Hi > > > I am new to linux and GNU Radio, I am trying to create a frequency to > voltage converter, I tried looking into the source code of QT GUI Frequency > Sink to get an idea how it detects frequency. However, it seems a little > complicated, is there any particular function i should look out for in the > coding? Or are there any alternative in creating a frequency to voltage > converter. Greatly appreciative if any advise can be provided. Thank you. > > > Regards > > > Larry > > ___ > 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] MMCR Filters
Hey all, Just threw this together and thought you'd be interested. It's a comparison of filters for the MMCR block on (raw data + noise). http://pastebin.com/nbq4HwQ1 - Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bidirectional with Socket PDU
You should be fine connecting both input and output ports at the same time for exactly this purpose! -Tim On 08/13/2015 03:29 PM, Jason Matusiak wrote: This will probably show my networking ignorance, but is there a way to use the socket PDU for bi-directional purposes? I see that it has a PDU in and out, but I cant' seem to get it to work. What I am doing is connection netcat to it with the PDU in UDP Server mode with nc -u localhost 52001 and I can transmit to it. But I know that I cannot open a listening port with nc -ul localhost 52001 since the port is bound. Is there a way to write and listen on the same port, or am I totally screwing how networking works (the only reason I would think there might be a way is because the GRC script allows me to connect the PDU in and out at the same time without throwing an error)? ___ 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] Processing expectations
You may also want to have a look at http://stats.gnuradio.org/ To get a feel for how fast different sdr kernels run on different processing platforms Tim On Fri, Aug 7, 2015, 11:47 AM Tom Cook tom.k.c...@gmail.com wrote: I'm brand new to SDR and I'm just trying to calibrate my expectations of what will be possible in real time. I'm hoping someone here can give me a pointer or two. I'm running GNU Radio 3.7.2 on Ubuntu 14.04, having installed from the Ubuntu repositories. The machine I'm using has an Intel Core i5-2520M running at 2500MHz. I'm constructing flowgraphs in GRC and using an RTL-2832U-based USB dongle as a receiver. I've built a fairly simple broadcast FM stereo receiver as an example. It has the following components: * RTL-SDR source (768k sample rate). * Low pass filter (768k sample rate, 96k cutoff, 4k transition) * Rational resampler (4x decimation) * WBFM receiver (quadrature rate 192k) * Low pass filter (1x decimation, 192k sample rate, 15k cutoff, 2k transition) * 2x Band pass filter (1x decimation, 192k sample rate, differing cutoff and transition) * Multiply * Low pass filter (192k sample rate, 15k cutoff, 2k transition) * Add, subtract * 2 x rational resampler (4x decimation) * Audio sink (sample rate 48k) My system is not able to run this in realtime, producing regular underruns (about two per second). Decreasing the receiver sample rate to 384k and decreasing the decimation factor in the first resampler to 2 allows it to run in without underruns, from which I deduce that the CPU is right on the edge of being able to process the flowchart in realtime. Are my expectations of what I'll be able to do in realtime unreasonably high? Is there something I'm missing, that I can do to make this run much faster? Thanks, 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] isolate channels from wideband
Just as a heads up, someone mailed this into the mailing list the other day. I think it accomplishes exactly what you all want -- although it doesn't use PFBs as I recall. https://github.com/madengr/ham2mon - Tim On Sun, Aug 2, 2015 at 2:18 PM, John Ackermann N8UR j...@febo.com wrote: Hi Chris -- Using the variables, I now have the program working in general. The channel mapping gave me some nightmares, though. I finally decided that you need two maps -- one for the channelizer block, where you do the 4,5,6,7,0,1,2,3 translation, and another for the GUI that is a simple 0..7. With that, it seems to be working well although my WBX front end seems to have been fried as it is more deaf than it used to be. Time to switch to hardware troubleshooting mode... Thanks, again! John On 08/02/2015 12:10 AM, Chris Kuethe wrote: Thanks for pointing out the paste-o. I'll fix that. I'm using gnuradio 3.7.8rc1, which has helper blocks for computing filter taps. You can replace them with variables: pfb_taps = firdes.low_pass(2.0, oversampled_width, noaa_fm_dev * 2, 2500, firdes.WIN_HAMMING, 6.76) lpf_taps = firdes.low_pass(1.0, hardware_rate, noaa_band_width / 2, noaa_chan_width, firdes.WIN_HAMMING, 6.76) On Sat, Aug 1, 2015 at 5:00 PM, John Ackermann N8UR j...@febo.com wrote: Thanks much for this, Chris! I look forward to playing with it, but... When I load the flowgraph on my GRC 3.7.6.1 system, I get a Missing Block error for each of lpf_taps and pbf_taps, triggering errors in the xfft and channelizer blocks. I also had an error in the Multiply Const block coming out of channel 7. but that was caused by a missing space before else in the evaluation. Help? But thanks so much for taking this on. It's the perfect starting point for some projects I've been wanting to work on! John On 08/01/2015 03:26 PM, Chris Kuethe wrote: OK, Here it is... at least, a beta version. I have yet to come up with a concise explanation of the channel map and why you'd want to oversample, but it is functional. This flowgraph would work equally well by directly connecting all the ports together, but I'm a big fan of using virtual sources and sinks to make the design somewhat self-documenting.. On Sat, Aug 1, 2015 at 4:55 AM, Markus Heller hel...@relix.de mailto:hel...@relix.de wrote: Great! Thanks! I'm very curious! br/vy73 markus dl8rds Am Freitag, den 31.07.2015, 14:34 -0700 schrieb Chris Kuethe: OK, I have a mostly working flowgraph and am now adding comment to all the blocks explaining why I'm doing this or that. Will publish tonight or tomorrow. On Tue, Jul 21, 2015 at 11:56 AM, Chris Kuethe chris.kue...@gmail.com mailto:chris.kue...@gmail.com wrote: Maybe I'll do up an illustrated example on this using NOAA weather radio, or the pager band On Tue, Jul 21, 2015 at 11:42 AM, mle...@ripnet.com mailto:mle...@ripnet.com wrote: I just use the built-in firdes stuff, rather than using an external designer. On 2015-07-21 14:38, Marcus Müller wrote: Hi Rich, hello Markus, On 21.07.2015 19 tel:21.07.2015%2019:51, Richard Bell wrote: GNU Radio has channelizers built-in, but I've not used them yet, so I don't know how far they take you into this kind of task. the Polyphase channelizer is actually an implementation derived from that school of thought, and it works amazingly well. In fact, in preparation of a presentation at a certain ham conference, I tried using it to get 20 PMR/LPD channels out of a 1MS/s signal in real time, and then just shuffle them around, before feeding them back into the inverse synthesizer PFB. It's pretty easy: Design a single low pass filter, as if you just wanted to filter out the channel which is centered exactly at your RF center frequency, i.e. 0Hz, with the full sampling rate [2], using the gr_filter_design tool. Play around with the different window types[1], and bear in mind that the suppression outside your desired passband needs to be high enough so that the sum of the energy in all other channels don't hurt your channel too much, but don't overdo it (60dB suppression should be enough). Now you get a long filter. Copy and paste the filter coefficients from gr_filter_design to your PFB filter taps property. Set your channelizers number of channels according to your plans -- 40, if you want to get all the 40 25kHz channels in 2MHz. You get a block with 40 outputs
Re: [Discuss-gnuradio] ham2mon GR based scanner
Nicely done! On Wed, Jul 22, 2015 at 9:11 PM, madengr rfeng...@me.com wrote: Throught I'd share my GR based scanner with curses GUI. Locks on and demodulates N number of NBFM channels and logs audio to disk. Uses gr-osmosdr source so should work with a variety of devices. https://github.com/madengr/ham2mon https://www.youtube.com/watch?v=BXptQFSV8E4 -- View this message in context: http://gnuradio.4.n7.nabble.com/ham2mon-GR-based-scanner-tp54975.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] Is there a project which implements half-duplex communications?
Jeon, Also check out http://wp.me/p55sJw-2v software based half duplex burst PSK modem which can operate using a single USRP, file loopback, or other SDR -Tim On 06/30/2015 09:30 AM, Jeon wrote: Hello, GNU Radio users, Very long time ago, USRP 1 was not suitable for half-duplex communications because USB 2.0 interface is too slow to achieve it. But now, there are USRP embedded and gigabit ethernet supporting USRP series. In my opinion, thus, half-duplex communications might be achievable nowadays. I am curious that there is a project which implements half-duplex communications. If there is, how many USRPs, daughterboards and antennas are used for each node? Can I find such a project in pybombs? In my guess, a half-duplex communication application can be built from both USRP sink and source being placed in one flow graph. But I have no idea of the rest of the flow graph. Should the flow graph open loop or closed loop? Is there a special configuration or tweak on USRP or GNU Radio required to achieve half-duplex communications? I apologize if my question sounds quite vague. Regards, Jeon. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Adding OOT Modules from Github
How did you go about installing GNU Radio, and what version are you using? (Check gnuradio-companion's version). On Tue, Jun 23, 2015 at 4:21 PM, Washbourne, Logan lwas...@ostatemail.okstate.edu wrote: Hello, I am trying to use the Burst PSK project that Tim O'Shea and Kiran Karra developed and I am having trouble figuring out how to add the projects' blocks into my version of Gnuradaio. Is there an easy way to add multiple blocks at a time or is it necessary to add them one at a time (using the method described in the OOT tutorial)? I haven't tried much in the way of solving this problem because I would consider myself a novice when it comes to Linux but a hint in the right direction would definitely be welcomed. I appreciate your time, Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) ___ 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] HermesNB with Pybombs
Check again, recipe added ./pybombs sync should update recipes to the latest for you On 05/04/2015 11:53 PM, Tom McDermott wrote: Hi Greg - there is no Pybombs recipe for gr-hpsdr. I do not have Pybombs installed, so can't test a recipe. My development system pushes to github, so it's always up to date and the most accurate mirror. I endeavor to keep TAPR SVN accurate, but it is manually copied from github... I recommend getting gr-hpsdr from github which has the latest, and doing the source build. https://github.com/Tom-McDermott/gr-hpsdr -- Tom, N5EG On Mon, May 4, 2015 at 6:58 PM, Gregory W. Ratcliff n...@att.net mailto:n...@att.net wrote: Tom, Heard your talk on this work. Went digging around in the new Pybombs list but didn't notice anything that looked HPSDR-like. Before I go to TAPR subversion could you give us a pointer to the latest version for the Everyone wants to brag about their progress before Dayton weekend. Greg nz8r ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] Release Announcement: GNU Radio 4.1
In the interest of saving the GR support team costly web hosting fees, may I send a self-addressed package with my blank 3.5 floppies to get the release? How many blank floppies should I send? I think I can get them in bulk on eBay. I'm in no hurry, so return by pre-paid surface mail is fine for me (it will take me time to convert my C++ GR blocks to C#). - Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pybombs
This issue should now be fixed in the latest version -Tim On 02/20/2015 06:33 AM, Marcus Müller wrote: Hi, you seem to be running pybombs and/or the app_store.py as root, although the prefix they use seems to be your home directory, making root privileges unnecessary. Using sudo therefore most likely messes up your paths, and thus things go wrong. Don't use sudo when you're using a home-directory prefix. Greetings, Marcus On 02/20/2015 11:32 AM, FredomFighter099 . wrote: Hello list Has anyone else has experienced any problems with pybombs: failing to load recipes This is happening when I try to install through ./app_store.py I am getting this output I have tried several prefixes all with the same result. test@test-virtual-machine:~$ cd pybombs test@test-virtual-machine:~/pybombs$ sudo ./app_store.py [sudo] password for test: Settled on prefix: /home/test Initializing environmental variables... no existing inventory found, creating an empty one... Loading recipes ... Failed to load recipe gr-zmqblocks Failed to load recipe numpy Failed to load recipe gflags Failed to load recipe gr-osmosdr Failed to load recipe pyqt4-dev-tools Failed to load recipe glib Failed to load recipe gr-baz Failed to load recipe pocsag-mrt Failed to load recipe gr-gsm Failed to load recipe gr-tagutils Failed to load recipe gr-compat Failed to load recipe libbzip Failed to load recipe fftw Failed to load recipe pango Failed to load recipe wireshark Failed to load recipe gr-smithchart Failed to load recipe gr-dvbs2 Failed to load recipe libpng Failed to load recipe gr-ettus Failed to load recipe gr-packetradio Failed to load recipe git Failed to load recipe gnuradio Failed to load recipe uhd Failed to load recipe gr-multimon Failed to load recipe freetype Failed to load recipe cairo Failed to load recipe libbtbb Failed to load recipe libpcap Failed to load recipe gr-mediatools Failed to load recipe boost Failed to load recipe libsndfile Failed to load recipe gr-mtb Failed to load recipe wxpython Failed to load recipe gr-iqbal Failed to load recipe gr-dvbt2 Failed to load recipe libpolarssl Failed to load recipe expat Failed to load recipe pyqt4 Failed to load recipe glog Failed to load recipe pycairo Thanks in advanced ___ 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] Updating GNU Radio, UHD or PyBOMBS
Try running Pybombs clean gnuradio Pybombs clean uhd And then installing -Tim On Oct 31, 2014 11:53 AM, Richard Bell richard.be...@gmail.com wrote: I'm still asking for help with this maintenance process. I tried the './pybombs remove' command to get rid of uhd and gnuradio as a test. I didn't get any error or warnings and it completed. When I looked in the pybombs/src folder, both gnuradio and uhd folders still existed there. I deleted them by hand. I then tried the './pybombs install uhd' command to reinstall uhd, but pybombs seems to think it's installed. I'm really at a loss as to how I'm supposed to do things here. I think in theory, pybombs would make all of this painless, but I've either done something terribly wrong and screwed pybombs up at this point, or it's not working as intended. What should I do at this point to fresh install with pybombs? I checked the packages I have installed on my ubuntu and I don't see gnuradio or uhd in the list, which is good. If I deleted the pybombs folder and start over from there, would you expect a clean installation at that point? Is that what Martin meant by Just reinstall it? Thanks, Rich On Wed, Oct 29, 2014 at 4:06 PM, Martin Braun martin.br...@ettus.com wrote: Just reinstall it. No hassle :) M On 10/29/2014 11:07 PM, Richard Bell wrote: Well, I can tell you that I deleted the gnuradio build directory and then executed ./pybombs update to see if it would start the build process. It did not. As of now I'm not really sure what ./pybombs update does. The wiki leads me to believe it's supposed to do the pull and build process, link below to explanation of ./pybombs update. http://gnuradio.org/redmine/projects/pybombs/wiki/Using Unfortunately, the wiki also recommends that we don't update each recipe manually, because we could break a dependency. So at this point, I'm still not sure what I'm supposed to do to update my install when new versions of gnuradio or uhd come out. Can someone with experience in this flow chime in for me. Much appreciated. Rich On Wed, Oct 29, 2014 at 2:46 PM, Martin Braun martin.br...@ettus.com mailto:martin.br...@ettus.com wrote: On 10/29/2014 09:32 PM, Richard Bell wrote: Thanks Martin, but I'm still unsure of this process. 1) I tried using ./pybombs update, but it doesn't look like it initiated a build process on anything. Did you mean to imply it would do that, or just the git pull process for gnuradio and uhd? Hm, I thought that's what it would do. Maybe it just git pulls. 2) There is no build directory in uhd, like there was in gnuradio. From the pybombs/src/uhd directory where do I need to be to execute make and sudo make install? You sure? Maybe pybombs/src/uhd/host/build ? 3) There is also no build directory in pybombs, where should I execute make and sudo make install? That you just git pull. It's pure Python, and doesn't get installed, so it just needs a build process. M Thanks, Rich On Wed, Oct 29, 2014 at 1:18 PM, Martin Braun martin.br...@ettus.com mailto:martin.br...@ettus.com mailto:martin.br...@ettus.com mailto:martin.br...@ettus.com wrote: Sometimes it's safer to clear the build dir, usually it's OK to leave in. If you have any cmake variables set, you'll need to reset them if you clear the dir. UHD is updated the same way. In all cases, it depends where you installed your stuff. pybombs can do all this for you, by the way: ./pybombs update ...although I don't think this will update pybombs itself. M On 10/29/2014 08:53 PM, Richard Bell wrote: Hi all, I am new to all of this, so I'm looking for some guidance. I recently setup UHD and GNURadio using PyBOMBS on Ubuntu 14.04. I now want to do a git pull and update my stuff. I'm not sure what commands to execute after I do the git pull for each. For example, I found two different recommendations for updating gnuradio after a git pull First way: *git pull * *rm -Rf build * *mkdir build * *cd build * *cmake ../ * *make * *sudo make install* Second way: *git pull * *cd build * *make * *sudo make install* Is the removal of the existing build directory and cmake command necessary? After
Re: [Discuss-gnuradio] PyBombs install maint branch from fresh
Martin, You are probably right we should track maint by default at this point.I think it's worth adding a Pybombs environment question about which branch to track during initial setup for those that prefer to track master however. Tim On Jul 23, 2014 7:10 AM, Activecat active...@gmail.com wrote: On Wed, Jul 23, 2014 at 5:16 PM, Martin Braun martin.br...@ettus.com wrote: On 07/23/2014 07:14 AM, Activecat wrote: Dear Sirs, I am performing fresh gnuradio installation using pybombs. Pybombs install master branch by default. How to make pybombs install 'maint' instead? Act@rsLAPTOP: ~/download/pybombs $ git checkout maint error: pathspec 'maint' did not match any file(s) known to git. This is not how you use git; you need to give it a remote branch to track first. Also, if you checked out 'maint' on pybombs, it wouldn't necessarily check out 'maint' on any SW package it's trying to install. I assume you're trying to install GNU Radio maint, right? I guess one way would be to modify the gnuradio.lwr recipe, change the default branch to maint. M Thanks. yes, I am trying to install GNU Radio maintenance branch. I will change the gitbranch of gnuradio.lwr recipe to 'maint'. Does this means the uhd.lwr also need to be 'maint', or can just be 'master' as default? ___ 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] PyBombs install maint branch from fresh
One of the problems with allowing this kind of customization is that a single set of pybombs recipes is generally intended to represent a fixed set of versions / branches as far as configuration management. Supporting additional branch combinations is kind of explosive in terms of new combinations of supported packages/versions.That said, master is kind of a moving target. The hope was to have a set of recipes that tracks master everywhere for the most part (for developers that want this), and then have numbered known good sets of recipes that track for instance 3.7.3 or 3.7.4 with known good OOT modules at the time (for more stable OOT development or pure users). However this is a lot of time/work to set up and constantly test / release so thus far we haven't really been doing that half - The versioned releases are to some extent already covered by binary packages - That said, we can always throw this feature in with a *danger untested version combination* caveat ... -Tim On 07/23/2014 07:28 AM, Marcus Müller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim, idea: pybombs install package gets the default branch as in the recipe, pybombs install package%awesomefeatures gets the awesomefeatures branch. That would allow people to specify they want UHD maint, GNU Radio v3.7.4, and gqrx master, if they really want to. Greetings, Marcus On 23.07.2014 13:18, Tim O'Shea wrote: Martin, You are probably right we should track maint by default at this point.I think it's worth adding a Pybombs environment question about which branch to track during initial setup for those that prefer to track master however. Tim On Jul 23, 2014 7:10 AM, Activecat active...@gmail.com wrote: On Wed, Jul 23, 2014 at 5:16 PM, Martin Braun martin.br...@ettus.com wrote: On 07/23/2014 07:14 AM, Activecat wrote: Dear Sirs, I am performing fresh gnuradio installation using pybombs. Pybombs install master branch by default. How to make pybombs install 'maint' instead? Act@rsLAPTOP: ~/download/pybombs $ git checkout maint error: pathspec 'maint' did not match any file(s) known to git. This is not how you use git; you need to give it a remote branch to track first. Also, if you checked out 'maint' on pybombs, it wouldn't necessarily check out 'maint' on any SW package it's trying to install. I assume you're trying to install GNU Radio maint, right? I guess one way would be to modify the gnuradio.lwr recipe, change the default branch to maint. M Thanks. yes, I am trying to install GNU Radio maintenance branch. I will change the gitbranch of gnuradio.lwr recipe to 'maint'. Does this means the uhd.lwr also need to be 'maint', or can just be 'master' as default? ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTz5xzAAoJEBQ6EdjyzlHt2oYIAJYYair2p3bJqiYwIMVhtX21 O5DUUVV06LQpEXUbxs99JBeGtA4KoY1KddVW2OPx26yUhP49xBAYO8dbNHth4ft8 PHNjS2vWroGK/8otLM8kkdzr+2+YmCw9zMKW/q/nl/afxsdUmu8N+gY9hZYsBkv8 jF8A4UPk7b8d4r79WxHmiiYHN6FLnW9glfGXDbigJMXyERzNaKJVPoy/o9Z7o5Q7 MLjsWBOkikn6mlNFjXD2VrHRBOJwQrp6gRLtirDhMqaeKepD1QBZddWYv5I5vYB0 5U/DFTN7j3Ar/BXWYiFIGFeUPqFunIw4YO6m/e9z4Le5VuJ0H36d3OptieuS/dE= =twiT -END PGP SIGNATURE- ___ 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] How to start with stream tags
Try: http://gnuradio.org/doc/doxygen-3.7/page_stream_tags.html or http://gnuradio.org/redmine/attachments/download/252/06-rondeau-stream_tags.pdf or even http://bit.ly/1kWXdCl On Tue, Apr 22, 2014 at 6:29 AM, Hoang Ngo Khac khachoang1...@gmail.comwrote: Dear List, I want to make time synchronization for implementation of two-way relaying network. Each node contain both RX chain and TX chain but they should not run simultaneously (half-duplex mode). Therefore, the TX chain is on when it is needed to transmit, and off when the transmission is over. I found that *stream tags* is the key solution to perform that. My question is, how should I start to learn about* stream tags*, where can I find tutorial of *stream tags*? Thank you so much. Best Regards, Hoang -- Ngo Khac Hoang Faculty of Electronics and Telecommunications - University of Engineering and Technology (UET) - Vietnam National University, Hanoi (VNU) Vice-president of Student Association of UET Alternative email: hoangnk...@vnu.edu.vn Mobilephone: +84.163.682.7874 ___ 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] Best way to output decoded data to user
check out gr-pyqt - this might be roughly what you are looking for I've added some very simple python blocks which can send and receiver pdus with strings stored in pmt u8vectors and can be easily dropped into a Qt Gui for user interaction https://github.com/osh/gr-pyqt/commit/7b12b79bc029d483ce71878960b24871ddbfd954 -Tim On 04/15/2014 04:35 AM, Martin Braun wrote: On 04/15/2014 06:14 AM, Francois Gervais wrote: I'm trying to figure out the best way to print the decoded data information of packets (received through gnuradio) to the user. File outputs are not really user friendly so I'm thinking of using a message queue out of my decoding block connected to the WX GUI Terminal Sink. Generally: Don't use a message queue. Also, I recommend not adding any WX widgets, unless you hate QT, because we're trying to move away from them. The message passing interface might be a better choice, but the idea in general is very good. Is this a good approach? I'm thinking it might not since I can't find any design using the terminal sink on the net. If this is the right path could someone point me to an easy example of using the message queue. I'd like to do a quick proof of concept and output something like hello world on the terminal sink. Have a look at the message_debug code. It does most of what you want, but not in a widget, just on the console. Martin ___ 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] Solution for SegFault with Lock / Unlock in 3.7 C++
What version of boost are you using? Tim On Fri, Mar 28, 2014 at 12:45 PM, Luke Berndt luk...@gmail.com wrote: I was wondering if there has been any progress or work arounds for Bug 598 in 3.7? http://gnuradio.org/redmine/issues/598 The issue is the GnuRadio will segfault if there are too many Lock / Unlocks. I am having it happen after 6 - 10 lock/unlocks. My program is a C++ program that records trunked radio calls and I need to be able to dynamically connect / disconnect recording flowgraphs as new calls are started. The program works fine under 3.6. I was wondering if there are any work arounds I should try. I have tried using tb-stop, tb-wait, tb-start, but it still crashes. Is there some other way to dynmically connect disconnect blocks that doesn't require lock / unlock? Is there an ETA when this would be fixed? Anything I can help on? I am going to have to go back to 3.6 if I can't figure out a solution. Thanks! - Luke ___ 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] Solution for SegFault with Lock / Unlock in 3.7 C++
I was thinking the older version of boost had a bug in the boost thread stuff that was causing this, but boost 1.53 should be fine. On Fri, Mar 28, 2014 at 1:09 PM, Luke Berndt luk...@gmail.com wrote: I am using Boost 1.53, on Ubuntu 13.10 via apt-get. When I was running it under GnuRadio 3.6, I think I was running Boost 1.49, but it got upgrade because I think it is not compatible with GR 3.7? Would it be worth it to try build from source for Boost 1.48 or 1.55? On Fri, Mar 28, 2014 at 12:54 PM, Tim Newman tim.new...@gmail.com wrote: What version of boost are you using? Tim On Fri, Mar 28, 2014 at 12:45 PM, Luke Berndt luk...@gmail.com wrote: I was wondering if there has been any progress or work arounds for Bug 598 in 3.7? http://gnuradio.org/redmine/issues/598 The issue is the GnuRadio will segfault if there are too many Lock / Unlocks. I am having it happen after 6 - 10 lock/unlocks. My program is a C++ program that records trunked radio calls and I need to be able to dynamically connect / disconnect recording flowgraphs as new calls are started. The program works fine under 3.6. I was wondering if there are any work arounds I should try. I have tried using tb-stop, tb-wait, tb-start, but it still crashes. Is there some other way to dynmically connect disconnect blocks that doesn't require lock / unlock? Is there an ETA when this would be fixed? Anything I can help on? I am going to have to go back to 3.6 if I can't figure out a solution. Thanks! - Luke ___ 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] Controlport error in GRC
If you built GNU Radio under pybombs, you can also run ./pybombs rb gnuradio this alias (rebuild) will blow away the build dir and re-run cmake/make/install for you with the proper environment set up don't forget to rebuild everything that links against gnuradio afterwards (any OOT modules you may have) -Tim On 03/12/2014 09:05 AM, Tom Rondeau wrote: On Wed, Mar 12, 2014 at 1:12 PM, sarankumar saran...@gmail.com wrote: hi, I removed version Ice3.5.1 and built Ice 3.5.0. But now GRC cannot detect Ice: from gnuradio.ctrlport.monitor import * File /usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/__init__.py, line 23, in module import Ice, IcePy ImportError: No module named Ice do I need to build PyBombs again for gnuradio to detect Ice? regards, Saran Remove CMakeCache.txt from your build directory and rerun cmake with the ICE_MANUAL_INSTALL_PATH set. Also make sure PYTHONPATH and LD_LIBRARY_PATH are set properly to the location of the ICE 3.5.0 installation. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Include guard bug
good find, this was probably my fault - sorry We should consider changing headers to use #pragma once which is simpler and less error prone do people still use gcc older than 3.4 ? I think this is pretty widely supported now not sure if that would cause swig issues as well - -Tim On 02/21/2014 10:51 AM, Marcus Müller wrote: Ruecan: I got carried away. This is indeed a bugfix for the header file not being processed in some cases, but since the error appeared although actually processing the fixed header file, I've run out of ideas, still. On 02/21/2014 04:37 PM, Marcus Müller wrote: Should be :) Just as side info: http://www.boost.org/doc/libs/1_54_0/doc/html/boost/random/mt19937.html Sorry, totally running low on clues here... This is twice as strange since boost::random is missing mt19937; if it was std:: I'd guess on a non-C++11 standard library, but like it is... If cleaning and rebuilding doesn't help, make sure that libstdc++-devel is correctly installed Basically, it should be right here: http://www.boost.org/doc/libs/1_54_0/boost/random/mersenne_twister.hpp and is included. AAAND bam. Found the bug. header include protection by #ifdef at the very beginning of the file. you might pull my bugfix from https://github.com/marcusmueller/gnuradio.git; git pull https://github.com/marcusmueller/gnuradio.git master_fix_message_strobe_random_ifndef Greetings, Marcus On 02/21/2014 04:00 PM, Ruecan wrote: Thanks Marcus, Actually the boost version I have is 1.54.0. Is this ok ? -- View this message in context:http://gnuradio.4.n7.nabble.com/Issue-while-installing-GR-3-7-tp46435p46451.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio 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] Control Port, Perf Mon for GRC - errors
Are you installing Ice after you build gnuradio? If so, then gnuradio won't enable the controlport modules during the gnuradio build because it doesnt detect Ice. Tim On Fri, Feb 7, 2014 at 11:10 PM, Tom McDermott tom.mcdermo...@yahoo.comwrote: Having some issues with Control Port and Perf Mon in GRC. 1. Built Latest Gnuradio 3.7.2 from git. enabled performance counters in the cmake command line cmake ../ -DENABLE_PERFORMANCE_COUNTERS=On then successful make, install, ldconfig, and gnuradio runs fine. 2. Edited the gnuradio-runtime-conf file to enable PerfCounters and ControlPort, Edges. 3. Installed zeroc-ice (ver 3.4). If I add both a ControlPort Complex Probe and a CtrlPort Monitor, get the following error: Traceback (most recent call last): File home/tom//mod_phasing_test.py, line 17, in module from gnuradio.ctrlport.monitor import * ImportError: No module named ctrlport.monitor If I delete the CtrlPort Monitor, leaving only the probe, I get the following error: Traceback (most recent call last): File /home/tom/mod_phasing_test.py, line 231, in module tb = mod_phasing_test() File /home/tom/mod_phasing_test.py, line 144, in __init__ self.blocks_ctrlport_probe_c_0 = blocks.ctrlport_probe_c(constellation, Constellation Points) AttributeError: 'module' object has no attribute 'ctrlport_probe_c' Are there other configuration steps needed? Does zeroc-ice need to be configured in some manner? -- Tom, N5EG ___ 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] UHD stream tagging
You can also do precisely timed burst to stream conversion in pure-software which is a bit more portable For one example of how to do this using gr-eventstream tools see the transmitter in https://github.com/osh/gr-bitcoin -Tim On 02/08/2014 02:37 PM, Price, Nathan D. (ST-Student) wrote: Hello, I'm working on project in gnuradio, in which I'm trying to toggle on and off the transmission from the USRP. After much research, I learned this was done by tagging the first sample of a transmission with tx_sob and the last sample with tx_eob (there was also a tx_time tag, but I found the former option more convenient). I wrote a custom block that periodically tags segments out of continuous stream of data as a proof of concept; however, the transmission remains continuous as if there were no tag. I've checked with the tag debugging block to ensure my block acutally generates tags. My flow graph is simply: file source(repeat)-custom tagging block-psk mod-multiply const-uhd sink. Reading in the archive, I haven't found reference to success much success with the streaming API. I would love the community's input on this problem. Thanks, Nathan ___ 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] PyBOMBS issue using recipe with hierarchical git branch.
Andrew, Try again with the latest version - this should be fixed now -Tim On 01/29/2014 12:21 PM, Andrew Back wrote: Hello, I tried adding a recipe to PyBOMBS for UHD-Fairwaves, setting gitbranch to fairwaves/umtrx. However, when I run install, fairwaves is stripped from the branch hierarchy and so it fails since there is no branch called simply umtrx. Guessing there may be a bug in the way in which PyBOMBS parses the recipe gitbranch value? Cheers, Andrew [1] https://github.com/fairwaves/UHD-Fairwaves ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] more pybombs
Generally $gituser is not used for anything you can if you want put a repository address like ssh://$gitu...@yourserver.com:gr-foo.git in a recipe I guess it is just intended to provide a standard easy way of doing this - we could probably remove it if it really upsets people, but it seems fairly harmless as is our list of configuration variables is getting longer and longer, I'm not sure what the right balance is between prompting the user for all of them, and trying to hide ones that a user may not understand or care about - perhaps simply a more verbose explanation of it would help -Tim On 01/22/2014 11:55 AM, ikjtel wrote: We're starting to get a few more folks who have used pybombs (successfully) to install gnuradio and/or gr-op25. Below is one comment - I have to admit, I had the same question/uncertainty myself, re: the gituser (Username for git access) prompt. For me, concurrent make threads was obvious and the penalty for wrong answers was perfectly clear; whereas this is not at all the case for gituser. In fact I seem to recall trying different answers for gituser without actually seeing that it had any effect [???]... Best Max ~~ [start paste, 1 minor edit] I was pointed to the Ettus Research builds of GNURadio, which apparently they regularly update for Windows. It's something I may try at some point. I was going to start IT tonight until the other Scott (the one that has his together far more than me for this project) dropped in with his info. I may still. EDIT: Might be nice to include the link, eh? http://code.ettus.com/redmine/ettus/...URadio_Windows http://code.ettus.com/redmine/ettus/projects/uhd/wiki/GNURadio_Windows Right now it's bombs awayor pybombs. The install is running merrily away...so far. I would note that at the outset in the step after ./pybombs install gnuradio I was prompted for numerous options, with a default for each. Because I don't have any clue as to what the hell I'm doing, I chose the defaults. __ Scott - Scan New England Webmaster http://www.scan-ne.net http://www.scannewengland.net/ Radio Reference MA, RI, CT Database Admin ___ 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] Pybombs issue
It should now prompt for a value if makewidth is undefined w an open -j argument was never the intended behavior - as it is not particularly safe Also the boost recipe has been converted to do $makewidth wide builds with bjam now -Tim On 01/09/2014 11:26 AM, Tom Rondeau wrote: On Thu, Jan 9, 2014 at 11:15 AM, Robert McGwier rwmcgw...@gmail.com wrote: I did an update to pybombs two days ago, and immediately gnuradio got to around 57% completion and just hung my Ubuntu 13.10 computer so hard, I couldn't get it to respond to ctrl-alt-del for over half and hour. I tried again after doing a force rebuild on gnuradio and it was worse. I long-hit the power button to do a reset. I checked the pybombs defaults and it is makewidth = 4, but it certainly acts like it is ignoring this and doing make -j . Further symptoms include a nonstop, hard green LED on disk writes on a 8 GB system. I have never seen it actually go to a major use of virtual memory (if that is what is happening) until now. I went into src/gnuradio/build and did a manual make -j4 and it worked perfectly, thus my diagnosis. Bob Yep, making with an unnumerated -j is really dangerous, even on very high-end systems. There was another report about issues with makewidth, so that needs looking into. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio 3.7.2.1 Installation Problem
Hi, Nathan, I think this is a known bug we're currently trying to squash (http://gnuradio.org/redmine/issues/582). I think this is the first report of a problem on x86 hardware; if we can't duplicate it on our machines would you mind if we bug you about testing out code in the following couple of days? FYI, I cited x86 in addition to ARM in my original report of #582. For my x86, gnuradio-config-info -v reports 3.7.1 (The GR tree is on maint branch, at the 3.7.1 release commit). My hardware is a 12.04 Ubuntu on top of VMWare: $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz stepping: 7 microcode : 0x25 cpu MHz : 3392.340 cache size : 8192 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss nx rdtscp lm constant_tsc up arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave avx hypervisor lahf_lm ida arat xsaveopt pln pts dtherm bogomips: 6784.68 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: Let me know if I can send anything else to characterize my x86 machine. Regards, Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [VOLK] Summary of call
On 12/12/2013 04:01 PM, Douglas Geiger wrote: On Thu, Dec 12, 2013 at 3:11 PM, West, Nathan n...@ostatemail.okstate.edu mailto:n...@ostatemail.okstate.edu wrote: The VOLK working group had a call earlier today. Agenda and summary are here: http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20131212 We'll likely have our next call late January or February time-frame. There's a semi-open question about what kind of stats we should collect. Tim added support for taking CFLAGS at build time and /proc/version and /proc/cpuinfo at runtime. While we're at it are there any other machine features that would be useful to collect? Toolchain name/version info please! (http://gnuradio.org/redmine/issues/620) Unless, of course, Tim's support for CFLAGS already includes that info and/or patch... Yep, already working on including compiler name / version as well ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Install: qa_volk_test_all fails on armv7
I am wondering if the QA failure is relates, to the use of the hard float ABI. For me, whenever I have tried to specify hard or soft float ABI, cmake fails. If I don't specify it, it just works... I'm switching my OE builds to armthf now so I can compare my results with Tom's. I'm working on a real fix for the qa code (not just symlinking until it works) Hopefully, I can confirm hard float status tomorrow. Philip Seems like Philip was able to replicate these VOLK bugs using the hard float build. I just tried it myself using his hard float OE, but I'm still getting everything to pass ok on my system. Tom OK, good to hear. Does that mean bugs 582 and 583 should be re-opened? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Install: qa_volk_test_all fails on armv7
The volk test is failing on my gnuradio build on a Beaglebone Black (armv7h) running Arch Linux Arm. # make test start 1: qa_volk_test_all *** 2 failures detected in test suite Master Test Suite1/177 Test #1: qa_volk_test_all .***Failed9.88 sec Full output of ctest -V _R qa_volk_test_all is attatched. which version of GNU Radio? These bugs were fixed on Nov. 19 and will be a part of the 3.7.2.1 release. See bugs #582 and #583 on our Issues page. Tom After pulling the latest GR code (as of Dec 1) and doing a fresh build, my ARMv7 target's ctest output for qa_volk_test_all matches what Ken attached in the first message of this thread. So there is something still going on here. Is it possible some external component needs to be updated, that is outside of what's in the GR git tree? The output I originally logged in Bug #583 differs from our latest results, but the behavior is the same (in1/in2 values appear to match). The output I originally logged in Bug #582 (for ARM target) remains the same (in1/in2 values differ by 1). I just did a fresh install on my ARMv7 of the entire OS and GNU Radio from the latest git checkout (was testing Balister's new OE manifest and SDK) and everything is working great here. When you say you did a fresh build, what does that really mean? One of the quirks of volk is that cmake /has/ to be rerun when these kinds of changes are made. Best really to clean up everything to make sure you're doing everything from a clean checkout. git reset --hard; git pull origin master; git clean -dxf;. Then rerun cmake and make from a clean build directory. The above might be overkill, so if you want a quicker test, start with the clean git pull of the latest head and just make sure to rerun cmake and make, not necessarily from an empty directory. Hi, Tom, I tried these steps: - Uninstalled gnuradio (make uninstall). - apt-get update + apt-get upgrade for my ARM7 target (Ubuntu 13.04), which updated quite a bit of stuff. - Deleted my gnuradio tree and re-cloned it. - Checkout maint branch. - Built as I have been doing. - Same problem :( Hi, Philip, Building gnuradio on an arm is silly :) I bow to the sheer power of your A15 toolchain-rebuild cross-compile x86 prowess. :) I am wondering if the QA failure is relates, to the use of the hard float ABI. For me, whenever I have tried to specify hard or soft float ABI, cmake fails. If I don't specify it, it just works... I'm switching my OE builds to armthf now so I can compare my results with Tom's. Thanks! Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Install: qa_volk_test_all fails on armv7
The volk test is failing on my gnuradio build on a Beaglebone Black (armv7h) running Arch Linux Arm. # make test start 1: qa_volk_test_all *** 2 failures detected in test suite Master Test Suite1/177 Test #1: qa_volk_test_all .***Failed9.88 sec Full output of ctest -V _R qa_volk_test_all is attatched. which version of GNU Radio? These bugs were fixed on Nov. 19 and will be a part of the 3.7.2.1 release. See bugs #582 and #583 on our Issues page. Tom After pulling the latest GR code (as of Dec 1) and doing a fresh build, my ARMv7 target's ctest output for qa_volk_test_all matches what Ken attached in the first message of this thread. So there is something still going on here. Is it possible some external component needs to be updated, that is outside of what's in the GR git tree? The output I originally logged in Bug #583 differs from our latest results, but the behavior is the same (in1/in2 values appear to match). The output I originally logged in Bug #582 (for ARM target) remains the same (in1/in2 values differ by 1). Regards, Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Go-back is possible?
gzip - base64 encode the grc file into some comments in the python file perhaps? a smallish grc file appears to be on the order of 1000 chars with such an encoding On 12/02/2013 05:11 PM, Dan CaJacob wrote: I have an interesting (to me anyway) idea: What if we added a default option to the GRC-XML-to-python converter to add the contents of the original GRC file as a big, delineated comment blob. Then, a simple tool could pull the GRC back out of the python file anytime and you could go back and forth. An option when building would disable the verbose output for those publishing code or who just don't want the extra cruft. It's a little lame, but it solves the problem. I know I've had to hand-craft many old GRCs from python files when the original GRC was lost or the originator was other than myself. The problem has often crept up with GRCs not properly updated for new versions of code, where the blocks go missing in the GRC representation (I think there was talk of fixing this - graying them out or something). Very Respectfully, Dan CaJacob On Mon, Dec 2, 2013 at 4:48 PM, Marcus Leech mle...@ripnet.com mailto:mle...@ripnet.com wrote: Think of the Python that gets emitted by GRC as object code. What you're asking is to convert said object code back into reasonable source code. Such things exist for *actual* machine object-code, but, they produce damned-ugly results. on Dec 02, 2013, *Raydel Abreu (CM2ESP)* cm2...@gmail.com mailto:cm2...@gmail.com wrote: Oh, that's bad, I guess I should use instead the old code-reading method Raydel 2013/12/2 Marcus Leech mle...@ripnet.com mailto:mle...@ripnet.com There's no automatic mechanism for doing that. on Dec 02, 2013, *Raydel Abreu (CM2ESP)* cm2...@gmail.com mailto:cm2...@gmail.com wrote: Hello, Is it possible to go back and convert a Python GNU Radio code back into the GRC Flow Graph from which it was generated? Cheers, Raydel, CM2ESP ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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] trying to use gdb
you should be able to run 'gdb python --core=corefilename' you may want to make sure you have compiled gnuradio with -DCMAKE_BUILD_TYPE=RelWithDebInfo for useful symbol tables On 11/26/2013 04:31 PM, Matt D wrote: Hi, I am using GRC3.6.3 and my program is dying with no verbose. so now i have my core file in my home folder and i cant find the path to the executable. Can someone please tell me the path? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-ctrlport-monitor timeout exception
I've seen ICE do this before, but usually its because my flowgraph dies, via segfault or something. When the flowgraph dies, the ice endpoints aren't available anymore so the controlport monitor timesout when attempting to query them. Are you sure your flowgraph isn't crapping out for some reason or another? Tim On Wed, Nov 13, 2013 at 11:10 AM, Nowlan, Sean sean.now...@gtri.gatech.eduwrote: *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf Of *Nowlan, Sean *Sent:* Monday, November 11, 2013 4:10 PM *To:* discuss-gnuradio@gnu.org *Subject:* [Discuss-gnuradio] gr-ctrlport-monitor timeout exception I’m using ControlPort to monitor transmissions through a USRP. I have a flowgraph responsible for generating burst traffic and streaming to a uhd_sink. Then I have a uhd_source tuned to the same frequency as the uhd_sink, and I connect it to a ctrlport_probe2_c block with length=128. I have ControlPort support compiled-in and enabled from a config file. I’m able to connect to a remotely running flowgraph using gr-ctrlport-monitor and plot the PSD of the “samples” vector pulled from the probe2 block every 100 milliseconds. The problem is that after (what seems to be) a nondeterministic time, the ICE port stops responding and gr-ctrlport-monitor reports an error: ctrlport-monitor: radio.get threw exception (exception ::Ice::ConnectTimeoutException { }). When I close and restart, gr-ctrlport-monitor times out and segfaults: 2013-11-11 16:02:47.329422 /usr/local/bin/gr-ctrlport-monitor: error: Traceback (most recent call last): File /usr/lib/pymodules/python2.7/Ice.py, line 984, in main status = self.doMain(args, initData) File /usr/lib/pymodules/python2.7/Ice.py, line 1031, in doMain return self.run(args) File /usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py, line 97, in run radio = self.getRadio(host, port) File /usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py, line 36, in getRadio radio = GNURadio.ControlPortPrx.checkedCast(base) File /usr/local/lib/python2.7/dist-packages/gnuradio_ice.py, line 1257, in checkedCast return _M_gnuradio.ctrlport.GNURadio.ControlPortPrx.ice_checkedCast(proxy, '::GNURadio::ControlPort', facetOrCtx, _ctx) ConnectTimeoutException: exception ::Ice::ConnectTimeoutException { } Segmentation fault (core dumped) So there are two issues to note here: -Something in the ICE instance is breaking on the GNU Radio flowgraph side. The port is still open; it just times out. Trying to instantiate gr-ctrlport-monitor to an incorrect port just says “connection refused,” as expected. -gr-ctrlport-monitor is not robust to connection-related errors like timeouts or refused connections. Is there any advice of what I can turn on or enable in GNU Radio or my flowgraph to debug the first problem? I can live with the second problem as long as I can make sure ICE doesn’t break on me. Thanks, Sean Sorry for getting antsy about this, but I’m really not sure how to go about debugging ICE server stuff. It seems like it’s buried pretty deeply in gnuradio-runtime. Where’s the best place to start looking to find out why the ICE server stops responding? 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] Sampling with multiple USRP N210s with one host computer
There are lots of different ways. One example would be to simply connect them all to a switch, along with your host. Assuming the aggregate bandwidth doesn't exceed what the host's network card or switch can handle you'll be fine. You could also, as you mentioned, have a single host with 8 network interfaces, this is completely possible. Tim On Thu, Oct 31, 2013 at 4:54 PM, rmsrms1987 rmsrms1...@gmail.com wrote: Hi Everyone, I recently discovered that Ettus offer a way of synchronizing up the eight USRPs with the following clock distribution system: https://www.ettus.com/product/details/OctoClock-G https://www.ettus.com/product/details/OctoClock-G Out of curiosity, how would one be able to connect and sample with eight separate USRPs with one host computer. Would you need eight separate ethernet ports? That seems like more than what a typical motherboard would be able to handle. Or can the USRPs all be connected to a server, which can be individually accessed through the host computer? Understanding how to do this will be extremely beneficial in order to gather some ideas for a project. Thank you very much in advance, Rob -- View this message in context: http://gnuradio.4.n7.nabble.com/Sampling-with-multiple-USRP-N210s-with-one-host-computer-tp44502.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] What conditions will cause block destructor to be skipped?
you're entering a minefield there... Thanks for helping me navigate :) First of all, destructors of python objects are called whenever the python runtime feels like it - this often happens when you do something like object_name = None but it doesn't necessarily has to happen right away. The Garbage Collector can choose when to do it, and sometimes, it decides not to do it at all - if your program terminates first, this might be the case. Furthermore, if it decides that at the end of runtime, it should destruct its output stream file handles before destructing your block, your printf output might be lost. So I know it isn't just dropping printf output, as other clean-up code does not execute. So these are the pitfalls I could think of. Maybe the situation is a lot easier, though :) Post some code, maybe a github gist or a pastebin! All excellent ideas, especially the GC that rightfully turns up its nose at any destructor complaints. So it is good to know that it is a bit out of my hands, but I can certainly move my clean-up code to the point where the work() method signals WORK_DONE. Sorry, I can't possibly air my dirty laundry on a pastebin :(. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] What conditions will cause block destructor to be skipped?
Rarely, I'm seeing evidence that my custom source block destructor is not being called. My flowgraph was built with No GUI and Prompt for Exit options (GR 3.7.1+) The condition is that my source block's work function has moved to a state returning WORK_DONE, and will stay in that state. When I press Enter to end the flowgraph, I sometimes don't see the usual ending printf() outputs. Fortunately, it does not happen often. This article cites such a case: http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00055.html, but my flowgraph only has my custom source block and a File Sink block. Regards, Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] timestamp tags and set_min_output_buffer
On 10/09/2013 02:59 PM, Juha Vierinen wrote: Hi, I'm writing a block that always outputs the same number of items as it gets in. The block is doing FFT on a fixed length vector, so I always need nfft samples in and nfft samples out. I've achieved this (I think) by using: set_min_noutput_items(nfft) and set_max_noutput_items(nfft). However, when I increase nfft to 8192, I get a message about not enough buffer space. I tested various things and ended up calling set_min_output_buffer(2*nfft) as just nfft wasn't enough. It all seems to work nicely, except that the rx_time tags are screwed up -- I get a nearly random offset in the beginning, even though there are no dropped packets on the USRP. Is this a bug or a feature? What is the correct way to increase the value of noutput_items without breaking rx_time tags? juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Juha, An easier way to achieve this is, is calling set_output_multiple(nfft) in the block constructor - which assures noutput_items = n*nfft where n = 1 then if its a sync block without the relative rate or forecast being change, it will also assume it also needs nfft items each work call set_min_noutput_nitems and set_min_output_buffer are bigger hammers that probably shouldn't be used in this case unless you have really big vectors - I think by default there should be no problems with an output multiple = 8k are you consuming nfft each time in your current block? If it is providing you nfft+extra samples each time through work you would get strange offsets if you simply consumed noutput_items each time. -Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Activating/Deactivating Blocks in real time
Can you do this with a 2:1 mux block? Input 2 = constant 0, control input is s(t)? From: discuss-gnuradio-bounces+tmonahan=qti.qualcomm@gnu.org [mailto:discuss-gnuradio-bounces+tmonahan=qti.qualcomm@gnu.org] On Behalf Of Achilleas Anastasopoulos Sent: Wednesday, October 02, 2013 3:48 PM To: Discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Activating/Deactivating Blocks in real time I have the following problem that I would like your opinion on how to solve elegantly: I have a block A (say a standard sync block with some memory--eg an fir filter) which has input x(t) and output y(t) and is pretty computationally intensive. I would like to add the following functionality to it: Add a new input s(t) to A which can be 0 or 1. When s(t)=1 the block operates as before ie, it processes x(t) to generate y(t). If s(t)=0 I would like it to output y(t)=0 and consume the appropriate x(t)'s from the input. This way when s(t)=0 block A essentially does not work. This is pretty straightforward to code if I modify the work function of block A. However, block A for me is a pretty complicated hierarchical block, so I don't have access to its work function. One way to do this is to rewrite the whole hierarchical block A as a flat block and then do as suggested above. Is there a better way? Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
On Wed, Sep 25, 2013 at 04:57:55PM -0700, Daniel Domínguez wrote: The solution I found was to set the Fixed Frame Length parameter to 1 on the OFDM Frame Equalizer block of the Header Stream. 1 is the correct setting. I'm currently adding a tx into the example so it runs as-is (like benchmark). It would be interesting to keep the original diagram, and then also show a replacement diagram that instead uses the OFDM Demod block and any other newer ones that consolidate the equivalent function. The reason: The headers have constant length, therefore it is not necessary to propagate them as tagged streams. The way the header/paylod demux work, it splits off the header and passes that regularly. There's no need to generate a length tag. Maybe that explains why my earlier issue about the Length Tag Key value for that same block does not matter (see GR issue # 593), since 1 implies it is not needed. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
The solution I found was to set the Fixed Frame Length parameter to 1 on the OFDM Frame Equalizer block of the Header Stream. 1 is the correct setting. With this fix, now I see a new error: INFO: Detected an invalid packet at item 0 INFO: Parser returned #f thread[thread-per-block[18]: block header_payload_demux (24)]: Buffer too small for min_noutput_items I'll look into this, but just in case this is familiar to anyone... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio-Companion Documentation.
Docs can take a long time to build, so when doing multiple builds a day during testing you really don't want to have this turned on. Likewise if you are building on slow machine or an older machine without sufficient doxygen. But obviously they are valuable for users doing their primary build who want to use the docs. I'm thinking it might make sense to just prompt the user when pybombs sets up its environment and asks for things like the prefix directory - for it to also ask the user whether they want to build documentation in general for all the recipes they will be building. The main issues with this are, 1. there are not currently recipes for doxygen and it's dependencies - those would need to be written and would pull in a bunch of latex, perl, ghostscript, etc -- 2. the dependencies for gnuradio need to change based on enabling/disabling this feature - we don't have a good mechanism yet in pybombs for turning deps on or off based on recipe options, but we could add something like this fairly easily At the end of the day we do have a choice now between trying to keep build configurations fairly static and simple (defined only by their recipe set and guaranteed for repeatability - which is great for performing repeatable testing, versioning, and packaging) or allowing it to become a monolithic thing that has lots of different user prompted states and options. It's not clear that we can't achieve both - but we would sacrifice a bit of conciseness and recipe simplicity to get there -Tim On 09/19/2013 09:59 AM, Tom Rondeau wrote: On Wed, Sep 18, 2013 at 3:48 PM, M Dammer i...@mdammer.net wrote: May I then suggest to enable the docs in the pybombs recipe by default as well ? You may suggest. Sorry for being glib. I also think it's a good idea to enable the documentation by default. If Tim agrees and there wasn't a technical reason why it was turned off in the first place, I think we can change it. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Proper way to update pybombs
On 09/14/2013 06:01 AM, M Dammer wrote: How can I update pybombs (to get the latest version and update the recipes) without loosing the information about my gnuradio build? in your pybombs directory or pybombs recipe directory run git remote update git pull this should pull down any pybombs updates that may be available you may want to 'git stash' before pulling and 'git stash pop' after if you have any local changes. or merge with a local branch with local modifications if you know what you are doing I want to continue to update gnuradio without the need to do a complete rebuild after a pybombs update. The 'safe' way to rebuild updated modules is to run ./pybombs update this will 1. find any out of date packages - and all packages that depend on these 2. uninstall all of these packages for you 3. perform a fresh install of all of these packages this may seem like overkill - but it is the only truly safe way to ensure you can try the shortcut approach - which is to run cd pybombs/src/gnuadio/ git remote update git pull cd build make install this is much much faster to do, it may not even need to run cmake if changes were very minor however - if you don't rebuild everything that links against gnuradio there is a danger that you will break linkage or some API/ABI contract with the dependent library, and there is always a danger that cmake won't automatically re-generate some file that is is supposed to when running this (like swig sources) - so when you do this you are rolling the dice. You may be able to get away with this a few times, but invariably one day you will start running into strange seg-faults which seem nonsensical, and which would completely go away in a fresh build. The other safe thing is to just do a fresh pybombs build in a separate directory so you don't lose your old working build while testing against the latest versions of code from various repos. -Tim tnx, Mark ___ 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] Questions on rx_ofdm example in GR 3.7.1
GR 3.7.1 gr-digital/examples/ofdm/rx_ofdm.grc 1. The OFDM Frame Equalizer block that is downstream from the Header Stream Virtual Source block has the Length Tag Key field set to length_tag_name, yet all other blocks on the diagram with that field are set to length_tag_key (which is the ID of a Variable block at the top of the diagram). Is that a mistake? If someone will confirm, I can file the bug. 2. When I try to run this flowgraph, modified for my target's custom source block, I get this error: FATAL: Missing a required length tag on port 0 at item #0 thread[thread-per-block[21]: block ofdm_frame_equalizer_vcvc (22)]: Missing length tag. Which led me to question (1) above. However, changing that block to match the others does not correct the runtime error. I found a couple of instances of the same error listed in (2) above in the mailing list, but no one replied to them. TIA, Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Enabling cpu #1 causes math error on ARM target
I wanted to post this observation to the group to see if I get a hit. I updated Bug #569 today with an additional observation: http://gnuradio.org/redmine/issues/569 Basically, on my ARM target, if I enable cpu core #1 (two cores total), the qa_mpsk_receiver test fails about 1/3rd of the time, when it compares 0.5 to sometimes -.492 or sometimes -.503 (i.e., the sign in the real part of a complex result flipped). If I keep cpu #1 disabled, the test passes every time. Keeping the CPUs limited to their minimum speed does not help. I'm compiling with gcc 4.7.3, and -mcpu=cortex-a15 -mfpu=neon -mvectorize-with-neon-quad -ffast-math -funsafe-loop-optimizations I'll be varying the build flags to see if that makes a difference in the meantime. Regards, Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Off-line signal processing (GR in slow motion)
Off-line example (3 separate flowgraphs, run one at a time): 1. USRP -- File 2. File -- AM Radio Demodulation, produces audio data -- File 3. File -- Throttle @ audio rate -- Audio Sink As Tim O pointed out, #3 would just be File -- Audio Sink, since the Audio Sink consumes at a fixed rate. Note that #2 can take as long as needed to complete, no issues with loss of data. If so, how would I set up flowgraph #2 above? Hm, I'm not quite sure if I understand your problem. You can simply connect a file source to the am demod and then to a file sink. Yes, #2 was meant to depict whatever processing blocks are needed to go from RF samples to audio samples. This flowgraph will then run unlimited ('cause no throttle). But that's OK if the input file is limited in size. Your CPU will be running full power until there's nothing left to process. Yes, I understand that part. What I was not sure about was whether the real time rate of data passing through the system was required to be able to do proper signal processing? Or whether some of the processing blocks are simply told what the rate is? Here is another example: suppose I have a file of audio samples. To determine the spectrum of the data , isn't the sampling rate of the data a factor? Or must a scalar be applied somewhere (related to the sampling rate) to convert relative values to energy per Hz? If the latter is true, then I'm still unclear on whether something like the rx_ofdm example under gr-digital can work, just given a file of samples and no throttle block (CPU limitations aside)? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Off-line signal processing (GR in slow motion)
I know that a source block of live IQ samples set to a certain sampling rate is equivalent to a File source of IQ samples followed by a Throttle block set to that same sampling rate. So far so good. But suppose the system cannot keep up with a live IQ stream, or the equivalent File + Throttle and do all the desired signal processing. Is there another way to process a file of captured samples without a throttle block, yet produce equivalent results output to another file? Here is an example to illustrate the question: Live example: USRP - AM Radio Demodulation, produces audio data - Audio Sink Off-line example (3 separate flowgraphs, run one at a time): 1. USRP -- File 2. File -- AM Radio Demodulation, produces audio data -- File 3. File -- Throttle @ audio rate -- Audio Sink Note that #2 can take as long as needed to complete, no issues with loss of data. If so, how would I set up flowgraph #2 above? Regards, Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk: Am I getting all that's available for ARM?
Just for the record. If the selected floating-point hardware includes the NEON extension (e.g. -mfpu='neon'), note that floating-point operations are not generated by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision. Regarding loss of precision: my target is able to use '-mfpu=neon-vfpv4' which selects floating point fused operations instead of chained. I tried it, but a new test error surfaces due to accuracy (v3.7.0): /src/gnuradio/build # ctest -V -R qa_ofdm_frame_equalizer_vcvc UpdateCTestConfiguration from :/src/gnuradio/build/DartConfiguration.tcl UpdateCTestConfiguration from :/src/gnuradio/build/DartConfiguration.tcl Test project /src/gnuradio/build Constructing a list of tests Done constructing a list of tests Checking test dependency graph... Checking test dependency graph end test 142 Start 142: qa_ofdm_frame_equalizer_vcvc 142: Test command: /bin/sh /src/gnuradio/build/gr-digital/python/digital/qa_ofdm_frame_equalizer_vcvc_test.sh 142: Test timeout computed to be: 9.99988e+06 142: .F. 142: == 142: FAIL: test_002_static (__main__.qa_ofdm_frame_equalizer_vcvc) 142: -- 142: Traceback (most recent call last): 142: File /src/gnuradio/gr-digital/python/digital/qa_ofdm_frame_equalizer_vcvc.py, line 244, in test_002_static 142: self.assertEqual(tag_dict, expected_dict) 142: AssertionError: {'frame_len': 4L, 'ofdm_sync_chan_taps': [0j, 0j, (-2.2037331959268158e-08+1j), [truncated]... != {'frame_len': 4, 'ofdm_sync_chan_taps': [0, 0, 1j, 1j, 0, 1j, 1j, 0]} 142: + {'frame_len': 4, 'ofdm_sync_chan_taps': [0, 0, 1j, 1j, 0, 1j, 1j, 0]} 142: - {'frame_len': 4L, 142: - 'ofdm_sync_chan_taps': [0j, 142: - 0j, 142: - (-2.2037331959268158e-08+1j), 142: - (-2.2037331959268158e-08+1j), 142: - 0j, 142: - (2.2037331959268158e-08+1j), 142: - (-2.2037331959268158e-08+1j), 142: - 0j]} So I went back to just '-mfpu=neon'. I didn't log this as a GR bug, since it feels like the Doctor, it hurts when I do this variety of problems. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio recipe in pybombs requires mcpp
Yeah, I think your right, mcpp isn't needed in the gnuradio pybombs recipe. Tim On Thu, Aug 8, 2013 at 9:05 AM, Alexandru Csete oz9...@gmail.com wrote: On Thu, Aug 8, 2013 at 2:16 PM, Tom Rondeau t...@trondeau.com wrote: On Thu, Aug 8, 2013 at 7:37 AM, Alexandru Csete oz9...@gmail.com wrote: Greetings, I just noticed that executing ./pybombs install gnuradio on a system that already has all the necessary dependencies starts by installing a package called mcpp. Searching the web I found out that it is a C/C++ preprocessor from 2008... Since gnuradio builds just fine with the standard preprocessor in gcc, I hope we can get rid of it get rid of this dependency. Alex It's an ICE dependency... the rest of GNU Radio doesn't use it. It's just needed to build ICE. Tom, Thanks for the info. If it is is an ICE build dependency then we can remove it from the gnuradio recipe, yes? Or is it also necessary for parsing and converting the gnuradio.ice files? Alex ___ 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] Xlate FIR filter broken in gr 3.7
rant I would vote for making copious use of the doc section in every block's XML file. For example, as a beginner, I spent a lot of time fiddling with Stream to Vector to figure out the parameters were opposite from what I thought they were. It is frustrating to open up a block's sheet and find it empty. /rant On 08/08/2013 05:01 PM, Andrew Davis wrote: Also, this change breaks a very important and very used part of hundreds of projects over the last ten years to make a variable name make slightly more since, when you could just change the variable name to 'frequency_shift' and leave the functionality the way it was. Andrew I have to agree. It's one thing to muck with the API semantics of a block that is new and hardly anyone has used. It's quite another to make a change like this on a block that has been in use for many years, with folks having figured out the semantics, despite the odd naming. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk: Am I getting all that's available for ARM?
Hi, Marcus. Thanks for your help. Tom seems to have given a pretty definitive reply, but this is just to completely answer your reply. On 08/07/2013 02:44 AM, Marcus Müller wrote: [1] note: in kernel terms of auxvec.h this stands for AT_HWCAP, see http://lxr.free-electrons.com/source/include/uapi/linux/auxvec.h?a=arm#L24 How Volk handles it looks like AT_HWCAP can only start on a 4-byte-aligned address within auxv; I'm absolutely not sure whether this is correct; on my x86_64 machine, there is no AT_HWCAP in that case. decided to have a look into this instead of sleeping; man proc(5) and volk are right: AT_HWCAP can only occur every 64 bit in /proc/PID/auxv. Sorry for the confusion. Your earlier reply said: snip ... however, as it seems, detection of Neon fails. But the cmake output I included said: -- Performing Test have_mfpu_neon - Success -- Performing Test have_funsafe_math_optimizations - Success So I think the neon detection works? You also asked: does executing hexdump /proc/self/auxv|sed ' 0010' show anything? Yes, an error :) ... Maybe you meant grep? The first line of auxv matches to your string: $ hexdump /proc/self/auxv 000 0010 b0d7 0001 0006 1000 010 0011 0064 0003 8034 020 0004 0020 0005 0009 030 0007 c000 4002 0008 040 0009 8f35 000b 050 000c 000d 060 000e 0017 070 0019 dc07 bed4 001f dfeb bed4 080 000f dc17 bed4 090 And if I run the basic cmake ../ command, I still get the same output for Volk. You asked for the CFLAGS in CMakeCache.txt in that s case, here you go: // CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel. CMAKE_C_FLAGS:STRING= CMAKE_C_FLAGS_DEBUG:STRING=-g CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //ADVANCED property for variable: CMAKE_C_FLAGS CMAKE_C_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_RELWITHDEBINFO CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 Just to compare, running my original cmake command yields the CFLAGS I manually specified: grep C_FLAGS CMakeCache.txt // CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel. CMAKE_C_FLAGS:STRING=-I/usr/include/arm-linux-gnueabihf -mcpu=cortex-a15 -mfpu=neon -mvectorize-with-neon-quad -ffast-math -funsafe-loop-optimizations CMAKE_C_FLAGS_DEBUG:STRING=-g CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG //ADVANCED property for variable: CMAKE_C_FLAGS CMAKE_C_FLAGS-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //ADVANCED property for variable: CMAKE_C_FLAGS_RELWITHDEBINFO CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 Thanks again and all the best, Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk: Am I getting all that's available for ARM?
Hi, Marcus, I was just a little confused, because I read the volk/gen/archs.xml template, and figured if has_neon() returned true, -mfloat_abi=soft and -nfpu=neon would have been added to the C_FLAGS... and cmake's output contained Performing Test have_mfloat_abi_softfp - Failed, so I guessed that (since I was quite sure that your machine supports softfp) it was disabled by lack of compiler flags... Actually, I compared my VMware x86 gnuradio cmake output to my ARM target, and it also failed the same abi_softfp test (but of course volk is much more exciting on the x86 target). But I also fiddled with that flag for a while: if I add -mfloat_abi=soft to my CFLAGS in the cmake command, it fails early as it can't find crti.o and crt1.o. But I was smart enough to find those on may target, and set LIBRARY_PATH to help. But then I get an error telling me there is a mismatch between the ABI of my toolchain and the ABI of the compiler output. So the soft flag came back out. Because of the 'abi_softfp' test failing on my x86, I decided I did not need to re-build the ARM tool chain to support soft ABI to try and help Volk. Is that still correct? (I have been able to build and run gnuradio without the soft flag just fine). Thanks, Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Volk: Am I getting all that's available for ARM?
Hi, Marcus On 08/07/2013 09:48 PM, Monahan-Mitchell, Tim wrote: Because of the 'abi_softfp' test failing on my x86, I decided I did not need to re-build the ARM tool chain to support soft ABI to try and help Volk. Is that still correct? (I have been able to build and run gnuradio without the soft flag just fine). I don't think -mfloat_abi=softfp (or even =soft) applies to x86; I think I remember the equivalent flag being something along the ways of -msoft-float... Or am I misunderstanding you and you talk about cross-compiling on x86 for arm? In my volk travels to answer this email thread's question, I was comparing what cmake did on my x86 (where there is more volk support) to what cmake does on my ARM target. I noted that both had -- Performing Test have_mfloat_abi_softfp - Failed, hence my conclusion that softfp was not a requirement for volk. snip If the selected floating-point hardware includes the NEON extension (e.g. -mfpu='neon'), note that floating-point operations are not generated by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified. This is because NEON hardware does not fully implement the IEEE 754 standard for floating-point arithmetic (in particular denormal values are treated as zero), so the use of NEON instructions may lead to a loss of precision. So it might make sense to include -funsafe-math-optimizations, if vectorize-with-neon-quad does not do that implicitly. Yes, I have -funsafe-math-optimizations and the cmake test for it passes: Performing Test have_funsafe_math_optimizations - Success Thanks, Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Volk: Am I getting all that's available for ARM?
Volk only gives me 'generic'. Is there some component available that I can to add to my system to get more out of it? Neon is detected, so I think that is why I see the 'generic_orc' machine listed. The gory details: gnuradio v3.7.0 Ubuntu 13.04 LTS (ARM distribution, ubuntu-core-13.04-core-armhf.tar.gz) Part of my cmake config : cmake -DCMAKE_C_FLAGS:STRING=-I/usr/include/arm-linux-gnueabihf -mcpu=cortex-a15 \ -mfpu=neon -mvectorize-with-neon-quad -ffast-math -funsafe-loop-optimizations \ Parts of the cmake output: -- The CXX compiler identification is GNU 4.7.3 -- The C compiler identification is GNU 4.7.3 snip -- Configuring volk support... -- Enabling volk support. -- Override with -DENABLE_VOLK=ON/OFF -- Found PythonInterp: /usr/bin/python2 (found suitable version 2.7.4) -- -- Python checking for python = 2.5 -- Python checking for python = 2.5 - found -- -- Python checking for Cheetah = 2.0.0 -- Python checking for Cheetah = 2.0.0 - found -- Boost version: 1.53.0 -- Found the following Boost libraries: -- filesystem -- system -- unit_test_framework -- checking for module 'orc-0.4 0.4.11' -- found orc-0.4 0.4.11, version 0.4.17 -- Found ORC: /usr/lib/arm-linux-gnueabihf/liborc-0.4.so -- Looking for cpuid.h -- Looking for cpuid.h - not found -- Looking for intrin.h -- Looking for intrin.h - not found -- Looking for fenv.h -- Looking for fenv.h - found -- Looking for dlfcn.h -- Looking for dlfcn.h - found -- Compiler name: GNU -- Performing Test HAVE_WERROR_UNUSED_CMD_LINE_ARG -- Performing Test HAVE_WERROR_UNUSED_CMD_LINE_ARG - Failed -- Performing Test have_maltivec -- Performing Test have_maltivec - Failed -- Performing Test have_mfpu_neon -- Performing Test have_mfpu_neon - Success -- Performing Test have_mfloat_abi_softfp -- Performing Test have_mfloat_abi_softfp - Failed -- Performing Test have_funsafe_math_optimizations -- Performing Test have_funsafe_math_optimizations - Success -- Performing Test have_m32 -- Performing Test have_m32 - Failed -- Performing Test have_m64 -- Performing Test have_m64 - Failed -- Performing Test have_m3dnow -- Performing Test have_m3dnow - Failed -- Performing Test have_msse4_2 -- Performing Test have_msse4_2 - Failed -- Performing Test have_mpopcnt -- Performing Test have_mpopcnt - Failed -- Performing Test have_mmmx -- Performing Test have_mmmx - Failed -- Performing Test have_msse -- Performing Test have_msse - Failed -- Performing Test have_msse2 -- Performing Test have_msse2 - Failed -- Performing Test have_msse3 -- Performing Test have_msse3 - Failed -- Performing Test have_mssse3 -- Performing Test have_mssse3 - Failed -- Performing Test have_msse4a -- Performing Test have_msse4a - Failed -- Performing Test have_msse4_1 -- Performing Test have_msse4_1 - Failed -- Performing Test have_mavx -- Performing Test have_mavx - Failed -- Available arch: generic;orc;norc -- Available machines: generic_orc My /proc/cpuinfo : Processor : ARMv7 Processor rev 2 (v7l) processor : 0 BogoMIPS: 13.53 Features: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 CPU implementer : 0x51 CPU architecture: 7 CPU variant : 0x1 CPU part: 0x04d CPU revision: 2 Thanks in advance, Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help Pybombs
When you run pybombs for the first time, it should ask you what prefix you want it to install into. For example, i think it defaults to /usr/local/. This then passes that prefix directory to the configurare parameter --prefix for autotools based projects or the cmake parameter -DCMAKE_INSTALL_PREFIX for cmake based projects, and the projects install into that prefix. Pybombs is simply running the configure/make/make install for the project you want to install and all it's dependencies. There's no magic about where it installs things. Tim On Fri, Aug 2, 2013 at 9:37 AM, tom sutherland alphatoz...@yahoo.comwrote: I have in stalled pybombs. I looked at all the projects in the recipe directory and have run ./pybombs install gr-ham and a few others but can't figure out what it is installing and WHERE did it put it. I thought it was installing some examples but I can't find anything. Thanks...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] Boost recipe in pybombs
Alex, This is set because of the unfortunate way some version of FindBoost.cmake are written the order it searches for libs can look something like 1. check for libboostfoo-mt.so in $BOOST_ROOT 2. check for libboostfoo-mt.so in /usr/lib/ 3. check for libboostfoo.so in $BOOST_ROOT 4. check for libboostfoo.so in /usr/lib/ A result of this is that if you build without the -mt tag, and you are on a distro that has an older version of boost installed into /usr/lib/ system paths - $BOOST_ROOT will be ignored because it checks all the search directories for each library naming case in an unfortunate order. So building with -mt every time to ensures FindBoost.cmake picks up the right prefixed boost library (if built from source) every time when building other recipes that use boost cmake. -Tim On 08/01/2013 02:16 PM, Alexandru Csete wrote: The boost recipe in pybombs builds using the --layout=tagged option which will generate libraries with the -mt suffix. The 'mt' stands for multi threaded and is only available for historical reasons,I suppose. Is there any particular reason for using this optionin pybombs? There are some linux distributions that have abandoned the -mt suffix and gnuradio builds just fine on those. Ubuntu still uses the -mt suffix but also creates softlinks without the suffix, so it is safe for an application to only link to libboost-xyz without the suffix. Alex ___ 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] Gnuradio3.7 make error
Its finding 1.40 headers somewhere on your system. Tim Sent on the Sprint® Now Network from my BlackBerry® -Original Message- From: Harry Zhang zhang...@gmail.com Sender: discuss-gnuradio-bounces+tim.newman=gmail.com@gnu.orgDate: Tue, 30 Jul 2013 19:23:47 To: Nathan Westnathan.w...@okstate.edu Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Gnuradio3.7 make error Dear Nathan, Thank you for your reply. I have changed the boost to 1.48 but the error remains. According to the error information, it seems to require libboost1.40,which puzzles me. 2013/7/30 12:12, Nathan West wrote: On Mon, Jul 29, 2013 at 11:55 PM, Gong Zhang zhang...@gmail.com wrote: Dear Nathan, I have tried the method in the URL but it does not work. The error remains. 2013/7/30 10:58, Nathan West wrote: On Mon, Jul 29, 2013 at 10:44 PM, Harry Zhang zhang...@gmail.com wrote: Hi, I'm using Ubuntu 12.04 and libboost1.46. I got the following errors when I make the project. libboost1.46 is known to cause problems with GNU Radio. Ubuntu 12.04 should have libboost1.48 available in the repos. Here's some more info: http://lists.gnu.org/archive/html/discuss-gnuradio/2013-02/msg00267.html What do you mean you tried the method in the URL? The cmake flag? The point of sending that link is the version of boost you have is known to cause problems with GNU Radio and unless you have a very good reason for using it you should use another version. If you're having trouble installing GNU Radio for the first time you might give pybombs a shot. It's pretty easy to get an installation going for the first time, especially if you're having a problem with dependencies like boost. Here's info on pybombs: http://gnuradio.org/redmine/projects/pybombs/wiki Nathan ___ 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] pybombs building 3.6.5.1 - swapping and out of virtual memory
By default pybombs runs make with the -j4 option, allowing it to compile things in parallel. This typically helps the compile go quicker. I certainly wouldnt expect the gnuradio compile to have issues like this, but you could edit the gnuradio recipe to force it not to use the -j4 option by adding: make { make } This basically overwrites the template pybombs uses for the make stage, which uses the -j4 by default. It will result in a longer compile time, and again I wouldnt expect a machine with 4GB of RAM to have any problems, even with that option, but its something to try. Tim On Mon, Jul 29, 2013 at 12:40 PM, M Dammer i...@mdammer.net wrote: Not sure if this is a Pybombs or Gnuradio build issue: When building version 3.6.5.1 via pybombs the system starts swapping after about 70% of the build have completed and even sometimes bails out with out of virtual memory. I can complete the build by restarting pybombs install - sometimes several times. I am building on XUbuntu 12.04 64bit - both machines have 4Gb RAM. I notice that top shows several cc1plus processes running in parallel each consuming over 1Gb of memory. ___ 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] PYBOMBS Build Failure
It appears that your error is not with pybombs but with building gnuradio. Can you post a bit more of the compile log? Tim On Thu, Jul 25, 2013 at 12:36 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hi, I've been trying out pybombs for building the latest gnuradio. I had a successful build at home last week, but I am having repeated failures in a test environment VM (virtualbox, ubuntu 12.04 x64). I am running the build like this: sudo ./pybombs install gnuradio Here's the relevant part of the make output: [ 68%] Built target gnuradio-blocks Linking CXX shared module _vocoder_swig.so [ 68%] Built target _vocoder_swig make: *** [all] Error 2 bash return val = 2 Traceback (most recent call last): File ./pybombs, line 91, in module install(p,True); File /home/spacequest/pybombs/mod_pybombs/pybombs_ops.py, line 49, in install global_recipes[pkg].install(); File /home/spacequest/pybombs/mod_pybombs/recipe.py, line 512, in install st = self.install_src(); File /home/spacequest/pybombs/mod_pybombs/recipe.py, line 582, in install_src self.install_order[step][1](); File /home/spacequest/pybombs/mod_pybombs/recipe.py, line 612, in make assert(st == 0); AssertionError ___ 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 3.6.x recipe for pybombs ?
On 07/20/2013 12:38 PM, M Dammer wrote: thanks for the suggestion. I already solved the problem here, by putting this configure section in the recipe: configure { git checkout tags/v3.6.5.1 cmake .. -DCMAKE_BUILD_TYPE=$cmakebuildtype -DCMAKE_INSTALL_PREFIX=$prefix $config_opt } On 20/07/13 17:04, Nathan West wrote: On Sat, Jul 20, 2013 at 10:26 AM, M Dammer i...@mdammer.net wrote: This does not work. I am getting a branch not found, building HEAD instead like error and then it builds 3.7. It looks as the gitbranch part of the recipe really only works with branches while the version numbers are tags. Does pybombs has a similar command than gitbranch to define a tag in a recipe ? On 19/07/13 20:00, Tom Rondeau wrote: On Fri, Jul 19, 2013 at 12:31 PM, M Dammer i...@mdammer.net wrote: Has anyone a recipe for installing the 3.6-branch via pybombs ? I need a 3.6 parallel installation on my system, because many old projects are not working out of the box in 3.7.x. Even many of the projects referenced by recipes that currently come with pybombs do not compile. tnx, Mark Mark, You can edit the recipe file to change the branch you want to check out. In pybombs/recipes/gnuradio.lwr look for the 'gitbranch' line. Change this from 'master' to the tag of the version you want, such as 'v3.6.5.1' for the latest in the 3.6 version. Tom Leave the branch as whatever you want (master, maint...) but add a line for gitrev: gitrev: tags/v3.6.5.1 Of course this could be whatever rev you want. Nathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Nathan's correct, the proper way would be by using the gitrev: line, you should be table to specify either a tag or a specific git revision. Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] git check out fails
=== THIS MAY TAKE QUITE SOME TIME= Fetching Gnu Radio via GIT...Could not find gnuradio/gnuradio-{core,runtime} after GIT checkout GIT checkout of Gnu Radio failed! omg. what do i have to do here? Well, you could run it using --verbose to see if there's anything extra going wrong. It looks like the build_gnuradio script is being used. Just try the git command that is in the script by itself like this I think: git clone --verbose http://gnuradio.org/git/gnuradio.git ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AttributeError: 'function' object has no attribute 'to_basic_block' ? (GR 3.7.0)
One of my OOT blocks is a function that takes in shorts and outputs shorts (a 1-to-2 interpolator). I have a simple flowgraph created in GRC: File Source - My block - File sync . GRC is happy until I run the flowgraph, and I get this: Executing: /top_block.py Traceback (most recent call last): File /top_block.py, line 54, in module tb = top_block() File /top_block.py, line 39, in __init__ self.connect((self.my_block_s_to_s_0, 0), (self.blocks_file_sink_0, 0)) File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, line 130, in connect self._connect(points[i-1], points[i]) File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, line 141, in _connect self._tb.primitive_connect(src_block.to_basic_block(), src_port, AttributeError: 'function' object has no attribute 'to_basic_block' I have found the error (or at least I am closer): The Python code that GRC generates is slightly different between v3.6.4.2 and v3.7.0 for the same test flowgraph. Namely, the newer version omits an empty set of parens, thusly: From v3.6.4.2 : ## # Blocks ## self.my_oot_my_block_0 = my_oot.my_block() From v3.7.0 : ## # Blocks ## self.my_oot_my_block_0 = my_oot.my_block My block has no parameters (thus the empty parens). If I manually edit the v3.7.0 generated py code to add the missing parens, it all works fine as with v3.6.4.2. Question: Is this a v3.7.0 bug, or some subtle coding error in my OOT module? As far as I can tell, I converted it according to the 3.6 - 3.7 recipe. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AttributeError: 'function' object has no attribute 'to_basic_block' ? (GR 3.7.0)
One of my OOT blocks is a function that takes in shorts and outputs shorts (a 1-to-2 interpolator). I have a simple flowgraph created in GRC: File Source - My block - File sync . GRC is happy until I run the flowgraph, and I get this: Executing: /top_block.py Traceback (most recent call last): File /top_block.py, line 54, in module tb = top_block() File /top_block.py, line 39, in __init__ self.connect((self.my_block_s_to_s_0, 0), (self.blocks_file_sink_0, 0)) File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, line 130, in connect self._connect(points[i-1], points[i]) File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, line 141, in _connect self._tb.primitive_connect(src_block.to_basic_block(), src_port, AttributeError: 'function' object has no attribute 'to_basic_block' I have found the error (or at least I am closer): The Python code that GRC generates is slightly different between v3.6.4.2 and v3.7.0 for the same test flowgraph. Namely, the newer version omits an empty set of parens, thusly: From v3.6.4.2 : ## # Blocks ## self.my_oot_my_block_0 = my_oot.my_block() From v3.7.0 : ## # Blocks ## self.my_oot_my_block_0 = my_oot.my_block My block has no parameters (thus the empty parens). If I manually edit the v3.7.0 generated py code to add the missing parens, it all works fine as with v3.6.4.2. Question: Is this a v3.7.0 bug, or some subtle coding error in my OOT module? As far as I can tell, I converted it according to the 3.6 - 3.7 recipe. Answer: This was my subtle coding error. I left the empty parens out of the XML file's 'make' entry (last line below). File: my_oot_my_block.xml block namemy_block/name keymy_oot_my_block/key categorymy_oot/category importimport my_oot/import makemy_oot.my_block/make - Forgot () after the name. Case closed. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AttributeError: 'function' object has no attribute 'to_basic_block' ? (GR 3.7.0)
I've stepped up to GR 3.7.0, re-used gr_modtool to freshly re-create my OOT module, everything builds, tests, installs OK. GRC has my OOT blocks listed and I can put them on my flowgraph. One of my OOT blocks is a function that takes in shorts and outputs shorts (a 1-to-2 interpolator). I have a simple flowgraph created in GRC: File Source - My block - File sync . GRC is happy until I run the flowgraph, and I get this: Executing: /top_block.py Traceback (most recent call last): File /top_block.py, line 54, in module tb = top_block() File /top_block.py, line 39, in __init__ self.connect((self.my_block_s_to_s_0, 0), (self.blocks_file_sink_0, 0)) File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, line 130, in connect self._connect(points[i-1], points[i]) File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py, line 141, in _connect self._tb.primitive_connect(src_block.to_basic_block(), src_port, AttributeError: 'function' object has no attribute 'to_basic_block' An update. First, I believe I exhaustively eradicated older installed versions of GR by searching and deleting for anything named '*gnuradio*' under /usr, re-built GR and re-installed. But, same results. Using the pdb single step debugger and also just looking at the code, I have a question about top_block.py (under /usr/local/lib/python2.7/dist-packages/gnuradio/gr): def _connect(self, src, dst): (src_block, src_port) = self._coerce_endpoint(src) (dst_block, dst_port) = self._coerce_endpoint(dst) self._tb.primitive_connect(src_block.to_basic_block(), src_port, dst_block.to_basic_block(), dst_port) def _coerce_endpoint(self, endp): if hasattr(endp, 'to_basic_block'): return (endp, 0) else: if hasattr(endp, __getitem__) and len(endp) == 2: return endp # Assume user put (block, port) else: raise ValueError(unable to coerce endpoint) I'm not a python expert, but _coerce_endpoint is checking if the attribute 'to_basic_block' exists... But then the _connect function goes right ahead and tries to use it as it prepares to call primitive_connect, which is what the error is about... And single stepping through the python code seems to verify that... (in my case, the test for __getitem__ and len(endp) == 2 is the path the code takes). I also don't understand why _coerce_endpoint in that path returns ony endp, but in its other leg, returns (endp, 0)? Seems like the caller wants to assign 2 values (src_block, src_port)... This part of the top_block.py code is the same between 3.6.4.2 and 3.7.0... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio