Direwolf <> AEA PK88

144.800Mhz @ 1200Baud (Test on 03-29-20 11:00 (rx only))

Today I did a reception test with the AEA PK88 and Direwolf. I must say that I am impressed with the PK88. This is the best test I have done so far. Now the conditions were not optimal, there is very little traffic at the time. So I will probably test it again at a busier time. Even now I let the reception run for half an hour.

So we missed 19 packets out of a total of 211 packtes from Direwolf. This compared to the tnc3s that missed 73 out of 219 packets from Direwolf.
Below again the TNC3s comparison with Direwolf.

It is nice to see that this AEA PK-88 performs so well after all these years and different owners.

The last week I save all the Aprs traffic I receive and post it on a blog. You might like to take a look there. https://pd9q.blogspot.com

News from the TARPN front.

I received a nice email from Tadd KA2DEW, there is a lot of development in the NinoTNC. Read the great news below.

We fixed the FTDI USB problem with the NinoTNC board by putting a USB-B socket on the PCB and a Microchip USB IC. This actually cut the parts cost by a few $. We’ll have the boards for sale on ETSY in April. Go to Etsy.com and search for TARPN. If the search doesn’t come up, then it isn’t listed yet. Our plan is to take orders in advance of shipping, and prime the pump with 200 boards ordering in early April with 3 weeks to get the boards into stock. At a time closer to ship time we’ll order programmed PIC CPUs with the latest firmware. When we get down to 50 or so in stock, we’ll order more. Because we’re running on out-of-pocket funding for the boards and CPUs, there may be some out-of-stock issues, but the price is right so hopefully people will smile and deal with it.

The new board is called the N9600A3. The last version was the A2, a black PCB with a 2-bit dip switch and the FTDI module on headers. The new board is the A3 blue PCB with USB B connector and a 4 bit dip switch. The new switches will be used to select more bit-rates. We’re not ready with anything new yet, but hopefully by the time the board ships? We’re likely to have 1200, 2400, 4800 and 9600 for FM and maybe some support for HF via SSB. Just like the A2 board, this one will come with IL2P Forward Error Correction mode which is a very efficient packet encoding providing Forward Error Correct in the same length packet as an AX.25 packet. (Full disclosure, as I understand it, packets with > 64 payload bytes will grow larger than AX.25 but small payloads result in shorter than AX.25 packets).

The NinoTNC A3 will come with a over-the-USB bootloader to update the firmware over USB, and we’ll be shipping a free Raspberry PI Raspbian application to boatload the TNC from a hex file. The hex file will be shipped for free one way or another. TARPN node ops will just do an UPDATEAPPS command on the TARPN scripts.

There is much software support to write for this which is not yet done. Our crack firmware and software teams are busy busy busy. Even though we’re not going to be ready with updated software in time we wanted to rush the A3 out there to solve the availability problem with the FTDIs. In addition we discovered that the tolerances for the Micro USB plugs and sockets are so bad that many people are breaking the FTDI modules plugging and unplugging. That’s not good. It’s easy to work-around but ugly. The A3’s USB-B connector is a much better deal.

See our news and info page starting at http://tarpn.net/d

Like before, we won’t be taking profit from this, and we’ll be selling the PCB + CPU for well under $10 on ETSY. Search on ETSY for TARPN. If it isn’t coming up, then we’re not ready to take pre-orders yet. It should be ready in early April. The news and info page will be updated when we get the store back up and when we have a clue about shipping this. We’ll also be posting a new A3 assembly link with access to the new bill of materials.

If you are interested in this, you should also sign up for the email reflector. http://tarpn.net/t/nino-tnc/email_reflectors.html

Tadd — KA2DEW

Direwolf <> Symek Tnc3s

144.800Mhz @ 1200Baud (Two tests one on 03-23 and one on 03-24 (rx only))

