From the Haltch web site:

ECU Manager allows you to tune your ECU with ease while monitoring all the vital parameters of your engine on easy to read gauges and displays.

For street cars, is there some sort of interface that will allow this information to be presented on a center consol 7" Double Din display? All that information available from the Haltch, to leverage into that output to create virtual gauges akin to what the Nissan GTR has would be a nice compliment. More information is better........................

Comments, experiences, suggestions?

 

It can work. You'd be on your own to make it happen though. Not sure what a good monitor would cost, but for less than $800 you can get a Racepak display dash that can show all the data you'll ever want to see. Includes programmable shift lights and warning lights as well.

 

I've already got the 7" double din and Haltech 1000. Just exploring what I'd need or is available to get one to talk to the other.

For instance, I know there such a thing as a "carputer". But all I'm after is a single function interface, not looking to make my car a laptop computer on 4 wheels.

 

Rolling laptop buddy, it's the best way. Unless you want an integrated car PC...you could get a widescreen monitor built-in to your sun visor. Serial data output is primitive in comparison.

 

cant there be some typ some screen function like the GTR haves to be made ?

just like a PFC commander but display only and more up to date.

i bet that will sell way good, its better then puting 10 gauges in the car making it look like a space shuttle

 

Yes. It's called a Racepak or AIM dash.

 

I'm going to second the logger dash . Its well worth the investment.

 

Not really what he's saying. The Racepak is a nice unit, albeit it's a replacement for the stock speedo, tach, etc. What we're talking about is something to compliment what's already there, not replace as is done with the GTR.

I've got the in-dash 7" monitor ready to display all that great information captured by my Haltech. It just bugs that to get that information displayed I need to roll with the added clutter of a big ol laptop.

 

Have you checked over on the http://www.MP3car.com forums? This is leaning towards their area of expertise. I was leaning towards doing this a couple years ago, and that led me into The Conector Project to find out who makes every connector in order to do stuff like Logicon+Vent/Radio swaps. Would make the screen much easier to see on a FC.

To pull it off, you'd need a carPC running some form of windows and a custom frontend for the ECU Manager software. Most guys with carPCs usually run some form of Linux as it seems to be more stable and reliable for an automotive application. On a side note, the hardware that the Platinum Sports use has Linux drivers readily available too. Not too sure if one is permitted to reverse-engineer the ECU Manager software by its EULA, but if you can decode how the data streams are interpreted, making a gauge program should be well within your skills too.

Programming is way over my head, but I'm pretty good with cracking codes. Years of hacking Pro-Action Replay codes on the SNES and hex editing PS2 game saves have taught me to find a needle in a haystack. Just gotta know what you're looking for. A good game to learn code hacking on is Legend of Zelda: A Link to the Past. The Y-button items are a very clear-cut example of how most games 'work' on the inside. For example, the boomerang's memory address is 7EF341. Give it a value of 00 (complete PAR code is 7EF34100) makes it so you don't have it. Value 01 (7EF34101) gives you the normal boomerang while value 02 (7EF34102) gives you the magical boomerang. Since the Hookshot is the next item on the screen, its address is next in line (7EF342) and the value system is the same (00 to not have it, 01 to have it).

Since the haltech's sensors are definable inside the ECU Manager, it shouldn't be too hard to crack each data stream and 'translate' it back to an on-screen gauge. Depending on the resolution of the haltech's scale, most of these values would fit inside a single byte (possible values are 0-255) or two bytes (values between 0 and 65535), exactly like on a Super NES. That would make it very workable to crack each data stream's values and isolate each one's memory address for display in a virtual gauge set. I'd bet that they organized it based on the I/O scheme, such as putting all of the AVIs first, then DPOs, and so on. Most SNES games are organized that way too. The main thing would be to find out how the values & addresses are structured first.

Some of the easier ones to do are:
Battery voltage, RPM, Coolant & Air temperature, all other DPOs (On/Off switches), All AVIs (0-5v scale).

 

Sounds like this can be done. But you lost me after "Have you checked...."

To dumb it down to my level, doing my own homework, I did discover there is a thing as a CarPuter which made me believe there is hardware available to make this happen. The challenge seems to be for someone much computer smarter than I to create/modify software. So who is the software guy that can bring this all together?

 

