[Discuss-gnuradio] firmware, did anyone verify hook_fgv ?
Dear all,
I modified a little the firmware of a usrp-based device.
I wanted to check the buffer overrun event on the BULK IN EP2 FIFO, but the
interrupt autovectoring mechanism doesn't work.
The following code
static void
isr_EP2FULLFLAG (void) interrupt
{
clear_fifo_gpif_irq ();
IOD ^= 0x01;
_usb_rx_overrun++;
}
void install_handlers (void)
{
setup_descriptors ();// ensure that they're set before use
hook_uv (UV_SUDAV, (WORD) isr_SUDAV);
hook_uv (UV_USBRESET, (WORD) isr_USBRESET);
hook_uv (UV_HIGHSPEED, (WORD) isr_HIGHSPEED);
hook_fgv (FGV_EP2FF, (WORD) isr_EP2FULLFLAG);
SYNCDELAY; EP2FIFOIE = 0x01; /* The FF on the EP2, which is BULK IN */
SYNCDELAY;
USBIE = bmSUDAV | bmURES | bmHSGRANT;
}
I don't see any changes in the port D bit 0 or _usb_rx_overrun variable,
even in case of the EP2 overrun, which I can less efficiently verify with
EP2468STAT or EP24FIFOFLGS (and maybe EP2CS as well).
Any clue? Did someone ever try hook_fgv?
Regards,
Mic
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Unable to install GNU radio with UBUNTU 7.1
Eric Blossom schrieb: On Sat, Nov 24, 2007 at 05:23:50PM -0800, Johnathan Corgan wrote: Did you add your user account to the 'usrp' group? You'll also need to log out and back in (or possibly reboot) for this to properly take effect. No need to reboot. Just a new top-level login. su - does the trick without new login. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with std.ihx
On Sun, Nov 25, 2007 at 03:15:00PM -0800, Martin Gawecki wrote: > Eric, > > > On a somewhat related question, when I do run usrp_fft.py as well as > usrp_oscope.py, I'm not able to actually control the GUI - it seems like its > "frozen" although I do get some waveforms. At the same time, the string "u0" > is continually written to the terminal. Those are usrp overruns, which indicates that your system is not keeping up with the data streaming from the usrp. You can fix this by using a higher decimation rate, or buying a faster computer. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with std.ihx
On Sun, Nov 25, 2007 at 04:32:43PM -0800, Martin Gawecki wrote: > Thanks George, > > > FYI: No Powermate or Contour Knob found > > And by the way - is there someplace where I can just look up what all these > erroneous outputs mean? Try googling powermate or contour knob. Don't forget that you have the source code ;) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Python blocks in a new package
Eric Blossom wrote: $ python from gnuradio import tdrss_utils dir(tdrss_utils) Do you see your module(s) in there or something unexpected? When I try the above, all I see is ['__builtins__', '__doc__', '__file__', '__name__', '__path__'] No trace of 'gold_code_pn_source_b' Here's the listing of .../site-packages/gnuradio/tdrss_utils: -rw-r--r-- 1 root wheel22 Nov 21 23:41 __init__.py -rw-r--r-- 1 root wheel 151 Nov 21 23:41 __init__.pyc -rw-r--r-- 1 root wheel 151 Nov 21 23:41 __init__.pyo -rw-r--r-- 1 root wheel 1459 Nov 21 23:41 gold_code_pn_source_b.py -rw-r--r-- 1 root wheel 1131 Nov 20 16:56 gold_code_pn_source_b.pyc -rw-r--r-- 1 root wheel 1131 Nov 20 16:56 gold_code_pn_source_b.pyo @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Python blocks in a new package
On Tue, Nov 27, 2007 at 10:11:51AM -0500, Ed Criscuolo wrote: > Eric Blossom wrote: >> >> $ python >> > from gnuradio import tdrss_utils > dir(tdrss_utils) >> >> >> Do you see your module(s) in there or something unexpected? >> > > > When I try the above, all I see is > ['__builtins__', '__doc__', '__file__', '__name__', '__path__'] > > > No trace of 'gold_code_pn_source_b' > > Here's the listing of .../site-packages/gnuradio/tdrss_utils: > > -rw-r--r-- 1 root wheel22 Nov 21 23:41 __init__.py > -rw-r--r-- 1 root wheel 151 Nov 21 23:41 __init__.pyc > -rw-r--r-- 1 root wheel 151 Nov 21 23:41 __init__.pyo > -rw-r--r-- 1 root wheel 1459 Nov 21 23:41 gold_code_pn_source_b.py > -rw-r--r-- 1 root wheel 1131 Nov 20 16:56 gold_code_pn_source_b.pyc > -rw-r--r-- 1 root wheel 1131 Nov 20 16:56 gold_code_pn_source_b.pyo > Where's the shared library (.so file)? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Python blocks in a new package
Eric Blossom wrote: On Tue, Nov 27, 2007 at 10:11:51AM -0500, Ed Criscuolo wrote: Here's the listing of .../site-packages/gnuradio/tdrss_utils: -rw-r--r-- 1 root wheel22 Nov 21 23:41 __init__.py -rw-r--r-- 1 root wheel 151 Nov 21 23:41 __init__.pyc -rw-r--r-- 1 root wheel 151 Nov 21 23:41 __init__.pyo -rw-r--r-- 1 root wheel 1459 Nov 21 23:41 gold_code_pn_source_b.py -rw-r--r-- 1 root wheel 1131 Nov 20 16:56 gold_code_pn_source_b.pyc -rw-r--r-- 1 root wheel 1131 Nov 20 16:56 gold_code_pn_source_b.pyo Where's the shared library (.so file)? There is no shared library in tdrss_utils. Should there be? It only has the one python module, nothing in C++. I have a separate package called "tdrss" which contains all the processing blocks written in C++. Those all work and pass their QA tests when I do a "make check". In .../site-packages/gnuradio/ there is: _tdrss.la _tdrss.so tdrss.py tdrss.pyc tdrss.pyo tdrss_utils/ Is there some way to put it all in one package? When I tried this by doing a "make" and "make install" with the directory named ...tdrss/src/python/tdrss/, I couldn't import any of my C++ modules. As soon as I changed the name to ...tdrss/src/python/tdrss_utils/ that problem went away. @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] TVRX
Matt, Is the TVRX daughter board expected to change anytime in near future? Thanks, Nirali Patel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] no signal from LFTX when data sent from gr.file_source
Hi all, I have been testing USRP and Gnu Radio for a while and it's been a very interesting, educational experience. One of the important things for me is to get capture to / playback from file capability to work. I simplified usrp_rx_cfile.py a bit and essentially what my script does is: usrp.source_c --> gr.head --> gr.file_sink It produces huge files (with complex samples, I understand) which I intend to "play" back through LFTX daughterboard. So, another script does something like: gr.file_source (gr.sizeof_complex, fname,true) \-> usrp.sink_c (0, interp) \-> fftsink2.fft_sink_c Gain on the LFTX is set to -1.02 dB - as read by self.u.pga(0). The problem is that I don’t get any signal from LFTX although I can see the expected spectrum in the FFT window (which is connected in parallel to the same stream). The signal is digital radio transmission with estimated S/N around 40 dB. Since the spectrum matches what I had seen when tuning the radio with some receiver script which also provided FFT window, I assume data stream is OK. Just to check my hardware I tried usrp_siggen.py and checked the outputs of LFTX with an oscilloscope. I could see the expected sine wave nicely phase shifted by pi/2. Hardware is OK, but somehow my “playback” script doesn’t want to push data out. Do you have any suggestions? Thanks, Peter ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)
Hi all, I was looking to kick some discussion to the board to get some ideas here. The in-band signaling code is likely to be used by many to research MAC protocols, and one thing crucial to CSMA style protocols are dependent packets which have very strict timing requirements. For example, an ACK is a dependent packet, it relies on a DATA packet to be generated. Generating these packets using the in-band code and the framing of some physical layer at the host using GNU Radio will be no problem. However, the latency across the bus will almost guarantee that these packets will never be transmitted and received in time to meet the strict timing requirements of most protocols such as 802.11. I'm not saying we're trying to meet 802.11 specs, just to giving an example. So what I would like to discuss are techniques to generating dependent packets in the USRP without placing the full physical layer in the FPGA. This would inhibit flexibility, which is a major goal of a development platform such as GNU Radio. If we wanted to meet 802.11 specs, sure... we could try this. But it's not our goal. We want the to keep the flexibility of using any physical layer. What I had discussed with Jeff (CC'ed) previously when asked how we would handle these situations, was the possibility of a technique using some sort of sample pattern matching. I don't know how possible this is in reality, this is at a level I'm still not very familiar with... but trying to learn :) There could be space in the FPGA where patterns could be stored that could be used to look-up incoming streams of samples. For example, after decoding one frame successfully in GNU Radio, is it possible that the host has some general idea of what the start of frame bits and its address look like (given its framing format) in sample space? If so, it could pass some amount of samples back to the FPGA to use in pattern matching. Of course, it is difficult to tell for sure if the packet can be successfully decoded without going to the host and using the physical layer. It may turn out that some of the bits are incorrect using a checksum, for instance, for which an ACK would not be generated. Generating a false-ACK could have negative impacts, but it is not so bad as generating an ACK for data not truly destined to you ;) The higher layers such as TCP could be used to recover from this error. These are all trade-offs that are great research material for SDRs and packet radio which can't meet timing specs, in my opinion... which I'd love to explore. While we cannot detect for sure whether the full packet can be decoded properly, SNR and other values could be used to make a ballpark guess. And again, if we guess wrong OK, it's a performance trade-off that can have negative impacts if wrong. Penny for your thoughts. I don't even know how realistic sample pattern matching is in the FPGA... I'm open to "you're crazy" responses, I don't typically work at this level. :) But maybe there's some other technique that could be used to generate these packets without incurring the bus latency. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TVRX
Nirali Patel wrote: Matt, Is the TVRX daughter board expected to change anytime in near future? No Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)
A few questions: - What is the current round trip latency for the in-band code? - Have you tried synchronizing two different USRPs to each other over the air? - What is the minimum amount of turnaround time you're looking to achieve? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SWIG only inherits interfaces from smart pointers
I have been trying to create a GNU Radio project composed of various
swig wrapped modules. In order to explain my problem, the following
subproblem might be useful to know about. I apologize ahead of time
for the length of this email. =)
SUBPROBLEM:
I would like to be able to have class B in module modB inherit from
class A in module modA. This would be implemented across two SWIG
interface files modB.i and modA.i.
// modA.i
#ifndef SWIGIMPORTED
%module modA
#endif
%{
#include
%}
%include
// modB.i
#ifndef SWIGIMPORTED
%module modB
#endif
%import modA.i
%{
#include
%}
%include
// classA.h
class A
{ ... }
// classB.h
class B : class A
{ ... }
The problem is that when I compile modB, the python wrapper generated
by SWIG (modB.py) does not give class B any of the inherited functions
from class A. It seems to just ignore class A all together.
If I remove the preprocessor tag "#ifndef ...", the SWIG generated
modB.py then tries to "import modA" which is not necessarily in that
directory. Ideally I would like to have SWIG just look at classA.h and
classB.h and create an interface from those two class definitions.
MAIN PROBLEM:
After trying to accomplish the above task unsuccessfully, I noticed
that the usrp module in gnuradio actually tries to do roughly the same
thing. I noticed, however, that in the SWIG wrapper python code
(usrp1.py) only the smart pointer classes (e.g. usrp1_source_c_sptr)
inherit any of the functions from their respective parents. This
happens even when I create a project (such as gr-howto) outside of the
gnuradio trunk. I am definitely at my wits end with trying to figure
out how to properly wrap my c++ classes with SWIG and could really use
some help.
QUESTION:
Could someone explain what happens when I place "%import 'gnuradio.i'
" into my interface file. Specifically, why does this allow me to
inherit methods from gr_block (and gr_basic_block) only for smart
pointers? Also are there any special SWIG directives that have to be
used to get inheritance to work across multiple modules (e.g.
%module(directors="1") modA )?
ADDITIONAL INFORMATION:
- I'm not getting any compile errors or warnings. The SWIG wrapped
python object just doesn't have the right interface.
- SWIG version: 1.3.31
- GNU Radio version: 3.1.0
Thanks for your help.
--
Ketan Mandke
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)
Brian Padalino wrote: A few questions: - What is the current round trip latency for the in-band code? To measure the round trip latency we used three USRPs... two in contention and a third monitoring. The two in contention would exchange the channel back and forth by reading the RSSI value from the incoming packets. To spare the details and cut to the chase, we measured the gap between the time the channel went idle, the contending node detected it was idle, and began transmitting. This is essential measuring dependent packets and host-level carrier sense performance. The average was 1.96ms and sdev 0.62ms. - Have you tried synchronizing two different USRPs to each other over the air? What do you mean by synchronizing? - What is the minimum amount of turnaround time you're looking to achieve? Tens of microseconds would be great... but I'm not sure if this is achievable? Hundreds of microseconds would be decent :) - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)
The average was 1.96ms and sdev 0.62ms. Sorry, I omitted the fact that this was calculated from 200 values. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)
On Nov 27, 2007 10:43 PM, George Nychis <[EMAIL PROTECTED]> wrote: > To measure the round trip latency we used three USRPs... two in > contention and a third monitoring. The two in contention would exchange > the channel back and forth by reading the RSSI value from the incoming > packets. To spare the details and cut to the chase, we measured the gap > between the time the channel went idle, the contending node detected it > was idle, and began transmitting. This is essential measuring dependent > packets and host-level carrier sense performance. > > The average was 1.96ms and sdev 0.62ms. That doesn't seem too bad to me. > What do you mean by synchronizing? Lets say for a TDMA MAC, there is a beaconing time that happens every 50ms for 1 ms and a 200us guard time between beacons for a specified number of radios. Can you setup a USRP to transmit some data every 50ms, and have a second USRP lock on to that periodic 50ms transmission and be sure to be on the air at 51.2ms +/- 10us? Is this a reasonable expectation? > Tens of microseconds would be great... but I'm not sure if this is > achievable? Hundreds of microseconds would be decent :) Is there any driving reason for a requirement of tens of microseconds? Is it mainly to be compatible with 802.11 style systems? To be honest, I feel that trying to achieve the turnaround of tens of microseconds is too lofty a goal without creating a special FPGA load for that specific waveform. I am not saying a custom FPGA load is a good or bad thing - I just think you can't go over USB and have the host do processing to then go back over USB for a response. There's just too much to do for it to basically be a real-time system. I feel that if you give a minimum latency of 2ms that there won't be issues creating latency tolerable MAC layers. On the other hand, being compatible with current waveforms that may be completely implemented in custom ASICs might be a bit of a problem. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)
Lets say for a TDMA MAC, there is a beaconing time that happens every 50ms for 1 ms and a 200us guard time between beacons for a specified number of radios. Can you setup a USRP to transmit some data every 50ms, and have a second USRP lock on to that periodic 50ms transmission and be sure to be on the air at 51.2ms +/- 10us? Is this a reasonable expectation? Let me find out :) Is there any driving reason for a requirement of tens of microseconds? Is it mainly to be compatible with 802.11 style systems? Mainly, yes. To be honest, I feel that trying to achieve the turnaround of tens of microseconds is too lofty a goal without creating a special FPGA load for that specific waveform. I am not saying a custom FPGA load is a good or bad thing - I just think you can't go over USB and have the host do processing to then go back over USB for a response. There's just too much to do for it to basically be a real-time system. I feel that if you give a minimum latency of 2ms that there won't be issues creating latency tolerable MAC layers. On the other hand, being compatible with current waveforms that may be completely implemented in custom ASICs might be a bit of a problem. I totally agree that 2ms is not that bad and is something that MAC layers can certainly deal with. The goal is an attempt to be compatible with current waveforms using software radios. Are there techniques that we can use to try and achieve these low latencies without implementing the PHY fully in the hardware? This is what I'm interested in. Is any sort of sample pattern matching possible in the slightest bit? - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
