discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] RTTY receiver


From: Barry Duggan
Subject: Re: [Discuss-gnuradio] RTTY receiver
Date: Wed, 12 Jun 2019 16:26:36 -0400
User-agent: Roundcube Webmail/1.3.8

Hi Marcus,

I wasn't careful in getting the filenames right, but the intent and the execution were there :)

If you look at bitglue/gr-radioteletype/lib/baudot_encode_bb_impl.h, the tables have a '-1' to indicate characters which do not have a corresponding Baudot code. In bitglue/gr-radioteletype/lib/baudot_encode_bb_impl.cc in lines 77 and 93, there is a test of the '-1'. However, it is not good practice to put integers in a table of characters. Therefore, I picked another value which is not a valid Baudot code, but is a seven-bit value, thereby avoiding any sign issues.

Git can tell you the 'what' and the 'when', but not always the 'why'. Good comments are worth the effort!

BTW, when I started from scratch (again), I did a git clone instead of downloading the zip file. So now I can track my changes better. When we finish this, I will offer my changes as well as some additions to README.

Best wishes.
---
Barry Duggan
cell: 256-426-0824


On 2019-06-12 12:40, Müller wrote:
Hi Barry,

On Wed, 2019-06-12 at 06:59 -0400, address@hidden wrote:
Hi Kyeong,

1) In lib/radioteletype/baudot_encode_bb.h I tried replacing "static
const char" with "static const signed char", but it caused complications
in radioteletype/baudot_encode_bb.cc, so I took an alternate approach:

Wait, these filenames don't align with the ones I'm looking at – could
you verify we're both looking at the code from github.com/bitglue/gr-
radioteletype ?

Since this really just "spells out" the original code's intent, there
shouldn't be *any* problems at all with that. Maybe we should have a
look at these problems that arose?

/*
  * modified by Barry Duggan KV4FV
  * 11 June 2019
  * with RaspberryPi compiler, an error is produced comparing char and
signed char values.
* to circumvent this problem, I have changed all "-1" entries to "0x7f"

Hm, -1 would be 0xFF in my math, wouldn't it? 0x7F is plain 127!

in the table
  * and in the code
  */

By the way, spot the experienced old-school programmer: That's a
classical beautiful changelog comment from the pre-git era. Kudos :)
Always a pleasure to see.

So now the 'make' works without errors.

I presume that also includes the negative number comparisons in
lib/baudot_encode_bb_impl.cc 's general_work() function?


2) In 'sudo make install' I got the following:
-- Installing:
/usr/local/lib/python2.7/dist-packages/radioteletype/_radioteletype_swig.so
-- Set runtime path of
"/usr/local/lib/python2.7/dist-packages/radioteletype/_radioteletype_swig.so"
to ""
which leads to a run-time error...
Traceback (most recent call last):
File "/home/pi/gr-radioteletype/examples/rtty_demod.py", line 30, in
<module>
     from radioteletype.demodulators import rtty_demod_cb
   File
"/usr/local/lib/python2.7/dist-packages/radioteletype/demodulators.py",
line 9, in <module>
     from radioteletype_swig import (
   File
"/usr/local/lib/python2.7/dist-packages/radioteletype/radioteletype_swig.py",
line 21, in <module>
     _radioteletype_swig = swig_import_helper()
   File
"/usr/local/lib/python2.7/dist-packages/radioteletype/radioteletype_swig.py",
line 20, in swig_import_helper
     return importlib.import_module('_radioteletype_swig')
   File "/usr/lib/python2.7/importlib/__init__.py", line 37, in
import_module
     __import__(name)
ImportError: No module named _radioteletype_swig

So, where should '_radioteletype_swig.so' go, and how do I specify it?

That file should have gotten installed just OK if it was successfully
built. Are we sure that the build itself is successful? Sometimes, SWIG
(which generates our C++/Python glue half-automatedly) gets stuck, so
you really have to "make clean; make; make install". It's a bummer, but
I've seen it get nearly extinct over the years.


3) When I loaded 'examples/rtty_demod.grc', there was a missing block
'pulseaudio_pa_sink'.

That seems to be a block from a different out-of-tree module.

However, you really don't need a pulseaudio block to speak to that most
common Linux user audio subsystem. Just replace that block with the
"audio sink" that GNU Radio brings itself.

Where is it, and what does it do?

Its purpose is probably to send audio to your Sound card, in the end.

Since it didn't
seem directly required for the rest of the example to work, I deleted it
and the two blocks feeding it.

4) I really appreciate all that you and the others are doing to help
with this.

We really appreciate you asking here, so keep up the good work!

Cheers,
Marcus



reply via email to

[Prev in Thread] Current Thread [Next in Thread]