Hi,

Sorry for the hassles. A couple things to get us started; Do you have OLED's installed? If not, did you ensure that you set that setting to 'No'? 

Do you have a Rotary Switch installed? The log data you included shows that you do, but we've seen where the wiring accidently grounded one of the RPi pins which the software mistook as a rotary switch. There was even one builder whose RPi internally had a problem and had to replace it. So that's worth checking.

You obviously have everything wired to make the LED's light appropriately if the wipes are working. So the next question is to see if you are receiving an error message. You can monitor the 'Console Output' under 'Utilities'. This is supposed to mimic the command line/ssh session. However at times not all messages get reflected. So you can either hook up a monitor directly to the RPi and watch the output, or I can tell you how to initiate the scripts from the SSH session so you can see all the output. Just let me know your preference.

Finally you can change the 'Logging Level' in 'Basic Settings' to 'Debug' which will record a bunch of extra data and then download it and attach it here so I can look at it to see if there is a clue there. Just be sure to put it back to 'Info' when you are done, otherwise your board will run real slow since its doing so much writing.

Also, tell us what RPi version you are using and the number of LED's you have wired. Or send a pic of the map. We are always curious to see maps. 🙂 - Mark

BTW:

"Metar data is being pulled, I can see it in the airport editor. "

The weather data being displayed in the Airports editor is not coming from the same source as for the LED maps. This was necessary due to the way the FAA provides its API. So even though you may be seeing data on the Airports editor, that doesn't guarantee that the needed data for the LED's is getting downloaded. 

Well, a little progress. I changed the auto start setting back to no, rebooted, and now the airport config screen works. I'm able to flip all the LEDs on and off and confirm my wiring matches my airport list. That's good. 

I do not have any screens, and those settings are in fact set to no. 

I do not have a rotary switch, but had not changed those settings because I assumed it defaulted to off. This may be a bad assumption. This could be an issue I overlooked however, because I'm using a couple pins for another purpose. I have a circuit I like to use with Pi-zeros that is basically an auto shutdown circuit with a small battery. I use it to cleanly shutdown Pis used in projects like this where it's possible to just pull power. Short version, it uses two GPIO pins, one an input, one an output. Input pin tells the pi when there is connected power and when there isn't, and the other tells the circuit when the Pi has shut down. So order of operations, someone pulls the power chord, the circuit switches to battery and drops that input pin low. Pi has a script running that watches that pin, when it goes low it issues a shutdown command. When the Pi turns off it's other pin drops low, which tells the circuit it's ok to cut power entirely. I have one of these pins, along with a charge status signal, on the pins this project uses for the switch. I had assumed it was possible to disable the rotary switch option entirely. I will see if I can cut and jump these signals to other pins. 

Pi Version is a raspberry Pi Zero V1.1, using the latest livesectional build available from the website. 

I'll make a thread with pictures once I've got this working. My printed map hasn't arrived yet, and I have some acrylic to cut still for the full stackup.

I'm sure you are right about your shutdown circuit, (BTW: if there is a source of info for this, please post it. I'd love to see it. It sounds like a great idea).  If you haven't already, disconnect that and see what happens, and let me know. I'll help any way I can. - Mark

Well, I just went and cut all the extra traces, so the only pins on the Pi that are connected to anything are the 5V, 3.3V, GND, and LED data out. Same behavior. It's still showing in the logs that it's flipping between switch position 2 and 6, which is odd, nothing is connected to either of those pins. I'm going to throw it under a microscope again and make sure I don't have bridged pins anywhere that I had missed. After that I'll try different log methods to see what it thinks is going on. 

OK, this might be an assembly issue on my part. I found two pins that the switch uses accidently grounded. I cut those out, it started to head the right direction, by which I mean the log showed " Rotary Switch Not Installed. Using Switch Position 0 as Default" But then it started flipping between other switch states (8, 7, 3). So I think I have some micro shorts going on. 

I assembled this PCB before my 40 pin header arrived, so I had tried to wipe off the solderpaste on the header pads. But I think I must have not gotten all the extra solder out and now some of it is bridging to ground. I'm going to pull the rest of the pins that the switch uses and see if that changes the behavior. 

also, yes, I'll post the autoshutdown stuff once I get a handle on making this build work. 

