[Discuss-gnuradio] Re: Porting GNURadio to arm-linux platform - build Debian package
Younghun Kim schrieb: Thank you for the link. I should try those debian packages, although I wanted to customize the gnuradio packages for my purpose. This is no problem. Debian supports building packages on your own, with your own change set. In general you do: (# as root/sudo, $ as user) # apt-get update # apt-get install build-essential # Compilers, linker, -dev stuff $ apt-get source $ apt-get build-dep $ cd - $ -> do your changes $ dch -i # update package version so it won't be overwritten on update $ debuild # or dpkg-buildpackage -rfakeroot $ cd .. # dpkg -i Share and enjoy! The Debian Reference[0] and the New Maintainers Guide[0.5] will help you. Short explanation at Building Custom Debian Packages[1] [0] http://www.debian.org/doc/manuals/reference/ch-package.en.html#s-port [0.5] http://www.debian.org/doc/manuals/maint-guide/ch-build.html [1] http://www.dit.gov.bt/admin/index.php?title=Custom-packages&redirect=no -- 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
[Discuss-gnuradio] FPGA original firmware problems
Hello list, First I apologise for posting in the Recovering x(t) from IQ samples thread, please delete my post there if possible. I also removed my old account from the list and created this new one. I have recently changed the USRP clock with an external PLL. Then I used the previously precompiled standard firmware std_4rx_0tx.rbf , using 2 sinusoidal inputs (2.1 MHz) to RXA, RXB with the results confirming that everything was working fine. I then downloaded the 3.0.4 version and tried to recompile the usrp_std project. I used the usrp_std.rbf file produced with the rx_cfile.py, feeding the RXA, RXB each with the same sinusoidal signal and when I plotted the output I found out that I was getting 0 values only. I then used again the std_4rx_0tx.rbf file which resulted in the expected output (sinusoidal signals at the same frequency) with amplitudes ranging from -15500 to 15500. . I then used another firmware which actually produces known data from within the rx_buffer.v file, (a signal that cycles from 0 to 15 and back to 0) and the output was as expected again, linear increase from 0 to 15 and then back to 0. I then tried other versions of the firmware that there were working, as Peter Monta's variable width and shift firmware, but again I was getting 0 values at this time. Does anyone has an idea what might be wrong? Why do I get nothing at the output when I use .rbf from the recompilation of the usrp_std project? Why some .rbfs work and some not? Thank you Rigas Ioannides _ Messenger Café — open for fun 24/7. Hot games, cool activities served daily. Visit now. http://cafemessenger.com?ocid=TXT_TAGLM_AugWLtagline___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Call for Papers: 5th Karlsruhe Workshop on Software Radios
Dear Colleague, we invite you to contribute to the 5th Karlsruhe Workshop on Software Radios - WSR08. The event will be held on March 5-6, 2008 in Karlsruhe, located in the southwest of Germany. This will be a great opportunity to bring the GNU Radio Community together. Topics include, but are not limited to, the following: - Antenna Techniques, - Baseband Data Processing, - Hardware/Software Co-Design, - Analog-to-Digital Conversion, - GNU Radio, - Cognitive Radio, - Dynamic Spectrum Access, - Cognitive Networks, - Pricing, Auctions, Game Theory and other Technical-economic Approaches - Applications of Cognitive Radio and Dynamic Spectrum Access Prospective authors are invited to submit one full page extended abstract. Important dates: Submission of extended abstracts: November 30th, 2007 Notification of acceptance:December 20th, 2007 Submission of camera-ready papers: January 31th, 2008 Workshop date: March 5-6th, 2008 For further details please visit our website: http://www.int.uni-karlsruhe.de We are looking forward to see you in Karlsruhe. Best regards, Friedrich Jondral, Christian Koerner and Hanns-Ulrich Dehner (Organizing Committee) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] building under OSX bootstrap does not work.
Heya there, i tried to install gnuradio now under osx and had built all dependencies incl libtool etc according to the tutorial using darwinports. Now when i go to checked out directory and run ./bootstrap thats what i get: ./bootstrap /opt/local/share/aclocal/audiofile.m4:12: warning: underquoted definition of AM_PATH_AUDIOFILE /opt/local/share/aclocal/audiofile.m4:12: run info '(automake) Extending aclocal' /opt/local/share/aclocal/audiofile.m4:12: or see http:// sources.redhat.com/automake/automake.html#Extending-acl ./bootstrap: line 28: libtoolize: command not found gr-qtgui/src/lib/Makefile.am:29: `%'-style pattern rules are a GNU make extension gr-qtgui/src/lib/Makefile.am:33: `%'-style pattern rules are a GNU make extension gr-qtgui/src/lib/Makefile.am:36: `%'-style pattern rules are a GNU make extension gr-trellis/doc/Makefile.am:51: `%'-style pattern rules are a GNU make extension configure.ac:84: required file `./ltmain.sh' not found What is weird is that libtoolize is nowhere on my system i am unsire if this should be part of the lobtool port but i got it installed. port installed libtool The following ports are currently installed: libtool @1.5.24_0 (active) and whats about that ltmain.sh? Hope this help and someone can help me. greetings max ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recovering x(t) from IQ samples
On Sat, 18 Aug 2007, Jeff Brower wrote: I don't know why programming the FPGA should look like a black hole. Verilog is straightforward, Matt's code is well structured and seems fairly well commented, there are tons of examples on Altera's website, etc. Sometimes I think people take "do everything in Linux software" to an extreme. There's a reason Altera, Xilinx, Texas Inst, sell more chips every year, even though Intel has tried for 15 years now to create a world without those guys. One of the great strengths of GNU Radio is that it opens the entire technology stack, from the FPGA all the way up to the GUI. You can optimize your application across the whole stack, putting each function where it makes the most sense. This contrasts with the usual approach where application developers are encouraged put everything in one layer. Verilog is no more difficult or mysterious than C++, wxPython, autotools etc. Jon Jacky ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] building under OSX bootstrap does not work.
Please review my install guide for OSX, in < http://www.nd.edu/ ~mdickens/GNURadio/ >; it addresses the issues you came across. To be short, 'libtoolize' isn't installed by MacPorts; 'glibtoolize' is, as is 'glibtool'. Apple has a 'libtool' application of its own ( /usr/bin/libtool ), that is -not- compatible with GNU's libtool; thus the renaming by MacPorts so-as to not (directly) break anything. You need to edit 'bootstrap' and change 'libtoolize' to 'glibtoolize'; the rest of the warnings can be ignored, though the "underquoted definition" can easily be corrected; again see the install guide near the end. Good luck! Let me know if this works. - MLD On Aug 20, 2007, at 11:11 AM, Max Moser wrote: What is weird is that libtoolize is nowhere on my system i am unsire if this should be part of the lobtool port but i got it installed. port installed libtool The following ports are currently installed: libtool @1.5.24_0 (active) and whats about that ltmain.sh? Hope this help and someone can help me. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Threaded c++ only USRP "cfile" dump
Recently I have been asking questions about overruns, threaded blocks,
and c++ only USRP reading. My application requires uninterrupted data,
which I was unable to get from the USRP with my laptop, even just
recording data to a file_sink. Attached is a program that records data
from the USRP. It is entirely in c++ and uses threads to prevent losing
data by writing to the hard drive while it reads from the USRP.
Thanks to Ian Larsen for a C++-only USRP example and to Greg Heckler for
the DBSRX c++ driver.
In addition to the attached, you also need db_dbs_rx.cpp and db_dbs_rx.h
from http://lists.gnu.org/archive/html/patch-gnuradio/2007-08/msg0.html
Compile with -lusrp and -lpthread
Chris
#include "db_dbs_rx.h"
#include
#include
#include
//#include
using namespace std;
#define NUMBUFFERS 16
#define NUMBYTES (4096*sizeof(short)*2/512*512)
void* Producer(void* Args);
void* Consumer(void* Args);
//-
//-
struct TSQueue
{
TSQueue();
~TSQueue();
char Buffers[NUMBUFFERS][NUMBYTES];
unsigned NumBytes[NUMBUFFERS];
unsigned Head, Tail;
bool Full;
bool Empty;
void Add(const char* in, unsigned n);
void Delete(char* out, unsigned& n);
pthread_mutex_t* pMutex;
pthread_cond_t* pNotFullCond;
pthread_cond_t* pNotEmptyCond;
};
//-
//-
TSQueue::TSQueue()
{
memset(NumBytes, 0, sizeof(NumBytes));
Empty = true;
Full = false;
Head = 0;
Tail = 0;
pMutex = new pthread_mutex_t;
pthread_mutex_init (pMutex, NULL);
pNotFullCond = new pthread_cond_t;
pthread_cond_init (pNotFullCond, NULL);
pNotEmptyCond = new pthread_cond_t;
pthread_cond_init (pNotEmptyCond, NULL);
}
//-
//-
TSQueue::~TSQueue()
{
pthread_mutex_destroy (pMutex);
delete pMutex;
pthread_cond_destroy (pNotFullCond);
delete pNotFullCond;
pthread_cond_destroy (pNotEmptyCond);
delete pNotEmptyCond;
}
//-
//-
void TSQueue::Add (const char* in, unsigned n)
{
if(Full)
{
pthread_cond_wait(pNotFullCond, pMutex);
}
NumBytes[Tail] = n;
memcpy(Buffers[Tail], in, n);
++Tail;
if (Tail == NUMBUFFERS) Tail = 0;
if (Tail == Head) Full = true;
Empty = false;
pthread_cond_signal(pNotEmptyCond);
}
//-
//-
void TSQueue::Delete(char *out, unsigned& n)
{
if(Empty)
{
pthread_cond_wait(pNotEmptyCond, pMutex);
}
n = NumBytes[Head];
memcpy(out, Buffers[Head], n);
++Head;
if (Head == NUMBUFFERS) Head = 0;
if (Head == Tail) Empty = true;
Full = false;
pthread_cond_signal(pNotFullCond);
}
//-
//-
struct TSProducerArg
{
TSQueue* pQueue;
usrp_standard_rx* pRx;
};
//-
//-
struct TSConsumerArg
{
TSQueue* pQueue;
ofstream* pStream;
};
//-
//-
void* Producer(void* q)
{
TSProducerArg* pArg = reinterpret_cast(q);
TSQueue *pQueue = pArg->pQueue;
usrp_standard_rx* rx = pArg->pRx;
rx->start();
while(true)
{
bool Overrun;
char Buffer[NUMBYTES];
int Size = rx->read(Buffer, NUMBYTES, &Overrun);
if(Size == -1)
{
cerr << "Problem" << endl;
}
else
{
if(Overrun)
{
cerr << "overrun" << endl;
}
pQueue->Add(Buffer, Size);
}
}
rx->stop();
return 0;
}
//-
//-
void* Consumer(void* q)
{
TSConsumerArg* pArg = reinterpret_cast(q);
TSQueue *pQueue = pArg->pQueue;
ofstream* pStream = pArg->pStream;
while(true)
{
unsigned n = 0;
char Buffer[NUMBYTES];
pQueue->Delete(Buffer, n);
pStream->write(Buffer, n);
}
return 0;
}
//-
//-
int main(int argc, char** argv)
{
if(a
[Discuss-gnuradio] Integrate Click Router and GnuRadio
Hello, Has anyone done this integration before? My first question is both Click and GnuRadio are in C++ so it would not be hard (in theory) to do so. But I haven't seen an example of calling GnuRadio APIs in C++. All of them so far are in Python. Is this true? - David Li ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Integrate Click Router and GnuRadio
A couple students did this for their master's thesis here two years back I think. Peter had e-mailed me their report, I'm hosting it for you: http://www.andrew.cmu.edu/user/gnychis/SDR-PRS-Final.pdf I have access to their thesis too, but they're just long drawn out versions of the short paper :) You may want to try contacting the student authors on the left before contacting Peter. If you can't get a hold of any of them let me know and I will ask Peter in my meeting with him this week about access to their work. https://www.cmu.edu/directory It's public information. - George Li, W David wrote: Hello, Has anyone done this integration before? My first question is both Click and GnuRadio are in C++ so it would not be hard (in theory) to do so. But I haven’t seen an example of calling GnuRadio APIs in C++. All of them so far are in Python. Is this true? - David Li ___ 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] Recovering x(t) from IQ samples
Jonathan Jacky wrote: Verilog is no more difficult or mysterious than C++, wxPython, autotools etc. Does it come with a debugger? I'd love to get into it, but things like learning how to debug/compile/etc are what scare me personally. Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recovering x(t) from IQ samples
On 8/20/07, Chris Stankevitz <[EMAIL PROTECTED]> wrote: > Does it come with a debugger? I'd love to get into it, but things like > learning how to debug/compile/etc are what scare me personally. Sure, check out Icarus Verilog and GTKWave. You basically write a testbench to stimulate your inputs, and make sure your outputs toggle the way they should. Or if you want to get into non-free software, check out ModelSim. Both Xilinx and Altera have bundled versions. With enough proper testing, you should be able to get a good 99% coverage on all statements and logic - which should be pretty darn good. Links: http://home.nc.rr.com/gtkwave/ http://www.icarus.com/eda/verilog/ http://www.model.com/ http://www.asic-world.com/verilog/art_testbench_writing1.html Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Integrate Click Router and GnuRadio
On Mon, Aug 20, 2007 at 04:27:40PM -0700, Li, W David wrote: > Hello, > > Has anyone done this integration before? My first question is both Click > and GnuRadio are in C++ so it would not be hard (in theory) to do so. > But I haven't seen an example of calling GnuRadio APIs in C++. All of > them so far are in Python. Is this true? > > - David Li Hi David, I suggest that you run Click and GNU Radio in separate processes and use, say, unix domain sockets to glue them together. Release 3.2 of GNU Radio will support all C++ usage. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Integrate Click Router and GnuRadio
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think Hydra at UT does this. - -Dan George Nychis wrote: > A couple students did this for their master's thesis here two years back > I think. Peter had e-mailed me their report, I'm hosting it for you: > http://www.andrew.cmu.edu/user/gnychis/SDR-PRS-Final.pdf > > I have access to their thesis too, but they're just long drawn out > versions of the short paper :) > > You may want to try contacting the student authors on the left before > contacting Peter. If you can't get a hold of any of them let me know > and I will ask Peter in my meeting with him this week about access to > their work. > > https://www.cmu.edu/directory > > It's public information. > > - George > > > Li, W David wrote: >> Hello, >> >> >> >> Has anyone done this integration before? My first question is both >> Click and GnuRadio are in C++ so it would not be hard (in theory) to >> do so. But I haven’t seen an example of calling GnuRadio APIs in C++. >> All of them so far are in Python. Is this true? >> >> >> - David Li >> >> >> >> >> >> >> ___ >> 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGyk5Oy9GYuuMoUJ4RAhQ5AKCMpSGtkNDuPai6zKjLb0PfPvWkuACfdLSA TxuESxLXtVTaRPF/3xvz/dY= =7MU3 -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem with 8-bit option and dropped samples
I'm testing the -8 option in various example programs, and haven't been successful in receiving valid data. The following test resulted in a very brief, flat line being displayed, then absolutely no data showed on the graph, but the program continued to run. ./usrp_fft.py -f 100M -d 4 -8 format = 0x288 set_format = True I decided to try decimating by 4 without specifying the 8-bit option, and I received the 'uO' indicating that samples were dropped from the USRP to host, but data was displayed on the graph, and it was 16MHz wide. What's going on? ./usrp_fft.py -f 92.7M -d 4 uOuOuOuOuOuOuOuOuOu I've also written a data capture script that simply writes data from the USRP to a file, and when I use the usrp.source_s () function (after using make_format, set_format) I get a few initial non-zero bytes, but the rest of the data file is zeroed out. Any idea what is happening here? I'm wondering if my signal is so weak, that the 8-bit option is truncating all the data off. When running usrp_wfm_rcv.py I can only get one strong FM radio station. Other questions are: Is the 'uO' the only indication that samples have been dropped? Does the number of 'uO's correspond to the number of samples dropped? What are the buffer sizes? Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with 8-bit option and dropped samples
Lisa Creer wrote: I decided to try decimating by 4 without specifying the 8-bit option, and I received the 'uO' indicating that samples were dropped from the USRP to host, but data was displayed on the graph, and it was 16MHz wide. What's going on? Lisa, I'm not sure from what angle you're wondering "what's going on" but let me say 1. No surprise that samples are being lost while you run usrp_fft.py. This is normal for me, especially while I am resizing the window. Presumably resources are devoted to running GUI tasks and the USRP bits get dropped. 2. No suprise that even though you are losing data, the FFT is still displayed. A valid FFT can be calculated even with missing samples. Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with 8-bit option and dropped samples
On Mon, Aug 20, 2007 at 11:15:36PM -0400, Lisa Creer wrote: > I'm testing the -8 option in various example programs, and haven't been > successful in receiving valid data. The following test resulted in a very > brief, flat line being displayed, then absolutely no data showed on the > graph, but the program continued to run. > > ./usrp_fft.py -f 100M -d 4 -8 > format = 0x288 > set_format = True Have you tried increasing the gain? What daughterboard are you using? Do you have an antenna connected? If so, what kind? > I decided to try decimating by 4 without specifying the 8-bit option, and I > received the 'uO' indicating that samples were dropped from the USRP to > host, but data was displayed on the graph, and it was 16MHz wide. What's > going on? > > ./usrp_fft.py -f 92.7M -d 4 > uOuOuOuOuOuOuOuOuOu 64 MS/s / 4 * 4 bytes/S = 64MB/s. This won't fit across the USB, hence the continuous overruns. > I've also written a data capture script that simply writes data from the > USRP to a file, and when I use the usrp.source_s () function (after using > make_format, set_format) I get a few initial non-zero bytes, but the rest of > the data file is zeroed out. Have you tried using the existing usrp_rx_cfile.py program? It's known to work. > Any idea what is happening here? I'm wondering if my signal is so weak, that > the 8-bit option is truncating all the data off. Could be. It currently takes the high 8 bits of the 16-bit value. [I thought that somebody had implemented the barrel shifter, but checking rx_buffer.v, I don't see it.] > When running usrp_wfm_rcv.py I can only get one strong FM radio station. Seems unlikely, unless you're living in the middle of nowhere... Have you tried: $ usrp_fft.py -f 95M -d 8 Should show lots of stations... > Other questions are: > > Is the 'uO' the only indication that samples have been dropped? Yes. > Does the number of 'uO's correspond to the number of samples dropped? No. Overrun detection is currently implemented by polling at approximately 10Hz. If you're trying to receive constantly streaming data, you shouldn't see any uO's. > What are the buffer sizes? They're configurable in the constructor to usrp.source_c. The default is generally reasonable. What OS and distribution are you running on? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions on US digital cable ...
Vijay, I would highly appreciate it if you can capture a few QAM-64 snapshots. I was able to successfully demodulate signals captured from a QAM modulator, but I don't have access to a real-world cable source. I guess the python script "usrp_rx_cfile.py" (in the examples directory) can be used to capture samples. We need at least 16 MHz sampling frequency for symbol timing recovery to work properly. My TVRX is on a UPS truck somewhere. As soon as it arrives, I'll give it a shot. Cheers, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
