I am planning to build a dash / interior for my car. It is currently a basically stock 87 fastback auto with a rebuilt motor and 3.1 crank. The electrical is stock as far as I know.

First off my dad came to me the other day to tell me about this computer you can buy called the raspberry pi. Raspberry pi official website - http://www.raspberrypi.org
It's pretty cool. You can buy just the computer for $35 or the whole starter kit for $100. There is also a touch screen you can buy for it for I think $90.

Since I am planning to completely remodel the interior of the car I was wondering if I could buy the raspberry pi and use it like it was a scan tool? I know I would need download OBD 1 system to the raspberry pi and get a cable that runs from the ALDL connection to the raspberry pi. Then I would need a screen to show the data the computer is giving to the raspberry pi so that the raspberry pi can give the info to the screen and I could then see it. I would like the screen to be the gauge cluster. It would now be a complete digital dash with every gauge I'll ever need. I was thinking about putting the touch screen in on the middle area of the dash under where the rally gauges are now and have the radio hooked up somehow. I would have it so I could plug in a USB drive and play music off of that and I plan on getting an Iphone purposely for how good the phone is with music. In the dash plan on having a port USB (like I said) and a spot where I can drop my phone in so it looks integrated into the dash.

I feel like it should work. Is there any reason it shouldn't? Are there better ways of making my gauge cluster read all the gauges like a scan tool?

Cool, I linke your idea and I'm very aware of the RPi as I have one. Not sure about using it as a scan tool since it runs a version of Debian Linux so you need odb1 software made for Linux that would run on an arm CPU. It does have GPIO and serial ports so from a hardware perspective so you should be good.

------------------
White 88 Formula with factory T-TOPS. Number 1016 out of 1252

http://i1167.photobucket.co...35/My87gt/Sig1-1.jpg

Do you like the raspberry pi? Did it live up to your expectations?

Also I am sure that there is a linux operated OBD1 software out there somewhere...

There are no Linux powered OBD1 scanner programs out there that I know of.

This is an example of a dash with TunerPro RT. Remember the gas gauge and the oil pressure gauge don't run through the ECM.



(Ignore his 'glitching' problem, it was a problem with his definition file)

Also remember if you are going to run a scanner on the stock 1227170 ECM, the gauges will update about once a second. Tick - Tick - Tick on the gauge needles updating. If you want to run a 'scanner dash' you should really swap to the 1227730 ECM since the gauges will appear to operate in 'real time'

Also the 7170 ECM wasn't designed to run in scan mode all the time. When it is in scan mode a number of things will happen including altering the engine's timing advance.

[This message has been edited by phonedawgz (edited 04-10-2013).]

I guess I should start researching a 7730 ecm swap then. Is there anything major I should know about in the 7730 ecm swap? Can the 7730 ecm be ran in scan mode all the time?

I had similar thoughts a while back and just finished the build process for a carputer that will go into one of the 2 Fieros I am rebuilding. My intent is not to through cold water on your ideas but rather to give you some thoughts based on the research I did as well as many decades in the computer world. As was pointed out, there are no off-the-shelf packages for the Pi or for the Unix environment. Even a knowledgeable programmer familiar with the platform could expect to spend dedicated several man months of effort to build the software functionality you describe.
Also think about the design you describe. Most auto mobile capable LCD displays are only capable of true 800x600 resolution an that is the 7" to 8" displays. This is not a lot of graphic real estate. You are in IN which means that you have winter temps that go well below freezing and often below 0 degrees. Even most of the auto capable (lilliput for example) barely do 0 degrees -- look at the operating specs for the display and it gerts worse for non-auto LCDs because they can't handle the voltage fluctuations in a car.
There is a reason auto manufacturers use led illuminated mecahnical guages or VFD displays.

If you use the computer for everything then you have a single point of failure -- computer hiccups or fails and there go your guages.

As to locating in the center console below the sports guages ( I am assuming this is what you meant in your post?) The point of guages inline with the steering wheel is so that minimal eye movement is required to check things like speed or the other engine related indicators. The push towards HUDs is to make even less eye movement required. Having to look over to the center console represents a serious distraction fom viewing the road and the need to constantly move ones eyes to check will cause significant eye fatigue.

i hope this provides some food for thought --- I am a firm believer in the usefulness of a carputer but it is not at the stage where one could realistically replace the whole dash with a single display with what is available today -- maybe a trailer queen show car but not something that is regualrly driven

Well I am not a programmer what so ever. So is there a way to upload windows to the raspberry pi?

As for the screen: I take it buy a screen with better resolution and the ability to do negative temps will just cost more? Or they don't offer them?
I'm glad you pointed out that low temps can be bad because I had never thought about that until you said it.

