The data on my raspberry are not that critical if they got stolen. There is no access from outside possible.
Beside that if someone wants to access it, he need to come to my house. And then they can simply steal the whole device and then the key file is the smallest problem
Understood, thanks. I checked again the logs and the autogain seems to do just fine, it’s not changing anything as the percentage of the strong signals is in the imposed limits. I think I will keep it for now.
Really appreciate what you’re doing. Keep up the good work!
Problem now solved – thanks.
Sorry, I normally work with enterprise IT images and .isos. Please assume I mean a disk archive image in a standard, distributable format.
How-to: Switch to the PiAware v6 SD Card Image Without Losing Your Account Feeder Stats
Somewhere along the line in the last six years, We’ve switched from MAC based feeders to GUID based IDs in the config file. You’ll need to manually set this in piaware-config if you want to maintain your feed stats and not start over as new. You’ll know this is the case if after adoption on the success web page you see something like this, (real values retracted for this reply).
1. Site xxxxx PiAware (SD Card) 6.0 claimed just now! (xx.xx.xx.xx/xx.xx.xx.xx)
2. Site xxxxx: PiAware (SD Card) 6.0 added Friday, September 3, 2021 (xx.xx.xx.xx/xx.xx.xx.xx)
3. Site {`YourOldAwesomeFeederUID`}: PiAware (Debian Package Add-on) 3.7 added Saturday, October 22, 2016 (xx.xx.xx.xx/xx.xx.xx.xx)
Lines #1 & #2 above are an examples of me assuming flightaware.com magically knows what to to after re-flashing SDs and associating now “new” installs. Line #3 has the real payload- the GUID of my original, established feeder. That’s the one with years of stats I wanted to keep.
Grab your established feeder account GUID from the adoptions results as above or anytime you need it from the feeder stats details page of your established feeder in your flightaware.com account. It will be in this format:
12345678-1234-1234-1234-123456789
Note: You’ll need this any time you re-flash your SD card and to repeat the steps below to maintain your feed statistics.
Next, there are two ways to use that value to get your new Pi feeding again. You can set it in the /boot partition of the SD card before installing in in your Raspberry Pi, or you can set it over SSH while PiAware is running.
Easy Option One: Configure on your PC
- Connect your PiAware SD card to your PC, and open the
piaware-config.txtfile - Configure the line
feeder-idto include the GUID of your established feeder in a line below theAdditional settingsline. Add thefeeder-idline if it’s not there:
# Additional settings can be added below.
feeder-id {your established feeder's GUID}
- Save your edits, install the SD card in your PI, and you should be good to go.
Easy-ish Option Two: Configure on your PIAware via SSH
For this one you’ll need to enable SSH access on the Pi by adding an empty file named ssh in the /boot partition of your SD card. But to do that, you might as well use the “Easy Option One” method, since you could simply edit the piaware-config.txt file anyway at the same time. Also if you enable SSH, you should log in and change the default pi user’s password because “pi” “flightaware” is a well known user default that attackers might scan for.
- Enable SSH as described here: flightaware.com/adsb/piaware/build/optional
- Boot your PiAware and let it come up on your network
- Open an SSH session to your PiAware from a terminal on your PC with the command
> ssh pi@{your PiAware's IP}
- Log in to the Pi and use the
piaware-configcommand, replacing this example feeder GUID with your desired feeder ID
$ piaware-config feeder-id {your established feeder GUID}
- Confirm the change in the config file:
$ cat /boot/piaware-config.txt
You’ll see that the line has been updated and a comment added to indicate the change came from piaware-config.
# Additional settings can be added below.
feeder-id {your feeder ID} # updated by fa_piaware_config
- Restart PiWare and then confirm your feeder is working again on your flightaware.com profile page. It may take a couple of minutes to show up.
$ piaware-config -restart
Last, once you have your new image feeding to your original account, wait 48 hours then cleanup your accidentally created and now dead feeders from the flightaware.com page for your account as described here: flightaware.com/adsb/faq/#removesite
Hope that helps!
3 Likes
A Big thanks to Cody as well. It is now 24h since I wrote the above and to my surprise my Pi was updated overnight (AU). Cody had successfully installed the Ver6 upgrade. Cody, am I still on Jessie or did you change it to Buster. I did manage to burn a Buster SD with FA and FR24 which I will have on standby if needed.
Thanks again for your assistance.
It says:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
What happens if you connect the stick directly without the USB hub it is seeing ?
I get the error Mon Sep 6 16:50:35 2021 UTC dump1090-fa 6.0 starting up. rtlsdr: no supported devices found.
What does the lsusb command say without the USB hub ? It seems that is is not detecting your rtlsdr stick
The stick is connected directly. I’m not using a hub.
It’s a Pi Zero W that I’m using and the stick is plugged straight into it.
Was all working fine until the upgrade to v6
Thanks for the feedback, it is detecting it as a hub now and not as a rtlsdr stick.
What brand is the stick ? Maybe you are missing a driver for it ? I don’t know but maybe I can look it up for you.
I can’t find the exact model details but it’s like this:
Did you try a different USB port ? It should be auto detected confirmed when you give the lsusb command.
1 Like
I only works on one of the ports on the Pi Zero W. It has two micro USB connectors that look identical. However, the one on just supplies power, and the other is the only USB On-The-Go connector (OTG).
I ran lsusb -v and got this output if it is any help:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 5.04
iManufacturer 3
iProduct 2
iSerial 1
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
I’m sorry but I can’t help you any further then.
It only sees the port and not the stick connected to it.
Maybe somebody else has an idea but i think the stick is having an issue or the firmware for the stick is missing for some reason.
I don’t have a Pi zero W to test it with…
No, that’s the internal root hub you’re seeing; it’s always present.
This sounds like a failing dongle or power issues.
Your stick is simply not detected by the operating system. If it’s a bad dongle or a bad USB slot cannot be determined directly.
Most likely the stick gave up operating.
Well since the Pi Zero W is using a Micro USB connector then it cannot be connected directly. You must be using an adapter or a dongle to connect the SDR to the Pi Zero W. (USB A to USB Micro.) Micro USB connectors can’t take a lot of stress so the connector may have worked itself loose due to the stress from the SDR and adapter/dongle.
Either way the SDR isn’t be detected by the USB hub. Try plugging the SDR into your PC and see if it’s detected.
Try running this command:
pi@piaware:/$ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
|__ Port 4: Dev 4, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
I have tried several times to upgrade and restart, to no avail. Not sure if I am on Jessie or not. Any suggestions?