[Discuss-gnuradio] Eight-core SPARC MCU record
G'day, May be this is of interest to some! http://www.electronicstalk.com/news/sun/sun102.html cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP hardware purchase
I've got to go with Dan on this one, there is no chance of 802.11 with the USRP and GNU Radio. However, we are working on something 802.11-like with the in-band signaling work and the MAC we are building. I think a big first step for the platform is getting a solid contention based MAC protocol, which the platform lacks as a whole. From this, some 802.11-like MAC can be built, and other protocols. To give you a heads up Dan, we are working on doing carrier sense in the FPGA and supporting it with the in-band signaling work. It's actually what we're working on at this second. Building it in the FPGA avoids the FPGA->host->FPGA latency. The FPGA is going to read carrier sense related parameters from registers, and the host will set a flag in the packet if it wants the FPGA to carrier sense before transmitting it. I think very time sensitive functionalities like this need to be pushed in the FPGA though we're also considering building it in the host too so we can evaluate the tradeoffs. - George Dan Halperin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The USRP has a maximum bandwidth of about 16 MHz (using 8-bit samples instead of the usual 16), which is not even enough to cover one 802.11b/g channel (22 MHz Nyquist). Thus you'll have a hard time decoding b/g packets at faster than 1,2 Mbit rates (BBN has done some work facilitating the recovery of these packets). On top of that, an (extremely, I think) optimistic lower bound for latency in a GNU radio system is over 1 millisecond from the RX antenna through the FPGA over the USB to the computer to your software back over the USB and out the TX antenna. This makes it _reallly_ hard to get the 10 _microsecond_ turnaround required for an 802.11b ACK, and carrier sense is meaningless with such a latency. Also, see Tom Rondeau's email of 12/05/2006 for more comments, but the short of it is that you're unlikely to be able to get any sort of reasonable interoperation between the USRP and commercial 802.11b/g hardware. - -Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGw67By9GYuuMoUJ4RAqhgAKDENetmsE0mIa9dw3JyE787xo8KMQCfX+Pf Odcvnn/HpAQ8PDahyfKt0Fo= =Hre7 -END PGP SIGNATURE- ___ 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] Receiving USRP bits in c++ (no blocks needed)
On Wed, Aug 15, 2007 at 10:20:43AM +0100, Richard Meston wrote: > Actually, I'd be very interested in this as well. Especially if it > worked under Windoze. Something that will just configure and grab data > from the USRP into a buffer would be fantastic. > > Any ideas anyone? > > Rich Support for C++ apps with no python is slated for the 3.2 release. http://gnuradio.org/trac/roadmap Until then, you're on your own... Eric > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Chris Stankevitz > Sent: 14 August 2007 18:02 > To: Matt Ettus > Cc: 'discuss-gnuradio@gnu.org' > Subject: Re: [Discuss-gnuradio] Receiving USRP bits in c++ (no blocks > needed) > > Matt Ettus wrote: > > It's called usrp_rx_cfile.py > > Thanks, but I'm looking for a c++ app. > > Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GPL/Makefile
On Tue, Aug 14, 2007 at 11:27:31PM +0200, Dominik Auras wrote: > Hi! > > First of all, excuse me for this beginner's question. Furthermore this is a > little bit offtopic. > > I have copied gr-howto-write-a-block and adapted everything to my needs. > Now, in the Makefiles, it says "This file is part of GNU Radio". But my > project is not part of the GNU Radio framework, and I don't think that I > should claim it is. > > Do I have to keep the copyright notice in the Makefile, since it has been > there, and add a note that there are changes? I mean, it is clear that there > are changes. A Makefile has to be modified, sources added etc. Or do I put > my own GPL-Note with my applications name? The FSF copyright should remain in the file. You may add others, but should not remove the existing copyright notice. > It's only about the Makefiles (.am etc.). > > (I tried to google for it, but my keywords are not that precise) > > Thank you very much > Great work! > > Dominik Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP hardware purchase
On Wed, Aug 15, 2007 at 06:56:17PM -0700, Dan Halperin wrote: > > On top of that, an (extremely, I think) optimistic lower bound for > latency in a GNU radio system is over 1 millisecond from the RX antenna > through the FPGA over the USB to the computer to your software back over > the USB and out the TX antenna. This makes it _reallly_ hard to get > the 10 _microsecond_ turnaround required for an 802.11b ACK, and carrier > sense is meaningless with such a latency. I think 100us is possible if you're mindful of the buffer sizing. I concur that 10us is not going to happen on the host ;) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] xG Technology
On Wed, 2007-08-15 at 22:54 -0500, Jeff Brower wrote: > Michael- > > > I think the most comprehensive page I've found is < http:// > > en.wikipedia.org/wiki/XMax >. Links to patents and reviews (e.g. > > Phil Karn's). - MLD > > Phil Karn is a Qualcomm employee -- maybe not the most impartial source. > Here is > something recent, starting with an actual face-to-face meeting with xG > management: > > Thanks guys - will check those out. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] xG Technology
Charles Swiger wrote: > On Wed, 2007-08-15 at 22:54 -0500, Jeff Brower wrote: > >> Michael- >> >> >>> I think the most comprehensive page I've found is < http:// >>> en.wikipedia.org/wiki/XMax >. Links to patents and reviews (e.g. >>> Phil Karn's). - MLD >>> >> Phil Karn is a Qualcomm employee -- maybe not the most impartial source. >> Here is >> something recent, starting with an actual face-to-face meeting with xG >> management: >> >> >> > > Thanks guys - will check those out. > > --Chuck > > > I couldn't find Jeffs response in my "discuss-gnuradio" archive, so I'm responding here. I've known Phil personally for many years (yikes, a couple of decades now!). I'd be utterly shocked to find him simply "spouting the company line". I've read his analysis, and talked to him in person about some of this stuff, and I find the approach of going back to first principles to be compelling. There seems to be a fair amount of "perpetual motion machines" happening in modulation schemes, and Phil has usually "taken them on" with grace and scientific rigour. I'd be keen to see the analysis that Jeff pointed out, but as I said, I don't appear to have that e-mail in the discuss-gnuradio archive I have here... signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: File format question
Bahn William L Civ USAFA/DFCS schrieb: I would prefer to use the constants that have been set up so that the code is (1) more readable, and (2) more maintainable. So instead of using "8" for complex, I would like to use gr.sizeof_"whatever". But I don't know what "whatever" needs to be. Where do I find this? Python has nice reflection/inspection capabilities, so you're able to list the content of a package. Doing this "by hand" is somewhat cumbersome, have a look at the module inspect[0]. I would recommend to use pyalamode from the wxPython project (should be packaged in a decent distribution, like python-wxtools in Debian[1]) pyalamode allows you to browse packages and does autocompletion, so you type "gr.sizeof_" and get a list of all available sizeof_s. Patrick asdf [0] http://www.python.org/doc/2.4.4/lib/module-inspect.html [1] http://packages.debian.org/cgi-bin/search_contents.pl?word=pyalamode&searchmode=searchfiles -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] xG Technology
Marcus- > I couldn't find Jeffs response in my "discuss-gnuradio" archive, so I'm > responding here. > > I've known Phil personally for many years (yikes, a couple of decades > now!). I'd be utterly > shocked to find him simply "spouting the company line". > > I've read his analysis, and talked to him in person about some of this > stuff, and I find the approach > of going back to first principles to be compelling. There seems to > be a fair amount of "perpetual motion machines" > happening in modulation schemes, and Phil has usually "taken them on" > with grace and scientific rigour. > > I'd be keen to see the analysis that Jeff pointed out, but as I said, I > don't appear to have that e-mail in the > discuss-gnuradio archive I have here... Here is a fairly recent (29 Jun 07) Phil Karn page on xG's xMax technology: http://www.ka9q.net/xmax.html -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] File format question
> > When possible, I would prefer to use the constants that have been set up > so that the code is (1) more readable, and (2) more maintainable. So > instead of using "8" for complex, I would like to use > gr.sizeof_"whatever". But I don't know what "whatever" needs to be. Where > do I find this? > > > From > /usr/local/lib/python2.5/site- > packages/gnuradio/gr/gnuradio_swig_py_runtime.py: > > sizeof_char = _gnuradio_swig_py_runtime.sizeof_char > sizeof_short = _gnuradio_swig_py_runtime.sizeof_short > sizeof_int = _gnuradio_swig_py_runtime.sizeof_int > sizeof_float = _gnuradio_swig_py_runtime.sizeof_float > sizeof_double = _gnuradio_swig_py_runtime.sizeof_double > sizeof_gr_complex = _gnuradio_swig_py_runtime.sizeof_gr_complex > > Those are the constants you want. > Thank you very much. I certainly would have never thought to look in that file in that directory. > > It would be so much simpler if I could just use the generated time > domain data directly. > > > > Thanks! > > When you say generated time domain data, are you talking about (time, > voltage) pairs off of a scope? IIRC scope data is just the I component, > and you can get the Q component from I using standard signal processing > techniques assuming your sampling rate is sufficiently high. No, I'm talking about instantaneous baseband waveform amplitudes generated by an external program and written to a file with a single amplitude value per sample. Also, what is the peak-peak signal values for floating point data sources? -1.0 to +1.0? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] xG Technology
Jordan- > > Phil Karn is a Qualcomm employee -- maybe not the most impartial > > source. > > Hey, Jeff: welcome to the Internet. I see this must be your first day > :) It seems like Phil has worked carefully and thoroughly to show areas of weakness -- or unexplained gaps -- in xG's approach and technical data. And he's qualified to do so. My comment would be that putting a "Snake Oil" image at the top of the web page is not a good way to immediately convey a sense of impartiality. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rssi questions
Eric Blossom wrote: > For now, don't worry about getting it into dB on the FPGA. > The representation can be manipulated on the host. > OK, so how do I get post-ADC rssi out of the USRP for any arbitrary daughtercard? My radio astronomy receiver could benefit from this, especially if the RSSI is low-pass filtered to some degree onboard the FPGA. Part of my host side stuff computes RSSI from the samples coming from the USRP (by squaring and low-pass filtering). I could probably save about 20% of my CPU load if I could get that squaring, and at least a first-stage low-pass filter done on the FPGA. signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rssi questions
On Thu, Aug 16, 2007 at 12:36:05PM -0400, George Nychis wrote: > Okay, so I'm a little bit intimidated, I'm not too familiar at this level. > > So I'm going to ask for some help me through with baby step questions :) > > We managed to get reading/writing to some unused registers working > through in-band C/S packets. So, we're ready to use this code to pass > information from the host to FPGA about the daughterboard configuration. > > We want to compute the RSSI in dB on the FPGA, we're not even interested > in the FPGA responding back with the RSSI at this point. > > 1. What exact information needs to be shared? Some measure of the received signal strength. > 2. Where can we get the information? I'm assuming when the > daughterboards are initialized most of this information is available. For the time being, assume that you are getting it from the "Post ADC" rssi block, rssi.v. See also usrp_std.v (search for rssi). > 3. How exactly would you compute the RSSI in dB given this information > on the FPGA efficiently? Equation? :) For now, don't worry about getting it into dB on the FPGA. The representation can be manipulated on the host. > Thanks! > George Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rssi questions
Okay, so I'm a little bit intimidated, I'm not too familiar at this level. So I'm going to ask for some help me through with baby step questions :) We managed to get reading/writing to some unused registers working through in-band C/S packets. So, we're ready to use this code to pass information from the host to FPGA about the daughterboard configuration. We want to compute the RSSI in dB on the FPGA, we're not even interested in the FPGA responding back with the RSSI at this point. 1. What exact information needs to be shared? 2. Where can we get the information? I'm assuming when the daughterboards are initialized most of this information is available. 3. How exactly would you compute the RSSI in dB given this information on the FPGA efficiently? Equation? :) Thanks! George Johnathan Corgan wrote: George Nychis wrote: Thanks for all the responses and info on the RSSI. I'm following most of it, but will probably have a bunch more questions the further we get in to it. The reason we are poking at this is because we are interested in using it for carrier sense. I agree that reporting it in terms of dB would be nice. I guess theres a tradeoff here of complexity/power at the FPGA which we can discuss. But you're saying that given information in registers from the daughterboard setup, it is possible? How the power level gets reported to the host can be different from how it is used in either an AGC loop or as a carrier sense/squelch block on the FPGA. The first thing to understand is that for a given hardware gain setting of a daughterboard, there is a fixed, multiplicative relationship between the RF amplitude and the ADC full scale output. (In the log domain, this becomes an additive relationship.) You can determine one from the other in either direction if you know the gain multiplier (or log power additive constant). In practice you'd have to measure this as a calibration step and supply the conversion value as a configuration register. A suitable default could be based on a theoretical calculation using the daughterboard design and configuration settings, but manufacturing tolerances will cause this to be somewhat inaccurate. But what you measure and use as a control value on the FPGA can be manipulated on the host into whatever format (dBm, etc.) you want for display; you don't need to worry about that at the FPGA. The next thing to consider is how to measure the ADC output "power". The RSSI block in the existing code implements an exponential averaging filter on the absolute magnitude of the ADC output. The "alpha" multiplier for this filter is fixed at 2^-10. This gives a time constant of about 16 us. A step change in the ADC output would result in the measurement output reaching 63% of the change after one of these periods. Five time constants get you to 99%. So you could threshold on this value to determine whether there is sufficient signal magnitude to say "carrier-sensed." To avoid "bounce" you'd want to two thresholds to add hysteresis. The limitation of the current rssi.v implementation is that the time constant is fixed. It could be too long or too short depending on what it is being used for. And some more advanced carrier-sense or squelch algorithms alter the time constant to get different dynamics during open or closed states. The main reason it is fixed is this results in very simple logic (shift by 10 bits and add vs. two multipliers.) So if you want to implement a more complex algorithm you'll have a lot more area involved. Another factor to consider is that the signal, at the output of the ADC, represents all the energy of the entire passband of the daughter card. If your signal of interest is narrow band and you haven't implemented external pre-filtering, then you're measuring energy from more than your signal of interest. This might be ok, but probably not. You could put the RSSI block after the DDC, which would help, but now your relationship to real RF power vs. RSSI block output becomes complicated by the decimation rate and DDC filter passband. Next, if you want to use this value in an AGC feedback loop to control hardware gain, there are further issues. One is loop response time. Can you measure, calculate a new gain value, reconfigure the hardware, and track your signal fast enough to be useful? For a digital comms system, maybe you only need to do this during the packet preamble and hold the gain constant for the duration of the data burst. Gain control on the RFX boards is controlled mostly by the motherboard AD9862 auxiliary DAC. Normally, this is done on the host through the SPI bus via the FX2 USB controller. Implementing a SPI master on the FPGA and sharing the lines with the FX2 master doesn't sound straightforward, and might even require jumpering the SPI enable lines. Perhaps the USRP2 design will make all this much simpler. (Matt--please step in any minute now :-) ___
Re: [Discuss-gnuradio] xG Technology
Jeff Brower schrieb: > Jordan- > > >>> Phil Karn is a Qualcomm employee -- maybe not the most impartial >>> source. >>> >> Hey, Jeff: welcome to the Internet. I see this must be your first day >> :) >> > > It seems like Phil has worked carefully and thoroughly to show areas of > weakness -- > or unexplained gaps -- in xG's approach and technical data. And he's > qualified to do > so. > > My comment would be that putting a "Snake Oil" image at the top of the web > page is > not a good way to immediately convey a sense of impartiality. > > -Jeff > I looked at the various posts on this topic and all I can say is... given that I was in Florida a few months ago, working with a 'very low bit rate' link set up over about 15 miles, using a 25 W transmitter in the ISM band (hey it was their FCC problem not mine...), and getting quite a bit of interference none the less... I would have loved to have some snake oil to grease the skids... as long as the customer signed off... As it was, with a few replacements of cables, turning off other 'local' transmitters operating in the same band, etc... all was well.. At 35 or 50 mW of power over 18 miles, in the 902-928 ISM band, and at 3 Mbits/s, I'm wondering where they were in Florida... On the topic of Phil Karn... my 'contact' with that name was using the ancient AX-25/Packet Radio networking stacks of yore to do incredibly low speed networking (as a note my system in Florida was replacing a KA9Q based implementation...). So perhaps while now Karn may have surcome to the corporate coolaid... at least at some point he was involved in the early phases of what we now call 'open software'... like GNURadio The last time I had anything to do with Packet Radio was when I ported it to an OS/9 setup for a small company called ITT... I thought that would be my entry in to the big time... ha... well anyway... John Clark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rssi questions
George Nychis wrote: > We want to compute the RSSI in dB on the FPGA, we're not even > interested in the FPGA responding back with the RSSI at this point. Okay, but--why do you need units of dB? This is in the log domain, so at some point on the FPGA you'll need to take a logarithm of an amplitude. If it is for the user's benefit, then it is much simpler to do the conversion on the host. > 1. What exact information needs to be shared? The output of the ADC is a fixed multiple of the signal at the antenna input. Since the gain settings are controlled by the host, the host would need to calculate what the overall gain is and poke a register with a value the FPGA logic could use. Again, though, why do you need to get the actual RSSI? If you're going to use it for carrier-sense, then all you really need to do is threshold the average magnitude of the ADC output. You've already got that value calculated in rssi.v (perhaps that's a confusing name for the Verilog file.) The only downside of rssi.v output is that the time constant for averaging is fixed (to make the logic very simple, fast, and low-area.) > 2. Where can we get the information? I'm assuming when the > daughterboards are initialized most of this information is available. It would be different for each daughterboard, but code could be added to the host daughterboard handling code to determine the overall antenna to ADC gain when the gain settings are set by the user. That overall gain value would then be poked into a register on the FPGA to be used by your code to get actual antenna power (assuming you still really need to do this.) Finally, for an AGC, the power measurement portion of the control loop doesn't need to be taken all the way to dB. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] xG Technology
John Clark wrote: > On the topic of Phil Karn... my 'contact' with that name was using the > ancient AX-25/Packet Radio networking stacks of yore > to do incredibly low speed networking (as a note my system in Florida > was replacing a KA9Q based implementation...). So > perhaps while now Karn may have surcome to the corporate coolaid... at > least at some point he was involved in the > early phases of what we now call 'open software'... like GNURadio > The last time I had anything to do with Packet Radio was > when I ported it to an OS/9 setup for a small company called ITT... I > thought that would be my entry in to the big time... ha... well > anyway... Phil's worked in the telecom industry for a long time, first for Bellcore and then for Qualcomm. But at the same time, he's done a tremendous amount of engineering in the public interest, not only with his KA9Q TCP/IP implementation but with spread spectrum, signal coding, and all sorts of other cool stuff. He was also an activist against the US' absurd export controls on encryption, and has worked to defeat bad patents using prior art. And, in his spare time, he takes down people who don't believe in what those Nyquist and Shannon fellas had to say. :-) John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rssi questions
Eric, we want feedback from you on this one :) I think you're right Jonathan, for performing carrier sense in the FPGA, we really do not need it in dB. Calculating the average to determine a threshold will get the job done with less the hassle. And right, if the host really wants it in dB, it can do the conversion. So here is what I want feedback on... how to communicate the RSSI to the host. What we figure is that the host should determine the threshold, in other words calculate the average and write it to a register that the FPGA can read. This saves the floating point computation on the FPGA, and the host can decide how many RSSI samples it wants to compute the threshold on. But, we've already determined that the 6-bits in the header are not enough for properly reading the RSSI from the FPGA. So, what do we want to do about this? We can store the RSSI in a register and read from it using C/S packets, then compute the average. This gives the full 32-bits. However, I still think it would be useful for each packet to contain an RSSI reading. I'm sure others would put use to this in the future. I propose adding a 32-bit RSSI field to the packet header. This doesn't even incur 1% overhead, it's ~.7% additional overhead per packet. Then with the higher bandwidth of USRP2, it's going to become even more insignificant. - George Johnathan Corgan wrote: George Nychis wrote: We want to compute the RSSI in dB on the FPGA, we're not even interested in the FPGA responding back with the RSSI at this point. Okay, but--why do you need units of dB? This is in the log domain, so at some point on the FPGA you'll need to take a logarithm of an amplitude. If it is for the user's benefit, then it is much simpler to do the conversion on the host. 1. What exact information needs to be shared? The output of the ADC is a fixed multiple of the signal at the antenna input. Since the gain settings are controlled by the host, the host would need to calculate what the overall gain is and poke a register with a value the FPGA logic could use. Again, though, why do you need to get the actual RSSI? If you're going to use it for carrier-sense, then all you really need to do is threshold the average magnitude of the ADC output. You've already got that value calculated in rssi.v (perhaps that's a confusing name for the Verilog file.) The only downside of rssi.v output is that the time constant for averaging is fixed (to make the logic very simple, fast, and low-area.) 2. Where can we get the information? I'm assuming when the daughterboards are initialized most of this information is available. It would be different for each daughterboard, but code could be added to the host daughterboard handling code to determine the overall antenna to ADC gain when the gain settings are set by the user. That overall gain value would then be poked into a register on the FPGA to be used by your code to get actual antenna power (assuming you still really need to do this.) Finally, for an AGC, the power measurement portion of the control loop doesn't need to be taken all the way to dB. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rssi questions
PS. We have a hacked up version of carrier sense working right now :) We're just using the C/S read register method to get a couple RSSI readings, computing an average, then writing the threshold to a register on the FPGA. The packets are then marked with a carrier sense flag, which we stole a 'mbz' bit for now, however we think that the 'rssi' bits in the first word of the header should be reused as more bits for flags, so all of the flags in the header are back to back. Leo already hacked up the FPGA code, checks the RSSI value and the threshold, and only transmits when the RSSI < threshold. We've verified this over the air already :D - George George Nychis wrote: Eric, we want feedback from you on this one :) I think you're right Jonathan, for performing carrier sense in the FPGA, we really do not need it in dB. Calculating the average to determine a threshold will get the job done with less the hassle. And right, if the host really wants it in dB, it can do the conversion. So here is what I want feedback on... how to communicate the RSSI to the host. What we figure is that the host should determine the threshold, in other words calculate the average and write it to a register that the FPGA can read. This saves the floating point computation on the FPGA, and the host can decide how many RSSI samples it wants to compute the threshold on. But, we've already determined that the 6-bits in the header are not enough for properly reading the RSSI from the FPGA. So, what do we want to do about this? We can store the RSSI in a register and read from it using C/S packets, then compute the average. This gives the full 32-bits. However, I still think it would be useful for each packet to contain an RSSI reading. I'm sure others would put use to this in the future. I propose adding a 32-bit RSSI field to the packet header. This doesn't even incur 1% overhead, it's ~.7% additional overhead per packet. Then with the higher bandwidth of USRP2, it's going to become even more insignificant. - George Johnathan Corgan wrote: George Nychis wrote: We want to compute the RSSI in dB on the FPGA, we're not even interested in the FPGA responding back with the RSSI at this point. Okay, but--why do you need units of dB? This is in the log domain, so at some point on the FPGA you'll need to take a logarithm of an amplitude. If it is for the user's benefit, then it is much simpler to do the conversion on the host. 1. What exact information needs to be shared? The output of the ADC is a fixed multiple of the signal at the antenna input. Since the gain settings are controlled by the host, the host would need to calculate what the overall gain is and poke a register with a value the FPGA logic could use. Again, though, why do you need to get the actual RSSI? If you're going to use it for carrier-sense, then all you really need to do is threshold the average magnitude of the ADC output. You've already got that value calculated in rssi.v (perhaps that's a confusing name for the Verilog file.) The only downside of rssi.v output is that the time constant for averaging is fixed (to make the logic very simple, fast, and low-area.) 2. Where can we get the information? I'm assuming when the daughterboards are initialized most of this information is available. It would be different for each daughterboard, but code could be added to the host daughterboard handling code to determine the overall antenna to ADC gain when the gain settings are set by the user. That overall gain value would then be poked into a register on the FPGA to be used by your code to get actual antenna power (assuming you still really need to do this.) Finally, for an AGC, the power measurement portion of the control loop doesn't need to be taken all the way to dB. ___ 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] rssi questions
George Nychis wrote: > I think you're right Jonathan, for performing carrier sense in the > FPGA, we really do not need it in dB. Calculating the average to > determine a threshold will get the job done with less the hassle. You may want to implement two thresholds, one for rising power and one for falling (hysteresis), to avoid "switch bounce" when the power is right at the threshold. > ...and the host can decide how many RSSI samples it wants to compute > the threshold on. If you implement an FPGA block to calculate the trailing-"n" sample average, you'll need to use memory to store the samples in a ring buffer. Much more efficient is to implement an exponential averager, which only needs to keep track of the previous averager output. (This is what the existing rssi.v does.) If the time constant (~16 us) is not correct for what you need, you can either modify the hardcoded shift, or implement a programmable shifter. That would at least let the user have some selection from a small number of fixed values. To make a completely generic one, you'd have to use two multipliers, which the USRP1 doesn't have (but the USRP2 will.) -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fg.run() doesn't return if gr.head() is used
Dawei Shen wrote: > BTW: Eric, you mentioned the gr_udp_source, I am quite interested in it, > is there any example in the svn using this block? If so, please point > some of them to me. Thanks. See gnuradio-examples/python/hier/networking. These use the new-style flowgraph code, but you can see the instantiation of gr.udp_source and _sink and how they are used. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Receiving USRP bits in c++ (no blocks needed)
If you're still interested, I'm about to upload a pure C++ Oscilloscope that I wrote to Sourceforge that does exactly what you're looking for, for the Basic TX and RX daughterboards only. It's pretty straightforward. The only problem you'll have is that with other daughterboards, you'll have to do more to tune them than simply setting the center frequency, and the code to do that is only accessible by Python, as far as I know. Tuning each daughterboard requires specific knowledge of the hardware. I'd hold off on trying to implement that until the 3.2 release, as others have mentioned. Code to follow shortly. -Ian Larsen On 8/13/07, Chris Stankevitz <[EMAIL PROTECTED]> wrote: > Does anyone have an example application that grabs data from the USRP > (say Basic RX) and is entirely in c++? I don't need GR blocks, just the > bits please. > > Thanks, > > Chris > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- My PGP Public Key: http://www.scrapshark.com/pubkey.txt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Receiving USRP bits in c++ (no blocks needed)
Ian Larsen wrote: If you're still interested, I'm about to upload a pure C++ Oscilloscope that I wrote to Sourceforge that does exactly what you're looking for, for the Basic TX and RX daughterboards only. Ian, I would love to have this!! Greg H. put a C++ DBSRX driver on the patches mailing list which I will incorporate into whatever you have. Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Block example that processes on another thread
Can anyone direct me to a block that does its processing on a separate thread (i.e. other than the thread that calls gr_sync_block::work) Thanks, Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Recovering x(t) from IQ samples
If my i(t) and q(t) samples are defined as follows: i(t) = x(t) * sin(wt) q(t) = x(t) * cos(wt) then, given i(t) and q(t), I can recover the magnitude of x(t) as follows: |x(t)| = sqrt(i^2(t) + q^2(t)) But how can I recover the sign of x(t)? For each of the four possible combinations of the signs of i(t) and q(t), x(t) could be either positive or negative. Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Recovering x(t) from IQ samples
I supposed I can reconstruct a virtual local oscillator by looking at the zero crossings and syncing a sine generator to that and then using the sine generator to determine the sign (making it a sign generator ;-P). Then my entire waveform might be inverted, but that is probably not much of a concern (at least for my needs). Please tell me there is a better way. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Bahn William L Civ USAFA/DFCS > Sent: Thursday, August 16, 2007 5:57 PM > To: discuss-gnuradio@gnu.org > Subject: [Discuss-gnuradio] Recovering x(t) from IQ samples > > If my i(t) and q(t) samples are defined as follows: > > i(t) = x(t) * sin(wt) > q(t) = x(t) * cos(wt) > > then, given i(t) and q(t), I can recover the magnitude of x(t) as follows: > > |x(t)| = sqrt(i^2(t) + q^2(t)) > > But how can I recover the sign of x(t)? For each of the four possible > combinations of the signs of i(t) and q(t), x(t) could be either positive > or negative. > > Thanks. > > > ___ > 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
