[Discuss-gnuradio] The [hopefully] full story SD Cards
I'll attempt to summarize the SD card situation as I see it. There are 3 main reasons why you might have trouble with SD cards in your USRP2 - - You aren't actually using an SD card. SD Cards have been made in sizes from 8MB up to 2GB. Any card of more than 2 GB is NOT an SD card, it is an SDHC card. They share the same connector, but they do not support the same access modes and will not work with the USRP2. Similarly, MMC cards look the same, but are very different inside and will also not work. - You aren't programming it properly. You need root privileges to properly program the card, for one thing. Make sure the filesystem is not mounted in Linux, follow the directions here: http://gnuradio.org/redmine/wiki/gnuradio/USRP2UserFAQ - You have a bad SD card. If you were part of the unlucky group that got bad cards from us in November and December, follow the directions from here: http://www.ettus.com/flash If you bought the card somewhere else, there is nothing we can do. You could try another one, or buy a known working one from us. We sell our SD cards at a loss to encourage you to buy them from us and avoid trouble. We currently have very good luck with Kingston 2GB SD and 2 GB micro SD cards, and that is what we ship now. Patriot 2GB micro SD cards seem to be good, but recent Patriot 2GB full-size SD cards do not. Purple Sandisk 2GB cards are good, but they are also the most commonly counterfeited -- because of their good reputation they command a premium in the market. Older and smaller cards are more likely to work. = So why would some SD cards work and some not? We do not 100% understand the mechanisms behind this. It could be actual problems with the cards, or it could be in the design we use to read the cards. SD cards have many supported access methods and we use one of them, SPI. You can see the design which we put in the CPLD on the USRP2 to read from the card in the FPGA repo under usrp2/boot_cpld and usrp2/opencores/spi_boot. CPLDs are very simple devices, and it is not possible to handle all possible error or retry responses which a card might give in response to a request, and that would make it fail to boot. SD cards are normally read by a microprocessor which can handle these cases due to increased resources. Cards which don't work with USRP2s usually work in cameras, but not always. I just walked into a camera store yesterday and bought an SD card for my camera, and it doesn't work. It works in other cameras, but not mine. I don't have a USRP2 with me to test it, but the point is that not all SD cards are created equal, as Bunnie Huang and others have found: http://www.bunniestudios.com/blog/?p=918 One thing that was left out of the above analysis is the fact that these cards are made at many different factories, from parts from different manufacturers. They are also commonly counterfeited or rebadged. Sometimes a card with some bad flash will be sold as one half as large. Often is there is no way to tell the difference between 2 very different cards by looking at the packaging. The SD card business is very complex. We are unable to buy them from the manufacturers because we don't buy 100,000 or more per month. We are unable to buy them from primary distributors because we don't buy 10,000 or more per month. Instead, we have to buy them from retailers who are willing to sell them to us wholesale. We have found a reputable consistent company to get cards from. But even then, there can be problems. We shipped hundreds of blue Patriot 2 GB cards with no problems. Then all of a sudden we got a shipment with half bad (for our definition of bad) cards. There is no way to look at the card and see if it is bad or good, but the bad ones have a different chip inside. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Invitation to connect on LinkedIn
LinkedIn I'd like to add you to my professional network on LinkedIn. - Muhammad Amir Muhammad Amir Pervaiz Software Engineer at TkXel Pakistan Confirm that you know Muhammad Amir Pervaiz https://www.linkedin.com/e/isd/1119880681/bR7w_C3p/ -- (c) 2010, LinkedIn Corporation___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Invitation to connect on LinkedIn
LinkedIn I'd like to add you to my professional network on LinkedIn. - Muhammad Amir Muhammad Amir Pervaiz Software Engineer at TkXel Pakistan Confirm that you know Muhammad Amir Pervaiz https://www.linkedin.com/e/isd/1119880681/bR7w_C3p/ -- (c) 2010, LinkedIn Corporation___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rx_timed_samples.cc doesn't stop streaming of samples
Thanks a lot Josh! Adding return not done() instead of return true did work. I'm running Ubuntu in virtualbox, hence the lack of resources. Couple more questions if you don't mind: 1) Where does the number of items per packet (which is 365 in my case) comes from? Or is it the format USRP2 always uses to send the data to the host? 2) After specifying -N as 1000 I got the following output: Got packet: 1267693414 secs, 35564266 ticks Got packet: 1267693414 secs, 35570106 ticks Got packet: 1267693414 secs, 35575946 ticks So the number of ticks between the packets is 5840, dividing by 365 we get 16-the number of ticks per sample, and the decimation is 16 which is consistent. My question is: if I want to extract the timestamps for each sample individually I would need to take the timestamp of the packet and subtract the required number of 16*N (e.g. for the sample number 300 in the first packet the timestamp is 35564266-65*16=35563226) or is there a different way the get hold of timestamps for individual samples? Thank you very much for your help. Valentin Josh Blum-2 wrote: 1) I've just installed the usrp2_vrt branch and tried running rx_timed_samples.cc. No matter what number of samples i specify in the options, the program just keeps running and printing out the timestamps... Even after i press Ctrl+C the computer still continues to receive data through the ethernet port implying that the u2-stop_rx_streaming doesn't get called. Does anyone know what the problem could be? Its possible that your machine is slow enough such that it always has samples in the packet ring and no lag time for the CPU. In this case, the rx_samples call does not get a chance to return and therefore the while loop cannot get a chance to check the done condition. A remedy could be to change line 54: return true; with the following return not done(); This will cause the callback to return false when done, so that rx_samples with exit and the loop condition will be checked. This is due to a false assumption on my part, let me know if that change fixes it for you. 2) Could anyone please clarify what nitems means in the following line of the handler in rx_timed_samples.cc: operator()(const uint32_t *items, size_t nitems, const vrt::expanded_header *vrt_header) Its a callable object. An instance of it gets created and passed into u2-rx_samples(my_handler); As far as I can see from the code, d_num_samples gets incremented by nitems every time rx_samples is called and then is comparared whith d_max_samples implying that nitems is the number of samples received. But nitems is always 365,hence d_num_samples gets incremented in step of 365, therefore is it correct that one can receive only a number of samples which is a multiple of 365? Hence what's the point in specifying 1000 as a number of samples to receive? 1000 is an arbitrary number. If the actual number of items per packet is 365, then it should take 3 receives to have more than 1000 samples, and the program should be done. -Josh ___ 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/rx_timed_samples.cc-doesn%27t-stop-streaming-of-samples-tp27771324p27780844.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
Re: [Discuss-gnuradio] The sinusiodal waveform is drifting from input to output.
On Wed, Mar 3, 2010 at 1:06 PM, Johnathan Corgan jcor...@corganenterprises.com wrote: On Wed, Mar 3, 2010 at 03:26, srinivas naga vutukuri srinivas.vutuk...@gmail.com wrote: I am transmitting the sinusoidal wave form (IQ samples), in the following methods, and found that when i stem plot in the MATLAB both the input wave form data on one USRP2 and the received data on another USRP2, initially the waveform is exactly fitting (i mean overlapping), and after certain samples, it starts ie., in the input wave form and the output data waveform drifting slightly and at the end samples both the waveforms overlaps perfectly. Why this slight drifting is happening when transmitting the I Q samples from one USRP2 to another USRP2. This is almost certainly due to receiver frequency and timing drift between transmitter and receiver USRPs. It's a fact of life in real-world radio systems, requiring significant design effort to compensate for; you're seeing exactly what you should expect to see. The digital demodulators in GNU Radio typically use DSP blocks like Costas loops for frequency/phase synchronization and MuellerMueller timing recovery blocks to track timing drift. Johnathan A fun thing to do on the USRPs is to blow on the crystal while it's transmitting. If you transmit a tone with usrp_siggen.py and receive it using usrp_fft.py with a high decimation rate (so you're only looking at a fairly small frequency window), you can see the effects that temperature makes in the oscillator's operation. You should see the tone in the FFT window swing left or right and the come back to settle on a nominal frequency. I haven't tried this with the USRP2, but it should work similarly (since it's not a TCXO). But the point I'm making is that oscillators have real constraints and issues related to anything from physical makeup to environmental conditions. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-howto-write-a-block refactored
Hi folks, I just committed a change to gr-howto-write-a-block that now has it install in the howto python namespace instead of in the gnuradio.howto namespace. This allows howto (or other things based on it) to install under a non-system prefix. For systems using binary GR packages, this means that user written out of tree code will not have a conflict with the gnuradio namespace. From a high level point of view, this changes means that if you're using these blocks, you would now import them using import howto instead of from gnuradio import howto Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_unpack_k_bits_bb, its inverse, and higher order constellations
Eric Blossom wrote: I assume that you mean 1 byte per symbol. I suggest that you create *_ci and *_ii versions that handle 32-bits. Eric You are correct, one byte per symbol. Or one symbol per byte, whichever way one wants to look at it. To clarify what the custom block does is that it takes K bytes with 1 significant bit (in lsb, from a glfsr or similar) and turns it into 1 byte with K significant bits. Then it's just to feed these new, packed (is this the word for it?), bytes into the chunks_to_symbols_bc- block, producing one symbol for every byte. Is this really stupid, or has it just not been done yet? I assume that there are more people working with more signal- points than two in their constellations. But at the same time it seems like I'm wasting a lot of resources on copying bytes with only two or three (qpsk, qam16) significant bits in them... //Mattias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_unpack_k_bits_bb, its inverse, and higher order constellations
On Thu, Mar 4, 2010 at 10:28 AM, Mattias Kjellsson m...@kth.se wrote: Eric Blossom wrote: I assume that you mean 1 byte per symbol. I suggest that you create *_ci and *_ii versions that handle 32-bits. Eric You are correct, one byte per symbol. Or one symbol per byte, whichever way one wants to look at it. To clarify what the custom block does is that it takes K bytes with 1 significant bit (in lsb, from a glfsr or similar) and turns it into 1 byte with K significant bits. Then it's just to feed these new, packed (is this the word for it?), bytes into the chunks_to_symbols_bc- block, producing one symbol for every byte. Is this really stupid, or has it just not been done yet? I assume that there are more people working with more signal- points than two in their constellations. But at the same time it seems like I'm wasting a lot of resources on copying bytes with only two or three (qpsk, qam16) significant bits in them... //Mattias Have you looked at gnuradio-core/src/python/gnuradio/blks2impl/dqpsk.py (and qam8, qam16, qam64, and qam256.py)? They handle the modulation and demodulation parts of the TX and RX. We don't have a good synchronization scheme, but I think these do what you want. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The sinusiodal waveform is drifting from input to output.
On Thu, Mar 4, 2010 at 06:59, Tom Rondeau trondeau1...@gmail.com wrote: A fun thing to do on the USRPs is to blow on the crystal while it's transmitting. If you transmit a tone with usrp_siggen.py and receive it using usrp_fft.py with a high decimation rate (so you're only looking at a fairly small frequency window), you can see the effects that temperature makes in the oscillator's operation. You should see the tone in the FFT window swing left or right and the come back to settle on a nominal frequency. One of the demos in my GNU Radio training course during the bit-error-rate testing lab is to spray the transmitter crystal with Duster or other cold spray. The BERT receiver continuously displays the calculated frequency and timing offset, so the transient becomes very obvious, yet the carrier and symbol timing loops deal with it just fine. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_unpack_k_bits_bb, its inverse, and higher order constellations
Tom Rondeau wrote: On Thu, Mar 4, 2010 at 10:28 AM, Mattias Kjellsson m...@kth.se wrote: Eric Blossom wrote: I assume that you mean 1 byte per symbol. I suggest that you create *_ci and *_ii versions that handle 32-bits. Eric You are correct, one byte per symbol. Or one symbol per byte, whichever way one wants to look at it. To clarify what the custom block does is that it takes K bytes with 1 significant bit (in lsb, from a glfsr or similar) and turns it into 1 byte with K significant bits. Then it's just to feed these new, packed (is this the word for it?), bytes into the chunks_to_symbols_bc- block, producing one symbol for every byte. Is this really stupid, or has it just not been done yet? I assume that there are more people working with more signal- points than two in their constellations. But at the same time it seems like I'm wasting a lot of resources on copying bytes with only two or three (qpsk, qam16) significant bits in them... //Mattias Have you looked at gnuradio-core/src/python/gnuradio/blks2impl/dqpsk.py (and qam8, qam16, qam64, and qam256.py)? They handle the modulation and demodulation parts of the TX and RX. We don't have a good synchronization scheme, but I think these do what you want. Tom I know of them, and have looked at them, but nothing more. Since I don't speak python very well, I try to do everything in c++. I have tried to use pilots mixed in every few data- symbols and compensate the data- symbols using these known symbols. I'm getting kind of good results, although I think the custom early/late gate sampler I wrote has a settling time way to long (between 900 and 3000 symbols depending on which constants I put in). I'll try to rewrite the MM- sync- block to utilize the slicer_45deg(), and see what results I get with that. From what I can tell from the paper pointed to by the header- file, the optimized MM- loop should be able to handle at least QPSK, and have a way shorter settling time than 900 symbols. I think the pilot- compensation code should still work and compensate any screw to the constellation. I'm getting all exited just writing about it ;) I'll let you know how it goes. //Mattias ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] u2_flash_tool : Can not find the command
Hi Johnathan, appreciate for your help. I have bought another brand (ADATA) 2GB SD card today and did the same thing as before since I can not find any Kingston card available in shop. 1. I downloaded txrx.bin and u2_rev3.bin files from http://gnuradio.org/releases/usrp2-bin/trunk/ and u2_flash_tool from http://gnuradio.org/redmine/repositories/changes/gnuradio/usrp2/firmware/u2_flash_tool then put them into the same folder. 2. After that I use “chmond” to make the u2_flash_tool executable 3. Using sudo ./u2_flash_tool --dev=/dev/mmcblk0p1 -t s/w txrx.bin –w Take off the SD card from the reader and insert it back Using sudo ./u2_flash_tool --dev=/dev/mmcblk0p1 -t s/w txrx.bin -v 4. Using sudo ./u2_flash_tool --dev=/dev/mmcblk0p1 -t s/w u2_rev3.bin –w Take off the SD card from the reader and insert it back Using sudo ./u2_flash_tool --dev=/dev/mmcblk0p1 -t s/w u2_rev3.bin –v 5. There is no extra information after the verify command. 6. I put the SD card into the USRP2 and power it. For sandisk SD card: Only LED (F) is on For ADATA SD card: All LEDs are off The same condition is described in here http://old.nabble.com/Write-bin-to-SD-card-td21680697.html#a21720726 If every step is fine, maybe I guess I am a bit unluck and have to wait for the replacement. Can I have another way to check if the firmware in SD card is correct rather than the verify command? Andy -- View this message in context: http://old.nabble.com/u2_flash_tool-%3A---Can-not-find-the-command-tp27760919p27783446.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
Re: [Discuss-gnuradio] gr_unpack_k_bits_bb, its inverse, and higher order constellations
On Thu, Mar 4, 2010 at 11:38 AM, Mattias Kjellsson m...@kth.se wrote: Tom Rondeau wrote: On Thu, Mar 4, 2010 at 10:28 AM, Mattias Kjellsson m...@kth.se wrote: Eric Blossom wrote: I assume that you mean 1 byte per symbol. I suggest that you create *_ci and *_ii versions that handle 32-bits. Eric You are correct, one byte per symbol. Or one symbol per byte, whichever way one wants to look at it. To clarify what the custom block does is that it takes K bytes with 1 significant bit (in lsb, from a glfsr or similar) and turns it into 1 byte with K significant bits. Then it's just to feed these new, packed (is this the word for it?), bytes into the chunks_to_symbols_bc- block, producing one symbol for every byte. Is this really stupid, or has it just not been done yet? I assume that there are more people working with more signal- points than two in their constellations. But at the same time it seems like I'm wasting a lot of resources on copying bytes with only two or three (qpsk, qam16) significant bits in them... //Mattias Have you looked at gnuradio-core/src/python/gnuradio/blks2impl/dqpsk.py (and qam8, qam16, qam64, and qam256.py)? They handle the modulation and demodulation parts of the TX and RX. We don't have a good synchronization scheme, but I think these do what you want. Tom I know of them, and have looked at them, but nothing more. Since I don't speak python very well, I try to do everything in c++. I have tried to use pilots mixed in every few data- symbols and compensate the data- symbols using these known symbols. I'm getting kind of good results, although I think the custom early/late gate sampler I wrote has a settling time way to long (between 900 and 3000 symbols depending on which constants I put in). I'll try to rewrite the MM- sync- block to utilize the slicer_45deg(), and see what results I get with that. From what I can tell from the paper pointed to by the header- file, the optimized MM- loop should be able to handle at least QPSK, and have a way shorter settling time than 900 symbols. I think the pilot- compensation code should still work and compensate any screw to the constellation. I'm getting all exited just writing about it ;) I'll let you know how it goes. //Mattias Matt and I wrote a resampler based on polyphase filterbanks a few months ago. It's called gr_pfb_clock_sync_xxf (in the filter directory). It works really well for any PAM signal (we've tested it with PSK and QAMs successfully). You can see how its used in the new dbpsk2.py and dqpsk2.py files. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Daughterboard
Hi All, When we use any of the USRP daughterboard to transmit, do we need the authorization? For example, FRX900 includes the cell phone bands in US. If we use FRX900 to transmit, do we violate the FCC rule? Or, we could legally use any daughterboard on any band that falls in the frequency range of the daughterboard? Thanks, Brook -- View this message in context: http://old.nabble.com/Daughterboard-tp27784947p27784947.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
Re: [Discuss-gnuradio] u2_flash_tool : Can not find the command
On Thu, Mar 4, 2010 at 08:51, Andy_Long luckshiw...@yahoo.com.cn wrote: I have bought another brand (ADATA) 2GB SD card today and did the same thing as before since I can not find any Kingston card available in shop. 3. Using sudo ./u2_flash_tool --dev=/dev/mmcblk0p1 -t s/w txrx.bin �Cw I'm a litttle concerned that you have an MMC card and not an SD card, based on the device name that gets created when you insert the card into your read/writer. Using SD cards, I've only ever seen Ubuntu generate devices of type '/dev/sdX'. But since I've never actually used an MMC card, I don't know if this is unrelated to your problem or not. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] u2_flash_tool : Can not find the command
I used the SD card with the laptop built-in reader. Actucally it is a bit difficult to buy a mmc card in shop now. :) I will try to use the other SD reader outside the laptop to see the difference. thank you. Andy Johnathan Corgan-2 wrote: On Thu, Mar 4, 2010 at 08:51, Andy_Long luckshiw...@yahoo.com.cn wrote: I have bought another brand (ADATA) 2GB SD card today and did the same thing as before since I can not find any Kingston card available in shop. 3. Using sudo ./u2_flash_tool --dev=/dev/mmcblk0p1 -t s/w txrx.bin �Cw I'm a litttle concerned that you have an MMC card and not an SD card, based on the device name that gets created when you insert the card into your read/writer. Using SD cards, I've only ever seen Ubuntu generate devices of type '/dev/sdX'. But since I've never actually used an MMC card, I don't know if this is unrelated to your problem or not. Johnathan ___ 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/u2_flash_tool-%3A---Can-not-find-the-command-tp27760919p27785252.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
Re: [Discuss-gnuradio] u2_flash_tool : Can not find the command
3. Using sudo ./u2_flash_tool --dev=/dev/mmcblk0p1 -t s/w txrx.bin �Cw I'm a litttle concerned that you have an MMC card and not an SD card, based on the device name that gets created when you insert the card into your read/writer. Using SD cards, I've only ever seen Ubuntu generate devices of type '/dev/sdX'. But since I've never actually used an MMC card, I don't know if this is unrelated to your problem or not. My built-in laptop card reader also produced device names like that. It never worked for me with writing the usrp2 images. Also, it would unmount/crash itself if i tried reading/writing large files to a sd card with a file system. Just sayin... Anyway, based on my experience, I recommend using a sd card reader device that mounts the thing as a /dev/sdX device. Ettus research usually ships one of these readers with the usrp2s. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Daughterboard
On Thu, Mar 4, 2010 at 12:48 PM, Brook Lin gnu.f...@yahoo.com wrote: Hi All, When we use any of the USRP daughterboard to transmit, do we need the authorization? For example, FRX900 includes the cell phone bands in US. If we use FRX900 to transmit, do we violate the FCC rule? Or, we could legally use any daughterboard on any band that falls in the frequency range of the daughterboard? Thanks, Brook -- As my dad used to say, You can do whatever you want as long as you are willing to face the consequences. So go nuts. If you aren't interested in FCC fines, then yes, you have to abide by FCC rules, with the RFX900 you can transmit safely in the ISM band. And others as long as you are below the transmit power thresholds (which are quite low). To find out the rules about where you can and can't transmit you should check http://www.fcc.gov/oet/spectrum/ specifically, check the Frequency Allocation Table. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Daughterboard
On Thu, Mar 4, 2010 at 10:48, Brook Lin gnu.f...@yahoo.com wrote: When we use any of the USRP daughterboard to transmit, do we need the authorization? For example, FRX900 includes the cell phone bands in US. If we use FRX900 to transmit, do we violate the FCC rule? Or, we could legally use any daughterboard on any band that falls in the frequency range of the daughterboard? You are responsible for complying with any and all FCC rules regarding intentional transmitters. The USRP is not FCC type-accepted and does not come with any pre-authorized licenses on any frequency bands. One recommendation is to obtain an amateur radio license, which would allow transmission with the RFX900 in the 902-928 MHz band in the US within the rules and requirements of the amateur radio service. This does not address the cellular bands you were asking about. Many people, of course, ignore the above and assume that at a few milliwatts transmit power in an indoor environment, nobody will notice or care. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rx_timed_samples.cc doesn't stop streaming of samples
Couple more questions if you don't mind: 1) Where does the number of items per packet (which is 365 in my case) comes from? Or is it the format USRP2 always uses to send the data to the host? Its probably the MTU (1500 bytes) minus the ip/udp/ethernet headers sizes minus the size of the vrt headers. Basically, the maximum number of samples per frame. 2) After specifying -N as 1000 I got the following output: Got packet: 1267693414 secs, 35564266 ticks Got packet: 1267693414 secs, 35570106 ticks Got packet: 1267693414 secs, 35575946 ticks So the number of ticks between the packets is 5840, dividing by 365 we get 16-the number of ticks per sample, and the decimation is 16 which is consistent. My question is: if I want to extract the timestamps for each sample individually I would need to take the timestamp of the packet and subtract the required number of 16*N (e.g. for the sample number 300 in the first packet the timestamp is 35564266-65*16=35563226) or is there a different way the get hold of timestamps for individual samples? That's correct: The Nth sample will be N*usrp2_clock_rate/samp_rate ticks offset from the timestamp or in this case N*16 ticks offset. Each sample has a temporal ambiguity equal to the width of 16 clock ticks. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Daughterboard
On Thu, Mar 4, 2010 at 11:24, Jason Uher jasonu...@gmail.com wrote: ...with the RFX900 you can transmit safely in the ISM band. And others as long as you are below the transmit power thresholds (which are quite low). I (perhaps mistakenly) thought that in order to be in compliance with FCC rules to intentionally transmit within ISM bands using low power, the transmitter needed to be pre-approved by having an FCC type acceptance certification. I'll will be happy to be found wrong on this count, as it has been a long time since I've studied the regulations. Even so, this doesn't address the original poster's question about cellular bands. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Enabling the cognitive radio with GNU Radio+USRP
Hi everyone, I am trying to use the GNU-Radio+USRP to implement a cognitive radio use case in which radios exchange information (XML-based documents) between each other in order to achieve a defined goal (e.g. to improve connectivity), without disturbing the usual communication. I have several questions regarding this scenario.. In a packet-based communication (e.g. tunnel.py) I imagine that I could transmit my own packets which would include the cognitive information and then receive them on the other end. It would require some special marking of the packets (binary level?) to distinguish the cognitive information from the regular data, so that it could be filtered out on the receiver side. I looked into the tunnel.py, but it seems that it doesn't implement anything higher than the MAC layer - therefore I cannot use it to reliably transfer data, packets get lost or are too small and I would have to split/merge data manually. Would it be possible to combine the tunnel.py with the TCP source/sinks in order to achieve a reliable link? It looks like some of the examples don't use the concept of a packet (eg. usrp_tv_rcv.py) -- how would I add my own data and filter it in such streams? Would it require writing a C++ block? If so, how would I ensure the reliability then? Last question.. I own to USRPs and I successfully installed the gnuradio with grc on two MacBooks (10.6.2). Examples run fine, but when it comes to the tunnel.py I cannot make the TUN/TAP interface to work on OSX, has anyone had luck with that? I browsed the list archives, but I couldn't find a tutorial to make it happen. After reading the http://lists.gnu.org/archive/html/discuss-gnuradio/2009-01/msg00047.html I tried the tuntaposx and Tunnelblick, but with no luck. For now I replaced the tun/tap with a STOMP/JMS layer. I have a CS background and the digital communication is rather new to me, I would appreciate any help or links to resources. Thanks, Jakub ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rx_timed_samples.cc doesn't stop streaming of samples
And the offset seems to be positive, i.e. the packet timestamp is the time of the first sample in the packet and not of the last one (referring to my previous calculation: for the sample number 300 in the first packet the timestamp is 35564266+300*16=35569066). I've come up to this conclusion by applying a PPS signal to the boards and calling u2-set_time_at_next_pps(5,0) and the output was: ... Got packet: 212 secs, 12258426 ticks Got packet: 212 secs, 12264266 ticks Got packet: 5 secs, 2244 ticks Got packet: 5 secs, 8084 ticks ... where 2244 is not divisible by 16, hence represents some sort of delay before the first sample gets received after the clock reset. Or am I missing something? Valentin Josh Blum-2 wrote: Couple more questions if you don't mind: 1) Where does the number of items per packet (which is 365 in my case) comes from? Or is it the format USRP2 always uses to send the data to the host? Its probably the MTU (1500 bytes) minus the ip/udp/ethernet headers sizes minus the size of the vrt headers. Basically, the maximum number of samples per frame. 2) After specifying -N as 1000 I got the following output: Got packet: 1267693414 secs, 35564266 ticks Got packet: 1267693414 secs, 35570106 ticks Got packet: 1267693414 secs, 35575946 ticks So the number of ticks between the packets is 5840, dividing by 365 we get 16-the number of ticks per sample, and the decimation is 16 which is consistent. My question is: if I want to extract the timestamps for each sample individually I would need to take the timestamp of the packet and subtract the required number of 16*N (e.g. for the sample number 300 in the first packet the timestamp is 35564266-65*16=35563226) or is there a different way the get hold of timestamps for individual samples? That's correct: The Nth sample will be N*usrp2_clock_rate/samp_rate ticks offset from the timestamp or in this case N*16 ticks offset. Each sample has a temporal ambiguity equal to the width of 16 clock ticks. -Josh ___ 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/rx_timed_samples.cc-doesn%27t-stop-streaming-of-samples-tp27771324p27785768.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
Re: [Discuss-gnuradio] rx_timed_samples.cc doesn't stop streaming of samples
On 03/04/2010 11:56 AM, ValentinG wrote: And the offset seems to be positive, i.e. the packet timestamp is the time of the first sample in the packet and not of the last one (referring to my previous calculation: for the sample number 300 in the first packet the timestamp is 35564266+300*16=35569066). I've come up to this conclusion by applying a PPS signal to the boards and calling u2-set_time_at_next_pps(5,0) and the output was: ... Got packet: 212 secs, 12258426 ticks Got packet: 212 secs, 12264266 ticks Got packet: 5 secs, 2244 ticks Got packet: 5 secs, 8084 ticks Yes, the timestamp that comes with the vrt header is the timestamp for the first sample in that packet. where 2244 is not divisible by 16, hence represents some sort of delay before the first sample gets received after the clock reset. Or am I missing something? Unless, you use the start streaming with a timestamp, the timestamp that you see above will be somewhat arbitrary as to where it starts. In the above case, the pps event occurs within: Got packet: 212 secs, 12264266 ticks Which explains why the third packet Got packet: 5 secs, 2244 ticks has a significantly larger than zero ticks value. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Quick question regarding plotting samples captured by usrp_rx_cfile.py against time!!
Hi,
I have a quick question regarding the complex binary samples captured by
using usrp_rx_cfile.py. I would like to draw them against time. So,
(Magnitude on Y-axis and Time on X-axis) in matlab. I was able to do the
following
1. ./usrp_rx_cfile.py -f 2.5G capture.dat
2. d = read_complex_binary('capture.dat');
3. I was able to choose every other sample, because there are two samples
per symbol. (Sample Rate =2). dd= d(1:2:length(d));
4. Then able to plot (abs(dd)) --- This gives me magnitude (Y-axis) vs.
Sample number (x-axis)
5. How can I draw these samples (dd) now against time(on X-axis).
Thank you for your time,
Sincerely,
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE : [Discuss-gnuradio] PSK demodulation : g et exact point before deciding what is the closest constel lation point
On Mon, Feb 22, 2010 at 12:03:28PM -0500, christophe.par...@etsmtl.ca wrote: Hi all ! I am dealing with PSK (BPSK, QPSK, 8PSK) modulation/demodulation ; in demodulation, I would want to retrieve the exact point (vector) before finding the closest constellation point. K Is there any way to get it with d?psk.py codes or whatever else ? Thanks in advance for your help. Chris Chris, If you look at the code (gnuradio-core/src/python/gnuradio/blks2impl/dbpsk.py et al.), you'll see that you can enable logging (and get all the intermediate values logged to files) or you could just wire in your own logging stuff wired in by reaching into the hier_block and connecting away. Eric Thanks Eric ! I've successfully retrieved the intermediate values by enabling logging to files. Though, I've no idea about how I could just wire in your own logging stuff wired in by reaching into the hier_block and connecting away, as an alternative way to reach the same results. Chris P.S. I posted this question in another message that is not smart at all. Sorry, that is why I'm re-posting it in a better way (after have read the article How To Ask Questions The Smart Way http://www.catb.org/~esr/faqs/smart-questions.html ). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Daughterboard
On Thu, Mar 4, 2010 at 12:15, Jason Uher jasonu...@gmail.com wrote: You are right, unless your device is pre-approved by the FCC you can't legally transmit in unlicensed bands. I was under the impression that the USRPs status as 'test equipment' allowed transmission in unlicensed bands (like the ISM) without needing the part 15 approval as long as it was below a certain effective radiated power level, as if a user were developing a new product prior to part15 certification. That may not be true. And I thought the USRP's status as test equipment is just what allowed them to be sold without type acceptance. This is similar to a signal generator, which could transmit on a wide variety of frequencies just by putting an antenna on the output. Anyway, enough speculation; I don't wish to steer anyone wrong, I am not a lawyer, and clearly I don't speak for Ettus Research. Government imposed rules are often unintuitive, arbitrary and subject to case-by-case interpretation, so I'll let Matt address the question if he chooses. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Loop-back on the same USRP
Hi all ! I have only one USRP2 and would like to use a loop-back cable to connect the output to the input of the same USRP. So I would, for example, run benchmark_tx and benchmark_rx in two different shells. Can I do it without any worry ? I am asking the question because it seems that many people always ran a such test with two USRP (one for Tx and the second for Rx). Thanks, Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] u2_flash_tool : Can not find the command
On 03/04/2010 11:24 AM, Josh Blum wrote: 3. Using sudo ./u2_flash_tool --dev=/dev/mmcblk0p1 -t s/w txrx.bin �Cw I'm a litttle concerned that you have an MMC card and not an SD card, based on the device name that gets created when you insert the card into your read/writer. Using SD cards, I've only ever seen Ubuntu generate devices of type '/dev/sdX'. But since I've never actually used an MMC card, I don't know if this is unrelated to your problem or not. My built-in laptop card reader also produced device names like that. It never worked for me with writing the usrp2 images. Also, it would unmount/crash itself if i tried reading/writing large files to a sd card with a file system. Just sayin... Anyway, based on my experience, I recommend using a sd card reader device that mounts the thing as a /dev/sdX device. Ettus research usually ships one of these readers with the usrp2s. Correction -- We don't ship one of the readers unless you purchase it separately. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Loop-back on the same USRP
On Thu, Mar 4, 2010 at 12:37, christophe.par...@etsmtl.ca wrote: I have only one USRP2 and would like to use a loop-back cable to connect the output to the input of the same USRP. So I would, for example, run benchmark_tx and benchmark_rx in two different shells. Can I do it without any worry ? I am asking the question because it seems that many people always ran a such test with two USRP (one for Tx and the second for Rx). No. In general, USRP applications assume they own the USRP they are communicating with, so the second script you run will stomp on the first one. There is no problem, however, using a single machine and having two USRP1 devices on the USB. In this case, scripts can distinguish which USRP they are talking to using a parameter during initialization. Not all example scripts are written with this in mind; I'd have to check if the digital example you reference does so (I think so.) A single USRP, however, could be used with a loopback between TX and RX if you were to write your own script that pulled in the transmit_path and receive_path hierarchical blocks into a single application, similar to what tunnel.py does. As an aside, I think the recommendation is to use 30 dB of attenuation between the transmitter and receiver boards to avoid damaging the front end of the receiver. You may be able to get away with less attenuation if you know what you are doing, and properly control the transmit power. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] u2_flash_tool : Can not find the command
3. Using sudo ./u2_flash_tool --dev=/dev/mmcblk0p1 -t s/w txrx.bin ¨Cw I'm a litttle concerned that you have an MMC card and not an SD card, based on the device name that gets created when you insert the card into your read/writer. Using SD cards, I've only ever seen Ubuntu generate devices of type '/dev/sdX'. No need to worry about this. The mmc driver handles both MMC and SD cards (their protocols are almost identical). The sd driver actually stands for SCSI disk; but in recent kernels, SATA and USB storage media also show up as sd devices. So if you access your SD card via a USB adapter, it becomes an sd device. If you access your SD card via a builtin non-USB SD interface, it becomes an mmcblk device. Ah! The issue is probably that he's accessing mmcblk0p1, that is, the first partition. I thought the USRP2 used unpartitioned cards, i.e. he should write to mmcblk0 (which will overwrite the partition label and eliminate those p1 devices on subsequent accesses anyway). John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Daughterboard
When we use any of the USRP daughterboard to transmit, do we need the authorization? For example, FRX900 includes the cell phone bands in US. If we use FRX900 to transmit, do we violate the FCC rule? Or, we could legally use any daughterboard on any band that falls in the frequency range of the daughterboard? When the OpenBTS folks transmit in the cellphone bands, such as at Burning Man last year, they get an STA (Special Temporary Authorization) from the FCC. They also get permission from the chief engineer of one of the incumbent cellular licensees in the area, to avoid interference with already-licensed traffic. I don't recommend proceeding without those precautions. I believe no license is needed to do bench testing with a dummy load that doesn't radiate beyond the tabletop. Merely opening the metal cover of your PC probably causes more electromagnetic radiation than that. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Daughterboard
To echo what John sent. There are provisions to do testing and very limited radiation from intentional radiators. You can see them outlined in Part 15 of the FCC Rules and Regulations... http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfrsid=0df10ae68df3af4194db436740229487rgn=div5view=textnode=47:1.0.1.1.14idno=47 Depending on the frequency/band you are going to use, there are levels that you can operate under. Typically, levels are rated in how many microvolts per meter that is induced on an antenna that is X number of meters away from the radiating device. If you just want to test a product, it is better to bench test it using a closed system with coax and attenuators to simulate free space loss. This way you can be assure you are not leaking out RF energy that could be causing interference, you can be assured that you are testing with known RF levels to confirm receiver sensitivity and transmitter power levels and you are shielded from outside interferences that could affect your testing. If you need to test in free space, depending on the band you are using, you may be under Part 15 rules to produce very low levels of RF. Anything beyond that would require, as John said, an Special Temporary Authorization for an experimental license. You can see some details at: http://www.fcc.gov/oet/faqs/elbfaqs.html http://www.fcc.gov/oet/info/filing/elb/ If you are going to be operating on a frequency that is already in use, you will need to coordinate with that license holder and get permission to use it. You will need to demonstrate this to the FCC when applying for your STA. This is one of the reasons why the OpenBTS picked Black Rock and Burning Man to test. It gave them a rather isolated area with that would be easier to coordinate with and a population to test with. A brilliant move if I may say so. If you want to get an STA, I suggest you work with a telecom attorney that has some experience in this area as it will speed the process up considerably. The OpenBTS folks may be able to help. I can point you at lawyers in this area if you like. Tim on 3/4/10 3:28 PM John Gilmore said the following: When we use any of the USRP daughterboard to transmit, do we need the authorization? For example, FRX900 includes the cell phone bands in US. If we use FRX900 to transmit, do we violate the FCC rule? Or, we could legally use any daughterboard on any band that falls in the frequency range of the daughterboard? When the OpenBTS folks transmit in the cellphone bands, such as at Burning Man last year, they get an STA (Special Temporary Authorization) from the FCC. They also get permission from the chief engineer of one of the incumbent cellular licensees in the area, to avoid interference with already-licensed traffic. I don't recommend proceeding without those precautions. I believe no license is needed to do bench testing with a dummy load that doesn't radiate beyond the tabletop. Merely opening the metal cover of your PC probably causes more electromagnetic radiation than that. John -- GPG Fingerprint: 4821 CFDA 06E7 49F3 BF05 3F02 11E3 390F 8338 5B04 http://www.lns.com/house/pozar/pozar_4096_rsa_public.asc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Daughterboard
There are two things that tend to get conflated here. One is the ability to market and sell products like the USRP and the other is the ability to operate it. Items that radiate and are marketed and sold in the US, typically are subject to certification. Test equipment is subject to certification. Test equipment is tested with dummy loads in the expectation that it will be used in a lab environment. It is not expected that the user will intentionally and willfully radiate beyond Part 15 levels by putting an antenna on it. Tim on 3/4/10 12:30 PM Johnathan Corgan said the following: On Thu, Mar 4, 2010 at 12:15, Jason Uher jasonu...@gmail.com wrote: You are right, unless your device is pre-approved by the FCC you can't legally transmit in unlicensed bands. I was under the impression that the USRPs status as 'test equipment' allowed transmission in unlicensed bands (like the ISM) without needing the part 15 approval as long as it was below a certain effective radiated power level, as if a user were developing a new product prior to part15 certification. That may not be true. And I thought the USRP's status as test equipment is just what allowed them to be sold without type acceptance. This is similar to a signal generator, which could transmit on a wide variety of frequencies just by putting an antenna on the output. Anyway, enough speculation; I don't wish to steer anyone wrong, I am not a lawyer, and clearly I don't speak for Ettus Research. Government imposed rules are often unintuitive, arbitrary and subject to case-by-case interpretation, so I'll let Matt address the question if he chooses. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- GPG Fingerprint: 4821 CFDA 06E7 49F3 BF05 3F02 11E3 390F 8338 5B04 http://www.lns.com/house/pozar/pozar_4096_rsa_public.asc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Daughterboard
Just to kick in our experience at Virginia Tech, we have several STA's because we do a lot of wireless work. I believe this link will take you to our license: https://fjallfoss.fcc.gov/oetcf/els/reports/ViewGrant.cfm?id_file_num=0013-EX-ST-2010application_seq=43699 The process is not as bad as I had originally thought coming into all of this. In fact, we used to have a graduate student fill out the online forms and manage them. You do need to provide the FCC with a significant amount of info, some of which is a little hard to do when working on numerous completely different software radio applications with varying waveforms and frequencies. The important items are obviously location, radiated power and frequency. We just assume if it's going over the air we'll need a license, although like Tim mentioned earlier, it's certainly possible to stay under the Part 15 limits. Tim Tim Pozar wrote: To echo what John sent. There are provisions to do testing and very limited radiation from intentional radiators. You can see them outlined in Part 15 of the FCC Rules and Regulations... http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfrsid=0df10ae68df3af4194db436740229487rgn=div5view=textnode=47:1.0.1.1.14idno=47 Depending on the frequency/band you are going to use, there are levels that you can operate under. Typically, levels are rated in how many microvolts per meter that is induced on an antenna that is X number of meters away from the radiating device. If you just want to test a product, it is better to bench test it using a closed system with coax and attenuators to simulate free space loss. This way you can be assure you are not leaking out RF energy that could be causing interference, you can be assured that you are testing with known RF levels to confirm receiver sensitivity and transmitter power levels and you are shielded from outside interferences that could affect your testing. If you need to test in free space, depending on the band you are using, you may be under Part 15 rules to produce very low levels of RF. Anything beyond that would require, as John said, an Special Temporary Authorization for an experimental license. You can see some details at: http://www.fcc.gov/oet/faqs/elbfaqs.html http://www.fcc.gov/oet/info/filing/elb/ If you are going to be operating on a frequency that is already in use, you will need to coordinate with that license holder and get permission to use it. You will need to demonstrate this to the FCC when applying for your STA. This is one of the reasons why the OpenBTS picked Black Rock and Burning Man to test. It gave them a rather isolated area with that would be easier to coordinate with and a population to test with. A brilliant move if I may say so. If you want to get an STA, I suggest you work with a telecom attorney that has some experience in this area as it will speed the process up considerably. The OpenBTS folks may be able to help. I can point you at lawyers in this area if you like. Tim on 3/4/10 3:28 PM John Gilmore said the following: When we use any of the USRP daughterboard to transmit, do we need the authorization? For example, FRX900 includes the cell phone bands in US. If we use FRX900 to transmit, do we violate the FCC rule? Or, we could legally use any daughterboard on any band that falls in the frequency range of the daughterboard? When the OpenBTS folks transmit in the cellphone bands, such as at Burning Man last year, they get an STA (Special Temporary Authorization) from the FCC. They also get permission from the chief engineer of one of the incumbent cellular licensees in the area, to avoid interference with already-licensed traffic. I don't recommend proceeding without those precautions. I believe no license is needed to do bench testing with a dummy load that doesn't radiate beyond the tabletop. Merely opening the metal cover of your PC probably causes more electromagnetic radiation than that. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Quadrature direct-conversion receiver design
OK, so this probably seems like a fundamental sort of question, but I've noticed that there seem to be a couple of different places on the net describing quadrature receiver toplogies, and I want to know something fairly simple. For a direct-conversion quadrature receiver, must you phase split *BOTH* the RF and LO inputs to the mixers? That is, do you need a 90 degree hybrid on both the RF and LO ports? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] implementing an interference source
hi everyone i am new to gnuradio, nowadays,i want to build an interference source,but in grc,i just know grc a little and do not implement the interference source.so can anyone help me resolve this problem or give me some advices. the interference source demands QPSK module,500K bandwidth,frequence about in 440M. thanks in advance.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] implementing an interference source
See the channel model block. -Josh On 03/04/2010 07:19 PM, cbwangmail wrote: hi everyone i am new to gnuradio, nowadays,i want to build an interference source,but in grc,i just know grc a little and do not implement the interference source.so can anyone help me resolve this problem or give me some advices. the interference source demands QPSK module,500K bandwidth,frequence about in 440M. thanks in advance. ___ 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] Transmit legit, become a ham
As discussed in the licensing thread... In FCC-land the only people that can legally transmit at any kind of real power level using non-certified devices without obtaining specific permission from the FCC are amateur radio operators. Testing with attenuators is an obvious first step, but it doesn't replace working in a real environment with multipath, fading, noise sources, etc. Becoming an amateur radio operator is trivial: You show up at a testing location [1] which is likely filled with people who will be more interested in your gnuradio use than anyone else you know, pay zero to $15 dollars (depends on which group is administering the test, the laurel VEC is free), take a simple 35 question multiple choice test, and tada a few days later You've obtained the lowest level of licensing, the Technician class. The license is good for ten years and costs nothing to renew. A technician license entitles you to transmit on: 28.000-28.500 MHz (200w max for tech class) 50.0-54.0 MHz, 144.1-148.0 MHz 222.00-225.00 MHz, 420.0-450.0 MHz 902.0-928.0 MHz, 1240-1300 MHz 2300-2310 MHz, 2390-2450 MHz 3300-3500 MHz, 5650-5925 MHz 10.0-10.5 GHz, 24.0-24.25 GHz 47.0-47.2 GHz, 77.0-81.9 GHz 119.98-120.02 GHz, 142-149 GHz 241-250 GHz All above 300 GHz (up to wherever the FCC regulation ends) with up-to 1500W of power, as needed. (some band specific and geographic restrictions apply) Generally no EIRP or antenna gain restrictions (some exceptions exist in the lower bands) ...plus a couple of narrow slices lower frequency bands I've omitted. Moreover, the amateur license gives you a ready and simple explanation for anyone who might want to claim that you possession of radio equipment signals some kind of intent to operate in a forbidden manner. Why do you have all this radio stuff? Are you a terrorist?? No. Ham radio operator. oh. Okay. I'll just leave now before you geek-out on me. The regulations related to use are very liberal and fairly compatible with experimental use— after all, radio experimentation is part of the stated purpose of the amateur radio service. The most onerous restrictions for a GNUradio user are probably the prohibitions against commercial use, encryption, and carrying traffic for third parties. Otherwise it's just mostly, behave in a socially responsible, safe manner, and observe good engineering practices. Nothing forces you to interact with other ham radio operators. You can happily work in isolation communicating among your own stations if you wish. However, ham-land contains a ready pool of technically inclined people, most of whom are interested in but not well informed about subjects like software defined radio and Free Software. So by interacting with the existing base of hams you can possibly help expand the pool of GNURadio users (as well as GNU/Linux, if thats your thing). More users means more developers, more demand for compatible hardware at lower prices, so generally a good thing. If you know a bit about RF and apply some common sense you can probably pass the test cold or only after a few minutes of drilling on some ham specific terminology and regulations. You can take a practice test online[2] and the entire question pool (391 questions) is available. (If anyone here is interested in becoming licensed, I'd be glad to answer whatever questions you have about the process off-list. I'm guessing the same is likely true of many of the other licensed list-members) [1] http://www.arrl.org/arrlvec/examsearch.phtml [2] Online practice test: http://www.eham.net/exams/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Daughterboard
Brook Lin wrote: Hi All, When we use any of the USRP daughterboard to transmit, do we need the authorization? For example, FRX900 includes the cell phone bands in US. If we use FRX900 to transmit, do we violate the FCC rule? Or, we could legally use any daughterboard on any band that falls in the frequency range of the daughterboard? Thanks, Brook There's four ways you can emit RF and remain within the scope of FCC regulations. First, you can emit RF for the purpose of communication as an FCC licensee, pursuant to the rules of the service in which your license is issued. Second, you can emit RF for the purpose of communication not as an FCC licensee, pursuant to the rules in Part 15 for intentional radiators. Third, you can emit RF not for the purpose of communication pursuant to the rules in Part 15 for incidential radiators or pursuant to the rules in part 18 for ISM equipment. Fourth, you can emit RF for any purpose pursuant to the terms of an FCC-issued Special Temporary Authorization. Any other emission of RF (within the FCC's jurisdiction of 9 kilohertz to 300 gigahertz) is illegal. In the first case, you must comply with all requirements of the regulations pertaining to the service in which you have a license. The thing is, for most services one of the rules is that you may only use equipment which has been certificated by the FCC for use with that service; using equipment which has not been certificated for use in that service is a violation of the rules and is prohibited. Some services permit uncertificated equipment to be used in certain situations, most notably the amateur radio service. An amateur radio licensee may use just about anything he or she wants to emit RF as long as his or her emissions are consistent with the regulations in Part 97 and with good engineering and good amateur practice (§97.1). Since the USRP is not certificated for use in any service, it can only be used as an intentional emitter in a licensed service if that service permits the use of uncertificated equipment. In the second and third cases, you must comply with the relevant requirements of Parts 15 and/or 18 for the class of unlicensed operation that applies to your situation. In many cases relevant to the USRP, neither Part 15 nor Part 18 will require certification. Generally, kits and one-off projects require neither certification nor a declaration of comformity; those requirements typically only come into play when a device that operates within the scope of these rules is to be offered for sale or distribution in commerce. The frequency, power, spurious emission, and bandwidth limitations applicable to Part 15 and Part 18 devices are complicated, and it's no mean feat to determine whether a given usage is or is not permissible; do your due diligence before you transmit at any measurable power. In the final case, of course, you can do whatever you negotiate for from the FCC. STAs are not that hard to obtain, especially if you already have a relationship with the FCC. If you're trying to develop a commercial product, you should obtain an STA to do any free space testing; you'll need to deal with the FCC anyway to get the eventual certification, and doing the STA will put the OET on notice of your product development, which might possibly facilitate the eventual certification of your device for commercial sale (or not). If you're just playing with radio out of personal interest, get an amateur radio license and use the amateur allocations, or if your particular investigation cannot be conducted on the amateur bands, use your amateur radio license as an entry to get an amateur STA. (The FCC may, in some circumstances, waive its usual fees for an application for an STA from an amateur licensee.) If your investigation or experiment is such that it can be conducted within the scope of a Part 15 intentional radiator not requiring certification, then just do it, although in that case I still recommend that you get an amateur radio license, because it will make your life slightly easier if you do find yourself dealing with the Enforcement Bureau. Regards, Kelly (AB9RF) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Transmit legit, become a ham
Gregory Maxwell wrote: Moreover, the amateur license gives you a ready and simple explanation for anyone who might want to claim that you possession of radio equipment signals some kind of intent to operate in a forbidden manner. Why do you have all this radio stuff? Are you a terrorist?? No. Ham radio operator. oh. Okay. I'll just leave now before you geek-out on me. Another point to consider is that the EB's approach toward interference is different when the interference comes from an unlicensed source as opposed to a licensed one. If harmful interference to a licensed station originates from an unlicensed source and the unlicensed source is an intentional radiator that isn't just a malfunctioning part 15 device or something, the FCC is very likely to slap the responsible party with a Notice of Unauthorized Operation, or NOUO; NOUOs typically carry an $11,000 fine and that fine is often assessed on the first offense. However, interference which originates from a licensed station, even if the licensee is not authorized to operate on the frequencies in question, will typically result in a Notice of Violation, or NOV. Licensees subject to a NOV are typically given an opportunity to correct the violation without penalty, especially when the interference was not intentional or was due to a misunderstanding or an ordinary technical error on the part of the licensee. Amateur radio operators, in particular, are often given considerable leeway here. NOVs also tend to carry smaller fines (at least for amateur service licensees) than an NOUO for the same behavior, and the FCC is less likely to confiscate offending equipment. As an aside, I'm a ARRL/VEC accredited volunteer examiner, and have administered nearly 100 license examinations now, so I think by now I have some concept of how the process works. If anyone has any questions regarding this process, I'll be glad to answer them. Regards, Kelly (AB9RF) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
