ultra cheap gauge to display any ECU parameter

[acannell]

heres how I feel about some things..

1) Logging with MPSCAN / MPSCANDROID with a laptop or phone

PROS:
Definitely the most powerful setup.

CONS:
Big mess of wires.
Tends to be difficult to get working.
Wont replace the always-on, always-ready, easy readability of a gauge.
Doesn't log AFR.

2) Using an OTC 2000 scanner

PROS:
Can access every engine parameter, actuator, and test available.
Fairly cheap ($75?)
Very easy to get working. Plug and play right out of the box.
Can almost function as a gauge since its somewhat tidier than a laptop and can show one or two parameters at a time.
Does support serial output for logging.

CONS:
Not a true gauge. Still bulky and you have wires all over.
Data logging would require a computer in the car along with the OTC 2000, making the whole thing even more of a mess and less "permanent".
Doesn't log AFR.

3) Using a DRB II scanner

PROS:
Same as OTC 2000 but I believe has much more powerful diagnostic tests.
Better screen is a little more user friendly.

CONS:
Same as OTC 2000.
Very expensive. $200+?
Doesn't log AFR.

So right off the bat we can come up with a list of things a new logging solution would have that would make it a winner:

a) permanent install with no wire mess
b) always-on/always-ready functionality like a standard gauge
c) full functionality of an OTC2000 (all sensors, read/clear faults, actuator/switch tests, etc..)
d) super easy setup as close as possible to plug in and use, like the OTC2000
e) gauge mode that shows 1 or more ECU parameters in real time but with gauge-like readability (bright 7 seg display for instance)
f) logging that is always-on/always-logging, automatically
g) logging output that can be immediately imported into excel for analysis/plotting, pre-labeled and formatted with timestamps
h) cheap!!

and how those can be accomplished:

a) there will be wires, but since this solution is not bulky and can be installed like a standard gauge, the wires can all be hidden and permanently secured like a normal gauge
b) permanently installed means its always ready
c) the protocol to talk to Chrysler ECU's is pretty much totally figured out. I can look at what the OTC2000 does to get it perfect. So full functionality.
d) Assuming the protocol is correct, the sticking point here will be how well the bluetooth pairing and android app work with each other. I really get annoyed when that sort of thing doesnt work right so I will make a big effort to make it robust and smooth. I think its doable. This is a very basic bluetooth SPP connection that is pretty much foolproof.
e)If I use the DTGAUGE display, its two 4 digit, 7 seg LED displays. Very easy to read as a gauge.
f) As long as you have your phone with you, running the app in the background, the bluetooth pairing should work automatically and logging should happen without you having to do anything. I would add a status light to this new device that indicates logging is active and functioning correctly with some kind of continuous verification of receive from the android app, so you KNOW its working.
g) all this takes is for the android app to timestamp things and parse them so they have commas..very easy
h) we shall see..Id like to price this for less than the OTC2000. But I still have to design a solution for a cable and connector to the chrysler ECU. Im not sure how cheap I can make that. The bluetooth adds a pretty hard $5. I think this as a product is definitely a case where the lower its priced the more it will sell, because alot of people who just want to get their TM running could use a diagnostic tool like this, long before they need it to check knock retard.

[ShelGame]

heres how I feel about some things..

1) Logging with MPSCAN / MPSCANDROID with a laptop or phone

PROS:
Definitely the most powerful setup.

CONS:
Big mess of wires.
Tends to be difficult to get working.
Wont replace the always-on, always-ready, easy readability of a gauge.
Doesn't log AFR.

