Re: [Discuss-gnuradio] Interest in beamforming and GNSS receivers
Thank you very much for your informative responses. Now things are clearer to me: the possibility of building an antenna array combining two or more USRPs is just exciting! I'm also delighted with the option of using an external reference clock. I definitely will buy at least one USRP for the first experiments and the development of a simple GPS receiver. If my progress is adequate, I will go for the multi-antenna approach. I will keep you informed, and surely I will come often with new questions. Thanks again for those great sources of information, I'm really enjoying while exploring them. Cheers, Carles. On Jan 31, 2008 10:33 PM, Martin Dvh <[EMAIL PROTECTED]> wrote: > Pavol Ďuriš wrote: > > Hi all, > > > > I have an interest in radioastronomy. I plan to make simple beamforming > > phase array (primary with 4 and later with 8 antennas) with USRP (later > > with 2) and GNU Radio. I am inspired by LOFAR radiotelescope. > > Now I collect all available information about using GNU Radio and USRP > > for it. > > > > Martin, could you send more information about your solution, project > > (url etc.) ? > > Info about connecting murli-USRPs: > http://gnuradio.org/trac/wiki/MultiUsrp > http://gnuradio.org/trac/wiki/USRPClockingNotes > > http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-examples/python/multi_usrp > This last one is also in your gnuradio source directory: > gnuradio-examples/python/multi-usrp > > It has been a while since I last used this setup, so there might be some > bitrot. > (incompatibilities between the multi-usrp fpga firmware (rbf-file) and the > latest gnuradio code and support for the latest daughterboards.) > But if this is the case then it should be solvable by implementing the > latest changes to the standard USRP firmware to the multi-USRP firmware. > > > There is not much info about my phase-array experiments online. > I know, I should update my website more often, but I am better at writing > code then at writing human-readable text. > I do haver a snapshot of my CMA (Constant Modulus Algorithm) adaptive > phase-array code. > This code automatically adapts to multiple FM, GMSK, QPSK or M-PSK > sources. > It should be able to extract multiple sources on the same frequency by > automatically nulling the other sources out when extracting one. > (max number of sources == number of antenna's used) > > Note that this code only works with phase-coherent daughterboards (boards > which use the USRP-clock as refclock) > This means allmost all daughterboards except TVRX. > (Which is too bad since I want to extract multiple broadband FM stations, > for now I use undersampled basicRX) > The code is at: > http://www.olifantasia.com/projects/gnuradio/mdvh/CMA_phase_array/ > > Other code of mine can be found at: > http://www.olifantasia.com/projects/gnuradio/mdvh/ > or > http://gnuradio.org/trac/browser/gnuradio/branches/developers/nldudok1 > or (when it has stabalized) in GnuRadio trunk > > Greetings, > Martin > > > Thanks, > > Pavol > > > > PS: I haven't USRP yet. However, I am buying my first USRP, right now :) > > > > Martin Dvh wrote: > >> Carles Fernandez wrote: > >> > >>> How well are they synchronized? > >>> > >> They run off the same 64 MHz clock, so are synchronised. > >> I have even used two connected USRPs running of the same clock (one is > >> master and exports its clock to the slave USRP) > >> (You use an additional flatcable between the USRPS and an align > >> software block in gnuradio which aligns the samples) > >> This gives you 8 ADCs. This means 8 real channels or 4 complex > channels. > >> > >> I used this setup for a phase array with 4 DBSRX daughterboards. > >> (DBSX daughterboards use complex sampling so they need two ADCs) > >> DBSRX boards also support the GPS frequencies and are a lot cheaper, > >> so you might want to consider them. > >> But they are receive only. > >> > >> You can even go higher and connect 4, 8 or 16 USRPS. > >> > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] More Interest in Beam Forming/Adaptive Beam Forming
I am also interested in beam forming from a different angle. I have a 4-element DX Engineering Phased array set up primarily for the 1.8 MHz and 3.5 MHz ham bands that I want to convert to a more flexible digitally controlled array using the USRP. Does anyone have any phased array software running that might be useful to help get me going? I am starting to use the multi-file example program to acquire data that I can analyze in MATLAB to test out ideas. Dick (K4IQJ)... ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interest in beamforming and GNSS receivers
Pavol Ďuriš wrote: > Hi all, > > I have an interest in radioastronomy. I plan to make simple beamforming > phase array (primary with 4 and later with 8 antennas) with USRP (later > with 2) and GNU Radio. I am inspired by LOFAR radiotelescope. > Now I collect all available information about using GNU Radio and USRP > for it. > > Martin, could you send more information about your solution, project > (url etc.) ? Info about connecting murli-USRPs: http://gnuradio.org/trac/wiki/MultiUsrp http://gnuradio.org/trac/wiki/USRPClockingNotes http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-examples/python/multi_usrp This last one is also in your gnuradio source directory: gnuradio-examples/python/multi-usrp It has been a while since I last used this setup, so there might be some bitrot. (incompatibilities between the multi-usrp fpga firmware (rbf-file) and the latest gnuradio code and support for the latest daughterboards.) But if this is the case then it should be solvable by implementing the latest changes to the standard USRP firmware to the multi-USRP firmware. There is not much info about my phase-array experiments online. I know, I should update my website more often, but I am better at writing code then at writing human-readable text. I do haver a snapshot of my CMA (Constant Modulus Algorithm) adaptive phase-array code. This code automatically adapts to multiple FM, GMSK, QPSK or M-PSK sources. It should be able to extract multiple sources on the same frequency by automatically nulling the other sources out when extracting one. (max number of sources == number of antenna's used) Note that this code only works with phase-coherent daughterboards (boards which use the USRP-clock as refclock) This means allmost all daughterboards except TVRX. (Which is too bad since I want to extract multiple broadband FM stations, for now I use undersampled basicRX) The code is at: http://www.olifantasia.com/projects/gnuradio/mdvh/CMA_phase_array/ Other code of mine can be found at: http://www.olifantasia.com/projects/gnuradio/mdvh/ or http://gnuradio.org/trac/browser/gnuradio/branches/developers/nldudok1 or (when it has stabalized) in GnuRadio trunk Greetings, Martin > Thanks, > Pavol > > PS: I haven't USRP yet. However, I am buying my first USRP, right now :) > > Martin Dvh wrote: >> Carles Fernandez wrote: >> >>> How well are they synchronized? >>> >> They run off the same 64 MHz clock, so are synchronised. >> I have even used two connected USRPs running of the same clock (one is >> master and exports its clock to the slave USRP) >> (You use an additional flatcable between the USRPS and an align >> software block in gnuradio which aligns the samples) >> This gives you 8 ADCs. This means 8 real channels or 4 complex channels. >> >> I used this setup for a phase array with 4 DBSRX daughterboards. >> (DBSX daughterboards use complex sampling so they need two ADCs) >> DBSRX boards also support the GPS frequencies and are a lot cheaper, >> so you might want to consider them. >> But they are receive only. >> >> You can even go higher and connect 4, 8 or 16 USRPS. >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio C++ engineer wanted
On Jan 31, 2008 12:52 PM, Jeff Brower <[EMAIL PROTECTED]> wrote: > Maybe you're right, it's inevitable. But I don't think it helps the cause > of GNU > radio at government agencies... I for one would be far more interested in using gnuradio to *spoof* the surveillance. That would really endear the gnuradio community to the agencies, wouldn't it? ;-) Frank -- The only thing we have to fear is whatever comes along next. -- Austin Cline ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interest in beamforming and GNSS receivers
Carles Fernandez wrote: Hi everybody, I discovered GNU Radio few months ago, in a before-go-to-bed surfing. I found it very interesting, but complicated because of my poor skills in programming Python or C++. I'm doing research on Global Navigation Satellite Systems (GNSS) receivers, and I'm used to code everything in Matlab. Night after night, I've been browsing the documentation and making humble steps: I installed Ubuntu on my laptop, followed the -excellent, also for dummies like me- guide for installing all the software, read diagonally the documentation and played with sample codes. Some Hello Worlds, some problems with the audio module, getting used to read the mailing list, feeling astonished by the intense activity of this community... nothing new, I guess. Now I want to take it more seriously. I've seen that both python and c++ have very well done matrix algebra libraries, and that's exactly what I need for my research (you can call me naive). I would like to implement a GNSS receiver (in the wide sense) based on an antenna array and play with beamforming algorithms and weird RF front-end architectures (direct RF, IF sampling, etc). My main concern is synchronization, concretely I want to implement some signal processing algorithms in a real receiver in order to assess their impact in the whole system, testing them with real data. I've been working in the development of some algorithms that -theoretically- performs better in multipath environments, but I want to see if this is true beyond classical academic benchmarks. What is the state of GNSS receivers development in GNU Radio? I have found some expressions of interest in the Internet, but nothing concrete. I'm willing to start it from the scratch, but it is nonsense to reinvent the wheel. I would like to put in contact with other people interested on these topics. Taking advantage of your patience, I have some other questions (and you will see my newbie approach): - I've seen some statements about "beamforming is possible". To what extend? I'm trying to understand the multi-antenna code example, but it is possible to use the four ADC at the same time? How well are they synchronized? it is possible to compute the weight values in software and perform the multiplication in the FPGA at real time? There is any other major bottleneck than algebraic weight computation time? - My first target is a "traditional" L1 C/A code GPS receiver. I guess that I can choose between RFX1200 and a BasicRx with an external front-end. Have someone worked in the connection of GNU Radio with gpstk? - It is 32 MHz the maximum bandwidth available? Will the USRP 2.0 increase this bandwidth? It is possible to decrease the resolution of the ADCs and/or increase their sampling frequency? - I also would like to work on the Galileo signal structure and the new L2CS GPS signal, mostly on the correlators. I have a background on signal processing, but I'm strongly matlab-shaped in what about programming is concerned. I'm willing to learn, but am I pointing to the right direction? If someone could enlighten me in some of this questions, it would be greatly appreciated. Sorry for the long text. Best regards, Carles Fernandez Carles, I'm just announcing my presence on the list: I'm the graduate research assistant at Purdue University in charge of GNU Radio efforts, including applications for GNSS. We are in a fairly early stage of development, but I watch the GNU Radio list, and I'd be happy to hear about your progress. --Paul Creekmore ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help generating frequency offset
George Nychis wrote: Hi all, I'm attempting to generate frequency offset in a script that is adding some channel features: http://cyprus.cmcl.cs.cmu.edu/matched_filter/gen_noise_samples.py The frequency offset is specified, for which the original signal is mixed and then the offset signal is added with the noise. But I'm not seeing the appropriate frequency offset. If I specify a frequency offset of 100Hz, I'm only seeing a single point shift, all other points are the same as if there is no offset: http://cyprus.cmcl.cs.cmu.edu/matched_filter/graphs/freq_offset.jpg I'm not sure what you have plotted in that picture. Is that just the raw samples? Can you write out to a file both the 2 inputs to the mixer and the 1 output? Then do an FFT on all 3 in octave to make sure the frequency has really moved as you expected. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] help generating frequency offset
Hi all, I'm attempting to generate frequency offset in a script that is adding some channel features: http://cyprus.cmcl.cs.cmu.edu/matched_filter/gen_noise_samples.py The frequency offset is specified, for which the original signal is mixed and then the offset signal is added with the noise. But I'm not seeing the appropriate frequency offset. If I specify a frequency offset of 100Hz, I'm only seeing a single point shift, all other points are the same as if there is no offset: http://cyprus.cmcl.cs.cmu.edu/matched_filter/graphs/freq_offset.jpg I'd greatly appreciate any feedback. Thanks! George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem setting transmit gain values....
On Thu, 2008-01-31 at 11:33 -0800, Matt Ettus wrote: > Kshitij Kumar Singh wrote: > > Hi, > > > > I tried out a simple script to get the gain range of the USRP (I had read > > in earlier mail archive > > that we were provided a single gain knob to tune over the entire range of 0 > > to 90 dB): > > > > There is no gain control on transmit with the RFX boards. There is 90dB > of gain range on the RECEIVE side. > > To change transmit power, you need to lower the level of the signal you > send. So +/-32767 is max power, +/-16383 is 6dB less power, +/-8192 is > 12 dB less power, etc. > > Matt Thanks Matt .. I was just trying out things by myself after reading usrp_siggen.py and got had these few doubts. I had another question regarding the 'u.tune()' method. Let me explain my problem. I tried generating a sinusoid at 2.39G. I got a DUC frequency of -43M. The tuning results were: Baseband: 2.396G, DUC freq = -6M. I understand that since we use an IF, our LO on the RFX board was tuned to 2.396G ( goes from 2.3 to 2.7G in steps of 4M), the IF came in at around 6M so we got 2.396+0.006 and 2.396-0.006 and chose the latter. Is this correct? But what about the -43M from usrp.calc_dxc_freq() ? I also tried transmitting at 2.396+6= 2.402G but then the tuning results were: Baseband:2.408,DUC=-6M. Why always a negative DUC freq(why not 2.396 +0.006)? Could you please explain this "tuning is a two step process" using a small numerical example? Thanks in advance and sorry for bugging you guys constantly. I tried reading usrp.py but got confused. Regards, Kshitij ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmitting and Receiving Simple Sinosoidal singal over RFX2400 board
On 1/31/08, Patel, Tushar P <[EMAIL PROTECTED]> wrote: > The question that I have is that when I send the signal is there a default > modulation taking place. If yes then what is it? If not then what options do > I have for sending the signal and receiving the signal? Are you using the usrp_siggen.py example script? If so, pass -w0, to set the modulation frequency to zero. Then you will just see a carrier. Otherwise, you'll need to tell us more about what you are doing to send and receive. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Transmitting and Receiving Simple Sinosoidal singal over RFX2400 board
I am attempting to transmit a simple sinusoidal signal generated by GNU radio. The signal would be transmitted by RFX 2400 connected to one computer and the transmitted signal would be received by RFX2400 connected to another computer. Basically the signal would be sent wirelessly from one computer to the other. The question that I have is that when I send the signal is there a default modulation taking place. If yes then what is it? If not then what options do I have for sending the signal and receiving the signal? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem setting transmit gain values....
Kshitij Kumar Singh wrote: Hi, I tried out a simple script to get the gain range of the USRP (I had read in earlier mail archive that we were provided a single gain knob to tune over the entire range of 0 to 90 dB): There is no gain control on transmit with the RFX boards. There is 90dB of gain range on the RECEIVE side. To change transmit power, you need to lower the level of the signal you send. So +/-32767 is max power, +/-16383 is 6dB less power, +/-8192 is 12 dB less power, etc. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem setting transmit gain values....
Hi, I tried out a simple script to get the gain range of the USRP (I had read in earlier mail archive that we were provided a single gain knob to tune over the entire range of 0 to 90 dB): - from gnuradio import gr, usrp u = usrp.sink_c(0) subdev = usrp.selected_subdev(u, (0,0)) #I use an RFX 2400 subdev.gain_range() - I get the following (0.0, 0.0, 1.0). This doesn't make sense. I even actually tried setting the gain to subdev.gain_range()[1]/subdev.gain_range()[0], but was still transmitting at a constant power level of around 11-12 dBm. Could someone please help me out with this. Thanks in advance. Regards, Kshitij ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Combining gr.trellis and mod_pkt
On Thu, Jan 31, 2008 at 10:49:50AM -0500, Steven Clark wrote: > Pardon the bump. Maybe I should simplify the question: > > With the packet modulator, is it possible to run the packet payload > bits through any kind of flow-graph/block during the rx_callback? Yes. You could push the bits back into a message source, do what you like, and suck them back out of a message sink. No need for a separate flow graph, just more blocks (The top_block code currently has an implementation limitation that allows only a single top_block.) Eric > On Jan 27, 2008 6:39 PM, Steven Clark <[EMAIL PROTECTED]> wrote: > > 'lo all. > > > > I would like to place code in the rx_callback of the packet mod > > architecture that takes each received payload and runs it though > > gr.trellis's viterbi decoder. > > Should this be possible? > > > > It seems like I'd have to set up, run, and tear-down a flowgraph or > > top-block in the duration of the callback. But wouldn't this interfere > > with the top-block/flowgraph that was already existing for the packet > > demod framework? > > > > Any thoughts? > > > > -Steven ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio C++ engineer wanted
Eric- > On Thu, Jan 31, 2008 at 09:13:48AM -0600, Jeff Brower wrote: > > Toby- > > > > > I hope no one minds me putting this up here: > > > > I took a look at the Path Intelligence website. It's actually the case > > that you > > would track individuals to within a few meters using their cellphones > > without their > > knowledge? What about privacy concerns? It's one thing to be monitored by > > security > > video in "expected" places (entrances, store isles, ATMs, etc), it's > > another to be > > tracked. > > > > With GSM, at least as far as the specs read, you wouldn't expect > personally identifiable information in the clear. You would expect to > be able to see a TMSI (temporary mobile subscriber ID). Now, like > many big systems, what's on the air, and what's in the specs may > differ. > > From a reality-based point of view, if you are carrying a cell phone, > and it's powered up, you are in fact carrying a locator device. How > do you suppose they make your phone ring? > > There is a reason some folks prefer pagers. > > You may enjoy reading up on the "Enhanced 911 System" E-911. It > mandates that cell phones in the US be locatable to within X meters > under particular conditions. There are two obvious ways this can be > done: (1) your phone has a GPS receiver (or part of a GPS receiver) in > it and thus has to cooperate to reveal your location, or (2) some kind > of third party geolocation system is used to locate you without your > phone's overt cooperation. The E-911 stuff was passed under the "If > it saves only one person's life..." rationale. For additional fun, > dig up the testimony of the FBI director during the CALEA procedings. > Basically he said, "We don't want the location info, just the call > setup info." A cynic might say he got what he "didn't want" by way of > the E-911 "safety" regulations. > > Don't want to be tracked? Don't use a cell phone. Thanks yes we know this, it's beside the point. The point I raise is privacy concerns, tracking by people for purposes of knowing your personal habits -- not to save your life when you do dial 911. For example commercial entities who want to know your buying habits regardless of whether you manually dial a number, click on a web page, etc. I don't really care myself... nevertheless, it's along the lines of the Beacon thing that bit Facebook. Many people are / would be "surprised" to find out someone else knows what they bought, where they went, etc. when they didn't expect it. Maybe you're right, it's inevitable. But I don't think it helps the cause of GNU radio at government agencies for people to be using it for such purposes. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio C++ engineer wanted
On Thu, Jan 31, 2008 at 09:13:48AM -0600, Jeff Brower wrote: > Toby- > > > I hope no one minds me putting this up here: > > I took a look at the Path Intelligence website. It's actually the case that > you > would track individuals to within a few meters using their cellphones without > their > knowledge? What about privacy concerns? It's one thing to be monitored by > security > video in "expected" places (entrances, store isles, ATMs, etc), it's another > to be > tracked. With GSM, at least as far as the specs read, you wouldn't expect personally identifiable information in the clear. You would expect to be able to see a TMSI (temporary mobile subscriber ID). Now, like many big systems, what's on the air, and what's in the specs may differ. >From a reality-based point of view, if you are carrying a cell phone, and it's powered up, you are in fact carrying a locator device. How do you suppose they make your phone ring? There is a reason some folks prefer pagers. You may enjoy reading up on the "Enhanced 911 System" E-911. It mandates that cell phones in the US be locatable to within X meters under particular conditions. There are two obvious ways this can be done: (1) your phone has a GPS receiver (or part of a GPS receiver) in it and thus has to cooperate to reveal your location, or (2) some kind of third party geolocation system is used to locate you without your phone's overt cooperation. The E-911 stuff was passed under the "If it saves only one person's life..." rationale. For additional fun, dig up the testimony of the FBI director during the CALEA procedings. Basically he said, "We don't want the location info, just the call setup info." A cynic might say he got what he "didn't want" by way of the E-911 "safety" regulations. Don't want to be tracked? Don't use a cell phone. Eric Today's meditation: If your cell phone is "off" and it's got a battery in it, is it really "off"? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Shielding on 2.4GHz
Martin Dvh wrote: > > > It might pick it up on the 6V power cable. > You could try putting ferrite beads around the power cable to reduce this. > > greetings, > Martin > > Thanks for your suggestion. I removed a ferrite bead from my USB cable and put it on the power cable. Tested it again. The interference was still there. I suspect the interference goes to the d'b directly, becasue when I use the enclosure and metal box to cover the d'b, the interference decreases dramatically. But those cannot reduce the interference low enough for our test. Maybe we just need a M1A1 tank. Best -DX -- View this message in context: http://www.nabble.com/Shielding-on-2.4GHz-tp15072399p15207372.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Combining gr.trellis and mod_pkt
Pardon the bump. Maybe I should simplify the question: With the packet modulator, is it possible to run the packet payload bits through any kind of flow-graph/block during the rx_callback? On Jan 27, 2008 6:39 PM, Steven Clark <[EMAIL PROTECTED]> wrote: > 'lo all. > > I would like to place code in the rx_callback of the packet mod > architecture that takes each received payload and runs it though > gr.trellis's viterbi decoder. > Should this be possible? > > It seems like I'd have to set up, run, and tear-down a flowgraph or > top-block in the duration of the callback. But wouldn't this interfere > with the top-block/flowgraph that was already existing for the packet > demod framework? > > Any thoughts? > > -Steven > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio C++ engineer wanted
Toby- > I hope no one minds me putting this up here: I took a look at the Path Intelligence website. It's actually the case that you would track individuals to within a few meters using their cellphones without their knowledge? What about privacy concerns? It's one thing to be monitored by security video in "expected" places (entrances, store isles, ATMs, etc), it's another to be tracked. Open source radio software already has run into resistance at the FCC, not a good thing. In my opinion, applications like this may not help and could fuel naysayers inside the government. They are likely to ask... if you can do it, then who else can? -Jeff > Path Intelligence Ltd is a multiple award winning start-up company, > whose most recent achievement is winning the UK SEEDA Enterprise Hub > Showcase event, ahead of more than fifty other innovative start-ups from > Oxford and the broader South East region. Although our operations have > been historically based in the UK we are looking to broaden into other > territories (particularly the US as we have recently closed a round of > funding with a Silicon Valley based VC). > > As a Principal Engineer, you will: > > o Re-architect the system to prepare for upcoming enhancements > o Optimize the existing C++ code base > o Assist the existing management team to continue to build the technical > team both in the UK and the US > o Work closely with the CEO to complete product development and > implement new research initiatives > o Help shape the future of Path Intelligence Ltd > o Work with a young, energetic and ambitious team > o Receive an attractive remuneration package > > The following skills are essential: > > o Expert C++ skills > o Solid understanding of RF > o Ability to formally communicate architectural designs and plans > o Proven team working experience, within teams consisting of both > technical developers and non-technical project/business owners > (experience in working with remote teams a bonus) > o Experience integrating open source technologies in application development > o Proven problem solving skills > o Self Starter > > Desired skills: > > o Proficiency in Python > o Knowledge of RF location techniques > o Experience in working on software defined radio projects and/or Gnuradio > o Knowledge and experience with RF and FPGA hardware development > > About Path Intelligence: > > Path Intelligence has developed an innovative product using software > defined radio, that is able to locate mobile phones highly accurately > within a confined area. In the first instance Path Intelligence is using > this technology to provide shopping centres and mass transit stations > with information on people flow through their space. However, this is > just the tip of the iceberg of what is possible with this technology and > Path Intelligence has plans to move into many different industries, > applications and geographies. > > Path Intelligence has recently concluded a funding round with a Silicon > Valley venture capital firm that focuses on leading edge technologies > and plans to aggressively expand into the US and Europe in the near future. > > At Path Intelligence, our goal is to provide the most timely and > accurate location information available.To that end, we strive very hard > to hire the smartest people. Weâre an environment where great ideas > shape our vision and true passion drives us to the best solutions to the > most challenging problems. > > Salary: Competitive + Benefits, with the potential for equity > Location: UK/US > Contact: Sharon Biggar ([EMAIL PROTECTED]) > Reference: GNUPATHCP ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RFX900 and Clocking Notes
Hello, I am reading the Clocking Notes in order to set up a coherent 2 antenna system. My setup is a USRP Rev 4.5 and two RFX900 daughterboards dated 3-10-2006 Step1: I want to disable the RFX900 clocks so I need to Move R64 to R84, Move R142 to R153 which looks straight forward. Step 2: To connect in the motherboard clock the notes say to Move R35 to R36, Move R117 to R115 on my board there isn't a component at R35 or R117 but there are components at R36 and R115. Is this a typo in the clocking notes? Should it read Move R36 to R35, Move R115 to R117 Or do I just need to perform Step 1 and ignore Step 2? Regards, Tomas O'Maille -- View this message in context: http://www.nabble.com/RFX900-and-Clocking-Notes-tp15202177p15202177.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
