Category: Pi

Building a transcoder for DMR -> D-Star

Grae  
Published under: D-Star, DMR, Online Radio Club, Pi, Radio, Software

At the Online Radio Club, we have a D-Star XLX reflector with SmartGroups. This is XLX944, and the smart groups TORC1, TORC2, and TORC3. We want to bring more people to this online watering hole, so we hatched a plan to add a transcoder to/from DMR. This post is about how I went about getting that organised. The transcoder needs to sit on a fixed IP with access to physical hardware to add some AMBE hardware encoder/decoders. While all the rest of reflectors can live in somebody’s cloud, there’s a need for something physical to plug the AMBE USB sticks into.

I grabbed a Raspberry Pi 3B as the server for this. I got a Pi 3B, loaded the latest Raspbian lite onto it. I ordered a pair of DV Mega DVstick30s. These are AMBE3000 chips, so you need two to do transcoding (on in each direction at once, full-duplex, I presume) You may be able to get the

Now, let’s get some software organised on this. The transcoding software is called ambed and it is a part of the xlxd software. I’m just running ambed on the Pi 3B, the actual xlxd is running in the cloud somewhere.

I found I needed to configure the DVstick30s to have a different USB name to be detected properly by ambed. I did that using FTD Prog to re-program the USB Product Description from a generic FTDI serial name to USB-3000. See how to do this in this message by KB2EAR.

Now to the ambed software. There’s a set of command to type on PA7LIM’s page for the AMBE3003 config. They worked for me.

A little bit of config. In /ambed, edit the run file and replace the IP address 127.0.0.1 with the IP address of your Pi on your network.

Finally, I wrote a systemd service script:

[Unit]
 Description=AMBED
 After=network.target
 [Service]
 ExecStart=/ambed/run
 Type=simple
 PIDFile=/run/ambed.pid
 User=root
 Group=root
 [Install]
 WantedBy=default.target

I placed this in a file called /etc/systemd/system/ambed.service. And then issued a couple of commands:

sudo systemctl daemon-reload
sudo enable ambed
sudo start ambed
sudo status ambed

And you should see something like:

pi@transcode:~ $ systemctl status ambed
 ● ambed.service - AMBED
    Loaded: loaded (/etc/systemd/system/ambed.service; enabled; vendor preset: enabled)
    Active: active (running) since Tue 2019-08-06 07:03:45 BST; 2h 48min ago
  Main PID: 498 (run)
     Tasks: 15 (limit: 2200)
    Memory: 5.5M
    CGroup: /system.slice/ambed.service
            ├─498 /bin/bash /ambed/run
            ├─527 sudo /ambed/ambed 192.168.105.112
            └─532 /ambed/ambed 192.168.105.112
 Aug 06 07:03:46 transcode run[498]: Description : USB-3000         Serial : DM481NAO
 Aug 06 07:03:46 transcode run[498]: Opening USB-3000:DM41GIUP device
 Aug 06 07:03:46 transcode run[498]: ReadDeviceVersion : 0AMBE3000R
 Aug 06 07:03:46 transcode run[498]: 1V120.E100.XXXX.C106.G514.R009.B0010411.C0020208
 Aug 06 07:03:46 transcode run[498]: Opening USB-3000:DM481NAO device
 Aug 06 07:03:46 transcode run[498]: ReadDeviceVersion : 0AMBE3000R
 Aug 06 07:03:46 transcode run[498]: 1V120.E100.XXXX.C106.G514.R009.B0010411.C0020208
 Aug 06 07:03:46 transcode run[498]: Codec interfaces initialized successfully : 2 channels available
 Aug 06 07:03:46 transcode run[498]: Initializing controller
 Aug 06 07:03:46 transcode run[498]: AMBEd started and listening on 172.21.105.112

And that is about it. It looks like it is working. More on the testing and xlxd integration later.

The CW Commuter

The CW Commuter

Grae  
Published under: CW, Morse, Pi, Radio

I’ve written before about trying to use CW while commuting. I was looking into a bunch of different ways of achieving commute CW operating via the Internet.

And going back to 2016, I started thinking about how to send/receive CW via a lossy datagram-based internet connection.  Lossy, because us hams can do error correction and deal with QSB already with our operating practices.   And it is more like real radio if it is a bit unreliable.

The protocol

So back in 2016, I wrote down an on-the-wire protocol for this — called bitoip.  Each end would send and receive packets of carrier-on and carrier-off events to communicate the CW with real timing (and therefore hand-key “fist” dynamics) — without needing to run up a pile of audio channels and all of that.   I assume it this ought to be low-bandwidth and reasonably reliable but not too reliable.

Protocol details in the GitHub repo at https://github.com/G0WCZ/cwc. See bitoip.md for those details.

Equipment

Okay, so how about the equipment needed for this?  There are two components:

  1. A station – that turns keyed morse into packets, and receives packets and turns them into a tone in headphones or can drive a separate oscillator.
  2. A reflector – that creates a number of channels that stations can connect to.  This really just broadcasts to connected stations what it hears coming in.  Plus other enhancements if needed later.

So now let’s look at equipment options:

Station

My minimal station would be a tiny box that can wifi to my phone hotspot and has a key and a headphone jack.  Optionally a volume control and channel selector.   That’s a minimal option.  That’s a Pi Zero W with a couple of parts to add a headphone output.  Other ways would be — a PC or Mac (Linux, Windows, OS/X) with a serial interface for key and using the built-in audio.

I’ve built basic Go code for a one-channel station client that will compile for most platforms. This includes the serial and Pi GPIO I/O for key interface (in/out) and PWM audio.   That’s in the repo. See https://github.com/G0WCZ/cwc/tree/master/go

I’ll tidy up the hardware and publish that soon.

Reflector

I’ve built a basic one-channel-only reflector in Go that works nice on a Pi, on OS/X or Linux.   That is also in the repo at https://github.com/G0WCZ/cwc/tree/master/go

There’s a basic single-channel reflector server running on cwc0.nodestone.io:7388

Initial Testing

CWC Pi and serial development

Over this Easter break, I’ve writing Go code and have been doing some tests of the basic station and reflector.  It works.  I suspect some more work on time sync is needed but for now, it seems to capture, transmit, receive and reconstruct morse okay.

More on Github

I’m going to keep working on this. Feel free to join and collaborate over on GitHub at https://github.com/G0WCZ/cwc or leave a comment here.

Pi + Mumble + iCW

Grae  
Published under: CW, iCW, Morse, Pi, Radio

I commute to and from London 4 days a week.  There’s an hour on the train each way.  I can only do so much CW training. What I need is something that connects to the phone to allow an easy CW QSO or two.  iCW is close, but doing that with a computer and all the gubbins is a bit too much to set up.  So I was thinking about this:

What sort of small black box can I make that will wifi to my phone hotspot, have a plug for key and headphones and micro USB for power (or have battery brick inside.)  It’d have just one big knob for channel selection and a couple of LEDs to indicate connection status.  

What would that be?  First thought is a Raspberry Pi Zero W with the headless Mumble client by Daniel Chote: https://github.com/dchote/talkiepi and a bit of work to interface a key and add a hacky headphone output.

So, that’s the basic idea.  I’ll see where experiments take me.