Forum: GNU Radio Question Regarding GMSK2 examples

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
4522584485642ff4b4021cb3dbc8fb76?d=identicon&s=25 Elaine Garbarine (Guest)
on 2006-05-03 18:58
(Received via mailing list)
Hello,

I have a question about the GMSK2 examples, specifically the receive
code.
What I would like to do is be able to print the contents of the received
data out to screen.  The end goal would be to be able to pass the data
over
to a Message Passing Interface so that it could be passed to higher
network
layers.  We have a working MPI but we just can't figure out how to
access
the demodulated GMSK data once it is received by the USRP.  Any help
would
be greatly appreciated.

Regards,
Elaine
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2006-05-03 18:59
(Received via mailing list)
On Mon, May 01, 2006 at 07:19:49PM -0400, Elaine Garbarine wrote:
> Regards,
> Elaine

Hi Elaine,

If you look at gnuradio-examples/python/gmsk/tunnel_ip_null_mac,
you'll see how to pass packets to and from the networking layer using
the "tun" interface.

In benchmark_gmsk_rx, look for the function rx_callback.  It's called
with the received data in the "payload" argument as a python string.

Eric
4522584485642ff4b4021cb3dbc8fb76?d=identicon&s=25 Elaine Garbarine (Guest)
on 2006-05-03 18:59
(Received via mailing list)
Eric,

Thanks for pointing out rx_callback to me.  I can't believe I missed
that
function when I was going through the example.

As a related question, does rx_callback only exist if the packet is
received
properly (i.e. without errors)?

Regards,
Elaine
821c1adf3f4be2f2aa6fbc89cce4c69a?d=identicon&s=25 Michael Dickens (Guest)
on 2006-05-03 18:59
(Received via mailing list)
On Monday, May 1, 2006, at 08:21 PM, Elaine Garbarine wrote:
> As a related question, does rx_callback only exist if the packet is
> received
> properly (i.e. without errors)?

In essence, yes: the rx_callback will only be called when a packet is
received without (*) errors.  See
.../gnuradio-core/src/lib/general/gr_packet_sink.cc and it's work()
method and finite-state-machine-ish code if you really want the
in-depth story.

(*) This happens when enough of the sync bits are correct (either the
user-supplied value or the default of 12 bits wrong out of 64) and the
immediately-following 32-bit header is correct (meaning that the first
16 bits and second 16 bits are identical [correct or not], and that the
payload length [the integer value of either of the first or second 16
bits] is <= 4096).  Note that the "function" 'slice()' could more
reasonably be called "hard_decode_bit()" since that's what it does.

ps> As a general question regarding the gr_packet_sink, why does this
have to do it's output via a gr_message inserted into a queue?  Why not
stream the output to the next block in the flow graph style?  Is this
one of the "message versus stream" issues that BBN's proposal will
address?  Or is it something to do with carrier recovery and such?  Or
was the carrier issue why the gmsk2_mod_pkt required queued packets and
not a stream?
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2006-05-03 18:59
(Received via mailing list)
On Mon, May 01, 2006 at 08:21:10PM -0400, Elaine Garbarine wrote:
> Eric,
>
> Thanks for pointing out rx_callback to me.  I can't believe I missed that
> function when I was going through the example.
>
> As a related question, does rx_callback only exist if the packet is received
> properly (i.e. without errors)?
>
> Regards,
> Elaine

It's called if the header (which includes the payload length) is
decoded correctly.  If the payload is error-free (based on the CRC),
then ok is True.

Eric
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2006-05-03 18:59
(Received via mailing list)
On Mon, May 01, 2006 at 09:42:01PM -0400, Michael Dickens wrote:
>
> stream the output to the next block in the flow graph style?
Because flow graphs, as currently constituted, do a terrible job with
variable length chunks of data.  Hence the BBN design-in-progress on
the m-block extension.

> Is this  one of the "message versus stream" issues that BBN's proposal will
> address?

Yes.

> Or is it something to do with carrier recovery and such?  Or was the
> carrier issue why the gmsk2_mod_pkt required queued packets and not
> a stream?

It was all to support variable length packets within the existing GNU
Radio framework.

Eric
4522584485642ff4b4021cb3dbc8fb76?d=identicon&s=25 Elaine Garbarine (Guest)
on 2006-05-03 18:59
(Received via mailing list)
That makes sense to me.  Is there anyway to access the payload even if
the
data is not decoded correctly?  I know this seems like a useless concept
but
it's something we would like to do.

Also, a quasi-related question, the README file included in the GMSK2
directory makes a note that the boards must be at least 3m apart in
order
for the rx to work properly.  Why is it necessary to place the boards at
least 3m apart?

-Elaine
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2006-05-03 18:59
(Received via mailing list)
On Tue, May 02, 2006 at 12:01:47AM -0400, Elaine Garbarine wrote:
> That makes sense to me.  Is there anyway to access the payload even if the
> data is not decoded correctly?  I know this seems like a useless concept but
> it's something we would like to do.

Yes, the payload (with errors) is passed even if ok is False.

> Also, a quasi-related question, the README file included in the GMSK2
> directory makes a note that the boards must be at least 3m apart in order
> for the rx to work properly.  Why is it necessary to place the boards at
> least 3m apart?

It's so that the transmitter doesn't drive the receiver's front end
into a seriously non-linear zone.  The Flex 400 Tx section will put
out about 100 mW, which is enough to cause intermodulation distortion
(IMD) on most receivers if they're close by.  For demos using amateur
handhelds as receivers, we've replaced the transmit antenna on the
Flex 400 (oops, that's the daughterboard formerly known as the Flex
400) with a 50 ohm load to avoid the problem.

Bottom line, it's the non-ideal analog stuff ;)

Eric
4522584485642ff4b4021cb3dbc8fb76?d=identicon&s=25 Elaine Garbarine (Guest)
on 2006-05-03 18:59
(Received via mailing list)
On 5/2/06 12:29 AM, "Eric Blossom" <eb@comsec.com> wrote:

>> least 3m apart?
>
> Eric

Got it.

Am I safe to assume the 3m distance would also apply to the
daughterboard
formerly known as the Flex 2400?

-Elaine
This topic is locked and can not be replied to.