AEA – Timewave Stuff

PK232 / PK232MBX Manuals and Firmware

Firmware HeatKit 232 (Tnx to Joshua (DO4FN))

Firmware PK232/PK232MBX

AEA PK-88

Firmware PK-88

AEA PK-90

AEA PK-96

Firmware PK-96

AEA PK-900

Firmware PK-900

AEA DSP2232

Firmware DSP2232

AEA DSP-232

 

 

NinoTNC Firmware

 

NinoTNC Firmware

4.06 is what is shipping from ETSY.  (we started shipping the “FAT” processor in January 2021)
3.06 is the same firmware (different RAM/buffer sizes) programmed into the 256 “thin” processor.  

We like .06 for stability and being ‘full’ featured.  

Nino is working on future firmware and he’s been improving things and breaking things. 
Up until now, no new features are added the the code, only clean-ups and improvements to functionality. 
For instance, 1200 baud AX.25 receive is better again than it was before, we think.
Also, there is a new firmware boot loader in the new firmware.  Nino also write a new Python boot loader and that is in the GitHub, zflash and tarpn scripting.

https://github.com/ninocarrillo/flashtnc

I am including the latest test versions, as well as the reliable .06, in the  “tarpn update” and in the zflash commands for people using Raspberry PI.  

In 3.07 / 4.07, Nino pulled apart the memory management, the way the different modes were separated in the program and the way certain timed features were called out.  .07 specifically tested the new memory and MODE-function calling and was definitely not working on all of the functions we had in 0.6.   

Now, several versions later, and many hours of testing and work on Nino’s part and some of the NCPACKET network people’s part, .14 is much better than .07.  However….

3.14 and 4.14 are test versions.   .14 may not be ready for prime time!  There still may be untested features missing or broken in .14 that were working in .06.  

So far we have had no trouble using the boot loader to move back and forth from 3.06 and 4.06 to the new stuff.  

All of the NinoTNC firmware (since 2.81 in October 2020) works in A2, A3 and A4 NinoTNCs.  

Beware that versions 2.90 through 3.05 should not be put on your NinoTNC because the boot loader support in those versions can get you stuck, requiring a PIC-KIT to refresh the chip.   

See the change log for details:
http://tarpn.net/t/nino-tnc/n9600a/n9600a_history.html#changelog

This is how the update process looks like.

pi@pi1lap:~/tarpnflash $ python3 flashtnc.py /home/pi/flashtnc/N9600A-v4-0-6.hex /dev/ttyACM0
Opened port /dev/ttyACM0
Scanning hex file to determine target chip.
Hex file target: dsPIC33EP512GP
Opened file /home/pi/flashtnc/N9600A-v4-0-6.hex
Flushing serial buffer.
Starting TNC reflash mode. Don't interrupt this process, the dsPIC may brick.
Flushing serial buffer again.
TNC successfully entered bootloader mode.
TNC bootlader version:  B
TNC ready for hex file, starting transfer. This will take a few minutes.
Start time:  09:17:38
Lines written:  1000
Lines written:  2000
(snip)
Lines written:  10000
Lines written:  11000
Lines written:  12000
End time:  09:19:49
Line count:  12791
Firmware update successful.

A test Packet

08:28:02R N9600A-3>IDENT Port=1 :
:Test Packet=FirmwareVr:4.06=SerialNmbr:=UptimeMilS:00077666=BrdSwchMod:04060002=AX25RxPkts:00000003=IL2PRxPkts:00000000=IL2PRxUnCr:00000000=TxPktCount:00000114=PreamblCnt:0000001E=LoopCycles:00532CD0
08:27:49R N9600A-3>IDENT Port=1 :
:Test Packet

Direwolf Vs QtSoundModem (part 2)

Rx Only

Okay, that was a bit of a disappointment. I ran the test at 14.1022Mhz on 300 Baud. I think the conditions were very bad in those 24 hours.

For the test I use Kissutil.

https://www.mankier.com/1/kissutil

