Re: [Discuss-gnuradio] Code of USRP experimental setup of full-duplex radio
Nader, an apology for making that sound a bit rough. You did mention you were a beginner, so I should have expanded the answer. My second point was a link to our module management system. Using that (and you might even have used to install GNU Radio itself) you can simply install an 802.15.4 module (you'll need to check how complete it is). Follow the instructions on the link I pointed out. For me, Google returns said 802.15.4 module as first result, followed by lots and lots of papers. That might differ for you since Google personalizes their results. You won't, however, need that if you use PyBOMBS (unless you're searching for the papers). Hope this was actually helpful! Martin On 02/19/2015 07:54 PM, Martin Braun wrote: > Nader, > > please answer to mailing list, not inviduals. > > You can just use Google, you can find it here: www.google.com :) > PyBOMBS: http://gnuradio.org/redmine/projects/pybombs/wiki > > Cheers, > M > > On 02/19/2015 02:03 PM, Nader Bouacida wrote: >> Hi Martin, >> >> What is the search engine do you use? Can you give some links to help me? >> I'm beginner with USRP devices. It's my first time I will use them. >> >> Best regards, >> Nader >> >> From: discuss-gnuradio-bounces+nader.bouacida=kaust.edu...@gnu.org >> [discuss-gnuradio-bounces+nader.bouacida=kaust.edu...@gnu.org] on behalf of >> Martin Braun [martin.br...@ettus.com] >> Sent: Thursday, February 19, 2015 3:52 PM >> To: discuss-gnuradio@gnu.org >> Subject: Re: [Discuss-gnuradio] Code of USRP experimental setup of >> full-duplex radio >> >> On 02/19/2015 01:33 PM, Nader Bouacida wrote: >>> I should create a testbed with USRP2 devices or stimulate a >>> full-duplex environment with ns-2. So, I need the code of experimental >>> setup to implement a practical 802.15.4 full-duplex radio or any >>> full-duplex environment. If possible, can you provide me with the code >>> of USRP experimental setup of full-duplex application or ns-2 simulation >>> of full-duplex environment ? I would very grateful to you if you help me >>> because I didn't find the code in the Internet. >>> >>> I appreciate your time and consideration. >> >> Nader, >> >> I find that hard to believe. I get tons of results using the search >> engine of my choice, and it's even in PyBOMBS. Please have another look. >> >> M >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> This message and its contents including attachments are intended solely for >> the original recipient. If you are not the intended recipient or have >> received this message in error, please notify me immediately and delete this >> message from your computer system. Any unauthorized use or distribution is >> prohibited. Please consider the environment before printing this email. >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GPSDO and B2100
On 02/19/2015 07:47 PM, Sharath Ananth wrote: > Hello, I recently installed a board mounted GPSDO (TCXO) on my B2100. > Specifically I am using this in a USB powered mode and the web-site > did say that the TCXO works off the USB power. I am using a passive > antenna at the moment. > > Now most of the time I get warning display "No GPRMC message found". > Only in two cases during the day have I seen the green LED on the > GPSDO turn on, in which case the warning message went away, so I know > all is well with the board and the mount. > > Now my questions: (i) Is there a way to force the B2100 to use the > internal clock and not wait for the GPS fix for all applications? For > example I don't want to change the uhd_usrp_proble executable, but > would like the board to use the internal clock and not wait for GPS > fix. Is there a way to toggle the mode from automatic to internal > clock for all applications via a jumper or other means? I don't want > to recompile other working applications just because I have installed > the GPSDO. There's no jumper or hardware way (short of taking out the GPSDO). You can call set_clock_source() (see the manual: http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a73ed40009d0d3787c183d42423d25026) If you're using GNU Radio & Python, that won't require a recompile (see the GR manual: http://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html#aac2a32bcaa207c18a0b8c037760508e6). > (ii) Does the active antenna work of USB power? You should be good, but in general, GPSDO+2x2 MIMO pushes what bus power can provide and is considered unreliable. > (ii) Once the GPS actually starts working, how can I use gpsd to get > the gps data. That is, the web page > http://files.ettus.com/manual/page_gpsdo_b2x0.html says "Other > information can be fetched as well. You can query the lock status > with the gps_locked sensor, as well as obtain raw NMEA sentences > using the gps_gprmc, and gps_gpgga sensors. Location information can > be parsed out of the gps_gpgga sensor by using gpsd or another NMEA > parser." The last sentence is what I want. I just had a very brief look at the gpsd man page, and it seems it works with devices that are directly connected to the PC -- this isn't how the B2x0 + GPSDO where intended to be used (you won't find an 'attached GPS device' on USB anywhere). If you want to use gpsd, you'll probably need to 'fake' such a device by polling the NMEA strings. Maybe someone out here has done that before? Cheers, M > I do have gpsd and gpsdx installed on my Mac. However neither can be > configured to actually get the data from the GPSDO module. For > example the options in the gpsdx does not see an external USB GPS to > begin with. > > Any suggestions are welcome. > > Thanks, Sharath > > > > > > > > > ___ 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] Msg passing + tag streaming: Is this flowgraph possible?
Hello, I would like to run a flowgraph similar to the one I attach in a picture. It would work as follows: USRP source would send frames with tags indicating the "rx_freq" of these samples. Then the power of those samples will be calculated. Will the "rx_freq tag" still be present at the input of the Tagged File Sink or does any block in the middle get rid of them? If still present in the Tagged File Sink, this block would store centain number of vectors. Lets say 5 vectors of 2048 lenght (this would give me 5 power estimations of the current band). When the number of stored vectors reaches a threshold, the Tagged File sink would stop storing samples and would send a "center_freq" message to the USRP in order to tune it to a new frequency. Then Tagged File Sink would wait for the new "rx_freq" tag to store samples (this way I would discard the old frequency samples). Is this flowgraph feasible? In case it is, I think I only have to program my custom "Tagged File Sink" with a vector data input port and a message output port. Is that correct? Any suggestions/ideas? Thanks in advance, Jorge ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Grcc from ssh session
Hi, I'm want to use grcc from an ssh session but I get the error importing the module Colors.py. I've seen this thread http://lists.gnu.org/archive/html/discuss-gnuradio/2013-06/msg00361.html about it. I'm using 3.7.5 and it seems like the patch it's been applied to the source code already. There are no differences between what the patch suggests and the source code that the installer script downloaded to my machine. However, I still get the import error (only when I use ssh). Thanks, Murray ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Msg passing + tag streaming: Is this flowgraph possible?
On 02/20/2015 09:33 AM, Jorge Gallo wrote: > Hello, > > I would like to run a flowgraph similar to the one I attach in a > picture. It would work as follows: > > USRP source would send frames with tags indicating the "rx_freq" of > these samples. Then the power of those samples will be calculated. > > Will the "rx_freq tag" still be present at the input of the Tagged File > Sink or does any block in the middle get rid of them? These blocks will keep the tags in there. > If still present in the Tagged File Sink, this block would store centain > number of vectors. Lets say 5 vectors of 2048 lenght (this would give me > 5 power estimations of the current band). > > When the number of stored vectors reaches a threshold, the Tagged File > sink would stop storing samples and would send a "center_freq" message > to the USRP in order to tune it to a new frequency. Then Tagged File > Sink would wait for the new "rx_freq" tag to store samples (this way I > would discard the old frequency samples). > > Is this flowgraph feasible? Yes, it's possible. However, I'm not sure it'll do exactly what you want (or maybe I'm misunderstanding), for two reasons: - Say you send a msg to the USRP source after you've received 5 vectors of spectral estimate. The USRP source will already be way ahead of your downstream block, so you could potentially be getting hundreds of vectors to process. They will be tagged, so you can discard them if you like. - The Vector IIR will not know that you've retuned, so you will be "smearing" together vectors that don't belong together. What you need is a form of integrate-and-dump -- maybe the gr-specest toolbox can help you with that. > In case it is, I think I only have to program my custom "Tagged File > Sink" with a vector data input port and a message output port. Is that > correct? Apart from what I mentioned above, yes. You might want to choose a different approach, e.g. an open loop approach where you simply send a retune message every N milliseconds. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Grcc from ssh session
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/20/2015 10:01 AM, Murray Thomson wrote: > Hi, > > I'm want to use grcc from an ssh session but I get the error importing the module Colors.py. > I've seen this thread http://lists.gnu.org/archive/html/discuss-gnuradio/2013-06/msg00361.html about it. I'm using 3.7.5 and it seems like the patch it's been applied to the source code already. There are no differences between what the patch suggests and the source code that the installer script downloaded to my machine. However, I still get the import error (only when I use ssh). > > Thanks, > Murray I tried to reproduce this on the current master. I also get "Unable to import Colors", but it is not an exception. grcc still completes and the output file is generated. Sebastian -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJU5wwQAAoJEIcqoDnyZkMDYQEP/0Mqmeb5d0K3A8G5k8u4LtUk GGHTyVq28h/NAh5NiShF7bFP3IsrLzJuQF3+2AKF8s1nK2WW/vf2RVnO5V+jpxGJ PFbz9GgGSoUPqL7PyTACNo8hJvN6BqMAlVY9luO2YVZSDQGLnyQZm4LEe8WII4fx v52yoxFXhApn6qNjjEybzQ0zP9oQ0bFyGuo5oLBMeeSuRfGspNGfRBu+R2XlzD4C DibsTIm/7qHCZBrbAdMmCB175OiZtpiPJvbS9D5kLT2+HLvHj0eSWW4rXXKGnfNY y3NSvc6Mkul/bhip1sy2kY00yNWeECEyirblYRXsipXrxiGe3pMcwV9+7KbZeZMJ bB/7dbhu+Zlzg1jAKJatSylzgAbLbEnDSW3zgfy6XEjnigi4QyOoQnxECpmSfXQ6 hndyuFbys5mabTekwDPedpj9IOt9TU19gckkSyKgNmQyHbNFP9IvTuS1O4Ypwrew idaSzog+oyXNYYKpKxF49saf/XQpF0a4i2GxEq/DYRFzP5CyoONTMHt4SZiQ1jOg zJS09VozAHOdbjKvjhuFTYmPdKmzoOlQpMIsFpC262xMYBwrM/WM44ifkBmVBwQf wqcZXCAL9o4hsf72ztNdJpaAFZ+3jpbTfxe1ZtbTRCmi4izzx9qs27zTh8/sCBMA tvrcVW5tx1GKV5Wthioo =M2lH -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] pybombs
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
Re: [Discuss-gnuradio] Msg passing + tag streaming: Is this flowgraph possible?
On 20 February 2015 at 10:26, Martin Braun wrote: > On 02/20/2015 09:33 AM, Jorge Gallo wrote: > > Hello, > > > > I would like to run a flowgraph similar to the one I attach in a > > picture. It would work as follows: > > > > USRP source would send frames with tags indicating the "rx_freq" of > > these samples. Then the power of those samples will be calculated. > > > > Will the "rx_freq tag" still be present at the input of the Tagged File > > Sink or does any block in the middle get rid of them? > > These blocks will keep the tags in there. > > > If still present in the Tagged File Sink, this block would store centain > > number of vectors. Lets say 5 vectors of 2048 lenght (this would give me > > 5 power estimations of the current band). > > > > When the number of stored vectors reaches a threshold, the Tagged File > > sink would stop storing samples and would send a "center_freq" message > > to the USRP in order to tune it to a new frequency. Then Tagged File > > Sink would wait for the new "rx_freq" tag to store samples (this way I > > would discard the old frequency samples). > > > > Is this flowgraph feasible? > > Yes, it's possible. However, I'm not sure it'll do exactly what you want > (or maybe I'm misunderstanding), for two reasons: > > - Say you send a msg to the USRP source after you've received 5 vectors > of spectral estimate. The USRP source will already be way ahead of your > downstream block, so you could potentially be getting hundreds of > vectors to process. They will be tagged, so you can discard them if you > like. > Yes, that is the idea. Since the flowgraph is continuously running many unwanted samples will arrive to my tagged file sink after a tune. I will discard them until I receive a sample with the correct "rx_freq" tag. > - The Vector IIR will not know that you've retuned, so you will be > "smearing" together vectors that don't belong together. What you need is > a form of integrate-and-dump -- maybe the gr-specest toolbox can help > you with that. > > I implemented this block in order to do a moving average but as you said it is problematic. The average should be done with the samples written in the files so that if averaging is needed it will be done by the SW which post-processes the written power samples. Without the IIR block, do you see any problem about mixing of wanted and unwanted samples? If I understood it correctly, after a tuning, the USRP source will send automatically the "rx_freq" tag so I have to do nothing to implement the tag streaming. Is it correct? > > In case it is, I think I only have to program my custom "Tagged File > > Sink" with a vector data input port and a message output port. Is that > > correct? > > Apart from what I mentioned above, yes. You might want to choose a > different approach, e.g. an open loop approach where you simply send a > retune message every N milliseconds. > Does your new approach have any advantage? I see that the signal processing (either approach) will have a host-dependent latency so that your "X miliseconds" parameter would have to be calibrated when different hosts used. Furthermore by monitoring the number of samples written to files I get more control about how much information I write in files. I am open to new solutions before I program something so any tips are more than welcomed. Many many thanks. > > M > > > ___ > 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
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
Re: [Discuss-gnuradio] pybombs
On Fri, Feb 20, 2015 at 6: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 > I'm actually seeing the same response about the failure to load recipes. Not at all sure why, because pybombs and app_store do pretty much the same thing to read in the recipes, but the former works and the latter doesn't. Haven't been able to trace down why. Tom > > 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 > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] pybombs
It doesn’t play any role whether or not I type sudo before ./app_store.py getting the same output, I have tried to change the prefix with the same result, so not quite sure what is is causing this error ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the user_peripheral kernel module to work
Could you clarify a bit what you meant by 'check the needed version'? I've cloned some of the reps and did the checkouts with the hashes, but I always just end up in a 'detached HEAD' state. e.g. $ git checkout 5f96c9333ea3ebdf52dd10f1a2cbc1532ff97009 Note: checking out '5f96c9333ea3ebdf52dd10f1a2cbc1532ff97009'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name HEAD is now at 5f96c93... gr-baz : Bump revision. Doing git branch just shows that I am at * (detached from 5f96c93). Should I try hunting down each repo branch where the specific commit was made and then edit the manifest.xml file? I tried going into oe-repo/.repo/manifest.xml and editing the revision values by changing them from hashes to actual branch names (i.e. master, dizzy, 1.24, etc. etc.) and after doing that repo sync did work in retrieving all of the repos. However, doing git branch on any of those returned a (no branch), which may or may not be expected. Sorry if some of this stuff seems obvious, I'm pretty dumb when it comes to git. Sarunas From: Philip Balister Sent: 19 February 2015 18:58 To: Sarunas Kalade; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the user_peripheral kernel module to work On 02/19/2015 08:58 AM, Sarunas Kalade wrote: > I tried doing this and got a fetch error again. (tried for stable, master, > dizzy and daisy got the exact same result) > $ repo init -u git://github.com/balister/oe-gnuradio-manifest.git -b dizzy > $ repo sync > > Fetching project meta-ettus > error: Cannot fetch meta-ettus > error: Exited sync due to fetch errors This is the problem you need to solve. Can you read the manifest file to see what repo it is using atry to clone by hand and check the needed version. Hopefully that makes the problem clearer. Something like: git clone git://github.com/EttusResearch/meta-ettus.git cd meta-ettus/ git checkout 9f47e8c6d4a91a06bd6c907f2d27ba40deaa0a2f Philip > > However, just setting my bblayers.conf to (using all Daisy branches btw) > BBLAYERS ?= " \ > /home/sarunas/oe-core/meta \ > /home/sarunas/layers/meta-xilinx \ > /home/sarunas/layers/meta-oe/meta-oe \ > /home/sarunas/layers/meta-oe/meta-networking \ > /home/sarunas/layers/meta-oe/meta-filesystems \ > /home/sarunas/layers/meta-sdr \ > " > And using the local.conf options as per you example ( > https://github.com/balister/meta-sdr/blob/master/conf/local.conf.sample ) > does seem to work for me and I can bitbake a gnuradio-dev-image. I just can't > include the meta-gnuradio-zynq layer, because I don't really know which > branches to use for all this. > meta-gnuradio-zynq is not maintained. I can't help you with anything on Jonathons wiki. Philip > Also tried doing the zynq-gnuradio-manifest again > $ repo init -u git://github.com/jpendlum/zynq-gnuradio-manifest.git > $ repo sync > > Fetching project meta-xilinx > Fetching projects: 11% (1/9) Fetching project bitbake > error: Cannot fetch bitbake > error: Exited sync due to fetch errors > > Which is kinda weird, because last time it failed at fetching oe-core. > > From: Philip Balister > Sent: 18 February 2015 21:23 > To: Sarunas Kalade; discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the > user_peripheral kernel module to work > > On 02/18/2015 12:50 PM, Sarunas Kalade wrote: >> Hey Philip, >> >> Thanks for the reply. I'm fairly sure I was using the same repo init command >> as shown in the wiki: >> repo init -u git://github.com/jpendlum/zynq-gnuradio-manifest.git >> repo sync > > https://github.com/balister/oe-gnuradio-manifest/tree/dizzy > > Use this. I keep this up to date. The dizzy branch is the best place to > start now. > > I need to ask Jonathon to put a warning about being old on his wiki page :) > > Philip > >> >> I tried the same thing just now on a relatively fresh Ubuntu (14.04) install >> on my laptop, which resulted in the following: >> $ repo init -u git://github.com/jpendlum/zynq-gnuradio-manifest.git >> >> $ repo sync >> Fetching project zynq-acp >> Fetching projects: 11% (1/9) Fetching project zynq-fir-filter-example >> Fetching projects: 22% (2/9) Fetching project meta-sdr >> error: Cannot fetch meta-sdr >> >> error: Exited sync due to fetch errors >> >> I also tried initing just the oe-gnuradio-manifest : >> >> $ repo init -u git://github.com/balister/oe-gnuradio-manifest -b stable >> (got th
Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the user_peripheral kernel module to work
On 02/20/2015 09:47 AM, Sarunas Kalade wrote: > Could you clarify a bit what you meant by 'check the needed version'? I've > cloned some of the reps and did the checkouts with the hashes, but I always > just end up in a 'detached HEAD' state. > > e.g. > $ git checkout 5f96c9333ea3ebdf52dd10f1a2cbc1532ff97009 > Note: checking out '5f96c9333ea3ebdf52dd10f1a2cbc1532ff97009'. > > You are in 'detached HEAD' state. You can look around, make experimental > changes and commit them, and you can discard any commits you make in this > state without impacting any branches by performing another checkout. > > If you want to create a new branch to retain commits you create, you may > do so (now or later) by using -b with the checkout command again. Example: > > git checkout -b new_branch_name > > HEAD is now at 5f96c93... gr-baz : Bump revision. > > > Doing git branch just shows that I am at * (detached from 5f96c93). Should I > try hunting down each repo branch where the specific commit was made and then > edit the manifest.xml file? > > I tried going into oe-repo/.repo/manifest.xml and editing the revision values > by changing them from hashes to actual branch names (i.e. master, dizzy, > 1.24, etc. etc.) and after doing that repo sync did work in retrieving all of > the repos. However, doing git branch on any of those returned a (no branch), > which may or may not be expected. > > Sorry if some of this stuff seems obvious, I'm pretty dumb when it comes to > git. It sounds like you can check out meta-ettus from the command line, but repo is running into a problem. I've done builds in vm's to try and detect all my cached credentials and haven't seen your issue. Can you confirm you succesfully checked out meta-ettus? Philip > > Sarunas > > > From: Philip Balister > Sent: 19 February 2015 18:58 > To: Sarunas Kalade; discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the > user_peripheral kernel module to work > > On 02/19/2015 08:58 AM, Sarunas Kalade wrote: >> I tried doing this and got a fetch error again. (tried for stable, master, >> dizzy and daisy got the exact same result) >> $ repo init -u git://github.com/balister/oe-gnuradio-manifest.git -b >> dizzy >> $ repo sync >> >> Fetching project meta-ettus >> error: Cannot fetch meta-ettus >> error: Exited sync due to fetch errors > > This is the problem you need to solve. Can you read the manifest file to > see what repo it is using atry to clone by hand and check the needed > version. Hopefully that makes the problem clearer. > > Something like: > > git clone git://github.com/EttusResearch/meta-ettus.git > cd meta-ettus/ > git checkout 9f47e8c6d4a91a06bd6c907f2d27ba40deaa0a2f > > Philip > >> >> However, just setting my bblayers.conf to (using all Daisy branches btw) >> BBLAYERS ?= " \ >> /home/sarunas/oe-core/meta \ >> /home/sarunas/layers/meta-xilinx \ >> /home/sarunas/layers/meta-oe/meta-oe \ >> /home/sarunas/layers/meta-oe/meta-networking \ >> /home/sarunas/layers/meta-oe/meta-filesystems \ >> /home/sarunas/layers/meta-sdr \ >> " >> And using the local.conf options as per you example ( >> https://github.com/balister/meta-sdr/blob/master/conf/local.conf.sample ) >> does seem to work for me and I can bitbake a gnuradio-dev-image. I just >> can't include the meta-gnuradio-zynq layer, because I don't really know >> which branches to use for all this. >> > > meta-gnuradio-zynq is not maintained. I can't help you with anything on > Jonathons wiki. > > Philip > > >> Also tried doing the zynq-gnuradio-manifest again >> $ repo init -u git://github.com/jpendlum/zynq-gnuradio-manifest.git >> $ repo sync >> >> Fetching project meta-xilinx >> Fetching projects: 11% (1/9) Fetching project bitbake >> error: Cannot fetch bitbake >> error: Exited sync due to fetch errors >> >> Which is kinda weird, because last time it failed at fetching oe-core. >> >> From: Philip Balister >> Sent: 18 February 2015 21:23 >> To: Sarunas Kalade; discuss-gnuradio@gnu.org >> Subject: Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the >> user_peripheral kernel module to work >> >> On 02/18/2015 12:50 PM, Sarunas Kalade wrote: >>> Hey Philip, >>> >>> Thanks for the reply. I'm fairly sure I was using the same repo init >>> command as shown in the wiki: >>> repo init -u git://github.com/jpendlum/zynq-gnuradio-manifest.git >>> repo sync >> >> https://github.com/balister/oe-gnuradio-manifest/tree/dizzy >> >> Use this. I keep this up to date. The dizzy branch is the best place to >> start now. >> >> I need to ask Jonathon to put a warning about being old on his wiki page :) >> >> Philip >> >>> >>> I tried the same thing just now on a relatively fresh Ubuntu (14.04) >>> install on my laptop, which resulted in the following: >>>
Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the user_peripheral kernel module to work
$ git clone git://github.com/EttusResearch/meta-ettus.git
$ cd meta-ettus/
$ git checkout 9f47e8c6d4a91a06bd6c907f2d27ba40deaa0a2f
Note: checking out '9f47e8c6d4a91a06bd6c907f2d27ba40deaa0a2f'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at 9f47e8c... Add script to build factory image for E310.
Doing git log brings up all the commits done up until the one I just checked
out, so I'm assuming it's behaving properly. I can also git checkout master or
e300-daisy with no issues.
Also when I tried to bypass meta-ettus, by force syncing I've noticed that it's
not just meta-ettus that repo can't fetch - it's all of them.
$ repo init -u git://github.com/balister/oe-gnuradio-manifest -b dizzy
$ repo sync -f
Fetching project meta-ettus
error: Cannot fetch meta-ettus
warn: --force-broken, continuing to sync
Fetching projects: 11% (1/9) Fetching project bitbake
error: Cannot fetch bitbake
warn: --force-broken, continuing to sync
Fetching projects: 22% (2/9) Fetching project meta-fsl-arm-extra
error: Cannot fetch meta-fsl-arm-extra
warn: --force-broken, continuing to sync
Fetching projects: 33% (3/9) Fetching project meta-sdr
error: Cannot fetch meta-sdr
warn: --force-broken, continuing to sync
Fetching projects: 44% (4/9) Fetching project meta-xilinx
error: Cannot fetch meta-xilinx
warn: --force-broken, continuing to sync
Fetching projects: 55% (5/9) Fetching project oe-core
error: Cannot fetch oe-core
warn: --force-broken, continuing to sync
Fetching projects: 66% (6/9) Fetching project meta-oe
error: Cannot fetch meta-oe
warn: --force-broken, continuing to sync
Fetching projects: 77% (7/9) Fetching project meta-ti
error: Cannot fetch meta-ti
warn: --force-broken, continuing to sync
Fetching projects: 88% (8/9) Fetching project meta-fsl-arm
Fetching projects: 100% (9/9), done.
fatal: failed to unpack tree object HEAD
Traceback (most recent call last):
File "/home/sarunas/oe-repo/.repo/repo/main.py", line 506, in
_Main(sys.argv[1:])
File "/home/sarunas/oe-repo/.repo/repo/main.py", line 482, in _Main
result = repo._Run(argv) or 0
File "/home/sarunas/oe-repo/.repo/repo/main.py", line 161, in _Run
result = cmd.Execute(copts, cargs)
File "/home/sarunas/oe-repo/.repo/repo/subcmds/sync.py", line 681, in Execute
project.Sync_LocalHalf(syncbuf)
File "/home/sarunas/oe-repo/.repo/repo/project.py", line 1196, in
Sync_LocalHalf
self._InitWorkTree()
File "/home/sarunas/oe-repo/.repo/repo/project.py", line 2296, in
_InitWorkTree
raise GitError("cannot initialize work tree")
error.GitError: cannot initialize work tree
Sarunas
From: Philip Balister
Sent: 20 February 2015 18:23
To: Sarunas Kalade; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the
user_peripheral kernel module to work
On 02/20/2015 09:47 AM, Sarunas Kalade wrote:
> Could you clarify a bit what you meant by 'check the needed version'? I've
> cloned some of the reps and did the checkouts with the hashes, but I always
> just end up in a 'detached HEAD' state.
>
> e.g.
> $ git checkout 5f96c9333ea3ebdf52dd10f1a2cbc1532ff97009
> Note: checking out '5f96c9333ea3ebdf52dd10f1a2cbc1532ff97009'.
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again. Example:
>
> git checkout -b new_branch_name
>
> HEAD is now at 5f96c93... gr-baz : Bump revision.
>
>
> Doing git branch just shows that I am at * (detached from 5f96c93). Should I
> try hunting down each repo branch where the specific commit was made and then
> edit the manifest.xml file?
>
> I tried going into oe-repo/.repo/manifest.xml and editing the revision values
> by changing them from hashes to actual branch names (i.e. master, dizzy,
> 1.24, etc. etc.) and after doing that repo sync did work in retrieving all of
> the repos. However, doing git branch on any of those returned a (no branch),
> which may or may not be expected.
>
> Sorry if some of this stuff seems obvious, I'm pretty dumb when it comes to
> git.
It sounds like you can check out meta-ettus from the command line, but
repo is running into a problem. I've done builds in vm's to try and
detect all my cached credentials and haven't seen your issue. Can you
confirm you succesfully checked out meta-ettus?
Philip
>
> Sarunas
>
>
Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the user_peripheral kernel module to work
On 02/20/2015 10:52 AM, Sarunas Kalade wrote:
> $ git clone git://github.com/EttusResearch/meta-ettus.git
> $ cd meta-ettus/
> $ git checkout 9f47e8c6d4a91a06bd6c907f2d27ba40deaa0a2f
> Note: checking out '9f47e8c6d4a91a06bd6c907f2d27ba40deaa0a2f'.
Thanks. I will now sit in the corner and go insane :)
I'm going to try making another clean vm and testing. My current
thinking is maybe there has been an update to repo that changed something.
In the short term, you should be able to checkout the layers called for
in the manifest and go from there.
Thanks,
Philip
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again. Example:
>
> git checkout -b new_branch_name
>
> HEAD is now at 9f47e8c... Add script to build factory image for E310.
>
> Doing git log brings up all the commits done up until the one I just checked
> out, so I'm assuming it's behaving properly. I can also git checkout master
> or e300-daisy with no issues.
>
>
> Also when I tried to bypass meta-ettus, by force syncing I've noticed that
> it's not just meta-ettus that repo can't fetch - it's all of them.
>
> $ repo init -u git://github.com/balister/oe-gnuradio-manifest -b dizzy
> $ repo sync -f
> Fetching project meta-ettus
> error: Cannot fetch meta-ettus
> warn: --force-broken, continuing to sync
> Fetching projects: 11% (1/9) Fetching project bitbake
> error: Cannot fetch bitbake
> warn: --force-broken, continuing to sync
> Fetching projects: 22% (2/9) Fetching project meta-fsl-arm-extra
> error: Cannot fetch meta-fsl-arm-extra
> warn: --force-broken, continuing to sync
> Fetching projects: 33% (3/9) Fetching project meta-sdr
> error: Cannot fetch meta-sdr
> warn: --force-broken, continuing to sync
> Fetching projects: 44% (4/9) Fetching project meta-xilinx
> error: Cannot fetch meta-xilinx
> warn: --force-broken, continuing to sync
> Fetching projects: 55% (5/9) Fetching project oe-core
> error: Cannot fetch oe-core
> warn: --force-broken, continuing to sync
> Fetching projects: 66% (6/9) Fetching project meta-oe
> error: Cannot fetch meta-oe
> warn: --force-broken, continuing to sync
> Fetching projects: 77% (7/9) Fetching project meta-ti
> error: Cannot fetch meta-ti
> warn: --force-broken, continuing to sync
> Fetching projects: 88% (8/9) Fetching project meta-fsl-arm
> Fetching projects: 100% (9/9), done.
> fatal: failed to unpack tree object HEAD
> Traceback (most recent call last):
> File "/home/sarunas/oe-repo/.repo/repo/main.py", line 506, in
> _Main(sys.argv[1:])
> File "/home/sarunas/oe-repo/.repo/repo/main.py", line 482, in _Main
> result = repo._Run(argv) or 0
> File "/home/sarunas/oe-repo/.repo/repo/main.py", line 161, in _Run
> result = cmd.Execute(copts, cargs)
> File "/home/sarunas/oe-repo/.repo/repo/subcmds/sync.py", line 681, in
> Execute
> project.Sync_LocalHalf(syncbuf)
> File "/home/sarunas/oe-repo/.repo/repo/project.py", line 1196, in
> Sync_LocalHalf
> self._InitWorkTree()
> File "/home/sarunas/oe-repo/.repo/repo/project.py", line 2296, in
> _InitWorkTree
> raise GitError("cannot initialize work tree")
> error.GitError: cannot initialize work tree
>
> Sarunas
>
> From: Philip Balister
> Sent: 20 February 2015 18:23
> To: Sarunas Kalade; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the
> user_peripheral kernel module to work
>
> On 02/20/2015 09:47 AM, Sarunas Kalade wrote:
>> Could you clarify a bit what you meant by 'check the needed version'? I've
>> cloned some of the reps and did the checkouts with the hashes, but I always
>> just end up in a 'detached HEAD' state.
>>
>> e.g.
>> $ git checkout 5f96c9333ea3ebdf52dd10f1a2cbc1532ff97009
>> Note: checking out '5f96c9333ea3ebdf52dd10f1a2cbc1532ff97009'.
>>
>> You are in 'detached HEAD' state. You can look around, make experimental
>> changes and commit them, and you can discard any commits you make in this
>> state without impacting any branches by performing another checkout.
>>
>> If you want to create a new branch to retain commits you create, you may
>> do so (now or later) by using -b with the checkout command again. Example:
>>
>> git checkout -b new_branch_name
>>
>> HEAD is now at 5f96c93... gr-baz : Bump revision.
>>
>>
>> Doing git branch just shows that I am at * (detached from 5f96c93). Should I
>> try hunting down each repo branch where the specific commit was made and
>> then edit the manifest.xml file?
>>
>> I tried going into oe-repo/.repo/manifest.xml and editing the revision
>> values by changing them from hashes to actual branch names (i.e. master,
>> dizzy, 1.24, etc
Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the user_peripheral kernel module to work
Sorry for potentially being a source of temporal madness : / Let me know if I
can provide any more info that could be useful.
Just FYI about recreating the issue: I tried it on a desktop Ubuntu 14.04, a
fresh Ubuntu 14.04 VM, a Debian VM and just now on a colleague’s Ubuntu 12.04
VM.
Worst case I've still got the prebuilt filesystem, which works fine. Just need
to do some more reading on the FPGA side of things.
Thanks for taking the time to help out!
Sarunas
From: Philip Balister
Sent: 20 February 2015 19:11
To: Sarunas Kalade; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the
user_peripheral kernel module to work
On 02/20/2015 10:52 AM, Sarunas Kalade wrote:
> $ git clone git://github.com/EttusResearch/meta-ettus.git
> $ cd meta-ettus/
> $ git checkout 9f47e8c6d4a91a06bd6c907f2d27ba40deaa0a2f
> Note: checking out '9f47e8c6d4a91a06bd6c907f2d27ba40deaa0a2f'.
Thanks. I will now sit in the corner and go insane :)
I'm going to try making another clean vm and testing. My current
thinking is maybe there has been an update to repo that changed something.
In the short term, you should be able to checkout the layers called for
in the manifest and go from there.
Thanks,
Philip
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again. Example:
>
> git checkout -b new_branch_name
>
> HEAD is now at 9f47e8c... Add script to build factory image for E310.
>
> Doing git log brings up all the commits done up until the one I just checked
> out, so I'm assuming it's behaving properly. I can also git checkout master
> or e300-daisy with no issues.
>
>
> Also when I tried to bypass meta-ettus, by force syncing I've noticed that
> it's not just meta-ettus that repo can't fetch - it's all of them.
>
> $ repo init -u git://github.com/balister/oe-gnuradio-manifest -b dizzy
> $ repo sync -f
> Fetching project meta-ettus
> error: Cannot fetch meta-ettus
> warn: --force-broken, continuing to sync
> Fetching projects: 11% (1/9) Fetching project bitbake
> error: Cannot fetch bitbake
> warn: --force-broken, continuing to sync
> Fetching projects: 22% (2/9) Fetching project meta-fsl-arm-extra
> error: Cannot fetch meta-fsl-arm-extra
> warn: --force-broken, continuing to sync
> Fetching projects: 33% (3/9) Fetching project meta-sdr
> error: Cannot fetch meta-sdr
> warn: --force-broken, continuing to sync
> Fetching projects: 44% (4/9) Fetching project meta-xilinx
> error: Cannot fetch meta-xilinx
> warn: --force-broken, continuing to sync
> Fetching projects: 55% (5/9) Fetching project oe-core
> error: Cannot fetch oe-core
> warn: --force-broken, continuing to sync
> Fetching projects: 66% (6/9) Fetching project meta-oe
> error: Cannot fetch meta-oe
> warn: --force-broken, continuing to sync
> Fetching projects: 77% (7/9) Fetching project meta-ti
> error: Cannot fetch meta-ti
> warn: --force-broken, continuing to sync
> Fetching projects: 88% (8/9) Fetching project meta-fsl-arm
> Fetching projects: 100% (9/9), done.
> fatal: failed to unpack tree object HEAD
> Traceback (most recent call last):
> File "/home/sarunas/oe-repo/.repo/repo/main.py", line 506, in
> _Main(sys.argv[1:])
> File "/home/sarunas/oe-repo/.repo/repo/main.py", line 482, in _Main
> result = repo._Run(argv) or 0
> File "/home/sarunas/oe-repo/.repo/repo/main.py", line 161, in _Run
> result = cmd.Execute(copts, cargs)
> File "/home/sarunas/oe-repo/.repo/repo/subcmds/sync.py", line 681, in
> Execute
> project.Sync_LocalHalf(syncbuf)
> File "/home/sarunas/oe-repo/.repo/repo/project.py", line 1196, in
> Sync_LocalHalf
> self._InitWorkTree()
> File "/home/sarunas/oe-repo/.repo/repo/project.py", line 2296, in
> _InitWorkTree
> raise GitError("cannot initialize work tree")
> error.GitError: cannot initialize work tree
>
> Sarunas
>
> From: Philip Balister
> Sent: 20 February 2015 18:23
> To: Sarunas Kalade; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the
> user_peripheral kernel module to work
>
> On 02/20/2015 09:47 AM, Sarunas Kalade wrote:
>> Could you clarify a bit what you meant by 'check the needed version'? I've
>> cloned some of the reps and did the checkouts with the hashes, but I always
>> just end up in a 'detached HEAD' state.
>>
>> e.g.
>> $ git checkout 5f96c9333ea3ebdf52dd10f1a2cbc1532ff97009
>> Note: checking out '5f96c9333ea3ebdf52dd10f1a2cbc1532ff97009'.
>>
>> You are in 'detached HEAD' state. You can look around, make experimental
>> changes and commit them, and you can discard any commits you ma
Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the user_peripheral kernel module to work
On 02/20/2015 12:00 PM, Sarunas Kalade wrote:
> Sorry for potentially being a source of temporal madness : / Let me know if I
> can provide any more info that could be useful.
>
> Just FYI about recreating the issue: I tried it on a desktop Ubuntu 14.04, a
> fresh Ubuntu 14.04 VM, a Debian VM and just now on a colleague’s Ubuntu 12.04
> VM.
I'm a Fedora guy. I wonder if the issue is there.
Philip
>
> Worst case I've still got the prebuilt filesystem, which works fine. Just
> need to do some more reading on the FPGA side of things.
>
> Thanks for taking the time to help out!
>
> Sarunas
>
>
> From: Philip Balister
> Sent: 20 February 2015 19:11
> To: Sarunas Kalade; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the
> user_peripheral kernel module to work
>
> On 02/20/2015 10:52 AM, Sarunas Kalade wrote:
>> $ git clone git://github.com/EttusResearch/meta-ettus.git
>> $ cd meta-ettus/
>> $ git checkout 9f47e8c6d4a91a06bd6c907f2d27ba40deaa0a2f
>> Note: checking out '9f47e8c6d4a91a06bd6c907f2d27ba40deaa0a2f'.
>
> Thanks. I will now sit in the corner and go insane :)
>
> I'm going to try making another clean vm and testing. My current
> thinking is maybe there has been an update to repo that changed something.
>
> In the short term, you should be able to checkout the layers called for
> in the manifest and go from there.
>
> Thanks,
>
> Philip
>
>>
>> You are in 'detached HEAD' state. You can look around, make experimental
>> changes and commit them, and you can discard any commits you make in this
>> state without impacting any branches by performing another checkout.
>>
>> If you want to create a new branch to retain commits you create, you may
>> do so (now or later) by using -b with the checkout command again. Example:
>>
>> git checkout -b new_branch_name
>>
>> HEAD is now at 9f47e8c... Add script to build factory image for E310.
>>
>> Doing git log brings up all the commits done up until the one I just checked
>> out, so I'm assuming it's behaving properly. I can also git checkout master
>> or e300-daisy with no issues.
>>
>>
>> Also when I tried to bypass meta-ettus, by force syncing I've noticed that
>> it's not just meta-ettus that repo can't fetch - it's all of them.
>>
>> $ repo init -u git://github.com/balister/oe-gnuradio-manifest -b dizzy
>> $ repo sync -f
>> Fetching project meta-ettus
>> error: Cannot fetch meta-ettus
>> warn: --force-broken, continuing to sync
>> Fetching projects: 11% (1/9) Fetching project bitbake
>> error: Cannot fetch bitbake
>> warn: --force-broken, continuing to sync
>> Fetching projects: 22% (2/9) Fetching project meta-fsl-arm-extra
>> error: Cannot fetch meta-fsl-arm-extra
>> warn: --force-broken, continuing to sync
>> Fetching projects: 33% (3/9) Fetching project meta-sdr
>> error: Cannot fetch meta-sdr
>> warn: --force-broken, continuing to sync
>> Fetching projects: 44% (4/9) Fetching project meta-xilinx
>> error: Cannot fetch meta-xilinx
>> warn: --force-broken, continuing to sync
>> Fetching projects: 55% (5/9) Fetching project oe-core
>> error: Cannot fetch oe-core
>> warn: --force-broken, continuing to sync
>> Fetching projects: 66% (6/9) Fetching project meta-oe
>> error: Cannot fetch meta-oe
>> warn: --force-broken, continuing to sync
>> Fetching projects: 77% (7/9) Fetching project meta-ti
>> error: Cannot fetch meta-ti
>> warn: --force-broken, continuing to sync
>> Fetching projects: 88% (8/9) Fetching project meta-fsl-arm
>> Fetching projects: 100% (9/9), done.
>> fatal: failed to unpack tree object HEAD
>> Traceback (most recent call last):
>> File "/home/sarunas/oe-repo/.repo/repo/main.py", line 506, in
>> _Main(sys.argv[1:])
>> File "/home/sarunas/oe-repo/.repo/repo/main.py", line 482, in _Main
>> result = repo._Run(argv) or 0
>> File "/home/sarunas/oe-repo/.repo/repo/main.py", line 161, in _Run
>> result = cmd.Execute(copts, cargs)
>> File "/home/sarunas/oe-repo/.repo/repo/subcmds/sync.py", line 681, in
>> Execute
>> project.Sync_LocalHalf(syncbuf)
>> File "/home/sarunas/oe-repo/.repo/repo/project.py", line 1196, in
>> Sync_LocalHalf
>> self._InitWorkTree()
>> File "/home/sarunas/oe-repo/.repo/repo/project.py", line 2296, in
>> _InitWorkTree
>> raise GitError("cannot initialize work tree")
>> error.GitError: cannot initialize work tree
>>
>> Sarunas
>>
>> From: Philip Balister
>> Sent: 20 February 2015 18:23
>> To: Sarunas Kalade; discuss-gnuradio@gnu.org
>> Subject: Re: [Discuss-gnuradio] GNU Radio on Zynq - trouble getting the
>> user_peripheral kernel module to work
>>
>> On 02/20/2015 09:47 AM, Sarunas Kalade wrote:
>>> Could you clarify a bit what you meant by 'check the needed version'? I've
>>> cloned some of the reps and did the checkouts with the hashes, but I always
>>> just end up in a 'detached HEAD' state.
>>>
>>> e.g.
>>> $ git
[Discuss-gnuradio] Project enquiry/interest
Hi, I am looking for some references on the following subject. Simultaneous transmissions, multiple users transmitting and receiving on the same channel frequency simultaneously, Multi user detection, etc. Is there any one here involved or aware of any research project or interested in the above subject. Any pointers will be highly appreciated. Thanks and Regards, Sajeev Manikkoth ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Newbie problem
Just so the mailing list doesn't feel out of the loop and the archives
have the solution:
We successfully tracked this issue to resolution here:
https://bugs.gentoo.org/show_bug.cgi?id=540658
and merged the fix into gnuradio here:
https://github.com/gnuradio/gnuradio/pull/387/
Thanks,
Zero_Chaos
On 02/18/15 16:13, Mike Markowski wrote:
> I was excited to successfully try an rtl-sdr GRC demo/tutorial and
> decided to start following the gnuradio tutorials to better learn the
> program. I quickly ran into trouble, so am sure I've done something
> stupid but can't figure out what! Running through tutorial
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GRC
>
> and reaching section 2.2.3, 'Generate' goes fine, but not 'Execute':
>
>
> Generating: "/home/mm/gnuradio/tutorial_two_1.py"
>
> Executing: "/home/mm/gnuradio/tutorial_two_1.py"
>
> Traceback (most recent call last):
> File "/home/mm/gnuradio/tutorial_two_1.py", line 13, in
> from gnuradio import qtgui
> File "/usr/lib/python2.7/site-packages/gnuradio/qtgui/__init__.py",
> line 34, in
> from qtgui_swig import *
> File "/usr/lib/python2.7/site-packages/gnuradio/qtgui/qtgui_swig.py",
> line 28, in
> _qtgui_swig = swig_import_helper()
> File "/usr/lib/python2.7/site-packages/gnuradio/qtgui/qtgui_swig.py",
> line 24, in swig_import_helper
> _mod = imp.load_module('_qtgui_swig', fp, pathname, description)
> ImportError: /usr/lib/libgnuradio-qtgui-3.7.6.1.so.0.0.0: undefined
> symbol: _ZN7QwtPlot11eventFilterEP7QObjectP6QEvent
>
Done (return code 1)
>
> The machine I'm on is a gentoo box with gnuradio compiled as follows
> (notice qt4 is specified):
>
> # emerge -pv gnuradio
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild R] net-wireless/gnuradio-3.7.6.1:0/3.7.6.1::gentoo
> USE="alsa analog audio ctrlport digital doc examples fcd filter grc jack
> oss qt4 sdl utils wavelet wxwidgets -atsc -channels -dtv -fec -log -noaa
> -pager -performance-counters -portaudio {-test} -trellis -uhd -vocoder
> -zeromq" PYTHON_TARGETS="python2_7" 0 KiB
>
> Total: 1 package (1 reinstall), Size of downloads: 0 KiB
>
> As I mentioned, all works well with RTL-SDR source, so I assume there is
> a QT problem of some sort?
>
> Thanks!
> Mike Markowski
>
> ___
> 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
