Re: [Discuss-gnuradio] Getting my feet wet on the Tx side of the world
On Sat, Sep 4, 2010 at 1:53 AM, Marcus D. Leech mle...@ripnet.com wrote: OK, so I'm wetting my collective feet (all two of them) in the Tx side of the world, with a comms/telecom application, no less. I'm playing with the OP25 project, which is an open-source initiative to produce tools to deal with the so-called Project 25 digital radio standard that is emerging as the way lots of public-service people talk to each other on their radios. The TX side of the project is still fairly primitive--they have a hand-coded flow-graph that implements an APCO-25 4-level FSK modulator, using an *audio* sink, and then carefully plugging the audio into the guts of a physical radio, right at the FM modulator (for those of you who were around in the old amateur packet radio days, that's the way we used to do 9600BPS packet--bypass the usual FM audio filtering, and plug directly into the FM modulator). So, I decided to adapt what they'd done on the audio side to driving a USRP directly (with an appropriate RF card, naturally). The audio version of their modulator is fairly straightforward. It takes two-bit sequences from a packed-byte stream, and uses them to produce symbols from a simple [1.0, 3.0, -1.0, -3.0] chunks-to-simples conversion. From there, the symbols are run through an RRC filter, then an FM preemphasis filter, then a gain multiplier block, and thence to the audio sink. I have constructed a flow-graph in GRC that I think does pretty-much the same thing, only instead of dumping to the audio port, it has an FM modulator block, and then goes to a USRP sink, with appropriate interpolation specified. My GRC flow-graph is here: http://www.sbrac.org/files/fm4_usrp_modulator.grc APCO-25 runs at a nominal symbol rate of 4800sps, to give 9600BPS, and occupies a nominal 12.5KHz of bandwidth. The rest of it involves the usual suspects of FEC coding, packetizing, etc, etc. I'm just interested in getting the modulator correct at this stage, since the rest of the goo is already partially addressed in the existing OP25 work. I'm not sure that my parameters for the RRC are correct, for one, and exactly what to set the sensitivity parameter to in the the FM modulator (I imagine it's similar to setting the deviation control on an analog FM modulator). Hi Marcus, In the nbfm_tx.py and wfm_tx.py blocks the sensitivity is calculated as: k = 2 * math.pi * max_dev / quad_rate Also, I've copied the signal processing chain almost directly from the version of the modulator that dumps to the audio port, so perhaps there are shortcuts I can take to produce a nice APCO-25 4-level FSK signal that are cheaper. Maybe you can use the wfm_tx block? Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP, GNURADIO, WINDOWS, APPLICATION HELP
Hi William, thank you very much for your answer. I don't really like Linux because it has many problems. As I'm writing you this message I'm installing Ubuntu on a VirtualPC, everything was OK, but when files were copied to the Virtual drive it gave me a BIG error, some I/O error while copying, so this is what I'm talking about, many problems and is very slow compared to Windows. Anyway I will try to install some older versions, maybe I will have some luck to install it. I would like to make the biggest part by myself, not using LabView or Matlab and neither Linux. What I would like to do is to use Windows environment, to install GNU Radio, emulate python in a OOP environment, meaning - execute scripts in a software and get out data. I don't want to use USRP and GNU Radio to see waveforms (only at the begining when I will try it out and when I will write the script), I want to transfer data, to communicate with other wireless devices, etc. I want to use it in the practical side to transfer data, if I could get 2 bytes of data from a wireless device using microcontroller it would be heaven. This is the hardest part, to transfer my first byte of data, after tha I could make some nice things, nice systems. Thank you very much for your answer and I would be very happy to receive any idea from anybody. Best regards, Sam Evans. From: William Cox wc...@ncsu.edu To: Sam Evans sam_evans1...@yahoo.com; GNU Radio Discussion discuss-gnuradio@gnu.org Sent: Thu, September 2, 2010 6:50:50 PM Subject: Re: [Discuss-gnuradio] USRP, GNURADIO, WINDOWS, APPLICATION HELP Sam, Coming from a Windows user, I have to say that switching to Ubuntu was 1) extremely easy and 2) greatly accelerated my understand and ability to use GNURadio/USRP - mainly because I could use the GRC, which is a Labview-like graphical interface to GNURadio and USRP. I'd *highly* recommend giving it a shot first, at least to learn with, before trying Windows development. That's my 0.02. YMMV. Also check out the Simulink libraries - I think they're linked from Ettus.com -William On Wed, Sep 1, 2010 at 5:36 PM, Sam Evans sam_evans1...@yahoo.com wrote: Hi everybody, I would like to ask some questions regarding USRP. I really need some help. I got my USRP with a WBX and LP0410. I work on a computer running Windows XP. After I read many thing about how to install the GNU Radio in Windows environment I could install it using MingW. I used the gnuinstall.py python script like many others but when I tried to run my first script in python I got an error message ImportError: No module named gnuradio. I don't know what is the problem, the gnuradio is installed, the latest one GNU Radio 3.3.0. Could anybody help me with some ideas, how to make it work, and what I'm missing. The second question would be. I would like to use the GNU Radio for a real application. I want to make a .NET application with Delphi Prism and to be able to get data from USRP an set data. There are many informations out there to emulate python (there are even DLL files) to be able to run python scripts from a .NET application. What I want is to exchange data with some devices running on 2 ISM bands (433 and 868). I will make an application with Visual Studio 2010 and I would like to be abel to read data through python script, interprete data and display in the form as some value or a therometer showing the value sent by a device. Wireless devices will have ASK, OOK modulation, some simple stuff. Anybody have made something like this and could help me to start it, I'll make all the work but I need some help from those who already made something like this. Do you have any other idea how could I implement this, what other solution do exists? A alternative would be to use LabView but there are problems, too. No documentation or some help. It would be very good to have some DLL files that would implement functions and interface to the USB data, but even if I was searching for a long time, I couldn't find anything. I'm opened to any suggestion, because right now I'm stuck, I don't have any idea. Thank you very much for any idea. I wish everybody a nice day. Best regards, Sam Evans. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting my feet wet on the Tx side of the world
The TX side of the project is still fairly primitive--they have a hand-coded flow-graph that implements an APCO-25 4-level FSK modulator, using an *audio* sink, and then carefully plugging the audio into the guts of a physical radio, right at the [snipped] Soundcard output direct into a TX is something we'd actually like to have working, but as of yet it hasn't been tested successfully by anyone that I know of. Getting this to work would be HUGE since it would enable use of TX RF hardware that has already received FCC certification in various bands... So, I decided to adapt what they'd done on the audio side to driving a USRP directly (with an appropriate RF card, naturally). Already done! Sorry the docs aren't better. Check out op25_tx.py Max ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [op25-dev] Re: [Discuss-gnuradio] Getting my feet wet on the Tx side of the world
In the case of a real flow-graph, taking real data in at 4800symbols/second, going to a real USRP transmitter, will it still run in fits and starts or will it do the right thing?? It will do the right thing, assuming that all blocks do the right thing and compute as much output as they are asked to. [snip] There are of course complexities. When both ends of the flow graph are connected to hardware, if the clocks aren't synchronized, you get the well-known multiple clocks problem. This can cause data to either overrun or underrun the sink. This multiple-clocks problem has been discussed previously on this list. The op25 TX app has its stretch buffer, Asterisk (PBX) has its jitter buffering, etc. A similar kind of issue you can run into is when local clock drift can cause the *apparent* receive rate to differ somewhat from the nominal value of 4800... More generally, for example in the case where RF transmissions are only intermittent, we have the question of how to keep the blocks happy when *no* data is flowing. Very briefly, one place this manifests is in GR's UDP stuff (used in our remote TX). If you have a GR udp source and it's not receiving a *constant* flow of input, it will give up and shutdown the entire graph. This is also something I've seen mentioned on the GR list. It's *not* a complaint or a request to fix anything, just an observation Best Regards Max p.s. another interesting thing on which to speculate is the effects of the dreaded USRP underrun on the overall integrity of the transmitted spectrum. I've a suspicion that one could see, shall we say, undesired spectral components at the instant in time when the underrun occurs? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Getting my feet wet on the Tx side of the world
On 09/04/2010 08:26 AM, ikjtel wrote: Already done! Sorry the docs aren't better. Check out op25_tx.py Max Ah! Thanks for the pointer! -- 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
Re: [op25-dev] Re: [Discuss-gnuradio] Getting my feet wet on the Tx side of the world
On 09/04/2010 08:56 AM, ikjtel wrote: / In the case of a real flow-graph, taking real data in at/ / 4800symbols/second, going to a real USRP transmitter, will it still/ / run in fits and starts or will it do the right thing??/ It will do the right thing, assuming that all blocks do the right thing and compute as much output as they are asked to. [snip] There are of course complexities. When both ends of the flow graph are connected to hardware, if the clocks aren't synchronized, you get the well-known multiple clocks problem. This can cause data to either overrun or underrun the sink. This multiple-clocks problem has been discussed previously on this list. The op25 TX app has its stretch buffer, Asterisk (PBX) has its jitter buffering, etc. The multi-clocks problem is nothing new. When our packet-radio group built a bit-regenerating 56KBPS repeater in the 1980s, we had to build in a hardware elastic buffer to compensate for clock-skew between Tx and Rx. A similar kind of issue you can run into is when local clock drift can cause the *apparent* receive rate to differ somewhat from the nominal value of 4800... More generally, for example in the case where RF transmissions are only intermittent, we have the question of how to keep the blocks happy when *no* data is flowing. Very briefly, one place this manifests is in GR's UDP stuff (used in our remote TX). If you have a GR udp source and it's not receiving a *constant* flow of input, it will give up and shutdown the entire graph. This is also something I've seen mentioned on the GR list. It's *not* a complaint or a request to fix anything, just an observation Best Regards Max p.s. another interesting thing on which to speculate is the effects of the dreaded USRP underrun on the overall integrity of the transmitted spectrum. I've a suspicion that one could see, shall we say, undesired spectral components at the instant in time when the underrun occurs? If those underruns happen only very occasionally, they'll be no different than analog noise in a traditional analog Tx chain, I'm thinking. -- 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
Re: [Discuss-gnuradio] USRP, GNURADIO, WINDOWS, APPLICATION HELP
thank you very much for your answer. I don't really like Linux because it has many problems. As I'm writing you this message I'm installing Ubuntu on a VirtualPC, everything was OK, but when files were copied to the Virtual drive it gave me a BIG error, some I/O error while copying, so this is what I'm talking about, many problems and is very slow compared to Windows. Flamewar much? Of course its slower, its a virtual machine; and of course it crashed, you were running it on windows! BTW I have a virtual windows running on ubuntu to test UHD compilation. Its slow compared to its host system, but not many problems in the crashing department. Virtualbox FYI Lb4lb, I have found windows to be frustrating as a development environment, and more sluggish with the IO. However, both platforms crash in their own ways and lack support in their own ways. If you just want to get some samples in and out of a USRP2 without using gnuradio as a DSP library then you can use the UHD which builds native on windows: http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki It has USRP1 support, but I have not tested libusb1.0 under windows. So, that being uncharted territory at the moment... -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem on passing complex data from rx_path to tx_path in benchmark_ofdm
Hi, I am currently implement such scheme that have to pass the information(complex data type) from rx_path to tx_path in benchmark_ofdm. The information (complex data) is said to be channel gain that can be calculated by pilot sequence inserted in ofdm symbol, and it can be get from gr_ofdm_frame_acquisition.cc. And I want to make use of this information for next transmitted packet. So I need a method to implement this scheme. Here are some methods that I used to implement but got some problems. 1) In gr_ofdm_frame_acqusition.cc, I save the complex data in a file and read this file when I send a packet. But it seems that saving file will slows down the process and causes the packet fail. 2) I rewrite the io_signature in the block of gr_ofdm_frame_acqusition.cc that increase the output port for the complex data. And connect this port to the transmit path. Like this: Rx-USRP - rx_path --(gr_complex)-- tx_path - Tx-USRP I know the rx_path and tx_path are parallel in GNU Radio. Is it possible to connect these two block with one port? 3) Maybe I can use gr_message. But I don't know how to use it for the data is complex data type. It seems that gr_message is for string data (unsigned char). Can it use for complex or floating data type? Anyone have any suggestions about these problems, please let me know. I am deeply appreciative. Fisheep -- View this message in context: http://old.nabble.com/Problem-on-passing-complex-data-from-rx_path-to-tx_path-in-benchmark_ofdm-tp29621722p29621722.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] Flowgraph running in fits and starts
On Sat, Sep 4, 2010 at 12:19 AM, Marcus D. Leech mle...@ripnet.com wrote: On 09/03/2010 11:52 PM, Eric Blossom wrote: Thought about that, as well. So replaced the graphical FFT sink with a file sink, and set the unbuffered flag. That file fills up in fits and starts'--that is, it spends quite a while with zero bytes in it, then really a lot of bytes, then no more bytes for quite some time, then another lump of bytes, etc. I confirmred that the producer end of the FIFO was producing bytes at the correct rate. So when I'm sending real data to an actual USRP (f'rexample), the symbols will get clocked out at the right rate, provided that I issue those bits in sufficiently large lumps to prevent the USRP from underrun on transmit. But what about situations where you might have a source of bits that's running in real time (like my little test case with the external FIFO), and you'd like the resulting symbols to be clocked out at something resembling real time? My test case was just a test case, but I can certainly imagine situations where it actually matters. Remember that GNU Radio runs stuff through each signal processing block in chunks. These chunk sizes can be around 100 to 32000 items in size, more when there is time to spare and less when the system is trying to operate quickly. When you're running with a sample rate of 4800, that's going to pass 4800 samples each second. At this rate, the GNU Radio scheduler is likely using very large block sizes (you could print out the value of noutput_items in one of the work functions to see for sure). Let's say that, generally, each block is given an noutput_items=8192. That's almost 2 seconds worth of data. I just created a simple flowgraph in GRC with a noise source, throttle, and scope sink. With varying rates on the throttle, you can get see this happening. With such a simple flowgraph, the noutput_items is always either 4095 or 4096, so it's pretty regular. With a rate of 4800, you get a scope update about every second. I've seen something like what you were observing with more complicated flowgraphs with very small sample rates; when the scheduler doesn't produce the same number of items each time through, it runs in fits and starts as you said. Conversely, when running with a source like the USRP, the USRP source is being run at a minimum of 250 ksps, so the flow graph has to work to keep up with that and therefore runs data through the whole graph faster but only because the sinks are being updated with new data more quickly. Like Eric said, remove the throttle or at least change the rate and that should clean things up. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph running in fits and starts
On 09/04/2010 08:08 PM, Tom Rondeau wrote: On Sat, Sep 4, 2010 at 12:19 AM, Marcus D. Leech mle...@ripnet.com wrote Like Eric said, remove the throttle or at least change the rate and that should clean things up. Tom I also noted in the reply to Eric that I observe the same behaviour with an external source that is producing 4800 symbols/second--so it's not the throttle *per se*, but rather the way that work chunks get scheduled in Gnu Radio. With a fast source, you dont find yourself in a situation where there aren't enough chunks to keep things busy. But a very reasonable example would be something like a cross-band digital repeater application, where bits/symbols would be arriving at the channel rate, and need to leave the Tx in something at least approaching real time--you certainly need to have a bit of elastic buffering to compensate for clock-skew between the two sides, but several-tens-of-seconds of latency isn't likely to be very useful in the real world. Note that I'm not criticizing anybody or anything. I'm making observations, and I *do* understand *why* it is the way it is. My little test flow-graph failed the least astonishment test, which is why I felt I needed to comment. Would it be reasonable to open a discussion about this class of flow-graph? I think they can be characterized as flow-graphs with a low symbol rate, and high interpolation (which I think is where the buffer-multiplier effect may be coming into play). In such flow-graphs, would it be reasonable to be able to tweak the scheduler to deal with this type of situation? I have little insight into how the scheduler works in detail, but I think I understand the fits and starts that I was observing. So, is this a reasonable discussion topic? Are other folks working on stuff that will run into part of the performance diagram I ran into yesterday? Or is everyone else working on high-event-rate type signal chains? Cheers -- 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
Re: [Discuss-gnuradio] Flowgraph running in fits and starts
On Sat, Sep 04, 2010 at 08:22:38PM -0400, Marcus D. Leech wrote: On 09/04/2010 08:08 PM, Tom Rondeau wrote: On Sat, Sep 4, 2010 at 12:19 AM, Marcus D. Leech mle...@ripnet.com wrote Like Eric said, remove the throttle or at least change the rate and that should clean things up. Tom I also noted in the reply to Eric that I observe the same behaviour with an external source that is producing 4800 symbols/second--so it's not the throttle *per se*, but rather the way that work chunks get scheduled in Gnu Radio. With a fast source, you dont find yourself in a situation where there aren't enough chunks to keep things busy. But a very reasonable example would be something like a cross-band digital repeater application, where bits/symbols would be arriving at the channel rate, and need to leave the Tx in something at least approaching real time--you certainly need to have a bit of elastic buffering to compensate for clock-skew between the two sides, but several-tens-of-seconds of latency isn't likely to be very useful in the real world. Note that I'm not criticizing anybody or anything. I'm making observations, and I *do* understand *why* it is the way it is. My little test flow-graph failed the least astonishment test, which is why I felt I needed to comment. Would it be reasonable to open a discussion about this class of flow-graph? I think they can be characterized as flow-graphs with a low symbol rate, and high interpolation (which I think is where the buffer-multiplier effect may be coming into play). In such flow-graphs, would it be reasonable to be able to tweak the scheduler to deal with this type of situation? I have little insight into how the scheduler works in detail, but I think I understand the fits and starts that I was observing. So, is this a reasonable discussion topic? Are other folks working on stuff that will run into part of the performance diagram I ran into yesterday? Or is everyone else working on high-event-rate type signal chains? Marcus, This is certainly a reasonable discussion topic. I suggest before wading in that you first enable the scheduler logging that I mentioned in a prior post and take a look at that. Feel free to send me the logs too. What we're looking for is which block is forcing the large chunk size. If you were reading from a file using for example gr.file_source, it won't return until until it's completely filled up the downstream buffer given to it. That's just how it's written. A trivial change would be to have it loop until it it read min(N_USER_SPECIFIED_ITEMS, noutput_items) items. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP, GNURADIO, WINDOWS, APPLICATION HELP
Can u be more specifc on the 'big' error? I use virtualbox all the time, never have issues Sent from my iPhone On Sep 4, 2010, at 6:27 AM, Sam Evans sam_evans1...@yahoo.com wrote: Hi William, thank you very much for your answer. I don't really like Linux because it has many problems. As I'm writing you this message I'm installing Ubuntu on a VirtualPC, everything was OK, but when files were copied to the Virtual drive it gave me a BIG error, some I/O error while copying, so this is what I'm talking about, many problems and is very slow compared to Windows. Anyway I will try to install some older versions, maybe I will have some luck to install it. I would like to make the biggest part by myself, not using LabView or Matlab and neither Linux. What I would like to do is to use Windows environment, to install GNU Radio, emulate python in a OOP environment, meaning - execute scripts in a software and get out data. I don't want to use USRP and GNU Radio to see waveforms (only at the begining when I will try it out and when I will write the script), I want to transfer data, to communicate with other wireless devices, etc. I want to use it in the practical side to transfer data, if I could get 2 bytes of data from a wireless device using microcontroller it would be heaven. This is the hardest part, to transfer my first byte of data, after tha I could make some nice things, nice systems. Thank you very much for your answer and I would be very happy to receive any idea from anybody. Best regards, Sam Evans. From: William Cox wc...@ncsu.edu To: Sam Evans sam_evans1...@yahoo.com; GNU Radio Discussion discuss-gnuradio@gnu.org Sent: Thu, September 2, 2010 6:50:50 PM Subject: Re: [Discuss-gnuradio] USRP, GNURADIO, WINDOWS, APPLICATION HELP Sam, Coming from a Windows user, I have to say that switching to Ubuntu was 1) extremely easy and 2) greatly accelerated my understand and ability to use GNURadio/USRP - mainly because I could use the GRC, which is a Labview-like graphical interface to GNURadio and USRP. I'd *highly* recommend giving it a shot first, at least to learn with, before trying Windows development. That's my 0.02. YMMV. Also check out the Simulink libraries - I think they're linked from Ettus.com -William On Wed, Sep 1, 2010 at 5:36 PM, Sam Evans sam_evans1...@yahoo.com wrote: Hi everybody, I would like to ask some questions regarding USRP. I really need some help. I got my USRP with a WBX and LP0410. I work on a computer running Windows XP. After I read many thing about how to install the GNU Radio in Windows environment I could install it using MingW. I used the gnuinstall.py python script like many others but when I tried to run my first script in python I got an error message ImportError: No module named gnuradio. I don't know what is the problem, the gnuradio is installed, the latest one GNU Radio 3.3.0. Could anybody help me with some ideas, how to make it work, and what I'm missing. The second question would be. I would like to use the GNU Radio for a real application. I want to make a .NET application with Delphi Prism and to be able to get data from USRP an set data. There are many informations out there to emulate python (there are even DLL files) to be able to run python scripts from a .NET application. What I want is to exchange data with some devices running on 2 ISM bands (433 and 868). I will make an application with Visual Studio 2010 and I would like to be abel to read data through python script, interprete data and display in the form as some value or a therometer showing the value sent by a device. Wireless devices will have ASK, OOK modulation, some simple stuff. Anybody have made something like this and could help me to start it, I'll make all the work but I need some help from those who already made something like this. Do you have any other idea how could I implement this, what other solution do exists? A alternative would be to use LabView but there are problems, too. No documentation or some help. It would be very good to have some DLL files that would implement functions and interface to the USB data, but even if I was searching for a long time, I couldn't find anything. I'm opened to any suggestion, because right now I'm stuck, I don't have any idea. Thank you very much for any idea. I wish everybody a nice day. Best regards, Sam Evans. ___ 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
