The DockerHub images link back to my GitHub, and I’m using the auto-build feature so that when I update the Dockerfile and scripts to build the software, it gets rebuilt over at DockerHub automatically.

Here’s an example of one of the builders for W1HKJ’s FlDigi software suite. Simply run the container volume mounting in some working directory to /opt/source in the container, and the build script finds the latest source, downloads, untars, and builds it, spitting out the results in your working directory.

jacob@jacob-aspire:/tmp/fldigi$ docker run --rm -v $PWD:/opt/source jacobcalvert/fldigi-build:latest 
Building fldigi-4.1.18
--2021-05-26 12:39:39--  http://www.w1hkj.com/files//fldigi/fldigi-4.1.18.tar.gz
Resolving www.w1hkj.com (www.w1hkj.com)... 143.95.246.118
Connecting to www.w1hkj.com (www.w1hkj.com)|143.95.246.118|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4847091 (4.6M) [application/x-gzip]
Saving to: 'fldigi-4.1.18.tar.gz'

     0K .......... .......... .......... .......... ..........  1%  736K 6s
    50K .......... .......... .......... .......... ..........  2% 1.53M 5s
   100K .......... .......... .......... .......... ..........  3% 2.52M 4s
   150K .......... .......... .......... .......... ..........  4% 27.7M 3s
   200K .......... .......... .......... .......... ..........  5% 3.33M 2s
   250K .......... .......... .......... .......... ..........  6% 2.67M 2s
   300K .......... .......... .......... .......... ..........  7% 28.3M 2s
   350K .......... .......... .......... .......... ..........  8% 8.94M 2s
   400K .......... .......... .......... .......... ..........  9% 9.29M 2s
   450K .......... .......... .......... .......... .......... 10% 7.04M 1s
   500K .......... .......... .......... .......... .......... 11% 4.42M 1s
   550K .......... .......... .......... .......... .......... 12% 8.31M 1s

  <<<<<<<<<<<<<<<<<<<<<<<< snipped for brevity >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

make[1]: Nothing to be done for 'all-am'.
make[1]: Leaving directory '/opt/source/flrig-1.3.54'
Done!!
jacob@jacob-aspire:/tmp/fldigi$ ll
total 11224
drwxrwxr-x  5 jacob jacob    4096 May 26 13:05 ./
drwxrwxrwt 18 root  root     4096 May 26 13:05 ../
drwxr-xr-x  9 jacob jacob    4096 May 26 13:05 fldigi-4.1.18/
-rw-r--r--  1 root  root  4847091 Jan 29 06:50 fldigi-4.1.18.tar.gz
-rw-r--r--  1 root  root  4847091 Jan 29 06:50 fldigi-4.1.18.tar.gz.1
drwxrwxr-x  7 jacob jacob    4096 May 26 12:45 flmsg-4.0.17/
-rw-r--r--  1 root  root   876560 Sep  8  2020 flmsg-4.0.17.tar.gz
drwxr-xr-x  7 jacob jacob    4096 May 26 12:46 flrig-1.3.54/
-rw-r--r--  1 root  root   891644 Feb  3 08:35 flrig-1.3.54.tar.gz

The post Docker Builders for Easy Updates appeared first on Jacob N Calvert.

The External Connector

The mini DIN connector on the back has a fairly standard pinout as shown below. Note it says 4800bps max for the DATA IN. I want to find out why!

In the service manual, I start by locating pin 1 on the DIN connector.

Internal Circuitry

Next I trace this to a pair of 2-1 muxes.

These muxes are operated together (that is, their control signal is the same signal). From my investigation, this is the mux pair that is activated when selecting the TNC operation for the radio. The right-most mux, IC114, selects between MIC IN audio from the mic port, through a series of filters, or the TNC port we’re interested in. The left-most mux, IC112, selects which TX generator chip we’re going to be using. The path I’ve highlighted in red is the TNC audio input path I’m trying to trace.

Transmission Modulation

Next the signal travels to the MICIN pin on a chip with designator IC109, and part number BK4811B.

This is where the magic of modulation happens, and where I ultimately found the reason for only supporting up to 4800bps. Scouring the web for a datasheet for this chip, I found a PDF I could download. Checking the relevant sections of the chip’s documentation, I found the culprit, screenshot below:

The audio path into the chip is shown in the blocks at the bottom. The bullet points 6 & 7 tell the details of why 9600bps isn’t usable. The low-pass and high-pass blocks cannot be bypassed on this chip, and the maximum achievable width is ~2.7k, which is not enough for 9600bps. You can turn off the compander and pre-emphasis, but there’s no way to expand the LPF->HPF network bandwidhth. To run 1200-4800bps you really only need ~1kHz, but 9600bps needs to have much more.

Wrapping Up

Now that I am satisfied that the radio can *not* in fact TX 9600bps (but can receive it, perhaps another analysis in another post to come), I will get on with getting DireWolf setup for APRS, and FlDigi for other fun digital modes.

The post Why the Alinco DR-735T can’t transmit at 9600bps appeared first on Jacob N Calvert.