OBDX Development - Developer Tools and Suggestions

Programs / Tools / Scripts
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

hjtrbo wrote:Maybe try plugging in a 150W 230V inverter to the cigarette lighter and load it up with 2 laptops charging using 75W chargers. All that switching will make things ugly I am sure.
I have an inverter sitting around somewhere, might go looking for that!
Cincinnatus wrote:I think a test with battery charger on is reasonable, and with other modules on the bus. Laptop plugged in as well. I don't think inverters or engine running is necessarily within the realm of an expected possibility for a flashing situation. Sounds like it's tolerant enough to be on the market to me.
Thats correct, its outside the realm of what anyone could do.. especially a running engine to actual flash. But we want to make sure their is a buffer zone for vehicle that have poor wiring/groundings so it can deal with a less then ideal connection. I mean, its not going to fix a rust bucket vehicle that barely has a grounding point, but for some of the less ideal vehicles, it should still then be able to hold a good connection.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
hjtrbo
Posts: 125
Joined: Tue Jul 06, 2021 6:57 pm
cars: VF2 R8 LSA
FG XR6T
HJ Ute w/RB25DET

Re: OBDX Development - Developer Tools and Suggestions

Post by hjtrbo »

Cincinnatus wrote:I don't think inverters or engine running is necessarily within the realm of an expected possibility for a flashing situation. Sounds like it's tolerant enough to be on the market to me.
Umm, tail between my legs here. Had to send a couple of modules off to Tazzi last month due to 'some idiot' doing something like you said. :oops:
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: OBDX Development - Developer Tools and Suggestions

Post by kur4o »

I agree crappy power supplies, can introduce unbearable noise on usb line. Actually had that issue long time ago on ALDL pcm, that always failed on one particular laptop that uses aftermarket psu.

Invertors should be prohibited for in car flashing. If wireless connection is used, some may get away with it. If connected a real disaster can happen, burning cable, pcm or even laptop, with unisolated common ground.
User avatar
antus
Site Admin
Posts: 8237
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: OBDX Development - Developer Tools and Suggestions

Post by antus »

yep there has been plenty of reports of people failing to erase with pcmhammer and its turned out to be a low quality, noisy or low voltage power supply - not the pcm, not the cable, not pcmhammer. often they use a car battery instead on the bench supply and everything starts working.
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
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

antus wrote:yep there has been plenty of reports of people failing to erase with pcmhammer and its turned out to be a low quality, noisy or low voltage power supply - not the pcm, not the cable, not pcmhammer. often they use a car battery instead on the bench supply and everything starts working.
Very very common to see unfortunately. Its the 12v 0.5amp wall chargers which really struggle. It appears the laptop chargers have faired much much better although this is because most are 13-15v and supply 2-5amps which is plenty :thumbup:
hjtrbo wrote:Umm, tail between my legs here. Had to send a couple of modules off to Tazzi last month due to 'some idiot' doing something like you said. :oops:
Happens to the best of us! Least they are usable again now.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

I have recently found that the OBDX CANBus coding has to deal with the "please wait Im slow" messages differently due to J2534 requiring to see these messages and not just suppress them.

An example of this message would be: 7E8 03 7F 1A 78

The 7F means error, the 1A is the 'mode' that was requested, and the 78 means "Im slow... give me a moment to process".

The newest ELM327 standard says from v2.1 onwards, they make the ELM wait for up to 5seconds to search for the response frame. Technically this was hard coded into the OBDX Canbus routines, but I temporarily disabled it when the J2534 standard actually wanted to see the 78 responses so it knew there was a hold up. This appears to be our final command implementation for OBDX so that it can be enabled/disabled to keep the ELM standard happy.

I only bring this up now, since I was messing again with a VZ V6 ECU (E55) and requesting the VIN resulted in the 78 response, which the ELM took as the total message instead of waiting for the rest as it should. The newest ELM standard shows this is enabled by default, so best to also do the same. On the DVI standard, I believe having this disabled by default would be smartest so the end user has finer control over what is being received.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Todays topic is... power saving!!

Now, the GT and VT are in no way low power devices. They both use ESP modules for their wireless connectivity.. this is VERY overkill for what they need, but there are not many wireless ICs which allow such customisation and support BT,BLE and WIFI.
Anyways, I believe the GT uses around 125-150mA, this varies depending on when connected to a wireless connection. I don't expect people to leave this permanently plugged in, but, there will be some that do (Even though we would not recommend it).

For a car battery, the average amp hours of a car battery is around 40-65... this means our 0.15amp tool "Should" be able to be connected to the car for 266hours (11-12days) before draining it. I do feel that number is acceptable.. but... it can be much better.

SAE standards indicate a cas total current draw must be less that 50mA after 1 hour. Thats the TOTAL draw of everything in the car.. so... adding the GT to this means it would be around 200mA. Now, that reduces the total battery time to 200hours (8.3days), now its closer to around a week worth.

Our main power user is the ESP, turning this off drops the power usage to around 40mA ish, so thats around 2-3x less then with ESP on. This would then result in around 90-100mA draw in the car assuming worst case scenario of car current draw.

Realistically, the tool should go into a deep sleep, around 1-2mA. This could be achieved by forcing the tool into low power mode, and to wake up after 'X' seconds. The only main issue I see here is how should the tool know when to wake up. Maybe it could sleep for 5seconds... wakeup.. the search for a pin change state on the support protocols (ALDL,VPW,CAN) for say.. 200ms.. and if it sees nothing, it then goes back to sleep?

Im not sure if we have enough flash to even fit this.. but since its basically just going to a deep sleep.. then reading some pin registers... it 'shouldnt' be too tasking.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Cincinnatus
Posts: 305
Joined: Fri Jul 30, 2021 5:49 pm
cars: 97 Corvette
92 Camaro
2005 Silverado
2001 Savana 2500
1998 c3500hd
1998 tahoe

Re: OBDX Development - Developer Tools and Suggestions

Post by Cincinnatus »

Tazzi, I don't see power consumption being worthy of any time investment. Anybody leaving it plugged in is asking for a dead battery. Also, who would use an inverter to charge their laptop while flashing, knowing they need that battery to power the PCM? I know you're testing for the reckless real world users, but there is no amount of preparation that can overcome foolishness.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: OBDX Development - Developer Tools and Suggestions

Post by Tazzi »

Agreed, but knowing I have done everything in my power to deal with accidental foolishness is something that is hardwired into me :)
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
hjtrbo
Posts: 125
Joined: Tue Jul 06, 2021 6:57 pm
cars: VF2 R8 LSA
FG XR6T
HJ Ute w/RB25DET

Re: OBDX Development - Developer Tools and Suggestions

Post by hjtrbo »

Tazzi wrote:Todays topic is... power saving!!

For a car battery, the average amp hours of a car battery is around 40-65... this means our 0.15amp tool "Should" be able to be connected to the car for 266hours (11-12days) before draining it. I do feel that number is acceptable.. but... it can be much better.
For what its worth the HP Tuners MPVI2 drained my VF battery in 2 weeks.
Post Reply