Re: [Discuss-gnuradio] Problem with rx_voice.py

[Eric Blossom]

On Wed, Sep 17, 2008 at 09:31:22PM -0400, Gregory Maxwell wrote:
> On Mon, Aug 25, 2008 at 4:05 PM, Eric Blossom <address@hidden> wrote:
> >> But the need for python to rebuild the signal chain after every
> >> packet is an utter killer which keeps it from working remotely
> >> efficiently. (i.e. back to back packets with the modem running at
> >> the same bitrate as the codec).
> >
> > I'm not sure why you'd be rebuilding the chain after every packet?
> 
> Because thats what all the "packet data" examples in python/digital/
> do. I had made a couple of assumptions because I didn't look under the
> covers deep enough.

Gregory, I think there must still be some misunderstanding.  The graph
is not changed (at all) in those examples.

> I had assumed that, it was the demodulator providing framing, and that
> it required the callback scheme. This seems to be incorrect, looks
> like I can just feed a stream of samples into the GMSK demodulator and
> I'll get out a stream of characters stuffed with bits at some random
> offset. Good: I can work with that.

The demodulators are orthogonal to framing recovery.

> > Is there some kind of "winking bit" in the frames (toggles every
> > vocoder frame) that you can use to establish frame synchronization?
> > If so, then I don't see any problem.  You just need a small state
> > machine that tracks the winking bit, and uses that to reframe the
> > payloads.
> 
> I can provide framing that I can sync to, that was never my problem.
> Now that I know the modulators aren't imposing this callback stuff on
> me I'm back to the races.  I don't know why this isn't a solved
> problem elsewhere in the gnuradio code tree, the stuff in
> digital_voice looks like is currently dead code and never would have
> worked.

It worked at some point in the past, but has seen serious serious bit rot.

It seems like the case you're working on -- the isochronous case --
should actually be cleaner and simpler than the discontinous packet
examples.


> The blks2 GMSK demodulator seems to only provide hard decision output.
>  I'd like to use a 1/2 rate code over my data.  Are there any other
> examples of blocks that implement any of this?

Just make a renamed copy of gmsk.py and remove the slicer.  Then feed
the resulting data to one of the viterbi decoders in the tree.  Take a
look at gr-trellis.  There are good examples and great documentation
there.


> >> Has there been any progress lately on the ability to do synchronous data 
> >> modes?
> >
> > I don't think there's anything in particular that needs to be done.
> 
> When I tell people about GNU radio I make a big point of how the
> 'python tying together blocks' model allows "non-programmers" to make
> real usable radio applications.   And it's true for the analog
> modulation stuff, I've taken people who have never programmed before
> and had them wiring up filters and FM demodulators in no time.


> Perhaps I'm still completely confused, but as far as I can tell
> "packet" type data can't be handled inside gnuradio except entirely
> internally to a block that presents stream interfaces to the outside
> world, or by using the callback hacks the stuff in /digital/ uses
> which simply doesn't  work right for anything not highly async.  I
> don't see any way, for example, to allow a python-only user to wire up
> different error correcting codes along with a standalone speech-codec
> because I need to have the whole framer inside the codec block since
> there is no way to provide framed data over the normal signal paths.

This isn't quite true (but see below).  There shouldn't be any problem
dealing with a convolutional code, or anything else that doesn't
require knowledge of a frame boundary.  Then you could build a block
that consumes the demodulated, decoded data 1 bit at a time (in the
LSB) and correlates for the winking bit, or some other pattern.  This
block would output two streams: a copy of it's input, and a 1/0
decision on whether the corresponding data bit is the beginning of a
frame.  Once you've got that, you can then package the bits up into
the format your vocoder decoder expects.


The "packet problem" will be solved in the relatively near future by
adding support for sending and receiving variable length messages to
all gr_blocks using a message type appropriated from the mblock code.
This supports data and arbitrary associated metadata.  This will
enable streaming blocks, message passing blocks and blocks that do
both to coexist and easily interoperate.  We all agree that MAC-like
and other packet based problems need a better solution than the
kludged up mess we've currently got.

Eric