Systemd RestartSec/StartLimitInterval/StartLimitIntervalSec

Systemd

The default delay between executions is 100ms (RestartSec) which causes the rate limit to be reached very fast.

Just using Restart and RestartSec is not enough: systemd services have start rate limiting enabled by default. If service is started more than StartLimitBurst times in StartLimitInterval/StartLimitIntervalSec seconds is it not permitted to start any more.

Add RestartSec=5 in the service section
Add StartLimitInterval=0 in the unit section

[Unit]
Description=Linbpq
After=network.target
StartLimitInterval=0

[Service]
Type=simple
Restart=always
RestartSec=5
ExecStart=/bin/bash /home/pd9q/linbpq/runbpq
WorkingDirectory=/home/pd9q/linbpq

[Install]
WantedBy=multi-user.target
Alias=linbpq.service

Run

systemctl daemon-reload

 

 

RMSGateway New version

There is a new version of RMSGateway. This is at the moment in Beta test. See the mail of Basil N7NIX.
If you like to test the new code. Just mail N7NIX. basil (@) pacabunga.com

 

The new code (version 2.5.0) has been running on a few machines for the
last couple of days. I would like to get a few more sites to try out the
new code before it is released.

If you would like to help please contact me directly & I will give you
instructions on how to install the new code. Only the python scripts &
xml files changed to support the latest Winlink Web Services.

Thanks,
/Basil n7nix

Looking for Constibutor / Author

For the website I am looking for people who want to write and post something on the site. They can be configuration examples, an explanation of how you did something. Updates from packet software. And so on. Are there people who feel like it please let me know via the contact form or via e-mail. pd9q (@) packet-radio.net. Thanks.

O Yes, it`s a hobby, so there is no cash ūüôā

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)

PORT
 PORTNUM=2
 ID=HF WINMOR
 TYPE=EXTERNAL
 PROTOCOL=WINMOR
 DLLNAME=WINMOR.DLL
; INTERLOCK=6
 QUALITY=0

CONFIG

ADDR 192.168.1.145 18500 PTT CAT PATH REMOTE:C:\WINMOR\WINMOR TNC.EXE
RIGCONTROL
/dev/ttyUSB0 4800 Yaesu FT100
7,7.050,USB,W2
7,14.110,USB,W2
****
WL2KREPORT PUBLIC, api.winlink.org, 80, PI1LAP-10, JO11VN, 00-23, 7051500, WINMOR1600, 25, 50, 0, 360
WL2KREPORT PUBLIC, api.winlink.org, 80, PI1LAP-10, JO11VN, 00-23, 14111500, WINMOR1600, 25, 50, 0,360
WL2KREPORT PUBLIC, api.winlink.org, 80, PI1LAP-10, JO11VN, 00-23, 430950000, PKT9600, 10, 60, 9, 0
WL2KREPORT PUBLIC, api.winlink.org, 80, PI1lAP-10, JO11VN, 00-23, 144850000, PKT1200, 10, 60, 9, 0
CWID TRUE
DEBUGLOG True
BW 1600
DRIVELEVEL 100
MODE AUTO
ROBUST False
SHOW True
BUSYLOCK False
BUSYHOLD 5
BUSYWAIT 12

ENDPORT

WINMOR TNC.ini

[WINMOR TNC Form]
ResponseDelay=300
LeaderExtension=0
Disable=False
Waterfall=True
Spectrum=False
Top=22
Left=22
MyCallsign=PI1LAP-10
Registration=
TCP Control Port=8500
MyGridsquare=JO11VN
StartMinimized=False
DebugLog=True
CommandTrace=False
CaptureDevice=Lijningang (High Definition Audio-apparaat)-61
PlaybackDevice=Luidsprekers (High Definition Audio-apparaat)-e9
TCP Address=192.168.1.145

Winmor Status screen from Linbpq

Winmor

Tnx for the help Jerry and John.

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

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