GitHub repo for XDFs

[In-Tech]

Good point, like you all have mentioned earlier, building a database to know that is a daunting venture.
TunerCat told me this is:
VIN: 1GNEK13Z34J235452

PCM Service No: 12586243
PCM Traceability Code: 1LA0PQL34037
PCM Security Seed: 389F

PCM Module 1: 12587603
PCM Module 2: 12587691
PCM Module 3: 12587955
PCM Module 4: 12587979
PCM Module 5: 12578788
PCM Module 6: 12578801
PCM Module 7: 12585937
PCM Module 8: 12579000

With the service number provided by TC "Vehicle Information", it should have had an IAC chip and hardware #12583659(according to what we've gathered so far)

When it popped up with the 12586243 service number I got excited since I only have 1 p59 with an IAC chip and it's a 2003 with an intel...then I removed it from the case

[In-Tech]

The OS's and tune files are interchangeable between all of the hardware's for that particular model (P01 or P59) PCM. I understand some have IAC drivers and some do not, some have analog A/C input and some don't, some have pull-up for tach output and some don't. This info is a given based on what it is pulled from however. Meaning if you have a express VAN tune it's known they use a mechanical throttle which requires IAC drivers.

So in a nutshell why clutter it up with Hardware ID's when for a repository of XDF's and Bin's only care about the model/style PCM rather than the specific hardwares of each model?

Drudging up an old thread. I just received some 69200 IAC chips(pics below) so I thought I'd have a go at converting a DBW pcm to DBC sometime. One of the pics I posted earlier shows the IAC chip and cap difference but where is this analog A/C input and tach pull-up spoken of above? Or are the boards the same traces minus the IAC chip and cap and these other inputs are firmware/OS based?

[Snoman002]

Jumping in here as this seems to be the discussion place for the GitHub repo.

One, thanks for setting up the repo. There are plenty of big barriers for new folks and IMO the repo as a step to focus efforts on the XDF and BINs themselves, and not the admin of maintaining the files.

