On Mon, 16 Aug 2010, Jonas M. Börner wrote:
Hi all,
I am trying to use the convolutional encoder and Viterbi provided by the
gr-trellis class within another environment. I have my own mapper and de-mapper
blocks which I want to use. So I tried to use the feed the viterbi_combined
with this
Hi Colby,
thanks for your reply. My trellis is created like this:
t=trellis.fsm(1,2,[91,121])
The constraint length is 7 so it doesn't look like it was connected to a
trellis-specific thing. As I remember from the gr-trellis examples they didn't
do any truncating there before comparing the
On Tue, 17 Aug 2010, Jonas M. Börner wrote:
Hi Colby,
thanks for your reply. My trellis is created like this:
t=trellis.fsm(1,2,[91,121])
The constraint length is 7 so it doesn't look like it was connected to a
trellis-specific thing. As I remember from the gr-trellis examples they didn't
Thanks for the reply!
Any other suggestions? I'm trying to change the UCLA ZigBee PHY to do
spreading and
despreading using a table of 16 64-chip-sequences instead of the 16
32-chip sequences.
The files I have edited are listed below.
Now, as it is still not working, I'm looking for hints,
On Mon, Aug 16, 2010 at 01:18:25PM -0700, Eric Blossom wrote:
The bug is fixed in the master, maint and next git branches.
Also, there shouldn't be a need to specify the --with-boost-thread and
--with-boost-program-options options.
Thanks a lot, for me it still needs the configure line,
Hello,
My current application needs to work on ISM band, and there is an ISM band
filter on RFX900, how to remove or bypass the ISM band filter on the RFX900?
Thanks
Zhen
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://www.google.com/search?q=inurl%3Adiscuss-gnuradio+disable+ism+filter
The filter affects both TX and RX, but not the auxiliary RX path
(RX2). If you just want to receive, use the 2nd SMA port and make sure
to set that in the software. If you want to bypass the filter for
transmit, you will
On 08/16/2010 09:22 PM, Ian Holland wrote:
Please disregard my last. I must have got something wrong in my
testing. It now compiles, but it seems I need to use txrx_xcvr.bin
instead of txrx.bin with the latest git trunk. Please correct me if
this is wrong (note I have XCVR2450 as my
Hi All;
It seems that 52MHz /64MHz precision clock references are like hen's teeth,
so I'm working on a design.
What I need to know is what sort of level is the USRP1 looking for ? Is it
3.3V CMOS ?
Once I get the design working, I'll make them available at a reasonable
price J
thanks for the contribution Martin :)
I have some tools I could add to it myself. I think devtools was the
right thing to do. Hopefully several people will contribute other tools to
it. I will move it to the top of the Projects page.
On Mon, Aug 16, 2010 at 5:44 AM, Martin Braun
On Aug 17, 2010, at 2:24 PM, William Pretty Security Inc wrote:
It seems that 52MHz /64MHz precision clock references are like hen’s teeth,
so I’m working on a design.
What I need to know is what sort of level is the USRP1 looking for ? Is it
3.3V CMOS ?
Once I get the design working,
Hi,
I tought I'd share some experiences with running the usrp2 system
clock with something else than 100 MHz (so I can google it when I
forget).
Matt suggested that I could remove the 100 MHz oscillator and input my
own external clock instead. The VCTCXO was easy to remove, and I put a
1 Vpp
On Tue, Aug 17, 2010 at 11:56:20AM -0700, George Nychis wrote:
I have some tools I could add to it myself. I think devtools was the
right thing to do. Hopefully several people will contribute other tools to
it. I will move it to the top of the Projects page.
Another interesting thing in
On 08/17/2010 02:01 AM, Vincent W wrote:
As evidence for the other kind of spikes, the ones that follow you around,
please see the attached pictures, centered around frequencies of 1134 and
1135MHz. These are the spikes that follow the centre frequency around.
The problem around 100MHz is
More Info on the parts I plan to use:
At this point I have two possible fixed frequency parts:
Silicon Labs Si590 series:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detailname=590PC-BDG-
ND name=590PC-BDG-ND
Pletronics
On Tue, Aug 17, 2010 at 3:10 PM, Mark J. Blair n...@nf6x.net wrote:
On Aug 17, 2010, at 2:24 PM, William Pretty Security Inc wrote:
It seems that 52MHz /64MHz precision clock references are like hen’s teeth,
so I’m working on a design.
What I need to know is what sort of level is the USRP1
On Aug 17, 2010, at 2:24 PM, Gregory Maxwell wrote:
I'd also like to echo the 10MHz comment. GPSDOs Clocks with excellent
long term stability show up at fairly low prices on ebay all the time
(excess from cell site deployments, I assume). I have a couple of
them. What they don't usually
On Aug 17, 2010, at 5:07 PM, William Pretty Security Inc wrote:
More Info on the parts I plan to use:
At this point I have two possible fixed frequency parts:
Silicon Labs Si590 series:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detailname=590PC-BDG-ND
Pletronics OHM4 Series:
Hi Matt
Thanks so much for your help. I tried your latest suggestion, and this gets my
frequency offset between Tx and Rx down to a mere 1 Hz. This is much better and
should make my testing considerably simpler.
Cheers
Ian.
-Original Message-
From: Matt Ettus [mailto:m...@ettus.com]
Gregory Maxwell wrote:
On Tue, Aug 17, 2010 at 3:10 PM, Mark J. Blair n...@nf6x.net wrote:
On Aug 17, 2010, at 2:24 PM, William Pretty Security Inc wrote:
It seems that 52MHz /64MHz precision clock references are like hen’s teeth, so
I’m working on a design.
What I need to know is
20 matches
Mail list logo