It can log AFR, if you use a Turbonator (SMEC or SBEC) cal and the WB-to-NB conversion function. It can be an all-in-one; without needing the WB mfg's proprietary logger.
Of course, if you want to log other analog sensors (for example, several intake temps, or EGT's), then MP Tune can't currently do that.
And, it's only the 1 wire, really. I permanently installed the FTDI cable and ran it to a male/female panel mount socket on my dash. I just have an 18" USB A-B cable going from laptop to dash.

a) permanent install with no wire mess
b) always-on/always-ready functionality like a standard gauge
c) full functionality of an OTC2000 (all sensors, read/clear faults, actuator/switch tests, etc..)
d) super easy setup as close as possible to plug in and use, like the OTC2000
e) gauge mode that shows 1 or more ECU parameters in real time but with gauge-like readability (bright 7 seg display for instance)
f) logging that is always-on/always-logging, automatically
g) logging output that can be immediately imported into excel for analysis/plotting, pre-labeled and formatted with timestamps
h) cheap!!

and how those can be accomplished:

a) there will be wires, but since this solution is not bulky and can be installed like a standard gauge, the wires can all be hidden and permanently secured like a normal gauge
b) permanently installed means its always ready
c) the protocol to talk to Chrysler ECU's is pretty much totally figured out. I can look at what the OTC2000 does to get it perfect. So full functionality.
d) Assuming the protocol is correct, the sticking point here will be how well the bluetooth pairing and android app work with each other. I really get annoyed when that sort of thing doesnt work right so I will make a big effort to make it robust and smooth. I think its doable. This is a very basic bluetooth SPP connection that is pretty much foolproof.
e)If I use the DTGAUGE display, its two 4 digit, 7 seg LED displays. Very easy to read as a gauge.
f) As long as you have your phone with you, running the app in the background, the bluetooth pairing should work automatically and logging should happen without you having to do anything. I would add a status light to this new device that indicates logging is active and functioning correctly with some kind of continuous verification of receive from the android app, so you KNOW its working.
g) all this takes is for the android app to timestamp things and parse them so they have commas..very easy
h) we shall see..Id like to price this for less than the OTC2000. But I still have to design a solution for a cable and connector to the chrysler ECU. Im not sure how cheap I can make that. The bluetooth adds a pretty hard $5. I think this as a product is definitely a case where the lower its priced the more it will sell, because alot of people who just want to get their TM running could use a diagnostic tool like this, long before they need it to check knock retard.

Yep, all good ideas there.

One that I would add (that I think someone else pointed out) is a way to still be able to plug in a USB cable and re-flash a cal; without having to open the hood and swap cables at the SCI connector. If your device handles the USB-to-SCI conversion instead of the FTDI cable that I use now, then great. One less device to buy (makes this more cost attractive, in my opinion)...

[acannell]

One that I would add (that I think someone else pointed out) is a way to still be able to plug in a USB cable and re-flash a cal; without having to open the hood and swap cables at the SCI connector. If your device handles the USB-to-SCI conversion instead of the FTDI cable that I use now, then great. One less device to buy (makes this more cost attractive, in my opinion)...

If we assume there are two main situations which logging either with MPSCAN or the new device (TND) would occur:

1) A dedicated tuning session, where you will have a laptop running MPTUNE and also need to be able to flash the ECU repeatedly.

2) Every day driving/racing where you aren't tuning, but want data logged anyway for analysis, and you want to be able to observe knock retard/counts on a gauge while driving/racing.

In situation 1), you already have a laptop present, so you may as well log data directly to it using MPSCAN. No reason to log to an android phone and then mess with getting that data from the phone to the laptop. So in this case, TND would act as a "spy" or "observer", and just watch the SCI bus, waiting for MPSCAN to request "KNOCK RETARD" and then watching for the response and displaying it on its little gauge display. So you still have the gauge functionality even if you are logging with MPSCAN. When you go to flash, TND doesnt disturb the bus at all. So everything acts like TND isnt even there, no cable switch is required for logging/flashing, and you dont lose gauge functionality during your runs. If TND has extra inputs for AFR, Thermocouples, etc..then they will not be logged here. Or, if they are logged, it will be to a separate log file on your Android phone and you will have to sync it up with MPSCAN's log. YUCK.

