(As a note, I'm not sure why Skyvector is displaying TRK as purple/LIFR - it's reporting 3 mile viz with an indefinite ceiling of 3,000 feet.)

The first thing that comes to mind is to be sure of which data product is being displayed. Verify that METAR's is setup as the default data in Basic Settings.

Also, you can change the logging level to "Debug" and run the map for a bit. This will record the data being received by the script from FAA. This could then be compared to what you are seeing on other sites.

I would be hard pressed to believe that the data is being decoded incorrectly, since this the crux of the software and has been used in the last few versions without issue. However, there could be some gremlin in there that I'm not aware of. So check those items and let me know what you find. - Mark

Yes, METAR is the data product being displayed, according to the settings.

I bumped up the log to debug, and I'm assuming it's the logfile.log in the NeoSectional directory.  I toggled the map off and on, and I see the fetch line for the METAR data, and it's getting the METARs appropriately.  I can copy the link, and I get an XML file with a bunch of METARs.

However, after the transition wipes are displayed in the debug log, it looks like it's trying to display MOS data.  Here's the snippet after I toggle on the map, note the "not all arguments converted" message which almost makes it sound like it's expecting a METAR but not getting the expected form.  Or maybe it has a METAR but it's expecting a MOS?

[I 200831 14:58:35 metar-v4:540] Airports File Loaded

[I 200831 14:58:36 metar-v4:555] MOS Data Loading

[I 200831 14:58:36 metar-v4:767] Starting MOS Data Display

[D 200831 14:58:36 metar-v4:826] Bad message (TypeError('not all arguments converted during string formatting')): {'name': 'logzero_default', 'msg': 'KCXP', 'args': ('T06', 'CIG', 6, 10, 3), 'levelname': 'DEBUG', 'levelno': 10, 'pathname': '/NeoSectional/metar-v4.py', 'filename': 'metar-v4.py', 'module': 'metar-v4', 'exc_info': None, 'exc_text': None, 'stack_info': None, 'lineno': 826, 'funcName': '<module>', 'created': 1598911116.936811, 'msecs': 936.8109703063965, 'relativeCreated': 22403.16128730774, 'thread': 3069880544, 'threadName': 'MainThread', 'processName': 'MainProcess', 'process': 1357, 'message': 'Bad message (TypeError(\'not all arguments converted during string formatting\')): {\'name\': \'logzero_default\', \'msg\': \'KCXP\', \'args\': (\'T06\', \'CIG\', 6, 10, 3), \'levelname\': \'DEBUG\', \'levelno\': 10, \'pathname\': \'/NeoSectional/metar-v4.py\', \'filename\': \'metar-v4.py\', \'module\': \'metar-v4\', \'exc_info\': None, \'exc_text\': None, \'stack_info\': None, \'lineno\': 826, \'funcName\': \'<module>\', \'created\': 1598911116.936811, \'msecs\': 936.8109703063965, \'relativeCreated\': 22403.16128730774, \'thread\': 3069880544, \'threadName\': \'MainThread\', \'processName\': \'MainProcess\', \'process\': 1357, \'message\': "Bad message (TypeError(\'not all arguments converted during string formatting\')): {\'name\': \'logzero_default\', \'msg\': \'KCXP\', \'args\': (\'T06\', \'CIG\', 6, 10, 3), \'levelname\': \'DEBUG\', \'levelno\': 10, \'pathname\': \'/NeoSectional/metar-v4.py\', \'filename\': \'metar-v4.py\', \'module\': \'metar-v4\', \'exc_info\': None, \'exc_text\': None, \'stack_info\': None, \'lineno\': 826, \'funcName\': \'<module>\', \'created\': 1598911116.936811, \'msecs\': 936.8109703063965, \'relativeCreated\': 22403.16128730774, \'thread\': 3069880544, \'threadName\': \'MainThread\', \'processName\': \'MainProcess\', \'process\': 1357}", \'asctime\': \'200831 14:58:36\', \'color\': \'\', \'end_color\': \'\'}', 'asctime': '200831 14:58:36', 'color': '', 'end_color': ''}

