Fix: Ford - PAS Dev Loc not Parsing

[TLane4N6]

Extraction from Sync3 did not parse locations due to format with semicolon separator.
Example data: 8/07/2026 5:56:51.842/23156/23/NAV_FRAMEWORK_IF/dev_loc_results/682/=pos_result.Tcount:11565508 GPS Input Lon:-42.123472 Lat:32.123444 Alt:199.000000 Hd:160.383911

Also received access denied error and found that script was attempting to open a directory "pas_debug.log.11" instead of the file with the same name that was within.

The script appeared to stop processing after the above error and didn't attempt to parse additional logs.

All but 2 or 3 of the 25+ logs were stored in gzip archives which were not parsed.

Script vibe coded with Claude.

Updated script went from 0 locations to over 52,000. I also successfully tested the script with a Sync4 extraction. The Sync4 extraction used the same syntax with the semicolon, but did not have any gzip and no directories with same name as the file..

1st time submitting a pull request so let me know if I missed anything.

[abrignoni]

Test data is now included for every changed artifact module. Thank you!

[TLane4N6]

Thanks, I will work on that. I have been unable to find any public images for Ford Sync and the data I have does contain personal info. I am in the process of sanitizing it and will add it when I'm able.

[abrignoni]

Thanks for this, and welcome. Strong first pull request. Both problems you found are real and I reproduced them here. The seekers hand an artifact the directory path as well as the file inside it, and opening that directory stops the loop, so every log after it goes unparsed. The gzip handling and the Lon: format are both needed.

Two things to fix before it goes in:

1. Timestamps. timeorder() does not zero pad, so a line with a single digit month or hour, like the one in your description, builds a string fromisoformat rejects. _ts returns the raw text into a column typed datetime, LAVA stores it as text, and those rows sort to the end of the table. Pad month, day and hour.

2. Truncated gzip. EOFError is not an OSError, so a .gz that ends early still stops the artifact, which is the same failure you just fixed for directories. Adding EOFError and zlib.error there also keeps the lines read before the truncation. PermissionError is already covered by OSError.

Three smaller ones:

• Log the skip. The module does not import logfunc, so an unreadable log disappears with nothing in the output.
• source_path is still the last file only. The wrapper splits that element on newlines, so join the logs you read and the "located at" line names all of them.
• Bump version and last_update_date on the eight artifacts, and put the new format plus the gzip and directory handling in notes.

One to watch: \s* also loosens the existing patterns, which had inconsistent spacing, so counts on older logs can move. Worth a run against a log in the old format so we can see whether they do.

Only the test data bot has run so far. The rest of CI needs my approval on a first pull request and I will kick it off. No rush on the fixture, and sanitizing in place is the right call.

[TLane4N6]

Here is the test data. I think I got everything else you mentioned, but if not please let me know!

testdata.pasDeGeo.pasDeGeoApInfo.caseSync4.zip
testdata.pasDeGeo.pasDeGeoDevLoc.caseSync4.zip
testdata.pasDeGeo.pasDeGeoOdometer.caseSync4.zip
testdata.pasDeGeo.pasDeGeoSpeed.caseSync4.zip
testdata.pasDeGeo.pasDeGeoTemp.caseSync4.zip
testdata.pasDeGeo.pasDeGeoTransm.caseSync4.zip
testdata.pasDeGeo.pasDeGeoVehicle.caseSync4.zip
testdata.pasDeGeo.pasDeGeoVSpeed.caseSync4.zip

[abrignoni]

Merged. Thanks for sticking with this one, and for the fixture, which is a good one: it carries the pas_debug.log.11 directory with the file inside it, so the bug you found is now covered by a test rather than by a description.

I pushed one commit to your branch before merging. It stages the eight case zips under admin/test/cases/data/pasDeGeo/ where the runner looks for them, and records a baseline for each artifact. Row counts on your Sync4 case:

artifact	rows
Dev Loc	24328
Outside Temperature	165
Transmission Status	84
Vehicle Speed	4
Vehicle Info	1
Road Speed Limits, Odometer, Access Point List	0

Those three zeros are real absences in the logs, not the parser missing something. There are no Speed limit or odometer lines anywhere in the 754604 timestamped lines.

Two small corrections to the notes. Vehicle Info said it supports the Lon:/Lat: format, which it never emits, and did not mention the directory skip it does perform. Dev Loc did not mention the single-digit month/day/hour handling its own code path has. All eight now make the same claims and only ones that hold for that artifact.

I exercised each claim against constructed input rather than reading the code: a truncated gzip raises EOFError and the run continues, an unreadable log raises PermissionError and the run continues, the directory is skipped while the file inside it is still parsed, and 8/07/2026 5:56:51.842 parses correctly. Worth knowing that your Sync4 case has no single-digit month, day or hour in it, so that last one is covered by test and not by the fixture. A Sync3 log would close that if you ever have one you can share.

One follow-up, not a problem with this change. Your Sync4 logs do carry Wi-Fi identifiers, but under PASA_HMI_IF as SSID[...] with a Converted BSSID, while the Access Point List artifact only reads the Sync3 spellings SSID: and Extracted BSSID. That is why it reports zero here. Happy to look at teaching it the newer spelling if you want to open that as a separate one.