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

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



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

[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]

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.

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

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



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.

[Xnke]

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.

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.

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

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

http://www.uobdii.com/wholesale/mini...able-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.

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

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