Opensource LS Flashing(It's Closer Than You Think)

[PeteS]

I never knew EagleMark but some of his old posts and information he had gathered on LS flashing and sites he had posted links to about flashing are what peaked my interest in flashing an LS pcm. It all started with an Elm 327 and I made remarkable progress with that but frankly I was in way over my head with stuff I didn't understand. So in desperation I posted what I had done on a couple of the LS focused websites and crossed my fingers I'd find people interested in what I was working on. Well it's been a bit of a bumpy ride but I've meet up with a couple other like minded people and as a collective group we had the knowledge it was going to take. The Elm327 was ditched in favor of something much more robust but a bit unorthodox. Well we've successfully gotten a BIN read out of both the 411 and 1mb pcm's.

This ones for Mark..........his work has inspired others to pick up where he left off:thumbsup:



https://www.youtube.com/watch?v=_lN201rOZqE


The data, software and hardware is being sorted and will be made public on GitHub as it becomes stable and in a usable state while we continue refining the whole process. Opensource flashing is almost here, it's just taken finding the right people that could bring the needed skillset's to the project to make all of this happen.




Thaniel - The Arduino Mastermind behind the heart of all this. Your work here is unparalleled, you've turned what many would consider a toy into a force to be reckoned with.


Garret - Your work on the VPW side of all this has been pure genius. It still blows my mind that you've made this work with out any type of commercial hardware interface..... WELL DONE ! ! ! ! ! !


NSFW - I know some of the software requests I given you seemed a bit "Out There" at the time but with out them none of this would have been possible. I can't wait to see what you've got in store for the rest of the project.


Antus - I know I didn't do any of the thing you told me to....and that you were never really interested in this project but with out your help this would have died months ago.


Tazzi - I'm going to call you my inspiration..... that kept me believing this was possible..... even when I questioned my self asking if an Opensource flash was really worth so much of a headache at times
.
Dimented24x7 - The work you left behind for others has been a tremendous help though out all of this and continues to help as we move forward and start working on writing a flash as our next step.


EagleMark (R I P) - It's an honor to have found your work and been able to pick up where you left off....I will do my best to see that this is finished.
Lost....... but not forgotten your dream will live on for years to come.






Pcmhacking.net - #1 source on the Web for anything thing related to hacking apart a GM/Holden Pcm.


Gearhead-EFI.com - This site may hold the largest collections of data related to pcm flashing that I have ever come across.


Ls1tech.com - Best place to find Gearheads on the Net






I would like to ask that you give these guys a round of applause......:rockon:

The official thread I will be keeping updated in the coming months as our work progresses can be found here:
https://ls1tech.com/forums/pcm-diagnostics-tuning/1892142-inexpensive-opensource-flashing-s-closer-than-you-think.html#post19836978

[1project2many]

Wow. Thank you for all the effort. A low cost solution to this problem is long overdue.

Any plans to make this work with other pcms?

[PeteS]

At this point in time were just focused on finishing the current project before thinking about anything else. There is still the matter of creating Xdf's for all of the 03+ stuff so that the bins can be used with tuner pro.

[dave w]

I personally got to know EagleMark.

What your "like minded" team has done would certainly make EagleMark SMILE!:thumbsup:

Congrats to all your "like minded" team for what has been accomplished to date. I sense the "Snowball" of success is growing bigger and bigger.:rockon:

dave w

[Xnke]

Having built a few interfaces for similar things, this is no small feat. When are you planning to update us on the hardware needed to help with the software development? (I'm pretty good with designing/troubleshooting hardware...but you don't want me writing your code...it might work, but it ain't gonna be pretty.)

[dzidaV8]

So I guess someone have done this software faster than I could :) I'm in the middle of work to create my own OBD2 reflash tool, I've had good progress with cheap ELM327 compatible hardware, I see no reason to build custom one. Maybe we could help each other finalize that :)

[EDZIP]

Great news ..kinda curious is this the same GitHub?

https://github.com/blog/2502-github-joins-amicus-brief-to-protect-sanctuary-cities

[PeteS]

Great news ..kinda curious is this the same GitHub?

https://github.com/blog/2502-github-joins-amicus-brief-to-protect-sanctuary-cities

Our work on this can be found here. It's still being filled in as we sort out every thing. Trust me.... some of the information we have been sending around the group would make your head hurt just looking at it lol. We're slowing making it so others can understand what we did, how we did it and then be able to recreate it on their own.

[PeteS]

What is the largest packet size you've been able to send? I personally have done quite a bit of work with the OBDLink MX. It has the largest buffer of any of the "Dongle" type interfaces I have come across.

[PeteS]

