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
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
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 saracheri...@gmail.comwrote:
I am testing some blocks to understand the synchronization in ofdm . I
edited c++ files put std::cout for all
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
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
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?
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
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
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
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 to that
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;
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
On Wed, Apr 30, 2014 at 3:22 AM, Martin Braun martin.br...@ettus.comwrote:
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
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
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
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.
This
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
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
On Wed, Apr 30, 2014 at 10:58 AM, zielalaoui z.i.elala...@gmail.com 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
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
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,
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?,
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 |=
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 m...@ossmann.com 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
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:
Cool! In
On Wed, Apr 30, 2014 at 12:04 PM, zielalaoui z.i.elala...@gmail.com 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
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
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,
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
29 matches
Mail list logo