In situation 2), you dont have the laptop present. So TND does all the logging to your phone over bluetooth, automatically when you get in the car. And it functions as a gauge for whatever ECU parameter you have selected, and also as a permanently installed OTC2000/DRB2. All ECU parameters you select AND any extra inputs for AFR/Thermocouples on TND get logged and synchronized perfectly into one log file on your phone.

So whats still missing from this is that in Situation #1, you arent getting any auxillary inputs that TND may have (AFR, thermocouples, etc.) logged into MPSCAN.

So how can we do that?

TND could monitor the bus for a special escape sequence that it will respond to with its own data. Something the ECU would never respond to, or that it responds to with data nobody cares about. Like some unused ram location. Then, assuming TND acts as a pass-through for the SCI bus, TND could momentarily disconnect the ECU's transmit line and take over just to spit out the requested data from one of its own inputs. So then TND acts as an expansion to the ECU, which a bunch of inputs.

My DTGAUGE already has very high quality electronics for sampling thermocouples and other voltages, so this is feasible from a hardware level. Just need to know if MPSCAN can be modified to request "special" ram locations like this. Rob, what do you think?? Are there any unused ram locations or any sort of byte sequence that the stock ECU would ignore?

P.S. I understand you can log AFR by connecting a widebands narrowband output to the stock ECU, so when I mention AFR above I mean if you want to keep the stock O2 sensor as the feedback device and have the wideband operate completely separate.

[acannell]

so to boil it all down:

"this new device"

would have extra inputs that MPSCAN could access and log along with the usual data from the ECU

and could also "spy" on the bus without disrupting MPSCAN during flashing of MPSCAN logging

and could also operate "standalone", logging data via bluetooth to android, and showing data with a gauge-like display

and all the above would therefore make everything perfect lol

[ShelGame]

P.S. I understand you can log AFR by connecting a widebands narrowband output to the stock ECU, so when I mention AFR above I mean if you want to keep the stock O2 sensor as the feedback device and have the wideband operate completely separate.

I don't mean by using the NB output. I have a way to input the WB signal to the ECU so that the actual WB AFR can be logged. Internally, I convert the signal to a NB signal with a simple transfer function so that the feedback mechanism stays the same as stock. This also gives you the ability to 'offset' the NB output to richen or lean the AFR during closed loop. Sorry for going OT....

[acannell]

okay did a little more observing..Rob this is probably all review for you but heres what I found

Im using an OTC 2000 with a 3 in 1 Domestic 1991 GM/CHRYSLER/FORD cartridge

I monitored everything that happens at startup.

The SBEC I have is for a 90 2.5 T1 and has a STAGE 5 FWDP cal in it

So, you plug it into power.

Besides a few glitches and idle level change there is nothing going on on the serial bus.

It asks you GM FORD CHRY.

As soon as you hit CHRY the serial bus changes idle state but there is no data being sent (a little glitch LOOKs like data but its not)

Then it asks for MODEL YEAR. As soon as thats done scrolling a transaction occurs:

All the following happens at 7812 baud

OTC: 0x16

ECU: 0x16

OTC: 0x81

ECU: 0x81 0x44 0x38 0x11 0x41 0x65

And thats it.

The OTC prints out 91 M then 91 2.5 Turbo Vin J

And then everything goes idle.

[acannell]

And then,

If you then hit DATALINE

At 7812 baud:

OTC: 0x12

ECU: 0x12

Then at 62500 baud

OTC: 0xF2

ECU: 0xF2

And then many bytes of data start flowing. Ill try to dissect them.

[acannell]

So in Dataline, it looks like immediately after the 0xF2 response, the OTC sends a repeating string of 76 bytes:

7E7E82827F7FC2C28C8C79797A7A757576768B8B0505717172 72C4C4C3C3C5C5C6C68A8A89898F8F90904C4C4D4D1F1F2020 2121222223232424252526260F0FACAC3A3AEDED9191505044 44

