Ok, I’ll add the ralink firmware to the default install, thanks for diagnosing it!
I’d like to get graphs etc into the standard image, with the base work done for piaware 3 this will be a lot easier to do but it’s not done yet and I didn’t want to delay the release further for more features.
I have two receivers and two pi’s on the same tower. One has an omni antenna and the other has a yagi aimed at a distant high traffic area. They are both on my wifi network. If one is set up as relayed, will it combine the results of both receivers and present them to flightaware from one mac address?
SMOOTH LIKE SILK
Just now burned Piaware3 image on spare microSD card, removed existing card from RPi #2 (Model 2), slipped in new card, powered up.
$ sudo-raspi-config #set time zone, changed password, expanded file system
$ sudo nano /boot/piaware-config.txt #changed gain setting from -10 to 28 to suite my setup (FA Antenna+FA Filter+ProStick)
No problem.
I’m glad that it was relatively easy to get it working in the end.
Fair enough. The graphs are something I’ve wanted to have to help diagnosis and antenna tuning but going from a stock install to getting them going always ended up in the too-hard-basket.
$ sudo reboot #checked wifi, found working, #SSH on wifi, working but very sluggish. #SSH on wired network, even this became sluggish EDIT: Tried again after reboot, now wifi & wired both working ok EDIT 2: After few minutes both wifi & wired network froze, no SSH. Pulled out wifi dongle, wired network started working ok.
Installation of Graphs (rrdtools/collectd) on Piaware 3 image using jprochazka’s script
At start, the script asked to install dump1090-mutability. When I selected “No” (as fadump1090 is already installed), the operation halted with comment “aborted by user”.
I then selected yes for dump1090-mutability and for the web portal (graphs). The installation is now in progress. Will update when finished.
EDIT 1
Installing the dump1090-mutability package…
Selecting previously unselected package dump1090-mutability.
(Reading database … 55411 files and directories currently installed.)
Preparing to unpack dump1090-mutability_1.15~dev_armhf.deb …
Unpacking dump1090-mutability (1.15~dev) …
Setting up dump1090-mutability (1.15~dev) …
Enabling lighttpd integration…
Enabling dump1090: ok
Run /etc/init.d/lighttpd force-reload to enable changes
Restarting lighttpd…
Job for lighttpd.service failed. See ‘systemctl status lighttpd.service’ and ‘journalctl -xn’ for details.
invoke-rc.d: initscript lighttpd, action “restart” failed.
Warning: lighttpd failed to restart.
Processing triggers for systemd (215-17+deb8u4) …
Configuring lighttpd…
already enabled
Run /etc/init.d/lighttpd force-reload to enable changes
ok ] Reloading lighttpd configuration (via systemctl): lighttpd.service.
SET THE LATITUDE AND LONGITUDE OF YOUR FEEDER
In order for some performance graphs to work properly you will need to
set the latitude and longitude of your feeder. If you do not know the
latitude and longitude of your feeder you can find out this information
by using Geocode by Address tool found on my web site.
EDIT 2:
After configuring dump1090-mutability, the gmap disappeared
Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]
so slightly surprising that yours didn’t work so well, assuming it’s the same chipset (CU vs CUS, I’m not sure it it’s a significant difference)
It might be worth testing with the wired network disconnected, depending on your network setup you might get some strange effects with both simultaneously connected. (The image is set up to have both active, but prefer to use the wired network where possible, so the Pi will be multihomed if both are active)
pi@piaware:~$ lsusb
Bus 001 Device 004: ID 0bda:2832 Realtek Semiconductor Corp. RTL2832U DVB-T
Bus 001 Device 005: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Well, I should not expect a trouble-free service from a wifi dongle costing only US$1.95+free shipping.
The costlier one (US $7.99+free shipping) gives ID 0bda:818b Realtek, and does not work.
pi@piaware:~$ lsusb
Bus 001 Device 004: ID 0bda:2832 Realtek Semiconductor Corp. RTL2832U DVB-T
Bus 001 Device 006: ID 0bda:818b Realtek Semiconductor Corp.
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Installed the new piaware image on a Pi3 and configured for ‘beast’ usb input - worked perfectly. Also configured for beast tcp using the ‘other’ config setting and it also worked fine.
Upgrade failed for me. WiFi adapter not working. I have vague memories of tweaking the config when I originally got the adapter but cannot find any documents at this time.
pi@piaware:~$ lsusb
Bus 001 Device 004: ID 0b05:1791 ASUSTek Computer, Inc. WL-167G v3 802.11n Adapter [Realtek RTL8188SU]
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
The device is correctly displayed above… ASUSTek Computer, Inc. WL-167G v3 802.11n Adapter [Realtek RTL8188SU]
dmesg gives me the following:
5.275777] usb 1-1.5: new high-speed USB device number 4 using dwc_otg
5.388572] usb 1-1.5: New USB device found, idVendor=0b05, idProduct=1791
5.399340] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
5.410436] usb 1-1.5: Product: ASUS WL-167G V3
5.418742] usb 1-1.5: Manufacturer: Manufacturer Realtek
5.427986] usb 1-1.5: SerialNumber: 00e04c000001
16.786087] usb 1-1.5: r8712u: USB_SPEED_HIGH with 4 endpoints
16.796076] usb 1-1.5: r8712u: Boot from EFUSE: Autoload OK
18.256787] usb 1-1.5: r8712u: CustomerID = 0x0010
18.265358] usb 1-1.5: r8712u: MAC Address from efuse = 98:58:38:98:99:99
18.275895] usb 1-1.5: r8712u: Loading firmware from "rtlwifi/rtl8712u.bin"
18.359258] usb 1-1.5: firmware: failed to load rtlwifi/rtl8712u.bin (-2)
18.369993] usb 1-1.5: r8712u: Firmware request failed
18.383281] usbcore: registered new interface driver r8712u
Notably: firmware: failed to load rtlwifi/rtl8712u.bin (-2)
Try installing the firmware-realtek package (“sudo apt-get install firmware-realtek”)
(FWIW I am planning on rolling a new image within the next week or so that tries to include a bunch more firmware packages so this is less of a problem)
In Armbian on Orange Pi, the driver for wifi had a problem of dropping connection due to bad power management, which they solved as follows:
There is a known issue with power management on some hardware. If your WiFi connection drops after a few minutes, install the following module setting file to disable power management in your WiFi interface:
# Disable power management in the 8192cu driver. This works around a bug in
# some hardware where the device never wakes back up.
# Credit goes to Saqib Razaq (https://github.com/s-razaq) for the fix.
# rtw_power_mgnt=0 disables power saving
# rtw_enusbss=0 disables USB autosuspend
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0
May be something similar required in Piaware 3 ???
Thank you Oliver. Your explanation pointed me to the “real” piaware-config.txt which I edited to taste before first boot.
My Pi B+ is now happily running the new piaware 3.0.3.
In addition to Oliver, my thanks to the folks at piaware.
Yes, “other” is a minimal feeder mode that tells piaware and fa-mlat-client to make direct connections to the host/port you specify, it doesn’t also forward it to the local dump1090 as well. (In fact, in “other” mode dump1090 should probably be turned off entirely - I’ll take a look at that for the next version). It’s intended for the case where you’re managing all the receiver bits yourself and you don’t want piaware to mess with them, you just want it to do the data feed bit.
If you want to also forward the data to the local dump1090 for map display, use “relay”; this will run a beast-splitter that makes a single outgoing connection to your receiver and then forwards it internally to piaware/fa-mlat-client/dump1090