and then each airport gets a block that looks kind of like this, that seems to indicate that it has parsed everything as VFR, which is not the case.  (The latest KCXP METAR is KCXP 312150Z AUTO 26004KT 4SM HZ CLR 29/M01 A3000 RMK AO2, so it would be MVFR because of the visibility.)

[D 200831 14:58:38 metar-v4:854]

    KCXP

[D 200831 14:58:39 metar-v4:855] ['HR', 'CLD', 'WDR', 'WSP', 'P06', 'T06', 'POZ', 'POS', 'TYP', 'CIG', 'VIS', 'OBV']

[D 200831 14:58:39 metar-v4:876]   GFS MOS GUIDANCE    8/31/2020  1200 UTC                      

    00CL290120199987N

[D 200831 14:58:39 metar-v4:905] VFR |

[D 200831 14:58:39 metar-v4:906] Windspeed = 12 | Wind dir = 290 |

[D 200831 14:58:39 metar-v4:935] Reported Weather = None

[D 200831 14:58:39 metar-v4:954] KCXP, 12, None

[D 200831 14:58:39 metar-v4:854]

Happy to run any further tests you'd like me to, just not sure where to start.

Okay, here's something interesting.  On further analysis, I saw the following message:

[I 200831 15:28:19 metar-v4:1285] Switch in position 4. Breaking out of loop for MOS/TAF + 2  hours

I don't have a rotary switch installed, but for some reason, the software believes that I have one, and it's in position 4, which is in fact the MOS for two hours from now.  So the map was displaying the MOS.

When I set switch position 4 to display the current METAR, the map looks like what I expect it to, and decodes METARs correctly.

So, I guess the real question is why the Pi believes the rotary switch is position 4 when I don't have one installed.  I assume that the relevant two pins are shorted somehow?  (I'd have to pull it apart to get at the backside of the Pi ribbon connector and look for a solder bridge.)

Yep, the two pins are shorted somehow. If you don't want to tear it apart, then just leave that rotary switch setting set to METAR's. It will limit you if you want to use the control app, but other than that it will work. 

I attached the wiring diagram so you can see which two pins are shorted. Actually only one pin needs to be shorted to ground somewhere. Looks like you will want check pin 35 or pin 37 (not sure which one is your #4) to see if its grounded. Great catch, I'm glad logging is available for us now. - Mark

@markyharris So I spent too much time chasing hardware problems before I zeroed in on this one.  I could tell that I had a short between GPIO 19 and ground with my multimeter.  The nice thing about the Adafruit solderable breadboard is it's pretty easy to put the probes into spare ports and measure resistance.  So I carefully considered all kinds of things (much experimentation with where to measure), and only thought about the Pi at the end.  If I measure resistance between those two pins on the breadboard, they weren't shorted.  They're shorted on the Pi itself.  So, it looks like I need to try another Raspberry Pi.  I'll do that and report back.

(This was only discovered at the end of a frustratingly long set of troubleshooting actions, which included insulating the back side of the breadboard because I was afraid it was conducting between the pins!)

That's a new on for me. I've not seen the RPI cause a problem like this. I admire your stick-to-it-iveness. Let us know how it goes. - Mark

@markyharris I replaced the Pi, and everything is working normally!

This is a great example of why it's a good idea to build everything with quick-release connectors.  It was annoying to diagnose, but with a solderable breadboard, it was easy to put probes and look for the short you pointed me at.  Once I confirmed the short, it was easy to remove the Pi (it's one ribbon cable), measure again with on breadboard directly and find that there was no connection between those pins, and then measure between the Pi header pins and find the short.

For future reference if anybody has a problem like this: on the non-working Pi, if I measure resistance with a multimeter between GPIO 19 (pin 35 on the header) and ground, it's zero (a short).  If I measure it on the replacement Pi, the same measurement is 0.6 Mohms.

Great news! I'm glad to see its operating properly. Thanks again for keeping us all up to date. - Mark