s geared toward high-spectral-efficiency signals
with many (>=8) bits per sample.
Cheers,
Peter Monta
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi Nan,
1. For TVRX board, as we know, the output signal is a 6MHz chuck. But
in which band is this 6MHz bandwidth located? For example, if the
carrier frequency is 477.25MHz, is the output signal from
477.25-1.5MHz to 477.25+4.5MHz, or from 477.25-3MHz to 477.25+3MHz, or
in other band?
F
From my knowledge all the semi-codeless tracking algorithms are
heavily patented, and hence cannot be found in textbooks or in any
open forum.
But the patents themselves contain pretty good descriptions of the
techniques;
also there is this paper:
http://www.navcomtech.com/Support/Downlo
I can verify that there is NO DATA on any of the L2C capable SVs.
Ah. I'd thought from the ICD that the only valid options were legacy
data or
new data. While I understand that this is all pre-operational, it would be
nice to have some rough guidelines from the GPS people about what to
ex
On the chance that there are GPS folks here that are
familiar with the status of the new L2C signals: is there
a currently-maintained list of which satellite is emitting
what? In particular, PRN 29 seems to have no L2C (or
at least none that I can acquire), while PRN 31 has a nice
strong carrier
probability)?
One thing you could try, if the channel permits, is to temporarily hold
the AGC
fixed to see if that gives a better constellation (perhaps at the wrong
size;
or if you're using decision feedback, try to get it to the right size :-) ).
Cheers,
Peter
from sudden jumps over temperature, but this
doesn't match your experience, since the TCXO is on the motherboard
and would affect both dbsrx's equally.
Cheers,
Peter Monta
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.
> [ I/Q compensation ]
There's some discussion in Razavi's "RF Microelectronics", section 5.2.2,
and Kenington's "Software Defined Radio", section 5.3.1.1. The distinction
you mention between DC and AC might come from this LO self-mixing
business, a nonlinear effect, and indeed only at DC since
For example, if I have a 6 MHz bandwidth that I direct convert to
baseband can I tune a narrow band DDC (say 30 kHz) around that
bandwidth without the performance degradation?
If you tune the DDC to, say, +500 kHz, then the output of the DDC will be
contaminated with a small amount of signal
Has anyone experimented with the digital compensation of the I/Q
imbalance from direct conversion asics like the one in the dbsrx? I'm
interested in the algorithms employed and how successful the
compensation can be.
It depends on how detailed a model you're willing to
implement and the st
e FFT demos, since currently there is no "video
filtering", as the spectrum analyzer folks say.
A more flexible spectral estimate would allow showing
nice clean noise floors at the expense of a little
measurement time.
Cheers,
Peter Monta
figure. There's also an
amplifier on the dbs_rx prior to the receiver chip, so the system
noise figure of the USRP itself should not be a problem.
Did you see my other email from April 4? I think it went out
to the list.
Cheers,
Peter
e acquisition step (say +- 50 kHz),
consistent with the 50ppm absolute accuracy of the USRP's LO.
Cheers,
Peter Monta
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
e tripler would just be a filter).
Cheers,
Peter Monta
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
input (after the saw
filter)
This will result in 24.58 Mhz +jitter +LOdrift at the input of the USRP (after
dbs_rx downmix)
I wonder if any 25th harmonic is already in the signal, by virtue
of leakage within the USRP itself? That would be great.
Cheers,
Peter Monta
would like). Thanks!
I could take a look if you like---two seconds perhaps?
Cheers,
Peter Monta
n = length(e);
r = 0;
phase = 0;
freq = 0;
data = zeros(1,n);
for i=1:n,
pd = exp((1j)*phase) * e(i); # phase detector
data(i) = real(pd); # save data (in-phase arm
Eric Blossom wrote:
The "short" version doesn't touch the data. You'll be able to unpack
it youself.
Strange, I had some problem with rx_cfile not seeming to respect
the width parameter. I'll try it again.
That determines the minimum decimation rate required upstream
from the halfband (4
Please let me know if anything else is needed for the patch.
There's a testbench for bit_pack.v I can send along if you like.
One possible issue is synchronization, to make sure that the
channels are properly distributed within the 16 bits after
changing width.
Cheers,
Peter Monta
//
ted).
Cheers,
Peter Monta
--- rx_buffer.v.orig2007-02-25 14:32:58.0 -0800
+++ rx_buffer.v 2007-03-01 02:57:00.0 -0800
@@ -51,8 +51,7 @@
output [15:0] debugbus
);
- wire [15:0] fifodata, fifodata_8;
- reg [15:0] fifodata_16;
+ reg [15:0] fifodata;
wire [1
ful, actually---if I request 4-bit
samples, I'm more or less expecting 4-bit uniform quantization,
right? So the attached patch changes to round-to-nearest-even.
Cheers,
Peter Monta
--- rx_buffer.v.orig2007-02-25 14:32:58.0 -0800
+++ rx_buffer.v 2007-03-01 00:01:05.0
20 matches
Mail list logo