It appears to be duplicating each ram location request for some reason. Not sure why.

I have confirmed on the scope that commands are being sent in duplicate.

Any ideas Rob?

It looks like the OTC sends this 76 bytes in a ~150ms burst, with large gaps between the bytes which accounts for the long time. Sending 76 bytes at 62500 should only take around 10 ms.

The overall burst rate looks like 4 times a second. The ECU appears to take about 1 to 2 ms to respond to a given byte request. So thats where the slow update rate comes from I suppose. And the apparent double-requests. And the huge gap between bursts. And that its requesting 36 different ram locations.

So if we are requesting the following:

1. RPM
2. TACH
3. MAP
4. TPS
5. KNOCK COUNTS
6. KNOCK RETARD 1
7. KNOCK RETARD 2
8. KNOCK RETARD 3
9. KNOCK RETARD 4
10. SPEED

Then we could probably do that in 25ms. Or 40 times a second. Not bad.

[acannell]

Looks like reading fault codes is done at 7812 baud, as follows:

OTC: Send 0x10

ECU: Respond with 0x10 and then fault codes..in my case I Have 8 fault codes and got 8 bytes back excluding the 0x10 response

[acannell]

Ahh I see from looking at MPSCAN's BIT settings that the fault codes are stored in 8 bytes as bit flags...

[Vigo]

As a 'probably will buy this' customer i'm kind of wondering if mission creep is going to kill this for me. Im thinking of price and real estate/packaging issues.

I like the idea of having 2-4 lines of data that you can individually cycle between a list of 'datastream' items, similar to an OTC2000 but 'always on' and quicker to cycle between items.

I like the idea of datalogging over bluetooth to another device. I think this limits the cost/complexity of the 'gauge' and also doesn't require any actual usb or card slots which physically take up space which would have to be either on the gauge face (bad! imo) or necessitate another cable coming out of the back of the gauge that has to be routed somewhere else (which i am indifferent to).

I would prefer to see the whole thing fit in a 52mm gauge format. I know having some cabling coming out the back for a remote-mount usb or card slot would open the possibility of still having those things while being able to keep a good-size screen and controls on the tiny 52mm gauge face.

Also i would like if it matched the style/coloring of the dual thermocouple gauge i already have but that's a pretty selfish concern and not a dealbreaker.

[acannell]

As a 'probably will buy this' customer i'm kind of wondering if mission creep is going to kill this for me. Im thinking of price and real estate/packaging issues.

I like the idea of having 2-4 lines of data that you can individually cycle between a list of 'datastream' items, similar to an OTC2000 but 'always on' and quicker to cycle between items.

I like the idea of datalogging over bluetooth to another device. I think this limits the cost/complexity of the 'gauge' and also doesn't require any actual usb or card slots which physically take up space which would have to be either on the gauge face (bad! imo) or necessitate another cable coming out of the back of the gauge that has to be routed somewhere else (which i am indifferent to).

I would prefer to see the whole thing fit in a 52mm gauge format. I know having some cabling coming out the back for a remote-mount usb or card slot would open the possibility of still having those things while being able to keep a good-size screen and controls on the tiny 52mm gauge face.

Also i would like if it matched the style/coloring of the dual thermocouple gauge i already have but that's a pretty selfish concern and not a dealbreaker.

Worry not Vigo, I am trying to keep a close eye on creep.

So in that spirit, lets review the "simplest" ideas:

a) bare bones knock gauge. Shows highest current knock retard and stores peak KR for all 4 cyl. Also shows knock counts. Uses DTGAUGE 2 line 7 segment display. Not compatible with MPSCAN, so you have to unplug it if you want to use MPSCAN and it will not work during logging. This is the simplest knock gauge possible and would also be the cheapest. Also, it would be very trivial to have it be able to display any ram location, not just KR and KC.

