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

[Eric Blossom]

On Mon, Aug 25, 2008 at 03:46:45PM -0400, Gregory Maxwell wrote:
> On Mon, Aug 25, 2008 at 2:17 PM, Johnathan Corgan
> <address@hidden> wrote:
> > On Sun, Aug 24, 2008 at 11:58 PM, Ulf Lindgren A
> > <address@hidden> wrote:
> >
> >> I have been  trying the tx_voice.py and rx_voice.py, and I have had some
> >> problems with the rx_voice.py failing. However, I think there is a bug in
> >> the rx_voice.py file, at least everything works when I change it.
> >
> > Good catch, this was missed back when we did the conversion on the
> > trunk.  It's been updated now.
> 
> FWIW, I've created an enhanced version with support for Speex and CELT
> along with a few other bells and whistles.

Great!

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

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.

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

On the receiver you just need a way to establish frame sync.  On
FEDSTD 1016 and most other (military origin) vocoders I've looked at,
there's a winking bit defined in the frame used to solve exactly this
problem.

See also section 3.6 of http://comsec.com/vp1-protocol.pdf
It describes a protocol where the modem and the vocoder were running
at the same rate.

Eric