Having built a few interfaces for similar things, this is no small feat. When are you planning to update us on the hardware needed to help with the software development? (I'm pretty good with designing/troubleshooting hardware...but you don't want me writing your code...it might work, but it ain't gonna be pretty.)

Currently the hardware is pretty simple. It's 4 resistors, 1 diode and 1 optocoupler. All the magic is done in the Arduino code.

[kur4o]

Currently the hardware is pretty simple. It's 4 resistors, 1 diode and 1 optocoupler. All the magic is done in the Arduino code.

I was almost sure you had used some cheap vpw transiever like motorola 33990 or similar auto grade one.
It is waste of time and effort to turn the arduino in software transiever when you can hook a simple piece of hardware to do it. Not sure how stable will be in car and off the bench test. Noise might be a big stability problem if software can`t compensate. Anyway big respect for the effort. I just want to express that it might not be the most economical approach.
VPW is 0-7 volt signal, so I guess the needed hardware is to change the 0-5 volts on the Arduino tx-rx line.
If you want to go cheaper and software only, ditch the Arduino and link the motorola transiever with 2$ usb to ttl and find a way to control the 4x switch.

The ELm is interesting and not the buffer but the main obstacle is that you cannot send hex data over it. You have to convert from ascii characters, and what a nightmare is to change the header.

[PeteS]

I

The ELm is interesting and not the buffer but the main obstacle is that you cannot send hex data over it. You have to convert from ascii characters, and what a nightmare is to change the header.
Buffer size is the only limit I've ever found with the elm stuff. I've read and written Vin numbers,serial numbers,BCC codes even OS segment id codes with an elm type device in Android. I actually read a bin file out over Bluetooth with my phone last night.....trust me when i say buffer size IS it's biggest drawback. Reading 192 byte blocks takes forever

If your still stuck on the ascii to hex thing i'll give you a tip on an easy hack method I used before I learned how to change from base 10 to base16 to take care of it the conversion for me.


Write a function that does the conversion. Here's a super easy hack method. Set your input = to an output

0=0
1=1
5=5
9=9
A=42
L=4C
Q=51
Etc.....

Yes the statement will be huge and its 100% hack method to do this but it works.

Store your variable
Call the conversion function & store as a new variable
send data from the new variable.

Like I said it's a total hack but it'll work.


Pm me if you'd like to discuss them elm in more depth

[Xnke]

So you're keeping this under wraps...just like every other LS1 flash tool that has been done so far, except Dimented24x7's, it's all "free" until it's complete and works...then it's for sale.

HPTuners, EFILive, Antus's flash tool...all of them started right down the exact same "Yeah let's get this done for free" path you're on right now. And all of them said "it's too complicated, I'll release it for free when it's done."

I'm hopeful, and still willing to work on this, but won't be surprised when this comes out to be another few hundred dollar subscription, instead of a free flash tool.

[PeteS]

So you're keeping this under wraps...just like every other LS1 flash tool that has been done so far, except Dimented24x7's, it's all "free" until it's complete and works...then it's for sale.

HPTuners, EFILive, Antus's flash tool...all of them started right down the exact same "Yeah let's get this done for free" path you're on right now. And all of them said "it's too complicated, I'll release it for free when it's done."

I'm hopeful, and still willing to work on this, but won't be surprised when this comes out to be another few hundred dollar subscription, instead of a free flash tool.

Here's some pepper to go with your salt

https://github.com/LegacyNsfw/PcmHacks

Publishing every thing myself and others have done that lead down this path would be well over a year of collective information. Forgive us for not having that much data formatted and laid out for others to understand right away. There are a number of people involved in this project and every one has the same goal. What makes this different is that no one person holds all the information. Loosing one of the core would seriously hurt our work BUT every thing they have done has been shared with others and WILL be made public before this is all said and done. If this goes belly up before we finish out work you can be sure at least ONE of the people involved will throw EVERYTHING online regardless of how clearly it's formatted just so that all our work will have been for nothing. The idea was that others could finish what we started if we are unable to.

So..... no matter what happens SOMEONE WILL BE ABLE TO FINISHING THIS.

[NSFW]

If you search for my alias in the RomRaider.com forums you'll find a handful of open-source projects for Subaru, from tuning utilities to a speed-density implementation that has since been ported (by someone else) to a bunch of other Subarus besides my own, and a rev-matching patch that is still a work-in-progress but is also up on GitHub for anyone who wants it. Everything I contribute to this effort will be open source as well.

I got involved in this effort a couple weeks ago because I bought a Corvette a few weeks ago. If you want to see the code I've written so far, it's all at the link PeteS just posted above. It's mostly just some simple dev utilities and a prototype that we're using to discuss the design of the real app, but hey... gotta start somewhere.

There are basically three main holdups right now.

1) The flash kernel we have now was written by a guy who can't be reached. He posts as Dimented24x7 on some other forums. His job takes him offline for long periods. We have permission to USE it, but nobody thought to ask for permission to post the source publicly before he left, and it wouldn't be right to share the source without that permission. But it works. So it will appear only in the form of a long string of bytes until he gives us his blessing to post the .asm files. (Or tell us to knock it off, in which case we'd just have to write a new one. But I don't think that's likely. And he did give us a nice reference to follow...)

2) We want an interface that doesn't cost an arm and a leg. The proof-of-concept uses an AVT interface, but it's hard to come by and rather expensive. PeteS mentioned the Arduino project, that's got great potential. Hopefully it will be up on GitHub soon as well, but that's up to the guy who is developing it. I also just ordered a Scantools SX in hopes that we can make it work. If anyone else wants to pitch in with a better / cheaper / faster interface, that would be fantastic!

3) The existing app needs to be rewritten for maintainability, flexibility (it's too tightly coupled to the AVT interface), and reliability. That's where I'm focusing my time.

This will be open source when we're done. Parts might not be open source at first, but that just means that we're not done.

[Xnke]

Can you use raw binary data instead of the AVT data interface? To be clearer, are you attempting to emulate the AVT852-E and are looking for less costly hardware, or are you willing to work with a direct serial translator instead?

If so, I'll have a 1x/4x capable hardware unit posted here shortly. It'll be atmel based so you can run your current VPW implementation if you'd like, I'm putting the old design through the wringer right now to make sure it'll do what you need it to do. Also, you could simply use the Harris or Fairchild bus interface chips to do the hardware, they're discontinued but available through second-source vendors. I have been pulling them from GM body control modules, they're surface mount so you need to be good with a hotplate.

Also the AVT interface is available directly from AVT, you can buy singles at 250ish dollars each. That's where mine came from.

[buddrow]

Xnke,

just how soon is "shortly:? :-)

Buddrow

[NSFW]

Can you use raw binary data instead of the AVT data interface? To be clearer, are you attempting to emulate the AVT852-E and are looking for less costly hardware, or are you willing to work with a direct serial translator instead?

If so, I'll have a 1x/4x capable hardware unit posted here shortly. It'll be atmel based so you can run your current VPW implementation if you'd like, I'm putting the old design through the wringer right now to make sure it'll do what you need it to do. Also, you could simply use the Harris or Fairchild bus interface chips to do the hardware, they're discontinued but available through second-source vendors. I have been pulling them from GM body control modules, they're surface mount so you need to be good with a hotplate.

Also the AVT interface is available directly from AVT, you can buy singles at 250ish dollars each. That's where mine came from.

Raw binary is fine, we're designing the next app(s) so that the raw binary payloads are totally separate from the details of the different interfaces. That should make it relatively easy to support different interfaces. Antus wrote the proof-of-concept and has an AVT, so that will probably be the first interface to work, but I'm not planning to buy one just yet. As a software developer I'd prefer the "direct serial translator" approach. But as someone who wants there to be an active community of people hacking 0411 PCMs, I really just want there to be an interface that is inexpensive and readily available. $250 could work, but that price point seems to leave a lot of room for improvement. DIY SMT isn't going to work for very many people though, so I'm not real excited about that approach.

What do you think about getting productizing your design through service like seeedstudio.com? Or PCBs through oshpark.com, a case through shapeways.com, OBD2 connector with pigtails from Amazon, etc, etc, so anybody with a soldering iron could build one?

[Xnke]

The problem with things like oshpark and seeeedstudio is cost. You can't buy just 1 board through those guys, and oshpark is 3 boards for close to 100 bucks all told.

You can't buy a lot of the parts and bits you need in through-hole anymore, you'd be buying breakout boards and main pcb's and pin headers...SMT is very easy to do at home, but people see it as scary so no one tries. It's actually much cheaper and faster to do than through-hole!

gotta go, second and possibly third tornado today just sounded the warning-if I have power in a few hours I'll start posting schematics.

[PeteS]

I will agree though hole is NOT fast, but at the same time SMT also requires a great deal of knowledge to use less then ideal tools.

[kur4o]

Here are some useful links for anybody that wants to build a custom interface for VPW bus.

https://forum.macchina.cc/t/support-for-j1850-vpw-pwm/67/34
https://www.irjet.net/archives/V4/i7/IRJET-V4I791.pdf
https://www.nxp.com/docs/en/application-note/AN1731.pdf

Transciever is a must and all the transcievers are surfice mount type. Most are 8 pin SOIC package. Cracking an old pc motherboard will give you a good starting point for creating custom board with surfice mount components.

If you plan to add support for CAN bus vehicles, there is an available break board with tja1050 transciever ready to be linked with arduino or other types of interface.

[Xnke]

None of the J1850 transceiver chips are in production or are available from distributors anymore. You can't buy them except through second-sourcing and counterfeits. They are *available* but it's hit or miss that they're real...Which is a real shame. Only reason I haven't posted the schematics and board layouts yet-I've been using the transceiver chips robbed out of old GM modules.

Anyway, if you CAN get the transceiver chips, you want the MC33990 or MC333990 from Freescale-by far the easiest to work with AND they will both do 4X transmit mode. The Harris HIP7020 will not do 4X transmit, only does 4x receive and 1x transmit. The chinese AUP7020 is the same as the harris-1x transmit and 1x/4x receive.

The current non-transceiver chip design is based on the BSS138 mosfet level shifter. The issue is that it no waveshaping is done in 1X mode, which means for datalogging and normal communications in 1x mode, you're dumping a lot of hash onto the bus that other transceiver chips don't want or expect and might cause problems. In 4x mode, the VPW protocol does away with waveshaping and runs without it-so the level shifter trick works fine and is actually compliant. This method, however, will not work for J1850PWM mode...which we don't care about for GM.

For basic usage, just grab one of these:

https://www.sparkfun.com/products/12009

and supply the "LV" side with +5v, and connect this side to your arduino pins. Then on the "HV" side, connect a 8V, and tie the two IO lines together to go to the J1850 bus-same as you'd do for an ALDL interface.

The BSS138 is the part I use in my non-transceiver design but since everyone is afraid of SMT soldering, the breakout board above will let you get it done "through-hole" style.

[buddrow]

As far as wave shaping, couldn't it be done with an RC filter. All its really doing is creating a non-digital type signal correct? a little slope on either side of rising/falling edge? Or am I offbase with that train of thought? Also. whats the cutoff voltage, I know it expects ~7vdc as high with a separation state of 3.5vdc, but is 5vdc enough to get the job done, say with an "off-the-shelf" unit like the arduino? Just spitballing here so feel free to correct/educate me. Im not new to embedded controls, but I am still learning the j1850 VPW setup.

Bud

[Xnke]

Yes and no. You won't get reliable data transfer with 5v logic highs-and you're going to be receiving 8V coming back at you which will destroy the arduino very quickly. You can make it work on a bench harness at 5v but not in a vehicle.

The wave shaping requires an RLC filter, and to get to the specified VPW "exact spec" is pretty tough-we can pretty well ignore it though if we go to 4x mode, which doesn't use the waveshaping at all. It's easier (and works well enough to do the job) to ignore the waveshaping in *most* cases. You're likely to run into a stubborn case that will have some dropped frames and the like in 1x mode if you don't use the waveshaping, but for flashing and receiving datalogging info, it'll be OK for 90% of cases.

On the receive side not only do you have to level shift, you need to use a comparator to clean up the logic signals-they are going to be pretty muddy without it and will have a lot of framing errors.

[Xnke]

Ok, so this is the surface mount, but still 100% all parts available nothing hard to find VPW transceiver hardware. Just checked it, this works in both 1x and 4x modes and if you just use the VPW translation circuits (top part of the drawing) then you could adapt these to any Arduino or PIC or Motorola processor you wanted. As is, the drawing contains an ATmega32U4, configured as per the ArduinoMicro style board. I'm going to verify footprints and make sure the layout isn't too tight for the supercheap board houses to do properly, and I'll send the schematics and board gerbers to whomever updates the Github stuff.

Technically the interface could be completely done in through-hole components but it'd be about the size of a postcard, but since we're working at baseband and the symbol rate is relatively low, it should still work in a through-hole board.

https://i.imgur.com/QkCCuB6.png

If you don't care about the ATMega32U4 and associated stuff that has to be there for it to work, and you only want the J1850VPW stuff, then start at the OBD-II connector and work from there-you'll see where it translates out to just the J1850VPWRX and J8150VPWTX lines. Yes, the two voltage regulators are both LM7805's, the D2PAK versions, and to get the 7.6v to transmit on the VPW bus, we just put four diodes in series from the GND leg of the voltage regulator to ground-this lifts the regulator 2.6v over ground, and provdes a 7.6v rail to the transmit assembly.

Since I cut a lot of unneeded junk out of this board that handled CANbus as well, I need to re-do the PCB layout. I'll get it posted up as soon as possible.

[kur4o]

A VPW bus operates in two states:• Active — In the active state, the bus is driven between 6.25 V and8.00 V.• Passive — In the passive state, the bus is pulled down to between1.5 V and 0 V.



Xnke do you have more info for 4x mode. Does the pulse width get slashed by 4 and there is no rounding of the waveform, or is something else done.

The most simple solution for smt is to get 8 soic to dip adapter. Ebay is full of them.
33390 and 33990 are availabe through aliexpress and are sold in 5 or 10 pieces. They look geniune also and the average price is 1$ per piece.
I have a busted bcm from w-body that uses 33390 and will post the schematics from the bcm.

[Xnke]

4x mode has no rounding of the waveform and as far as I can tell, the pulse width windows are just divided by 4 to push the data rate up-the rest of the spec is the same.

I have yet to purchase a "good, working" 33390 or 33990 anywhere on the net-I've been pulling them from BCM's myself. Doesn't take much, a little hot air and some tweezers has netted me a few. I've even done it in the junkyards with a cigarette lighter and tweezers, just have to be very careful.

I tried to make a video on how to do SMT soldering very easily at home, but my GoPro doesn't have the close-up abilities to show very clearly what's happening and how easy it really is. I'll have to get a new camera to do it.

[Xnke]

Now I've done it...

The boss is not gonna be happy, I have been picking at this for over 24 hours now, grabbed some fairly basic VPW code for Arduino off of Github and have been re-writing it as a state machine, integrating support for both the discrete optoisolator/transitor-comparator hardware and the MCZ33390/33990, and including 4x transfer mode.

Only things left is to get it working in AVT compatible mode so all the ADX's that Dimented24x7 wrote will work still, and then figure out how block transfer mode should work because I got no clue how that happens.

Oh yeah, I probably ought to plug this into a whole truck and see what happens...so far all testing has been in the lab and I haven't *broken* anything yet...

[PeteS]

Ok, so this is the surface mount, but still 100% all parts available nothing hard to find VPW transceiver hardware. Just checked it, this works in both 1x and 4x modes and if you just use the VPW translation circuits (top part of the drawing) then you could adapt these to any Arduino or PIC or Motorola processor you wanted. As is, the drawing contains an ATmega32U4, configured as per the ArduinoMicro style board. I'm going to verify footprints and make sure the layout isn't too tight for the supercheap board houses to do properly, and I'll send the schematics and board gerbers to whomever updates the Github stuff.

Technically the interface could be completely done in through-hole components but it'd be about the size of a postcard, but since we're working at baseband and the symbol rate is relatively low, it should still work in a through-hole board.

https://i.imgur.com/QkCCuB6.png

If you don't care about the ATMega32U4 and associated stuff that has to be there for it to work, and you only want the J1850VPW stuff, then start at the OBD-II connector and work from there-you'll see where it translates out to just the J1850VPWRX and J8150VPWTX lines. Yes, the two voltage regulators are both LM7805's, the D2PAK versions, and to get the 7.6v to transmit on the VPW bus, we just put four diodes in series from the GND leg of the voltage regulator to ground-this lifts the regulator 2.6v over ground, and provdes a 7.6v rail to the transmit assembly.

Since I cut a lot of unneeded junk out of this board that handled CANbus as well, I need to re-do the PCB layout. I'll get it posted up as soon as possible.

That is for more complex then it needs to be.

https://www.mouser.com/ProductDetail/Microchip-Technology/PIC18F2620-I-SP?qs=sGAEpiMZZMvqv2n3s2xjsXReEaAKUmyLAbws7PIwC%25 2bY%3d

A VERY simple circuit is all that's needed and it can do both 1x and 4x

Datasheet....
http://ww1.microchip.com/downloads/en/DeviceDoc/39626e.pdf

And best of all it's still in production and comes in a DIP package.

[PeteS]

Now I've done it...

The boss is not gonna be happy, I have been picking at this for over 24 hours now, grabbed some fairly basic VPW code for Arduino off of Github and have been re-writing it as a state machine, integrating support for both the discrete optoisolator/transitor-comparator hardware and the MCZ33390/33990, and including 4x transfer mode.

Only things left is to get it working in AVT compatible mode so all the ADX's that Dimented24x7 wrote will work still, and then figure out how block transfer mode should work because I got no clue how that happens.

Oh yeah, I probably ought to plug this into a whole truck and see what happens...so far all testing has been in the lab and I haven't *broken* anything yet...


Obdlink MX supports 3K packets

ObdLink Sx Suports a touch under 2K packets.

Adx files already exist for Elm protocols.

Did this last week just messing around to see what would happen......
https://www.youtube.com/watch?v=IMQU2gDfpOg

I'm so tempted to write the code into my current Android app just to see big blocks.....but I'm in the middle of a total rewrite on the app changing every thing to block mode and I really don't want to add it into a outdated version. The rewrite is a long ways from being done but I'm going for stability with the rewrite not just making it work in the fastest possible time.

[Xnke]

That is for more complex then it needs to be.

https://www.mouser.com/ProductDetail/Microchip-Technology/PIC18F2620-I-SP?qs=sGAEpiMZZMvqv2n3s2xjsXReEaAKUmyLAbws7PIwC%25 2bY%3d

A VERY simple circuit is all that's needed and it can do both 1x and 4x

Datasheet....
http://ww1.microchip.com/downloads/en/DeviceDoc/39626e.pdf

And best of all it's still in production and comes in a DIP package.

So you're changing ships and going to the PIC from the AVR that you're currently using? The above drawing is just the arduino board plus the simplified 1x/4x VPW level shifter circuit. As I said above, if you don't need the Arduino you just use the top part that includes the voltage regulation to the VPW 8V bus, and the 5V logic bus to power whatever microprocessor you want to use.

Also, not sure if you meant to link a different transceiver or if you thought there was one built into the PIC, but the part you linked is pretty much going to need all the same stuff in the above drawing, plus another interface to get from RS-232 to USB. The drawing above includes the USB interface, the complete microprocessor and all it's support components (which are substantially the same as what you need for the PIC) the power supply, and the VPW transceiver. No dongles/adaptors needed.

You could use the ATmega328p in DIP form factor too...and then continue using your arduino code instead of having to do a complete rewrite for the PIC. Still gonna need a USB interface, crystal and load capacitors, reset button, both voltage regulators, and the VPW interface, so I don't see how your link above helps you simplify anything.


Obdlink MX supports 3K packets

ObdLink Sx Suports a touch under 2K packets.

Adx files already exist for Elm protocols.

Did this last week just messing around to see what would happen......
https://www.youtube.com/watch?v=IMQU2gDfpOg

I'm so tempted to write the code into my current Android app just to see big blocks.....but I'm in the middle of a total rewrite on the app changing every thing to block mode and I really don't want to add it into a outdated version. The rewrite is a long ways from being done but I'm going for stability with the rewrite not just making it work in the fastest possible time.

Ok, so block mode needs to support 4096bit blocks, I can make sure that happens.

I thought you were using the flash tool and ADX/XDF that Dimented24x7 wrote to work out of. His software and ADX files, IIRC, are written for the AVT-852 cable, and speak a totally different language to the ELM chips.

So, what hardware is your open source tool actually using?

[PeteS]

Nope I'm not "doing" any thing. I linked the pic for your benefit, rather then trying to use obsolete parts you could consider something that's still in production and works with a very basic circuit with out a transceiver.....and it could communicate with the Arduino over serial data if you want to, I've done it before.

The arduino to date is the only interface outside of things like the AVT that can do 4k blocks. Others can get close but would need modified firmware to achieve 4x speeds. The arduino it's just a matter of adding an additional set of timing markers to get into 4x. Now you don't need 4k blocks or need 4x mode they both just make things a lot faster. One of the guys in the group working on this has actually read out a bin in 1 byte blocks.....a long time doesn't even come close to describing how long that took. The purpose was too see if there was a minium block size that had to be read since there is a maximum block size. As it turns out 1 byte does work so it's just an upper limit.

What we are using represents more then 10 years of research from a lot of different people.....not just Dimenteds. We are taking a lot more open minded approach then others have, rather then focus on only supporting one type of interface with a program like others have we are exploring a "universal" type program that would be easily adaptered to multiple interfaces giving users a much larger choice of how they would like to use it.

And yes, an Android based version will also exist, but since Bluetooth isnt as reliable as USB connection it will be much more limited in terms of what it will do. For example an Android version will never support a full OS write. It would be limited to calibration writes. If you want to start swapping Os's around do It on a computer not a phone.

The Adx/Xdf your referring to is but one of many that will need to be created. I have started working on this but it's going to take a long time to do. There are something like 30 primany Os's across the 99-07 pcm's and then there's around 200 segment combations that could also be used. The read/write aspect of this will be done a long time before all the Xdf's will completed.

[KC5UEA]

Anybody have the diagram from Xnke's post (#25)?
I would LOVE to see it, but apparently it has been pulled?

Thanks, Mike

[Xnke]

It's still there, Mike.

Pete, nothing in the schematic I posted has been obsolete or will be anytime soon. The part that my schematic replaces that is MUCH simpler, (the dedicated transceiver chip) has been obsoleted-so I have drawn it using the still very widely available, in production, discrete parts instead. (obsolete part is an 8-pin surface mount chip, my solution is completely available in through-hole if you want it as an 8 pin DIP, two TO-220 and two TO-92 parts.)

I've got 4x mode working right now, and have it running on the bench PCM next to a noise generator to test for error detection and correction. I'm gonna let it run for a few hours and see how the error rates look.

[kur4o]

Now I've done it...

Only things left is to get it working in AVT compatible mode so all the ADX's that Dimented24x7 wrote will work still, and then figure out how block transfer mode should work because I got no clue how that happens.



If you make it compatible with the avt commands, that will open a whole lot of opportunities for using it with a software like dhp and some other popular stuff.
The basic commands are not that much and can be easily mimicked. I have a good knowledge of them and will help you out. I will get you some serial dumps of pcm read and the AVT manual if you don`t have it.

[KC5UEA]

It's still there, Mike.

Pete, nothing in the schematic I posted has been obsolete or will be anytime soon. The part that my schematic replaces that is MUCH simpler, (the dedicated transceiver chip) has been obsoleted-so I have drawn it using the still very widely available, in production, discrete parts instead. (obsolete part is an 8-pin surface mount chip, my solution is completely available in through-hole if you want it as an 8 pin DIP, two TO-220 and two TO-92 parts.)

I've got 4x mode working right now, and have it running on the bench PCM next to a noise generator to test for error detection and correction. I'm gonna let it run for a few hours and see how the error rates look.


I had been using I.E. 11. Decided to try Chrome, and sure enough it is showing! Thanks, Mike.

[EDZIP]

Hey guys...way over my head but I'm following this thread, been collecting 411's for that special day:-)