b) a+ add full OTC 2000 functionality. If we're lucky this is easy to do. If there are oddities then it could take some time to get working right. Not sure. Might not be much more work than a)

c) a+ b + add ability to log many parameters and send that data via bluetooth to an android phone. this is a fairly big deal.

d) a, b, c + have a pass through mode so you dont need to disconnect MPSCAN and the gauge works when MPSCAN is logging

e) a + b +c +d +have additional inputs for AFR, thermocouples, etc.. that MPSCAN can query and log (or it can log when working standalone)

So where do we want to stop?

I for one, will not be satisifed until I can log EVERY engine parameter I want including external inputs, automatically, with convenience and without juggling a bunch of stuff around. So for me something equivalent to e) is going to be needed.

But I think a) or b) would be a very powerful tool for almost everyone.

[DoubleD]

I know i will be a purchasing customer of this gauge however it is built.
I am all for option E, I have an Iphone, but I can get an android tablet for specific logging dutiesm, not a deal breaker for me.
I can currently dataog my engine parameters using MPScan and datalog the wideband using Innovate's software but what a PITA to overlay the data and sync it up for anlysis.

I am pretty sure all of the OTC functions are available through MPScan, I can read any codes and run any actuator tests, so that function is not as important to me and i am really curtious how you will run those tests using the gauge.

On the discussion of knock, I run a Turbonator cal in my car and the way mines set up is any time there is knock, the check engine light blinks, I dont know how much knock, what voltage, or how many degrees of timing is pulled, but I do know it is knocking and to back out of the throttle.

I like to have as much data available to me so I can decide what I want and need, the more engine parameters logged for me the better!

[acannell]

I know i will be a purchasing customer of this gauge however it is built.
I am all for option E, I have an Iphone, but I can get an android tablet for specific logging dutiesm, not a deal breaker for me.
I can currently dataog my engine parameters using MPScan and datalog the wideband using Innovate's software but what a PITA to overlay the data and sync it up for anlysis.

I am pretty sure all of the OTC functions are available through MPScan, I can read any codes and run any actuator tests, so that function is not as important to me and i am really curtious how you will run those tests using the gauge.

On the discussion of knock, I run a Turbonator cal in my car and the way mines set up is any time there is knock, the check engine light blinks, I dont know how much knock, what voltage, or how many degrees of timing is pulled, but I do know it is knocking and to back out of the throttle.

I like to have as much data available to me so I can decide what I want and need, the more engine parameters logged for me the better!

Yes I would agree that logging AFR in MPSCAN is CRITICAL and if that cant be done easily there really is no point in logging at all. AFR is about as important as RPM for tuning.

What we need is a plug-and-play way to get ALL required data out of the car and into excel with no fussing. These forums should be SWARMING with data from logging runs but I think you can count the number of people who actual log and review data on one or two hands. The current way is just too inconvenient and difficult for whatever reasons. Or maybe I'm wrong but thats my perspective at this moment. Would like to hear discussion on this.

Yes, the knock indicator light is better than nothing, but not really good enough to let you monitor the situation and start to get an intimate idea about what the knock sensor and your tune are doing at all times.

If IPHONE supports bluetooth spp then if whatever this device becomes spits out data over bluetooth then you should at least be able to log it on your iphone.

Ive been thinking more about how a new device could be queried by MPSCAN just like the ECU and provide data from auxillary inputs like thermocouples, AFR, etc..

Its seeming more and more realistic and easy to implement:

1- look through the ram locations in the ECU and pick a few that nobody logs and have obscure data nobody cares about
2- how about "SparkScatter" at 0xE5 for instance
3- this device will be a "pass through" so that the SCI bus goes THROUGH it, and therefore it can disconnect the ECU's transmit (data out) line whenever it wants
4- its also monitoring the ECU's receive line, so it sees all the commands/ram location MPSCAN is sending to the ECU
5- when this device sees MPSCAN request "SparkScatter" at 0xE5, it momentarily disconnects the ECU's TX line (so the ECU's response goes nowhere), and takes over the TX line, transmitting to MPSCAN whatever auxillary input it digitized..like AFR, thermocouple, etc..

