[Discuss-gnuradio] *much* faster filtering --- plus vhf mountaintopping
First, that IS great news about the ccf filter code. Last Sundays trip to the mountaintop with a view of several states was interesting, altho too short. An 8Mhz wide plot of the FM band centered at 100Mhz is shown here: http://webpages.charter.net/cswiger/fm_mountain_top.jpg using a Radio Shack mag mount scanner antenna. For that pic, usrp decimation was 8, but thats too much data for the notebook disk drive, way too choppy. Using 16 was much better (altho you only get 4Mhz bw) but still enough dropped blocks to be annoying (like losing the brief station IDs). Using 16 I can get the entire FM bcb in 6 segments, for about 3 or 4 minutes each before filling up 20Gb free space. Still it's nice to collect field data for later slicing and dicing in the basement. Looking for faster/bigger portable storage. The Adaptec SlimSCSI 1480 card will only do 20MB/sec. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] *much* faster filtering --- plus vhf mountaintopping
On Wed, 11 May 2005 21:43, Chuck Swiger wrote: > for about 3 or 4 minutes each before filling up 20Gb free space. Still it's > nice to collect > field data for later slicing and dicing in the basement. > > Looking for faster/bigger portable storage. The Adaptec SlimSCSI 1480 card > will only do > 20MB/sec. If you can power a mains appliance (car inverter?) you could use an external firewire drive. I doubt you could run a USB enclosure and the USRP without running out of USB bandwidth but firewire should be OK. The enclosures I've used (Mapower) can keep up with WDJB drives which do around 30-50Mbyte/sec. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp7LYNKfyjFY.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] *much* faster filtering --- plus vhf mountaintopping
I have successfully used an external USB 2 drive along with the usrp, no problems. And that's with a USB hub with USB2 drive as well as a GPS attached and spewing data. There's a trick, though compression. You can make a fifo, ask gnuradio to write to it, and zip it. In one window, make the fifo and start it: #> mkfifo testfifo #> cat testfifo | gzip -c > data.gz In another, start up the capture, something like this: #> usrp_rx_file.py -o testfifo THE reverse step is to unzip,, like this (for example, with the wfm script): #> wfm_rcv_file.py testfifo In the other window, do: #> gzip -dcf data.gz > testfifo Seems to work barely on my laptop, which is a 1.6 GHz pentium M machine HOWEVER, to aid things along even more, I did the captures without using X-windows (you don't need it if your not using any guis). You can switch consoles in linux with ctl-alt-Fx, where F7 is where your x-windows is running. I switched to a console, killed X, used one console for the usrp, the other for the piping and zipping. How well did it work? I did a sweep of the entire front-end's range, about 40 minutes of sampling incrementing by 400kHz about every second from 50 Mhz to 860 MHz... this gave me a zipped file roughly 600MB. For usrp source, complex samples, decim 8 (therefore, rate= 8Mbits/sec), this worked out well. By the way, Chuck, I think that if you're using a TVRX board, the downconverter 4937 has a 6 MHz bandwidth... so even though you captured at 8Mhz, don't you only have just 6 of useable data? -jamie Daniel O'Connor wrote: On Wed, 11 May 2005 21:43, Chuck Swiger wrote: for about 3 or 4 minutes each before filling up 20Gb free space. Still it's nice to collect field data for later slicing and dicing in the basement. Looking for faster/bigger portable storage. The Adaptec SlimSCSI 1480 card will only do 20MB/sec. If you can power a mains appliance (car inverter?) you could use an external firewire drive. I doubt you could run a USB enclosure and the USRP without running out of USB bandwidth but firewire should be OK. The enclosures I've used (Mapower) can keep up with WDJB drives which do around 30-50Mbyte/sec. ___ 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] *much* faster filtering --- plus vhf mountaintopping
Daniel & James (et al) - Firewire or USB drive looks the way to go, with compression in the stream (Tks James). I've found a world of 12vdc input ATX power supplies are available, like: http://www.orbitmicro.com/products/power%20supplies/dc-dc/ps2/KPDX250H.htm might run a small server mobo with big SCSI disk. --Chuck On Wed, 11 May 2005, Daniel O'Connor wrote: > > If you can power a mains appliance (car inverter?) you could use an external > firewire drive. > > I doubt you could run a USB enclosure and the USRP without running out of USB > bandwidth but firewire should be OK. > > The enclosures I've used (Mapower) can keep up with WDJB drives which do > around 30-50Mbyte/sec. > > -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] *much* faster filtering --- plus vhf mountaintopping
All, I've got a Targus 150W APV07US Slimline inverter and a Buslink external usb enclosure... works great. Only things are that the Targus lets out this ear-splitting beep for some unknown reason when it starts up Also, my car's a bit flaky in that it shuts off the cigarette lighter power at inconvenient times!! Another tip for all of you: Use a more ROBUST file system on the external drive. I lost a day's worth of data because I used FAT32 on the external drive and had the power shut off as stuff was being written. The FAT filesystems are notoriously lousy. I now use ext3. Do mount and umount it cleanly, but if you should lose power accidentally, you are more likely to be ok. The drawback is that you can't really use it under windows. Try out the compression before you go all the way to a mountain top, though. :) I can't swear that my laptop isn't dropping data... I don't *think* it is (I'm packing extra header data ahead of each sample block and things really wouldn't work if the number of complex samples were messed up), but you never know. If gzip can't read from the fifo quick enough, data will just be dropped. Any improvements, better compression schemes would be welcome! I'm sure there's a way to come up with a compression scheme that's tailored to the sort of sample data we see... -j cswiger wrote: Daniel & James (et al) - Firewire or USB drive looks the way to go, with compression in the stream (Tks James). I've found a world of 12vdc input ATX power supplies are available, like: http://www.orbitmicro.com/products/power%20supplies/dc-dc/ps2/KPDX250H.htm might run a small server mobo with big SCSI disk. --Chuck On Wed, 11 May 2005, Daniel O'Connor wrote: If you can power a mains appliance (car inverter?) you could use an external firewire drive. I doubt you could run a USB enclosure and the USRP without running out of USB bandwidth but firewire should be OK. The enclosures I've used (Mapower) can keep up with WDJB drives which do around 30-50Mbyte/sec. -- ___ 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] *much* faster filtering --- plus vhf mountaintopping
James Cooley wrote: ...I'm sure there's a way to come up with a compression scheme that's tailored to the sort of sample data we see... A topic for a dissertation if ever there was one :-) In the general case, you're going to have to work hard to beat Ziv-Lempel. You might improve the performance somewhat by tweaking the parameters, but probably not a lot. The problem is that, as we know, in the general case, compressibility is basically the reciprocal of entropy. Ziv-Lempel depends on conditional entropy being lower, and thus compressibility being higher, through markovity. For most human-generated signals, the influence of the past (the markovity) decays exponentially towards the past. For general signals, the decay is very rapid, so there's going to be a lot of slop at the boundaries of the underlying markov model. There's also a theorem in there somewhere (due to Rissanen, I think) that says there's a limit on how much slop you can trim by tuning the adaptation. Where you might win is by picking different compression algorithms depending on the signals. For example, for voice-bandwidth channels, you might gain a lot from first converting to mu-law and then gzipping. And so on. For wide, densely-packed signals, you can probably forget it. The fact that they're densely packed means they're already high-entropy. Regards Frank ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RF Analysis
Hi I was wondering if any of you guys had links or pointers to general good quality RF analysis and logging software? Ideally it would be compatible with the likes of the gnu radio hardware, but could also be interfaced to drive an agilent spectrum analyser or similar Any tips or thought welcome Many thanks Mochara ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] RF Analysis
If you have a GPIB card, you can use a simple program like this to log data
points in a range of spectrum. This was for an HP spectrum analyzer, but if
you're using visa it shouldn't matter.
// SpectrumSurvey.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include
#include
#include
#include
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
ofstream OutputFile("spectrum.dat", ios::out);
if (!OutputFile)
{
cerr<<"File could not be opened"< -Original Message-
> From: [EMAIL PROTECTED] [mailto:discuss-
> [EMAIL PROTECTED] On Behalf Of SIGINT Admin
> Sent: Wednesday, May 11, 2005 9:03 AM
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] RF Analysis
>
> Hi
>
> I was wondering if any of you guys had links or pointers to general
> good quality RF analysis and logging software?
>
> Ideally it would be compatible with the likes of the gnu radio
> hardware, but could also be interfaced to drive an agilent spectrum
> analyser or similar
>
> Any tips or thought welcome
>
> Many thanks
>
> Mochara
>
>
> ___
> 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] RF Analysis
I suspect the original poster was looking for something a little more
sophisticated, but since Richard mentioned using a c program an visa,
I'll mention the linux-gpib project which provides drivers and a
more-or-less NI compatible library to talk to GPIB cards from several
vendors. I've written several programs in Perl to talk to older (ie,
sort-of-hobbyist-affordable) HP gear like spectrum analyzers and
frequency counters. They're on my website under
http://www.febo.com/geekworks, but are sort of scattered around and hard
to find. Contact me offline for more details if you're interested.
John
Richard Cagley wrote:
If you have a GPIB card, you can use a simple program like this to log data
points in a range of spectrum. This was for an HP spectrum analyzer, but if
you're using visa it shouldn't matter.
// SpectrumSurvey.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include
#include
#include
#include
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
ofstream OutputFile("spectrum.dat", ios::out);
if (!OutputFile)
{
cerr<<"File could not be opened"<
ViSession defaultRM, vi;
char buf [256] = {0};
char buf2 [256] = {0};
// set the parameters for measurement: in kHz
int StartFreq = 21;
int StopFreq = 24;
int StepFreq = 25;
int NumberRuns = 1;
// write out the frequencies in the header
int CurrentFreq = StartFreq;
while (CurrentFreq < StopFreq)
{
OutputFile<
// Open session to GPIB device at address 18
viOpenDefaultRM (&defaultRM);
viOpen (defaultRM, "GPIB5::18::INSTR", VI_NULL,VI_NULL, &vi);
viPrintf (vi, "ID?\n");
viScanf (vi, "%t", &buf);
printf ("Instrument identification string: %s\n", buf);
double ChannelPower;
// main loop to do measurements
for (int n = 0; n < NumberRuns; ++n)
{
CurrentFreq = StartFreq;
while (CurrentFreq < StopFreq)
{
viPrintf( vi,"IP;SNGLS\n");
viPrintf(vi, "FA %dMHZ\n", CurrentFreq);
viPrintf(vi, "FB %dMHZ\n", CurrentFreq+StepFreq);
viPrintf(vi, "CHP\n");
Sleep(1000*10);
viPrintf(vi, "*CHPWR?\n");
viScanf(vi,"%lf",&ChannelPower);
OutputFile<
viClose (vi);
viClose (defaultRM);
return 0;
}
-Original Message-
From: [EMAIL PROTECTED] [mailto:discuss-
[EMAIL PROTECTED] On Behalf Of SIGINT Admin
Sent: Wednesday, May 11, 2005 9:03 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] RF Analysis
Hi
I was wondering if any of you guys had links or pointers to general
good quality RF analysis and logging software?
Ideally it would be compatible with the likes of the gnu radio
hardware, but could also be interfaced to drive an agilent spectrum
analyser or similar
Any tips or thought welcome
Many thanks
Mochara
___
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
[Discuss-gnuradio] Okay, issue with tvrx_* resolved
tvrx_debug and tvrx_wfm_rcv_gui were written to call usrp.source_c with an argument for the mux in the form 0xf0f0f0fA where A = 0 or 2 depending on where the tvrx is located. usrp.source_c seems to have been modified to drop the requirement for the 0xf0f0f0f part. I have tvrx on both RX A and RX B. I modified the code to call to usrp.source_c with 0 if which_size was 0 and 2 if which_side was 1. I am listening to 97.5 FM now with this working. Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SIGBUS on test_runtime and test_vmcircbuf
Hi, I am starting to use gnuradio and I was trying to get everything working. I downloaded from CVS bootstrapped, configured and made. But when I try to do a make check I get a SIGBUS on test_runtime and test_vmcircbuf. What might that be? I am using Fedora Core 3. Thanks, Romano ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] *much* faster filtering --- plus vhf mountaintopping
> Looking for faster/bigger portable storage. The Adaptec SlimSCSI 1480 > card will only do > 20MB/sec. For what you are doing, my suggestion would be to store 8 bit signed samples instead of floats or 16-bit shorts. You'll need a block to convert from 16 bits (gr.usrp_source_s) to bytes. You could also do a software agc on it to make sure you make the most of the 8 bit resolution. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] scopesink / fftsink fixes
Thanks to the troubleshooting efforts of Jon Jacky, we've now got scope and fft sinks that work reliably on OS/X. [There was a problem with os.read returning a short read count.] I've also added a gr.throttle(itemsize, sample_rate) block that limits the average sample rate through the block to sample_rate samples/sec. This can come in handy where there is no i/o device limiting the CPU consumption of GNU Radio. I've added this block to the scopesink and fftsink demos so they are now *much* more responsive. To get this stuff you'll need to update and build gnuradio-core and gr-wxgui from CVS. [I've noticed a dependency problem with swig .i files. Work around: After updating gnuradio-core, cd gnuradio-core/src/lib/swig, make clean, then build as usual.] Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: RF Analysis
Hi John Thanks for the tip, but as you guessed, I am looking for something a little more professional and turnkey so to speak. The system alone, would need to handle and log over 24hours of spectrum traces for analysis and comparison etc. If anyone has any further ideas I'd sure appreciate them. Kind regards Mochara > > -- > > Message: 6 > Date: Wed, 11 May 2005 13:24:35 -0400 > From: John Ackermann N8UR <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] RF Analysis > To: Richard Cagley <[EMAIL PROTECTED]> > Cc: discuss-gnuradio@gnu.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I suspect the original poster was looking for something a little more > sophisticated, but since Richard mentioned using a c program an visa, > I'll mention the linux-gpib project which provides drivers and a > more-or-less NI compatible library to talk to GPIB cards from several > vendors. I've written several programs in Perl to talk to older (ie, > sort-of-hobbyist-affordable) HP gear like spectrum analyzers and > frequency counters. They're on my website under > http://www.febo.com/geekworks, but are sort of scattered around and hard > to find. Contact me offline for more details if you're interested. > > John > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] *much* faster filtering --- plus vhf mountaintopping
On Thu, 12 May 2005 01:08, cswiger wrote: > Daniel & James (et al) - Firewire or USB drive looks the way to go, > with compression in the stream (Tks James). I've found a world of > 12vdc input ATX power supplies are available, like: > > http://www.orbitmicro.com/products/power%20supplies/dc-dc/ps2/KPDX250H.htm > > might run a small server mobo with big SCSI disk. Not sure "big" and "SCSI" go in the same sentence :) Modern IDE drives to very well at sequential read/writes so they should be very good for this application IMO. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp0tX1WCVkoG.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] *much* faster filtering --- plus vhf mountaintopping
On Wed, 11 May 2005 23:49, James Cooley wrote: > In the other window, do: > #> gzip -dcf data.gz > testfifo > > > > Seems to work barely on my laptop, which is a 1.6 GHz pentium M > machine HOWEVER, to aid things along even more, I did the captures > without using X-windows (you don't need it if your not using any guis). > You can switch consoles in linux with ctl-alt-Fx, where F7 is where your > x-windows is running. I switched to a console, killed X, used one > console for the usrp, the other for the piping and zipping. > > How well did it work? I did a sweep of the entire front-end's range, > about 40 minutes of sampling incrementing by 400kHz about every second > from 50 Mhz to 860 MHz... this gave me a zipped file roughly 600MB. It would be interesting to see how well say, FLAC or Shorten work at compressing this stuff. When I did some tests with our radar systems Shorten worked very well, but I suspect FLAC would have worked better if it could have been configured for the right number of channels (ie 300). -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpwM0N4kxfov.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] "When T.V. Watches You"
http://www.defensetech.org/archives/001545.html -- Krzysztof Kamieniecki callsign:KB1KLB mailto:[EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