Okay Hozzman, here's a lesson about memory addresses, using a game that we're all familiar with: Legend of Zelda- A Link to the Past.

The first thing to keep in mind is that games (and computers) don't count in decimal order, they use Binary and by extension, Hexadecimal. A Bit is akin to an On/Off switch as it can be either 1 (On) or 0 (Off). Since 8 Bits equal 1 Byte, that's 8 On/Off switches all lined up together. Doing the math yields the 'magic number' of 256 different possibilities, as this would be 2 to the 8th power (number of switch 'positions' to the power of the number of switches).

Because binary is a PITA to work with, everything is converted to Hexadecimal so it makes more sense to us humans. Instead of "00110011" you end up; with "33" in Hex, which equals 51 in normal decimal numbers. Any windows/linux calculator can do the conversion for you.

The quick and short of Hexadecimal is that you have 0-9, then A through F, which represent 10 through 15. If you want 16, the number goes from "0F" (which was 15) to "10" just like in decimal numbering. As such, the maximum possible value is "FF", which equals 255 and the lowest is "00" which is 0.

Now, back to our story...Here's a pic of the Item Subscreen, courtesy of RPGfan.com


Let's start with the Bow & Arrows since it's the first item. Since there are 3 possible states (Don't have it, have it, have Silver Arrow upgrade), the values here are "00", "01" or "02". If you start a new game, the value you search for in the cheat finder in the emulator of your choice (SNES9X works REALLY well) is "00" because you don't have the Bow & Arrows yet. This narrows down the range of possible addresses to a big list. Once you play through to the Eastern Palace and get the Bow & Arrows, open the Cheat Finder again and revise your search to find values that changed to "01". The result is that it will give you address "7EF340". If you add that to your cheats and leave the value at "01" you'll always have the Bow & Arrows. Changing it back to "00" takes the Bow & Arrows out of your items, while making it "02" upgrades it to the Bow & Silver Arrows. The actual number of Arrows is stored elsewhere, but you can find that by repeating the process (search for current number of arrows, fire one, search again, repeat till you find the correct address).

Now that you know how to zero in on an address by looking for its value, try the process with the Boomerang which also has 3 states (don't have it, got the regular one, got the upgraded one). The address you'll find is the next one in line: 7EF341. Now try the hookshot (2 states this time) and you find the next address in order, 7EF342. See the pattern now?

The code for Bombs is probably most similar to the Haltech's I/O system and will be the one we focus on as it's a rare example of a combined Status/Counter code.

Since it's directly after the Hookshot on the Item Screen, its address is 7EF343. But because it is a consumable item, you're limited to the number you can carry in the game (starts at 10, increases to 50 later). So once you have 10 Bombs, look for a value of "0A" and you'll find the address every time. Try changing the value to "63" and see what happens...
Now you have 99 Bombs.

By watching a memory address and changing its value, you can change what appears/happens on the screen. Want Princess Zelda to follow you for the whole game? Try putting Value 01 on Address 7EF3CC.

Anyway, given enough time and effort, I could probably figure out the coding scheme. If I were to bet, my wager would be that it's done like the Bow & Arrows. Identifier Value in one address, Quantity Value in another address. The Gameboy Advance game Zoids Saga uses this extensively, but keeps the Identifier and Quantity addresses one directly after another in a series of "blocks" so it is relatively easy to figure out the code structure once you've got your feet wet on a SNES.

Overall, here is my estimation of how it works, without delving into it yet:
Each Input or Output has its own Address Block with several bytes that tell the Haltech EXACTLY what it is working with.

Identifier Address: (what DPO, AVI, etc you're working with)
Identifier Value Byte 1: Tells the Haltech that it's an injector, coil, sensor, etc
Identifier Value Byte 2: Gives more details on what is being used, such as a LS1 Coil, FC Coolant Temperature Sensor and so on. This byte depends on the first Identifier Value Byte.
Identifier Value Byte 3: Extra Information about each device, such as Coil Dwell Time, pulses for tach output, etc
Range Value Byte 1 & 2: Defines lower end of scale for the device.
Range Value Byte 3 & 4: Defines upper limit of scale for each device
Dynamic Byte 1 & 2: Current Reading for each input or output. This would be the Needle on a Virtual Gauge.
The reason for using two bytes for each of these is to give as much range on each input/output as possible. One byte would limit these to 255, while two makes it 65535. As we all know, 255 on a tachometer output wouldn't even be enough to idle on.

As said before, this is just a rough estimate of how I believe it works, based on similar code structures found in different games. There's probably much more to it, but you'd have to crack open the software and/or page & map files in a Hex Editor to find out for yourself. The hardware to pull this off is readily available, the drivers are available for free, it's just a matter of getting a Linux CarPC to 'talk' to the correct addresses & values in the Haltech and making a software display to turn the code into needles, gauges, warning lights, numerical counters and graphs.

 

You guys are approaching it from the wrong angle if the only thing you want to do is display data. The CAN signal can be used. This is already decoded for you (the protocol is available). You just need a system that will read the CAN stream and convert that information into a display. Once you have that, you can setup a display to show whatever you want. You would not be limited to what is shown through the ECU Manager software.

Again, this is how the digital dashes work. Single cable connection with power, ground, and signal all supplied through one cable.

 

While decoding a CAN data stream would certainly work and be reasonably quick due to the protocol being readily available, most guys with FCs are a bit broke and come up with very creative solutions to stuff like this. Sometimes the most byte-heavy solution isn't always the best one. Often times, a simpler device will outperform a more complex one at the same task, especially if it means eliminating an encryption operation and a decryption operation.

Turns out the actual live readings are part of the ECU Manager .EXE while the range and calibration details are in the map file. Working in tandem with Moldypoo, we cracked the memory address block offsets for each data stream. Using the aforementioned drivers and a memory dump from the Haltech's processor (to match up the offsets for each stream there), any good linux programmer could write an application to read the data from these memory offsets, translate them back to decimal and display them on screen. By having it as a small, lightweight application, it won't take much memory or processor power to run, even under the worst possible conditions. Hardware requirements would be roughly equal to a windows calculator on each data stream as all the would really have to do is read the data, convert it and then spit it out on the screen according to the directions in the config file.

The rest of the process is cosmetic stuff like drawing out nifty gauges and redoing one for the linux CarPC frontends to have a tab for gauges.

 

What is Haltech's stance on an app of some sort for lets say... android... that could be used as a display or even used like a commander on a PowerFC??

With the rise of tablets and large screen phones that many people already have, the screen is taken care of. Obviously there are the costs of development, but whose to say the app has to be free? I'd pay $25 or maybe even $50 depending on the capabilities for the ability to monitor things or maybe make coarse temporary adjustments without a laptop.

 

Akagis,

Sent you a PM.

 

buy a windows 7 table. ( refurb acer iconia w500 for 10" or w100 for 7 ") they are around $ 170-$ 250 .

these come with a usb port.

Buy Keyspan USA-19HS ( usb to serial adapter if using older haltech such as e6x e8 e11 and halwin )

and connect to your haltech.

you can even make adjustments on the tablet. ( the acer iconias come with a plug in keyboard also, which is great if you want to do your tuning, or buy a bluetooth keyboard ).

If you are running an older haltech unit such as e6k or older e6x, install dos box on tablet, and it will work .

 

Only down side is with the older haltech units, you only have so many inputs you can display.

the 7" tablet would work amazing with a haltech platinum 2000 and an array of extra inputs such as egt, oil , etc.

but at that point you are spending $$ on the tablet, might as well get the race dash .

But its nice to have a descent display.

 

<http://www.palmerperformance.com/products/dashcommand/index.php> I think that is what you're looking for. It will integrate with Haltech's CANBUS protocol system. And looks a hell of a lot better than that **** display they are trying to sell.

 

Bump to a old but my laptop finally died on me last night in the middle of tuning . So this mornin been looking at buy a new laptop . Will I found one at agreat price running windows 8.1 and separates into a tablet , as a 32gb Emmc ,1gb ram ( will upgrade this for data logging space ) . I was just wondering if the tablets is separated from the base Does it still communicate between each other . Ive been using dosbox with the e6k 6.34 with no problem on windows 98 and vista either with the normal 9 pin connector or with the 9p to USB adapter and reg. dell laptops .

 

THIS is a good idea. Thanks. I'm looking into getting something like this...