Re: [Discuss-gnuradio] MAC layer development and USRP2
Think of it this way... MAC *development* is severely limited by GNU Radio... it lacks the much-needed functionality to make information passing between the blocks rich, simple, and bi-directional. Some of the building blocks are in place (e.g., PMT), and the m-block was implemented to solve the rest of the problems, but was deprecated (maybe removed as of now?). MAC *performance* is limited by several things: 1) delay between GNU Radio and the USRP/USRP2, 2) signal processing delay (GNU Radio), and (3) jitter (e.g., unpredictable delay) ... (1) is reduced a little by USRP2 using GigE, but it's still not down to traditional MAC turnaround times (10s of us). (2) benefits from Moore's law. (3) kind of depends on whether you use realtime scheduling and how your data hits delays in queues mainly. All in all... still an open problem IMO. - George On Sun, Mar 14, 2010 at 5:06 PM, Charles Irick wrote: > I've been reading some papers related to MAC layer development on the > USRP, but they seem to have tapered off with the USRP2. Does anyone > have any information about MAC layer and protocol development for the > USRP2. Has this been satisfied with things like timestamps and gigE? > Any current papers or web links related to USRP2 protocol level > development? Thanks. > > Charles > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MAC layer development and USRP2
I've been reading some papers related to MAC layer development on the USRP, but they seem to have tapered off with the USRP2. Does anyone have any information about MAC layer and protocol development for the USRP2. Has this been satisfied with things like timestamps and gigE? Any current papers or web links related to USRP2 protocol level development? Thanks. Charles ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] LFRX boards at low-VHF frequencies
On Fri, 2010-03-12 at 14:12 -0500, Marcus D. Leech wrote: > Has anybody on-list had experience using the BASIC_RX or LFRX boards at > low-vhf frequencies > (30-50MHz)?? BasicRX works when you add a corresponding bandfilter and a LNA. Note however that the first niquist frequency is at 32 Mhz with a default USRP1 with a 64 MHz ADC clock. So signals above 32 Mhz will fold around to stations below 32 Mhz. You can remove this effect with a bandfilter, but you need some cutting space to do this. With a very tight filter you can do about 98-126 Mhz or 66-94 Mhz or 34 - 62 Mhz or 0 - 30 Mhz. But around the niquist freqs itsself +/- 32 Mhz +/64 MHz, +/- 96 Mhz is not possible. If you use a different clockfreq for the ADC you can change the niquist freq. The USRP2 for example uses a 100 MHz ADC clock. With this you can do about 0 - 48 Mhz wit a tight lowpass filter. Running the USRP1 at 56 MHz will give you around 30 - 54 Mhz or 0 - 26 Mhz with the right bandfilters. You can easily check this by running usrp_WFM_rcv.py on the commercial FM band with a basicRX daughterboard. Note that there is a niquist freq at 96 Mhz with the default clock ( 64 Mhz). So if you leave out the bandfilter the stations above 96 Mhz fill fold around on top of the stations below 96 Mhz. I use a programmable clockgenerator with a USRP1 for experiments like this. I haven't tried with LFRX. These use diffential amplifiers which have a limited bandwidth. They will probably work up to 50 Mhz but not much above that. BasicRX works up to around 200 MHz. But also note that the higher the frequency, the lower the sensitivity and the higher the phasenoise. > > I have a potential science project that could usefully be implemented in > that frequency range. Cheers, Martin > > Cheers > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bpsk lost some packet when transmit data discontinuously
Tom, It is really what you are said. After I transmitted packet several times, I got the probability of 1/2 that correctly received packet and probabilty of 1/2 that got nothing. I think this result is explicit when I change the carrier frequency from 900M Hz to 2.4G Hz. It is my fault. I thought that it will work like a bpsk if I removed the differential encoder/decoder from dbpsk.py. But I haven't do the channel estimation to get the correct phase rotation. Did anyone try to implement the channel estimation into gnuradio? I find that at the gr_mpsk_receiver_cc block there is a parameter theta that pass into this block. In dbpsk the theta is set to 0. Is it correct that I pass the phase rotation from the channel estimation? If is, how do I do the channel estimation before the synchronization...there are two samples/symbol before the gr_mpsk_receiver_cc block. Sorry for I first contact with software defined radio. And I really don't have a complete concept of the transmission structure when it involves synchronization and channel estimation. Fisheep Tom Rondeau wrote: > > On Tue, Mar 9, 2010 at 3:03 AM, Fisheep wrote: >> >> Hi: >> >> I have some problem about dbpsk and bpsk using benchmark_tx/rx.py with >> some >> modification. >> >> My experiment set up was that the transmitter waits for a time delay (0.5 >> s) >> after sending a packet. >> It means that we transmit data discontinuously. >> >> If we using dbpsk modulation, we can successfully receive every packet. >> But if we removed the differential encoder/decoder (equals to bpsk >> modulation), we uaually >> lost some packet (almost half of the data lost). >> >> However, when we transmit data continuously,the bpsk modulation seems >> work >> fine and we can successfully receive every packet. >> >> My problem is that what reason causing the bpsk modulation can not >> successfully receive packet when >> transmit data discontinuously. >> >> Could anyone have any idea about it, please let me know. >> I am deeply appreciative. >> >> Fisheep :) > > > Fisheep, > > I'm wondering how you are compensating for the phase ambiguity of the > BPSK signal in the receiver? In the current DBPSK, there is no method > to properly rotate the constellation because the differential encoding > doesn't care. If you are just transmitting BPSK, you'll have a 180 > degree phase ambiguity in the receiver. If that's the case, then for > every burst of a packet, when the receiver locks to the constellation, > it will be in one of two phase rotations, one which works and one > which inverts every symbol. They should be distributed with equal > probability, so half of the time you'll have the correct rotation and > the other half you won't. > > When you transmit continuously, I would expect that you'll also see > the same behavior. If you've got the right rotation, you'll receive > every packet. Otherwise, you'll see nothing. Does that happen > sometimes? > > Tom > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/bpsk-lost-some-packet-when-transmit-data-discontinuously-tp27832481p27893508.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