kissutil  can be used interactively for troubleshooting a KISS TNC. It is usable with direwolf and other generic KISS TNCs connected to a serial port. It can also be used as an application interface where each side places files in a directory for the other to process.

First I wrote two start files for the test.

Direwolf.sh

#!/bin/bash
cd /home/niels/testbed/
./kiss-direwolf -p 8009 -o /home/niels/testbed/rec-direwolf

Qtsm.sh

#!/bin/bash
cd /home/niels/testbed/
./kiss-qtsm -p 8105 -o /home/niels/testbed/rec-qtsm

The test ran for 24 hours, which is 86400 seconds.

timeout -s 9 86400 ./qtsm.sh

After 24 hours I can start counting the received frames.

As you can see this is very disappointing. Now I understand that the focus of QtSoundModem is more in the HF area. With a difference of 4 frames, the difference between Direwolf and QtSoundModem is minimal. In fact, too few frames were received in the 24 hours to make a good comparison. Is my opinion.

The next test we will try on 144.800Mhz the local Aprs frequency.

Direwolf Vs QtSoundModem (part 1)

This is about RX and not TX.

This has caused some headaches. I want to use one trx and one antenna for this test. (Icom 7300 and a Hyendfed)Now the problem is that Direwolf and QtSoundModem both use the sound card. Now you can’t both use the same sound card at the same time. So we will have to use two virtual sound cards and route the audio to these sound cards.  For this I use “pactl” with this I can manipulate the PulseAudio server.

pactl load-module module-virtual-sink sink_name=direwolf
And
pactl load-module module-virtual-sink sink_name=qtsoundmodem

Actually we are making a virtual audio card for Direwolf and QtSoundModem. Now we need to route the Audio from the input to the virtual audio card. This is possible with PavuControl.

Setup Direwolf

ADEVICE pulse
ACHANNELS 1
CHANNEL 0
MYCALL N0CALL
MODEM 300 1000 1200
AGWPORT 8008
KISSPORT 8009

Uhmmmmm port 8001.  I don’t understand that yet, in the config it really is port 8009.

Setup QtSoundModem

 

Now I haven’t fully read up on PulseAudio and pactl and the virtual cable/cards. Perhaps my wording and references are not quite correct.

Now I have the opportunity to test…..

Kantronics KPC4

Today I have been working on a Kantronics KPC4 which I bought from PD4R. I am very happy that I can add it to the collection.

Kantronics KAM_KPC-1-2-4-2400_Installation Manual
Kantronics KAM_KPC-1-2-4-2400_Operations Manual

Kantronics KPC4 Firmware

The nice thing is that such modems can also be accessed from BPQ32. Here is a small example.

PORT
 ID=Serial TNC KPC4
 COMPORT=/dev/ttyUSB1
 SPEED=9600
 DRIVER=SERIAL
 QUALITY=0
 PORTCALL=PI1LAP
ENDPORT

PointoPoint link between two Ninotnc`s

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
cd tncattach

# Make program
make

# Install to system
sudo make install

The next thing I did was setting up a pointopoint link. But first attach the modem.

sudo tncattach /dev/ttyACM0 57600 -d --noipv6 --noup --mtu 329
sudo ifconfig tnc0 10.0.0.1 pointopoint 10.0.0.2

The second Ninotnc n9600A3 I have connected to my rpi 3

sudo tncattach /dev/ttyACM0 57600 -d --noipv6 --noup --mtu 329 
sudo ifconfig tnc0 10.0.0.2 pointopoint 10.0.0.1

I made a short video of how it works.

That was Fun….

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+

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
./tarpnflashinstaller.sh

Run
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.

[0]N9600A3>IDENT::TestPacket=FirmwareVr:2.81=SerialNmbr<0x00<0x00<0x00<0x00<0x00<0x00<0x00>0x00>=UptimeMilS:0007C5F2=BrdSwchMod:02060002=AX25RxPkts:0000001B=IL2PRxPkts:00000000=IL2PRxUnCr:00000000=TxPktCount:0000000A=PreamblCnt:0000001D=LoopCycles:006CD389