FYI: Each time that I open this thread in Chrome and approach post #35 there is no image and suddenly my screen crashes. If I backspace and scroll down again..it crashes each time. If I open the thread in FireFox or Safari no problem viewing the entire thread?

[Xnke]

something in the way chrome handles links to IMGUR. Ever since photobucket decided to screw their users I switched.

[PeteS]

It's still there, Mike.

Pete, nothing in the schematic I posted has been obsolete or will be anytime soon. The part that my schematic replaces that is MUCH simpler, (the dedicated transceiver chip) has been obsoleted-so I have drawn it using the still very widely available, in production, discrete parts instead. (obsolete part is an 8-pin surface mount chip, my solution is completely available in through-hole if you want it as an 8 pin DIP, two TO-220 and two TO-92 parts.)

I've got 4x mode working right now, and have it running on the bench PCM next to a noise generator to test for error detection and correction. I'm gonna let it run for a few hours and see how the error rates look.

I'll go and take a closer look at it then, I looked at the transceiver chips that had been linked......I know all about those and have been down that road trying to find one's still avaible.

I'm curious to know what you have the pcm doing while it's in 4x mode since with out the appropriate VPW commands it won't stay in 4x mode for very long with out rebooting.Unless your using the older "Blackbox" style pcm I find that somewhat hard to believe.