Having the computer being the only failure point doesn't scare me because if the computer fails then it's probably not driveable and if it is then I will only be limping it home to fix the problem.

The main screen that would displays the gauges would go behind the steering wheel like where they are now. A second touch screen for the radio would go under the rally gauges in the center console. Sorry if I was misleading.

For voltage fluctuations couldn't you add a capacitor?

Also are there any other ways of doing this? MCDUCK how did you make your carputer? How did anyone else make his or her carputer?

I was hoping this would work because it would be cheap and easy!

You can find very small mother boards with intergrated graphics, there are power supplies for computers in cars to take care of all the problems you will find doing this, the are extremely small, slightly bigger than the plug on the mother board. Solid state drives are very common and cheap now. You can then run windows and do most anything you can do on youre machine at home only smaller. Larry

Can I be pointed into a good direction of other motherboards?

I am in the process of doing something similar. However, I have a 3800 SC III swapped into my 88 GT. So it has OBD II. There are several manufacturers of OBD II Bluetooth links you can buy that work fine with some of the Android cell phones and Tablets. However there is now an option with a small stick computer running Android 4.2. The MK 809ii runs Android 4.2, has WiFi, Bluetooth, Two micro USB ports that can take the power supply connection, another USB full sized port for a wireless mouse or keyboard. There is a relatively cheap app out there for Android called Torque that works great to run the dash display. I also bought a Coby 15 inch TV that I can connect to the Android Stick computer since that is the way you get a display for it. This Coby is a true 1080p TV screen and is pretty bright at 400 nits and only uses 20 watts of power.

Having said all of this unfortunately the Torque program and the Bluetooth OBD II don't work for OBD 1. I know there is someone on the forum who is trying to develop software for OBD 1 and maybe that could be ported over to operate in an Android system. I hope someone can come up with a way to push the OBD 1 information to a computer such as these Android Sticks so that, that will become an option for OBD 1 systems.

If you go to E-bay and search for carputer you will find several vendors that have computer hardware packages designed for automotive use. They are all windows based and use either the Intel Atom or the Intel i-series processors. You can also look at the mini-box or mo-co-so websites for what is available from e-tailers. As an all encompasing software package, Centrafuse is probably the closest thing to an (out of the box) integrated environment. It handles multi-media, bluetooth, web, wireless, and has add-in support for navigation. OBDII software such as OBDWhiz can be launched within its shell. I would not call it mature or troublefree but it seems to work fairly well and has a free SDK that is allowing users who are techincally capable to build add-ins for it. Going through their website would be useful.

As MadMark posted, there are ways to potentially roll your own in the Android environment but prepare to spend time troubleshooting possible incompatabilities between various pieces and designing the integration.

Just as a side note --- I would tend to avoid both wireless lan and wide range bluetooth adapters. Both leave you open to possible virus contamination and I would not want that in a system that is connected to the car's ECM. In a car, you only need a very short range bluetooth capability as the phone to computer is never more than a few feet and all Windows motherboards today come with wired lan built right on the motherboard. If you really need an Ian connection for doing work on the system, I would rather put an access point in the garage and hardwire to it from the car as required. For connecting to OBDII I would rather use a USB to OBDII adapter and stay hard wired -- less susceptible to interference and more reliable.

The PI will run windows 3.1 :S but I don't think that's a good idea. If you were to go the PI route you would be better of with the default Raspin build and writing your own code in python.

Well I have recently found these:

https://www.miniand.com/products/MK802%20Android%20Mini%20PC
http://cubieboard.org/
http://beagleboard.org/
http://www.pandaboard.org/content/platform
http://www.solid-run.com/products/cubox
http://apc.io/products/
http://www.amazon.com/Mele-...ptical/dp/B008PBTS18

Does anyone see any problems with these? Anyone familiar with any of them? I'm asking before I researched to much but I'm pretty sure they all use android.

{edit}

Also why would running the 3.1 windows be a bad idea?

MCDUCK - All of the carputers on ebay are very expensive. I was planning on trying to get this done for around $400. Like with the Raspberry PI you have 35 dollars in the computer then you need a 12 inch or so screen that would be the gauges about $100 dollars then a 7 inch touch screen (135) that would control the radio a with USB jack and headphone jack that run into the computer and the touch screen would be the mouse and screen for the computer so I could go into individual files and select my music I want to play. Then I would need to buy an ALDL connector that costs around

35+100+135+75=345

So with 55 Extra dollars I'm sure I could buy any misc wires. That budget obviously only includes the electronics portion without speakers and other misc.

[This message has been edited by Shonyman32 (edited 04-11-2013).]