The first test I did was of course not entirely fair, different antennas were used and different transmitters/receivers. Now I made a setup with the same antenna and the same receiver, so with the same audio input.
First the setup, as a computer(if I haven’t lost it.some where) I use a Raspberry PI 2B+, as a sound card I use an Fe-Pi Audio Z V2. As a receiver I use a Realistic pro 2006. It is an old receiver but still works 100%. The antenna is a x50 from Diamond. Of course the Tnc3s from Symek, and Direwolf from John WB2OSZ. I use Kissutil from WB2OSZ, this allows me to connect to Direwolf and the Tnc3s as well as save the received Frames. This makes comparing easy/easier.

Now I have made two start files, one for Direwolf and one for the Tnc3s. I start these in different terminals. I do this manually, so there is a slight delay in starting up.

I start the scripts with the option “timeout” now I can specify the time how long the script runs.
Example. “timeout -s 9 1800 ./tnc3s.sh”
In this comparison, both scripts run for 30 minutes. 1800 Second. Now it is time for the comparison.

With the command “ls -A | wc -l” the number of files in the directory are counted. (Frames received.)

03-23-2020

03-24-2020

Here you can see the difference between the received frames of the Tnc3s and Direwolf. There is a difference of 73 and 125 missed frames from the Tnc3s. I tried something with the reception levels of the Tnc3s. It is To soft – Ok – To hard, there is little difference between To soft and Ok and To hard.

I did some tests with the amount of calls received. Just for fun.

The NEW… NinoTNC form TARPN

Tadd KA2DEW send me some great news. Thank you Tadd.

I`ve read that they were working on it, but that they were already that far …..

The sale will probably start at the end of January or the beginning of February.

TARPN is about to start selling its own TNC called NinoTNC. This is to be sold as a programmed CPU and PCB for $14 including shipping. They give you a BOM file and instructions to submit it to DigiKey for the rest of the parts. Costs about $25 including USPS shipping. Total cost is < $40. The NinoTNC is a USB KISS hardware/firmware TNC which looks like the TNC-PI, but isn’t a HAT. It is powered over USB and can connect to any USB equipped computer which supports a program to operate a KISS TNC. The NinoTNC has its own FEC mode useful for making dedicated point-to-point links.

Here some links with further information.

http://tarpn.net/d
http://tarpn.net/t/nino-tnc/n9600a/news-about-ninotnc9600A2—starting-field-tests.pdf
http://tarpn.net/t/nino-tnc/n9600a/n9600a_general_info.html

Kantronics Kam xl stops transmitting

I came across some interesting in the BPQ32 news group about a Kantronics TNC`s.
On 10 May 2018 I also posted about this on my website.

https://packet-radio.net/kantronics-kpc3-kiss-considered-harmful/

Ray N3HYM runs into the following problems.

  1. Replace an mfj tnc with a new kam xl dual port
  2. Dual port kam xl seems to stop transmitting after 2 days or less of use. Have to cycle the power button to get it back to transmitting . I do see bpq32 sending to the kam when the sta  light flashes.
  3. All cables have troids on them , power, serial, radio interface cable.
  4. Kam xl has been set to 19200 abaud rate to computer.
  5. Turned off all other transmitting equipment to try an eliminate rf getting into kam xl.
  6. Kam is exactly where mfj tnc was on the bench. Mfj tnc did not have any issues.
  7. Running Windows 7 with bpq32 and tnc’s in kiss mode.


Also Don N7HPX is running into this issue with the KPC3+

The issue you describe is nearly identical to the one I had for a while when using a Kantronics KPC3+ in KISS mode.
The fault problem I observed was consistent and repeatable.
While the TNC was in KISS mode and attached to a real serial port it would hang-up and not transmit.
This would seemly happen randomly, however, the observed external factor that most often caused it was receiving a faint packet burst that was just below the decode threshold.

You could hear the packet tones and the low signal level static. After the freeze-up and from the BPQ32 Terminal console, I could send a specific connect command to the KPC3+ and note that the STA light would flicker but it would never actually transmit as it normally would.
At that point I knew I was stuck, yet again, and needed to power cycle the TNC.

I would assume that the KAM XL and the KPC3+ probably have the same KISS software routines.

Matt Ackerman said…