If you are using the "Blackbox" style then you need to drop it and move to the LS style since they have very little in common.


And what your doing sounds a lot like what you "accused" me of in your initial post you made in this thread. There is a "Group" of people actively working on this project, some are remaining behind the scene so to speak while providing some valuable information , others are just choosing to focus on the work they are doing currently. Where not out to reinvent the wheel with this....we're designing a blueprint so to speak that ANYONE will be able to use across multiple platforms with out becoming tied to any specific type of hardware.

I'm not at liberty to say what programs specifically; but we(the people that need it) have been provided source code (from the authors directly) of existing software for "educational research"(Not reuse) to help streamline this entire project. People that have already written software regardless of if it was ever released or not see the value in what we are doing for the community as a whole and have contributed to make sure this actually happens.

[PeteS]

So, what hardware is your open source tool actually using?
The Arduino is know about but there are some other tools that we have been looking at. The Avt852 as well but due to cost alone it's not something we are directly focusing on.

These are some of what's currently being worked with.....
http://www.obdlink.com/mxbt/

http://www.obdlink.com/sxusb/

http://www.obddiag.net/allpro.html

http://www.obddiag.net/allpro.html#bluetooth

http://www.obddiag.net/allpro.html#usb


These are others we are looking into......But have not tried yet....

http://www.vxdiagshop.com/wholesale/vxdiag-vcx-nano-for-gm-opel.html

http://www.buyobdtoolshop.com/wholesale/mongoose-vci-toyota-v830023-single-cable.html

http://www.uobdii.com/wholesale/mini-vci-for-toyota-tis-techstream-v500028-single-cable-2442.html

[Xnke]

The PCM on my bench is not a Blackbox PCM, it's an 0411 from a 2002 S10 blazer. It'll talk in 4x mode fine, as long as you keep poking it over and over and over again...it just doesn't say much. In 1x mode it's been chattering with the a BCM from a Grand prix...they don't understand what the other's on about, but they keep trying to talk over each other as long as I keep poking them with a data request. All I have to do is listen, send a few commands, try to get appropriate responses, and go on about it. To test the hardware, I don't need to care that the PC can actually accomplish anything with the PCM/BCM...just that the hardware converts VPW messages to USB serial and vice versa. Is it a useful test? For me, yes. For you, no-you are looking to do meaningful communication...which my test setup doesn't try to do. It just tries to get as many VPW messages on the bus translated and interpreted as possible without glitches or mangled frames.

The big reason for testing this way due to the way Arduino handles inputs and outputs, if you use a digitalRead(IOPIN) function, that takes 4.78uS to read and store the incoming data-so considering that our "short" pulsewidth in VPW 4x mode is 16uS, the processing time is a considerable portion of the short pulsewidth. I needed to make sure that I could reliably decode 4x mode without having the quality decay over time due to processing overhead.

As I said in my first response to this thread, I'd be glad to help with the hardware development of this project. That's all I'm good for. Since you aren't interested in the hardware, I'll just continue on with my project, and it can either intercept with yours or not-either way, I get out of it what I need, and whether you benefit from it or not is up to you.

As many people who have tried to get a reflash tool working based around the ELM327 protocol and failed, I never saw a reason to pursue it. It won't be hard to add that functionality to my tool, as it's already an Arduino library and can be added relatively easily.

[steveo]

keep at it; i'm so glad someone is working on this.

