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

[Gregory Maxwell]

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.

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.

> 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.

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?

>> 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.