[Discuss-gnuradio] N210 non-uhd?
Can I burn the USRP2 non-UHD firmware on an N210? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] sine output between packets
It seems my old patch that zeroed out the output of the USRP didn't make it into UHD- we're seeing a constant sine output between packets- and in our case this messes with the receiver unless we use some custom TX cards that have an amp we can shut down with ATR. Is there any way to fix this? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD changes and reconfiguration
We have a flowgraph that does a full stop, some disconnects and a restart during its execution. Before the latest UHD version bump, this worked fine, but now it goes silent after the upgrade without any apparent failures. Is dynamic reconfiguration now broken- either on purpose or accidentally? Has anyone else seen this? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD quadrature sampling help
We have a number of old flowgraphs that take advantage of quadrature sampling and work fine in USRP1 non-uhd, but once converted to UHD (for USRP1 and 2), we've been wholly unable to come up with subdev specs that work- the I and Q are not synchronized in any way and any change in frequency changes the relative phase between I and Q. The main flowgraphs we're trying to convert are Charles Swiger's VNA and related flowgraphs from http://swigerco.com/gnuradio/index.html . Can anyone offer some proven working flowgraphs, or reduced version of them, for UHD that depend on quadrature sampling at the USRP (LFRX or BasicRX) as an example to us? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] throttle for very low data rates
I have a loop block that I wanted to run very slow (1Hz), and put a throttle block set to rate 1. Unfortunately, it seems to tear through the first 8-9k samples in a blink before it slows down. Is there an alternative implementation of the throttle block that would work at very slow speeds? Perhaps rather than memcopying the entire batch of samples passed into the work function, it would loop copy and deal with rate and sleeps during the loop? Obviously this wouldn't be optimal for fast rate blocks, but what about creating a separate throttle optimized for slow data rates? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Are there any Gnuradio Events?
Lets say you have a GUI app that has a fixed runtime determined by a head block set to (sample_rate * n_seconds). Currently, the gui keeps running. Is there an OnShutdown or some function I can override to catch the flowgraph completion? Worst case, can I set up a loop thread to check tb.is_running or something to that effect? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] super minor UHD Subdev "bug"/feature request
I have a UHD app I'd like to work with USRP1 and 2- but when I give USRP2:
self.dut_out.set_subdev_spec("A:A A:B", 0)
it complains about the A's and I have to specify ":A :B" instead, but
for USRP1 it needs the A.
It would be a nice simplification if the USRP2 allowed A:whatever since
it technically has a side A and just no B.
I'm about to look in the .h files right now, but is there a quick way,
given a self.usrp = uhd.usrp_source() to call self.usrp.is_usrp2() or
something?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] libusb1 not the solution to USRP crashing
I just discovered the not well published --with-fusb-tech=libusb1 option to configure, hoping to resolve the USRP1 non-uhd crashing issues myself and one other person are seeing when the flowgraphs do a lock or stop. Unfortunately, I still see the same lockup, which rules out any libusb-0.1 possibilities. I removed libusb-devel from my system and recompiled gnuradio with the libusb1 option. You can see libusrp in the ldd here as well. [root@aurora ~]# ldd /usr/local/lib64/libusrp-3.4.0git.so.0 linux-vdso.so.1 => (0x7fffbb5ff000) libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x7f54a2ca8000) libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5 (0x7f54a2a93000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7f54a278d000) libm.so.6 => /lib64/libm.so.6 (0x7f54a24dd000) libc.so.6 => /lib64/libc.so.6 (0x7f54a214b000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f54a1f35000) librt.so.1 => /lib64/librt.so.1 (0x7f54a1d2d000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f54a1b0f000) /lib64/ld-linux-x86-64.so.2 (0x003f0c60) RHEL-6 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Complex / Quadrature sampling
With UHD, what's the proper way to use the A and B connectors on an LFRX to get quadrature sampling? I've tried setting subdev spec as A:AB but it doesn't seem to work with the UHD source at anything other than 0 for the frequency for both USRP1 and USRP2 via UHD. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb: (rd status -2) No such file or directory
This is precisely the problem I'm seeing that kills my USB. I have to ctrl+c to keep that from happening. On 05/27/2011 12:05 PM, Johannes Schmitz wrote: > I made a simple example to show how it happens. > It is a problem of lock/unlock in combination with usrp. > > Like this the lock unlock disconnect seems to absolutely unusable :( > > - > > #!/usr/bin/env python > > from gnuradio import gr > from gnuradio import usrp > > from time import sleep > > class top_block(gr.top_block): > def __init__(self): > gr.top_block.__init__(self, "fusb error") > > self.u = usrp.source_c () > self.sink = gr.null_sink(gr.sizeof_gr_complex) > self.connect(self.u, self.sink) > > def reconfigure(self): > self.lock() > print 'lock' > self.unlock() > print 'unlock' > > if __name__ == '__main__': > app = top_block() > app.start() > #sleep(1) > print 'start' > app.reconfigure() > print "reconfigured" > sleep(1) > print 'now stopping' > app.stop() > print 'stopped' > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] libusb-0.1 versus libusb-1.0
So after discovering that while I had libusb-devel-0.1 and libusb1-devel-1.0.3 installed on my RHEL-6 machine here (and ubuntu), gnuradio compiled against 0.1 despite 0.1 being "ancient and unsupported". I then removed libusb-devel and gnuradio fails to configure. [root@aurora gnuradio]# ls -lad /usr/lib64/libusb-1.0* -rw-r--r--. 1 root root 81950 Nov 19 2009 /usr/lib64/libusb-1.0.a lrwxrwxrwx. 1 root root19 Jan 4 22:50 /usr/lib64/libusb-1.0.so -> libusb-1.0.so.0.0.0 lrwxrwxrwx. 1 root root19 Jan 2 17:59 /usr/lib64/libusb-1.0.so.0 -> libusb-1.0.so.0.0.0 -rwxr-xr-x 1 root root 54976 Nov 19 2009 /usr/lib64/libusb-1.0.so.0.0.0 [root@aurora gnuradio]# rpm -qa | grep -i libusb libusb1-static-1.0.3-1.el6.x86_64 libusb1-1.0.3-1.el6.x86_64 libusb1-devel-1.0.3-1.el6.x86_64 libusb-0.1.12-23.el6.x86_64 [root@aurora gnuradio]# ./configure --enable-docs --enable-grc --enable-gnuradio-examples --enable-gr-utils --enable-gr-sounder --enable-gr-qtgui --enable-gr-wxgui --enable-gr-video-sdl --enable-gr-trellis --enable-gr-radio-astronomy --enable-gr-pager --enable-gr-noaa --enable-gr-gsm-fr-vocoder --enable-gr-gpio --enable-gr-cvsd-vocoder --enable-gr-atsc --enable-gr-audio-jack --enable-gr-audio-alsa --enable-gr-usrp2 --enable-gr-usrp --enable-usrp2 --enable-usrp --enable-gnuradio-core --enable-gruel --enable-python --enable-gr-uhd checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu ... ... configure: Checking for LIBUSB version 'libusb' checking for USB... no configure: Checking for LIBUSB version 'libusb-legacy' checking for USB... no Unable to find dependency libusb. checking for sdcc... sdcc -mmcs51 --no-xinit-opt checking for asx8051... asx8051 -plosgff checking sdcc_version "2.9.0"... 2.9.0 configure: error: Component usrp has errors; stopping. So just what is the status with libusb. Should it be compiling against libusb-0.1 or should it be compiling against libusb-1.0 and if so, why isn't configure finding libusb-1.0 on Ubuntu or RHEL-6? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion
On 05/26/2011 09:14 PM, Brett L. Trotter wrote: > On 05/26/2011 08:06 PM, Nick Foster wrote: >> On Thu, 2011-05-26 at 19:29 -0500, Brett L. Trotter wrote: >>> USRP1: >>> - When we have a very simple flowgraph with a USRP1 sink connected to a >>> signal source and a USRP1 source connected to a WX scope- trying to shut >>> down the app using the close box causes the USB on the host system to >>> freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids >>> this problem. This problem exists on many flowgraphs, both GRC generated >>> and not- as far as I know it is limited to flowgraphs with both USRP1 >>> source and sink. This is a serious problem that has hit us on multiple >>> platforms and machines and causes unnecessary reboots. It is honestly an >>> unacceptable bug. >> UHD or gr-usrp? What OS? What version of libusb? Do all USB devices >> "freeze" or just the USRP? Does power cycling the USRP un-freeze it? >> This is definitely not something I've seen before. > gr-usrp > Ubuntu x86_64 with libusrp /usr/lib/libusb-0.1.so.4.4.4 > RHEL-6 x86-64 with libusrp /usr/lib64/libusb-0.1.so.4.4.4 > I believe I've also seen it on FC14 and RHEL5 > > USB devices continue to function, but it will not recognize new > connection events of any device, the USRP will not reinitialize even if > power cycled and reconnected, even to a different port. > Correction- apparently there's libusb1 installed here. Silly me looking for /usr/lib/libusb-*. RHEL-6: libusb1-static-1.0.3-1.el6.x86_64 libusb-devel-0.1.12-23.el6.x86_64 libusb1-1.0.3-1.el6.x86_64 libusb-static-0.1.12-23.el6.x86_64 libusb1-devel-1.0.3-1.el6.x86_64 un ia32-libusb-0.1-4 ii libusb-0.1-4 2:0.1.12-15ubuntu2 ii libusb-1.0-0 2:1.0.8-2 ii libusb-1.0-0-dev2:1.0.8-2 ii libusb-dev 2:0.1.12-15ubuntu2 un libusb0 ii libusbmuxd1 1.0.4-1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion
On 05/26/2011 08:06 PM, Nick Foster wrote: > On Thu, 2011-05-26 at 19:29 -0500, Brett L. Trotter wrote: >> USRP1: >> - When we have a very simple flowgraph with a USRP1 sink connected to a >> signal source and a USRP1 source connected to a WX scope- trying to shut >> down the app using the close box causes the USB on the host system to >> freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids >> this problem. This problem exists on many flowgraphs, both GRC generated >> and not- as far as I know it is limited to flowgraphs with both USRP1 >> source and sink. This is a serious problem that has hit us on multiple >> platforms and machines and causes unnecessary reboots. It is honestly an >> unacceptable bug. > UHD or gr-usrp? What OS? What version of libusb? Do all USB devices > "freeze" or just the USRP? Does power cycling the USRP un-freeze it? > This is definitely not something I've seen before. gr-usrp Ubuntu x86_64 with libusrp /usr/lib/libusb-0.1.so.4.4.4 RHEL-6 x86-64 with libusrp /usr/lib64/libusb-0.1.so.4.4.4 I believe I've also seen it on FC14 and RHEL5 USB devices continue to function, but it will not recognize new connection events of any device, the USRP will not reinitialize even if power cycled and reconnected, even to a different port. >> USRP2 / UHD: >> - With a similar flowgraph to the one above, changing the secs/div >> causes the various traces to change phase relative to one another but >> this doesn't happen when a USRP1 source is substituted. However, I >> believe this is indicative of a deeper problem. We also see with the >> same flowgraph and a slider that controls both the TX and RX frequencies >> simultaneously, the flowgraph gets into a place where it seems to be >> getting data but it no longer represents the state of what's coming in >> and we also see the phase slippage. Long story short, create a flowgraph >> with a UHD (USRP2) sink and source with a siggen at a fixed >> frequency/amplitude, a wx scope, and a slider that sets the TX+RX >> frequencies to the slider value. Direct connect the TX to the RX with an >> SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX >> this seems to give various results. Do the same thing with a USRP1 for >> comparison. To me it seems like UHD is losing data or the various paths >> in the flowgraph get out of whack with eachother. There were no O's or >> U's printed. > If you lose samples somewhere in the chain, which can happen, the TX and > RX paths will change their relative alignment. Have you tried reducing > your sample rate, or the refresh rate on the graphical sink? The various > graphical sinks can be very CPU-intensive. > > It is generally not a great idea to rely on the TX and RX paths staying > aligned with respect to each other all the time. The fact that the USRP1 > seems to in your test is a bonus, but I wouldn't rely on that going > forward either. > > If you require the TX and RX paths to maintain a fixed relationship, the > USRP2 with UHD will let you use timed samples to achieve this down to > 10ns. You could also align your TX and RX paths in your application, > using known TX waveforms to correlate the RX against. This approach > probably fits best into your design flow (don't have to code C++ with > UHD). > > --n The alignment I'm talking about wasn't even relative between RX and TX- it was between branches of the RX path such as the real and imaginary components of that path when viewed on the scope. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion
Replying to self- here's another case on the USRP2/UHD- TX Path: Sig Source -> UHD (USRP2) Sink RX Path: UHD (USRP2) Source -> Band Pass Filter -> Scope Sink It seems that any kind of filter, even with appropriate calculation of the rate coming out of the filter taking into account decimation will yield a very delayed signal on the scope sink. The same problem does not happen on USRP1 when the sinks are swapped out and the sample rates adjusted appropriately. On 05/26/2011 07:29 PM, Brett L. Trotter wrote: > USRP1: > - When we have a very simple flowgraph with a USRP1 sink connected to a > signal source and a USRP1 source connected to a WX scope- trying to shut > down the app using the close box causes the USB on the host system to > freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids > this problem. This problem exists on many flowgraphs, both GRC generated > and not- as far as I know it is limited to flowgraphs with both USRP1 > source and sink. This is a serious problem that has hit us on multiple > platforms and machines and causes unnecessary reboots. It is honestly an > unacceptable bug. > > USRP2 / UHD: > - With a similar flowgraph to the one above, changing the secs/div > causes the various traces to change phase relative to one another but > this doesn't happen when a USRP1 source is substituted. However, I > believe this is indicative of a deeper problem. We also see with the > same flowgraph and a slider that controls both the TX and RX frequencies > simultaneously, the flowgraph gets into a place where it seems to be > getting data but it no longer represents the state of what's coming in > and we also see the phase slippage. Long story short, create a flowgraph > with a UHD (USRP2) sink and source with a siggen at a fixed > frequency/amplitude, a wx scope, and a slider that sets the TX+RX > frequencies to the slider value. Direct connect the TX to the RX with an > SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX > this seems to give various results. Do the same thing with a USRP1 for > comparison. To me it seems like UHD is losing data or the various paths > in the flowgraph get out of whack with eachother. There were no O's or > U's printed. > > We were trying to do a simple VNA in UHD and it just doesn't work as > expected, but switching it all over to a USRP1 its fine and dandy. > > > > > On a general note- I think there should be two new block sets added: > 1) A simple source block that provides samples in the appropriate format > (float, complex, etc depending on the _f / _c etc) which generates as > fast as possible and counts how many it generates in a second which gets > output on a float output. > > 2) The same thing but a consumer. > > The idea being it would help diagnose blocks that end up putting out > more or less data than they take in and whose decimation/interpolation > rates aren't apparent. For instance, I have a decimating filter block > that appears to actually be producing more samples than it takes in, > causing the data to show up almost 30 seconds later on the scope which > is set at the source's data rate. I'd love to put the timed consumer and > timed provider blocks on either side and see how the in/out amounts compare. > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP1 problem, UHD problem, and one suggestion
USRP1: - When we have a very simple flowgraph with a USRP1 sink connected to a signal source and a USRP1 source connected to a WX scope- trying to shut down the app using the close box causes the USB on the host system to freeze up requiring a reboot. Yanking USRP power or ctrl+c'ing avoids this problem. This problem exists on many flowgraphs, both GRC generated and not- as far as I know it is limited to flowgraphs with both USRP1 source and sink. This is a serious problem that has hit us on multiple platforms and machines and causes unnecessary reboots. It is honestly an unacceptable bug. USRP2 / UHD: - With a similar flowgraph to the one above, changing the secs/div causes the various traces to change phase relative to one another but this doesn't happen when a USRP1 source is substituted. However, I believe this is indicative of a deeper problem. We also see with the same flowgraph and a slider that controls both the TX and RX frequencies simultaneously, the flowgraph gets into a place where it seems to be getting data but it no longer represents the state of what's coming in and we also see the phase slippage. Long story short, create a flowgraph with a UHD (USRP2) sink and source with a siggen at a fixed frequency/amplitude, a wx scope, and a slider that sets the TX+RX frequencies to the slider value. Direct connect the TX to the RX with an SMA cable. Run the flowgraph and move the slider. At least on LFTX/RX this seems to give various results. Do the same thing with a USRP1 for comparison. To me it seems like UHD is losing data or the various paths in the flowgraph get out of whack with eachother. There were no O's or U's printed. We were trying to do a simple VNA in UHD and it just doesn't work as expected, but switching it all over to a USRP1 its fine and dandy. On a general note- I think there should be two new block sets added: 1) A simple source block that provides samples in the appropriate format (float, complex, etc depending on the _f / _c etc) which generates as fast as possible and counts how many it generates in a second which gets output on a float output. 2) The same thing but a consumer. The idea being it would help diagnose blocks that end up putting out more or less data than they take in and whose decimation/interpolation rates aren't apparent. For instance, I have a decimating filter block that appears to actually be producing more samples than it takes in, causing the data to show up almost 30 seconds later on the scope which is set at the source's data rate. I'd love to put the timed consumer and timed provider blocks on either side and see how the in/out amounts compare. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Non SDHC Card Availability for USRP2s
I discovered today that almost no big retailer (newegg, bestbuy, etc) except amazon appears to sell 1 GB SD cards any more and 2GB cards are probably going to be headed that way sooner or later. 2GB cards, while also overkill on the USRPs, are riskier to buy since some may be SDHC. What's the long term plan for making sure we have cards we can stick in these things? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] writing a c++ block that can access other blocks
Follow up to self here- can anyone confirm whether I'm understanding
this right?
Looks like gr_edge_vector_t is a shared/static vector with all the edges
Say I take this guy from gr_hier_block2_detail and modify it:
gr_edge_vector_t edges, tmp = d_fg->edges();
gr_edge_vector_t::iterator p;
for (p = tmp.begin(); p != tmp.end(); p++) {
if ((*p).src().block() == block || (*p).dst().block() == block) {
edges.push_back(*p);
if (GR_HIER_BLOCK2_DETAIL_DEBUG)
std::cout << "disconnect: block found in edge " << (*p) <<
std::endl;
}
}
so that it tests to see if the block is an instance of a usrp/usrp2
block? Would that do? Ultimately I can assume there'll only be one usrp
connected in my application, and through the one (be it source or sink)
i can get to the dboard iface for either card (rx or tx) and manipulate io?
Assuming the above is sound, is there any potential for harm in messing
with things this way?
And taking my original goal a step further for the sake of discussion,
what if instead of an AGC I just wanted a block that gives a handle to
the gain controls. Does GnuRadio have any facility for blocks that
aren't really part of the flowgraph in terms of moving data, but just
provide an instance of some sort of control?
Thanks!
On 05/22/2011 04:09 PM, Brett L. Trotter wrote:
> I'm looking for a way to create a block that can find the USRP source
> and/or sync in the flowgraph and be able to get to the dboard iface for
> doing write_aux_dac and write_io. Bottom line I'd like to write an AGC
> block that can manipulate a custom card. Is there a facility for finding
> other block instances, or some other way of finding the USRP?
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] writing a c++ block that can access other blocks
I'm looking for a way to create a block that can find the USRP source and/or sync in the flowgraph and be able to get to the dboard iface for doing write_aux_dac and write_io. Bottom line I'd like to write an AGC block that can manipulate a custom card. Is there a facility for finding other block instances, or some other way of finding the USRP? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] grc/blocks/blks2_variable_sink_x.xml gone in the last few weeks
Why/when was variable sink removed? It seems to have been in the last few weeks. It's still used in gnuradio-examples/grc/simple/var_sink_taps.grc among a bunch of places in our own code. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 set_gpio_ddr
I did a bench experiment here and observed that set_gpio_ddr is required
on a tx card but not an rx card. Is this intended?
Here is iotest.py (Python 2.5 required for ternary I used)
#!/usr/bin/env python
I2C_DEV_EEPROM = 0x50# 24LC02[45]: 7-bits 1010xxx
I2C_ADDR_BOOT = (I2C_DEV_EEPROM | 0x0)
I2C_ADDR_TX_A = (I2C_DEV_EEPROM | 0x4)
I2C_ADDR_RX_A = (I2C_DEV_EEPROM | 0x5)
I2C_ADDR_TX_B = (I2C_DEV_EEPROM | 0x6)
I2C_ADDR_RX_B = (I2C_DEV_EEPROM | 0x7)
from gnuradio import uhd
from gnuradio import eng_notation
from gnuradio.eng_option import eng_option
from optparse import OptionParser
import time
if __name__ == '__main__':
device = uhd.usrp_sink(
device_addr="addr=192.168.10.2",
io_type=uhd.io_type_t.COMPLEX_FLOAT32,
num_channels=1,
)
cmd_handle = device.get_dboard_iface()
cmd_handle.set_gpio_ddr(uhd.dboard_iface.UNIT_TX, 0x, 0x)
#cmd_handle.set_gpio_ddr(uhd.dboard_iface.UNIT_RX, 0x, 0x)
toggle = False
while True:
print ("True" if toggle else "False")
cmd_handle.set_gpio_out(uhd.dboard_iface.UNIT_TX, (0x if
toggle else 0x), 0x)
cmd_handle.set_gpio_out(uhd.dboard_iface.UNIT_RX, (0x if
toggle else 0x), 0x)
toggle = ~toggle
time.sleep(1)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help using gri_glfsr from an external app
Replying to myself here- I've resolved the issue. In my previous email, I also cut/pasted the wrong affected line from a different file. The line was actually originally d_glfsr = new gri_glfsr::gri_glfsr(mask, seed) which compiled fine but now things have changed somewhere and the gri_glfsr:: part needed to go. It now compiles fine. On 05/03/2011 04:49 AM, Brett L. Trotter wrote: > I have an application I've been compiling fine against gnuradio for > several years, including recent ubuntu and RHEL-6, until I tried it on > FC14. For some reason, on FC14, it seems like gri_glfsr is > improperly/inadequately defined or not linked properly. Long story > short, after the #include , I can test that > INCLUDED_GRI_GLFSR_H is defined, so it doesn't seem to be an include > path issue. I have a "gri_glfsr *d_glfsr;" and then the line in question > is "d_glfsr = new gri_glfsr(mask, seed);" which complains "error: cannot > convert ‘int*’ to ‘gri_glfsr*’ in assignment" > > can anyone help me understand what's the matter here and moreover why it > only happens for me on FC14? > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] help using gri_glfsr from an external app
I have an application I've been compiling fine against gnuradio for several years, including recent ubuntu and RHEL-6, until I tried it on FC14. For some reason, on FC14, it seems like gri_glfsr is improperly/inadequately defined or not linked properly. Long story short, after the #include , I can test that INCLUDED_GRI_GLFSR_H is defined, so it doesn't seem to be an include path issue. I have a "gri_glfsr *d_glfsr;" and then the line in question is "d_glfsr = new gri_glfsr(mask, seed);" which complains "error: cannot convert ‘int*’ to ‘gri_glfsr*’ in assignment" can anyone help me understand what's the matter here and moreover why it only happens for me on FC14? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Motorola IIi Hybrid Trunk decoding
Has anyone written a motorola trunk decoder for gnuradio? I'd like to be able to dump all active audio in a trunk to separate streams by talkgroup. I'd love to know about any trunk decoders in general. Thanks! -Brett ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD memory leak?
swig/python detected a memory leak of type 'uhd::usrp::multi_usrp::sptr *', no destructor found. Anyone seen this before? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] PyQwt5 and RHEL-6
Who do we petition to get PyQwt5 included in RHEL-6? It compiles straightforwardly from Fedora 15 SRPM, so it shouldn't be a problem. This new build requirement means one can't build GnuRadio with stock RPMs even on RHEL 6 now otherwise. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp.source_c python object to usrp_open_cmd_interface on selected subdev?
I desperately need to know how to get from a usrp.source_c python object down to what would be the result of going through usrp_prims.usrp_open_cmd_interface? Can anyone help? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usb errors while stopping flowgraph
I'm sure this has been asked many times, but if you would be so kind as
to offer any hints where to look for solutions or what to test, it would
be much appreciated.
I've got several different flowgraphs here that upon shutting down some
portion of the time, they emit a series of errors and then totally tank
my USB controller on a number of test systems, requiring a full system
reboot to reset the USB (the RHEL6 box I'm using has USB modules
compiled into the kernel, so rmmod isn't an option). The flowgraphs stop
normally about 3/4 times. It seems to be chance when its in some odd
state that it won't shutdown right.
Relevant code:
tb = top_block()
tb.start()
raw_input("Press Enter to quit: \n")
tb.stop()
tb.wait()
Errors emitted:
usb_control_msg failed: error sending control message: Connection timed out
write_cmd failed
usrp_basic_tx: set_tx_enable(false) failed
usb_control_msg failed: error sending control message: Connection timed out
write_cmd failed
usrp_basic_rx: set_fpga_rx_enable failed
usb_control_msg failed: error sending control message: Connection timed out
write_cmd failed
usb_control_msg failed: error sending control message: Connection timed out
write_cmd failed
usrp_basic_rx: failed to fini AD9862 RX regs
usb_control_msg failed: error sending control message: Connection timed out
write_cmd failed
usb_control_msg failed: error sending control message: Connection timed out
write_cmd failed
usb_control_msg failed: error sending control message: Connection timed out
write_cmd failed
usb_control_msg failed: error sending control message: Connection timed out
write_cmd failed
usrp_basic_tx: failed to fini AD9862 TX regs
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] daughterboard PCB/PADS files?
I see that http://code.ettus.com/redmine/ettus/projects/public/documents has the PDFs, but are the PCB/PADS files still around for any of these boards? If the answer is no, then is "open source hardware" becoming "open, but we don't want to make it too easy since we make money on these". If yes, then kindly skip over that last part :) -Brett ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] book/video (MIT courseware, whatever) recommendations?
Is there one or two books that give a pretty comprehensive, yet low base communications/DSP knowledge requirement that would be a guided walkthrough of waves and fields, various forms of modulation, carriers, filters, sidebands, etc? I'm really looking for something that's either not a textbook, or not written like one- most textbooks are very dry and hard to understand without someone guiding the experience and asking the right questions. I realize the material is fairly dry, so I understand that it's not going to be a crichton novel, but the less crazy math and algorithm intensive it is, the better. Long story short, what's a good way to get a more solid grasp of how driving a DAC can create electromagnetic waves, and what can one do with those waves. I'd really really like to walk away understanding how complex numbers turn into constellations are really formed as an electromagnetic wave, etc, and the real guts of some basic things like FM and DSSS. -Brett ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DB EEPROM location 0x20
The card I'm looking at (an LFRX variant) has the proper checksum in 0x1F (0x17), but then byte 0x20 has 0x04 with the remaining data 0xFF I previously thought I understood 0x20 began the region where we could do what we wanted, but I'm now not so sure. If I was going to store some custom data, where does that region begin and what is the significance of the 0x04 in 0x20? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] timestamp recorded stream
I'd like to record raw broadcast (rx_cfile) with either a USRP1 or USRP2 (have both) but with all samples known to as accurate as the system clock, preferably millisecond to sub-millisecond accuracy. I considered writing a block that outputs the number of milliseconds since midnight as shorts that get interleaved into the datastream? Has anyone accomplished anything like this before? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD: get_center_freq ?
Sorry for the delay- I sent this 02/02/11 from an email that's not
subscribed.
On 02/02/2011 04:48 PM, Josh Blum wrote:
>
> On 02/02/2011 12:48 PM, Brett L. Trotter wrote:
>> gr-usrp has set_tx_freq and tx_freq
>>
>> uhd has set_center_freq but no get_center_freq or center_freq- I'm
>> trying to port some USRP1 python code to UHD and there doesn't seem to
>> be a clear analog.
>>
> The uhd has a get/set_rx/tx_freq.
I couldn't find one...
[root@aurora lib]# grep _freq *.h
uhd_multi_usrp_sink.h:virtual uhd::tune_result_t set_center_freq(
uhd_multi_usrp_sink.h:uhd::tune_result_t set_center_freq(double
freq, size_t chan){
uhd_multi_usrp_sink.h:return
set_center_freq(uhd::tune_request_t(freq), chan);
uhd_multi_usrp_sink.h:virtual uhd::freq_range_t
get_freq_range(size_t chan) = 0;
uhd_multi_usrp_source.h:virtual uhd::tune_result_t set_center_freq(
uhd_multi_usrp_source.h:uhd::tune_result_t set_center_freq(double
freq, size_t chan){
uhd_multi_usrp_source.h:return
set_center_freq(uhd::tune_request_t(freq), chan);
uhd_multi_usrp_source.h:virtual uhd::freq_range_t
get_freq_range(size_t chan) = 0;
uhd_single_usrp_sink.h:virtual uhd::tune_result_t set_center_freq(
uhd_single_usrp_sink.h:uhd::tune_result_t set_center_freq(double
freq, size_t chan){
uhd_single_usrp_sink.h:return
set_center_freq(uhd::tune_request_t(freq), chan);
uhd_single_usrp_sink.h:virtual uhd::freq_range_t
get_freq_range(size_t chan = 0) = 0;
uhd_single_usrp_source.h:virtual uhd::tune_result_t set_center_freq(
uhd_single_usrp_source.h:uhd::tune_result_t set_center_freq(double
freq, size_t chan){
uhd_single_usrp_source.h:return
set_center_freq(uhd::tune_request_t(freq), chan);
uhd_single_usrp_source.h:virtual uhd::freq_range_t
get_freq_range(size_t chan = 0) = 0;
> Did I forget to swig up the get_freq
> for the source and sink wrappers?
>
This is what I could find anyway...
[root@aurora swig]# pwd
/root/gnuradio/gr-uhd/swig
[root@aurora swig]# grep "def.*_freq" uhd_swig.py
def set_center_freq(self, *args):
def get_freq_range(self, *args, **kwargs):
def set_center_freq(self, *args):
def get_freq_range(self, *args, **kwargs):
def set_center_freq(self, *args):
def get_freq_range(self, chan = 0):
def set_center_freq(self, *args):
def get_freq_range(self, chan = 0):
I'm usually missing something dumb when I put myself on the line and
post, but I'm happy to take my grains of salt and have a solution :)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD: get_center_freq ?
gr-usrp has set_tx_freq and tx_freq uhd has set_center_freq but no get_center_freq or center_freq- I'm trying to port some USRP1 python code to UHD and there doesn't seem to be a clear analog. Have I overlooked something? Thanks for any input/help! -Brett ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Missing files in USRP1 FPGA?
Looks like these files were not moved from gnuradio/usrp. A symlink in fpga/usrp1 to ../../gnuradio/usrp/firmware seems to do the trick, but it would be nice if one of the repos had everything necessary. On 12/13/2010 12:49 PM, Brett L. Trotter wrote: > `include "../../firmware/include/fpga_regs_common.v" > `include "../../firmware/include/fpga_regs_standard.v" > > these seem to be absent from the repo obtained here: git clone > git://git.ettus.com/ettus/fpga.git > > Where can I find those files? > > ___ > 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] Missing files in USRP1 FPGA?
`include "../../firmware/include/fpga_regs_common.v" `include "../../firmware/include/fpga_regs_standard.v" these seem to be absent from the repo obtained here: git clone git://git.ettus.com/ettus/fpga.git Where can I find those files? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Bug in gr_scrambler?
I observed today with a controlled test using valve blocks that the
scrambler block continues to output data even when no input data should
be coming in. I then looked at the source:
int
gr_scrambler_bb::work(int noutput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const unsigned char *in = (const unsigned char *) input_items[0];
unsigned char *out = (unsigned char *) output_items[0];
for (int i = 0; i < noutput_items; i++)
out[i] = d_lfsr.next_bit_scramble(in[i]);
return noutput_items;
}
It seems to be looking only at the number of requested output items and
outputting anyway. Unless the input_items[0] array is guaranteed to be
filled with zeroes to the length of the number of output items, isn't
this potentially reading past the end of the input items?
Shouldn't the above be something like:
int
gr_scrambler_bb::general_work(int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
const int ninput_items = ninput_items[0];
const unsigned char *in = (const unsigned char *) input_items[0];
unsigned char *out = (unsigned char *) output_items[0];
for (int i = 0; i < ninput_items; i++)
out[i] = d_lfsr.next_bit_scramble(in[i]);
return ninput_items;
}
Regardless of whether there are sufficient input items to read, is there
a reason the scrambler block should continue outputting when the input
stream shuts off, sending zeroes or random data when you don't
necessarily want anything going out?
Is this a bug or an intended feature?
-Brett
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Location of USRP1 and USRP2 non UHD FPGA Verilog sources
The current git tree doesn't seem to have the USRP1 or USRP2 firmware for a non UHD setup. The Wiki seems to indicate it should be in gnuradio/usrp/fpga, but the only directory I see there is 'rbf'. Has it moved to a separate tree, and where might I find it? Thanks in advance! -Brett ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Bug in gr_scrambler?
Following up to my last- it seems I've generally misunderstood the valve
block. (also, my code example was off the top of my head and incorrect).
Please disregard the other post on this thread. Thanks.
-Brett
On 12/08/2010 12:55 PM, Brett L. Trotter wrote:
> I observed today with a controlled test using valve blocks that the
> scrambler block continues to output data even when no input data should
> be coming in. I then looked at the source:
>
>
> int
> gr_scrambler_bb::work(int noutput_items,
> gr_vector_const_void_star &input_items,
> gr_vector_void_star &output_items)
> {
> const unsigned char *in = (const unsigned char *) input_items[0];
> unsigned char *out = (unsigned char *) output_items[0];
>
> for (int i = 0; i < noutput_items; i++)
> out[i] = d_lfsr.next_bit_scramble(in[i]);
>
> return noutput_items;
> }
>
> It seems to be looking only at the number of requested output items and
> outputting anyway. Unless the input_items[0] array is guaranteed to be
> filled with zeroes to the length of the number of output items, isn't
> this potentially reading past the end of the input items?
>
> Shouldn't the above be something like:
>
> int
> gr_scrambler_bb::general_work(int noutput_items,
> gr_vector_int &ninput_items,
> gr_vector_const_void_star &input_items,
> gr_vector_void_star &output_items)
> {
> const int ninput_items = ninput_items[0];
> const unsigned char *in = (const unsigned char *) input_items[0];
> unsigned char *out = (unsigned char *) output_items[0];
>
> for (int i = 0; i < ninput_items; i++)
> out[i] = d_lfsr.next_bit_scramble(in[i]);
>
> return ninput_items;
> }
>
> Regardless of whether there are sufficient input items to read, is there
> a reason the scrambler block should continue outputting when the input
> stream shuts off, sending zeroes or random data when you don't
> necessarily want anything going out?
>
> Is this a bug or an intended feature?
>
> -Brett
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Not getting Makefile after bootstrap configure?
On 11/27/2010 11:55 PM, Eric Blossom wrote: > On Sat, Nov 27, 2010 at 11:16:24PM -0600, Brett L. Trotter wrote: > >> On an up to date fedora 13 x86_64 >> >> I just did this: >> 624 git clone http://gnuradio.org/git/gnuradio.git >> 625 cd gnuradio >> 626 git branch --track next origin/next >> 627 git checkout next >> 628 ./bootstrap >> 629 ./configure --enable-docs --enable-grc --enable-gnuradio-examples >> --enable-gr-utils --enable-gr-sounder --enable-gr-qtgui >> --enable-gr-wxgui --enable-gr-video-sdl --enable-gr-trellis >> --enable-gr-radio-astronomy --enable-gr-pager >> --enable-gr-noaa--enable-gr-gsm-fr-vocoder --enable-gr-gpio >> --enable-gr-cvsd-vocoder --enable-gr-atsc --enable-gr-audio-jack >> --enable-gr-audio-alsa --enable-gr-usrp2 --enable-gr-usrp --enable-usrp2 >> --enable-usrp --enable-gnuradio-core --enable-gruel --enable-python >> --enable-gr-uhd UHD_LIBS=/opt/uhd/lib UHD_INCLUDEDIR=/opt/uhd/include >> --no-create --no-recursion >> 630 make >> >> ... >> >> Have i missed something? >> > Any particular reason you're passing the --no-create --no-recursion flags? > > Eric > I copied this out of my config.log and didn't bother to look at it- totally missed it! Nice catch, thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Not getting Makefile after bootstrap configure?
On an up to date fedora 13 x86_64 I just did this: 624 git clone http://gnuradio.org/git/gnuradio.git 625 cd gnuradio 626 git branch --track next origin/next 627 git checkout next 628 ./bootstrap 629 ./configure --enable-docs --enable-grc --enable-gnuradio-examples --enable-gr-utils --enable-gr-sounder --enable-gr-qtgui --enable-gr-wxgui --enable-gr-video-sdl --enable-gr-trellis --enable-gr-radio-astronomy --enable-gr-pager --enable-gr-noaa--enable-gr-gsm-fr-vocoder --enable-gr-gpio --enable-gr-cvsd-vocoder --enable-gr-atsc --enable-gr-audio-jack --enable-gr-audio-alsa --enable-gr-usrp2 --enable-gr-usrp --enable-usrp2 --enable-usrp --enable-gnuradio-core --enable-gruel --enable-python --enable-gr-uhd UHD_LIBS=/opt/uhd/lib UHD_INCLUDEDIR=/opt/uhd/include --no-create --no-recursion 630 make and I get success from configure: * The following GNU Radio components have been successfully configured: config gruel gnuradio-core usrp usrp2 gr-usrp gr-usrp2 gr-msdd6000 gr-audio-alsa gr-audio-jack gr-audio-oss gr-atsc gr-cvsd-vocoder gr-gpio gr-gsm-fr-vocoder gr-noaa gr-pager gr-radar-mono gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui gr-qtgui gr-sounder gr-utils gnuradio-examples grc gr-uhd docs You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gcell gr-gcell gr-audio-osx gr-audio-portaudio gr-audio-windows gr-comedi These components will not be built. but I get no Makefile generated. [r...@localhost gnuradio]# ls -la Makefile* -rw-r--r-- 1 root root 1455 Nov 27 22:47 Makefile.am -rw-r--r-- 1 root root 4024 Nov 27 22:47 Makefile.common -rw-r--r-- 1 root root 1358 Nov 27 22:47 Makefile.common.spu -rw-r--r-- 1 root root 2734 Nov 27 22:47 Makefile.gen.gen -rw-r--r-- 1 root root 43538 Nov 27 22:48 Makefile.in -rw-r--r-- 1 root root 2833 Nov 27 22:47 Makefile.par.gen -rw-r--r-- 1 root root 3913 Nov 27 22:47 Makefile.swig -rw-r--r-- 1 root root 9605 Nov 27 22:47 Makefile.swig.gen.t Have i missed something? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio-examples/python/digital/tunnel.py issue
I seem to be having trouble with gnuradio-examples/python/digital/tunnel.py on a fedora 13 box complaining with an eng_notation error about any value I put in (eg 10M, 10e6, 1000) for --rx-freq or --tx-freq where the same exact script (md5 matches) on an ubuntu box works fine. This is the latest gnuradio git on track origin/next. Any thoughts how I might fix this? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 UHD bug?
I've got a laptop here (Acer Aspire 7552G) with 1GB ethernet with the latest git development copy of gnuradio and UHD, with a USRP2. On this particular laptop, when I try to transmit anything substantial, the USRP2 stops transmitting and quits responding, meanwhile the host keeps sending udp datagrams. The USRP2 has to be reset to start responding again. What might be causing the freak out and why isn't it recovering more gracefully? The behavior has been verified on Ubuntu 10.10 and Fedora 13, both x86_64 on this particular laptop. Any thoughts? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] external ref
On 11/09/2010 11:44 PM, Brett L. Trotter wrote:
> Does any alteration to code or firmware need to be made in order to get
> a USRP2 to lock to an external 10MHz reference?
>
>
I'm still looking for more information on this subject, and have some
additional information to add.
We're still in the non UHD realm, but looking into trying out the Python
method of telling the AD9510 to use the 10M refclock. In any case, I
wrote a new firmware that enabled the test output and told it to lock to
SMA, but I was unable to confirm based on the reported PPM drift in our
receiver or by scoping the test clock outs on both usrps at the same time.
The only conclusion we could come to by going back and forth between the
standard firmware and my ref sync firmware was that the test port was
being enabled but that the PPM generally stayed in the same range and
felt like either the clocks are good enough the oscillator wasn't
helping, they're syncing up with eachother by proximity effect, or we're
doing something wrong with the sync enable.
So the questions I have are:
1) I initially modified txrx.c
int
main(void)
{
u2_init();
+ // trigger lock to SMA
+ clocks_mimo_config(MC_WE_LOCK_TO_SMA);
+ // enable debug clock
+ clocks_enable_test_clk(true, 1);
which definitely enabled the output port.
I later tried changing MC_WE_DONT_LOCK in clocks.c to MC_WE_LOCK_TO_SMA,
but saw no change which was generally expected. Am I doing the right
thing or is there something more we should be doing to properly enable
the ref sync?
2) the docs are saying the UHD firmware lights up LED E for ref sync,
but non UHD firmware has no indication. Is there a way to enable the
same light in the non UHD firmware?
3) just out of curiosity, what's involved in enabling J505 (the 2nd
output of the DS90CP22) just as it would give us one more place to prove
the clock is getting in to the USRP2.
All in all it seems UHD is the answer, but non-UHD is the more known
entity to us. If you have answers to any or all of these questions, any
thoughts or confirmation would be really handy.
-Brett
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] external ref
Clarification to last- I see it can be done in Python with UHD, but without, do I need to put clocks_mimo_config(*MC_WE_LOCK_TO_SMA*); in clocks.c- perhaps in place of WC_WE_DONT_LOCK on like 52 or is there a way to do it in python for non UHD? On 11/09/2010 11:44 PM, Brett L. Trotter wrote: > Does any alteration to code or firmware need to be made in order to get > a USRP2 to lock to an external 10MHz reference? > > ___ > 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] external ref
Does any alteration to code or firmware need to be made in order to get a USRP2 to lock to an external 10MHz reference? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD help
I have UHD built, "burned" a UHD firmware to SD, the USRP2 pings, uhd_find_devices is happy- how do I use usrp2_fft.py for instance with UHD- or do I need to edit the .py files to change the flowgraph for UHD? Sorry if this has been answered somewhere already. -Brett ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] quick question regarding usrp_rx_cfile
With the -s option on, what is the byte ordering of the output? eg is a sample 0xABCD being written as 0xCD, 0xAB, or 0xAB, 0xCD? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio with alternate python
Thanks for both your replies. Regarding the PATH fix- in the situation I'm looking to fix for myself and my users, I've got system python 2.4 from RHEL 5/CentOS 5 as /usr/bin/python and my python 2.5 as /usr/bin/python2.5 (with python25 link). I suppose another choice would have been to make it /usr/local/bin/python instead, which if I recall my computing roots, was the place to extra software that departs from the basic install. In any case, for me the decision to make it side-by-side was based on sticking to the redhat standard locations. But due to that, creative path ordering doesn't help. I suppose I'm open to suggestion on this one- is the case that people are compiling gnuradio against a non-default python common enough to merit the additional step? If so, would doing either a template sort of approach (put @@PYTHON@@ in all the gnuradio examples .py files, and use m4 or sed to replace), just plain using sed, or some other method I'm not thinking of be the best? If not, I'm open to changing my python25 rpm to relocate the python and expect users to set the path properly, but I sort of like the "it just works". P. S. Maybe this is a bad idea or demonstrating a lack of knowledge, but it seems that its kind of too bad there isn't some kind of handy little variant or option of /usr/bin/env that looks at the program name, looks for an environment variable with a capitalized spelling of the same name, and uses that path/exe if it exists or falls back to doing the program name itself. eg setting PYTHON=python2.5 /usr/bin/env -foo python would run python2.5 instead. Alternatively if the shebang could support a conditional [ ! -z PYTHON ] .. or something. P.P.S. I won't reply to the other post about the circbuf message- thanks for clearing that up, its been a while since I've seen that message. -Brett On 06/26/2010 05:10 PM, Eric Blossom wrote: > On Sat, Jun 26, 2010 at 12:32:38PM -0500, Brett L. Trotter wrote: > >> I'm just now getting to a gnuradio project and hadn't had much of a >> chance to dogfood my gnuradio RPM from my repo. Now that I'm getting to >> it, all of the examples scripts have #!/usr/bin/env python hardcoded at >> the top. I was thinking the build process (which already knows the >> appropriate python) should populate all the python scripts with the >> correct python? >> > Yes, it could. It would probably be best if the "install" step of > "make install" did it while installing them. > > Feel free to submit a patch for this based off of the "maint" branch. > > >> Otherwise, it looks like I'm going to have to rebuild my RPM and sed all >> of the .py files? >> > Or, as a workaround, juggle your PATH such that the python you want > comes in front of the python that you don't want. > > Eric > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr_vmcircbuf_createfilemapping not available?
[r...@aurora rng2]# usrp_rx_cfile.py -R A:0 -d 4 -g 18 -f 8M -N 1.5M -s /tmp/brx_8m_d4_g18_1.5msamples-06-26-10_13-22-37 Using RX d'board A: Basic Rx USB sample rate 16M gr_vmcircbuf_createfilemapping: createfilemapping is not available [r...@aurora rng2]# ls -lh /tmp/brx_8m_d4_g18_1.5msamples-06-26-10_13-22-37 -rw-r--r-- 1 root root 5.8M Jun 26 13:22 /tmp/brx_8m_d4_g18_1.5msamples-06-26-10_13-22-37 It appears I've got data, but what is the vmcircbuf error? [r...@aurora rng2]# uname -a Linux aurora 2.6.18-194.3.1.el5 #1 SMP Sun May 2 04:17:42 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux [r...@aurora rng2]# cat /etc/redhat-release Red Hat Enterprise Linux Client release 5.5 (Tikanga) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio with alternate python
I'm just now getting to a gnuradio project and hadn't had much of a chance to dogfood my gnuradio RPM from my repo. Now that I'm getting to it, all of the examples scripts have #!/usr/bin/env python hardcoded at the top. I was thinking the build process (which already knows the appropriate python) should populate all the python scripts with the correct python? Otherwise, it looks like I'm going to have to rebuild my RPM and sed all of the .py files? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Gnuradio 3.2.2 for RHEL 6
I know there aren't too many folks toying with RHEL 6 yet, but I've uploaded gnuradio 3.2.2 RPMS (i386 + x86_64) for RHEL 6 on the new repo. For info: http://blackopsoft.com/RHEL_6 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] An update on my repository (a repo for RHEL/CentOS which has gnuradio)
First please let me note that I will not and do not email this list about the repo except when I have an update pertaining to gnuradio. When I first started the repo, I was only building packages for x86_64, but soon after adopted mock and built most of them for i386 as well, but the sdcc source rpm had problems compiling under mock, leaving me unable to build gnuradio for i386. It fell by the wayside and no one seemed to care since i386 isn't the typical platform of power-users these days. However, I had a recent request for an i386 package, gave sdcc another whirl, and finally got a more recent sdcc package that builds successfully under mock and was able to at last put gnuradio 3.2.2 for i386 into the repository. In the same request, it was noted that wxPython should have been called wxPython25 so as not to conflict with the upstream for Python 2.4. I repackaged wxPython and gnuradio with the appropriate obsoletes and was updated to 3.2.2-5 from rawhide with the usual tweaks to use the python25. Long story short, gnuradio 3.2.2-5 is now available pre-compiled for x86_64 and i386. Boost is still at 1.40 as the 1.41 didn't build on my last attempt and haven't tried very hard to work it out as I'm holding out for a 1.43 source rpm. I have an eye out for it, but may up-package 1.43 using the 1.40 spec as a starting point, but I like to go with version specific rpms with something as big and complex as boost whenever possible to avoid missing files. If anything else is creeping out of date, please let me know. Last but not least, Gnuradio 3.3 final is nearly here- I'll do my best to package it as soon as possible, but may need feedback whether it works appropriately. And to sign off- as always, please contact me if you have any problems, complaints, suggestions, etc. Thanks to all who are making use of the software and providing feedback. -Brett ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] scientific computing repository update
I hate to be partly off topic, but I wanted to give an update on the repository I shared a few days ago. I created the repository because I've been using RHEL/CentOS for GNURadio and Octave a long time and wanted to help others do so since it can be a chore on the slower distributions. Although I've been porting and packaging a long time, I admit I'm new to running a repository and may have made some beginner mistakes in that area. I made the announcement on the 6th after getting some initial RPMs up, and later found out that there may have been some RPMs I'd built locally long ago that may have been used in the build process but weren't actually in my repository which were causing failed dependencies in yum. I worked for several days to improve the packaging of the RPMs provided, and added several new packages. I went through and made sure everything was signed and included, so all dependencies should now be resolved. I apologize if anyone gave it a try and encountered problems, and I hope they'll try again. If there are other packages you'd like to work on RHEL/CentOS or are having problems with the ones posted, I'll be happy to try and remedy the situation. I'm also open to packaging suggestions or corrections such as trying to put some of these off to the side with alternate package names. I'm all ears and just want to make GNURadio more accessible. -Brett P.S. I'm still in the process of getting a mock build environment for RHEL organized so I can create the i386 repository, which should clean up some of the few remaining library issues as well as make GNURadio a little more accessible. Lastly, I hope to include SDL support sooner or later, but it's dependency heck and ultimately messes with packages like nss which is dangerous and needs to be done carefully. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem in configure with trunk 10632
Usually for stuff like compiling and it has worked in the past (even a few days ago). You're correct, when I come on with VNC or console, it works fine. Any idea what broke? Johnathan Corgan wrote: > On Tue, Mar 17, 2009 at 4:16 PM, Brett L. Trotter > wrote: > > >> top doesn't show anything eating up CPU, at all. >> > > Are you perhaps ssh'd in and have X forwarded over your network? > > Johnathan > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem in configure with trunk 10632
the same.
top doesn't show anything eating up CPU, at all.
Josh Blum wrote:
> Thats really bad!
>
> howabout
>
> python -c "import pygtk; pygtk.require('2.0'); import gtk"
>
> Brett L. Trotter wrote:
>> Josh Blum wrote:
>>> what does python --version give you?
>>>
>>> what happens when you run python -c "import gtk" in the same terminals?
>> ubuntu:
>> r...@phenom2:~/gnuradio# uname -a
>> Linux phenom2 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009
>> x86_64 GNU/Linux
>> r...@phenom2:~/gnuradio# python --version
>> Python 2.5.2
>> r...@phenom2:~/gnuradio# python -c "import gtk"
>> freezes as in configure
>>
>> FC10 #1:
>> [r...@phenom gnuradio]# python --version
>> Python 2.5.2
>> [r...@phenom gnuradio]# python -c "import gtk"
>> same freeze
>>
>> FC10 #2:
>> [r...@evo2 gnuradio]# python --version
>> Python 2.5.2
>> [r...@evo2 gnuradio]# python -c "import gtk"
>> same freeze
>>> Brett L. Trotter wrote:
>>>> checking for xdg-mime... true
>>>> checking for Python >= 2.5... yes
>>>> checking for Python Cheetah templates >= 2.0.0... yes
>>>> checking for Python lxml wrappers >= 2.0.0... yes
>>>> checking for Python gtk wrappers >= 2.10.0...
>>>>
>>>> ^C^C^C^C^C^C^C^C^C^C^C
>>>>
>>>>
>>>>
>>>> can't control C either..
>>>>
>>>> this has happened on an ubuntu intrepid box, and two FC10 boxes
>>>> independently.
>>>>
>>>>
>>>> ___
>>>> 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
Re: [Discuss-gnuradio] problem in configure with trunk 10632
Josh Blum wrote: > what does python --version give you? > > what happens when you run python -c "import gtk" in the same terminals? ubuntu: r...@phenom2:~/gnuradio# uname -a Linux phenom2 2.6.27-11-generic #1 SMP Thu Jan 29 19:28:32 UTC 2009 x86_64 GNU/Linux r...@phenom2:~/gnuradio# python --version Python 2.5.2 r...@phenom2:~/gnuradio# python -c "import gtk" freezes as in configure FC10 #1: [r...@phenom gnuradio]# python --version Python 2.5.2 [r...@phenom gnuradio]# python -c "import gtk" same freeze FC10 #2: [r...@evo2 gnuradio]# python --version Python 2.5.2 [r...@evo2 gnuradio]# python -c "import gtk" same freeze > > Brett L. Trotter wrote: >> checking for xdg-mime... true >> checking for Python >= 2.5... yes >> checking for Python Cheetah templates >= 2.0.0... yes >> checking for Python lxml wrappers >= 2.0.0... yes >> checking for Python gtk wrappers >= 2.10.0... >> >> ^C^C^C^C^C^C^C^C^C^C^C >> >> >> >> can't control C either.. >> >> this has happened on an ubuntu intrepid box, and two FC10 boxes >> independently. >> >> >> ___ >> 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] problem in configure with trunk 10632
checking for xdg-mime... true checking for Python >= 2.5... yes checking for Python Cheetah templates >= 2.0.0... yes checking for Python lxml wrappers >= 2.0.0... yes checking for Python gtk wrappers >= 2.10.0... ^C^C^C^C^C^C^C^C^C^C^C can't control C either.. this has happened on an ubuntu intrepid box, and two FC10 boxes independently. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] site down?
Subversion and www seem to be misbehaving. Is it just me/my connection? Is there an ETA on revival? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problems with a block
I've got a block that I needed to make a gr_io_signature4 for- unless
I've misunderstood something:
gr_io_signature_sptr
gr_make_io_signature4(int min_streams, int max_streams,
int sizeof_stream_item1,
int sizeof_stream_item2,
int sizeof_stream_item3,
int sizeof_stream_item4)
{
std::vector sizeof_items(4);
sizeof_items[0] = sizeof_stream_item1;
sizeof_items[1] = sizeof_stream_item2;
sizeof_items[2] = sizeof_stream_item3;
sizeof_items[3] = sizeof_stream_item4;
return gr_make_io_signaturev(min_streams, max_streams, sizeof_items);
}
the class definition looks like this:
myclass::myclass(unsigned int code_length,
unsigned int samples_per_chip,
unsigned int periods_per_bit,
float amplitude)
: gr_block("myclass",
gr_make_io_signature4(4, 4, sizeof(char), sizeof(char),
sizeof(gr_complex), sizeof(gr_complex)),
gr_make_io_signature(1, 1, sizeof(gr_complex)))
{
..snipped...
}
the block takes two chars' and two complex's and does some work with
them and outputs the one complex.
depending on what order I call the self.connect's in the python, I get
one of two errors:
terminate called after throwing an instance of 'std::invalid_argument'
what(): port number 2 exceeds max of 1
Aborted
grc was calling connect to 2, then 3, then 1, then 0, if I swapped the
connect line order to connect to 0, 1, 2, 3 that error went away and I got:
terminate called after throwing an instance of 'std::invalid_argument'
what(): itemsize mismatch: diff_encoder_bb(18):0 using 1,
myclass(12):1 using 8
Aborted
I've now reordered the connections by hand extremely carefully and the
2nd error remains, but the first error may be a GRC bug because it's not
connecting the ports in order and that seems to generate an error.
The diff encoder is 1 byte, and the port it is connected to is 1 byte
(vis a vis the signature above). Any suggestions on resolving the second
error would be great.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] block destructors
I'm doing some logging of what time signal events happen and in the destructor of a custom signal block, I'm printing a log line to a file, followed by an fflush, but i'm not always getting my line. Is the destructor not happening, or is something else transpiring? Is there a way to ensure a destructor will fire even if a user ctrl+c's a flowgraph, especially with WXGUI/GRC, or is that not what is happening? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Netgear GA311 (Realtek 8169) and USRP 2
The purpose of this email is to ask if anyone (out of the relatively few USRP2 users) had happened to bump into this card and had similar difficulty as well as to determine if this is repeatable on other systems and thus warn others away from the headache I've encountered. I've been successful with the Attansic Technology Corp. L1 on an AMD board I have, but a Netgear GA311 produces odd results. find_usrps works, but usrp2_siggen fails to identify the daughterboard. I believe the GA311 is at fault. I was originally on Fedora Core 7 but upgraded to 10 after the initial problems. Please let me know if you have any experience with this card in general, or even better, with this card and a USRP2. I'm anxious to resolve the issue (or return the card). Thank you in advance. -Brett ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] block question (correction)
Brett L. Trotter wrote: > two interrelated questions here: > 1) in a block with minimum output streams = 1 and maximum = 1, do I need > to know if the output stream is not connected and not try to fill the > output buffer at all (or will outputitems be 0?) > and 2) if yes, how do I get a count of the number of connected streams? > > drat- should have proof read that. minimum was meant to be 0. please excuse ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] block question
two interrelated questions here: 1) in a block with minimum output streams = 1 and maximum = 1, do I need to know if the output stream is not connected and not try to fill the output buffer at all (or will outputitems be 0?) and 2) if yes, how do I get a count of the number of connected streams? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr_make_io_signaturev
Are there any examples of how to use this?
Since the current C++ (until C++0x is out) doesn't support vector
initialization, how does one format the inheritance constructor?
for example:
myblock::myblock(...) : gr_block("myblock", gr_make_io_signaturev(4,4,
std::vector somevec)) { ...}
in what code do I populate somevec? or is there another way to attack this?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] massive buffering occurring
I've got a couple proprietary transmitter and receiver blocks here with some other custom blocks in the flowgraph, and the problem I'm seeing is that I seem to be building up a really large buffer of data that hasn't been transmitted out of the USRP yet. I'm guessing I've missed something with regards to the set_relative_rate? Can someone explain or point me to documentation that does, how to minimize the buffering to a sane rate relative to the consumption? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] c++ question
I've got a relatively large array of maximal length LFSR masks I'd like to be able to use, there are of course a different number for each degree, increasing with the degree. I forgot that C++ doesn't support jagged arrays like C# so I created this great little jagged array with the 2nd dimension 0 terminated (mask of 0 isn't really useful anyway, so I used it like null) so that I could figure out how many were in each degree. I've been googling and IRCing and trying to figure out if there's a way to initialize a vector of vectors as a constant in a class header file or something that would hold these constants and coming up short on answers. Do I need to dump all my data to a file and read it in? That seems poor for minimizing the initialization delay. Is anyone willing to point me in the right direction? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ah ha
I have figured it out- the actual callback was occurring, but then the d_updated wasn't being evaluated in the work function at due to the aforementioned improper conditions :) Thanks Eric! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] force break to allow callbacks between work functions?
I now am encountering a situation where my work function is consuming all of the inputs trying to search for a match for a particular condition and does so successfully when the parameters are correct for the data it is receiving, but if it gets busy looking with the wrong settings, the callbacks from the gui never make it through to update the settings (watching printfs to verify). Is there a (VB/C#) Application.DoEvents() equivalent here that makes work take a breather long enough to accept another method call? Will mutexes somewhere help this? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] broken copyright form link on trac
Just FYI: on the page: http://gnuradio.org/trac/wiki/Development the link to the form (http://www.gnu.org/prep/maintain_6.html) appears to have moved. http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant is about as close as I could find, though it is not a form in and of itself. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] proposal/question about patching gr_file_{source, sink} to support a change filename callback
Looking at the gr_file_source code, it doesn't appear that there is a callback to close the current file and open a new one instead. I have an application where I'd like to be able to do that. If it's not implemented in some other way I haven't found, I'd like to implement this and have done so successfully in other modules for private use, but my question main is, if I'm not mistaken in thinking this needs to be done in the first place, is there any interest in me submitting a patch and are there any side effects I'm not thinking of in adding/exposing these callback methods in a core block even though the io signatures will be the same? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] apologize for mail problems trying to contact me
I've been having some trouble after upgrading my mail server- I apologize for any bounces or inconvenience over the last few days and think the problem is currently resolved. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] lsusrp
I have a rev 2, rev 3 and a rev 4 usrp here. When I plug in either the 2 or 3 (no serial #) and a 4 and do a lsusrp, both usrp's show up as one or the other (daughter cards and everything) until I do a second lsusrp. Is this a bug? It's no big deal, but I was curious what's causing it. This is the svn trunk (up to date) on FC7. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] -T A:1 or -T B:1 tuple out of range?
We're getting tuple out of range when specifying port 1 on either side for an LFTX board. Specifying -T A:0 or -T B:0 on does seem to work on several of the transmitter apps we've tried. [EMAIL PROTECTED] ~]# usrp_siggen.py -T A:0 -f 5M -i 128 --sine -a 16000 -g 0 Using TX d'board A: LF Tx [EMAIL PROTECTED] ~]# usrp_siggen.py -T A:1 -f 5M -i 128 --sine -a 16000 -g 0 Traceback (most recent call last): File "/usr/local/bin/usrp_siggen.py", line 184, in ? main () File "/usr/local/bin/usrp_siggen.py", line 164, in main tb.subdev = usrp.selected_subdev(tb.u, options.tx_subdev_spec) File "/usr/local/lib64/python2.4/site-packages/gnuradio/usrp.py", line 393, in selected_subdev return weakref.proxy(u.db[side][subdev]) IndexError: tuple index out of range [EMAIL PROTECTED] ~]# [EMAIL PROTECTED] ~]# usrp_siggen.py -T B:0 -f 5M -i 128 --sine -a 16000 -g 0 Using TX d'board B: Basic Tx [EMAIL PROTECTED] ~]# usrp_siggen.py -T B:1 -f 5M -i 128 --sine -a 16000 -g 0 Traceback (most recent call last): File "/usr/local/bin/usrp_siggen.py", line 184, in ? main () File "/usr/local/bin/usrp_siggen.py", line 164, in main tb.subdev = usrp.selected_subdev(tb.u, options.tx_subdev_spec) File "/usr/local/lib64/python2.4/site-packages/gnuradio/usrp.py", line 393, in selected_subdev return weakref.proxy(u.db[side][subdev]) IndexError: tuple index out of range Receiver seems happy to take :1 [EMAIL PROTECTED] ~]# usrp_rx_cfile.py -R A:0 -d 8 -f 5M -g 0 out.dat Using RX d'board A: LF Rx USB sample rate 8M [EMAIL PROTECTED] ~]# usrp_rx_cfile.py -R A:1 -d 8 -f 5M -g 0 out.dat Using RX d'board A: LF Rx USB sample rate 8M Have I missed another post about new syntax? This is latest SVN as of a couple days ago. Please let me know if I'm doing something else silly. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] boost 1.35
I apologize for missing the announcement. I'm guilty of filtering out most of the stuff that doesn't pertain to my application :) SMP is a very good thing. My question was mainly if this was an accidental dependency, did we really want to be using non-mainstream software in the core, but obviously this is a worthwhile endeavor. Thank you for the time. Eric Blossom wrote: > On Thu, Aug 21, 2008 at 08:50:26PM -0500, Brett L. Trotter wrote: > >> I may be mistaken, but when I last svn updated off the trunk, boost >> 1.35+ was required. This is not yet in the Fedora repositories (1.36 >> beta is in development however) and means building gnuradio with a >> standard system is not possible. While one can find the 1.36 src rpm and >> build it, it's a bit of a hassle. I updated the trunk not expecting any >> major changes in the last week-ish and now have to make it work. Is >> there anything truly requiring 1.35? If not, 1.33 would be much preferred. >> >> > > I announced more than 2 weeks ago that boost 1.35 was going to be > required, and that then was a good time to do something about. > > Directions on building from source are in README.building-boost. > It takes about 5 minutes to build the part we need, and it can coexist > with the already installed version. > > And yes, we need it. I didn't just randomly introduce what I know to > be a problematic dependency. Do you want SMP support? :-) > > If this is inconvenient for you, there are two other options: > the 3.1 stable branch or the tarballs. > > $ svn co http://gnuradio.org/svn/gnuradio/branches/releases/3.1 > > > Meanwhile, we're charging ahead on the trunk! > > Eric > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] boost 1.35
I may be mistaken, but when I last svn updated off the trunk, boost 1.35+ was required. This is not yet in the Fedora repositories (1.36 beta is in development however) and means building gnuradio with a standard system is not possible. While one can find the 1.36 src rpm and build it, it's a bit of a hassle. I updated the trunk not expecting any major changes in the last week-ish and now have to make it work. Is there anything truly requiring 1.35? If not, 1.33 would be much preferred. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tracing a connection stack
Eric Blossom wrote: On Tue, May 20, 2008 at 11:14:18AM -0700, Johnathan Corgan wrote: On Tue, May 20, 2008 at 11:07 AM, Eric Blossom <[EMAIL PROTECTED]> wrote: On Tue, May 20, 2008 at 12:09:27PM -0500, Brett L. Trotter wrote: Is there a simple way to print out a list of what was connected into a flow graph? Not right now. However, just last night I was thinking about something similar. Give me a day or so and I'll put something together. Eric--there is a dump() method on gr_flat_flowgraph objects currently used for debugging. You can create a method on gr.top_block (exposed via swig) that would call dump() on the d_ffg member. Thanks! FYI, I opened it as ticket:245 Eric Most excellent. Thank you for the reply and the solution. Just debugging some code and I think it's just omission, but wanted to see if there's something connected higher up- it seemed being able to see what all was hooked up would be handy. Cheers and thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tracing a connection stack
Is there a simple way to print out a list of what was connected into a flow graph? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] not gnuradio, but FPGA
I realize that this is not gnuradio traffic specifically, hopfully it won't put anybody off- I apologize if it does, but I'm desperate! I'm working with an Altera/Terasic DE2 board trying to get ethernet up and running with the onboard DM9000a. I've read the manuals backwards and forwards and I don't see much about what really happens in 16-bit mode (the way I understand it, since the EE* pins are unconnected on the DE2, we're in 16-bit mode and all of the pins are labeled ENET_DATA[15..0]. In any case I have a huge chunk of a state machine that should have me getting all linked up but is failing to do so. The simulation looks perfect as far as I can tell from my understanding of the documentation. If anyone out there is really familiar with the DE2 and/or the Davicom DM9000a or just is willing to help, I'll send over all of my quartus project files (in VHDL) Thanks in advance! P.S. Sooner or later, I may understand enough to make some level of contribution on the Verilog code- or perhaps port it to VHDL. It has been too long since my last patch. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] file transmitter
I think this has been answered in the past, but I couldn't find the answer- is there a pre-done script to transmit a raw data file directly as samples? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tunnel.py / pick_bitrate.py
I had originally asked Johnathan Corgan about expanding the list called sbs_to_mm that has the m&m mu gain for given samples/symbol to include higher samples per symbol so that we can use it at very low bitrates. I don't know who wrote the script in the first place, but Johnathan had indicated he'd get in touch with the author. He's currently out of the country I believe and I was hoping to get in contact with the author directly. Would you care to email me? Thanks in advance -Brett ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tunnel.py and low bit-rates
In 3.03 and before, as opposed to CVS, one could add higher samples per symbol values to pick_bitrate.py and operate at lower bitrates than 35k. Currently, gmsk seems to be the only one that works via that method, dqpsk and dbpsk complain about sbs_to_mm not having an array key for the particular value of samples/symbol. Did it previously figure out something that worked and now uses a lookup? Similarly, even with gmsk which lets me go below 35k, I seem to have little to no success even with enough signal to operate at 35k. What can I do, or what can be done to operate in the neighborhood of 1KB/s throughput and require the lowest possible SNR? I've added in some error correcting code, but have almost no success below 35k even if the tunnel appears to set-up. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] lost bytes and reed-solomon
Got a few good replies on my question about lost bytes. I appreciate the input, that sounds like it'll work great in conjunction with the error correction then. I'm hoping to have that in place within the next couple of hours and start testing. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] lost bytes and reed-solomon
Brett L. Trotter wrote: > I'm working on a self-educational project to replace the simple CRC in > the tunnel apparatus with a very heavy reed-solomon encoding for very > lossy and low-bandwidth links. One thought just occurred to me. > Originally, I was going to group up all of my data in 127 byte blocks, > r/s encode it with a 255,127, and just shove each 255 byte block into a > new payload string which would basically be twice as long with reed > solomon parity stuff every other 127/128 bytes from each respective > block and then just grab each 255 bytes and run them through the decoder > on the receive and do the opposite, shoving each decoded 127 bytes into > a decoded payload. > > But the thought was, what if a byte is completely obliterated- then > everything would be shifted over one (or more) and my groupings wouldn't > align so I'd be looking in the wrong places for parity and not know that > there was a total deletion rather than just a corruption? Is there any > way to prevent/identify this case, or can it even happen? > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > Partially answering myself here (and expanding on my question/thought) I suppose a simple answer would be to check the length of the received payload and if not a multiple of 255, just discard the whole thing- then we can at least identify the deletion. Since we can't pinpoint where it was, we can't just fill it in with a 0 that would get repaired (hopefully).. If this is the right move, then the question becomes, how often can a byte be lost in transmission, and is it more often than only corruption occurs? If it is rare enough, then the loss of the entire packet is acceptable (and no worse than the current CRC), but if it isn't so rare, would the reed-solomon do much good in the first place? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] lost bytes and reed-solomon
I'm working on a self-educational project to replace the simple CRC in the tunnel apparatus with a very heavy reed-solomon encoding for very lossy and low-bandwidth links. One thought just occurred to me. Originally, I was going to group up all of my data in 127 byte blocks, r/s encode it with a 255,127, and just shove each 255 byte block into a new payload string which would basically be twice as long with reed solomon parity stuff every other 127/128 bytes from each respective block and then just grab each 255 bytes and run them through the decoder on the receive and do the opposite, shoving each decoded 127 bytes into a decoded payload. But the thought was, what if a byte is completely obliterated- then everything would be shifted over one (or more) and my groupings wouldn't align so I'd be looking in the wrong places for parity and not know that there was a total deletion rather than just a corruption? Is there any way to prevent/identify this case, or can it even happen? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] swig question
Brett L. Trotter wrote: > I've made a swig wrapper for some code that needs a char pointer passed > in, how do I do such a thing? > > > Thinking about this more, maybe I need to give more information. I've wrapped Phil Karn's FEC library and I'm trying to call encode_rs_char: void encode_rs_char(void *rs,unsigned char *data, unsigned char *parity); I passed it a string of a correct length, like I did for data, and it only complained about the one for parity my python looks like this from fec import * def main(): # make a test string with a predictable value teststr = '' for i in range(127): teststr = teststr + chr(i) # make a 127 byte long string to fill with parity paritystr = chr(0) * 127 # create a handle for the reed-solomon function with the right params rs_handle = init_rs_char(8, 0x187, 1, 1, 128, 0) # do the actual encoding encode_rs_char(rs_handle, teststr, paritystr) main() and I get: Traceback (most recent call last): File "./test.py", line 18, in ? main() File "./test.py", line 15, in main encode_rs_char(rs_handle, teststr, paritystr) TypeError: in method 'encode_rs_char', argument 2 of type 'unsigned char *' so what can I pass it? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] swig question
I've made a swig wrapper for some code that needs a char pointer passed in, how do I do such a thing? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] r/s encoding
I'd really like to work on the reed-solomon encoding over the weekend here and unfortunately I can't do so without more information. If anyone can tell me whether the padding mechanism proposed in my recent email might work- or how to make it take into account the bits/sample and samples/symbol, I'd be really greatful. Thank you ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] learning about SDR
I've been learning about software defined radio from the ground up and my maths are a bit shaky and I'm mainly a software guy, so concepts of signals and whatnot are rather foreign to me. So as I've been reading, I've taken lots of tangents to review what must seem like completely elementary concepts along the way. I fully understood what ADCs and DACs do, but I didn't have any clue what complex sampling really was. I ended up stumbling across a document from 1958 that seems to be when the concept of complex sampling was developed. Please do correct me if I'm wrong, but either way- this document seems to do a great job of explaining some of the maths of complex signals and with a small trigonometry review, it should be more clear just what a complex signal really is doing. I imagine most of the folks on this list are well past needing this type of review, but I'd highly recommend reading this if you need some of the basics. It pertains in large part to Frequency Modulation. Without further ado, here's the URL: http://handle.dtic.mil/100.2/AD636038 I've also found the JNL Research Group's gnuradio tutorial invaluable (and is linked to in several places on the gnuradio pages IIRC) (http://www.nd.edu/~jnl/sdr/docs/) I found a fairly good article on Cascaded Integrator-comb filters as well (http://www.us.design-reuse.com/articles/article10028.html) http://www.dspguru.com has quite a bit of useful background too for folks like me that need a lot of terminology defined. All this may be referenced/linked elsewhere, but I figured I'd share what has been useful to me so far. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] r/s encoding and padding on gmsk
I'm involved with very lossy links and low signal strengths using gmsk and dqpsk and would like to add a layer of reed-solomon encoding in place of the current CRC check. My plan was to use reed solomon in a standard (255,223) configuration and use PKSC#7 padding in 223 byte blocks where the last N bytes up to 223 are filled with the value N and if the block is precisely full, you'd have to waste a full block of 223 bytes with the value 223. In our lossy circumstance, this kind of waste (even though fairly rare that you'd have a packet precisely 223 characters) would be worthwhile for the added redundancy of the r/s. In any case, in reading the associated python code, I noticed that the data sent over the USB seems to have to be in multiples of 128, but it also seemed to imply that it had to be multiples of 512. The current padding mechanism seems to take into account the bits/sample and samples/symbol as well. What I really need to know is whether my simple 256 byte system (223 before r/s, 256 after r/s) would suffice if I kept track of whether the current block was at a 512 byte boundary and if not would have to add another 256 byte packet of padding. In other words, do I need to take into account the bits/sample and samples/symbol if our data length is always a multiple of 256 (or 512)? How might I take all that is required into account if not? Thanks in advance! P.S. the amount of wasted bandwidth isn't really as important as quality packets (correctable packets at least) in lower SNR environments. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] updating trac?
The gnuradio build guide for fedora should be updated since the latest trunk requires guile-devel to be installed as well. Is there a way for average joes to update the trac wiki? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] DQPSK/GMSK receive strengths
Is there a way to know or log (in the verbose logging) the maximum received strength of a packet- or running max perhaps over a period of a few seconds? I'm trying to measure it with a scope and coming up short- I think I have some faulty hardware in the loop here, but that's what I'm trying to diagnose. If there's a way that the USRP can report the received strength while using tunnel.py that'd be quite useful to me at least. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP and "fusb: (rd status -71) Protocol error"
Eric Blossom wrote: > On Thu, May 03, 2007 at 07:27:33AM +1000, stevie.glass wrote: > >> Hi >> >> I've a rev 3 USRP which has the Flex2400 and TVRX daughtercards installed. >> At one time the setup worked well - altho I've let it lie a while. This >> week I've swapped out a TVRX and replaced it with the DBSRX in >> preparation for a new project. >> >> When I run usrp_fft.py things are fine for a few moments but inevitably >> the program crashes with: >> >> fusb: (rd status -71) Protocol error >> >> repeatedly written to the terminal. Similar story for usrp_oscope.py and >> most other examples. >> > > I have in the past seen this, but mostly when I've powered down a USRP > while the application was still running. > > You may want to try a different USB cable. It might be flaky. > > Eric > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > Could this be related to the (now fixed) FX2 power bug on the FPGA that surfaced with the Ubuntu Feisty Fawn kernel? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] multi-machine sweeper
In looking for particular frequencies which can successfully transmit across a particular medium or antenna, I've spent days running benchmark_tx on one side and benchmark_rx on the other (two separate machines). I've got an ethernet connection between the two machines, so it is a matter of sshing and running the test app and then looking at the benchmark_rx or usrp_fft. Has anyone ever automated this process? I'd really love a way to relatively quickly sweep across the entire range of a particular daughterboard and have the other machine generate a brief report of frequencies that seemed to work. Is there a python whiz out there who could cobble such a thing together in a hurry? I have a passwordless ssh key that lets me connect to the other box and run commands without authentication which is good for scripting (ssh 10.0.0.2 benchmark_tx.py yatta yatta yatta). In the long run- perhaps a python app that sits on a socket and changes the frequency at the command of the other side of the link, which is doing a loop through the daughtercard frequencies and then keeps track of the SNR or the db above baseline or something. The quick and dirty way would be to have the RX hop to the frequency, listen to baseline with transmitter not going, record level, ask TX side to go to same frequency, measure again- record the result and then move to the next frequency. Any thoughts would be great. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] regarding fft-ifft processing
Trond Danielsen wrote: > I read in an earlier thread that you want to do the (I)FFT processing > in the FPGA. This is not how it is intended to be used. GNU Radio is a > software radio framework, and the goal is to move as much of the > signal processing as possible onto the host computer. Moving the FFT > back to the FPGA would therefore be a step backward in the software > approach. This is just my personal opinion, so feel free to spank me > with a 10 foot monopole if your view is different :) > An interesting debate. FPGA is indeed hardware, but I'd argue that if the (I)FFT can be done faster on the FPGA and can use the appropriate window sizes, etc (eg on-the-fly reconfigurable) that it would still technically meet the definition of 'software'. If it frees up USB bandwidth somehow or frees up host-CPU and lets the host have more resources left to do its job and we're not really doing a mode-specific function that locks us into MIMO or GMSK or OFDM, etc that it would be OK by me as a consumer. That Cyclone FPGA was awfully full last I checked- I don't know enough about this type of thing to say it wouldn't fit, but it seems at least possible that the amount of real-estate required to do the FFT might be more than the current generation USRP could handle? IANAE (expert), but I thought the debate was interesting enough to risk embarassment :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM status
What is the current status of the OFDM project? Is it such that I could give it a try using a tunnel.py type setup over a shared wireline - or at least over two separate RX/TX wires? Last I heard the receiver and transmitter were working but not over the air. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 8b/10b for GMSK
Johnathan Corgan wrote: > Brett L. Trotter wrote: > > >> Yay- congratulations- transferred 100MB successfully and all of my >> 'stumbler' packets- even with UDP. >> > > You're using FSP (which goes over UDP), correct? FSP has a retry > mechanism, so good. Glad it's working now! > I used FSP for the 'stumblers' but did the 100MB with scp (though the FSP did work for the 'stumblers'- I'll test FSP on the big file here momentarily) > >> I'm going to continue work on the 8b/10b, because I still think >> that's the closest 'real' solution to the issue- and the overhead >> isn't as severe as repeating 1500 byte packets- >> > > Well, only the "stumbler" packets get repeated, and as you found, there > were only five in 10,000 that you tried. So your overhead isn't 100%, > it's no different than if your channel dropped one in 2000 packets. (For > those following, the problem before resulted in a complete link failure, > as the retransmitted packets on the connection would always fail CRC.) > True enough, but that was also with random data- ordered data could yield either significantly higher hangup rate or perhaps none at all. 8b/10b seems like a good generic robustness idea- as I said, I'll implement it and test it, and if anyone wants to turn it on, cool beans. > >> Worst case, it can be an option in the python that most people can >> leave turned off. >> > > An 8b/10b line coding scheme would probably be best implemented as a > standalone hierarchical block that a developer could choose to use or > not as part of a flow graph implementing a transmit and receive path. > Sounds like a good plan and more or less what I had in mind. > >> FYI: Am achieving nearly 100kb/s with -r 800k on a BasicTX >> > > Is that bytes or bits per second? > 89-94 kibibits per second, nifty! (And thats not accounting for SCP overhead) > -- > 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] 8b/10b for GMSK
Johnathan Corgan wrote: > Johnathan Corgan wrote: > >> There is an alternative that Eric and I have conceived that would be >> a temporary workaround. It would not solve the original problem but >> would at least allow upper level protocols that do re-transmission to >> recover from the failure. I'll talk about that once I've got it >> coded, tested, and into my developer branch. > > This has been implemented, checked into a developer branch, and > successfully tested. > > A new command-line parameter has been added to both tunnel.py and > benchmark_tx.py, --use-whitener-offset. It defaults to false so existing > behavior is unchanged. > > A new 4-bit field has been added to the existing packet header, above > the 12 bits already used for the length field. This field holds an > integer (range 0-15) that represents an offset value. > > When transmitting, this value (which defaults to zero), determines the > offset into the whitening array which is XORed with the payload data to > form the whitened data for submission to the modulator. > > When the --use-whitener-offset option is set, this offset is > incremented for each transmitted packet, and stored in the new 4 bit > field. Thus, even identical packets, when transmitted successively, > result in completely different "on the air" data. > > The receiver extracts the offset value from the header and uses it to > recover the original data. In the case where the offset option is not > used, the offset is always set to zero, so the receiver behavior is then > unchanged. > > If a received packet fails CRC because of some pattern-specific > synchronization problem, and if the upper protocol layers cause a > retransmission, then the re-transmitted packet will have a different > whitened bit pattern, allowing it to go through. > > While this doesn't solve the underlying problem, whatever that may be, > it does give a workaround for users who have to get past this issue > while we are debugging it. Unfortunately this workaround is only for > people who are using higher level protocols which use retransmission to > recover from link errors. This of course includes TCP, which is the > underlying protocol for the majority of users. > > I've verified that my prior failure test cases now "work", in the sense > that the upper layers just continue as if the bad packets were dropped > due to noise. This includes ssh, scp, ftp, and https, each of which I > could reliably make to fail with the old code and now succeed with the > new workaround. > > The code is in the developer branch: > > http://gnuradio.org/svn/gnuradio/branches/developers/jcorgan/digital > > ...which is based on a snapshot of the trunk as of a couple days ago. > > We haven't decided whether this will make it into the trunk. We'd much > rather make a real fix. > > Johnathan Corgan > Corgan Enterprises LLC > http://corganenterprises.com > Yay- congratulations- transferred 100MB successfully and all of my 'stumbler' packets- even with UDP. I'm going to continue work on the 8b/10b, because I still think that's the closest 'real' solution to the issue- and the overhead isn't as severe as repeating 1500 byte packets- especially when you consider that ethernet and many other mediums use this specific implementation of 8b/10b. Worst case, it can be an option in the python that most people can leave turned off. FYI: Am achieving nearly 100kb/s with -r 800k on a BasicTX ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gmsk in light of fpga modifications
Daniel O'Connor wrote: > On Thursday 18 January 2007 21:31, Brett Trotter wrote: > >> I realize ssh probably isn't the best thing to test with, but it happens to >> be a quick and easy way to test file sending. The question is, is our >> tunnel acknowledging corrupted packets instead of asking for resends? The >> question I'm asking ultimately is, what would cause corruption of the ssh >> session? >> > > I suggest you install something like netcat > (ftp://coast.cs.purdue.edu/pub/tools/unix/netutils/netcat/) and see if raw > socket connections help things. > > Also you might be running out of entropy.. > > Saw the entropy problem when using /dev/random, but /dev/urandom seems happier- in either case, at some point, ctrl+c's quit working and the session basically locks up (with scp, it eventually stalls out- the most I transferred was a MiB)- but typing causes packets to traverse the tunnel even though the typed text does not render, nor seem to reach the other end. I ran a ping -A and lost '0%': 117536 packets transmitted, 117011 received, 0% packet loss, time > 1288562ms > rtt min/avg/max/mdev = 7.952/10.591/35.604/0.920 ms, pipe 3, ipg/ewma > 10.963/10.484 ms So bottom line is, the ssh dies off. I'm going to try out the tcpdump suggestion from Greg Troxel and see what things look like. It's possible that the interface is seeing so many errors that the checksums occasionally work out despite the errors- I'm going to also try increasing the symbols/sample. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gmsk
Paying more attention to your message this time, our intent is to use the LFTX/RX boards.. Is there any way to make it work with those as that is our target frequency range? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gmsk2 (new tunnel.py)
Eric Blossom wrote: > On Thu, Jun 22, 2006 at 03:32:10PM -0500, Brett L Trotter wrote: >> I've got two machines with one usrp each using basic tx/rx board pairs. >> >> As soon as I start tunnel.py on each and set the ip's, one machine >> (usually the one started second) starts showing B. >> >> If i disconnect wires, both sides go silent, reconnect and one or both >> start showing b... >> >> what is the 'B' anyway? > > 'B' means "backoff". > It prints a B everytime it attempts to transmit if it detects carrier. > >> I cannot ping between the hosts.. what am I missing? > > First off, this example will only work with RFX-* daugherboards, not > the basic tx and rx board. Why: we currently can't enable/disable the > transmitter on the basic tx board. > > If using a RFX-* board and you see this, try setting the rx gain lower > and/or the carrier sense threshold higher. > > $ tunnel --help > > will give help ;) > > Eric > Thanks for your wonderful help and patience so far. I've gotten rid of the B's with sufficently high -c options, but ping still isnt happening.. A: ./tunnel.py --freq 102.0M --bitrate 500k -c 80 (other terminal) ifconfig gr0 10.10.10.1 (other terminal) ping 10.10.10.2 also tried with route add -host 10.10.10.2 gr0 B: ./tunnel.py --freq 102.0M --bitrate 500k -c 80 (other terminal) ifconfig gr0 10.10.10.2 (other terminal) ping 10.10.10.1 also tried with route add -host 10.10.10.1 gr0 both pings fail.. though I'm getting nice Tx: len(payload) messages with sizes from 42-283 on both sides. I've got to be missing something silly at this point- i've got cables between the machines RX->TX and TX->RX cross connect with SMA cable, though cables are about 1M (I don't have 3M cables just this second). Could cable length be my problem? Thanks again. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
