[Discuss-gnuradio] 1PPS Signal on USRP1
I'd like to take in a 1PPS signal on the USRP1, and, using the inband FPGA firmware, trigger a reset of the timestamp on the rising edge of every 1PPS pulse to get a rough idea of timing. From reading the documentation, I know that my max input voltage cannot be higher than 3.3V, so I've got that covered, but I can't seem to get the verilog code to work. I've modified the verilog code to add the following lines to the top level code: // Master timestamp counter reg [31:0] timestamp_counter; wire ts_io_reset; // -- NEW LINE assign ts_io_reset = io_rx_a[0]; // -- NEW LINE always @ (posedge clk64 or posedge ts_io_reset) begin // -- MODIFIED if (ts_io_reset) // -- NEW LINE timestamp_counter = 32'd0;// -- NEW LINE else if (tx_dsp_reset | rx_dsp_reset)//FIXME: does it make sense for rx/tx to reset independently? timestamp_counter = 32'd0; else timestamp_counter = timestamp_counter + 32'd1; end Nothing happens when I apply a test input to input 0 of the basic rx board (I am also polling the io from software with read_io, and I see the input switching). I am new to verilog, but for the life of me I can't figure out what I'm doing wrong here. I am using a basic_rx and a basic_tx on side 0 of a USRP1. Thanks, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FTW IEEE802.11a/g/p OFDM Frame Encoder
Guanbo ZHENG wrote on 22.02.11 00:36: The frequency band is correct. Just now, I re-install the repository from the CGRAN, and tried again using: sudo python ftw_ofdm_tx.py -f 2.462G -i 5 --regime=8 --payload=Here are some test messages from WiSeR -r 1 So the only question is, I have NOT updated my firmware. I will try that as well. We used the XCVR2450 only so far. In our experience, the most common reasons why it fails are: 1) channel on the RX side is not set to the one you use at TX 2) TX gain is too high or too low (depending on what kind of antennas and channel environment you are using) 3) old USRP2 firmware bug (try also with -s option and see if it changes the behavior) see documentation https://www.cgran.org/wiki/ftw80211ofdmtx 4) try also with -r 1 and -r 0 (the repetition method we used in the code is very dirty) By the way, what does the USRP2 generated packet look like in Wireshark at another laptop? Ideally, you would tick the capture using promiscuous mode and capture using monitor mode in the Wireshark GUI. Then you should see *every PHY-valid frame whatsoever* the card is able to decode on the channel that it is currently listening on. Make sure it does work like that. E.g. do you see beacons of the access-points nearby? The link-layer header-type should be 802.11 plus radiotap header and you should see the radiotap headers appended to every frame. If you have it available you can also use cmd-line tool called athstats to debug. You can get access to some atheros-specific counters with it, like how many frame-detected events per seconds are registered by the NIC. If all of this doesnt help there is this method to find out if the problem is in HW/GNUradio subsystem or on the encoder/decoder side: Try to generate frames using the Atheros NIC and record the signal (a block of baseband to disk) using the USRP2 with rx_cfile.py. Then put the Atheros in monitor mode again and transmit this very baseband block using transmit.py we included in the ftwofdm release (in src/matlab). You have to use the same USRP2 for recording/transmission, and you should not wait too long between RX/TX because of potential frequency offsets. If this record-playback does not work there is still something wrong in your current XCVR2450/USRP2/GNUradio subsystem. If it does work our encoder is the source of the problem :( cheers paul -- Dipl.-Ing. Paul Fuxjaeger FTW - Telecommunications Research Center Vienna http://www.ftw.at callto://:paul.fuxjaeger.at.work PSTN:+43-1-505283057 | 3GPP:+43-676-4787088 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FUNCube dongle
schrieb Alexandru Csete am 2011-02-19 17:46: On Sat, Feb 19, 2011 at 4:58 PM, Patrik Tast pat...@poes-weather.com wrote: Hi All, Has anybody tried the FUNCube USB dongle? http://www.funcubedongle.com/ How tricky would it be to add GNU Radio support for it? I'm not sure if it makes sense to create a GNU Radio block for this since the FCD is already an audio source and a block is not necessary for setting frequency and such. I guess it would still be useful for using it in GRC applications. I think this would be of great use. The FCB is based on the Softrock DDS design, which evolved to a family of different solutions, with the common factor of a stereo sound interface and a HID interface for control like frequency, source multiplexer switch and filter banks. AFAIK the HID commands are the same in most of these designs. Treating the system as a single interface much like a USRP would get users rid of extra programs and doing things every time over again. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser patrick dot strasser at student dot tugraz dot at Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how do I submit updates?
On Tue, Feb 22, 2011 at 12:18 AM, Achilleas Anastasopoulos anas...@umich.edu wrote: I had some time and finished updating gr-trellis with serial/parallel encoders and decoders. I also refactored all heavy-duty algorithms ()such as viterbi, siso, turbo, etc) and used templates for simplicity. I have these updates on branch turbo on my github site: https://github.com/anastas/gnuradio_turbo.git What is the process for submitting those for merging with master? thanks Achilleas You are about 90% of the way there. I'll take it from here, check over the code, and merge it in. Thanks! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how do I submit updates?
Tom, sounds great. BTW, the correct address is https://github.com/anastas/gnuradio_turbo Also, there was a related email I sent earlier regarding .gitignore and automatically generated files. I would really like to get your feedback on this because I am not sure I understand all the intricacies of git... I reattach the question below. thanks Achilleas = I am looking at the file Makefile.gen inside gr-trellis/src/lib which says that is automatically generated. This is indeed true since when i delete it and make gr-trellis it correctly generates it with all additions, etc that are implied by the file generate_trellis.py However if I delete it and try to do ./bootstrap (on the whole project) then automake reports an error automake: cannot open gr-trellis/src/lib/Makefile.gen: No such file or directory I came across this issue when i decided to put Makefile.gen in the .gitignore and not track it since it is machine generated... What is the explanation of this behavior? Shouldn't all automatically generated files not be tracked by git? thanks Achilleas == On 2/22/2011 10:54 AM, Tom Rondeau wrote: On Tue, Feb 22, 2011 at 12:18 AM, Achilleas Anastasopoulos anas...@umich.edu wrote: I had some time and finished updating gr-trellis with serial/parallel encoders and decoders. I also refactored all heavy-duty algorithms ()such as viterbi, siso, turbo, etc) and used templates for simplicity. I have these updates on branch turbo on my github site: https://github.com/anastas/gnuradio_turbo.git What is the process for submitting those for merging with master? thanks Achilleas You are about 90% of the way there. I'll take it from here, check over the code, and merge it in. Thanks! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The 'next' branch [MinGW]
Tom Rondeau wrote: I would ask all of you who can to start either using or at least testing out the 'next' branch now and provide us with feedback and bug reports. Two more issues with the 'next' branch: (1) It appears that the Boost 'system' and 'filesystem' modules are now required. This should be documented somewhere. (2) The Boost 'filesystem' module does not build on MinGW, because wstring is not supported in its libstdc++. I will look at the latest MinGW to see if this has changed. One possibility is to use an alternate C++ library (such as STLPort), but that sounds like a lot of work. An MSVC port is looking better all the time! -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with installation of howto
A quick note regarding the gr-howto-write-a-block. I reworked it a bit with what I think is a better solution. I just wanted everyone to be aware that previously, you would have done an import howto whereas now you will want from gnuradio import howto. I think this naming and keeping everything under the gnuradio space makes more sense. Thanks, Tom On Thu, Feb 17, 2011 at 5:22 PM, Tom Rondeau trondeau1...@gmail.com wrote: Sorry for the delayed response to this, but I just tested out the howto write a block code and had the same problem. I fixed the code, but according to Eric's logs from December when he made these changes, I'm not sure what's happening is what is supposed to be happening after they did some work on the swig system. Bottom line, this might not be the right answer, but it makes it work and it's easy to reverse when we find the right answer. Also, this should have only been broken in the 'next' branch. Can you confirm that this is where you were seeing the problem, or was there a problem with the 'master' branch as well? Thanks, Tom On Sat, Feb 12, 2011 at 8:38 PM, Mike Cornelius d...@drelectro.com wrote: Hi Achilleas, I've been doing some work on the qtgui module. When I started this work I was using a somewhat hackish approach to building it 'out of tree', this weekend I've been working on cleaning this up so that the build is based on the process used in how-to-write-a-block from 'next'. In the process I've come across the issue you describe below, To fix it I :- - added a suitable swig/__init__.py - modified swig/makefile.am to include the new __init__.py - modified the import path in python/__init__.py - modified the import path python/qa_howto.py I've attached a copy of my mods to this message if you'd like to give it a try. I'm not sure how 'correct' my solution is though. BR, Mike VK2XMC -Original Message- From: discuss-gnuradio-bounces+dr=drelectro@gnu.org [mailto:discuss-gnuradio-bounces+dr=drelectro@gnu.org] On Behalf Of Achilleas Anastasopoulos Sent: Saturday, 12 February 2011 3:55 AM To: gnuradio mailing list Subject: [Discuss-gnuradio] problem with installation of howto As it turns out after building howto make install installs a directory howto in .../site-packages containing the files: -rw-r--r-- 1 anastas nobody 1691 Feb 11 11:53 __init__.py -rw-rw-r-- 1 anastas nobody 556 Feb 11 11:53 __init__.pyc -rw-rw-r-- 1 anastas nobody 556 Feb 11 11:53 __init__.pyo and ANOTHER directory howto_swig in .../site-packages/gnuradio containing the files: -rwxr-xr-x 1 anastas nobody 1327 Feb 11 11:52 _howto_swig.la -rw-r--r-- 1 anastas nobody 12267 Feb 11 11:53 howto_swig.py -rw-rw-r-- 1 anastas nobody 22958 Feb 11 11:53 howto_swig.pyc -rw-rw-r-- 1 anastas nobody 22958 Feb 11 11:53 howto_swig.pyo -rwxr-xr-x 1 anastas nobody 411339 Feb 11 11:52 _howto_swig.so if i copy the files of the latter to the former then everything works, ie, python can import howto, otherwise, it complains! Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem with the high correlation in noise while receiving in USRP
Hi, I am trying to implement Eigenvalue based sensing method using gnuradio and USRP. and while doing the testing, when we try to receive the noise and do the detection we still get the output as 1 (i.e. the ratio of eigevalues is higher than threshold). This may be due to the high correlation in noise. I tried with removing the antenna and also tried increasing the gain but still the problem is there. I can someone help me with this problem. Thanking you, Abhijeet ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: FUNCube dongle
On 22/02/2011 9:26 AM, Patrick Strasser wrote: I think this would be of great use. The FCB is based on the Softrock DDS design, which evolved to a family of different solutions, with the common factor of a stereo sound interface and a HID interface for control like frequency, source multiplexer switch and filter banks. AFAIK the HID commands are the same in most of these designs. Treating the system as a single interface much like a USRP would get users rid of extra programs and doing things every time over again. Patrick I agree--having a slick UHD/USRP-like interface would be very cool, so that you can control it entirely from within a GR flow-graph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem while trying to run GRC
Hello, I recently decided to install the latest version using the git. Since I had the 3.2.2 version, I removed it all and then began the process... ./bootstrap, ./configure (removing the unnecessary package etc) etc etc... Note that the grc package was installed. The problem is, after I installed everything with no error message, when I try to run the grc, it simply seems that it wasn't installed! *mula@mula:~/Downloads/gnuradio$ grc* *The program 'grc' can be found in the following packages:* * * gnuradio-companion* * * grc* *Try: sudo apt-get install selected package* Even after installing every necessary packages etc and not having any error message, I'm still afraid I might have commited a mistake (I'm not a linux expert as well). A friend has also installed using the same steps and got it working. Thanks! Regards, Bernardo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem while trying to run GRC
2011/2/22 Bernardo Guadagnin Gonçalves swooper...@gmail.com: Hello, I recently decided to install the latest version using the git. Since I had the 3.2.2 version, I removed it all and then began the process... ./bootstrap, ./configure (removing the unnecessary package etc) etc etc... Note that the grc package was installed. The problem is, after I installed everything with no error message, when I try to run the grc, it simply seems that it wasn't installed! mula@mula:~/Downloads/gnuradio$ grc The program 'grc' can be found in the following packages: * gnuradio-companion * grc Try: sudo apt-get install selected package Even after installing every necessary packages etc and not having any error message, I'm still afraid I might have commited a mistake (I'm not a linux expert as well). A friend has also installed using the same steps and got it working. Thanks! Regards, Bernardo GRC was renamed to gnuradio-companion to avoid a name conflict with another package. Try that instead. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem while trying to run GRC
Thanks Tom, now it works! I didn't know that... I'm sorry! Regards, Bernardo 2011/2/22 Tom Rondeau trondeau1...@gmail.com 2011/2/22 Bernardo Guadagnin Gonçalves swooper...@gmail.com: Hello, I recently decided to install the latest version using the git. Since I had the 3.2.2 version, I removed it all and then began the process... ./bootstrap, ./configure (removing the unnecessary package etc) etc etc... Note that the grc package was installed. The problem is, after I installed everything with no error message, when I try to run the grc, it simply seems that it wasn't installed! mula@mula:~/Downloads/gnuradio$ grc The program 'grc' can be found in the following packages: * gnuradio-companion * grc Try: sudo apt-get install selected package Even after installing every necessary packages etc and not having any error message, I'm still afraid I might have commited a mistake (I'm not a linux expert as well). A friend has also installed using the same steps and got it working. Thanks! Regards, Bernardo GRC was renamed to gnuradio-companion to avoid a name conflict with another package. Try that instead. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM implemrentation
Hi all, I am trying to implement OFDM on USRP N210 using Gnu Radio. I haven't got the entire hardware yet,so I was wondering whether it was possible to edit the OFDM example provided , in order to bypass the hardware requirements and just simulate the code and view its functioning. I am slightly new to python and wanted some help on changing the code , so that it can be simulated . Please do let me know, how to go about it. I ll be much obliged. Also I wanted to know, if the OFDM module provided in the Gnu Radio Companion is complete and whether it can be implemented. Thanking you for your help. Kind Regards Varun K Masters Student Georgia Institute of Technology ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: FUNCube dongle
On Tue, Feb 22, 2011 at 9:57 PM, Marcus D. Leech mle...@ripnet.com wrote: On 22/02/2011 9:26 AM, Patrick Strasser wrote: I think this would be of great use. The FCB is based on the Softrock DDS design, which evolved to a family of different solutions, with the common factor of a stereo sound interface and a HID interface for control like frequency, source multiplexer switch and filter banks. AFAIK the HID commands are the same in most of these designs. Treating the system as a single interface much like a USRP would get users rid of extra programs and doing things every time over again. Patrick I agree--having a slick UHD/USRP-like interface would be very cool, so that you can control it entirely from within a GR flow-graph. Well, implementing it as UHD device seems a bit overkill from a programming point of view because one would have to implement the audio source, which is readily available in GNU Radio. So a GNU Radio source just like the old pre-UHD USRP drivers seems to be most feasible. I don't know much about the Softrock series, but I doubt they have much in common with the FCD. Maybe the USB idea and the protocol structure, which for the FCD is really trivial and simple streams of 1-4 bytes per command. Most of the commands and parameters for the FCD map directly to the tuner chip, which I assume is not present in the Softrocks - see attached screenshot of the windows controller. Alex attachment: fcd_win.png___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: FUNCube dongle
On Tue, Feb 22, 2011 at 15:36, Marcus D. Leech mle...@ripnet.com wrote: On 02/22/2011 06:24 PM, Alexandru Csete wrote: Well, implementing it as UHD device seems a bit overkill from a programming point of view because one would have to implement the audio source, which is readily available in GNU Radio. So a GNU Radio source just like the old pre-UHD USRP drivers seems to be most feasible. If implemented as a C++ hierarchical block, then you can encapsulate an audio source and the float to complex transformation blocks internally. You'd hold an instance of the libfcd library and expose an external set of accessors that resolve internally into the calls to the libfcd instance. This is not that much coding, and makes something that works just like a native GNU Radio block. It would be able to be used in pure C++ GNU Radio apps, in Python GNU Radio apps, or instantiated and controlled entirely from within a GRC flowgraph. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] book/video (MIT courseware, whatever) recommendations?
Is there one or two books that give a pretty comprehensive, yet low base communications/DSP knowledge requirement that would be a guided walkthrough of waves and fields, various forms of modulation, carriers, filters, sidebands, etc? I'm really looking for something that's either not a textbook, or not written like one- most textbooks are very dry and hard to understand without someone guiding the experience and asking the right questions. I realize the material is fairly dry, so I understand that it's not going to be a crichton novel, but the less crazy math and algorithm intensive it is, the better. Long story short, what's a good way to get a more solid grasp of how driving a DAC can create electromagnetic waves, and what can one do with those waves. I'd really really like to walk away understanding how complex numbers turn into constellations are really formed as an electromagnetic wave, etc, and the real guts of some basic things like FM and DSSS. -Brett ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: FUNCube dongle
On 02/22/2011 07:00 PM, Johnathan Corgan wrote: If implemented as a C++ hierarchical block, then you can encapsulate an audio source and the float to complex transformation blocks internally. You'd hold an instance of the libfcd library and expose an external set of accessors that resolve internally into the calls to the libfcd instance. This is not that much coding, and makes something that works just like a native GNU Radio block. It would be able to be used in pure C++ GNU Radio apps, in Python GNU Radio apps, or instantiated and controlled entirely from within a GRC flowgraph. Johnathan So, you have it implemented then, Jonathan? :-) :-) -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: FUNCube dongle
On Tue, Feb 22, 2011 at 16:09, Marcus D. Leech mle...@ripnet.com wrote: On 02/22/2011 07:00 PM, Johnathan Corgan wrote: If implemented as a C++ hierarchical block, then you can encapsulate an audio source and the float to complex transformation blocks internally. You'd hold an instance of the libfcd library and expose an external set of accessors that resolve internally into the calls to the libfcd instance. This is not that much coding, and makes something that works just like a native GNU Radio block. It would be able to be used in pure C++ GNU Radio apps, in Python GNU Radio apps, or instantiated and controlled entirely from within a GRC flowgraph. Johnathan So, you have it implemented then, Jonathan? :-) :-) Send me the hardware :-) Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: FUNCube dongle
On Wed, Feb 23, 2011 at 1:00 AM, Johnathan Corgan jcor...@corganenterprises.com wrote: On Tue, Feb 22, 2011 at 15:36, Marcus D. Leech mle...@ripnet.com wrote: On 02/22/2011 06:24 PM, Alexandru Csete wrote: Well, implementing it as UHD device seems a bit overkill from a programming point of view because one would have to implement the audio source, which is readily available in GNU Radio. So a GNU Radio source just like the old pre-UHD USRP drivers seems to be most feasible. If implemented as a C++ hierarchical block, then you can encapsulate an audio source and the float to complex transformation blocks internally. You'd hold an instance of the libfcd library and expose an external set of accessors that resolve internally into the calls to the libfcd instance. This is not that much coding, and makes something that works just like a native GNU Radio block. It would be able to be used in pure C++ GNU Radio apps, in Python GNU Radio apps, or instantiated and controlled entirely from within a GRC flowgraph. Yes, I agree with this. With the overkill I meant a pure UHD device that does not use existing GNU Radio blocks. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] book/video (MIT courseware, whatever) recommendations?
On 02/22/2011 07:04 PM, Brett L. Trotter wrote: Long story short, what's a good way to get a more solid grasp of how driving a DAC can create electromagnetic waves, and what can one do with those waves. I'd really really like to walk away understanding how complex numbers turn into constellations are really formed as an electromagnetic wave, etc, and the real guts of some basic things like FM and DSSS. -Brett The first few chapters of the ARRL handbook actually make a fairly good introduction to radio in general. Once you realize that an electronic circuit oscillating at some frequency can launch an EM wave into a suitably matched antenna like thing, it's not hard to see how you can make that oscillation happen digitally, etc. DSP/SDR uses digital representations of the underlying mathematics of creating signals. In the analog world, we use analog components to *approximate* (to varying degrees of fidelity) the mathematical transformations of radio communications. Consider, very briefly, amplitude modulation: You have a carrier frequency, at some Mhz, that is modulated in *amplitude* by a much-lower-frequency audio wave. In the analog world, you use a mixer to do this (with suitable futzing-about that is nearly-always necessary in the analog world). But once you realize that amplitude modulation is nothing more than *multiplication* of two waveforms (or, the digital representation of those waveforms), then AM becomes quite trivial to generate. Here's a quick experiment you can try at home. Assuming you have GnuPlot: gnuplot plot (sin(x*100)*sin(x*100)) You just plotted what amounts to a simple amplitude modulated signal, where the audio frequency is a fraction of the carrier frequency. It's not that realistic, but it's illustrative. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: FUNCube dongle
On 02/22/2011 07:11 PM, Johnathan Corgan wrote: Send me the hardware :-) Johnathan I don't have one, but you may have a good case for getting a freebie to do the Gnu Radio support for it. Having been unemployed for the last 7 months, and just starting a new job, anything more expensive than Ramen noodles is a luxury item for me :-) -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GR Conference Dates
On Tue, Feb 22, 2011 at 6:53 PM, Eric Cottrell wb1...@runbox.com wrote: Hello, Thanks for posting the information. I am planning on going and it looks like I can take the train. In early March I am going to the Winter SWL Fest up in Plymouth Meeting, PA. 73 Eric Great, Eric! See you there. And, yes, getting into and out of Philadelphia by train is very easy (up and down the East coast, at least). I use it all the time to get around from here to NY, DC, etc. Tom - Start Original Message - Sent: Mon, 21 Feb 2011 23:13:32 -0500 From: Tom Rondeau trondeau1...@gmail.com To: GNURadio Discussion List discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] GR Conference Dates The GNU Radio conference has been scheduled for September 14 - 16, 2011. We will start after lunch at 1 PM on Wednesday and end 5 PM on Friday. I am currently planning on having some space reserved on Saturday for an informal hack session. The conference will be held in Levine Hall of the University of Pennsylvania, Philadelphia, PA. There will be plenty more information to come about location, hotels, transportation, etc., but you can use this to start planning. After looking at the feedback from everyone, this time seemed like not only the best time of the week but also the best dates. As per a previous suggestion (from Jens, if I recall), this occurs right after PIMRC in Toronto, so hopefully anyone in this general area of the world for that could piggyback onto that trip. I recognize that this won't work for everyone, but hopefully with this lead time, many of you can plan your schedules accordingly. Please let me know if you are planning and able to attend. The better idea that I have for the number of people coming, the smoother a process I can make this. I know that cost is going to be a factor for many of you, and I'm afraid that I can't speculate as to what it will be costing at this point. My intention is that the conference is designed to not make any money, and so cost for attending will be based on the cost of putting it together. For that, the more people who I know can make it, the better I can estimate the registration fee. I expect/hope that it will not be too much (expect travel and hotel costs to outweigh the fee). Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio - End Original Message - ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: FUNCube dongle
On Tue, Feb 22, 2011 at 16:28, Marcus D. Leech mle...@ripnet.com wrote: On 02/22/2011 07:11 PM, Johnathan Corgan wrote: Send me the hardware :-) Johnathan I don't have one, but you may have a good case for getting a freebie to do the Gnu Radio support for it. Having been unemployed for the last 7 months, and just starting a new job, anything more expensive than Ramen noodles is a luxury item for me :-) Congratulations, by the way. Hope your new situation still affords you time to work on the odd GNU Radio block now and then. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: FUNCube dongle
On 02/22/2011 07:45 PM, Johnathan Corgan wrote: Congratulations, by the way. Hope your new situation still affords you time to work on the odd GNU Radio block now and then. Johnathan New job seems a very 9-to-5 kinda place, unlike the previous engagement, which was 14 hours/day, 6 or 7 days a week :-( -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] book/video (MIT courseware, whatever) recommendations?
It would be useful to know the background of whoever this would be for. EE? Computer Science? Familiarity with trigonometric functions and some basic calculus would be helpful for getting up to speed. I would advise against the MIT courseware link... I found it overly theoretical, and pretty much the exact thing you don't want (crazy math and algorithms). Personally, I found the tutorials at this link from SuggestedReading helpful, although I had studied some of the basics in undergrad courses 10 years ago, so I had some background: http://www.complextoreal.com/tutorial.htm They're not the most polished write-ups (some typos, formatting errors), but I found it easy to follow and the diagrams are very helpful, and may meet your criteria of not being too textbook-ish. Kunal On Tue, Feb 22, 2011 at 7:04 PM, Brett L. Trotter br...@webtrotter.comwrote: Is there one or two books that give a pretty comprehensive, yet low base communications/DSP knowledge requirement that would be a guided walkthrough of waves and fields, various forms of modulation, carriers, filters, sidebands, etc? I'm really looking for something that's either not a textbook, or not written like one- most textbooks are very dry and hard to understand without someone guiding the experience and asking the right questions. I realize the material is fairly dry, so I understand that it's not going to be a crichton novel, but the less crazy math and algorithm intensive it is, the better. Long story short, what's a good way to get a more solid grasp of how driving a DAC can create electromagnetic waves, and what can one do with those waves. I'd really really like to walk away understanding how complex numbers turn into constellations are really formed as an electromagnetic wave, etc, and the real guts of some basic things like FM and DSSS. -Brett ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to stop the top_block and restart signal transmission
Hi Tom, Sorry about the question. I tried the method lock() and unlock() to pause the flow graph that I built, but still shows the continuous signal wave on the oscilloscope. I cannot see the pause between the signal waves. The code related to the top_block scheduling is as followed. Could you help me see what would be the problem which lock/unlock cannot pause the flow graph for 5 milliseconds? I'm trying to transmit 13-bit through the USRP board, after this transmission pause the system for 5 milliseconds then repeat this process again. If continuously transmitting the Barker code, this system works fine. I'm wondering why lock/unlock method cannot work in this case? What's the problem here? I really appreciate your help! try: top_block.start() statr_flag payload_13barker ='\x01\x01\x01\x01\x01\x00\x00\x01\x01\x00\x01\00\x01' while(start_flag == 1): msg_13bit =gr.message_from_string(payload_13barker) top_block._ls.msgq.insert_tail(msg_13bit) eof_msg = gr.message(1) top_block._ls.msgq.insert_tail(eof_msg) top_block.lock() time.sleep(0.005) top_block.unlock() top_block.wait() The top_block that I built: class tx_bpsk_block(gr.top_block): def __init__(self, subdev_spec, freq, verbose, chip_rate,amplitude): gr.top_block.__init__(self, tx_mpsk) self._freq = freq self._verbose = verbose self._amplitude = amplitude self._u = usrp_sink_s(0,subdev_spec, chip_rate, self._freq, self._verbose) self.in_data = gr.message_source(gr.sizeof_char, 3329) self.msgq = self.in_data.msgq() self._constellation = [-1, 1] self._mapper = gr.chunks_to_symbols_bf(self._constellation) self._gain = gr.multiply_const_ff(self._amplitude) self.f2s = gr.float_to_short() self.connect(self.in_data,self._mapper self._gain, self.f2s,self._u) Thank you so much for your help! I really appreciate! Thanks, Yan On 02/21/11, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Feb 21, 2011 at 9:50 PM, Yan Nie yn...@uwo.ca wrote: Dear all, I'm trying to stop top_block implementing the signal transmission for 5 milliseconds and then restart the signal transmission at the transmitter side, by using the tb.stop() then time.sleep(0.005) to suspend the system for 5 milliseconds then tb.start() to start the signal transmission again. This approach gives an RuntimeError: top_block::start: top block already running or wait() not called after previous stop(). Could you please help me to find what the problem is? I also tried lock() and unlock() which cannot stop the signal transmission implemented in top_block Yan, You want to use the lock() and unlock(). They should pause and unpause the graph, so please elaborate when you say that they don't stop the signal transmission. The start and stop methods will definitely not work here. Tom attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] daughterboard PCB/PADS files?
I see that http://code.ettus.com/redmine/ettus/projects/public/documents has the PDFs, but are the PCB/PADS files still around for any of these boards? If the answer is no, then is open source hardware becoming open, but we don't want to make it too easy since we make money on these. If yes, then kindly skip over that last part :) -Brett ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to stop the top_block and restart signal transmission
Sorry about the last uncompleted email. I tried the method lock() and unlock() to completely pause the flow graph without transmitting any signal, but the continuous carrier wave still showed on the oscilloscope. I'm trying to transmit 13-bit Barker code carried by a 4MHz sinusoid wave. After this 13-bit code transmission, the whole system need to be suspended for 5 milliseconds without transmitting any signal, even though the carrier wave. I'm wondering how to completely pause the whole flow graph, not transmitting any signal including the carrier wave? What's the problem of the scheduler that I wrote. I really appreciate any help on solution to this problem! really appreciate! The code related to the scheduling part is: top_block = tx_bpsk_block(options.tx_subdev_spec,options.freq,options.verbose,options.chip_rate,options.amplitude) try: top_block.start() start_flag = 1 payload_13barker = '\x01\x01\x01\x01\x01\x00\x00\x01\x01\x00\x01\x00\x01' while(start_flag == 1) msg_13bit = gr.message_from_string(payload_13barker) top_block.msgq.insert_tail(msg_13bit) eof_msg = gr.message(1) top_block.msgq.insert_tail(eof_msg) top_block.lock() time.sleep(0.005) top_block.unlock() top_block.wait() except KeyboardInterrupt: pass if __name__ == __main__: main() The top_block is created as: class tx_bpsk_block(gr.top_block): def __init__(slef, subdev_spec, freq, verbose, chip_rate, amplitude): gr.top_block.__init__(self,tx_mpsk) self._freq = freq self._verbose = verbose self._amplitude = amplitude self._u = usrp_sink_s(0,subdev_spec,chip_rate, self._freq, self._verbose) self.in_data = gr.message_source(gr.sizeof_char,14) self.msgq = self.in_data.msgq() self._constellation = [-1,1] self._mapper = gr.chunks_to_symbols_bf(self._constellation) self._gain = gr.multiply_const_ff(self._amplitude) self.f2s = gr.float_to_short() self.connect(self.in_data,self._mapper,self._gain,self.f2s,self._u) If continuously transmitting Barker code without any pause, this flow graph works fine. When using lock/unlock to pause this system, Barker code won't feed into the flow graph,which means the carrier signal won't be modulated, but the transmitter still send the carrier sinusoid wave which can be observed by oscilloscope. I'm wondering how to completely pause the whole flow graph, not transmitting any signal including the carrier wave? What's the problem of the scheduler that I wrote. I really appreciate any help on solution to this problem! really appreciate! Thanks, Yan On 02/22/11, Yan Nie yn...@uwo.ca wrote: Hi Tom, Sorry about the question. I tried the method lock() and unlock() to pause the flow graph that I built, but I still can see the continuous signal wave on the oscilloscope. Could you please help with On 02/21/11, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, Feb 21, 2011 at 9:50 PM, Yan Nie yn...@uwo.ca wrote: Dear all, I'm trying to stop top_block implementing the signal transmission for 5 milliseconds and then restart the signal transmission at the transmitter side, by using the tb.stop() then time.sleep(0.005) to suspend the system for 5 milliseconds then tb.start() to start the signal transmission again. This approach gives an RuntimeError: top_block::start: top block already running or wait() not called after previous stop(). Could you please help me to find what the problem is? I also tried lock() and unlock() which cannot stop the signal transmission implemented in top_block Yan, You want to use the lock() and unlock(). They should pause and unpause the graph, so please elaborate when you say that they don't stop the signal transmission. The start and stop methods will definitely not work here. Tom attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
