New Raspberry Pi available - Pi 4

You likely added them on reinstall by installing piaware and claiming the station.
Instead of claiming a new station, you do this:

For Beginners - How to Get Back Existing Station Number in A Fresh Install

Anyway just make sure your piaware configuration is using the feeder id you want and you’ll be able to delete the other stations after a while.

I have no clue how you managed to uninstall piaware.
Maybe your sd-card is dying but could also be you just entered a command you didn’t understand.

! account was on lan and did add itself
second is a mac i dont have so will delete after few days
all working again now with a clean sdcard crap gone added what i needed all your stuff hehe
thankyou again and all others for there help
adjustments now

john
ps … but could also be you just entered a command you didn’t understand. ← YES

Upon further investigation

SITE 29790 – EGXH - This site appears to be your site was added August 26, 2016 and is currently active

SITE 114667 – EHKD - This site was added November 2, 2019 and is currently active and has a slightly different reception pattern

SITE 115268 – EGSQ - this site looks to have been added November 11 and is currently NOT active.

You should be able to delete site 115268 in a few days as long as it remains inactive.

I suspect you will have to contact FlightAware support for site 114667

The hackers took over… :face_with_hand_over_mouth:

https://www.raspberrypi.org/forums/viewtopic.php?t=257394&p=1569615

Dynamic Voltage Scaling with the new rpi-update

1 Like

Not ideal with a busy site, not something I would think most users who are using a Pi4 for FlightAware would want to have.

The improvement on power management shouldn’t be anything but a bonus really - if you are doing anything that’s not maxing out the cpu then you should see some improvement in thermals.

I updated my PI4 to see what happens with the power management with the latest firmware update.

I’m running a PI4 with force_turbo = 1, an Airspy R2 @ 20 MHz with Airspy settings of “-v -f 1 -b -e 10.0 -w 3 -t 120”. Since the update/reboot, CPU usage overall and ADSB CPU Utilization are down. Notice at the end. Temp remains about the same.

I cannot explain the decrease in ADSB CPU Utilization.

system-localhost-temperature-24h

dump1090-localhost-cpu-24h

On my system that exact drop happend when I changed the CPU governor to “Performance”. That basically increased the CPU frequency to the max boost and that increase of CPU processing power resulted in a lower number for the ADS-B Utilization.

Maybe the firmware update changed the behavior of the default governor?

I think you might be on to something. I never messed with the governor, but in that article there was discussion about the governor I think. And that would make sense. If it raised CPU freq, that would explain why I really didn’t see any decrease in temperature.

I never played around with the governor stuff before and didn’t even think of that.

Mike

Interesting observation at the end, in a vertical orientation the Raspberry Pi runs cooler and heats more slowly.

1 Like

I read that. I tested that theory with my Canakit setup put vertical instead of lying horizontal on the desk. Maybe 1C difference in the case. I’m sure the effect would be different if the PI4 was not in a case, fan or no fan. But in the particular case that came in my Canakit kit, it made nearly zero difference vertical vs horizontal.

Cut holes in the case at the top and bottom (when vertically mounted).

And space the case away from the surface that it is placed on, so that the bottem ventilation holes are not blocked.

Obvious I know, but Laptops still suffer from this when placed on ones lap.

Unless a Pi4 is located in a really low traffic area, it will most likely benefit from a fan.

Running the newest beta-firmware via RPi-update for a few days now,so far no issues, not lost frames. CPU is at 70% adsb and 22% overall, Max messages is around 1600, so not the busiest station

Today I stopped the 8cm fan cooling the Pi and Airspy, this lead to the jump in temp, then putting the Pi on its side lead to the small decrease of a few degrees c.

image

2 Likes

Above quote reminded that I did some tests a while ago, after I bought an armor case for my Pi4, one of those big aluminium heat sinks.

I am not very good at putting tiny stickers on things, so installing the small heat pads were a challenge, and I had to use thicker ones I had for the ram, as the one supplied was to thin to connect with the heatsink.

The RPi 4 is in the attic, without a case mounted vertically. ADSB-CPU utilisation is at 70%.

At 10.30 I disconnected 80mm fan cooling Pi4/Airspy combo. The temps rose from 23 to 46 degrees, so nothing to worry about, at least not in winter.

I then swapped the RPis to the one with a heat sink, without any fan. The big heat sinks helps, even without a fan temps stay below 40 degrees C.

Then I switched on the 80mm fan again, and the temperature is almost as low as it was without the fan, but it seems without the case with the fan, they were a little lower.

The only caveat here is, that after swapped Pis again, the temperatures of the case and heatsink-free Pi were higher than they were at the start. Not sure what happened there, so maybe 80mm fan + heatsink are even better?

I guess the real test comes in the summer, when ambient temperatures in the attic are pretty high.

system-localhost-temperature-3h

same here. Mine went outside end of december, meanwhile located in a wooden box.

My former 3B was running in the upper floor with temperatures up to 30°C during summer. But the CPU temp never exceeded 55°C and no active cooling was used. Only the typical passive heatsinks were used

On my Pi4 I am using this case and the fan running at 3.3V because otherwise the temperature will drop below 20°C during nighttime.

At summer i might need to switch to 5V, but it’s then fully covered by the roof from direct sun impact.

1 Like

I’ve been reading thru this long, long thread…

Was there a fix for the rtl_test and the many, many:

lost at least 2004 bytes
lost at least 536 bytes
lost at least 932 bytes

lost samples??

I should have added more context…

I just built up a RPi4B with Buster Desktop and I was hoping to use it for PiAware (not the SD image version). I ran a quick test using rtl_test and got lots of lost sample messages:

lost at least 2004 bytes
lost at least 536 bytes
lost at least 932 bytes
pi@rpi4b:~ $ uname -a
Linux rpi4b 4.19.97-v7l+ #1293 SMP Wed Jan 22 17:16:14 GMT 2020 armv7l GNU/Linux

So I’m was curious if anyone has stumbled across a fix for this?

I don’t see this on a 4B running current Buster. I would be suspicious of your power or cabling.

2 Likes