RedneckNo4

does anyone know if there is an external/piggyback computer that you can reprogram? or any aftermarket reprogrammable computers with a lot more processing capability?

I only ask because I think it would be an interesting project to make my own adaptive C++ or C# program to run the car, A new smart phone is more than capable of doing the calculations, sooo why not?

Six_Shooter

iTrader: (2)

Piggy backs will only do so much, it still relies on the origial programming, it will just alter the input signals to try and convince the ECM of different operating conditions than is actually happening. Very limited.

Reprogramming the orginal ECM is the best way. Current, even older ECMs have more than enough prcessing power and speed to run an engine.

RedneckNo4

the point isnt to just run, I'm thinking of writing a program to dynamically adjust the air/fuel thus a change in cam or intake would be automatically adjusted for, only problem would be requiring larger injectors for big changes, there is a guy that essentially did this to his TBI S10 using an LS1 MAF and computer, I could do it with a laptop but input is the problem, not translating voltage changes or pulses just getting all those wires into the correct spots which several usb ports would work but again i wouldn't want to use a laptop

Six_Shooter

iTrader: (2)

*sigh*

I think you're assuming that more processing power is needed, when there's already more than enough processing speed in existing ECMs.

Piggy backs won't be able to do everything that tuning the ECM directly can accomplish. Like I said before a piggy back will only be able to rely on existing ECM programming, and try to trick it.

Why not do it better and tune calibrate the ECM itself, like this forum is dedicated to?

There are already dozens of piggy back computers out there.

RBob

iTrader: (1)

This may be true on the computational end. But it doesn't have the hardware to make it a reality. There is much more to running an engine then processing power. The hardware in GM ECMs is what makes it happen.

RBob.

RedneckNo4

I only say processing power because i'd be making a program to constantly check everything then determine how to fire the injectors and how much to advance the timing, the faster the computer the more often it can do that? I just was thinking of making it as accurate as possible?
and what i meant with the laptop wasn't piggybacking that was for replacing the ECM your first post explained that wouldn't accomplish my idea?
again, using existing sensors and adding more (more information the more accurate) and as i said i could wire those into usb ports using the voltage reading just as the GM computer does but it would be a much faster smarter computer storing much more data and doing many more calculations constantly allowing it to adapt to any change the fuel system could handle the only preset value it would require is the flow rate of the injectors? idk if i'm explaining myself really i'd think this is just unnecessary but I enjoy programming? I also feel OBD 2 is a bit archaic

Six_Shooter

iTrader: (2)

You're missing the big picture here.

Current ECM/PCM have WAY more processing power and speed than they really need to run an engine to it's fullest potential.

We don't need faster processing, or "more accuracy", the accuracy is there.

The only things that would be nice to add are more inputs and control outputs, but there's already ways to do that with existing hardware, most of the time just adding patches to the existing code.

If you think OBD2 is archaic, then you must think that OBD1 is pre-stone age, and what most of use on this forum are working with.

bnio

Second what all these guys have said, its hardware that makes the fuel injection work. Inputs and outputs!!! You need input capturing (many channels), Pulse width modulation channels, possible output compare channels, ADC's (analog to digital converters), multiple timers and counters basically, etc, but you already knew that right? Then if you used a laptop you would need iron clad data bus that would never hiccup if it were to run a vehicle.

You should jump into the world of microprocessors like I did many years ago! Maybe look at designing a fuel injection system around one and you quickly find your small programming project turn into a grotesque beast with a insatiable hunger for more and better programing and algos. There are so many different ways to do things its rediculous. I have been their and decided at this point its not worth reinventing the wheel. I am using a hacked source code for maf with mpfi all from a GM TBI computer and it works better than EXCELLENT it works STUPENDOUSLY! Thanks to demented24x7 for that piece of code. I would have liked to have learned the assembly language for the ecm I needed to use to make this happen, but I just didn't have the time in my life right now.

I am not trying to deter you at all, I applaud you for wanting to create something better and unique and you should pursue this if thats what you want to do. But I think you will realize quite quickly the more you learn about stock pcms and even the prehistoric OBD1 computers which I currently use, theres alot of processor power to work with depending on which computer you are looking at. In the end I feel you may concede and work with in the bounds of some these computers because they can do most anything you want and its the simplest quickest way to bring your work to life for testing. So say you want to try and sharpen up an algorithm, well most computers have the memory space or if need be delete some unnecessary functions. You will have to learn assembler and the motorola processor though.