Great progress. Thanks. Let me know what happens and if you have any other questions. - Mark

Ok, confirmed this was all assembly error probably combined with my auto shutdown stuff. I have it running with just 5V in, gnd, and the data to the LEDs, and it works now, hooray. Some tweaks to make, like reducing max brightness on these LEDs, and figuring out why one site isn't reporting data, but the rest is working which is lovely. 

One random question. A few LEDs don't light during the checkerboard wipe, but they do light in rainbow and when commanded with data. Is this normal?

give me a few minutes and I'll get the auto shutdown stuff posted. I'm going to have to order an new rev of this board with the signals routed to unused GPIO, would be good to know if you think they'll interfere with the core software. 

Great News.

One random question. A few LEDs don't light during the checkerboard wipe, but they do light in rainbow and when commanded with data. Is this normal?

Yes, this is normal. The wipes bypass unused LED's (NULL) and Legend (LGND) LED's. You can test this by replacing the NULL with test airport then watching to be sure it lights properly.

Thanks for getting us the info on your shutdown circuit. - Mark

BTW: It's fairly common to have an airport temporarily not report weather. What makes it even more frustrating is that it seems to depend on which FAA API is being used. I've seen the Airports Editor report weather when the LED is not, and visa-versa. Timing of the updates are different between products too. So fast moving weather will show differences between the Airport Editor and the LED's. Go figure.

Ok, autoshutdown. Caveat to this, I did not design this circuit, some friends at my local makerspace did when they were designing RFID access control systems for tools. The idea is that you have a small 200-300mAh lipo that is just enough to carry the Pi while it shuts down. When you pull power the voltage into the Pi will drop from 5V down to battery voltage, which can be down around 3.7ish, but this doesn't appear to harm anything. I'm sure someone more electrically focused could adjust the circuit, but for me, well it works so why mess with it. 

U4 is a basic battery charger to handle charging the lipo while power is on. 

U1 is a 3.3V regulator. It provides 3.3V to U3 when the Pi is booting or shutting down

U3 is the power auto switch. Based on signals it decides which of two power sources to pass along. 

The two important signals that need to get to/from the Pi are SHUTDOWN and PWR_LOSS.
PWR_LOSS is what tells the Pi that power was removed. When power is plugged in this signal is high (3.3V so it's GPIO compatable). When power is removed this signal is low. 
SHUTDOWN is a signal from the Pi to U3. When the Pi boots a script sets this pin high. When the Pi then shuts down this pin goes low and tells U3 to remove power from it's output. 
There is also CHARGE_STATUS going to a GPIO. This was used in the RFID system, but I'm not doing anything with it, it could be removed from GPIO. 

To make this work you need a python script to run at start. Built into this script is a small time delay to keep the pi from shutting down if power is returned within 5 seconds of being unplugged. 

#*************************************************************************
#
# autoshutdown.py  -  by: Chris Egan
# GPIO interface for auto shutdown
# 12/1/2020   Rev A - Initial Release
#
# This program handles shutting down the raspberry pi when external power
# is lost. At boot it sets GPIO23 (pin 16) high to signal to the external 
# circuit that it is powered up. When external power is lost GPIO24 (pin 18)
# is pulled low and a countdown is started. If power isn't returned whithin
# 5 seconds the Pi will shutdown.
#
#*************************************************************************

#Import
import RPi.GPIO as GPIO
import time
import os

#Setup
GPIO.setmode(GPIO.BCM) #Set Pin numbers to GPIO numbering
GPIO.setup(24, GPIO.IN) #Set GPIO24 as input
GPIO.setup(23, GPIO.OUT, initial=GPIO.HIGH) #Set GPIO23 as constant output

#Define Program to shutdown RPi
def shutdown(pin):
        print('interupt, sleeping')
        time.sleep(5)
        if GPIO.input(26):
                time.sleep(1)
        else:
                os.system("sudo shutdown -h now")


#Setup Interrupt on GPIO24 when Grounded
GPIO.add_event_detect(24, GPIO.FALLING, callback = shutdown, bouncetime = 200)

#Main
while 1:
        time.sleep(1) #Keep Program Alive

Let me know if you see any reason that would conflict with the main livesectional software. I'm hoping not since I've now moved it to unused GPIO. 

Thank you for this. This looks like a great idea to protect from a power disruption! - Mark