Problem with rx_voice.py

GNU Radio
1

Hi All,

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.

line 88 reads:

    fg.audio_tx.msgq().insert_tail(gr.message_from_string(payload))

since fg is undefined I altered this line to:

    tb.audio_tx.msgq().insert_tail(gr.message_from_string(payload))

Have anyone experienced the same thing?

/Ulf

2

Yes Ulf,

some changes are going on in the building blocks of GnuRadio. For some
guidance, have a look at
http://lists.gnu.org/archive/html/discuss-gnuradio/2008-08/msg00222.html

We are going to create a Wiki page about the required changes to old
code when things slow down a bit…

On Mon, Aug 25, 2008 at 08:58, Ulf Lindgren A
[email protected] wrote:

since fg is undefined I altered this line to:
Discuss-gnuradio Info Page

–
Dimitris S.
“If you think you’re too small to make a difference, try sleeping with
a mosquito!” - Amnesty International

3

On Sun, Aug 24, 2008 at 11:58 PM, Ulf Lindgren A
[email protected] 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.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

4

On Mon, Aug 25, 2008 at 2:17 PM, Johnathan C.
[email protected] wrote:

On Sun, Aug 24, 2008 at 11:58 PM, Ulf Lindgren A
[email protected] 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. 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).

Has there been any progress lately on the ability to do synchronous data
modes?

5

On Mon, Aug 25, 2008 at 03:46:45PM -0400, Gregory M. wrote:

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

6

On Mon, Aug 25, 2008 at 4:05 PM, Eric B. [email protected] 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.

7

On Wed, Sep 17, 2008 at 09:31:22PM -0400, Gregory M. wrote:

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.

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