My advice would be to look into the stock pcm a little more before you just say no! Also the stock algos can sometimes be good sanity checks to compare you code against to keep you going down the right path and to keep you from being to **** about how you are trying to do something. There is alot to learn from these guys here, Good luck with whatever you do.

Saar

LOL

the whopping 1-2MHz 8-bit processors most of the OBD1 ECM/PCMs run has worked great due to the code being lean and straightforward, not something you'll likely find on any kind of mass-marketed phones.

and having a "self-tuning" ECM is nothing new... especially if you want to consider the SAM functions in the ECMs. those hold the last BLM values in each BLM cell after running for a set period of time in closed loop.

want to have it self-tune more? add more BLM cells for different conditions.

if you want it to modify VE tables on it's own, that's different, i don't know what kind of hardware would be required to program a PROM when it's on-board. but the software portion of it is very real.

but VE tuning is easy enough anyway, the BLM and INT and proportional to the amount of fuel added or subtracted from the base tables to achieve stoich(or whatever you tell the ECM stoich is). now, spark tuning...

BlueIroc-Z

iTrader: (6)

Like others have said, it is the hardware contained in the PCM's that really makes the magic happen. You are saying that you would wire all the sensors/electronics up to the USB, but keep in mind you will need to design a very extensive hardware interface to translate all the raw I/O into something that the PC can work with via USB.

And, upon creating said interface, you have basically built yourself a PCM, minus the processor and memory... So you would just be outsourcing the processing and memory operations to a PC, with the intent being to use that massive boost in processing power/memory to run a much more advanced OS. But, now you will probably* (I'm no programmer/electronic engineer) have timing issues with your OS running between two layers of hardware (the interface and the PC itself).

RedneckNo4

[quote=BlueIroc-Z;4642128]Like others have said, it is the hardware contained in the PCM's that really makes the magic happen. You are saying that you would wire all the sensors/electronics up to the USB, but keep in mind you will need to design a very extensive hardware interface to translate all the raw I/O into something that the PC can work with via USB.=quote]

actually its not extensive at all its really easy we just worked on a simple RFID reader program with a USB reader (its just a box that sends a specific signal through the usb to the computer), the signal the the reader box sends is very similar to what... the tps sends essentially it was a range of voltages, we just had the software translate it to a number to pop up on the screen (each voltage was a function of the frequency on the tag) it only took a day or two to program

it would take more time to research the ranges and interaction of the sensors and what they mean for the air/fuel ratio or injector pulses required, i could have a maf and a map if I wanted or two map's and a maf (manifold and intake map) just for more information for a more optimal range, also more info to go into calculating the optimal spark timing

the hardware is also fairly simple we purchased a simple 8X6 circuit that separated the signals from a single usb, we used SQL server to store the preset data and it ran 5 model trains running back and forth (on 2 tracks) and turned switches and such, you wouldn't need something even that extensive to run the fuel injectors turning a tpi engine into an mpfi if i really wanted to.

I could put in as many inputs as I want it really doesn't add much coding because it would only have one goal, the HTML for this web page is around the same requirements as what I'd need, but it would be cheaper to use an old computer i have laying around than to re-design the ECU it would just be a fun project

BlueIroc-Z

iTrader: (6)

You'll have to forgive me if I'm way off base here, I've been dabbling in programming, usb, and electronic hardware for a while, but I wouldn't say that I'm very far along just yet...

Anyway, what I was going to say/ask, is with your RFID project you said: "the signal the reader box sends is very similar to what the TPS sends...a range of voltages" This is giving me the impression that the reader box is sending the computer an analog voltage signal. I thought USB could only work with digital signals...? And, that it was the duty of the receiver box to translate and format the RF signal into a digital packet for transmission via USB...?

By my methods (copy/paste HTML source into a line counter) this page comes out to around 700 lines... For comparison, I found the source code written in C for the MegaSquirt-II fuel injection computer. That came out to around 8,000 lines...

RedneckNo4

how did they run their calculations? C++ and C share syntax but C++ can do a lot more thats why i'd write it in C++ or C# which is C++++ essentially, there are some very good books on C++ you can get from amazon for around 400$ if you're interested

RedneckNo4

a usb is 4 wires wrapped in a convenient and simple package

RedneckNo4

I was going to check out that code myself only to realize that the megasquirt computer is essentially the type of thing I started this thread for, rather than being trolled

so thank you very much blueIroc-Z