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

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-diagn...l#post19836978

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?

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.

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

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.)

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 :)

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

https://github.com/blog/2502-github-...nctuary-cities

Quote:

---

Originally Posted by EDZIP

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

https://github.com/blog/2502-github-...nctuary-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.

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.

Quote:

---

Originally Posted by 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.)

---

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

Quote:

---

Originally Posted by PeteS

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.

Quote:

---

Originally Posted by kur4o

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

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.

Quote:

---

Originally Posted by 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.

---

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.

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.

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.

Xnke,

just how soon is "shortly:? :-)

Buddrow

Quote:

---

Originally Posted by 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.

---

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?

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.

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.

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

https://forum.macchina.cc/t/support-...-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.

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.

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

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.

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.

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 between

1.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.

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.

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...

Quote:

---

Originally Posted by 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.

---

That is for more complex then it needs to be.

https://www.mouser.com/ProductDetail...7PIwC%252bY%3d

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

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

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

Quote:

---

Originally Posted by 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...

---

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.

Quote:

---

Originally Posted by PeteS

That is for more complex then it needs to be.

https://www.mouser.com/ProductDetail...7PIwC%252bY%3d

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

Datasheet....
http://ww1.microchip.com/downloads/e...Doc/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.

Quote:

---

Originally Posted by PeteS

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?

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.

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

Thanks, Mike

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.

Quote:

---

Originally Posted by Xnke

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.

Quote:

---

Originally Posted by 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.

---

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

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?

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

Quote:

---

Originally Posted by 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.

---

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.

Quote:

---

Originally Posted by Xnke

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/...r-gm-opel.html

http://www.buyobdtoolshop.com/wholes...gle-cable.html

http://www.uobdii.com/wholesale/mini...able-2442.html