This indicates issue of transfer of data from dongle to Pi. Possible causes of intermittent failure may be due to intermittent connection failure caused by:
An intermittent failure is harder to troubleshoot than a persistant failure.
I’ve now swapped out the Pi, the PoE splitter and the dongle.
I took out the microSD card,V3 dongle and the Pi4 and swapped it to a PiZer2W with a old generic dongle.
The PiZero2W and dongle have been running Piaware for months without a problem.
The Pi4 and V3 dongle are now running the Piaware microSD.
It will be interesting to see if the problem moved with the Pi and dongle.
Just checking the frequency PPM offset for the generic dongle.
S
Good luck
Swaping microSD card to another set of hardware (another Pi + another power supply + another dongle) is the best way to find if the cause of failure is hardware or software.
Did that and it has now been running for 48 hours without a glitch.
The Pi4, V3 dongle and PoE splitter have been running Piaware for 48 hours also without a glitch
Stability has returned and the problem has gone away but I have no idea what it was. Undoubtedly, it will come back and bite me on the bum when I least expect it.
I’ll have to contemplate a better antenna now.
S
Deserves to be placed in a new thread:
Who has the longest PiAware AIS streak contest? 
Unfortunately this is lost at reboot. Yesterday my figure was about 60 hrs when I rebooted on reboot it got reset to 0. Now it is showing this:
The developer is working towards providing an option for persistent statistics.
Issue following commands. The AIS-Dispatcher will stop, and will not automatically start after reboots:
sudo loginctl terminate-user ais
sudo loginctl disable-linger ais
sudo reboot
If you want to enable it again, use following commands:
sudo loginctl enable-linger ais
sudo reboot
The AIS-Dispatcher uses loginctl instead of systemctl.
Following are commands to enable and disable the Apps controlled by loginctl
(The [USER] for AIS-Dispatcher is “ais”)
To enable: sudo loginctl enable-linger [USER]
To disable: sudo loginctl disable-linger [USER]
To kill all processes run by user: sudo loginctl terminate-user [USER]
The uptime has now been 4 days and it has remained stable on the Pizero2W
and of course Piaware running on the Pi4 with the V3 dongle hasn’t missed a beat in 4 days either.
In the meantime, I am somewhat perplexed that I have two shipXplorer accounts fed from the same instance of AIS-catcher with very different stats over the last 4 days.
Something seems not quite right but I can’t decide if it is here or ShipXplorer.
S.
Great
Looking at history of erronous behaviour of Radarbox24 AND ShipXplorer web plots of feeders, I am pretty sure it is the ShipXplorer Servers causing this behaviour.
That’s the main reason I stopped sending data to shipxplorer, as the reliability has gone well downhill recently.
Hi Guys, apologies if I’m intruding. I’ve been reading the posts with interest and must say big thanks to ABCD for the usual detailed diagrams and commands.
I have a station at one location running a Pi and rtl-dongle with an uputronics ais preamp.
I had tried the shipxplorer dongle on its own with dismal results, also tried it with the preamp and even bought another dongle incase I had a DUD. I guess it’s all down to locations and the usual rules of thumb as there are good reports with these sx dongles elsewhere.
At station 2 at the girlfriends house I have several devices an SDRplay rsp1a which I stole from my Icom 7300(panadapter) while I experimented with Jasper’s decoder.
I also have just learned how to use raw data from Comar R400N USB data with AIS-catcher. Additionally I have a Comar R500NGI with the GPS shenanigans which has the same AIS receiver (as a Pi Hat on top of the pi gpio) as the R400N and most other Comar devices
But truth be told the rtl-sdr station beats my other devices I’ve tried so far due to the RF gain being able to be turned up.
I also see many disconnections to shipxplorer despite my connection remaining to other sites. I’ve put it down to them apparently new kids on the block with the sx server side if things?
Anyway wishing you all a happy new year.
Hello @adsbgreenock I have 2 AIS PI’s running side by side on vessel finder as a comparison to test the effectiveness of an LNA in my area
B-ker_1 with LNA & Filter
B-ker_2 without
Both have the exact same cable length going into each dongle fed from the same home brew antenna & have the appropriate ppm correction made in ais catcher config file.
Between the 2, the one with the amp, that I have seen anyway, only gets around 2-4 more vessels at any given time. The majority of the time they see the same amount. So alot is to do with the location. Im currently 19.7nm from the nearest shore line and only get max range around 38nm
Hi @Jonseyt23
That’s interesting I did try the homebrew one found here:
N Arundales Hi Gain AIS Antenna
I built this from Messi and Paoloni ultraflex 7 as opposed to the RG58 and had amazing results. However I am in a really windy location and the tube I had the elements inside snapped during 80mph gusts.
Just now I am using a Diamond X30 which you may know is a 2m/70cm dual band ham antenna while I can find a replacement and also find the courage to get back up on the roof. This antenna also works surprisingly well and I use this split for marine audio comms.
It is something else to mess about with and now we have a great decoder to use (AIS-catcher) which is a breath of fresh air for the hobby.
Two stations both have requested that my two different stations one 110m AMSL, one 138 AMSL be sent to same udp port.
Kind Regards
I just made a flowerpot antenna out of RG6 cable. But currently you have a ship in Japan on your station. Unless that’s Yr 2nd station.
Vessel finder were quite OK with setting a 2nd one up for testing though.
The only quirk I have with vessel finder is anyone can send shipdata to anyone’s Station if they felt the need as the station port is listed on the page, whether that’s a downside I don’t know.
Hi there,
I noticed this earlier and haven’t a clue what’s happening. Sometimes with tropospheric ducting maybe a couple hundred miles isn’t rare for faraway ships in the right conditions but a ship showing on Japan must be a network thing at VF server side.
I do share a feed to Australia Amateur Radio (Sarcnet) club but again, I doubt this would cause this.
Thanks for letting me know.
Regards
/usr/share/aiscatcher/aiscatcher.conf /usr/share/aiscatcher/aiscatcher.conf.old
If you want, you can replace default config file by your saved config file using following commands:
cd /usr/share/aiscatcher
sudo cp aiscatcher.conf.old aiscatcher.conf
sudo systemctl restart aiscatcher
Click on Screenshot to See Larger Size
After about 6 days AIS-catcher crashed and didn’t restart.
sudo systemctl status aiscatcher still resulted in buffer overrun messages but all seemed OK after a reboot.
pi@AIS:/usr/share/aiscatcher $ sudo systemctl status aiscatcher
● aiscatcher.service - AIS-catcher
Loaded: loaded (/lib/systemd/system/aiscatcher.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Fri 2023-01-06 18:49:53 AEDT; 3h 53min ago
Process: 1177 ExecStart=/bin/bash /usr/share/aiscatcher/start-ais.sh (code=exited, status=0/SUCCESS)
Main PID: 1177 (code=exited, status=0/SUCCESS)
CPU: 2d 11min 7.097s
Jan 06 18:52:28 AIS aiscatcher[1178]: RTLSDR: buffer overrun.
Jan 06 18:52:28 AIS aiscatcher[1178]: RTLSDR: buffer overrun.
Jan 06 18:52:28 AIS aiscatcher[1178]: RTLSDR: buffer overrun.
Jan 06 18:52:28 AIS aiscatcher[1178]: RTLSDR: buffer overrun.
Jan 06 18:52:28 AIS aiscatcher[1178]: RTLSDR: buffer overrun.
Jan 06 18:52:28 AIS aiscatcher[1178]: RTLSDR: buffer overrun.
Jan 06 18:52:28 AIS aiscatcher[1178]: RTLSDR: buffer overrun.
Jan 06 18:52:28 AIS aiscatcher[1178]: RTLSDR: buffer overrun.
Jan 06 18:52:28 AIS aiscatcher[1178]: RTLSDR: buffer overrun.
Jan 06 18:52:42 AIS aiscatcher[1178]: RTLSDR: buffer overrun.
pi@AIS:/usr/share/aiscatcher $
S.
This seems hardware (dongle) problem
There was a commit in v0.40 to add an option for RTL-SDR buffer count. It sounds like something that could help you, but there is no mention of it on the README so I don’t know any details. All I can say is the default is 2 as it shows up in my syslog when starting up.
Dec 30 18:11:51 HP-TUNN AIS-catcher[865]: Device : RTL2838UHIDIR
Dec 30 18:11:51 HP-TUNN AIS-catcher[865]: Settings : rate 2304K bw 15K format CU8 tuner 49.599998 rtlagc ON biastee OFF buffer_count 2
Dec 30 18:11:51 HP-TUNN AIS-catcher[865]: Model #0 : [AIS engine v0.42] ps_ema ON afc_wide OFF droop ON fp_ds OFF
You could contact Jasper on GitHub and ask how it works and if it pertains to your issue. He is very good at responding.
abcd@debian11:~$ sudo grep aiscatcher /var/log/syslog | grep 'Settings\|Device\|Model'
Jan 7 01:56:24 debian11 aiscatcher[3240]: Device : RTL2838UHIDIR
Jan 7 01:56:24 debian11 aiscatcher[3240]: Settings : rate 2304K format CU8 tuner 49.599998 rtlagc OFF biastee OFF buffer_count 2
Jan 7 01:56:24 debian11 aiscatcher[3240]: Model #0 : [AIS engine v0.42] ps_ema ON afc_wide OFF droop ON fp_ds OFF
abcd@debian11:~$