if you get it working nobody will give a flying crap what kind of hardware it requires (as long as it isn't too complicated for the average guy to put together).

you should also consider that most LS1 tuners don't even know what a pull-up resistor or optocoupler is, and will probably do a messy job soldering these PCBs together, making the project hard to spread to the masses. perhaps consider having some chinese electronics manufacturer build 500 of them or something, then sell them for super cheap to support the project (software free, hardware cheap). it would be pretty easy to do.

[PeteS]

The libraries are where your slowing your self down. Switch to using tabs and write the libraries directly into your sketch, the compiler will optimize them better then as a library.



void reader_init() {
// For reader:
// PC5 input, pull-up
bit_RX = digitalPinToBitMask(input_pin);
port_RX = digitalPinToPort(input_pin);
if (port_RX == NOT_A_PIN)
{ Serial.println("BAD input PIN");
return;
}
Serial.println("Hi");
direction_RX = portModeRegister(port_RX);
out_RX = portOutputRegister(port_RX);
in_RX = portInputRegister(port_RX);
*out_RX |= bit_RX;
// enable pin change interrupt PCINT#
if(digitalPinToPCICR(input_pin)==0)
{
Serial.println("not interupt pin");
return;
}
*digitalPinToPCICR(input_pin) |= (1<<digitalPinToPCICRbit(input_pin));
*digitalPinToPCMSK(input_pin) |= (1<<digitalPinToPCMSKbit(input_pin));


reader_pin_last = *in_RX & bit_RX; // read pin state


// Timer1 setup CLK/64
OCR1A = 0x61A7; // will campare value of OCR1A against timer 1 for timeout
TCCR1B = (1<<CS11) | (1<<CS10); //CLK/64
TCCR1A =0;
TCCR1C =0;
// Timer1 enable Output Compare 1 match interrupt
TIMSK1 |= (1<<OCIE1A); // if OCR1A matches timer interupt will happen
// notes:
// 100,000us = 0x61A7 (CTC timer max)
// 64us = 15 (small bit period)
// 128us = 29 (large bit period)
// 200us = 46 (Start Of Frame period)
// 768us = 177 (Break period)
}

Maybe this will give you a better idea of what we are doing.

When you say Elm327, perhaps you should clarify. DO you mean the Elm chip specifically or a device using the Elm command set? I personally have read a bin file out with an Elm327 over Bluetooth. I've written the Vin, Serial,Bcc,Os Id and a bunch of other parameters using an Elm "Type" device.

And from someone who has a done a bit more then I have....


I can get it doing 180 byte packets and 4x now with firmware mods. Will work with you on this project. I have working write on the avt now but im not happy with the code and am time poor. This packet size is a bit small but its enough and can be improved further.

The issue wasn't that the Elm couldn't do it, it was how fast it could do it. Like I said you can go all the way down to 1 byte to do this with it's just a matter of speed. Some... if not all of the most knowledgeable people that have every worked with this stuff have/are contributing to what we are doing either by providing past work they have done or assisting with our current work.


Now if you would like to assist with hardware I'd be happy to talk to you again, but we are already a long ways into this and are not likely to "Jump Ship" on any thing we currently have. It's taken us a long time to get to this point and have had to prove our work/intentions to an awful lot of people to get the assistance we now have.

[PeteS]

keep at it; i'm so glad someone is working on this.

if you get it working nobody will give a flying crap what kind of hardware it requires (as long as it isn't too complicated for the average guy to put together).

you should also consider that most LS1 tuners don't even know what a pull-up resistor or optocoupler is, and will probably do a messy job soldering these PCBs together, making the project hard to spread to the masses. perhaps consider having some chinese electronics manufacturer build 500 of them or something, then sell them for super cheap to support the project (software free, hardware cheap). it would be pretty easy to do.

Really trying to stay away from any type of "Hardware" sales, any time you bring money into a project like this it always goes amuck. Now finding an existing company that's trust worthy to build/sell and ship could be a possibility. I would expect this to end up with several avenues for use letting people decided "How" they want to use it and what they are willing to invest to do it.

[Xnke]

The libraries are where your slowing your self down. Switch to using tabs and write the libraries directly into your sketch, the compiler will optimize them better then as a library.


In Arduino, library usage itself imparts zero penalties, it's all tied together during linking. Using functions like digitalRead/digitalWrite incurs penalties because they do a lot more than just reads and writes, thus using direct port control speeds up the reads/writes by between 27 and 30 times. It's just more difficult to get the library to be portable that way, because you have to define the pins by hardware addressing, not the arduino's much more convenient methods. So, right now the library (what's written of it so far) would work on an Uno, micro, mega, Teensy, etc...all you would need to do is buy an Uno and then stick the VPW level shifter on it, and boom, you've got a cable. Easy to make a "OBD-2 shield" that speaks ELM, AVT, direct binary, whatever you want it to talk on the PC side of things, but the issue is that it's borderline capable of doing 4x mode on the Uno, unless I write the library in such a way that it changes the library for the target device (which can be done, but I've never done it)

Using 180 byte packets and 4x mode, it takes a maximum time of 6660 uS per packet, and a minimum time of 3780 uS per packet. That's an average packet time of 5220 uS per 180 bytes. A full 512K flash would take 2845 packets, for an average time of 119 seconds to transfer the data. At 1x mode, that's still just under 8 minutes to do the data transfer across the VPW bus. How much time is lost in the turnaround on the ECU side, do you know?

I'm not asking anyone to "jump ship" on hardware. You started out this thread by saying you were using arduino for the hardware, and that it took a very long time to do it. I have some experience with using the arduino to do VPW, and had the intention of helping you speed your arduino hardware up, as well as make it more flexible-but now you seem to be using Scantool.net stuff, so it seems irrelevant. You mentioned using Dimented24x7's tools, which use the AVT protocol, and it's what I use now-so I was excited that you were essentially finishing his project where he left off. Now it seems that you're committed to the ELM327 protocol, which is fine-but it isn't what any of the other working tools out there have used, and I would add support to my hardware for it *if* it was what you were planning on using. You seem rather non-committal on what hardware you plan to use, maybe all the project members are using different hardware, no one but the project members know.

Whatever you come up with, will probably work, and it'll be whatever it is. For me, I'm happy using the tools already available for the 512k PCMs, I'll just have to wait till 1Mb support comes around.

[kur4o]

I was looking for some flash chips and stumble upon this link.
https://www.ebay.com.au/itm/LS1-PCM-FLASH-TOOL-VT-VX-VY-VZ-COMMODORE-V8-COMPUTER-5-7-MAFLESS-OTR-TUNING-VATS-/162108316648

The interface resembles one of the free ls1 flash tools released recently, but a later version. And the cable is some custom made one with a controller and some transistors.

I hope this thread doesn`t end that way.

[buddrow]

That tool does look awfully familiar...one if the gents down under...

[PeteS]

Trust me this won't end up that way......or be nearly as big of a disappointment.

He really should update the screen shots as well, the program is has been at V1.18 for a couple of years now. Someone in the US bought one of those and found out it was incompatible with a great deal of the OS's used here in V1.17 of the program.......:innocent2:

A lot of people were unknowingly supplying information that was used to make that program.....it was a good reason that so many people stopped working on similar projects and were very skeptical to help anyone else that was working on the same type of project. But I think were past that point now :thumbsup:

[cmaje72]

Well this is awsome! I have not been to this site in a long while. I went back and forth with Dimented way back when he was figuring out the first flash tool. Got an AVT cable and did some testing. I can probably help out with the XDF side of things. Its been a while though. Gotta hit that other thread and see whats going on.

[Devine]

i may be shooting in the wind here but have you looked at the macchina M2 at www.macchina.cc its suports all obd2 protocall i bought one a few weeks ago but lack the wits to use it its arduino due based

[Devine]

just hoping to help out on finding fairly cheap hardware interface

[PeteS]

It has been looked at and isn't even close to being up to the task. Currently there are 5 interface's being considered for support. It's very likely this project will not be tied to one specific device like you might expect. Cheaper hardware will work no diffrent then high end devices like the Avt-852. The only thing that would change is how fast a given device takes to do the same thing. What takes 2 minutes to complete with one may take 10 minuites with another one. Users will be able to decide what's more valuable to them, time it takes to flash or how much the hardware costs.

[Devine]

i understand well i got 5 cardaq j2534 passthrough devices laying around if any of those could be of use id like to see a opensource flash program one day that could be configured pretty easy with a few drivers for multiple devices thanks for info on macchina ill put i up in the drawer as a play around device

[PeteS]

i understand well i got 5 cardaq j2534 passthrough devices laying around if any of those could be of use id like to see a opensource flash program one day that could be configured pretty easy with a few drivers for multiple devices thanks for info on macchina ill put i up in the drawer as a play around device

A j2534 device is on the list. In theory it should be compatible with all J tools when it's done but since this is a gray area that no one has tried yet it's hard to say for sure. The J tool being considered is the VXdiag Nano.

[NSFW]

Edited...

So my first thought was, that's awesome. At the very least I'm sure we can use it as an interface device. This thing has a ton more potential beyond that, though. I'm getting one.

But then I saw what Pete wrote about this thing not being up to the job. That's a bummer. :( We'll have to keep an eye on it though. If they add what we need for reflashing, that thing could be great.

Are they missing 4x support? Or does VPW just not work right at all?

[NSFW]

I just read on their forum that they got 1x VPW working late last year, but I don't see anything about 4x. It's a start... Definitely something to keep an eye on.

...and I just looked at the code they have to support 1x VPW, and it has a message length limit of 12 bytes, including the CRC byte. That might be easy to change (just bump the "12" limit to "2000" and see what happens) but it might not (bad things could happen).

It's still pretty intriguing though, I'm sure the hardware they're using is more than capable of high speed and large messages. If someone takes care of the firmware I'll gladly add support for this thing in the app.

[PeteS]

Lots of work has been going on. Ardunio is now able to read data in 4x mode with 4K blocks no trouble. Still working on the transmit side of things.

Arduino code and diagram for 1x is on the github project now. No flash kernel is provided since we still don't have one we can share....but soon we will.

Nsfw, Antus and Tazzi have been doing some serious work on the software side of things. Wheels are still rolling on this.

[antus]

Yep, were getting somewhere with it. Lots of hardware drivers work, basic functionality in place. All code so far is up on github, and pulling basic data from pcm + vinchange is working on all ELM compatible type devices with long packet support (thats scantool, allpro with custom firmware), avt 852 (842 untested, but should work) and Tazzi's J2534 driver is working in his hardware and ive tested on GM MDI. Bridging the differences between ASCII encoded hex (ELM style) and binary streams (AVT and J2534) was a bit of a challenge but we got that under control so the app core can just send Message data and let the layers under that deal with it.

[PeteS]

Yep, were getting somewhere with it. Lots of hardware drivers work, basic functionality in place. All code so far is up on github, and pulling basic data from pcm + vinchange is working on all ELM compatible type devices with long packet support (thats scantool, allpro with custom firmware), avt 852 (842 untested, but should work) and Tazzi's J2534 driver is working in his hardware and ive tested on GM MDI. Bridging the differences between ASCII encoded hex (ELM style) and binary streams (AVT and J2534) was a bit of a challenge but we got that under control so the app core can just send Message data and let the layers under that deal with it.

Add the VxDiag Nano to that list of J tools as well :happy:

[kur4o]

I can get you any vpw factory flash write routine + basic commands list and seed/key algo number by a vin number.
The offset address the bin starts and the chunk size.
All you have to do is figure where in the ram the routine is loaded and if some of the stuff is overwritten.

Gm even assigns them a part number, so you can make a list based on car, model, pcm used.
I compare two flash routines for 1mb pcm and it was 1 byte difference/2004 y-body vs 2005 truck/. It could be intel vs amd flash.
Does intel /amd pcm have different hardware part numbers.

[PeteS]

I can get you any vpw factory flash write routine + basic commands list and seed/key algo number by a vin number.
The offset address the bin starts and the chunk size.
All you have to do is figure where in the ram the routine is loaded and if some of the stuff is overwritten.

Gm even assigns them a part number, so you can make a list based on car, model, pcm used.
I compare two flash routines for 1mb pcm and it was 1 byte difference/2004 y-body vs 2005 truck/. It could be intel vs amd flash.
Does intel /amd pcm have different hardware part numbers.

That's very interesting.....I it might be outside the scope of this thread currently so I'm going to PM you about this until I know exactly how/if this would be useful for what we are working on.

[PeteS]

Quick status update for this forum.....

The "Pcm Hammer" Pc program has been coming along slowly, drivers and formatting has just about been worked out for 7 commercially available tools so far. Once the framework is complete and the tools are all working with the same program core we can start working on adding in the block mode and start reading data back from the pcm.

For mobile use the Android+Bluetooth development is also coming along nicely and has just started to read data in block mode.


https://www.youtube.com/watch?v=JsvUkCJy_8E&feature=youtu.be

[KC5UEA]

Hi Pete,

Looking good so far. Any idea when you will release this one? I have v1.7 on a phone - just can't do anything with it as I don't have a working adapter YET!
Also, is this going to support the AllPro USB with an OTG cable?

Mike

[CDeeZ]

Keep up the excellent work! It's definitely time to have an open source option for this. Some of these LS PCMs are ~20 years old now.

[blundar]

PeteS, you may find this useful:
http://www.gearhead-efi.com/Fuel-Injection/showthread.php?7286-Gm-Seed-key-algorithms&p=70883#post70883

[PeteS]

There hasn't been much to talk about in this thread recently and I've had a lot of questions asking what the status of this project was since it just kind of seemed to fade away over the last month or so, that was the calm before the storm......




https://www.youtube.com/watch?v=Gc44bJOBUaQ&amp;feature=youtu.be

[Xnke]

Nice. Does this mean you're using your own open-source flash kernel now or are you still using the LS1Flash closed-source kernel?

[NSFW]

The kernel is closed source but we have permission to use it and I think we we will soon have permission to distribute it.

[Xnke]

How's the UI stuff going? Is the hardware abstraction layer stuff working out well? Which interfaces did you ultimately stick with so far?

[PeteS]

How's the UI stuff going? Is the hardware abstraction layer stuff working out well? Which interfaces did you ultimately stick with so far?

Working out the last of the bugs and tweaking a few things to improve read times with some of the tools. We are pretty close to being able to release a "beta" version that will work in a vehicle as well as it does on the bench.

Tools we have tested to be 100% working for read at this point....

Obdlink Sx (Usb), Lx(BT), Mx(BT) - 1x speeds with 512 byte blocks and by far the slowest but manageable on a bench.... in car you'd need a damn good battery with 1mb pcm's. $30 -$80 price range depending on device

Allpro (USB), Allpro Development board(Rx/Tx headers), Allpro "kit"(Rx/Tx headers) - 4x speeds W/2048 byte blocks. 512K pcm is around 7 minutes, 1mb is around 15 minutes but these times will get faster as we make improvements. $25-$35 price range depending on device. **The Bluetooth version is currently not working however you can add an HC-5 BT module($4.00) to either of the boards with Rx/Tx connections to make it BT**

Avt - 852 is smoking fast and will be a contender for any commercial tool. Expect $300 depending on what options you order one with. The Avt-842 "Should" also be working but we have not verified.

J 2534 - This one's interesting, the quality of the device has a HUGE impact on read times but so far every J tool genuine and clone's(quality clones) has worked with out an issue. MDI, Vxdiag Nano, Mongoose etc are all working with out issue. A quality MDI clone is comparable in time to the Avt-852 but the Avt still win's. The Vxdiag is significantly slower then the MDI and is more in line with the Allpro for speed. $90-$2500 price range

At this point every tool we set out to support is working, some are much faster then others but that was to be expected. The real deciding factor is cost of the interface but that was the intention of all of this. The end user will be able to decide how much or how little they want to spend to be able to get into programming. While the J tool is pretty expensive for a lot of them these are also very common in automotive shops where a lot of people work (or have friends that work) and would have access to them making them still accessible to a lot of people.


Things on the todo list still include cleanup and some minor bugs and a final version of the flash kernel. Antus from Pcmhancking has shard a couple different kernels we've been working with for testing but he hasn't decide what the "release" version of the kernel will be at this point. Antus has been working on extensive firmware changes to the Allpro and working directly with the company to improve and fix some bugs we had with it. Once that's wrapped up I'm sure he get the final version of the kernel worked out. There has been talk of adding compression into the kernel but we're not sure how the "Elm" stuff would like it, compression can DRASTICALLY speed up read times, for example the 1mb pcm's only take around 20 seconds longer to read then the 512Kb pcm's do. It's a huge gain but it may create more problems at this point so it's still up in the air.

Once a read only version is out and no one finds any major bugs we've missed a calibration only write will be next on the list will hopefully be working this summer, once that's done a full OS write will be the last thing that's added and will be a ways out at this point.

There are a couple of people working on Xdf's as well but coverage will be spotty on the 1mb's for a while yet. There are a LOT of os's and each one takes a good bit of time to create. I'm in talks with a couple of people that have partial Xdf's on the 512k pcm's......if they were to "donate" them to the cause and they were finished it would give almost complete coverage for the 411 and 0896 pcm's.

[Xnke]

Right now there are some pretty complete XDF's for the 512K PCMs, as you really only want to use the 2002 unified OS for most swaps. The unified OS lets you easily swap blocks to get the engine/transmission combination right, and has the widest coverage of features out of all of the other OS's.

As to the 1mb PCMs, we haven't had a free/inexpensive way to read/write them that didn't already have the ability to edit the PCM, so not too many people have messed around with them yet. Once your tool is released, I don't expect it will take very long to get a WIDE variety of XDF/ADX contributions. I believe we already have a few people working on the blue/clear PCM as well, I've done some work with it and EJ282 has done some. Those applications will likely be slower to come to fruition, but as the hardware is very similar, it won't take too long to get them all going, I think.

[PeteS]

Right now there are some pretty complete XDF's for the 512K PCMs, as you really only want to use the 2002 unified OS for most swaps. The unified OS lets you easily swap blocks to get the engine/transmission combination right, and has the widest coverage of features out of all of the other OS's.

As to the 1mb PCMs, we haven't had a free/inexpensive way to read/write them that didn't already have the ability to edit the PCM, so not too many people have messed around with them yet. Once your tool is released, I don't expect it will take very long to get a WIDE variety of XDF/ADX contributions. I believe we already have a few people working on the blue/clear PCM as well, I've done some work with it and EJ282 has done some. Those applications will likely be slower to come to fruition, but as the hardware is very similar, it won't take too long to get them all going, I think.
Some of the people that wrote the Xdf's your referring to are the one's working on the 1mb Xdf's now :thumbsup:

There is a VERY good change the other Pcm's your talking about would be compatible with the software we are working on but would need a different flash kernel. The commands to read haven't changed much over the years....even the CAN pcm's use the same commands with a couple of extra bytes tacked onto the end.

[PeteS]

This just in.........Android is now a up and running. Tested in vehicle tonight using an Allpro dev board with Bluetooth Hc-5 module....verified my Bin file was correct with EFI Live and it passed with flying colors:rockon:


https://www.youtube.com/watch?v=gFFHPOCvRJM&amp;feature=youtu.be

[Xnke]

On the blue/clear PCM-when I say the hardware is very similar-I mean it's *VERY* similar. It's used with the LS4 V8, as well as most all the 60*v6's and the shortstar V6's, so as you say-might need a slightly altered flash kernel, but it is contemporary to the 512K and 1Mb LS PCM's.

LSDroid is looking pretty cool-combined with a decent OBDII datalogger, it could be pretty powerful.

[kur4o]

I see your bigest obstacle is the flash routine.
Can you add an option for user provided flash routine with some small config file containing data as seed/key algo used and some basic stuff as commands and how the bin is dumped to memory.

I found that all obd2 gm pcms support mode 3a and 3b to stream data. When the PCM is configured It starts to dump continuous data with 8 messages containing 6 bytes of data each. So you got 48 bytes with super fast refresh rate. It will be nice addition to read/write functionality. I know that elm devices have some built in inability to recieve more than one message. That can easily be overcomed with monitor all command when the pcm is configured and starts dumping the data.

If you want to add it to the android application I can give you more details.

[Xnke]

How's this going? Haven't heard from you in a while, Pete!

[PeteS]

How's this going? Haven't heard from you in a while, Pete!

Waiting for Antus to finish a kernel for the Pcm Hammer or at least release some variant of the flash kernel we used for development so people can use this for at least reading with and any remaining bugs could at least be sorted out.

[PeteS]

I'm just gonna leave this here......

13301

[CDeeZ]

Pete, I'm not going to lie, while I feel I know more about computers and electronics than the average joe I still have a lot to learn from people like you. What does that mean exactly? I know you post on LS1tech, I'm over there also.

I Appreciate everything you do, even though I don't understand 100% of it. I know you got some flak from at least one dude on tech. Haters gonna hate.

[PeteS]

Pete, I'm not going to lie, while I feel I know more about computers and electronics than the average joe I still have a lot to learn from people like you. What does that mean exactly? I know you post on LS1tech, I'm over there also.

I Appreciate everything you do, even though I don't understand 100% of it. I know you got some flak from at least one dude on tech. Haters gonna hate.

Thanks, nice words like that go a long ways when doing things like this. I'm far from an expert with any of this but I'm doing what I can to make this happen and help others along the way when I can.

[dzidaV8]

It's nice to see that you are progressing! I've been away for a while and didn't have time to participate, but I got some stuff cleared out of my way and I'd really like to take part in this and help.
I had a lot of free time this week as I was curing a flu, so I took my OS12212156 xdf and updated it to 12587603 2004 vette OS. It should also work with 12592425 and 12585950 OS bins, which seem to share the same calibration.

BTW, with OBD2 xdfs coming, it would be nice to increase forum attachment size limit for xdf files, as this one already doesn't fit :)

[PeteS]

It's nice to see that you are progressing! I've been away for a while and didn't have time to participate, but I got some stuff cleared out of my way and I'd really like to take part in this and help.
I had a lot of free time this week as I was curing a flu, so I took my OS12212156 xdf and updated it to 12587603 2004 vette OS. It should also work with 12592425 and 12585950 OS bins, which seem to share the same calibration.

BTW, with OBD2 xdfs coming, it would be nice to increase forum attachment size limit for xdf files, as this one already doesn't fit :)

Thank you for sharing the Xdf, it will be greatly appreciated by many I'm sure.

[PeteS]

I don't have anything to update progress wise on the Pcm Hammer but I do have some updates on the Android app I've been working on for a while now.

I've been in contact with OBDLink and they have been kind enough to provide with with some commands not published in any of the literature they would normally provide developers since the commands are basically untested in the developed field..of course they have been tested internally and work fine they've just never had the limits pushed to see what they are capable of in a real world setting.

Well the commands are amazing, previous read time with my app was almost 30 minutes for a P01 and nearly an hour on the P59. I rewrote a good section of the app to work with the new command structure and I about fell over. The P01 is down to 12 minutes on the Pixel 2 and a hair over 13 minutes on an S6. The P59 is now just over 20 minutes for a complete readout, that's still a but long but it's a hell of a lot better then an hour like with the previous commands I had been using.

There is still a LOT of room for improvement on my end in the app itself, I'm loosing over 3 minutes on the block sum calculation's alone on the P01. That figure can be doubled on the P59 meaning once I get the speed of the sum's improved it's going to cut a considerable amount of time off this again. I'm aiming for read times on the P01 of under 10 minutes and less then 20 on the P59......but I've got some work to do still to get there.

And just so there's no confusion.....this is being done in 1x mode:yikes:

[dzidaV8]

I don't have anything to update progress wise on the Pcm Hammer but I do have some updates on the Android app I've been working on for a while now.

I've been in contact with OBDLink and they have been kind enough to provide with with some commands not published in any of the literature they would normally provide developers since the commands are basically untested in the developed field..of course they have been tested internally and work fine they've just never had the limits pushed to see what they are capable of in a real world setting.

Well the commands are amazing, previous read time with my app was almost 30 minutes for a P01 and nearly an hour on the P59. I rewrote a good section of the app to work with the new command structure and I about fell over. The P01 is down to 12 minutes on the Pixel 2 and a hair over 13 minutes on an S6. The P59 is now just over 20 minutes for a complete readout, that's still a but long but it's a hell of a lot better then an hour like with the previous commands I had been using.

There is still a LOT of room for improvement on my end in the app itself, I'm loosing over 3 minutes on the block sum calculation's alone on the P01. That figure can be doubled on the P59 meaning once I get the speed of the sum's improved it's going to cut a considerable amount of time off this again. I'm aiming for read times on the P01 of under 10 minutes and less then 20 on the P59......but I've got some work to do still to get there.

And just so there's no confusion.....this is being done in 1x mode:yikes:

That's great! Are you using some kind of compression in transmission?

[PeteS]

No compression, just a much faster baud rate then 115200. I don't recall how much faster but it was in the 900,000's range. It can't speed the pcm up but it does speed up how long it takes to send data from the device back to the Android App, this is one thing that the BT devices apparently can do much better then USB devices.

The new command set eliminates the need to use "Elm" header change commands or send send any type of command to the interface that isn't getting some type of data. It also has allowed me to skip past any type of adaptive or fixed timing, I'm able to specify how many responses the tool should wait for. While this may not seem like a large gain it eliminates a LOT of unnecessary commands being sent or time spent waiting before the tool closes the port and returns the data to the app.

[PeteS]

It's taken a lot longer then I had hoped..... but better late then never.... so here ya go.

13406

It's currently read only so you'll need to wait a while longer to flash anything back to pcm; stability is the most important thing at this point as I begin working on the write code to flash a file back into a pcm.

Works with the Obdlink Lx/Mx Bluetooth devices and Android 6.0 and up. It may work on older version of Android but it has not been tested.

Works with the P01 and P59 pcm's and will save the complete binary file from the pcm in .bin format.

P01 takes 10-12 minutes to read and the P59 is 20-25 minutes.

Vin number works on both the P01 and P59 as well.

Serial number change only works on the P01 and not all OS's for these pcm's are currently supported.

This is 100% free...nothing to buy.....no adds...no strings attached.

Download links, instructions and related questions can be found here: https://ls1tech.com/forums/pcm-diagnostics-tuning/1885809-android-elm327-pcm-flash-app-ls-droid-read-only-released-12.html#post19993353

[Xnke]

Any plans for a laptop-based app?

[PeteS]

sure.....was waiting for someone to ask :thumbsup:

https://github.com/LegacyNsfw/PcmHacks/releases/tag/PcmHammer

Support thread can be found here....
https://ls1tech.com/forums/pcm-diagnostics-tuning/1892142-inexpensive-opensource-flashing-read-100-working.html

[NISANDA]

So this Bin files can be used/supported with what Programs?

[PeteS]

The bin file can be edited in Tuner Pro if you have an XDF for the OS number your working with. We are now working on the write side of the program that will allow flashing the altered file back into the pcm but we don't have an ETA how long it's going to take to add write to this.

[fastrun86]

Hi PeteS i would be interested in a program that just lets me change vin #s on 411 conversions,etc. since my hptuners wont let between operating systems. please pm me if you can help. i dont mind paying some if i have to for your troubles

[PeteS]

If you look back a couple of posts there is a link to the Pcm Hammer and my Android app. Both are "Read Only" but both will change a vin number with out an issue.

[3400tZ]

That's an amazing project. Just read the whole thread, very interesting!

If you guys want me to add support for all this into ALDLdroid so that you can have the read/write operations and tune editing all in one Android app over Bluetooth/USB, I might be able to do that. Just hit me up at aldldroidapp at gmail.com :)

[PeteS]

One of the very first posts on what was required to Read or flash a PCM that I read was written by EagleMark. It's a shame he's not around to see this happen, but the trail of bread crumbs he left behind is what lead me to work on this in the first place.

I feel privileged that I'm now able to come here today and finish his legacy. We've had read and write on the 411 for a few years now but it was costly and I know that Marks vision had something a whole lot bigger in mind...

So this one's for Mark - I used an Android phone and a $35 Bluetooth device to 100% clone a P59 tonight, this should make every one smile a bit..


https://www.youtube.com/watch?v=DYc3lrYagqg&feature=youtu.be

[1project2many]

Hi Pete,

I believe it's fair to say Mark would really appreciate this. It's going to be a great tool. It's amazing how many times a project like this has started only to die or turn into a for-profit solution over the years.

Thank you very much.

Also wanted to note, with humor, the auto suggest options at 2:12.

[NSFW]

Write support has been released. Please read and heed the warnings though...

https://github.com/LegacyNsfw/PcmHacks/releases/tag/2018.12.30.01

You can also find the latest release by going to http://PcmHammer.org and clicking the Releases link.

[kur4o]

Write support has been released. Please read and heed the warnings though...

https://github.com/LegacyNsfw/PcmHacks/releases/tag/2018.12.30.01

You can also find the latest release by going to http://PcmHammer.org and clicking the Releases link.


After 6 months of silence, I thought this project was dead, . Or mutated to a commercial release.

And now it exploads. You should have gotten some strong motivation to finish the job.

I read about that checksum issue you had, and it got me a little worried, how stable is the whole thing.
I hope you know what your doing and the final product be worry free.
Is there anytime soon a OS change option added. That is what matters most, since dimented tool can do a cal data write already.


Do you have any plans to make the tool complete with some datalogging and realtime control. Analizing the trim logs will be nice addition.
Some guys here have huge experience with similar products for earlier GM controllers and can be of big help to you.

I also ripped the GM block logging, modes 3A and 3B, and realtime control Mode AE. This works a lot faster than any of the available logging tools available now.


Keep up the good work and get for the community a nice and useful tool.

[NSFW]

After 6 months of silence, I thought this project was dead, . Or mutated to a commercial release.

And now it exploads. You should have gotten some strong motivation to finish the job.

I read about that checksum issue you had, and it got me a little worried, how stable is the whole thing.
I hope you know what your doing and the final product be worry free.
Is there anytime soon a OS change option added. That is what matters most, since dimented tool can do a cal data write already.


Do you have any plans to make the tool complete with some datalogging and realtime control. Analizing the trim logs will be nice addition.
Some guys here have huge experience with similar products for earlier GM controllers and can be of big help to you.

I also ripped the GM block logging, modes 3A and 3B, and realtime control Mode AE. This works a lot faster than any of the available logging tools available now.


Keep up the good work and get for the community a nice and useful tool.

The project was never dead, we just had other things come up in our lives that took up too much of our time. All of us are doing this in our free time, so when we don't have free time, we don't have progress.

The checksum issue was a problem with the XDF that I was using, not with PCM Hammer itself. The contents of my .bin file were written to the PCM correctly!

I think the app is good, but the only way to know that it is good is to have a lot of people try it, and prove that it is good. As we have more proof, we can all have more confidence in it.

We also want to add some features to the app
to prevent users from making mistakes, like mixing incompatible files, or flashing when the voltage is too low.

It is good enough to use it to reflash PCMs that are on a workbench. Those of us who are working on the app have done that a lot.

It is good enough to use it on a car that isn't one that you need to get to work, or to get groceries. I got that confidence after successfully flashing my car three times.

When we have a LOT more reports of successful in-car flashes, that will give me the confidence to recommend using it more widely. That will also give me the confidence to add support for OS flashing. It will require only tiny changes to the code. I just don't want to make those changes until I have more confidence. Recovering from a bad calibration or checksum flash is relatively easy, but recovering from a bad OS flash is hard.

[babywag]

I am very excited! Finally a reality?
I have an LM7 on an engine run stand and a few 0411 pcm(s). Looks like I need an SX USB model from scantool.net?
If you need some testing I'm game.
Is there a good TunerPro .xdf for a particular OS out there. I recall trying one and .bins always had errors when checked against EFILive.

[NSFW]

The Scantool interface is the slowest of the bunch.

I use and recommend the USB version of the AllPro, which is available here:
http://obddiag.net/products.html

The web site is a little bit cumbersome - you have to add the product and shipping costs yourself. :) But that's because the guy who is making and selling these great interfaces is just... a guy who is making and selling great interfaces.

There are good XDFs for a few OSes, we have collected a few of them here:
https://github.com/LegacyNsfw/PcmHacks/tree/develop/XDF

I know there are more out there, but we need to work on consolidating them. In addition to finding the files themselves, we also need to find the authors, and get permission to host copies of the files. If anyone wants to help with that job, that would be great.

[CDeeZ]

Pete and NSFW, Et al. Thanks for the hard work. You guys are a vital asset to the community.

[DavidBraley]

I agree with CDeez. This project has opened doors for me and many others that didn't exist before. I am super grateful for this work.

[PeteS]

I have sent out copies of my Android flash app to a hand full of people for testing but its been slow getting feedback. No one has broken a pcm yet that I'm aware of and every one testing has used it at least once for a full flash. While I'm pretty sure there should be no major issues I'm still being very cautious before publicly posting the app.

With that being said if any one would like a copy or the write side of my LS Droid app send me a PM or email and I'll get you a copy. Its only been tested on Android 6.0 and up but it may work on older versions. As for hardware it only works with the Obdlink Lx and Mx bluetooth devices. It supports 3 modes of flashing for the P01 and 3 modes on the P59. They are calibration data only, OS+Calibration or PCM cloning. Flashing only the calibration data takes around 3 minutes for either the P01 or P59. Changing an OS on the P01 is around 12 minutes and Cloning is around 15 minutes. The P59 times are not quite double what the P01 are for OS+Cal and cloning.

While it is unlikely that the app will have an issue this a possibility a flash may fail. That doesn't mean the PCM is really bricked it just means I'd need to work with the person 1 on 1 to sort out what happened and what needs to be done to make the pcm functional again.

[PeteS]

SO we have ways to read and write a pcm now.....next we'd need to be able to make changes to the file.

Flashing was what has been missing all along, there have always been ways to make changes to the file there just wasn't a lot of coverage. Well many others have been working on things behind the scene gambling with their time if this was actually going to happen this time around. A long standing member on this forum dusted off his keyboard several months ago and has been working on expanding coverage for tuner pro and has created a bunch of new XDF's adding a great deal of coverage to what we can now tune for free.

To keep this thread on track for things flashing related here is the link to the newly developed XDF's
http://www.gearhead-efi.com/Fuel-Injection/showthread.php?7676-Free-LS1-Tuning-Software-(all-you-need-is-TunerPro)

It's people like LRT that we are going to relying on to expand tuning coverage so make sure you show him some appreciation for the work he's done.

We've still got a ways to go on the flashing software for PC and Android but I think the hardest parts are now behind us, for the first time ever people actually have a choice on how they want to flash a pcm and how much they want to sped doing it. With the Allpro firmware development Antus@Pcmhacking did last year; the cost to buy the hardware needed to flash a PCM is next to nothing. We went from no options to the cheapest computers out their to work with in less then a years time and I'm betting no one ever expected it to happen like this.

[NSFW]

PCM Hammer Version 4 is ready for testing:
https://github.com/LegacyNsfw/PcmHacks/releases

The biggest improvement in this release is that the app will prevent you from writing if the operating system in the PCM doesn't match the operating system in the file you have selected.

If you run it while connected to the internet, it will check github for a new release. Ordinarily it will just say "Thank you for using PCM Hammer" when it starts up, but when we have a new release that will change to something like "Hey, we have a new release!"

[NSFW]

Version 5 is out:

https://github.com/LegacyNsfw/PcmHacks/releases/tag/2019.02.09.01

A couple people reported that the app wasn't working with their AVT interfaces, and this release fixes those issues. Reads and writes with AVTs got a little faster, too.

[PeteS]

I'll apologize in advance for a generic copy/paste here but I've got a lot of forums and groups to update still.

Ls Droid is now in open beta....
Currently only read is enabled for the P01/P59, 98-05 V6(exact coverage unknown) and the 2001 -2004 LB7.

Once I'm confident there aren't any major hiccups I will enable ALL forms or write on the P01 and P59. V6 and Lb7 flash are still in the development stage.

This is the last version of the app you'll ever need. All future updates can be done from within the app. As the app is updated things may change that you don't like So I've decided to make avaible ALL previous versions of Ls Droid that are stable from this point on and can also be downloaded from with in the app.

For those that are feeling daring I've also included the P01/P59 Alpha Write version(Can be downloaded from with in the Beta app) This version was in testing for the last 4 months and only had a couple of users run into issues BUT I would strongly advise against using it on your daily driver as it does have some bugs.... and does not play nice with some vehicles. I am no longer offering support for this version of the app so if you run into trouble with it your going to be on your own.

Ls Droid is currently ONLY compatible with the Obdlink Lx, Mx and Mx+ Bluetooth devices. However a new tool will be supported in the near future that is more then 4x's faster then any of the Obdlink devices and also costs a bit less less :)

14137

You can email me about any bugs or issues you run into.....
feedback@ls-droid.com

[NSFW]

Right on, Pete!

[NSFW]

PCM Hammer Release 6 is out: https://github.com/LegacyNsfw/PcmHacks/releases/tag/2019.06.22.01

There's now a "Write OS and Calibration" button that replaces everything but the parameter blocks, which is useful if you want to update the operating system in your vehicle. Leaving the parameter blocks unchanged means the PCM will still be recognized by the other devices in your car.

If you want to replace your PCM, do a full read from the current/old PCM, then "Write OS and Calibration" then "Write Parameters (Clone)" to the new PCM. The entire flash memory of the new PCM will then be completely identical to that of the old PCM.

[brian617]

Will a Tractrix open port 2.0 cable work for this? Just bought one to tune me Subaru.

If not can someone make a cables for dummies post so I know what to order.

The link to the Allpro usb board just confuses me.

OBDlink the easy solution for a PC language challenged tuner?

[Xnke]

Now that the Allpro device is no longer available, what's the best device out there? OBDiag.net no longer sells that tool, apparently.

[steveo]

i'm just learning about this stuff (quickly) but for trying out these new free flash tools, right now probably got two options..

obdlink (bout $50 buy it on amazon) works with everything, not the fastest thing ever
avt852 (bout $300) fastest most reliable and overpriced thing ever, hard to get i think

i've heard a pretty reliable rumor something really nice might be coming out soon in the price range of an obdlink. if you're not in a huge rush and like to gamble maybe wait and see if that happens. the guy working on it is so stubborn that its unlikely it wont happen, just not sure of timing.

[NSFW]

i'm just learning about this stuff (quickly) but for trying out these new free flash tools, right now probably got two options..

obdlink (bout $50 buy it on amazon) works with everything, not the fastest thing ever
avt852 (bout $300) fastest most reliable and overpriced thing ever, hard to get i think

i've heard a pretty reliable rumor something really nice might be coming out soon in the price range of an obdlink. if you're not in a huge rush and like to gamble maybe wait and see if that happens. the guy working on it is so stubborn that its unlikely it wont happen, just not sure of timing.

That's a great summary of where we're at right now.

I've got a prototype of the rumored interface and it works great. I'm sure it's going to be the best option when it becomes available. I don't think there's an ETA for that, though. Last I heard, the guys behind it were still refining the design and working out how to get them produced in volume.

If you have a car you want to tune now, I'd say get the ObdLink and go for it. It works fine, you'll just get faster flashes if you buy the new interface later.

I'm not sure about the Tactrix, but if you have one, give it a try. They definitely support the J2534 standard, so the app should be able to talk to the device, but I don't know whether they support the VPW standard, so the device may or may not be able to talk to the PCM. Easy to test though - if "read properties" works, try a test write, and if that goes smoothly, you're good. I've been meaning to try it myself, but I don't know where mine is.

[brian617]

I'll give the Tractix a try, need to build a bench harness first. If that doesn't work I'm in no hurry and will wait.

Thanks Guys

[myburb]

I am going to work towards trying this. My computer that I use for tuning doesn’t have Bluetooth. I see there are several OBDLink units available. I see one that is OBDLink USB. Just to make sure, that one will work, right?

[NSFW]

The OBDLink SX is USB-only, and it is supported.

You might also consider getting the LX and a USB bluetooth adapter. I haven't tried that myself, but it should work just as well, and there are a bunch of adapters on Amazon for $10-$15 shipped.

All features work with all interfaces, the only difference is speed. This table is overdue for a refresh, but it gives you a rough idea of what to expect:
https://github.com/LegacyNsfw/PcmHacks/wiki/Read-And-Write-Times

The "DVI" row of that table is the one that's still being developed.

[THEFERMANATOR]

I have an SX cable and it takes me right at 50 minutes to read an 0411, haven't tried a full flash yet. I wished I knew how to make my TECH 2 work with it as that would flash ALOT faster.

[steveo]

I have an SX cable and it takes me right at 50 minutes to read an 0411, haven't tried a full flash yet. I wished I knew how to make my TECH 2 work with it as that would flash ALOT faster.

but how long just for the calibration?

...how often do you really need to flash more than the calibration?

[NSFW]

Calibration write with the SX is about four and a half minutes. Full OS write is something that you might never need, or might want to do once or twice - for example if you want to swap in a PCM that came from another car. Or if we start making progress on an open source custom OS, and come up with something useful. :)

[DavidBraley]

NSFW!

Just wanted to say !!Thank You!! for the work you (and others) have done to get this latest version of PCM Hammer out into the wild. I've been distracted with other stuff, but will get a chance soon to test this and I will report back. :thumbsup:

[THEFERMANATOR]

but how long just for the calibration?

...how often do you really need to flash more than the calibration?

That was just for a read, not a write. I've done 3 reads now on 2 different PCM's, and it has averaged 50 minutes for each read. Cal flashes were pretty quick though.

[PeteS]

I have posts up in so many places these days that I often forget to update posts from time to time......

With that being said.... I've been developing a tool with Envyous Customs as an alternative to the Allpro (since it is no longer avaible).... and I wanted something that would also work with my Android app over Bluetooth.

And it needed to be fast......


https://youtu.be/ImU5L5yQLTQ

[In-Tech]

Very cool. How many bytes are you writing in each block? Curious how you verify the write is correct? Thanks

[PeteS]

How many bytes are you writing in each block?

Ls Droid works with strings rather then bytes so packet size it a bit misleading here but my App is writing 2K blocks(4K characters).


Curious how you verify the write is correct? Thanks
Do you mean on each block or at the end of the flash?

Each block uses a checksum that the PCM verifies when a block is written. If the checksum calculated by the flash kernel does not match the value sent by the app the kernel will reply with a 7F message indicating the checksum is incorrect. Each block also has a size value attached to it that the flash kernel checks to make sure the block is complete. If the block is not the correct size specified there is also a corresponding 7F message that will be sent back to the app by the flash kernel.



When the flash is complete the app also checks for a complete write at the end in 2 ways, first it checks the kernel to make sure the correct number of blocks have been written and then it reads the last 2 bytes of the PCM by address to make sure they are correct. If either check fails the app will alert the user and the flash kernel will continue running and allow you to start the flash over again with the same file or with another file if you'd rather write something else.

[In-Tech]

Really neat stuff, I've tuned a few LT1's over the years but the progress you all have made makes me wish I had a LT1 to play with :)

Back in the days of crapola I was happy to find a rom routine that would do 40h bytes at a time, load ram,write,read,verify,incw,continue. I was doing that in a vb shell, non car stuff and the files were in the 18k range and could finish in a few seconds. I really like what y'all are doing and I am enjoying the reading :)

[PeteS]

I didn't forget this time......

In an upcoming update for Ls Droid I'll be releasing a segment swap utility to make it easier to build the ideal file rather then hunting down a file that matches the exact combination your running.




https://www.youtube.com/watch?v=mEDQ0Q2PzOA&feature=youtu.be

[NISANDA]

I didn't forget this time......

In an upcoming update for Ls Droid I'll be releasing a segment swap utility to make it easier to build the ideal file rather then hunting down a file that matches the exact combination your running.




https://www.youtube.com/watch?v=mEDQ0Q2PzOA&feature=youtu.be

this is great! news

[CarlsLQ9SS]

I have used ls droid and tunerpro to clone pcms, flash and delete vats, learning about the pe table and injector flow rates. Theres alot to it from what I am learning so far, a little overwhelming but neat stuff. Thanks to all involved in developing all of this!!!

[bigbill0679]

has this been released yet Kind Sir

[B52Bombardier1]

Hello,

Not only has it been released, it works very nicely. I have already used it to clone a PCM but I wrote a new OS+CAL tonight to my lab rat P59 PCM for the very first time using my bench wiring harness. No problems. I have not put this P59 into a vehicle but every OBD II app that I have reads it perfectly. This was a 1 megabyte BIN from a 2004 Chevy SSR truck that is considered to be the "universal donor" BIN for P59 PCM's because it has pretty much every feature anybody would ever need.

I used a matching XDF for the SSR BIN inside of Tuner Pro RT to make all the changes needed - VATS, EGR, EVAP, Fuel Level Sensor, Air Injection, Catalyst System Efficiency . . . everything.

Rick

[bigbill0679]

Hello,

Not only has it been released, it works very nicely. I have already used it to clone a PCM but I wrote a new OS+CAL tonight to my lab rat P59 PCM for the very first time using my bench wiring harness. No problems. I have not put this P59 into a vehicle but every OBD II app that I have reads it perfectly. This was a 1 megabyte BIN from a 2004 Chevy SSR truck that is considered to be the "universal donor" BIN for P59 PCM's because it has pretty much every feature anybody would ever need.

I used a matching XDF for the SSR BIN inside of Tuner Pro RT to make all the changes needed - VATS, EGR, EVAP, Fuel Level Sensor, Air Injection, Catalyst System Efficiency . . . everything.

Rick i was speaking about the ls droid video i saw with segment swapper but read on thread more and saw there is a delay due to tech diff. i was hoping this rolled out i do it now the same way u have stated .. i cant wait for xpro vt too be avail look up petes160plus youtube channel it shares teasers as i call them

[bigbill0679]

would you share 2004 ssr xdf and bin stock files or location

[NSFW]

PCM Hammer Release 14 is out!

Improvements in this release:

- Reflashing is reliable with the new ObdX Pro devices.

- Reading and writing are significantly faster with AllPro devices, and slightly faster with ObdLink devices.

- And a few minor bug fixes.

To get the zip file, go here...
https://github.com/LegacyNsfw/PcmHacks/releases
...click "Assets" at the bottom of the release description, and click the zip file.

Extract the zip file to your hard drive, and have fun.

If you're not familiar with PCM Hammer, you might want to read this:
https://github.com/LegacyNsfw/PcmHacks/wiki