No need to be extra paranoid about bluetooth or wifi. Both are reasonably secure if you do everything correctly. Just don't be promiscuous about connecting to random devices.

As for cost of the screen, it's not just a 7 or 12 inch screen you need. They need to be fast enough and bright enough in direct sunlight, and for the gauges at least, needs to have very fast refresh rate with basically no lag. You also want to avoid ones with cheap glass that can get picture burn-in.

Also, as already mentioned, running gauges off the ECM is going to be problematic with stock Fiero equipment. It's way too slow. I wouldn't do it on anything that wasn't OBD-II, honestly. If you really want to do it without swapping to an OBD-II drivetrain, a custom solution with additional sensors for various things, that can operate in real time, would be the best route to go I think.

Well I do plan to put in a 3800 eventually but I don't have the space to perminately commit to a build so I am just slowly building up the an extra cradle with it. That will be OBD II but that is at least a year off. So would switching to the 7730 ECM not be good enough?

With the 7730 the reaction time is as quick as a mechanical meter needle will move.

When I test my bluetooth OBD1 adapters that I build I wet my finger and touch the bare pins to make sure things are connected and working. The reaction appears to be instantaneous. That considering that with the bluetooth there is that additional link and it's delay.

Compared to the stock Fiero electro-mechanical gauge needle, I will say the reaction time is quicker with the 7730/OBD1.

Well I now know for a fact that I will need the 7730 ECM or have OBD 2 system and OBD 2 is out of the question for now.

Pretty much any OBD2 system is going to require two crank sensors and a cam sensor. The 2.8 iron head, 3.1 iron head and 3.4 iron head engines won't support it.

To go OBD2 you would have to run a 96+ 3100 3400 3500 or 3800.

Well I am running a 3.1 block but I do not know the year. It does have a position for a crank sensor that I plugged. It has a 2.8 top end though. So that means Iron heads. I really don't want to switch to OBD 2 if I could use the 7730 ECM. Unless OBD 2 is easier.

I have also found a microcomputer called the gooseberry. It runs Android and looks way more "doable" than the raspberry pi since there are no OBD I software on linux.
The gooseberry looks just as good as the raspberry did with first impression.

The center crank pick up is a 7x pick up. The 7x is needed for DIS, and you could drop the distributor. 7x = 7 pulses per crank rotation. GM started running DIS about 1990 on these engines.

To be OBD2 you also need the 24x CKP Crankshaft Position sensor at the front of the engine under the balancer and the CMP Camshaft Position sensor near the cam.

CKP


The CMP is the cable by the oil filler cap that runs to the left (front) of the engine. This is a 3100 aluminum head engine.


----
There is no OBD1 software on android either. I have started with a project of writing it. That project is way behind scheduled.

One problem with the android solution is the only way to get the OBD1 signal into the android is via Bluetooth. Also btw I sell the only OBD1 USB device. - http://www.reddevilriver.com/ALDL_Bluetooth.php -

Right now it's only application is for windows users w/ laptop/tablets running windows scanner programs.

So I need to get the android interface working to increase the market of OBD1 Bluetooth devices.

[This message has been edited by phonedawgz (edited 04-12-2013).]

"There is no OBD1 software on android either. I have started with a project of writing it. That project is way behind scheduled.

One problem with the android solution is the only way to get the OBD1 signal into the android is via Bluetooth. Also btw I sell the only OBD1 USB device. - http://www.reddevilriver.com/ALDL_Bluetooth.php - "

If you get an Android Stick it will have at least two USB connectors on it. One for power, usually a micro connector and the other can be used for a wireless mouse or anything else that comes through the USB. I have even seen on the Android forums where people use USB multipliers off of the larger port so that they can hook up other things along with a mouse/keyboard. Things like an Ethernet to USB or USB to serial. So there are a lot of option out there for the small Android Stick computers.

I hope that you keep working on your OBD 1 software, it will be a great addition to the available things you can do to help with displaying information on the older engines.

quote Originally posted by phonedawgz: There are no Linux powered OBD1 scanner programs out there that I know of.

There is. I wrote one.

http://steventsnyder.com/linuxaldl/

I use it with my OBD1 3.4 DOHC Fiero running $DF code on the 9396 ECU.

Some users have made definitions for other ECUs and firmware. I can provide all of the necessary information for writing and compiling new definitions for any GM OBD I application, just send me a PM or e-mail.

[This message has been edited by Steven Snyder (edited 04-12-2013).]

Wow that's awesome Steven.

And MadMark I do plan on continuing OBD1 but thanks for the info PhoneDawgs.

BTW - PM sent (Steven)