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
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
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
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?
On Mon, May 01, 2006 at 09:42:01PM -0400, Michael D. 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
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
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
On 5/2/06 12:29 AM, “Eric B.” [email protected] 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
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