Yesterday I added 2 HF ports to my Bpq32 Node / BBS. I have chosen to use QtSoundModem and Hamlib. QtSoundModem is a Linux port or Soundmodem from UZ7HO. I use Hamlib/rigctld to take control of the Tranceiver. QtSoundmodem and Hamlib run on a different Raspberry than the BBS and Node.
After some testing I found out that I need Hamlib version 3.3 to control the icom 7300. The versions 4.0 and 4.1 do not work for me. Apparently the icom 7300 is not being initialized. Can’t actually find out why this is. With the command “rigctld -l” you get a list of which tranceivers are supported.
ADDR 126.96.36.199 8101 ; AGW port of QtSoundModem
ADDR 188.8.131.52 8101 ; AGW port of QtSoundModem
With Hamlib it is also possible to control the TRX from Bpq32. I immediately added a Robust 300 packet port to Bpq32 with rig control. Here is an example.
ID=Robust 300 ;(RPR Packet)
WL2KREPORT PUBLIC, api.winlink.org, 80, PI8LAP-10, JO11VN, 00-23, 14102200, ROBUST, 25, 35, 3
WL2KREPORT PUBLIC, api.winlink.org, 80, PI8LAP-10, JO11VN, 00-23, 14102200, PKT300, 25, 35, 3
WL2KREPORT PUBLIC, api.winlink.org, 80, PI8LAP-10, JO11VN, 00-23, 144850000, PKT1200, 10, 20, 5, 0
WL2KREPORT PUBLIC, api.winlink.org, 80, PI8LAP-10, JO11VN, 00-23, 430950000, PKT9600, 10, 20, 5, 0
O 4 ; MAXFRAME
F 190 ; FRACK
T 8 ; TX Delay
USEAPPLCALLS ; Accept connects to all APPLCALLS
BEACONAFTERSESSION ; Beacon after session
%L 1500 ; Centre Freq for Normal Packet (Default is 1500)
@I 64 ; Paclen = 60
%T 1 ; TX Autotracking 1 = on
Apr 4 16:34:41 pi1lap : Initialising Port 01 TCPKISS IP 127.0.0.1 Port 8001 Chan A
Apr 4 16:34:41 pi1lap : Initialising Port 02 TCPKISS IP 127.0.0.1 Port 8001 Chan B
Apr 4 16:34:41 pi1lap : Initialising Port 03 SCSTRK /dev/ttyUSB0
Apr 4 16:34:41 pi1lap : Initialising Port 04 UZ7HO Host 184.108.40.206 Port 8101 Chan A
Apr 4 16:34:41 pi1lap : Initialising Port 05 UZ7HO Host 220.127.116.11 Port 8101 Chan B
Apr 4 16:34:41 pi1lap : Initialising Port 06 ASYNC /dev/ttyUSB1 Chan A
Today I am playing with tncattach, I thought it would be fun to test this with the Ninotnc`s.
I have connect the first Ninotnc n9600A4 to my rpi 4 and install “tncattach” on it. The TNCs are connected with each other by means of a short cable. Cross cable. The tnc are running 9600Baud
TNC1 TNC2 RX TX TX RX
# If you don't already have a compiler installed
sudo apt install build-essential
# Clone repository from GitHub
git clone https://github.com/markqvist/tncattach.git
# Move into source directory
# Make program
# Install to system
sudo make install
The next thing I did was setting up a pointopoint link. But first attach the modem.
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+
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”
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 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.
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.
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
chmod +x tarpnflashinstaller.sh
* 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.
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.
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.
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.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.