Re: [Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 28, Issue 18
> Hye all > > Iam also a hardware engineer and work on FPGA and design > with Digital fundamentals and code on verilog , can u all > tell me where can i fit into this discussion and how can i > help. > > Regards > > Sarvamiti Welcome. All of the code and designs for the USRP are available at http://www.ettus.com so you can download them and take a look. More users and developers are always welcome, especially those with FPGA experience. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Directions..
> I have been successfully using the USRP to digitize NTSC video. However I > need to change > the system operation freq to 27 MHz. I am thinking of using cyclone's PLL > for generating the > 27 MHz clock for internal operation. But the problem is really feeding the > 27 MHz clock > to the ADC. I am going to use an unused FPGA output and use it to drive the > CLK_CODEC_A and CLK_CODEC_B signals. That would work. > I am referring to the schematic for the FPGA (fpga.pdf). I will disconnect > R1012 and R1023, > and simply connect the output clock of the FPGA to the R1014 and R1015. I think you meant R1012 and R1013. That would work. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Query on GPS
Krzysztof Kamieniecki wrote: Right now it looks like my software does to the demodulation and calculation of position into xyz coordinates, I'm still looking for enough raw data to be able to test the full position calculation. Hi. I'm a newbie in this list, but I'm a telecom engineer and have experience in signal "soft decoding". I just bought a GPS unit a few weeks ago and I'm very curious about the protocol. I know the basics, but I would like to know more about the PRN codes used (Gold codes) and the format of ephemerids and almanac transmissions. Basically to know enough to soft decode the satelites' signals. I just subscribed to this mailing list and seems that people here have that kind of information. Could you possibly point me to online "deep" docs about that subject?. I'm more interested in docs that source code, BTW. Thanks in advance for your time and attention. -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/ _/_/_/_/ _/_/ _/_/_/_/ _/_/_/_/_/ PGP Key Available at KeyServ _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Query on GPS
This is the GPS standard http://www.navcen.uscg.gov/gps/geninfo/ICD-GPS-200C%20with%20IRNs%2012345.pdf There are more links to interesting GPS documents at http://comsec.com/wiki?GlobalPositioningSystem Which is part of the GNURadio Wiki http://comsec.com/wiki Quoting Jesus Cea <[EMAIL PROTECTED]>: > Krzysztof Kamieniecki wrote: > > Right now it looks like my software does to the demodulation and > calculation of > > position into xyz coordinates, I'm still looking for enough raw data to be > able > > to test the full position calculation. > > Hi. I'm a newbie in this list, but I'm a telecom engineer and have > experience in signal "soft decoding". > > I just bought a GPS unit a few weeks ago and I'm very curious about the > protocol. I know the basics, but I would like to know more about the PRN > codes used (Gold codes) and the format of ephemerids and almanac > transmissions. Basically to know enough to soft decode the satelites' > signals. > > I just subscribed to this mailing list and seems that people here have > that kind of information. Could you possibly point me to online "deep" > docs about that subject?. I'm more interested in docs that source code, BTW. > > Thanks in advance for your time and attention. > > -- > Jesus Cea Avion _/_/ _/_/_/_/_/_/ > [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/ _/_/_/_/ _/_/ >_/_/_/_/ _/_/_/_/_/ > PGP Key Available at KeyServ _/_/ _/_/_/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > > > ___ > 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] interpolation and output level + missing Tx_check
Greetings, I updated my code from CVS yesterday and the tx_check.py was missing in the gnuradio-examples. Was this removed ? I am still wresting with the issues below. This time I tried usrp_siggen.py and it fails the first time giving: [EMAIL PROTECTED] usrp]$ ./usrp_siggen.py usrp: found usrp rev2 usrp_open_interface: usb_claim_interface: failed conf 0 could not set config 1: Operation not permitted open_nth_cmd_interface: open_cmd_interface failed Traceback (most recent call last): File "./usrp_siggen.py", line 144, in ? main () File "./usrp_siggen.py", line 128, in main sg = siggen () File "./usrp_siggen.py", line 21, in __init__ self._instantiate_blocks () File "./usrp_siggen.py", line 68, in _instantiate_blocks self.usrp = usrp.sink_c (0, self.interp) File "/usr/local/lib/python2.3/site-packages/gnuradio/usrp1.py", line 740, in sink_c return _usrp1.sink_c(*args) RuntimeError: std::runtime_error --- Any suggestions ? Thanks in advance. Javs --- Javs <[EMAIL PROTECTED]> wrote: > Hey Eric, > > I tried various values for the amplitude and looks > like it works fine anywhere between 1 and > 35000, > giving me ~= 10mV and 35mV respectively. But > anywhere > below or beyond its behaving erratic. Is this the > boundary ? > > And here is what I get when I boot my usrp and run > the > tx_check.py the first time. > > [EMAIL PROTECTED] usrp]$ ./tx_check.py usrp: found usrp > rev2 > usrp_open_interface: usb_claim_interface: failed > conf > 0 > could not set config 1: Operation not permitted > open_nth_cmd_interface: open_cmd_interface failed > Traceback (most recent call last): > File "./tx_check.py", line 78, in ? > main () > File "./tx_check.py", line 70, in main > sg = siggen () > File "./tx_check.py", line 17, in __init__ > self._instantiate_blocks () > File "./tx_check.py", line 53, in > _instantiate_blocks > self.usrp = usrp.sink_c (0, self.interp) > File > "/usr/local/lib/python2.3/site-packages/gnuradio/usrp1.py", > line 692, in sink_c > return _usrp1.sink_c(*args) > RuntimeError: std::runtime_error > > - > > Thanks for looking into it. > > Javs > > --- Eric Blossom <[EMAIL PROTECTED]> wrote: > > On Fri, Mar 18, 2005 at 02:05:24PM -0800, Javs > > wrote: > > > > > > Hello ppl, > > > > > > > > I understand that the interpolation factor > changes > > the amplitudes of > > > the signals. The default usrp_siggen.py works > fine > > and I can admire > > > 16mV and 100 K on the scope. But if I use the > > default intrp of 64 in > > > the example usrp_siggen.py and try to change the > > amplitude levels > > > using -a option, the signals still come down. > Any > > guesses why ? > > > > What value's are you trying with the -a option? > > Keep them <= 16000. > > > > > Also, When I first boot my USRP and try an > > example, it fails for the > > > first time. For instance, I tried tx_check.py > and > > i had a runtime > > > error. However, it works fine the second time. > Is > > this because, it > > > takes its time to load firmware into the FX2 and > > the FPGA or am I > > > missing something here ? > > > > What's the error? > > > > Eric > > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FPGA RA spectrometer
Just saw this on my SARA (Society of Amateur Radio Astronomers) list: http://arxiv.org/abs/astro-ph/0503067 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] interpolation and output level + missing Tx_check
On Tue, Mar 22, 2005 at 07:04:13AM -0800, Javs wrote: > Greetings, > > I updated my code from CVS yesterday and the > tx_check.py was missing in the gnuradio-examples. Was > this removed ? Yep. Try usrp_siggen.py instead. > I am still wresting with the issues below. This time I > tried usrp_siggen.py and it fails the first time > giving: > > [EMAIL PROTECTED] usrp]$ ./usrp_siggen.py > usrp: found usrp rev2 > usrp_open_interface: usb_claim_interface: failed conf > 0 > could not set config 1: Operation not permitted > open_nth_cmd_interface: open_cmd_interface failed > Traceback (most recent call last): > File "./usrp_siggen.py", line 144, in ? > main () > File "./usrp_siggen.py", line 128, in main > sg = siggen () > File "./usrp_siggen.py", line 21, in __init__ > self._instantiate_blocks () > File "./usrp_siggen.py", line 68, in > _instantiate_blocks > self.usrp = usrp.sink_c (0, self.interp) > File > "/usr/local/lib/python2.3/site-packages/gnuradio/usrp1.py", > line 740, in sink_c > return _usrp1.sink_c(*args) > RuntimeError: std::runtime_error > > --- > > Any suggestions ? > > Thanks in advance. > > Javs Can you please provide additional platform info such as: OS, version, distribution, hardware architecture, etc. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: interpolation and output level + missing Tx_check
Note: forwarded message attached. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- Begin Message --- Sure. I am running Redhat 4.0 on a linux machine with a VIA EBC-C3 733MHz MMX compatible processor and 512MB of PCI133 SDRAM. I added a USB 2.0 host controller(NEC uPD720101) over the existing slow USB. Other Features: VIA 733 MHz low power C3 processor EBX-compliant board - 32 to 512MB of system PC133 SDRAM supported in a 168-pin DIMM socket - Socket for up to 1GB bootable DiskOnChip® or 512KB SRAM or 1MB EPROM - Type I and II Compact Flash (CF) cards supported - PC-compatible supports Linux,Windows CE.NET and XPe, plus other x86-compatible RTOS - High resolution video controller supports - Color panels supported with up to 36-bits/pixel - Supports resolutions up to 1920 x 1440 - Simultaneous CRT and LCD operation - 4X AGP local bus for high speed operation - LVDS supported - Dual 10/100 Mbps Intel PCI Ethernet controllers - 4 RS-232 serial ports with FIFO, COM1 & COM2 with RS-422/485 support - Bi-directional LPT port supports EPP/ECP - 48 bi-directional TTL digital I/O lines with 24 capable of event sense interrupt generation - Four USB ports onboard - Two, dual Ultra DMA 33/66/100 EIDE connectors - Floppy disk controller supports 1 or 2 drives - AC97 Audio supported - PC/104 and PC/104-Plus expansion connectors - AT keyboard controller and PS/2 mouse support - Activity LEDs onboard for visual status - Two interrupt controllers and 7 DMA channels - Three, 16-bit counter/timers - +5 volt only operation - Upgrade for WinSystems' EBC-LP and EBC-BX - Real Time Clock,WDT and power fail reset - Small size: 5.75" x 8.0" (146 mm x 203 mm) Thanks Javs Eric Blossom <[EMAIL PROTECTED]> wrote: On Tue, Mar 22, 2005 at 07:04:13AM -0800, Javs wrote:> Greetings,> > I updated my code from CVS yesterday and the> tx_check.py was missing in the gnuradio-examples. Was> this removed ? Yep. Try usrp_siggen.py instead.> I am still wresting with the issues below. This time I> tried usrp_siggen.py and it fails the first time> giving: > > [EMAIL PROTECTED] usrp]$ ./usrp_siggen.py> usrp: found usrp rev2> usrp_open_interface: usb_claim_interface: failed conf> 0> could not set config 1: Operation not permitted> open_nth_cmd_interface: open_cmd_interface failed> Traceback (most recent call last):> File "./usrp_siggen.py", line 144, in ?> main ()> File "./usrp_siggen.py", line 128, in main> sg = siggen ()> File "./usrp_siggen.py", line 21, in __init__> self._instantiate_blocks ()> File "./usrp_siggen.py", line 68, in> _instantiate_blocks> self.usrp = usrp.sink_c (0, self.interp)> File> "/usr/local/lib/python2.3/site-packages/gnuradio/usrp1.py",> line 740, in sink_c> return _usrp1.sink_c(*args)> RuntimeError: std::runtime_error> > ---> > Any suggestions ? > > Thanks in advance.> > JavsCan you please provide additional platform info such as:OS, version, distribution, hardware architecture, etc.Eric__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- End Message --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Physical layer for packet-based communication
Rahul, Sorry for the delay in responding. Answering your questions in reverse order: On Thu, Feb 10, 2005 at 04:37:12PM -0500, Rahul Dhar wrote: > Given 802.11's tight timing requirements (discussed > briefly earlier in this thread), can the CPU schedule and send packets > fast enough? I think it depends which MAC you use, how many packets/sec, how much CPU overhead you can tolerate, etc. I don't think you can send an 802.11 ACK packet fast enough if the CPU has to get involved---but then again, maybe your preferred MAC doesn't use ACK packets. > Do you know how to access those parameters? As far as I know, most of > the useful ones are stuck in firmware, and vendors don't want to tell us > how to play with the firmware. Otherwise, this sounds like the best > solution, especially if I can write my own firmware (or edit the > existing one). 802.11 makers are moving away from microcontrollers. Real-time MAC functions are implemented by silicon state machines. The rest of the firmware's intelligence has moved into the device driver. The host computer is responsible for setting up the modem, synthesizer, and transceiver. I believe the best way to find out what parameters you can tweak is to look at some examples sources. Take a look at the driver I wrote for ADMtek 802.11b chips. You can browse the sources on-line at http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/. Check out these files: dev/ic/atwreg.h /* MAC register definitions */ dev/ic/atwvar.h /* driver data structures */ dev/ic/atw.c/* driver logic */ dev/ic/rf3000reg.h /* modem register definitions */ dev/ic/si4136reg.h /* synthesizer register definitions */ You should be able to discern from rf3000reg.h which registers control the transmit power and the receiver's AGC loop. (If not, please tell me so that I can fix the in-line documentation!) si4136reg.h defines the registers for programming the IF/RF synthesizer. atw.c shows how I write registers on the synth and baseband---start at the subroutine atw_tune. For another example, there is the new Realtek driver, which is used with three or four different transceiver/synthesizer chips. My driver only supports two: dev/ic/rtw.c dev/ic/rtwphy.c /* PHY control logic */ dev/ic/rtwphy.h dev/ic/rtwphyio.c /* PHY I/O */ dev/ic/rtwphyio.h dev/ic/rtwreg.h /* MAC / modem registers */ dev/ic/rtwvar.h dev/ic/sa2400reg.h /* Philips SA2400A transceiver/synthesizer * registers */ dev/ic/max2820reg.h /* Maxim MAX2820 transceiver/synthesizer regs */ The Maxim MAX2820 datasheet is available for free download. I think you can find the SA2400 datasheet on the web without looking very hard. > > > 3 Use an existing 802.11 PHY, but replace the MAC > > with a microcontroller [*]. Design a PHY abstraction. > > Implement, in C (say), the PHY abstraction for the PHY of your > > choice [**]. Program your MAC in C. > > This is actually what I'd like to do for GNU Radio, but I'm not sure > where to start, nor am I sure if it's even feasible. It has been noted > that PHY's tend to be too diverse to make a meaningful abstraction very > difficult. I may not have understand what you mean, but I don't think 802.11 PHYs are too diverse to abstract. Look at how I have abstracted the PHY in the Realtek driver. It is not a great abstraction, but it is a start. Essentially, I treat the PHY as an "object" with methods Initialize, Set Powersaving State, Set Transmit Power, and Set Channel. I create the PHY object with callbacks for doing serial I/O (transceivers and such are usually located on some serial bus) and for activating a MAC calibration mode. Dave -- David Young OJC Technologies [EMAIL PROTECTED] Urbana, IL * (217) 278-3933 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] A question about the synchronization
Hi Eric and Matt When the input IF signal passes quadrature downconverter, does any kind of carrier and symbol synchronization is performed in the FPGA code? If so, which algorithm did you use? Thanks Sachi __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Microtune 4937-based RF front end
Hello everyone, We'd like to make some off-air HDTV measurements, but realize the Microtune 4937-based RF front-ends are no longer available. We've tried eBay and parts brokers. We've looked at alternative RF front-ends, but the IF output is usually too high for the A/D card. We could patch together a different front end, but that would be more trouble than it's worth (for us, anyway, perhaps not for other folks on this list). So, here's a question for the group: does anyone have a 4937-based front end that we could buy, borrow, or steal? :) Much thanks, -Graham -- I am using the free version of SPAMfighter for private users. It has removed 8581 spam emails to date. Paying users do not have this message in their emails. Try www.SPAMfighter.com for free now! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Microtune 4937-based RF front end
Quoting Graham Stead <[EMAIL PROTECTED]>: > Hello everyone, > > We'd like to make some off-air HDTV measurements, but realize the Microtune > 4937-based RF front-ends are no longer available. > > We've tried eBay and parts brokers. We've looked at alternative RF > front-ends, but the IF output is usually too high for the A/D card. We could > patch together a different front end, but that would be more trouble than > it's worth (for us, anyway, perhaps not for other folks on this list). > > So, here's a question for the group: does anyone have a 4937-based front end > that we could buy, borrow, or steal? :) In a couple of weeks you'll be able to buy 4937-based daughterboards for the USRP. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
