[Discuss-gnuradio] Problem with last GRC and gnuradio versions
I used old versions of both GRC and gnuradio, and they worked fine in my computer. I have updated both programs to its last versions: http://gnuradio.org/svn/gnuradio/trunkand http://gnuradio.org/svn/grc/trunk and they seem to be incompatible. When I execute GRC in a terminal appears the message: Missing critical module: gnuradio.gr.hier_block2 Exiting! Anyone knows where is the problem? Thanks in advance. Sebastián Blanch ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with last GRC and gnuradio versions
Sebastián Blanch wrote: and they seem to be incompatible. When I execute GRC in a terminal appears the message: The trunk is going through some changes as we ready 3.1 for release. Unfortunately, these changes have broken GRC. There will be one more major update of the trunk (conversion of code to hier_block2) that will cause some churn, then GRC can catch up with a reasonable expectation that GNU Radio won't incompatibly change underneath it. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] list of gnuRadio apps for USRP ?
Hi all, Relative newbie to the list. Got my GnuRadio installed on an OSX machine and my USRP hardware working (Thanks Michael!). I have the basic LF TX and RX, plus TV tuner and a few other daughterboards. I have had the oscope.py script running ok. The hf_radio seems to hang after starting and before drawing all the screen items. Is there a webpage complete list of the various apps and test scripts that are included in various directories with the install or indeed available on the web from anywhere which I can try out, along with a brief description of what they should do? I realise there is a readme in the various directories of apps in the distribution but wondered if anyone had put all these together in a table on the web somewhere. I didn't find such a thing on the wiki so far. Just need to see if there are any impressive test apps I can use to demo the platform thus far before attempting to develop things further. Many thanks for any pointers. Jonathan. -- winmail.dat___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] buffer sizes, timing and overflows
Hi, I am writing a simple program that stores USRP sampled data and stores it on disk continuously in 1s sized files. I have made a new sink for this purpose, which is almost identical to gr_filesink, except that mine blocks in work() while the file is closed and a new one is created. I have only been using USRP for a couple of days, so I have some hopefully simple questions: 1) I would like to get as accurate timestamp as possible to the beginning of the dump to make later analysis easier. What would be the best way to estimate the time delay between fg.run() and the moment when the first sample comes out of the down converter? 2) I have managed through trial and error to get a fairly reliable 8MHz sampling system using the following parameters: fusb_nblocks=32768,fusb_block_size=1024. Is this a good way to make a large buffer or should I use some other gnuradio block to create a large buffer in RAM? I am hoping to write the data at 8MHz on a networked RAID array and this will cause even larger waiting times for my filesink, even though the average bandwidth is large enough. 3) Another question: is there any way to query the driver if a buffer overflow has occurred and maybe throw an exception? I am going to sample continuously for long durations and it would be nice to be able to restart sampling automatically if an overflow is detected due to some reason. 4) What happens in an overflow situation? Do I still get the correct amount of samples, albeit with wrong samples, or are the missing samples just tossed away? Gnuradio and USRP is great! I really prefer your system to labview. Best regards, juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] list of gnuRadio apps for USRP ?
[EMAIL PROTECTED] wrote: Hi all, Got my GnuRadio installed on an OSX machine ... ... The hf_radio seems to hang after starting and before drawing all the screen items. I experienced the same thing on other apps. It's usually a result of trying to render too many fps on the screen. Try reducing any fft_sinks from 15 to 10 fps, and change the oscope's frame decimation from 1 to 2. That usually works for me. Reducing the sample rate can also work if you can get away with the lower rate in the rest of your app. @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Packet mod/demod race condition?
Hi Steven, If I uncomment the sleep, I never see this message. So: Q1) Any idea what this error is all about? Is this a race condition that needs to be addressed, or am I doing something wrong? This part I'm not sure about. Q2) The original audio file is 350.0KB. Sometimes the resulting audio file is complete, other times it never gets the last few KB (ends up 341.0KB, for example). How do I ensure that all the bytes make it across successfully? The benchmark loopback code makes no guarantee of delivery. In order to do so, you need some method or higher level protocol to detect and retransmit any dropped frames. Though in your case, I wouldn't expect the received file to vary per run. Again, I'm not sure here. Q3) What is the effect of packet size? Is there an optimum size? A max size? For USRP, packets need to be padded to a multiple of XXX? The optimal size depends on the given application. Latency and overhead might be two considerations. The max packet size is limited by the length of the whitener PN sequence. I don't believe there are any restrictions beyond that. The USRP will view the data in a stream form; it won't have any notion of the data packet length at that point. Q4) Some examples use gr.enable_realtime_scheduling(). What is the effect of this, and do I need it? I note that it requires a sudo. Realtime scheduling changes the scheduling policy of selected threads to a priority over normal threads. In Linux, root access is required in order to do so. It should result in more lower latencies and more deterministic behavior. Thanks for your time! -Steven Anytime. -TT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DBSRX and bias voltage issue
Hello! I am experimenting with an old Primestar DBS dish and GNU Radio using the USRP and the DBSRX daughterboard. In order to power the dish's LNB, I need to send 12 volts up the antenna line. After reading previous posts to the GNU Radio mailing list about antenna bias and the DBSRX, I decided against a bias tee and applied 12 volts at 300 mA to the J100 jumper on the DBSRX. When I hooked everything up indoors, I measured 12 volts, as expected, at the LNB end of the coax. Thinking all was well, I disconnected everything and moved the whole setup outdoors to start experimenting. However, after reconnecting everything, I now measured only 5 volts at the LNB end of the coax. Working backwards, I measured 12 volts at the J100 pins and 5 volts downstream. I recalled from previous posts that shorting J101 would give 5 volts from the USRP power supply. To be certain that this wasn't happening in this case, I disconnected the 12 volt supply and measured no voltage on the line. Reconnecting the 12 volt supply to J100 restored 5 volts to the line. I saw a reference in a previous post that, with the 5 volts in place from jumping J101, the DBSRX could not withstand a short at the SMA connector. According to the post, a small inductor acting as a fuse would be fried but could be replaced. Of course my first suspicion is that I caused this, maybe by an accidental short across the coax while measuring the voltage or connecting to the LNB. However, the fact that I'm still getting 5 volts as opposed to no voltage, like with a blown fuse, makes me wonder. I would greatly appreciate any insight or suggestions for additional diagnostics that you might have. Thanks in advance. Jon Jennings ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM GRC block attempt
Josh Blum wrote: I reimplemented the packet modulator/demodulator in GRC, and updated the packet_mod_demod.grc.xml example. The packet modulator can be used interchangeably with the gmsk, psk, and qam modulators (same for demod). See PacketModHelper and PacketDemodHelper in http://gnuradio.org/trac/browser/grc/trunk/src/SignalBlockDefs/Packet.py Here is a screen shot of the example that may help explain what I was talking about, and why: http://www.joshknows.com/tmp/packet_mod_demod.grc.xml.png Thanks! GRC has been a huge help for our development/testing efforts. I suppose that until m-blocks come around, these packet blocks in grc are the only way a user can actually use a gmsk, psk, or qam de/modulator. I will add the ofdm mod/demod, once its hier2 version is merged. The ofdm modulator will be implemented in a similar manner: GRC will have a ofdm wrapper block that reads from a message source and calls ofdm_mod.send_pkt. (I do this so that the output of any block in grc can be used with the ofdm_mod block). Again: similar story with ofdm demod. I'm still not entirely sure what the difference between the hier and hier2 versions are? Is there anywhere that discusses this? I've checked the wiki and the mailing list with no results. Thanks, Dev ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: hier_block2 stuff (was: OFDM GRC block attempt)
Dev Ramudit wrote: I'm still not entirely sure what the difference between the hier and hier2 versions are? Is there anywhere that discusses this? I've checked the wiki and the mailing list with no results. This will get documented as we release 3.1. Release 3.1 will have entirely rewritten flow graph construction and handling code, and will support arbitrarily nested flow graphs. (We're leaving in the old way of doing things until release 3.2 to give people time to convert their code.) Instead of deriving your own flow graph class from gr.flow_graph, you now derive your own 'top block' class from gr.top_block. You wire up gr-blocks in the usual way, with self.connect. Hierarchical blocks can now have arbitrary numbers of input and output ports. You derive them from gr.hier_block2 (instead of the old gr.hier_block), then and in their __init__ function, you tell the parent class how many ports of each there will be. Hierarchical blocks can be connected into a flowgraph the same way you'd connect a gr-block. Internal to the hierarchical block, you wire the inputs and outputs to an internally defined flow graph, which can itself contain hierarchical blocks, etc. So simple, flat flow graphs work almost identically--substitute gr.top_block for gr.flow_graph and you're done. For complex flow graphs, you can now encapsulate a portion of a flow graph in to a hierarchical block definition, wire the inputs and outputs to the internal blocks, and use this composite block wherever you'd use a gr-block. This kind of nested, hierarchical design allows modularity and reuse. As an aside, all the new flow graph code is written in C++. This allows compiling pure C++ GNU Radio apps. But it won't be until release 3.2 that the C++ code for the USRP daughterboards, audio handling, build infrastructure, and C++ only example applications will be completed. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM GRC block attempt
I'm still not entirely sure what the difference between the hier and hier2 versions are? Is there anywhere that discusses this? I've checked the wiki and the mailing list with no results. The hier blocks were a way to hide a linear chain of blocks inside a macro block, and all blocks ultimately reside in one top level flow graph. However, this method of doing things is being phased out of gnuradio in favor of the hier2 blocks. hier2 blocks offer a fully hierarchical approach. A hier2 block can contain any number of gr blocks and hier2 blocks. These blocks may connect to any number of input and output ports. A hier2 block is itself, a flow graph. And the highest level hier2 block is nothing more than a hier2 block with no IO ports, this is called gr.top_block. hier2 blocks should offer everything that hier blocks offer, but also, can do a lot more. The gnuradio trunk is towards the end of switching from hier to hier2. Currently, both types of blocks work in the gnuradio trunk, but are incompatible with one another. Also, the blks2 package is still missing some blocks that you would find in blks. GRC uses the hier2 format, but continued to support the hier blocks (due to some hackery) until the incompatible trunk check in. Just another week or so, and all the GRC blocks should be functional again. -Josh Thanks, Dev ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
