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”

 

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.

New Soundmodem version is available UZ7HO

New Soundmodem version is available: http://uz7.ho.ua/packetradio.htm

SoundModem v1.00b changes:
– Added “DW QPSK 2400bd” and “DW 8PSK 4800bd” Direwolf compatible modes.
The carrier frequency must be “1800Hz” (for a full compatibility with Direwolf).

http://uz7.ho.ua/modem_beta/CHANGELOG.txt

http://uz7.ho.ua/modem_beta/user_guide_v045b_EN.pdf

Get the version V1.00b http://uz7.ho.ua/modem_beta/soundmodem100.zip

Direwolf to LinBPQ configuration and parms

John WQ6N has found a solution for direwolf and Linbpq that works very well for HF.

Direwolf.conf

bpq32.cfg

 

Direwolf and Jnos (review)

In the previous post about Direwolf and jnos i use Direwolf-1.3 and does not know about the SERIALKISS port.
John WQ6N point it out to me… Tnx John WQ6N. Nice one.
Read the previous post.
So maybe I wrote that script for nothing. This is working pretty simple 🙂

In Direwolf 1.5-beta is it possible to use SERIALKISS to connect com to com.
I have try to use a PTY pair created with socat.

I use conspy to look at the output of Direwolf. apt-get install conspy
Use it just like this “conspy 3” The number 3 stands for the tty were Direwolf is running on /dev/tty3.
Hit the escape button a couple of times to exit.

Here is the output of Direwolf

Ok that is working quit well.
I start Direwolf with the option “-d kn” So you can look at the kiss communication between Direwolf and Jnos.

Some text out of the User-Guide.pdf.
“Up to 3 concurrent TCP KISS client applications are allowed at the same time.
You can raise this limit by increasing the value of MAX_NET_CLIENTS, in source file kissnet.c and recompiling.”

Whoooo thats nice up to 3 (and more) applications can connect to Direwolf on the KISSPORT.
And there is also the AGW and the SERIALKISS port. Men where do I start.

John WQ6N

John WQ6N has found something that is useful. He use a Legacy BSD pseudo pair.
There are no Legacy BSD pseudo pairs in Linux any more. But it is possible to create some.

After editing the grub file run the command “update-grub” and reboot.

So now it`s time to set Direwolf and Jnos to use the pty Legacy devices.