Friends -
On Fri, Jul 12, 2024 at 10:09:18PM -0400, Marcus D. Leech wrote:
> On 12/07/2024 16:42, Walter Szeliga wrote:
> > I have a GNSS Firehose
> > https://transitiva.com/product/gnss-firehose-receiver-tri-band-quad-constellation/
> Are these things actually in production? What kind of price
Cinaed -
On Wed, Dec 28, 2022 at 06:31:17PM -0800, Cinaed Simson wrote:
> Hi Larry - try
> apt install libsndfile1-dev
Yes, I confirm that is the solution. Thanks!
Although it's more practical to
apt-get install --no-install-recommends libsndfile1-dev
to keep xtrx-dkms out of it. Both
gnuradio gurus -
I just hit a problem with symptoms that precisely match
https://lists.gnu.org/archive/html/discuss-gnuradio/2020-09/msg00055.html
This is while attempting to build gr-osmosdr, basically the first
real step in the instructions at
John et al. -
On Fri, Jan 06, 2006 at 08:36:08PM -0500, John Ackermann N8UR wrote:
BTW -- one of the challenges with Debian is that the automake version
that's installed by default is 1.4. I don't know why they continue to
include such an ancient version. You need to uninstall 1.4 and
Guys -
On Sun, Dec 18, 2005 at 04:14:56PM -0800, Larry Doolittle wrote:
I think Debian went this way for a while, but for the moment
the 32-bit mode is relegated to emulation status: 64-bit
libraries go in $prefix/lib, and 32-bit libraries go in
$prefix/emu/ia32-linux/usr/lib. [chop
Bob -
On Sat, Oct 01, 2005 at 02:56:26PM +, Robert McGwier wrote:
The paper you included and the mathematical and electrical phenomenon
you are talking about applies to the analog to digital converter, the
receiver only. [chop]
You cannot do the reverse on transmit. It is a one to
Kalen and lurkers -
On Tue, Sep 27, 2005 at 04:22:18PM +0200, Kalen Watermeyer wrote:
I'm trying to re-use the USRP code (where I can) for my own SDR device
which also uses the FX2 chip. I've managed to install the GnuRadio onto
my Debian system and have built the USRP source code.
I do
On Mon, Sep 12, 2005 at 08:33:09PM -0700, Eric Blossom wrote:
On Thu, Sep 08, 2005 at 11:04:33AM -0700, Larry Doolittle wrote:
The libusb folks maintain a libusb/linux.h that parallels
the kernel-space linux/usbdevice_fs.h, but is designed to
be used by user-space programs. So I grabbed
On Tue, Sep 13, 2005 at 09:47:45AM -0700, Larry Doolittle wrote:
In Debian's case, /usr/include/linux/* comes not from the kernel,
but from the linux-kernel-headers package. [chop]
Ask yourself, why did the libusb decide to make and use their
own version of this include file?
Here
On Tue, Sep 13, 2005 at 09:47:45AM -0700, Larry Doolittle wrote:
This category of problems including Linux kernel headers is not new.
Several are tracked as Debian bugs to the linux-kernel-headers
package, [chop]
Our particular problem might be AMD64 specific, as reported in
http
It works for me
--- /home/ldoolitt/cvs/usrp/host/apps/test_usrp_standard_rx.cc 2005-09-08
08:34:57.0 -0700
+++ test_usrp_standard_rx.cc2005-09-09 09:23:35.0 -0700
@@ -38,7 +38,7 @@
char *prog_name;
-static bool test_input (usrp_standard_rx *urx, bool forever_p, FILE
Something about debian sid broke compilation of fusb_linux.cc
badly. My guess is that something subtle but important changed
about the kernel/user header boundary. The first error is the
funniest and easiest to bypass:
error: #error do_div() does not yet support the C64
but it gets into much
I asked -
Something about debian sid broke compilation of fusb_linux.cc
badly. My guess is that something subtle but important changed
about the kernel/user header boundary. [chop]
I'm researching the problem now, but would appreciate any hints
from people who have already seen this. It
On Fri, Jul 22, 2005 at 05:11:35PM -0700, Eric Blossom wrote:
On Sat, Jul 23, 2005 at 04:35:05AM +0500, Ahmad Sheikh wrote:
But using usrp.source_c().set_pga() means that the feedback control
be on the python level, which would mean that there would be a large
latency in the gain control.
On the other side of what Harald Welte wrote
While Gigabit Ethernet is certainly a ubiquitous and cheap interface, I
wouldn't recommend it's use for USPR or alike devices.
[the linux network stack] is not intended for an application which just
wants to get big data streams with low latency and
John -
[chop], there
will be three or four signals, on different frequency bands (near 3.58,
7.08, 14.08, and 21.08 MHz). The signal will be an unmodulated carrier
(well, there will be some CW identification) and will be transmitted for
about 10-15 minutes.
It seems to me that with
Hi, everyone!
My adaptation of USRP code for a conceptually related (rx-only)
project has gone pretty well. I get a reliable 33 MB/s sustained
data transfer from the FPGA to the host (same results on an AMD64
desktop and Intel Centrino laptop). The hardware platform is an
Avnet Virtex-4 Eval
Tim -
On Mon, May 02, 2005 at 01:46:48PM +0930, Tim Ansell wrote:
So where do we request free samples from :P
Good question. I'd be happy with a data sheet, for the moment.
I'm in the low-latency business, so this chip _may_ be useless to me.
The question is how would you get this into a
Guys -
I took a first stab at an FX2 WaveData compiler, since I don't touch
Microsoft-only software (GPIFTool) with a 3.048 meter pole. This attempt
is good enough to recreate the WaveData definition in usrp1_gpif.c from
the following source code:
-- cut here --
// GPIF Ctrl Outputs
CTL 0=
On April 6, I posted:
It looks like my code is in there, attempting
to read the JTAG ID chain, and getting all 1's. Not
the right answer, of course, but I'm on my way.
I don't promise that anyone outside my project cares, but I
now have a good start making an Avnet V4LX evaluation board
20 matches
Mail list logo
