Are you using anything-sync daemon? If so then it may not have recovered properly from the reset. It keeps backups of these in the same directory as the directory being mirrored, so if mirroring /var/lib/collectd, you will see a hidden directory /var/lib/.collectd- or similar. Make sure you stop collectd first, then copy the most recent dated saved directory back to /var/lib/collectd, and then restart collectd. It should then have whatever data up to the point asd last saved a copy. I’ve had this happen before if there was an unexpected power outage or reset, but have usually been able to recover it like this. I also make a copy of the collectd data folder to a different machine once per day as a further backup.
I did what I thought was a proper shutdown.
sudo shutdown -h now
-then powered off the PI
-inserted the new FA Dongle
-and re-powered the PI
There are no /var/lib/.collectd- folders
Here is the directory listing of /var/lib/collectd/rrd/localhost/dump1090-rpi
4 drwxr-xr-x 2 root root 4096 Sep 10 2015 .
4 drwxr-xr-x 5 root root 4096 Jun 29 2015 …
304 -rw-r–r-- 1 root root 307516 Apr 13 17:47 dump1090_aircraft-recent.rrd
152 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_cpu-background.rrd
152 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_cpu-demod.rrd
152 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_cpu-reader.rrd
156 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_dbfs-noise.rrd
156 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_dbfs-peak_signal.rrd
156 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_dbfs-signal.rrd
156 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_messages-local_accepted_0.rrd
156 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_messages-local_accepted_1.rrd
156 -rw-r–r-- 1 root root 154692 Sep 10 2015 dump1090_messages-local_accepted_2.rrd
156 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_messages-local_accepted.rrd
152 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_messages-positions.rrd
156 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_messages-remote_accepted_0.rrd
156 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_messages-remote_accepted_1.rrd
152 -rw-r–r-- 1 root root 154692 Sep 10 2015 dump1090_messages-remote_accepted_2.rrd
156 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_messages-remote_accepted.rrd
156 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_messages-strong_signals.rrd
156 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_mlat-recent.rrd
152 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_range-max_range.rrd
152 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_tracks-all.rrd
152 -rw-r–r-- 1 root root 154692 Apr 13 17:47 dump1090_tracks-single_message.rrd
Are you using anything sync daemon? If not then you shouldn’t expect to see those folders. They are usually hidden though, so use “ls -lah” to see if they are there.
If you aren’t using it then it’s possible that the rrd files became corrupt somehow. Collectd seems to be a bit sensitive to it, and I don’t know if there is any realistic way to recover the data. It might be possible to use rrdtool to read out the data into knew rrds, but I’m not sure exactly what commands would be needed.
OK, I do not know what you mean by sync daemon. I tried the ls -lah command in the /var/lib folder and the only thing in there collectd.
For laughs I tried another reboot using the FA control panel ‘reboot device’ command, and the same thing happen again, all data prior to the reboot has vanished.
Anything sync daemon is a service that caches writes in RAM to reduce wear on the SD card. If you haven’t set it up, then you won’t see any extra folders as it’s not enabled by default.
It would appear that the rrd files are being corrupted during the reboot for some reason. Perhaps collectd is not shutting down cleanly - is there anything in the system journal for it?
Sorry again, but I do not know what you mean by system journal. dmesg?
Assuming you are using a Jessie based installation then the main system log is kept by systemd. You can read it by doing:
sudo journalctl
but that will be rather long, since it will be absolutely everything.
To see the log from today, do
sudo journalctl --since today
To see the log since the last reboot:
sudo journalctl -b
You can also filter by a particular service, so to see output from collectd today do:
sudo journalctl --since today -u collectd.service
Not jessie, its debian and the journalctl command does not function.
My other two system are not doing this, wipe the data, on a reboot. So it might be time for a SD card rebuild or a reload from backup image at least.
jessie is a particular release of Debian.
see the contents of /etc/os-release for what you’re running.
Thank you, I’d say is Wheezy then…
PRETTY_NAME=“Raspbian GNU/Linux 7 (wheezy)”
NAME=“Raspbian GNU/Linux”
VERSION_ID=“7”
VERSION=“7 (wheezy)”
ID=raspbian
ID_LIKE=debian
ANSI_COLOR=“1;31”
HOME_URL=“http://www.raspbian.org/”
SUPPORT_URL=“RaspbianForums - Raspbian”
BUG_REPORT_URL=“RaspbianBugs - Raspbian”
I have the same problem here with a Pi using Jessie. I tried to install collectd via the usual scripts. It works but every file installed gets removed when I reboot.
I’m thinking of a SD-card issue, tried to order a fsck on reboot (I’m distant from the pi). But it doesn’t seem to have given any better result. I have to dig further.
Major reception improvement. 8 bay homemade co linear antenna with filter and prostick at antenna fed by 50’ active usb cable. Happy!
I received my Flightaware filter + Pro Stick from the ebay vendor and installed it last evening. It replaced a NooElec NESDR Mini 2+ TCXO + satellite TV amp. Initial results look promising but the system is in my attic and my roof has black shingles. Per my attic temperature sensor (DHT22E being sampled by the RPi), I had a temperature swing of from ~40F to ~105F yesterday, and we’re not even into the summer heat yet. Hence the TCXO in the NooElec was a great solution.
My strategy was going to be run kalibrate and determine the PPM offset when it was at some average temperature, say 85*F to get through the summer. Will kal work against GSM850 with the Pro Stick if I remove the Flightaware filter? Does anyone have any better ideas on optimizing the performance?
EDIT: kal works fine on the Pro Stick with no filter. With attic temperature at about 95F, the Pro Stick was running 124F and averaged around -21 PPM. RPi3 case is 109F and CPU temperature is 147F as reported internally. A couple of FLIR pics for the record:http://imgur.com/a/IE5TM
well I have ran into a problem using the new FA Pro stick. Every once in a while I see an anomaly regarding server synchronization
this started when I got the FA Prostick.
I am using a flightaware antenna with the flightaware filter and the flightaware Pro Stick.
after receiving an email from the developers stating that during heavy traffic times most of the cpu is being used to transmit data and does not have the capacity to continually update the time since the time is being updated over the network.
So I bought the raspberry Pi 3 and set it up using the latest Jessie version also I have super fast internet via cable here.
after all that it still happens !.. Also I see what looks like data creep???
i can see the flights in the data window on the right of the screen then sometime I see it expand with a whole lot of ICAO numbers but no flight or squawk or altitude… then it will settle down and go back to normal.
then to try something different I use a RTL-SDR stick with a TCXO and heat sink and all these problems disappear !!! and runs normal !!!
any Ideas or help ???
thanks
Howard
Sounds like the dongle’s USB connection is resetting. Are you using a USB extension cable?
if you SSH into the pi and run “dmesg -t” you can see logs that will let you know if the dongle is disconnecting and reconnecting.
Every time the dongle connects there will be an entry something like this
usb 1-1.5.3: New USB device found, idVendor=0bda, idProduct=2838
usb 1-1.5.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.5.3: Product: RTL2838UFA
usb 1-1.5.3: Manufacturer: Realtek
If you see that repeatedly and not just around bootup, then this is the problem. My suggestion if that’s the case is to connect the dongle through a powered hub.
ProStick gain optimization test
My setup: Moonraker collinear (6.5dBd supposedly, should be comparable to FA antenna) in attic, 50cm N-sma pigtail, FA filter
I have been running my ProStick with gain=45 (44.5), which seems good when looking at graphs of noise, single track count, and average signal strength. But this depends a lot on me eyeballing data that can vary a lot from day to day.
I wanted to try gain-scanning mentioned on the dump1090-mutability enhancement list, so I wrote a little script to start dump1090 at different gains, log messages for 15 seconds at each gain, and repeat 10 times.
With the RTLSDRblog R820T2 dongle, it’s quite obvious that higher gain gives me better performance:
With the ProStick, there is no clear winner:
Are we overdriving it? Let’s try even lower! Only below a gain of about 30 do I start seeing consistently poorer message rate.
Since the RTLSDRblog dongle has a TXCO, I thought perhaps it takes time for the oscillator to stabilize in the Prostick every time we start it with a new gain. So for one final test, here’s a generic blue dongle. It shows a fairly clear msg/gain trend, though not as obvious differentiation at high gains as with the TXCO:
RESULTS: inconclusive
1 Like
What is the input impedance of RF Amplifier chip of Pro Stick, 75 ohms or 50 ohms?