I'm trying to build gnu radio with control port, but cmake won't find
my Ice installation. I have Ice-3.4 installed through apt on Ubuntu
13.10. Digging in to the FindIce.cmake I made the following changes:
diff --git a/cmake/Modules/FindICE.cmake b/cmake/Modules/FindICE.cmake
index 087ee9b..705c0
Hi everyone,
on behalf of the IEEE student branch Karlsruhe[1], I'm happy to present
the 1st IEEE Signal Intelligence Challenge (ISIC).
Briefly, it's a challenge to find, decode and decrypt 10 signals in a
given chunk of spectrum. Eligible are teams of up to 8 students (you
need to be enrolled, b
Yes I did, with channel model like that:
Noise voltage = 200m
frequency offset=50m
epsilon=900m
taps=1
seed=0
And I can receive data.
--
View this message in context:
http://gnuradio.4.n7.nabble.com/On-air-16-QAM-transmission-problem-with-USRP-N210-tp47871p47903.html
Sent from the GnuRadio mai
On Wed, Apr 30, 2014 at 12:04 PM, zielalaoui wrote:
> Hi Tom,
> Yes i've already done the simulation with 16 QAM and even 64 QAM by
> following your example for MPSK. The simulation was very good even I add
> noise in the channel model. I had only problem of power, if the
> transmitting
> power i
Oops. I forgot part of it:
def advance(lfsr, num):
for i in range(num):
nextbit = (lfsr & 1) ^ ((lfsr >> 5) & 1)
lfsr >>= 1
lfsr |= (nextbit << 8)
return lfsr
On Wed, Apr 30, 2014 at 10:38:54AM -0600, Michael Ossmann wrote:
>
> Coo
Of course - I forgot whitening as a nother parameter to be tried. Thanks!
-John
On Wed, Apr 30, 2014 at 9:38 AM, Michael Ossmann wrote:
> Cool! In case either of you doesn't have this yet, here is an
> implementation of the CC11xx whitening algorithm:
>
> # XOR the output of this with a pack
Cool! In case either of you doesn't have this yet, here is an
implementation of the CC11xx whitening algorithm:
# XOR the output of this with a packet
def whitening(length):
lfsr = 0x1ff
white = 0
for i in range(length):
white <<= 8
white |=
Jay,
As it turns out I am working on an out-of-tree module to work with the
CC1101, which I think I'll be able to release. The number of possible
formats for the frame are relatively few if you know they are using CRC and
you know the packets aren't fixed length. (use_sequence_number?,
use_addres
Hi Tom,
Yes i've already done the simulation with 16 QAM and even 64 QAM by
following your example for MPSK. The simulation was very good even I add
noise in the channel model. I had only problem of power, if the transmitting
power is high enough the transmission is perfect with no errors. On air,
My workflow in this case is to dump the output of Correlate Access Code
to a file and then write small Python programs to read that file. Yes,
the tools within GNU Radio for handling this kind of thing are getting
better, but they still haven't been as useful (to me) as a few lines of
Python here
On Wed, Apr 30, 2014 at 10:58 AM, zielalaoui wrote:
> Hi all,
> For synchronization I did not add blocks because the QAM.py calls
> synchronization blocks from generic_mod file which already contains AGC,
> fll, polyphase clock synk, ... I thought that those bolcks are doing the
> job. So i just
Maybe I should rephrase: I don't know the entire protocol. I know there is
a preamble, and I know the sync word. I know the packets are not fixed
length, I know there is a CRC. This can all be determined from looking at
the register settings for the CC1101 chip. The format of the data portion
of
Sorry, my fault - I altered the FDE so it *does* give soft outputs, because the
constellation decoder makes hard decisions anyway - so I didn't see the need
for it to be done twice.
I forgot i'd made changes :s But now maybe I understand why people haven't seen
this issue - because they have ne
Jay,
If you stream the output of the correlate access code to file, and you
leave them unpacked, Bit 1 being set will show where the sync word is (I
think the bit after). Of course Bit 0 will be the data. This assumes
you're using correlate access code, and not "correlate access code - tag".
Thi
On 30.04.2014 16:03, David Halls wrote:
It's just the built in basic FDE. Its not awesome, but works well enough
at high SNR.
Hm, the FDE doesn't output soft info, so I'm stumped why you'd see
anything other than clean constellation points in the first place.
Yes, when I send multiple packe
Hi all,
For synchronization I did not add blocks because the QAM.py calls
synchronization blocks from generic_mod file which already contains AGC,
fll, polyphase clock synk, ... I thought that those bolcks are doing the
job. So i just think to add FEC block because it is not a part of my
flow-graph
On Wed, Apr 30, 2014 at 3:22 AM, Martin Braun wrote:
> On 29.04.2014 23:22, zielalaoui wrote:
>
>> Hi all,
>> I am trying to build transmission on air by using USRPs N210. The
>> transmission is good with MPSK modulations but when i try to use 16_QAM i
>> could not receive data (0 bytes at the rec
I guess I'm confused then. I'm using the hex FIFO dump as I described to
examine AX.25 packets one bit at a time. Since the output of the slicer is
a byte whose LSB is the only thing you are interested in, I believe you can
use the unpacked-to-packed block to strip off the LSB from 8 bytes and pa
Hi Martin,
Setting the rolloff factor in the cyclic prefixer to CP_len (16 samples) fixes
the problem?! Previously I had rolloff = 0.
Any thoughts?
DH
From: Martin Braun [martin.br...@ettus.com]
Sent: 30 April 2014 14:56
To: David Halls; discuss-gnuradio
Hi Marcus!
>> get_time_now is a public function of usrp_sink, it is accessible from
>> everywhere :)
Great, I thought it was a public function, just wasn't sure how to get a
pointer to it.
>> uhd::time_spec_t now = my_usrp_sink->get_time_now();
Sure thing.
>> You'll need a (shared) pointer t
Hi,
It's just the built in basic FDE. Its not awesome, but works well enough at
high SNR.
Yes, when I send multiple packets, its only the last OFDM symbol of the last
packet that is affected.
I have tried suffixing FFT_len/4 (i.e. 16 = CP) lots of 0's in the TD at the
transmitter, and this fi
On 30.04.2014 13:14, David Halls wrote:
Hi Martin,
This is OTA or over a cable, 2.48GHz using the N210 with XCVR2450. The
results I sent are over a cable, and the results I sent are post equalizer.
Which equalizer are you using? A custom one? Those in GNU Radio aren't
fantastic, and they don'
Hello David,
as get_time_now is a public function of usrp_sink, it is accessible from
everywhere :)
You'll need a (shared) pointer to that usrp_sink;using that, you can do
something like
uhd::time_spec_t now = my_usrp_sink->get_time_now();
You could, for example, take an usrp_sink::sptr as an argu
Dear All,
I would like to have knowledge of the USRP time in my transmitter flow graph.
In the receiver flow graph this is straight forward because 'rx_time' tag is
propagated from a USRP source as a tag.
How can I obtain the time_spec from a c++ block in my transmitter flow graph?
"usrp_sink_
Hi Martin,
This is OTA or over a cable, 2.48GHz using the N210 with XCVR2450. The results
I sent are over a cable, and the results I sent are post equalizer.
It is only the final symbol of a burst, not the final symbol of each packet.
I agree they should all be equally noisy, and I am certain i
On 30.04.2014 11:51, David Halls wrote:
Hi Martin, All,
Has anyone noticed that the final symbol of any burst (no matter how
many packets in a transmission) appears slightly 'noisy' in the OFDM
example code? Is it something to do with my set-up?
I attach a picture of the eq'd FD constellation w
You should attached the files where you put the std::cout.
The std::cout should be in the work() function.
On Wed, Apr 30, 2014 at 11:07 AM, Sara Chérif wrote:
> I am testing some blocks to understand the synchronization in ofdm . I
> edited c++ files & put std::cout for all variables in
> frequ
On 29.04.2014 23:22, zielalaoui wrote:
Hi all,
I am trying to build transmission on air by using USRPs N210. The
transmission is good with MPSK modulations but when i try to use 16_QAM i
could not receive data (0 bytes at the reception). I tried to adapte
transmission power, gain at the tranmitte
On 29.04.2014 22:43, Jay Radcliffe wrote:
The protocol is unknown at this time. I need to see the packets to
figure some of this out.
Jay,
does the QT GUI Time Raster sink help you in any way?
M
Ideally, I would like to see the entire packet (including the preamble
and sync word) to start
29 matches
Mail list logo
