Re: [Discuss-gnuradio] Bricking and recovery of N210
Hi Nick, Please send me also the n210.bit file. I experience the similar problem as was presented in: [Discuss-gnuradio] Getting USRP N210 running http://lists.gnu.org/archive/html/discuss-gnuradio/2010-12/msg00222.html The safe mode by pressing J2 doesn't work. So I want to try re-program the FPGA. BTW: How can I generate the .bit file myself using the FPGA source code. I'm a Layman to FPGA. :) Bests, Hanwen 2011/4/20 Nick Foster > On Wed, 2011-04-20 at 10:13 +1000, Vladimir Negnevitsky wrote: > > Hi folks, > > > > We've recently received an N210. I updated the firmware successfully a > > few times, but then usrp_n2xx_net_burner.py crashed. I immediately > > tried rewriting the image, and all seemed to go fine, however both > > default and backup booting (holding S2 during powerup) failed. I > > directly programmed the FPGA over JTAG using iMPACT and a Xilinx > > platform cable, and the firmware loaded correctly. At this point I ran > > usrp_n2xx_net_burner.py twice with both the default and the > > --overwrite-safe options. Rebooting into both the default and safe > > images worked fine and FLASH burns have worked since then. > > This is something that's strangely come up three times this week on the > list, under similar circumstances, despite several months of (mostly) > trouble-free updates. We've been so far unable to replicate it here or > deduce why it's happening, and I've got an N210 here which I've been > continuously updating for several hours without incident. Either it's > cosmic rays, or something else we haven't found yet. Can you please send > me the following information: > > * OS and version > * UHD host code version > * FPGA/firmware versions > * Ethernet card model > * Any hub or switch in between the PC and the N210? > * What exactly was the behavior of the net burner app? Did it crash, or > stall? What arguments did you invoke it with? > > > > > I have a feeling I was very lucky. Since I only reprogrammed the FPGA, > > it would have searched the FLASH for working ZPU firmware, which must > > have been intact. My question is, is there any technique to recover > > the N210 in the event that both the FPGA and ZPU firmware are corrupt? > > I've seen it alluded to in old posts where the CPU and FPGA firmware > > were accidentally written into each other's locations. The technique > > would be very useful if a similar crash happens again and it *does* > > overwrite the CPU firmware this time. I'd also like to hear others' > > success (or failure) stories. > > You're right about the mechanism of recovery. In the future, if the > updater crashes, locks up, or otherwise behaves anomalously, do the > following before rebooting: > > Re-load the safe firmware and FPGA image with the --overwrite-safe > option of the N210 firmware updater (NEVER USE THIS OPTION OTHERWISE). > Use the latest N210 images from the UHD download site for this step. It > should then be safe to reboot. > > For future reference, if you (or anyone else) manage to brick your N210 > using the firmware updater, we'll be happy to issue an RMA to have it > recovered here. If you'd like to recover it yourself, it's really not > that hard, provided you have a Xilinx Platform JTAG cable and a USB to > RS232 (3.3V logic level ONLY) adapter. Here's how to bootstrap it: > > 1. JTAG program FPGA with n210.bit (email me for it, it's just the .bin > file with a header, but iMPACT requires it). The FPGA bootloader will > start and won't find software, so it falls back to an Intel HEX prompt. > If your firmware hasn't been erased, it will boot the firmware, the LEDs > on the front panel will go through their startup sequence, and you can > skip step 2. > > 2. Build the N210 firmware from the latest UHD master (or I can email it > to you). Connect the USB-RS232 adapter (be SURE it's 3.3V logic level > output!) to J305 -- the silkscreen labels the pinout. Run the program > firmware/zpu/bin/uart_ihex_ram_loader.py . The IHX > file will be named usrp2p_txrx_uhd.ihx. The RAM loader should say "USRP2 > + found" and start loading. When it finishes, it will load the program. > > 3. At this point the device is up and running like a regular USRP N210, > and you should be able to write firmware and FPGA images to it. Use the > --overwrite-safe option of the N210 firmware update program to write > safe FPGA and firmware images first, then load production FPGA and > firmware images. Use the latest N210 images from the UHD download site. > After loading all four images, go ahead and reset the device. It should > now be operating normally. > > > We apologize for any inconvenience, and we'll find an explanation for > the issue as soon as possible. > > --n > > > > > > Best regards, and thanks for your help. > > > > Vlad > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > __
Re: [Discuss-gnuradio] Extending UHD Device Support
On Fri, Aug 26, 2011 at 11:45 AM, Wilson, Jeffery (DS-1) wrote: > Designation: Non-SSA/Finmeccanica > > Matt, > > Thank you for your response. We will certainly be sure to abide by any and > all licensing requirements as we move forward. > > As for now I would like to develop a simple source block (without using UHD) > for our radio so I can at least do something like a basic FFT display as a > proof of concept that we can in fact get our radio working in some way with > GNU Radio. Is there anywhere I can find help/guidance specific to creating > new source blocks other than picking apart the current ones? If not, which > block(s) would be a good starting place? > > Thanks! > > -- Jeff Hi Jeff, Most of the hardware interfaces we have consist of a hardware interface library (call it drs0) and a GNU Radio wrapper block around that one that would be called gr-drs0. The gr-drs0 is structured in a standard GNU Radio format. It inherits from a gr_block (actually, it's usually a gr_sync_block), has a constructor to initialize the device through the drs0 library, and has a work function that either gets samples to push onto the flow graph for a receiver or takes samples from a flow graph and sends them to the device for a transmitter. This will also have wrapper accessors to get and set the properties of the device, like frequency, gain, etc. If you want to have a quick hack at it without the UHD, you can look at how things were done with usrp and gr-usrp (or usrp2 and gr-usrp2), which are both in the GNU Radio source tree. If you can work with the UHD, though, I would recommend doing so. It would make integration into GNU Radio projects much simpler. Tom > From: Matt Ettus [mailto:m...@ettus.com] > Sent: Thursday, August 25, 2011 6:18 PM > To: Wilson, Jeffery (DS-1); discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Extending UHD Device Support > > > > Jeffery, > > The first thing to keep in mind is that everything is GPL'ed (and > specifically, *not* LGPL). This means that if you use any UHD host code, > you must obey the GPL for EVERYTHING that links in. This goes all the way > up to your customer's application. This restriction already applies for GNU > Radio itself since it is also GPL'ed. > > The firmware is GPL'ed. This means that if you use any of the firmware, > your ENTIRE firmware image must obey the terms of the GPL. > > The FPGA design is GPL'ed. This means that if you use any of our Verilog, > *everything* compiled into that FPGA image must comply with the GPL. This > would include all of your custom signal processing code, if it is in the > same FPGA. > > The implementation of UHD host code is heavily oriented towards the state > machines in the firmware and FPGA, so modifying it to work with other > devices is easier if they use the same firmware and FPGA designs. This is > fine as long as you are ok with invoking the GPL requirements on those > portions of your design. > > Users of Ettus Research hardware are able to use all of this under less > restrictive terms in our alternative license. > > Matt Ettus > President, Ettus Research LLC > > On Wed, Aug 24, 2011 at 8:23 AM, Wilson, Jeffery (DS-1) > wrote: > > Designation: Non-SSA/Finmeccanica > > Hello, > > > > We make several RF front-ends that we’d like to see supported in GNU Radio. > Our initial idea is was to extend the Ettus UHD to include support for our > devices, so that a waveform/flow graph using a UHD block could run using > either a USRP or one of our devices with only minor modifications. Does it > “make sense” to extend UHD for this purpose? > > > > Our radios are embedded Linux systems that can communicate over USB as well > as Ethernet. Initially I would like to use Ethernet as communication (using > sockets). As far as I can figure a good place to start would be to follow > the USRP2 UHD implementation and re-implement it for our system. > > > > Any tips, examples or general guidance would be very much appreciated. > > > > Thank you! > > > > -- > > Jeff Wilson > > DRS Signal Solutions, Inc. > > Direct: 301.944.8772 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] web site down?
On Fri, Aug 26, 2011 at 11:42 AM, Walter Barmak wrote: > hi, > > is it possible that there is something going on with the gnuradio + uhd > git repository web site? > > i'm trying to reinstall build-gnuradio and have been waiting at: > "checking for package libxi-dev" for more than 2 hours. > > thanks in advance, There were a few hiccups with both the GNU Radio and Ettus websites this past week that appear to be related to our (different) hosting services. Things look normal now. Incidentally, libxi-dev is not served by either website, so any trouble with our services wouldn't have affected that. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Looking for books and online courses on gnuradio?
On Thu, Aug 25, 2011 at 12:49 PM, Nazmul Islam wrote: > This is Nazmul, a PhD student of Wireless Info. & Networking Lab of ECE, > Rutgers University. I need to use GNUradio in UHD platform to implement some > wireless communication algorithms. I have two very general questions. > > 1. Do you know of any book that focuses mostly on software defined radio > with GNUradio? I found one > (http://www.amazon.com/Software-Defined-Radio-GNU-USRP/dp/0071498834) but it > is out of print! :S > > 2. Do you know of any online course that focuses on GNU radio? > > Basically, I am a beginner in software defined radio research. I am coming > from mostly theoretical wireless communication background and I have some > limited programming language experiences (C/C++, Matlab). I will really > appreciate if you can even suggest some general books/online courses on > software defined radio that might help me. I am probably asking some > elementary questions but any of your feedback will be really helpful. > > Thanks, > > Nazmul Nazmul, Search back in the archives on this topic as it has come up a lot. The short answer is that there is no book dedicated to this topic, and the one you pointed out was never published (and I don't know why Amazon keeps it on its website). There are a couple, but instead of rehashing this conversation, please look for the past discussions of this topic. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bricking and recovery of N210
> Please send me also the n210.bit file. > I experience the similar problem as was presented in: > [Discuss-gnuradio] Getting USRP N210 running > http://lists.gnu.org/archive/html/discuss-gnuradio/2010-12/msg00222.html > > The safe mode by pressing J2 doesn't work. So I want to try re-program the > FPGA. > The bit and bin files for Nseries devices can be found in the images package: http://code.ettus.com/redmine/ettus/projects/uhd/wiki > BTW: > How can I generate the .bit file myself using the FPGA source code. I'm a > Layman to FPGA. :) > Bit and bin files are generated by the same process. See this Makefile for commands to run to generate FPGA images: http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/images/Makefile Happy Hacking! -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The correlator of benchmark_rx.py looks dose not work well
On Fri, Aug 26, 2011 at 10:41 AM, Nick Foster wrote:
> Sorry, forgot to reply to list:
>
> On Fri, Aug 26, 2011 at 5:16 AM, Zhonghua wrote:
>>
>> Hi everyone,
>> When I start to assemble 'gnuradio/examples/digital/benchmark_tx.py' and
>> 'gnuradio/examples/digital/benchmark_rx.py', I found there is no output from
>> the 'rx_callback' function defined in benchmark_rx.py. I inspected it
>> further and found no message is stored in the 'framer_sink'. I got rid of
>> the 'USPR' part from both transmitter and receiver ports, then just connect
>> the remainder parts such as modulator,demodulator,correlator and
>> framer_sink. There is also no any message in the framer_sink. I wrote my
>> own test-bench in which I made a packet with the 'packet_utils.make_packet'
>> tool and transmitted the packet to the modulator(blks2.mod_pkts),then
>> connect to the demodulator('dbpsk_demod' class of dbpsk.py) and correlator
>> (gr.correlate_access_code_bb(access_code, threshold)). I watched the input
>> and output of the correlator and found that the correlator looks does
>> nothing but just delays the input for 64 bits. The input and output data are
>> as below:
>
> It's actually working exactly as designed. The correlate_access_code_bb
> block outputs the original 1-bit-per-byte data and sets the second bit to
> "1" when it finds a correlator match.
> --n
>
>>
>> input:
>> (0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 1, 1, 1, 1, 0, 0, 1, 0, 0, 1, 0, 0, 1, 1,
>> 1, 1, 0, 0, 1, 0, 1, 0, 1, 0, 1, 1, 0, 0, 1, 1, 0, 1, 1, 1, 0, 1, 1, 0, 1,
>> 0, 0, 1, 0, 0, 1, 1, 1, 0, 0, 0, 1, 0, 1, 1, 1, 1, 0, 0, 1, 0, 1, 0, 0, 0,
>> 1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1,
>> 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0, 0,
>> 1, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0, 0, 1,
>> 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0,
>> 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 1, 0, 0, 0, 1, 1, 0, 0,
>> 1, 0, 0, 0)
>> The input length is 228
>> output:
>> (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0,
>> 1, 1, 1, 1, 0, 0, 1, 0, 0, 1, 0, 0, 1, 1, 1, 1, 0, 0, 1, 0, 1, 0, 1, 0, 1,
>> 1, 0, 0, 1, 1, 0, 1, 1, 1, 0, 1, 1, 0, 1, 0, 0, 1, 0, 0, 1, 1, 1, 0, 0, 0,
>> 1, 0, 1, 1, 1, 1, 0, 0, 1, 0, 1, 0, 0, 0, 1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0,
>> 0, 1, 1, 1, 1, 1, 1, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0,
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>> 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0,
>> 1, 1, 0, 0)
>> The output length is 228
>> We can see that the output of the correlator is just 64 bits delayed
>> string of the input and there even has an error bit of '2' in the string.
>> Because the input vector has been delayed, the original last 64 bits are
>> eliminated.
>> As my understanding the correlator which input is 1 bit per input byte
>> should do the access_code detection and then output a string of 2 bits per
>> byte. The data following the access_code would be detected and so could be
>> seen as effective data to send to the framer_sink. But my factual output of
>> the correlator is not like that. Could anybody tell me why? My gnuradio
>> version is gnuradio-3.3.0.
>>
>> BR,
>> Zhonghua
The delay is in the filters in both transmit and receive paths, so
that is expected. They are FIR filters, so the group delay is well
behaved and known, depending on the number of taps that are used.
You can use the benchmark_loopback.py test, which doesn't use any
radio hardware but instead has a simulated channel. That should work
for you.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] minor bug
On Fri, Aug 26, 2011 at 10:00 AM, Dimitris Symeonidis wrote: > I noticed that the "docs" component passes the configuration tests > even without doxygen installed. This on Ubuntu 11.04, latest gnuradio > from git master. That might actually be on purpose, since there is more in the docs than just the Doxygen-generated stuff. Does this generate and failures during make, make check, or make distcheck for you? > Also, it seems fort77 is no longer a dependency, not sure when it went away... Yeah, I don't recall why we had fort77 as a dependency. If it really isn't necessary, it shouldn't be listed. Thanks! Tom > Have a nice weekend > > Dimitrios Symeonidis > "If you think you're too small to make a difference, try sleeping with > a mosquito!" - Amnesty International > > ___ > 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
Re: [Discuss-gnuradio] Two instances of QT GUI Sink in a single program
On Thu, Aug 25, 2011 at 4:41 AM, Sivan Toledo wrote: > Is it possible to put two QT GUI Sinks (FFT displays) in a single > application window? I want to use one to show the radio spectrum (to/from > UHD) and another to show the audio spectrum, at the same time. > > When I put two QT GUI Sink blocks in a GRC graph, I see only one of them in > the application windows, unlike QT GUI Entries and other GUI elements that > can have many instances in the same window. > > Thanks, Sivan Toledo You can definitely have more than one QT GUI blocks in a program. It's probably an initialization problem that's going wrong in your code. You can see multiple QT GUI's used in gnuradio-examples/python/digital/benchmark_qt_loopback.py. Also, gnuradio-companion now works with QT GUI (set in the Options block), and it handles multiple QT GUI blocks. You could create something there, build the flow graph, and then see how the QT GUI objects are manipulated to make sure they all get shown properly. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Need to resolve error: "Unpack requires a string argument of length 3"
On Sat, Aug 13, 2011 at 7:13 PM, Nazmul Islam
wrote:
> Hello,
>
> This is Nazmul, a PhD student of Rutgers University. I am using a modified
> form of 'benchmark_Tx.py' and 'benchmark_Rx.py' for my research. I am
> transmitting a random binary sequence and calculating the bit error rate at
> the receiver (BER). Basically, I am generating a long binary sequence,
> grouping them into different packets and then transmitting the packets using
> 'benchmark_Tx' program. I receive the packets using 'benchmark_Rx.py' and
> then find the BER. The program works at high transmitter amplitude, i.e.,
> when channels are good. However, when I start lowering the transmitter
> amplitude, i.e. create bad channels, at some point, I get the following
> error:
>
> Exception in thread Thread-1:
> Traceback (most recent call last):
> File "/usr/lib/python2.6/threading.py", line 532, in __bootstrap_inner
> self.run()
> File "/usr/local/lib/python2.6/dist-packages/gnuradio/blks2impl/pkt.py",
> line 164, in run
> self.callback(ok, payload)
> File "./rec_randombingen.py", line 97, in rx_callback
> (ide,pktno,) = struct.unpack('!cH', payload[0:3])
> error: unpack requires a string argument of length 3
>
> After showing this error, the whole programs. Let's assume that I am
> transmitting 100 packets. If this error occurs at 20-th packet, the
> benchmark_rx does not receive the next 80 packets. This really hampers the
> calculation of packet loss probability and bit error rate.
>
> I guess, for very bad channels, noise is acting as erasure, i.e., some part
> of the packet header is getting erased. Ideally, I would like the program to
> assume this packet to be 'lost' and move on to receiving the remaining
> packets. It is OK with me if I lose a packet due to this type of error but
> how can I make sure that the whole program does not stop due to this error?
>
> Your feedback will be very appreciated.
>
> Thanks,
>
> Nazmul
Nazmul,
There are certain cases where the frames are received with errors that
are just such a way that passes the checks and are delivered to the
callback function. My guess is that it occurs when the received packet
length is received as 0. When the unpack action happens with no
payload, it throws an error.
One way to work around this is to put in an extra check for the packet
size, if this is indeed the problem. You can also put a try/except
block around the code to catch when those errors happen.
In my previous experience, these issues happened rarely, but it sounds
like you are having a bigger problem with it. Could be that I was
running in a higher SNR environment, so that these errors were more
rare.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FFTW usage in a new signal processing block
On Thu, Aug 25, 2011 at 09:57:30AM -0300, Felipe Fideles wrote: > Hello All, > > I'm trying to use FFTW in the development of a new signal processing block. > The ./boostrap and ./configure commands work fine, but when I type the make > command, I get the following error: > > /usr/src/gnuradio/gr-deteccao/ lib/.libs/libgnuradio-deteccao.so: undefined > reference to `fftw_execute' > /usr/src/gnuradio/gr-deteccao/lib/.libs/libgnuradio-deteccao.so: undefined > reference to `fftw_plan_dft_1d' > /usr/src/gnuradio/gr-deteccao/lib/.libs/libgnuradio-deteccao.so: undefined > reference to `fftw_destroy_plan' > collect2: ld returned 1 exit status > > It sounds weird because the fftw in already at the gnuradio files. It's solved. Just type ./configure LIBS=-lfftw3 that it works. -- Felipe Fideles ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] New build-gnuradio
I've updated build-gnuradio to use a somewhat different approach to fetching firmware/fpga images from the newly-shuffled website where they're now kept. I'm sure I'll need to do it again. http://www.sbrac.org/files/build-gnuradio -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