So then you dont need any changes to MPSCAN.

And I should be able to test this functionality out 100%

It may seem complicated and difficult but its really not. Things on the SCI bus happen in 1/1000th of a second time scale but things on the PIC processor I'm using happen 10,000 times faster..there is plenty of time to be disconnecting TX lines and doing shenanigans like this. All you need is a mux connected to the PIC and voila

And since you will already have the whole MPTUNE laptop mess in your car for a tuning session, its okay to have MPSCAN logging too, no need for the gauge to log and add a step getting data from the gauge/phone to your laptop.

But when you are just driving/racing with no laptop, then the gauge will log everything including all its inputs and the selected ECU parameters, for dump to your phone for later analysis.

??

[DoubleD]

I was thinking about this on lunch at work today, How would the cabled for connecting this gauge work? Are you planning on having a cord go from the gauge to the SCi connector and then have a usb cord on the back of the gauge that you could plug into a computer. One small detail about MPTune and using Rob's flashable chip, on Rob's chord you need to have one wire on the sci connector go to a "switchable" 12v source. I can see that being easily ran off the same power wire that could run the gauge, but just another thing to think about. The more every little detail is brought up before, the easier it will be to make sure everything is working right the first time.

I just looked and Apple does not support SSP directly, but there seems to be work arounds.

What year is your Daytona, the traveler I posted earlier in this topic is out of a Lebaron, tapping into two wires on the BCM will give you all of the ouput of the traveler in a Daytona and the Lebaron one bolts directly in place of one of the cubbies in the center stack. The one I showed will go in a 91+ Daytona with the more "modern" dash.
For my car I have an extra cubby that I will just cut up and mount the round gauge in and still have half of a cubby useable. I will take whatever this device ends up being apart and swap the yellow display for a blue one to match the rest of my mods.

[acannell]

I was thinking about this on lunch at work today, How would the cabled for connecting this gauge work? Are you planning on having a cord go from the gauge to the SCi connector and then have a usb cord on the back of the gauge that you could plug into a computer. One small detail about MPTune and using Rob's flashable chip, on Rob's chord you need to have one wire on the sci connector go to a "switchable" 12v source. I can see that being easily ran off the same power wire that could run the gauge, but just another thing to think about. The more every little detail is brought up before, the easier it will be to make sure everything is working right the first time.

I just looked and Apple does not support SSP directly, but there seems to be work arounds.

What year is your Daytona, the traveler I posted earlier in this topic is out of a Lebaron, tapping into two wires on the BCM will give you all of the ouput of the traveler in a Daytona and the Lebaron one bolts directly in place of one of the cubbies in the center stack. The one I showed will go in a 91+ Daytona with the more "modern" dash.
For my car I have an extra cubby that I will just cut up and mount the round gauge in and still have half of a cubby useable. I will take whatever this device ends up being apart and swap the yellow display for a blue one to match the rest of my mods.

Yep I would say a cord from the vehicle diagnostic connector up to the gauge, and then the gauge has a cord that is gets mounted somewhere in the cabin so you can connect whatever you want to it be it MPSCAN, OTC2000, DRB 2..etc..

To save money that part of it could just be the factory connector cut off and reconnected to the cable coming out of the gauge.

There should be no problem passing switchable 12V to the in-cab diag conn.

[acannell]

I think we need to list the scenarios where engine monitoring takes place:

Daily driving/racing: No laptop. Just your gauges. Possible your phone and in that case all ECU parameters and any gauge inputs can be logged automatically to your phone via bluetooth.

Dedicated tuning session on DYNO: Laptop present. So in that case, log everything with MPSCAN. Tuning with MPTUNE. Gauge acts as pass-through to provide MPSCAN with its auxillary inputs, as well as display knock or whatever ecu parameter you want on the gauge display, which is still useful even in a dyno, for the guy operating the car.

