Jnos vara FM/HF

Okay, I’m probably a bit behind. But Maiko has managed to great a IP BRIDGE over VARA HF/FM modem.
That’s really great … I read that WINRPR is also already supported. Lots of progress.


prototype IP bridge interface for EA5HVK VARA HF Modem - January 16, 2021

 Ready to declare the first prototype, evening of January 16, this is working
 quite well, almost flabbergasted. I am now using PPP as part of the code, and
 the interface is now an IP bridge - JNOS to JNOS using VARA HF modems ...

 Initially started working on the VARA HF interface on January 5, 2021

 Just have to tidy up the code a bit, and document the heck out of it.

 Latest prototype code is found under RSYNC area, look for 'varadev.tar' file
  (make sure you #define PPP and #define EA5HVK_VARA in your config.h)


 Success - Jaunary 15, 2021

It would appear that I have successfully developed an IP BRIDGE over
VARA HF modem for JNOS. With some mods to the JNOS ppp code,
and integrating into the VARA HF interface I've been working on, I now
actually have an active telnet going on between my 2 JNOS test sites,
both linked to each other via trial copy of VARA HF modem software
over hard wired audio.

It's working flawlessly. I would love to see how fast it is in a real
environment. I need to tidy up stuff, make it more automatic, and
really document the heck out of this, but yes ... appears to work.

This is basically what SCS is doing with their Pactor IP Bridge.

Maiko / VE4KLM

site a ::

attach vara vara0 1500 8300

varacmd "mycall ve4klm"
varacmd "connect ve4klm ve4pkt"

site b :

attach vara vara0 1500 8300

varacmd "mycall ve4pkt"
varacmd "listen on"

After  physical connect established, both sides run :

  ppp vara0 trace 2
  ppp vara0 lcp timeout 60000
  ppp vara0 lcp open
  ppp vara0 ipcp timeout 60000
  ppp vara0 ipcp open

Timeouts have to be large, I will document all of this, very excited !

F9 trace window

Fri Jan 15 22:12:03 2021 - vara0 sent:
PPP: len 104    protocol: IP
IP: len 100> ihl 20 ttl 254 prot TCP
TCP: 23->1030 Seq xa66c161 Ack xf22c034 ACK PSH Wnd 2048 Data 60
0000  ff 03 00 21 45 00 00 64 03 da 00 00 fe 06 d0 93 ...!E..d.Z..~.P.
0010  ac 10 48 01 ac 10 48 04 00 17 04 06 0a 66 c1 61 ,.H.,.H......fAa
0020  0f 22 c0 34 50 18 08 00 48 ed 00 00 55 73 65 72 ."@4P...Hm..User
0030  73 3a 0d 0a 54 65 6c 6e 65 74 20 20 20 28 76 65  s:..Telnet (ve
0040  34 6b 6c 6d 20 40 20 31 37 32 2e 31 36 2e 37 32  4klm @ 172.16.72
0050  2e 34 29 20 20 2d 3e 20 49 64 6c 65 0d 0a 0d 0a  .4)  -> Idle....
0060  28 23 30 29 20 3e 0d 0a                          (#0) >..

jnos> ppp vara0

Network Protocol Phase  (open for 0:00:22:54)
      4196 In,         126 Flags,     0 ME,      0 FE,      0 CSE,      0 other
                    70 Lcp,     0 Pap,    41 IPcp,     0 Unknown
      4312 Out,        135 Flags,     0 ME,      3 Fail
                    72 Lcp,     0 Pap,    41 IPcp
LCP Opened
                 MRU     ACCM            AP      PFC  ACFC Magic
        Local:   1500    0xffffffff      None    No   No   unused
        Remote:  1500    0xffffffff      None    No   No   unused
PAP Closed
        Message: 'none'
IPCP Opened
        local IP address:  remote IP address:


 IDEA - 3 am January 14, 2021

  VARA will be like PACTOR and AMTOR, it requires a changeover which in the
  case of VARA is handled internally. Ever wonder how SCS did the IP BRIDGE
  over PACTOR ? It's publically documented. They use the PPP protocol used
  for telephone circuits, SLIP would work too (pretty sure it would), but
  PPP has better error checking and stuff.

  I think that's the way to do it now, so that's the next part of all this
  experimenting ...


 update January 13, 2021, decided to try enabling IP over AX25 (datagram mode)
 and I got my two JNOS test systems pinging each other. I should know better,
 but this VARA link is probably no different then how PACTOR does it's change
 over functions, but it's all done 'inside the VARA HF modem software'.

 As soon as things try to go both ways, the whole thing stalls. That's where
 I am right now. I really like this 'bridge' approach to linking the systems,
 since I can technically just connect ax25 (ttylink works as long as each
 side waits for the other to finish typing, seems to be okay, but), and I
 have been able to telnet to the point of getting the password prompt, but
 then again it stalls (that's understandable).

 So now spending time trying to figure out flow ctl, may have to rethink
 the interfaces, but I just don't want this to be just another forwarding
 type back and forth, need to get some type of IP and/or AX25 working over
 it, that will most certainly be a challenge (already has been for a bit).


 update January 11, 2021, now able to establish a ttylink session between the
 2 JNOS systems linked to each other with the VARA HF modems. It seems to be
 quite consistent, and I was having a keyboard to keyboard with myself :)
  (see further below for how to setup this up, sorry if it's vague)

 trying to establish a mailbox prompt is another story, seems to be stalling
 on me still, not sure why.

 The latest vara development code is on my JNOS rsync site. Disclaimer, it is
 very experimental, may result in one pulling out their hair, and frustration
 as well, But if you want something to play with, or just to see what or how
 these VARA HF modems work, then go for it.

 Make sure to include this directive below in your config.h before you compile :

   #define EA5HVK_VARA

 to try out the ttylink tests, setup 2 JNOS systems, each will connect
 to their own instance of a Windows VARA HF software modem, use the main
 JNOS log to determine the status of stuff for now. Sorry, but it's still
 in development, so the log will have to do. See example setup below, make
 sure you use valid callsigns of course and the IP addresses applicable
 to your setup. It's VERY experimental, your milage will vary I'm sure.
 on JNOS A :

  attach  vara vara0 256 8300

  once you see both command and data ports connected in the log,
  then set the callsign of your software modem :

    varacmd "MYCALL CALLA"

 on JNOS B :

  attach  vara vara0 256 8300

  once you see both command and data ports connected in the log,
  then set the callsign of your software modem :

    varacmd "MYCALL CALLB"

  we will get the second JNOS to be the listener (both can be),
  but for this test we will have JNOS A connect to JNOS B, so
  still on JNOS B, a few more commands :

    varacmd "LISTEN ON"

  we need ttylink to be working as well, so set the ttycall :

    ax25 ttycall CALLB-4

 then on JNOS A, initiate the CONNECT and establish VARA link :


 again watch the logs, at some point the systems will be linked,
 then you can run this command on JNOS A :

    c vara0 callb-4

 and you should be able to have a keyboard to keyboard :)

 To QUIT the ttylink session, just use 'reset' on the main console
 on either JNOS setup. To disconnect the VARA HF link between your
 2 JNOST systems, issue the following command :

   varacmd "DISCONNECT"

 on either one, it 'should' discconnect both sides ...

 ONE LAST THING - your JNOS will likely hang if you exit the
 vara hf modem software, has to do with tcp socket connection
 not properly ended between JNOS and the software. You might
 have to do a 'kill -9 ' to exit, sorry :)

 This seems to stall if I try the mailbox call, the ttycall seems
 to work fairly decently. Your luck may vary, but this is what I've
 got working so far.

Kantronics KAM All Mode

Today I am the lucky one again. I have added a new modem to the collection. Namely the Kantronics KAM All Mode.

The KAM is using the oldest Firmware that I know of. Version 5.00. The newest is version 8.2. Have a look at this link
Here can you find the Kam Manual.
It is the third Kantronics modem I have. I have the KPC3 (non plus) and the KPC9612 + and now the Kantronics Kam All Mode. Now I am still looking for the KPC3+

Dx Cluster PI1LAP-1

PI1LAP is Running DXSpider as Cluster Software. With Postgresql as database backend for Web Cluster http://dx.packet-radio.nl

PI1LAP is also connected to the Reverse Beacon Network (RBN). Now it is possible to see (Live) Spots from CW, BEACON, RTTY, PSK, FT8 and FT4.
Connect to PI1LAP-1 (telnet dx.packet-radio.nl 7300) and give the command “help set/skimmer” to get help about the skimmer feed.

The skimmer feed from CW and FT8 / FT4 can be overwhelming. Now there are all kinds of possibilities to filter this to specific spots. Filter help use the command “help filter” on the cluster.

# Possible Filter
To only allow FT4 spots you can use a filter
set/skimmer ft
reject/rbn 1 info ft8
show/filter # Show the rules in the filter
clear/rbn 1 or all # Delete filter rule

If you like Dx spots (just like me) you can go to “telnet dx.packet-radio.nl 7300

See ya on the Cluster.

Website DxSpider http://www.dxcluster.org/

LinFBB 7.0.10 released

  Released version 7.0.10 of Linfbb. Great news……

Download it at https://ham.packet-radio.net/packet/f6fbb/linux/recent-version/fbb-7.0.10.tar.gz
Source Link  https://sourceforge.net/projects/linfbb/files/fbb-7.0.10.tar.gz/download

Some info from Dave.

Many thanks to Brian (N1URO) for his maintenance scripts contribution and to Paul (G4APL) for his extensive tests and feedback regarding some old bugs and their fixes. Also many thanks to all other sysops using and testing the development version in the SVN repo prior to this release.


7.0.10 (Dave van der Locht) Add date 1 Nov 2020
- Fixed gateway using wrong FROM callsign with outgoing socket connections.
- Fixed gateway could only use port 1 to 9.
- New 20_epurmess and 20_epurwp maintenance scripts (N1URO).
- Fixed pagination issue with ? command, C (remove paging) didn't work.
- Cleaned obsolete code, fast_fwd was hard set to 1 in init.c but only used 
  in some 'if' statements. 
- Corrected satdoc.c line 384 gcc compiler warning (-Wstringop-overflow)
- Corrected behaviour of /K and /L sysop commands
- Fixed buffer overflow possibility in ibm.c getcurdir()
- Corrected several misleading indentations
- Cleaned code and comments in xfbbd.c
- Fixed problem where inbound connections were disconnected after connect.
  with some port types when port in port.sys was higher than 9.
- Commented debugging printf code in the call_nbdos() function.
- Changed version number to 7.0.10.
- Set SVN file properties accordingly for executable files.
- Placed autogen.sh script back in the SVN repo.
- Fixed gateway J command only could show port 1 to 9 heard lists.
- Fixed mailbox J# command only could handle J1 to J8 (numeric) ports.
- Extended mailbox J# command (letters) a bit.
- Detected and corrected some character encoding problems in tnc.c file.
- Removed autotool generated files from SVN repo.
- Accidentally removed Makefile.am. Placed back into SVN repo.
- Fixed filename not exists error when using YAPP download command (YD).
- Fixed housekeeping routines crashing on several newer Linux distributions.
- Changed src/Makefile.am, the -fstack-check flag conflicts with
  -fstack-clash-protection which is included by default when GCC is built with
  stack smashing protection (SSP).
- Changed README to reflect correct mailing list e-mail address.

BPQ32 Yapp file transfer

BPQ32 and QTermTCP support the Yapp Protocol. Let’s take a look at how that works.

First we have to great a Directory  ” Files”  in the root dir of Linbpq. The user Pi must be the owner of the Directory.

cd /home/pi/linbpq
mkdir Files
ls -l
drwxr-xr-x 2 pi pi    4096 nov  1 12:10 Files
* If the user Pi does not own the directory "Files", you can change that with.
sudo chown pi:pi Files

Now we can set QTermTCP to use the directory “Files” for uploads and downloads. In the top menu choose ” Yapp” , ” Set Receive Directory” and choose the correct directory (Files).

First we need to connect to a local BBS that supports the YAPP protocol. Now I have set up a BBS here for this test. As modems I use two Ninotnc`s connected with a null modem cable.
Now we are ready to send a file. Again choose in the top menu “Yapp” and “Send File” Now you can choose which file you want to send.

Here we go…..

Monitor screen from Linbpq BBS.

File compleet.

The same file but compressed.

NinoTnc update

On my very expensive scoop (hi) you see a packet frame @ 1200 Baud received from a station about 50 kilometers away. Looks fine to me.

After updating the Firmware from version V2.35 to V2.81 I see a good increase in the decoded frames.

How to update the Firmware

wget http://tarpn.net/zflash2020oct/tarpnflashinstaller.sh
chmod +x tarpnflashinstaller.sh

tarpnflash usb
* My Ninotnc is connected to ttyACM0.
tarpnflash version ttyACM0
* Is there a newer version available in the dir "ninotnc" you can run.
tarpnflash flash ttyACM0 (version number)
* Now the Firmware is being updated.
* Check if the flash of the firmware went well.
tarpflash version ttyACM0
* Great now running Version v2.81
/dev/ttyACM0 NinoTNC v2.81

I immediately built my second NinoTNC. I am very curious how that works with IL2P mode, Improved Layer 2 Protocol. In the picture below, the two NinoTnc`s are running at 2400 Baud with IL2P mode. Functions perfectly. Now I have some problems with adjusting to 4800 and 9600 Baud. I have to look into this.


Direwolf 1.6 Official release

Today is the Official release of Direwolf 1.6 (29 Oct 2020)

I’ve been running the “Dev” version of Direwolf for a while. 1.6D. But now I read this morning that John WB2OSZ has made version 1.6 official after 2 years. Version 1.5 was released on 8 Oct 2018

I read in the mail that there is almost no difference with the “Dev” branch. So I don’t really see any need to install the official release.



New Build Procedure:

* Rather than trying to keep a bunch of different platform specific Makefiles in sync, "cmake" is now used for greater portability and easier maintenance.

* README.md has a quick summary of the process. More details in the *User Guide*.

New Features:

* "-X" option enables FX.25 transmission. FX.25 reception is always enabled so you don't need to do anything special. "What is FX.25?" you might ask. It is forward error correction (FEC) added in a way that is completely compatible with an ordinary AX.25 frame. See new document *AX25_plus_FEC_equals_FX25.pdf* for details.

* Receive AIS location data from ships. Enable by using "-B AIS" command line option or "MODEM AIS" in the configuration file. AIS NMEA sentences are encapsulated in APRS user-defined data with a "{DA" prefix. This uses 9600 bps so you need to use wide band audio, not what comes out of the speaker. There is also a "-A" option to generate APRS Object Reports.

* Receive Emergency Alert System (EAS) Specific Area Message Encoding (SAME). Enable by using "-B EAS" command line option or "MODEM EAS" in the configuration file. EAS SAME messages are encapsulated in APRS user-defined data with a "{DE" prefix. This uses low speed AFSK so speaker output is fine.

* "-t" option now accepts more values to accommodate inconsistent handling of text color control codes by different terminal emulators. The default, 1, should work with most modern terminal types. If the colors are not right, try "-t 9" to see the result of the different choices and pick the best one. If none of them look right, file a bug report and specify: operating system version (e.g. Raspbian Buster), terminal emulator type and version (e.g. LXTerminal 0.3.2). Include a screen capture.

* "-g" option to force G3RUH mode for lower speeds where a different modem type may be the default.

* 2400 bps compatibility with MFJ-2400. See *2400-4800-PSK-for-APRS-Packet-Radio.pdf* for details

* "atest -h" will display the frame in hexadecimal for closer inspection.

* Add support for Multi-GNSS NMEA sentences.

Install/compile instructions

### Linux - Using git clone (recommended) ###

***Note that this has changed for version 1.6.  There are now a couple extra steps.***

First you will need to install some software development packages using different commands depending on your flavor of Linux.
In most cases, the first few  will already be there and the package installer will tell you that installation is not necessary.

On Debian / Ubuntu / Raspbian / Raspberry Pi OS:

    sudo apt-get install git
    sudo apt-get install gcc
    sudo apt-get install g++
    sudo apt-get install make
    sudo apt-get install cmake
    sudo apt-get install libasound2-dev
    sudo apt-get install libudev-dev

Or on Red Hat / Fedora / CentOS:

	sudo yum install git
	sudo yum install gcc
	sudo yum install gcc-c++
	sudo yum install make
    sudo yum install alsa-lib-devel
    sudo yum install libudev-devel

CentOS 6 & 7 currently have cmake 2.8 but we need 3.1 or later.
First you need to enable the EPEL repository.  Add a symlink if you don't already have the older version and want to type cmake rather than cmake3.

    sudo yum install epel-release
	sudo rpm -e cmake
	sudo yum install cmake3
	sudo ln -s /usr/bin/cmake3 /usr/bin/cmake

Then on any flavor of Linux:

	cd ~
	git clone https://www.github.com/wb2osz/direwolf
	cd direwolf
    git checkout dev
	mkdir build && cd build
	cmake ..
	make -j4
	sudo make install
	make install-conf

This gives you the latest development version.  Leave out the "git checkout dev" to get the most recent stable release.

For more details see the **User Guide** in the [**doc** directory](https://github.com/wb2osz/direwolf/tree/master/doc).  Special considerations for the Raspberry Pi are found in **Raspberry-Pi-APRS.pdf**

NinoTnc progress

Boy, I can hit my head against the wall. I made a very rookie mistake. I had  soldered a number of Leds the wrong way round.  Tsss before I finally invented that. Very stupid.
But when I finally found out (it’s even in the description on the tarpn website) it now works the way it should.

Let’s test how the reception is. (aprs on 144.800Mhz @ 1200 Baud)

I feel like he is a little deaf. Looks like he’s missing some frames. Maybe it’s the setup I’m using. I am using a Yaesu ft7800 with the NinoTnc directly on the Mini Din of the radio. I have to figure this out, I will read the Tarpn website one more time.

First let’s update the flash.

Mmmmm, let’s give it a go.


A Linbpq configuration example



I am very happy to be able to add this (Nino)TNC to the collection.

Draws Raspberry PI Hat

With patience (over 6 months) my Draws Hat has finally arrived from NW Digital Radio. I also ordered a GPS mouse.

DRAWS is a platform with multiple components.

First, it is a Raspberry Pi HAT.  This is a purely hardware solution that puts several components that are useful for amateur radio projects on a single board; namely a high-performance sound chip (CODEC), a GPS with pulse per second (PPS) that includes an embedded battery backed real-time clock (RTC), and a 12VDC power circuit to power the onboard devices and the Raspberry Pi from a single power supply.  It has two mini DIN-6 audio sockets that match the ‘TNC’ specification found on many radios designed for amateur radio, an SMA connector for a powered GPS LNA antenna, power connection socket, and a small GPIO array for additional I/O.

Secondly, the DRAWS Workstation, which is the HAT plus an SD Card, Raspberry Pi, and an optional metal case, which creates a self-contained unit.  The Raspberry Pi provides the computing power for the workstation to run the drivers for the HAT components and applications to provide various functions.  Those functions are mostly in the realm of packet radio (Direwolf modem, AX.25, APRS, etc.), other digital modes (fldigi, WSJT-X, etc.), and digital voice (D-STAR, etc.), and ancillary utilities and applications such as a Stratum 1 timeserver, GPS location, and so forth.

Is there a prebuilt image for DRAWS?

Get the current beta at http://images.nwdigitalradio.com/downloads (current_beta.zip) and follow Getting Started

Starting with delivery of the DRAWS HAT, a downloadable image will be available to run the DRAWS workstation.  It will contain the current version of Raspbian (Stretch) including preloaded DRAWS HAT driver and a selection of applications that have been compiled for and tested on the DRAWS platform.

© http://nwdigitalradio.com/draws/

At the moment I use the Draws Hat for Aprs, because I am still busy trying out the possibilities of the Draws Hat. For this I use Direwolf and Yaac.