Re: [Discuss-gnuradio] Packet Transfer?

[Joshua Lackey]

Quoting Michael Dickens (address@hidden):
> After reading through the GMSK2 code, I wonder why packets are not  
> transferred in the "usual" way: via the graph "connect()" method?   
> They are instead transferred via "callforward" ["send_pkt()"] and  
> "callback" ["rx_callback()"] methods, which requires extra threads to  
> "automate" any data transfer.

I didn't write the GMSK2 code, just some of the modulation/demodulation
used in the background, but I can take a stab at the reasoning.

The main problem with using connect() to attach a source to your
transmitter is what to do when you have nothing to send.  Normally a
transmitter will just transmit an unmodulated carrier when it has
nothing to do.  It will modulate the carrier when it has data to
transmit and then go back to transmitting an unmodulated carrier when
the data is finished.  If you directly attach a source to the GMSK code
it couldn't ever transmit an unmodulated carrier.  It would immediately
start transmitting a modulated carrier and then, once the data source
was exhausted, stop transmitting anything.  The way that GMSK2 is coded
now allows the source to produce the unmodulated carrier when there is
nothing to send and to modulate the carrier when data is provided via
send_pkt().

One could argue that it makes sense to only transmit when there is data
to modulate and thus the GMSK code should be a processor block and you
should connect a source to it but there are a couple of problems with
this.  How does your source get the data?  If you think about it you'll
probably end up reimplementing the send_pkt() routing for your new
source anyway.  Also, if you don't transmit an unmodulated carrier it
becomes difficult for your receiver to know that it has tuned to, and
doesn't drift from, the correct frequency.


> Reading through the code provided at < http://wwwcs.upb.de/cs/ 
> gsr.html >, they send packets using special flags the indicate  
> "start" and "end" ... not exactly what I had in mind because it means  
> that each block must search for the start before processing ... lots  
> of wasted time because once as packeted has been 'sync'ed, the rest  
> of the packet should be "known" to any further blocks.  I -think-  

I haven't read through this code but I think you may be mistaken.

The obvious thing to do is to attach synchronization bits to the start
of a packet just before you transmit it.  The receiver can then search
for those bits to determine when data is sent.  Once the receiver
determines that it has actually received data it will strip the
synchronization bits off the data and send it along to the next
processing block.  (Or rx_callback() as the case may be.)

So you aren't searching for these flags between each block just between
the receiver and the transmitter.


> their method can also result in believing that a packet is there when  
> it's not really (found the "start", must be a packet, but it was just  
> random data; or similar for "end"), which would be undesirable.

Noise can always look like data no matter what you do.  The probability
can be made arbitrarily small using various methods but you can't make
it zero.

For example, if you make the synchronization word very long you can make
it much more unlikely for noise to be misinterpreted as your
synchronization word.  You could also add a parity check to the data you
receive so that even if you accidently recognize noise as your
synchronization word you still won't be fooled because the parity check
on the received data will, in most cases, fail.

Except in either case noise can still look like the synchronization word
or it can pass the parity check.  Or it can do both.  Sure, it's not
likely, but it can happen.


> What I'd really like is to send packets as structured chunks of data,  
> using "connect()" in a graph.  I will likely code this up & see if  
> the "scheduler" can handle both (1) sometimes getting nothing when it  
> wants something (e.g. when 'sync'ing on incoming symbols and no  
> packet found); (2) sending exactly the packet data, not truncated,  
> between block modules.
> 
> Any advice, thoughts, comments?  Has anyone done this?

My advice is to go for it!  You'll quickly see what I'm describing above
and there is no better way to learn something then to do it yourself.
In fact, the reason for all the python glue is to be able to quickly
experiment with these types of things.


-- 
Joshua Lackey, PhD. -- address@hidden