"Shotgun" tuning session: Laptop present, riding "shotgun" in the passenger seat. Just like the Dedicated tuning DYNO session except less tolerant of hassle and inconvenience as far as wires or procedures. You want to be able to pull over,review the run, modify the tune, and get back on the road for the next run as quickly and as easily as possible.

Ad-hoc troubleshooting: No laptop present. Gauge user interface allows OTC2000 functionality. Troubleshoot your car wherever you are at any time.

So its starting to seem the this device would really kick A$$ and go full win-win in all categories if it had the following features:

-several auxillary inputs for AFR, thermocouples, etc..
-allow MPSCAN to access its inputs via a "pass through" mode..so now MPSCAN can log the aux inputs/AFR connected to the gauge
-no interference of flashing or cable swapping required
-"standalone" mode to log all of its aux inputs as well as selected ecu parameters via bluetooth to your phone
-"standalone" mode also shows selected ecu parameters on highly visible gauge-type display
-OTC2000 functionality for sensor,actuator, fault codes

And there we are. I dont believe thats missing anything. Im not sure how cheap that will be though. The electronics I use in the DTGAUGE to sample thermocouples are not cheap, and you cant go cheap on thermocouple sampling. You can go cheap on other stuff though thats just 0-5V. I can delete the "analog output" circuitry from the DTGAUGE. But then we have the need for the two cords with a custom SCI connector. So this full blown ultra-solution wont be $25 but it wont be $125 either. But this would be a BOMB tool and would satisfy even all my wants for logging.

[Vigo]

For price reasons i think if you DONT stop at A or B you will not have many customers. This is a notoriously cheap community and most of the people who have OTC2000s (myself included) bought them for less than $100.

I love the idea of more functionality but if you need to recoup costs it may be steep diminishing returns to go down that path. I love the stuff of yours that i've bought so far but even the price difference between the initial BMF group buy and the one going on now might have killed that for me, so there is always some line even among your supporters where it will be difficult to sell. Not trying to be negative, just expressing my personal opinion. As said, i hope to buy anything that comes out of this thread so my default position on this potential product is optimism.

[acannell]

For price reasons i think if you DONT stop at A or B you will not have many customers. This is a notoriously cheap community and most of the people who have OTC2000s (myself included) bought them for less than $100.

I love the idea of more functionality but if you need to recoup costs it may be steep diminishing returns to go down that path. I love the stuff of yours that i've bought so far but even the price difference between the initial BMF group buy and the one going on now might have killed that for me, so there is always some line even among your supporters where it will be difficult to sell. Not trying to be negative, just expressing my personal opinion. As said, i hope to buy anything that comes out of this thread so my default position on this potential product is optimism.

Your opinion is highly valued as always Vigo!

Im especially excited today because Im starting to realize that this product is what I need to make for myself too.Not having a super easy way to get TONS of data out of the car for factory sensor and beyond is killing my buzz when it comes to tuning cals and tweaking things, not to mention designing new products that have some data behind them. But I dont want to go crazy and build an LCD into the dash with displays either, as cool as that would be, I think it actually would not function as well as a simple 7 seg gauge......unless it was a display that replaced one of the stock instrument cluster modules () hehe...but lets pretend I didnt say that for the moment.

So sorting all this out is helping me figure out what really needs to be what.

Anyone with an OTC2000 could liquidate it to buy this gauge, which would in theory have the same functionality but also be a logger and show things in an easy to read way, permanently installed. So superior to the OTC2000 really and a critical piece of the puzzle in getting the data you need logged and displayed for cal tuning/engine monitoring.

And I think I can keep the price below $100. Depends on where it ends up when all is said and done.

[Vigo]

Oh well if it's below $100 then take my money and build whatever you want. At that price i'm already sold and it doesn't even exist yet.