Uronode nodesearch 2.2 released

Brian N1URO has released a new version of Nodesearch 2.2

Change is that now users can search a netrom node
by alias. This idea was taken from a recent change in JNOS. Ex:

Which node are you looking for (no * please): NOS
Searching NetRom nodes for NOS …
CTJNOS:N1URO-7    DZINOS:SV1DZI-12  INNOS:N9LYA-5     MFNOS:N1URO-14
NodeSearch v2.2 by N1URO for URONode.
Goodbye.

For now it’s only on the ftp server of N1URO

ftp://n1uro.no-ip.org/pub/hamradio/packet/node-plugins/

LinBPQ with Winmor port.

With the help of the config file of Jerry, N9LYA and some help from John, G8BPQ I have setup a Winmor port on my Linbpq.I use a Microham USB II as soundcard device connected to my Windows PC and a direct Cat kabel from my Linux PC to control the TRX.

Here is the section for the Winmor port. (BPQ32.CFG)

WINMOR TNC.ini

Winmor Status screen from Linbpq

Winmor

Tnx for the help Jerry and John.

Complex BPQ32.cfg from N9LYA

N9LYA has setup a complex system using multi modes and multi ports. Using Packet 1k2 and 9k6, Hf Packet 300Baud, Robust packet, Winmor, Pactor, Fldigi, Axip, Telnet.

http://www.n9lya.com/

 

Remote Packet Station

I’m busy building a remote packet station.

  1. Airgrid AG-HP-5G23 For remote control the Pi 5Ghz Point to Point
  2. USB DC-DC step down module 4,5V-40V to 5 Volt 2A USB – Power for the Pi
  3. W1401 12V Digital Thermostat Temperature Controller Switch Module NTC Sensor
  4. Power supply Mean Well (150W, 12V,12.5A)
  5. 3x Fan 80x80x25 mm 12 volt
  6. Raspberry Pi 2
  7. 3D Sound card
  8. 2x Ground loop isolater
  9. Trx President Lincoln 2
  10. Antenna  Siro tornado 27 5/8
  11. 10Mtr EcoFlex 15

Connect the Pi to the Trx

DireWolf and Linpq with Systemd.

I have a bad time behind me, I have had a lot of arguments with Systemd to start DireWolf and Linpq when booting 🙂
If you like Systemd, you can read some about it here https://en.wikipedia.org/wiki/Systemd

I want Linbpq to run under /dev/tty2 and DireWolf under /dev/tty3. This is because if I login remotely I can view the monitor from DireWolf with “conspy”. “conspy 3” Hit esc a few times to leave conspy.

Systemd does not want to accept the start line with >/dev/tty3 &

This upper start line does not work.

So I had to come up with something else for that. So i wrote a start file. “direwolf.start”

Now i wrote a unit file to start DireWolf on boot.
/etc/systemd/system/direwolf.service

Now DireWolf is starting very nice on /dev/tty3

I had the same problem with Linbpq, which I solved in the same way.

Linbpq start file “runbpq”

The unit file “linbpq.service”

Ok, let’s see if it is running

Now have a look at /dev/tty2 “conspy 2”

 

SCS Tracker TNC and new BPQ32 Node

Sample config file based on a system off John, kx4o.

Jeff have made some comments about it.

 

Uronode update version 2.9

Brian N1URO has released uronode-2.9 on 2018-05-28

Download add https://sourceforge.net/projects/uronode/files/?source=navbar

 

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 service@kantronics.com 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.