
Software On ELM Street - OBD2 Software Development
Re: Software On ELM Street - OBD2 Software Development
I only meant that ADX files are for logging datastreams.... an ADX file has nothing to do with reading and writing bin files
its a datastream definition only!

Re: Software On ELM Street - OBD2 Software Development
Jayme wrote:I only meant that ADX files are for logging datastreams.... an ADX file has nothing to do with reading and writing bin filesits a datastream definition only!


Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: Software On ELM Street - OBD2 Software Development
New plan of attack here.
Soooo, Im finding it extremely hard to apply a "replay" log feature in SOE with the current movable gauge layout.
Since gauges could be added/removed at any time, or changed ect. This is something I have to take into consideration for these logs. It gets waaaaay to complex for myself to be able to save the gauge type, location, parameters, when its added or removed ect.
So, Im feeling that the whole "moveable" gauges needs to be removed. And fixed gauges can be put in place.
That way I dont need to worry about guages changing.
But it does still mean I have to keep in mind new parameters being added on the fly.. since this causes a completely new array of received frames with new data. The logs recorded will need to include exactly when new parameters are added, the DPID's they are in and then update the gauges with the new parameters or remove any "deleted" engine data.
Probably means Im going to have to make some sort of custom "commands" to be added into the log files that the replayer will interpret.
Eg
01 = Engine Data received = Process this
02 = Engine data parameter added - Update available parameters
03 = Engine data parameter removed - Update available parameters
04 = Unknown response - Ignore or return to defaults
ect
It would be ALOT easier.. if engine data could not be added/removed while logging. I mean, that eliminates all problems right there. But I like be able to flick between anything.. rather than having to stop
Orrrrr, another option is to "select" which PID's are to be used at the beginning. Then start the logging, and then any of these PIDs can be displayed on any of the gauges.
Actually.. thinking about it.. I like that idea... need a nice simple way to display the engine parameter.. and to simple tick it to view it.
Oh, and Iv started reverse engineering the transmission data from the VE SS, I think from what Iv been told.. this will be a T43 trans controller. Ill be redoing the entire front connection display to include transmission data.. and also remove the infamous "freeze data" until I have that sorted.
*Random muttering/rant over*
(If anyone has ideas, feel free to share!)
Soooo, Im finding it extremely hard to apply a "replay" log feature in SOE with the current movable gauge layout.
Since gauges could be added/removed at any time, or changed ect. This is something I have to take into consideration for these logs. It gets waaaaay to complex for myself to be able to save the gauge type, location, parameters, when its added or removed ect.
So, Im feeling that the whole "moveable" gauges needs to be removed. And fixed gauges can be put in place.
That way I dont need to worry about guages changing.
But it does still mean I have to keep in mind new parameters being added on the fly.. since this causes a completely new array of received frames with new data. The logs recorded will need to include exactly when new parameters are added, the DPID's they are in and then update the gauges with the new parameters or remove any "deleted" engine data.
Probably means Im going to have to make some sort of custom "commands" to be added into the log files that the replayer will interpret.
Eg
01 = Engine Data received = Process this
02 = Engine data parameter added - Update available parameters
03 = Engine data parameter removed - Update available parameters
04 = Unknown response - Ignore or return to defaults
ect
It would be ALOT easier.. if engine data could not be added/removed while logging. I mean, that eliminates all problems right there. But I like be able to flick between anything.. rather than having to stop
Orrrrr, another option is to "select" which PID's are to be used at the beginning. Then start the logging, and then any of these PIDs can be displayed on any of the gauges.
Actually.. thinking about it.. I like that idea... need a nice simple way to display the engine parameter.. and to simple tick it to view it.
Oh, and Iv started reverse engineering the transmission data from the VE SS, I think from what Iv been told.. this will be a T43 trans controller. Ill be redoing the entire front connection display to include transmission data.. and also remove the infamous "freeze data" until I have that sorted.

*Random muttering/rant over*
(If anyone has ideas, feel free to share!)
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: Software On ELM Street - OBD2 Software Development
done any work on the AVT yet? or plugged it into your VE and tried my adx? 

Re: Software On ELM Street - OBD2 Software Development
Ill try out your ADX nowJayme wrote:done any work on the AVT yet? or plugged it into your VE and tried my adx?

Im still working on the AVT protocol handler, mkaing it so its a simple job of just requesting a function: SendCommandGetResponse(Frame2Send,ExpectResponse,NumExpectedFrames)
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: Software On ELM Street - OBD2 Software Development
ok, so you may be a bit confused by seeing disappearing posts!! I moved all the posts about the ADX to the ADX thread.... saves clogging up the SOE thread with talk of ADX's!!
Re: Software On ELM Street - OBD2 Software Development
No worries!!Jayme wrote:ok, so you may be a bit confused by seeing disappearing posts!! I moved all the posts about the ADX to the ADX thread.... saves clogging up the SOE thread with talk of ADX's!!

Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Re: Software On ELM Street - OBD2 Software Development
Im adding in transmission engine data reading and diagnostics... but I dont have an LS1 auto ecu...
Looks like Ill be using the new trusty AVT to simulate an auto LS1. Just first need to work out what the responses should be!
I know that for LS1.. scantools still request from the standard device ID as when requesting engine data since the trans section is in the LS1 ecu.
Im pretty sure I do have all the fault codes nailed for the LS1 including transmission since its all requested exactly the same.
Just need to work out which PID's for trans are supported.
Alternatively.. I need to flash this LS1 with an auto calibration.
The CAN transmission should be easy, Iv got a VZ V6 tcm here (T42?) and my VE SS auto (T43?) so they are the test subjects there. Both of which communicate at 7E2.
Looks like Ill be using the new trusty AVT to simulate an auto LS1. Just first need to work out what the responses should be!
I know that for LS1.. scantools still request from the standard device ID as when requesting engine data since the trans section is in the LS1 ecu.
Im pretty sure I do have all the fault codes nailed for the LS1 including transmission since its all requested exactly the same.
Just need to work out which PID's for trans are supported.
Alternatively.. I need to flash this LS1 with an auto calibration.
The CAN transmission should be easy, Iv got a VZ V6 tcm here (T42?) and my VE SS auto (T43?) so they are the test subjects there. Both of which communicate at 7E2.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

- antus
- Site Admin
- Posts: 9014
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: Software On ELM Street - OBD2 Software Development
You can flash in an auto bin to your ls1 pcm, no problems there. Yes the VE uses the T43 controller.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Re: Software On ELM Street - OBD2 Software Development
Perfect!antus wrote:You can flash in an auto bin to your ls1 pcm, no problems there. Yes the VE uses the T43 controller.

Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726

Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
