Re: [Discuss-gnuradio] ALSA audio source not working---why?
Eric--- Buggy ALSA driver. Perfect. GNURadio side, or ALSA side? What kind of a audio card are you using? I'm running an SBLive! Value 24, which uses the emu10k1 chipset. All else seems to be working fine under ALSA. As per another suggestion, I switched over to audio_oss, and that seems to be working fine. Thanks, Henry C. Gernhardt, III ke4pib ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 30, Issue 24
Can anyone provide me the 'building blocks' of a basic and or intermidiate digital radio for general receptionLooking at the Component parts the physical parts(a/d other components) the software for demodulation stages preceding and past the demod stage nescesary for building it from scratch using widely available parts from companies like RS componetns and the likes. On 5/25/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Send Discuss-gnuradio mailing list submissions to discuss-gnuradio@gnu.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.gnu.org/mailman/listinfo/discuss-gnuradio or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Discuss-gnuradio digest... Today's Topics: 1. newbie cant get wxPy to work (jmdaniel) 2. USRP DDC usage (Philip Balister) 3. Error in building GNU radio core 2.5 (Ahmad Sheikh) 4. DBSRX status (Matt Ettus) 5. ALSA audio source not working---why? (Henry Gernhardt III) 6. DSP based SDR (Darrell Harmon) 7. Re: Error in building GNU radio core 2.5 (LRK) 8. Re: DBSRX status (Lamar Owen) 9. Re: USRP DDC usage (Eric Blossom) -- Message: 1 Date: Wed, 25 May 2005 13:19:42 -0400 From: jmdaniel [EMAIL PROTECTED] Subject: [Discuss-gnuradio] newbie cant get wxPy to work To: Discuss-gnuradio@gnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hello, I'm fairly new to gnuradio/unix/linux and have seemed to gotten through much of the installation of gnuradio (thanks to this discussion) except for wxPy which is giving me trouble. Heres what happens when I try to import wx. % python Python 2.4 (#1, Apr 19 2005, 15:47:38) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 Type help, copyright, credits or license for more information. import Numeric import wx Traceback (most recent call last): File stdin, line 1, in ? File /usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/__init__.py, line 42, in ? from wx._core import * File /usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py, line 4, in ? import _core_ ImportError: /usr/lib/python2.4/site-packages/wx/_core_.so: undefined symbol: PyUnicodeUCS4_AsEncodedString I have looked over the No module named wx thread and seem to have a different problem. I'm pretty certain that there is only one installation of wx on my machine but I've been working on this off and on so that may be the source of my wx headache. Has anyone run into this error before that knows a quick fix? if not how can I check to see if there are multiple installations on my machine? Let me know if more information is needed. Thanks, John Daniel Virginia Tech -- Message: 2 Date: Wed, 25 May 2005 14:54:05 -0400 From: Philip Balister [EMAIL PROTECTED] Subject: [Discuss-gnuradio] USRP DDC usage To: discuss-gnuradio@gnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain I'm working on making a SCA component for the usrp based on the usrp standard interface. I've got a few questions on how to use the DDC's and the input mux. If I set the mux word to 0x33221100 (and the number of channels to four) I believe I will have 4 channels of complex data from each A2D. If I set the mux word to 0xf3f2f1f0 I will have four channels of real data, interleaved with the zeros from the Q channel. Is this correct? Thanks, Philip -- Message: 3 Date: Thu, 26 May 2005 04:08:01 +0500 From: Ahmad Sheikh [EMAIL PROTECTED] Subject: [Discuss-gnuradio] Error in building GNU radio core 2.5 To: discuss-gnuradio@gnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 I get the following error when I enter ./bootstrap in building gnu-radio-core-2.5 on Redhat Linux v3. /usr/local/share/aclocal/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal /usr/local/share/aclocal/cppunit.m4:4: warning: underquoted definition of AM_PATH_CPPUNIT and this error when I enter make. In file included from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/istream:771, from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/sstream:45, from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/complex:51, from ./gr_complex.h:25, from ./gr_types.h:30, from ./gr_runtime.h:26, from
[Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 30, Issue 24
Can anyone provide me the 'building blocks' of a basic and or intermidiate digital radio for general receptionLooking at the Component parts the physical parts(a/d other components) the software for demodulation stages preceding and past the demod stage nescesary for building it from scratch using widely available parts from companies like RS components and the likes. On 5/25/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Send Discuss-gnuradio mailing list submissions to discuss-gnuradio@gnu.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.gnu.org/mailman/listinfo/discuss-gnuradio or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Discuss-gnuradio digest... Today's Topics: 1. newbie cant get wxPy to work (jmdaniel) 2. USRP DDC usage (Philip Balister) 3. Error in building GNU radio core 2.5 (Ahmad Sheikh) 4. DBSRX status (Matt Ettus) 5. ALSA audio source not working---why? (Henry Gernhardt III) 6. DSP based SDR (Darrell Harmon) 7. Re: Error in building GNU radio core 2.5 (LRK) 8. Re: DBSRX status (Lamar Owen) 9. Re: USRP DDC usage (Eric Blossom) -- Message: 1 Date: Wed, 25 May 2005 13:19:42 -0400 From: jmdaniel [EMAIL PROTECTED] Subject: [Discuss-gnuradio] newbie cant get wxPy to work To: Discuss-gnuradio@gnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 Hello, I'm fairly new to gnuradio/unix/linux and have seemed to gotten through much of the installation of gnuradio (thanks to this discussion) except for wxPy which is giving me trouble. Heres what happens when I try to import wx. % python Python 2.4 (#1, Apr 19 2005, 15:47:38) [GCC 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)] on linux2 Type help, copyright, credits or license for more information. import Numeric import wx Traceback (most recent call last): File stdin, line 1, in ? File /usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/__init__.py, line 42, in ? from wx._core import * File /usr/lib/python2.4/site-packages/wx-2.6-gtk2-ansi/wx/_core.py, line 4, in ? import _core_ ImportError: /usr/lib/python2.4/site-packages/wx/_core_.so: undefined symbol: PyUnicodeUCS4_AsEncodedString I have looked over the No module named wx thread and seem to have a different problem. I'm pretty certain that there is only one installation of wx on my machine but I've been working on this off and on so that may be the source of my wx headache. Has anyone run into this error before that knows a quick fix? if not how can I check to see if there are multiple installations on my machine? Let me know if more information is needed. Thanks, John Daniel Virginia Tech -- Message: 2 Date: Wed, 25 May 2005 14:54:05 -0400 From: Philip Balister [EMAIL PROTECTED] Subject: [Discuss-gnuradio] USRP DDC usage To: discuss-gnuradio@gnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain I'm working on making a SCA component for the usrp based on the usrp standard interface. I've got a few questions on how to use the DDC's and the input mux. If I set the mux word to 0x33221100 (and the number of channels to four) I believe I will have 4 channels of complex data from each A2D. If I set the mux word to 0xf3f2f1f0 I will have four channels of real data, interleaved with the zeros from the Q channel. Is this correct? Thanks, Philip -- Message: 3 Date: Thu, 26 May 2005 04:08:01 +0500 From: Ahmad Sheikh [EMAIL PROTECTED] Subject: [Discuss-gnuradio] Error in building GNU radio core 2.5 To: discuss-gnuradio@gnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 I get the following error when I enter ./bootstrap in building gnu-radio-core-2.5 on Redhat Linux v3. /usr/local/share/aclocal/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal /usr/local/share/aclocal/cppunit.m4:4: warning: underquoted definition of AM_PATH_CPPUNIT and this error when I enter make. In file included from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/istream:771, from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/sstream:45, from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/complex:51, from ./gr_complex.h:25, from ./gr_types.h:30, from ./gr_runtime.h:26, from
Re: [Discuss-gnuradio] DSP based SDR
Have you considered putting a USRP-compatible daughterboard connector on your DSP-based board? That would let you mostly ignore radio front ends. You and anyone else could piggyback on the work done to make each radio front end receiver board made for the USRP. You'd just use the cheap connector/transformer board for direct connection to external radios. It seems like building the radio front ends is a significant pain (they're coming out more slowly than expected), so you can save yourself that pain. Matt and Eric claimed during the USRP development that it wasn't possible to build a USB-powered board that didn't (1) draw too much power, and (2) couple too much noise into the sensitive analog circuitry. Of course, their board has four hungry chips on it; yours will have only two. You might try building your first prototype boards with jumpers or solder bridges that will let you test with USB power and with wallwart power -- and see if the radio performs differently. In the USRP I had proposed that the clocks to the ADC's be programmable, so the whole processing chain could run more slowly than the maximum rate. Matt was unable to find clock generator parts that meet his jitter specs (which are critical for oversampling). That's why the USRP runs the ADC at top speed and downconverts using math in the FPGA. If your Blackfin can't accept data at top speed, you'll have to improve on the USRP's clocking. You prefer USB2 over firewire or gigabit Ethernet? It would be nice to have a radio spectrum interface that didn't have USB2's bandwidth as its bottleneck. Gig E is always full duplex (no collisions between transmit and receive), and offers higher bandwidth. GigE switches are now in the $100 range and dropping fast (or you can plug the board directly into a computer's GigE port, if it isn't on the Internet at the same time, e.g. for mobile laptop use). John Gilmore ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] An interesting application for my new USRP... some input requested
None of this work needs to be done realtime. It can be done after the fact on recorded digital signals. May I suggest that you take that Reflock II tamed 10 Mhz oscillator and record it in parallel. Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP DDC usage
I have a question/observation on this issue: Since the DDC multiplication is complex and since the internal DDC oscilator is noncoherent, I do not see a difference between the MUX settings: 0x33221100 and 0xf3f2f1f0. Similarly, with the setting 0x3210 you will never be able to separate the two channels coming from ADC0/ADC1 and ADC2/ADC3. Is this right? Thanks Achilleas On Wed, May 25, 2005 at 02:54:05PM -0400, Philip Balister wrote: I'm working on making a SCA component for the usrp based on the usrp standard interface. I've got a few questions on how to use the DDC's and the input mux. If I set the mux word to 0x33221100 (and the number of channels to four) I believe I will have 4 channels of complex data from each A2D. FYI, the current fpga image only support two DDCs. You always get complex data out of the DDCs. The question is what are you putting in? If you want two DDCs with a different pair of A/Ds to each one the mux should == 0x3210 If I set the mux word to 0xf3f2f1f0 I will have four channels of real data, interleaved with the zeros from the Q channel. Yes. This will feed a zero to the Q input of each DDC and will feed ADC's 3, 2, 1, 0 to the I inputs. Note that there are only two channels available in the current FPGA build. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] An interesting application for my new USRP... some input requested
Let me add that if done off line and the 10 Mhz Reflock II based oscillator is used, then you can use a forward backward algorithm tracking the oscillator to resample the other channels to remove all systematic biases/errors up to the accuracy and the lock of the 10 Mhz oscillator. Not much can be done with the phase noise of course. If you want, you can multiply that 10 Mhz to 60Mhz and use it as the external clocking (rather than the 64 Mhz oscillator now on board). The Reflock II could also be used to lock a 64 Mhz oscillator as well, given an external reference such as GPS, and then all sample rates will be as needed. This implies having a VCXO that runs at 64 Mhz. The phase noise would be low since you are taming a crystal oscillator. Thus the accuracy can be improved in either of these ways. A TC-VCXO would be ideal. Barring that, put a thermal tab on it. DB6NT http://*www.kuhne-electronic.de* makes a slip over microprocessor controlled dress for keeping a crystal at nearly 40C. It is called the QH40A. Go here: http://www.kuhne-electronic.de/english/special.htm and click on crystal heater. Bob n4hy wrote: None of this work needs to be done realtime. It can be done after the fact on recorded digital signals. May I suggest that you take that Reflock II tamed 10 Mhz oscillator and record it in parallel. Bob ___ 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] An interesting application for my new USRP... some input requested
There are no other clock sources of error in your analysis system since the clocking is all driven by the 64 Mhz stabilized oscillator. No sound card oscillators are involved. This will be a straight digital transfer to the analysis program(s) and all clocks from one reference. I would do this as follows: Insert a known tamed oscillator in LSB and have the measured tone in USB and use arithmetic to back out the offset (phase and frequency) using the known source. Since this is a frequency measuring test, a little phase modulation makes little difference. Using the USRP or SDR-1000, etc. the known reference is the key and you are doing that. In the SDR-1000 case, using the tamed and controlled 8640B, put it in LSB, the signal of interesting in the USB (say) and use the console to record an IQ signal. The analysis and the computation is then easy. The digitally recorded signal is resampled based on the reference signal. Then the frequency of the unknown signal is computed using a large FFT and the known new sample rate. You could do it this way with a known external reference and a combiner and a digital recording program. You record the known reference and the unknown signal in the same passband. Again, I would use my tamed 8640B as the reference. Then you can do it with analog receiver and a digital recorder. Bob John Ackermann N8UR wrote: Hi Bob -- Yup, using a 64MHz Reflock II is exactly what I was planning to do. It'll be driven by one of the house Cs or Rb standards that's compared against GPS. One of my questions -- whether a frequency-stabilized 64MHz clock would remove all sources of frequency error, or whether there was other clocking going on that could affect frequency measurement results. Sounds like you're saying there isn't. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] An interesting application for my new USRP... some input requested
I'm confused by the need to insert a reference signal and resample from that. I was thinking of just programming the four DACs (through two Basic RX boards) to each look at a, say, 10kHz wide chunk of spectrum around the nominal frequency, and then do a deep FFT of each of those streams. I'm confused by the need to inject another signal and resample. I'm sure I'm missing something, but I don't know what... John PS -- it may be you're describing what I did in the last couple of FMTs -- insert a known frequency from a signal generator within 100Hz or so of the unknown, then using FFT measure the delta between the two. That works very well, but requires me to measure only one signal at a time. I was hoping that with the USRP I'd be able to measure all four bands simulateously. n4hy wrote: There are no other clock sources of error in your analysis system since the clocking is all driven by the 64 Mhz stabilized oscillator. No sound card oscillators are involved. This will be a straight digital transfer to the analysis program(s) and all clocks from one reference. I would do this as follows: Insert a known tamed oscillator in LSB and have the measured tone in USB and use arithmetic to back out the offset (phase and frequency) using the known source. Since this is a frequency measuring test, a little phase modulation makes little difference. Using the USRP or SDR-1000, etc. the known reference is the key and you are doing that. In the SDR-1000 case, using the tamed and controlled 8640B, put it in LSB, the signal of interesting in the USB (say) and use the console to record an IQ signal. The analysis and the computation is then easy. The digitally recorded signal is resampled based on the reference signal. Then the frequency of the unknown signal is computed using a large FFT and the known new sample rate. You could do it this way with a known external reference and a combiner and a digital recording program. You record the known reference and the unknown signal in the same passband. Again, I would use my tamed 8640B as the reference. Then you can do it with analog receiver and a digital recorder. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] An interesting application for my new USRP... some input requested
Apologies. Poor writing. YOU do not need to insert with the all derived from one source system. Others, with multiple LO's etc. can use the injection of known reference method. HF sucks. It is full of very large signals that will typically hurt this kind of system (12 bit front end). You have to scale to handle the largest signal and the weaker ones go off the bottom, even after processing gain through the DDC. If you build filters and preamplifiers, you can hook up single banded front ends directly to the Basic RX inputs. These filters and preamps do not have to be super but do need to do some selection, filtering and amplification for your work. Then you can directly digitize and DDC the RF. I do not view this as a thing you would want to try with the USRP directly hooked to the antenna. Bob John Ackermann N8UR wrote: I'm confused by the need to insert a reference signal and resample from that. I was thinking of just programming the four DACs (through two Basic RX boards) to each look at a, say, 10kHz wide chunk of spectrum around the nominal frequency, and then do a deep FFT of each of those streams. I'm confused by the need to inject another signal and resample. I'm sure I'm missing something, but I don't know what... John PS -- it may be you're describing what I did in the last couple of FMTs -- insert a known frequency from a signal generator within 100Hz or so of the unknown, then using FFT measure the delta between the two. That works very well, but requires me to measure only one signal at a time. I was hoping that with the USRP I'd be able to measure all four bands simulateously. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP DDC usage
Quoting Achilleas Anastasopoulos [EMAIL PROTECTED]: I have a question/observation on this issue: Since the DDC multiplication is complex and since the internal DDC oscilator is noncoherent, I do not see a difference between the MUX settings: 0x33221100 and 0xf3f2f1f0. Is the difference between them a phase shift of 45 degrees and a gain ratio of sqrt(2)? Yes about the sqrt(2), but I guess the 45 degrees are irelevant here since the operation is noncoherent so we cannt resolve the phase. (see also comment below) Similarly, with the setting 0x3210 you will never be able to separate the two channels coming from ADC0/ADC1 and ADC2/ADC3. You can seperate ADC0/ADC1 and ADC2/ADC3 if you set the DDC frequency to zero (I think you also have to never have set it to a non-zero value after powerup, since you can't reset the DDC phase) Even if you set the frequency to 0, there is a random initial phase that is unknown, and thus you cannot separate the two channels. If x0(t) and x1(t) are the two inputs from ADC0 and ADC1 respect, then the output is [x0(t)+j x1(t)] exp(j w_cordic t + phi), where phi is unknown... Is this right? Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP DDC usage
Quoting Achilleas Anastasopoulos [EMAIL PROTECTED]: Quoting Achilleas Anastasopoulos [EMAIL PROTECTED]: I have a question/observation on this issue: Since the DDC multiplication is complex and since the internal DDC oscilator is noncoherent, I do not see a difference between the MUX settings: 0x33221100 and 0xf3f2f1f0. Is the difference between them a phase shift of 45 degrees and a gain ratio of sqrt(2)? Yes about the sqrt(2), but I guess the 45 degrees are irelevant here since the operation is noncoherent so we cannt resolve the phase. (see also comment below) Similarly, with the setting 0x3210 you will never be able to separate the two channels coming from ADC0/ADC1 and ADC2/ADC3. You can seperate ADC0/ADC1 and ADC2/ADC3 if you set the DDC frequency to zero (I think you also have to never have set it to a non-zero value after powerup, since you can't reset the DDC phase) Even if you set the frequency to 0, there is a random initial phase that is unknown, and thus you cannot separate the two channels. If x0(t) and x1(t) are the two inputs from ADC0 and ADC1 respect, then the output is [x0(t)+j x1(t)] exp(j w_cordic t + phi), where phi is unknown... I can't find the message, but I though that Matt Ettus stated that phi is zero at powerup, but it cannot be accessed thru software. Matt? Is this right? Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP DDC usage
Even if you set the frequency to 0, there is a random initial phase that is unknown, and thus you cannot separate the two channels. The initial phase is always 0 at power up. If you never set the frequency to something other than 0, it will always stay that way. Its a simple change to make the phase go back to zero. Patches welcome... Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP DDC usage
Dear all, although I agree that in the SPECIAL case when the CORDIC frequency is set to 0 it is meaningful to assume a known phase (set to 0 at power up or otherwise set externally to 0), I think it is a bad engineering practice to design receivers that assume a known phase (ie, a coherent operation) when the CORDIC frequency is NON-ZERO. I wonder if you share this reservation with me. Achilleas Matt Ettus wrote: Even if you set the frequency to 0, there is a random initial phase that is unknown, and thus you cannot separate the two channels. The initial phase is always 0 at power up. If you never set the frequency to something other than 0, it will always stay that way. Its a simple change to make the phase go back to zero. Patches welcome... Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RF building blocks
And at $550-ish, the TVRX/USRP are underpriced. Thanks Matt! I would suggest more realistic pricing on future components. There is little hope of long term viability, time for support, upgrades, etc. without sufficient capitalization. I know that even this is more than many can afford. Nevetheless, it would be better if Matt made enough per board to have a development budget of some sort and new toys to help us get new toys. With all of the GPL software, it would be a bargain at much more. IMHO. Throw tomatoes now please. Bob Eric Blossom wrote: On Thu, May 26, 2005 at 07:00:13AM -0700, Spencer Chirume wrote: Can anyone provide me the 'building blocks' of a basic and or intermidiate digital radio for general receptionLooking at the Component parts the physical parts(a/d other components) the software for demodulation stages preceding and past the demod stage nescesary for building it from scratch using widely available parts from companies like RS componetns and the likes. The path of least resistance it to buy a USRP with the TVRX daughterboard. See http://ettus.com Using radio shack parts, you're going to be limited to the bandwidth you can fit through a sound card, and then you'll still need a way to downconvert and filter to something that will fit. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP DDC usage
On Thu, May 26, 2005 at 04:33:15PM -0400, Krzysztof Kamieniecki wrote: I can't find the message, but I though that Matt Ettus stated that phi is zero at powerup, but it cannot be accessed thru software. Matt? It's zero at power up. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP DDC usage
On Thu, May 26, 2005 at 01:36:28PM -0400, Krzysztof Kamieniecki wrote: Quoting Achilleas Anastasopoulos [EMAIL PROTECTED]: I have a question/observation on this issue: Since the DDC multiplication is complex and since the internal DDC oscilator is noncoherent, I do not see a difference between the MUX settings: 0x33221100 and 0xf3f2f1f0. Is the difference between them a phase shift of 45 degrees and a gain ratio of sqrt(2)? That's what I would expect. Similarly, with the setting 0x3210 you will never be able to separate the two channels coming from ADC0/ADC1 and ADC2/ADC3. You can seperate ADC0/ADC1 and ADC2/ADC3 if you set the DDC frequency to zero (I think you also have to never have set it to a non-zero value after powerup, since you can't reset the DDC phase) I think I'm missing the question. Set nchannels to 2 and the output of the two DDCs will be interleaved. You deinterleave to separate them. See gnuradio-examples/python/usrp/wfm_rcv_many.py for an example that separates the output from more than one DDC. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP DDC usage
On Thu, May 26, 2005 at 04:41:17PM -0700, Matt Ettus wrote: Even if you set the frequency to 0, there is a random initial phase that is unknown, and thus you cannot separate the two channels. The initial phase is always 0 at power up. If you never set the frequency to something other than 0, it will always stay that way. Its a simple change to make the phase go back to zero. Patches welcome... Matt A couple of hints: You'll need a bit in an FPGA register to control the resetting to zero. Edit usrp/firmware/include/fpga_regs_standard.h and add // Reset phase accumulator to zero for those with bits set. // E.g., writing a 0x000f resets them all. Writing 0x0001 resets // the phase accumulator associated with DDC 0. #define FR_PHI_RESET 44 Doing a make in usrp/firmware/include will generate fpga_regs_standard.v from fpga_regs_standard.h Then look at these files to figure out the rest: usrp/fpga/sdr_lib/serial_io.v usrp/fpga/toplevel/usrp_std/usrp_std.v Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error in building GNU radio core 2.5
On Thu, May 26, 2005 at 09:58:11PM +0500, Ahmad Sheikh wrote: I am using automake 1.9.5 and autoconf 2.57. Also, does anyone know about these errors? /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/bits/type_traits.h:196: error: redefinition of `struct __type_traitsint' /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/bits/type_traits.h:126: error: previous definition of `struct __type_traitsint' /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/bits/type_traits.h:347: error: redefinition of `struct _Is_integerint' /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/bits/type_traits.h:305: error: previous definition of `struct _Is_integerint' In file included from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/../../../../include/c++/3.4.4/memory:61, from /usr/local/include/boost-1_32/boost/detail/shared_count.hpp:34, from /usr/local/include/boost-1_32/boost/shared_ptr.hpp:26, from ./gr_types.h:26, from ./gr_runtime.h:26, from ./gr_block.h:26, from gr_block.cc:27: I notice that you are running a version of gcc installed in /usr/local. Shouldn't be a problem, but does it compile other small C++ test cases OK? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Delta 44
Even though the Delta 44 has only four inputs and four outputs (all balanced monoaural), it reports twelve through ALSA to jack. I can tell this is happening since dial_tone.py and tvrx_wfm_rcv.py both blow up with complaints about the number of sinks. multi_tone.py works perfectly since it loads stuff up for all gazoutas. Has anyone done a general work around for this? Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] HDTV
On Thu, 2005-05-26 at 21:41 -0700, John E. Don Carlos wrote: What is the best way to get hdtv going? I don't know if anyone's done anything on this topic lately, but this is what I found from my experience on this: There is code in gnuradio-0.9 (hint: you don't have to make install gnuradio-0.9 -- the code will work out of the compiled source tree) which will allegedly take a 20MS/s (short samples) file, where the signal is centered around 5.75MHz (as is the case with the TVRX board assuming it uses the Microtune 3x7702), and produce a file containing the ATSC-encoded samples. The problem is that the USRP can't send 20MS/s over the USB bus, nor can it sample at 20MS/s without using an external reference. I think that support for the USRP in gnuradio-0.9 is... lacking. Another problem is that the code isn't particularly clever -- it needs a rather clean signal in order to decode it properly -- all of my attempts ended up with 100% errors while my pcHDTV card got the signal on that channel just fine. What I did was take the USRP, record the ATSC signal to a file centered at 0MHz using DDC (make sure to downconvert in the right direction) (compex floats), which allows you to use 8MS/s and the USB bus seems to be able to keep up with that, mostly. Then you can write a script to convert that to a file of shorts with the signal centered at 5.75MHz (e.g. by multiplying it by a complex sine wave). Now you have a file that the gnuradio-0.9 code is willing to deal with, and if your signal is clean enough then you should get an mpeg file. This is where I hit a dead end, and thus wasn't really willing to try to convert the old code to new code since I had no way of knowing if it would work or not. Good luck :) (If you're just interested in watching HDTV I'd personally advise you to get a card like the pcHDTV 3000 which has good linux support and does ATSC as well as QAM; today's computers don't have enough cpu power to do this in real time) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
