Nissan GT-R Forum banner
1 - 2 of 2 Posts

·
Registered
Joined
·
2,069 Posts
Very practical to do all that, but flashing needs special care due to bandwidth, reliability, power source, latency, multitasking, interrupts (phone call in the middle, disconnections), security, piracy. Most existing OBD interfaces are too generic/slow to be used for flashing, with a few exceptions that end up costing as much as AP hardware.
 

·
Registered
Joined
·
2,069 Posts
It would take a while to breakdown all the details behind what I summarised, but I wouldn't trust a cell phone running iOS or Android to flash my ECU based on my experience of using up to date versions of these devices and experiencing their latency and bugs. They are not mission critical, much like a PC running Windows. There are far too many things to interfere compared to even a modest microcontroller running no "operating system" but just running tried and tested code in tight loops. Upgrading your phone OS is something that is envisaged by the manufacturer to do in the field, by the end user. Flashing your ECU is not and needs more care (you can't hold a functional version of the old flash and new flash at the same time but a device is needed that responds to a protocol in real time to stream data without latency which could make it fail), only designed to be done on the manufacturing line and by an accredited technician with a known locked down device (Consult). The GTR ECU has a recovery mode for a failed flash, but it is not completely fool proof, and the last thing I want is a multitasking device missing the ECU's required response time for the next block because a Facebook widget is busy, less still receiving a call. The EMI from a cell phone is enough to interfere with ECU flashing, even without a call.

Having spent a few days recovering GTR ECUs, and having seen about 15 other ECUs fail during flashing, I'm more for locked down. There is a big difference between a powerful multimedia phone doing lots of things and a mission critical flash protocol that if it fails will need recovery and have a reasonable chance of an immobilised vehicle. ECUs require different thinking. Latency and response time are all, you have to have that spark and fuel sequencing ready, interrupt driven with accurate hardware timers. A bit of realtime editing of RAM with a failsafe is a different kettle of fish. Datalogging or adjustments similarly.
 
1 - 2 of 2 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top