Page 23 of 91

Re: OBDX Development - Developer Tools and Suggestions

Posted: Fri May 20, 2022 4:58 pm
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.

Re: OBDX Development - Developer Tools and Suggestions

Posted: Fri May 20, 2022 6:31 pm
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:

Re: OBDX Development - Developer Tools and Suggestions

Posted: Fri May 20, 2022 8:34 pm
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.

Re: OBDX Development - Developer Tools and Suggestions

Posted: Sat May 21, 2022 1:57 pm
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.

Re: OBDX Development - Developer Tools and Suggestions

Posted: Mon May 23, 2022 10:24 am
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.

Re: OBDX Development - Developer Tools and Suggestions

Posted: Mon May 23, 2022 11:01 am
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.

Re: OBDX Development - Developer Tools and Suggestions

Posted: Tue May 24, 2022 12:20 pm
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.

Re: OBDX Development - Developer Tools and Suggestions

Posted: Tue May 24, 2022 2:58 pm
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.

Re: OBDX Development - Developer Tools and Suggestions

Posted: Tue May 24, 2022 3:34 pm
by Tazzi
Agreed, but knowing I have done everything in my power to deal with accidental foolishness is something that is hardwired into me :)

Re: OBDX Development - Developer Tools and Suggestions

Posted: Tue May 24, 2022 5:16 pm
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.