I was working with Kantronics support on this issue and I seem to have solved it by shorting the RTS and CTS pins together within my serial cable. (PINS 4/5 on DB25 and PINS 7/8 on DB9)
I simply ran a jumper between the two. This appears to be an issue with how the APRS software and/or the AX.25 stack controls the RTS pin and shorting the RTS and CTS together prevents the software from holding the RTS pin low.
If the RTS pin is at low voltage the KPC3+ will start buffering and does not get caught back up.
I have been running mine for several weeks without showing this behavior again.
Before I made the change it would happen after about 12 hours.

Jean-Jacques ON7EQ has try the mod.

After applying the mod with RTS/CTS, both on TNC and PC side, now running systems one week completely in-sync !

So sure this is a mod to be considered!

By default, the KPC3+ is configured for software flow control. In particular, when operating as digipeater, it is very likely that in the datastream sent to the TNC, soon or later there are frames containing ‘flow control characters’ sent – what will start the buffering!

It is therefore essential to completely disable the software flow control, this can be done by giving following commands:

  • XFLOW OFF
  • START $00
  • STOP $00
  • TRF OFF
  • TXF OFF
  • CONO OFF
  • FLOW OFF
  • XON $00
  • XOFF $00



Kantronics KPC3+ KISS considered harmful

I was reading on the aprs.fi blog and came across some interesting things.

http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html

If you happen to have a Kantronics KPC-3+ TNC, please do not use it for your APRS igate. It appears to have a software bug which causes delays of over 10 minutes when receiving packets from the radio and then forwarding them to the computer, which then forwards them to the Internet (or possibly retransmits the old packets back to the radio channel, if digipeating).

This is a very bad thing to do, as the greatly delayed packets cause network overload and make moving vehicles jump back and forth between their current positions and the past positions. Looks very funny when aprs.fi tries to draw a track line between the received positions.

For years there have been anecdotal stories and suggestions about a possible problem. Yesterday Alan (radionerd1) has uploaded three videos to Youtube demonstrating the problem. This serves as a nice technical proof that the problem is real, and demonstrably a problem of the KPC-3+. There have been hints that the bug could be in UI-View32 (when using it with the KPC-3+), but Alan demonstrated the problem without involving UI-View.

Alan ran APRSIS32 on a computer, and connected it to two APRS receivers. One used a KPC-3+ and one used AGW packet engine (sound card packet decoder). At first, the two ports received the same packets at the same time. After about a week the KPC-3+ started to misbehave – the received packets were given to the computer only after they had been held as hostage for over 10 minutes. Some people have reported that it can go in this delaying mode within hours or days – it might be due to bad luck, or due to the amount of traffic received. The KPC-3+ did put out a KISS packet to the computer every time a packet was heard from the radio, but it was an old one. When the TNC was reset, it started performing well again.

My guess, as a programmer, would be that the KPC-3+ looses count of the packet it should be transmitting on the serial port. It receives a packet on the radio port, puts it in the received packets buffer, and then prints the wrong packet on the serial port. It might be the oldest packet in the buffer, or thereabouts. The amount of perceived delay would depend on the amount of traffic received in your area.

So, I repeat: If you have a KPC-3+ on your igate in KISS mode, please switch it to something else as soon as possible (KPC-3, OpenTracker, TinyTrak, TNC2 clones, whatever). If you wish to continue using it later, please contact Kantronics at [email protected] and ask them to fix the software bug.

It has been said that the problem only exists in KISS mode. So if you’re using the KPC-3+ as a stand-alone digipeater, it should be fine (in this respect). If you’re using it as a digipeater in KISS mode, with the digipeating happening on the computer (digipeating enabled in UI-View32 or APRSIS32), the effects are seriously bad, as you’re transmitting old packets on the radio channel.

Solution

I was working with Kantronics support on this issue and I seem to have solved it by shorting the RTS and CTS pins together within my serial cable. (PINS 4/5 on DB25 and PINS 7/8 on DB9) I simply ran a jumper between the two. This appears to be an issue with how the APRS software and/or the AX.25 stack controls the RTS pin and shorting the RTS and CTS together prevents the software from holding the RTS pin low. If the RTS pin is at low voltage the KPC3+ will start buffering and does not get caught back up. I have been running mine for several weeks without showing this behavior again. Before I made the change it would happen after about 12 hours.