I will admit, I'm not experienced with Github but I'm still surprised by the simplistic "folder" like structure that is being used.
(forgive the terminology, I'm not a programmer myself)
-I'm surprised the BINs and XDFs are treated as entities/objects and not code themselves. XDFs could benefit from collaborative code implementation/discovery. As such building the "code" out online seems like a win, especially for those OSIDs that are just starting to be worked. Bin files themselves could be treated like code and bins of the same OSID/Config could be compared against each other (or known stock version).
-Hardware configs could be treated as a distinct bucket. Since different hardware configs have different capabilities it could be helpful to index the known capabilities and allow community involvement. This can then serve as a reference as opposed to identifier.
-I think there are some inconsistencies in the repository regarding naming, I believe I have found both my Service ID and my OSID on Bin files. If Service ID is used it would be helpful to treat service ID like HW ID and index those separately.

Aside from those, have the XDFs themselves been compared against each other? I understand they differ between each OSID but it sure seems like online comparison/mapping tool could start to use multiple XDFs to look for commonality in the structure and at least help identify min/max ranges across XDFs for tables to reside in. I expect that across all the different ECMs the results will be varied, but analysis of the structure may show commonality across Hardware/service/os groupings.

I'm sure you can tell from my post count that I'm relatively inexperienced in tuning. But if I can help on the organization side while I figure this out I would be willing to do so.

edit: should's and would's to could's, my tone was wrong

[Gampy]

A misquote from Field of Dreams. “If you build it they will come”

[Snoman002]

A misquote from Field of Dreams. “If you build it they will come”

Happy to help, but there are now what, 6 forks of the repo itself. Creating additional forks will do the opposite of consolidating effort. Nor are these my files to be messing with.

And I could be completely wrong...but happy to discuss

[Gampy]

Don't create a fork, create competition ...

Collect the files wherever you get them, pretty much what others do.
Hook up with salvage yards to bench read units.

Just do it better ...

[kur4o]

I think we need some massive archive with all the files that float online. The stock vs not-stock problem is already fixed by using CVNs to verify the files. Just the name of the files must include basic description of the vehicle used, year, and some options like trans and transaxle.

To make use of the archive using this utility https://github.com/joukoy/UniversalPatcher
can build any file you need. I guess we can make a simple search addon for intel vs amd chip. Just need to know what to look at.

[Snoman002]

I think we need some massive archive with all the files that float online. The stock vs not-stock problem is already fixed by using CVNs to verify the files. Just the name of the files must include basic description of the vehicle used, year, and some options like trans and transaxle.

To make use of the archive using this utility https://github.com/joukoy/UniversalPatcher
can build any file you need. I guess we can make a simple search addon for intel vs amd chip. Just need to know what to look at.

And that is the hope. The repository linked here is a great start, but IMO it doesn't allow full performance of community based involvement. This is essentially online folders for holding files, and although that already is a HUGE help, I think a bit more would be what is needed to entice other users into contributing.

I wonder if an "enhanced" bin (eBin) could be pushed on the community. Keep the bin structure but add a header of human readable text at the top to include things like service ID, Hdw ID, year, model, etc.


Right now I'm trying to understand GitHub and how this can be structured different. Tags look to help but are not quite the metadata one needs.

[antus]

i'd suggest not touching the files. adding info at the end would be better than the start but it'll be a lot harder to work with for people who dont understand whats going on. github is for code, but it can do what we need. you'll need to look in to how you clone the repo, create a branch on your machine, switch to that branch, edit it how you like then send a pull request back to the archive owner. they should then accept it, and your changes are in the main repo for others.

I would suggest we keep file details in the readme file in each directory. When viewing github you'll see the details of what is what down the bottom. Some kind of tables in the markup that github uses should be able to do this nicely. if we got really in to it we could write and app or a script that can load the readme, pull a bunch of additional info out the bins and fill out fields in the readme. I could see filename, service number, hardware number, osid, year, pcm type, engine, transmission, stock?, description being populated manually, and a script adding the ids of each segment if we wanted to go that far. we could have factory cvn too. It just depends if anyone is willing to put in the time to start it, or even better but perhaps asking too much, do the whole archive?

[Snoman002]

i'd suggest not touching the files. adding info at the end would be better than the start but it'll be a lot harder to work with for people who dont understand whats going on. github is for code, but it can do what we need. you'll need to look in to how you clone the repo, create a branch on your machine, switch to that branch, edit it how you like then send a pull request back to the archive owner. they should then accept it, and your changes are in the main repo for others.

I was thinking more of a different file type. Drop the .bin data entirely into say a json structure. The json itself could house the metadata and the bin and the bin code itself is just a section of the json. I agree, you would NOT want to modify the internal structure of the BIN itself. Unfortunately it is a chicken and egg situation that is unlikely to get developed.

I am learning GitHub as we speak. Unfortunately I do wish it had bit more database type structure but that is not the intent of GitHub. We are actually looking for more document management then anything else, but that is not as popular and I'm not finding any well known document management sources available for free. Something like an Confluence/Jira/Bitbucket instance would be great, but I doubt anyone wants to pay for that...

I would suggest we keep file details in the readme file in each directory. When viewing github you'll see the details of what is what down the bottom. Some kind of tables in the markup that github uses should be able to do this nicely. if we got really in to it we could write and app or a script that can load the readme, pull a bunch of additional info out the bins and fill out fields in the readme. I could see filename, service number, hardware number, osid, year, pcm type, engine, transmission, stock?, description being populated manually, and a script adding the ids of each segment if we wanted to go that far. we could have factory cvn too. It just depends if anyone is willing to put in the time to start it, or even better but perhaps asking too much, do the whole archive?

This is my hope. I'm hesitant to dive too far into structuring right now since I'm not well versed with GitHub services but I think this is how it will end up. Each Bin or XDF will get its own "folder" and inside the folder the .md can hold the details. Not very pretty but it should help. The downside I'm seeing right now is structure. I want to flatten the structure as much as possible and use metadata or tagging to help organize, but Github isn't a database in this manner so you can't sort info all too well. I also can't create relationships between hardware specifications which is something I really want to do. Diving into bins and specs gets even more messy if you don't know if the hardware supports DBC, TAC, etc and so it would be great to start a repository for the hardware specs that could be tied together, but that is a database not Github...