Subaru Impreza GC8 & RS Forum & Community banner

2061 - 2080 of 2558 Posts

·
Registered
99'RS w/EJ205, 16'340i 13'Volt
Joined
·
969 Posts
wouldnt be an RS25 thread without people telling other people what to and what not to do to their car. :)
 

·
Registered
Cheap Kitchens
Joined
·
1,889 Posts
I lowered my posts per page specifically because of this thread taking a million years to load
 

·
They call me Garrett
98 RBP V4 STi Swapped RS
Joined
·
4,088 Posts
Discussion Starter #2,070
Polk DB651 Rear Speakers

Finally got around to putting these rear speakers in after limping along the OEM ones that were dying.

I went with the slim mount speakers and I'm really glad that I did. They couldn't have fit more perfectly. Bolted right up the OEM holes... which NEVER happens for speakers. Really happy.

All I had to to was solder on some blade connectors to go to the factory harness and now the rear speakers in the car don't sound like a garbled mess.

Oh and taking off the decklid for the first time ever. One of the only pieces on the car that has never been removed. While it was out I reglued the fabric as it was coming up. I'll hopefully soon be swap this deck lid out for the JDM one with the cutout for the wiper, but until then I'll take this.







 

·
Premium Member
96 Impreza Coupe
Joined
·
1,583 Posts
Did you recover the parcel shelf or just add some more glue to the one fabric? Either way looks good!

The Particle board on min is starting to fall apart. I wouldn't mind the carbon one from Rallye Tech Composites if it wasn't so darn expensive to ship over here.
 

·
Registered
'00 RS / V5 STI
Joined
·
577 Posts
You should have told me David I had one a few months ago.

Someone wanted it so bad, they asked me to cut the wood in half, I did super clean and shipped, they were stoked.
Meanwhile mine's broken in 3 pieces and looks like complete ass.

I want to fiberglass something back there and wrap it to match. Can't be too hard, right? Right...?

-TC
 

·
#32
95 Coupe, 95 Sedan & 95 Wagon
Joined
·
12,223 Posts
I don't have them, too much weight.

Psh, what's an interior. I have front door cards (cut) only because I have to. Oh and >50% of the dash left too I guess...


ahh who am I kidding.



I have those parts in the garage ready to go in my shells... someday
 

·
They call me Garrett
98 RBP V4 STi Swapped RS
Joined
·
4,088 Posts
Discussion Starter #2,078 (Edited)
It's winter here in Michigan, which means my desire to be in a garage is just as low as my desire to live. It's been extremely cold for a couple weeks here and because I go stir crazy if all I can do is drink beer (New Holland Cabin Fever by the way is the drink of choice) and snuggle up on a couch, I took it upon myself to go work on something that would teach me some stuff I wanted to learn, as well as have a functional end use. You won't find that sentence in a college level controllers course!

So: I had an idea to create my own k-line transceiver to work on my own controller so I can process the data specifically, quickly and only use it for a very niche application. In English, I am basically building a personal ROMraider that's a bit easier to use, has a bit less functionality, but turns on immediately without hassle. The benefit of this? Honestly, I just want ECU parameters displayed alongside the rest of my gauges in a nice looking manner with the ability to expand to anything with a reprogram.

So with this project there are two different portions of the design and functionality:

1. K-line data interpolation, getting the data from the ECU and turning into useful data a human can read
2. Graphics and display, showing off the data that a human can read in an attractive and useful manner

Right now I'll say before jumping into this I knew pretty much NOTHING about graphics, and I still stand by that. It's very confusing to me how it's done in a professional setting and how graphics run in embedded systems. We'll get more into that later. As far as the K-line data interpolation goes, I am pretty versed in serial communications but had to teach myself the Subaru Select Monitor (SSM) protocol and translate that from ECU language to human language and vice verse in order to keep the ECU happy and giving me what I want it. The point I am trying to make here is that I have no absolute idea of what I am doing, so I'm sure there are many things that are completely and utterly wrong, inefficient and stupid.... but when has that stopped me before?

Because I knew less than nothing about the display portion of things I started working with that. I started with a super basic OLED tft screen that had basic support for ease of making a display. It was a basic Adafruit display that was about the same size as a 52mm gauge so it looked like a great way to start. I had to manually draw each line/circle/text/ everything pixel by pixel and it was very tedious to work with especially trying to write over pixels I didn't want to change. I came up with some example stuff like this:







All of this took way more math than I want to admit to display ticks, numbers and move the needle. Lots of bringing back old sine/cosine logic from my math classes in school. It was also asking a lot from a little 16MHz controller to do all of the math needed to make it pleasurable to look at, and I'd say pleasurable was a stretch. I sort of came to the conclusion that these displays were pretty good for a nice looking numerical display and needed a dedicated graphics controller to process it all while something else sent the data. I then came up with this simple example screen:



After that I decided to move on to something a bit easier to work with and that included a dedicated GUI creator that supported the screens. I went with a Nextion screen that had it's own 100MHz graphics controller and software to help build a GUI. The screen has a bit bigger and I don't think it would fit well in a gauge slot, but it had the power and ease of development I was looking for as a newgamer in the graphics field. After waiting the typical 3-10 weeks (ended up being about 3 and a half) shipping from Hong Kong the screen came in and I threw together some example gauges to familiarize myself with their GUI creation software.



Using some pots to emulate data that would come in, as well as an external controller these gauges moved with an OKAY refresh, but more importantly, minimal effort. I think there's some videos I didn't upload so I'll add these when I have a chance to. It's pretty cool to watch, even with a startup sequence.

I was finding some issues using some of the built in functions of the Nextion software and I did some reading about how others were sort of "working around" these issues by basically creating images of every possible scenario on the display and just calling for each one given your input data. This process is tedious as hell, not very intuitive, definitely not efficient... but it was effective. I wanted to see how fast the screen would reload an entire image without using a built in function. To do this, I had an idea to have a live ECU map displayed. Not super useful, but cool to look at and could easily be calculated based on data from the ECU. Now, it's not as easy as you may think to do this. I can't just "grab the tables off the ECU" because that's just not how it works. I had to create the tables and each scenario of what cell the ECU would be operating in to be displayed. This resulted in a specific map specific to that ECU calibration and about 85 images all loaded into the graphics controller flash memory. The max memory was 32MB and I was using 27MB for just this simple function. Like I said, not efficient.

The end result looked a bit like so, and I am sorry for the bad picture. I took it from a video I made because apparently I didn't take any pictures of the result.




Basically, the cells were all shown and a little red cursor blips around to show what cell the ECU is currently using from the map in memory. Kinda kewl. I used two pots to emulate the throttle position and engine speed (X and Y axes respectively). Worked wonderfully and the display update was immaculate.

What I learned from this was that the Nextion software was pretty garbo with it's built in functions with no coding, but it was easy to get something that doesn't require a good refresh rate. Hmm. A bit let down with this result, as well as frustrated with the other display I was a bit let down and decided to move on to getting data from the ECU and would come back to the graphics later. No point in solidifying a good display without even having the data TO display yet.

Will continue with this in another post because this one is getting long and I don't feel like having it all erased.
 

·
They call me Garrett
98 RBP V4 STi Swapped RS
Joined
·
4,088 Posts
Discussion Starter #2,079 (Edited)
To dive into k-line sending and receiving took me a lot of research, so I'll try to write out some pace notes. K-line is an ISO standard serial data communication used for vehicle ECUs before CANbus because the new standard. It's an old, slow single line communication designed in the 90s made to talk with ECUs for diagnostic and data purposes. It's essentially the Gran Turismo 2 of video games in the sense that when it came out it was top freaking notch, holds up great as time goes on, but man does it look dated. To give an example, the serial data line communicates at 4800 baud, which is 600 bytes/s. not MEGAbytes or GIGAbytes, but bytes. A high speed CAN communication line used in cars today (and is being replaced with an even faster standard) runs at 500,000 baud or 61 kbytes/s or 61,000 byte/s

Basically, it's 10x slower at giving data than cars today. Imagine this post loaded 10x slower when you loaded it up, that's k-line.

REGARDLESS, there's enough data to be had and really, 600 bytes/s isn't awful for just logging a few parameters of interest especially when each parameter is only 2 bytes of data at most (I think?? don't take my word for this).

I should also note I took a lot of information from this post here: Clock pod mod with Subarb Select Monitor ECU polling and Arduino

This guy has a lot of good info in his post, but it's also a lot all at once and some if his data is bit off, but it definitely helped me get started.

First things first: To process data I am using an Arduino, which has data send and receive on two different ports. And the ECU k-line was is a single line send and receive line. To do this, I needed to split the line into two lines. The ECU data is also operating at 12 volts and the controller reads a maximum of 5 volts. This means that if I applied the 12v communication line to the 5v controller ports, it would either blow silicone right off the chip, or just (more likely) clip the signal and the controller would never see a pulse for data.

To rectify that situation, I with a bit of help from the ol' father and the man in the post I used some simple, cheapy BJTs (bi-polar junction transistors) to step up the 5v transmit line to 12vs to send data to the ECU, and step down the 12v ECU response to 5v receive port. I also needed to add in another transistor to use as an inverter because apparently the serial ports on the controller are pulled up, meaning always 5v if there is no data coming into it.

They make buffer chips for this sort of thing, but it was easy, cheap, and i could debug problems easier with this setup. I'd like to move to CMOS transistors eventually because of some ghetto pulling down I had to do with the .7v drop from the BJTs in order to get a proper 0v level when data comes in (thanks for the debug help Dad!).

I need to make a schematic and post it up because the one the guy used in the thread I've referenced is kind of a backasswards way of drawing it out, and I have some differences in my hardware. Also I don't think I have a great picture of everything hooked up, but I'll add some in if I can remember. I know this is a lot of text without a picture. STICK WITH ME!

Sorry if that's confusing to some people, basically all you need to know is that I turned 12 volts into 5 volts so that the controller I am using didn't explode and could maintain good communication.

My first thought at how to go about talking to an ECU was to have everything directly hooked up to my car and just to run data to and from it for development. Well, as it turns out, it's COLD in a garage, there's not much room to lay out lots of components, equipment and crawling under a dash to change things didn't sound appealing. So I grabbed one of my many spare ECU pigtails, got out a plywood board (previous painted by my sister for whatever reason) and hooked up a sorta ghetto, but perfectly acceptable in the world of Garrett bench ECU test rigs.



Not a great picture because I made quite a few changes to it after I took the picture, but you get the gist. ECU on a bench, wires spread out for ease of figuring it out, and property ghetto. If you're curious the pieces I added into the picture were a functioning main relay like the car would have to turn ECU power on, a different ECU hooked up, and more wires spread out and labeled. The wires I put up and labeled were the single line k-line send data line, the ECU test mode line, the two memflash lines and the vehicle VSS line. We'll get more into these in a second.

In order to verify my bench actually worked before wasting a bunch of time programming a controller to talk to it, I hooked up a known good ECU querying device, the good ol' tractrix and ROMraider. This would show me if I was getting ECU data with the ECU on the bench, or if I had just wasted my time and destroyed my sister's priceless middle school art. To do so I just hooked up the tractrix cable like it would have been in an OBD port (12v, ground, k-line data), turned on the computer and ECU and off it went.

Now going back to why I hooked up a VSS. I was looking for some easy to create parameters on the bench that would be sent over serial communication lines. At first i tried to emulate the crank position sensor since I wanted vehicle speed available but, but as it (obviously now) turns out, the ECU doesn't ONLY use a crank position sensor to determine RPM. There's a lot more smarts going on to do such a thing, and rightfully so.

Vehicle speed is something I am super familiar with after working with the clusters, as well as something super easy to emulate with a waveform generator. Vehicle speed is also broadcast over the k-line so it was perfect to use just to verify I am getting data. Hooked up the VSS lines from the ECU to my waveform generator, turned up frequency and pulled up the parameter on romraider. We had data and a vehicle speed read, and my tester was working. Here's a picture of the whole setup. You can see some of the new modifications to the ECU board and some of the electronics laid out.



With a working bench tester, I was now ready to go to get my controller running.

I'll continue this in yet ANOTHER post, because it's a lot to write down and I have to take a short break to get a few things done.
 

·
They call me Garrett
98 RBP V4 STi Swapped RS
Joined
·
4,088 Posts
Discussion Starter #2,080 (Edited)
Alright. Let's write this next post.

So in order to program a controller to talk to the Subaru ECU, I had to first understand how to speak in ECU language. There's a lot of good information on this on the romraider forums, more specifically right here: RomRaider - Open Source ECU Tools | RomRaider / Ssm Protocol. This is basically the ECU's language it speaks and you must speak to that ECU in that language just as you would a person. If a person who doesn't speak Japanese is asked a question in Japanese, there's a very good chance that person will not be able to fulfill the request. Same works for computers.

I set up the basics for the code to start serial data, send data. At first I wasn't to make sure that I was sending data, so the o-scope was hooked up to the send line on my controller and this is what I got.



Cool, we are definitely sending data and you can see the simple ups and downs in voltage, and these correspond to the 0s and 1s that are read by the ECU and controller. The sent data is sent in a packet, and is basically a question asked of the ECU. More about "packets" in a second.

With some help from the post in the post above I was able to then receive the data back from the ECU, and the data received from the ECU is very important data. I'll let you read about that on ROMraider forums.

Basically the ECU response to initialization tells the "diagnostic tool", which in this case is my controller, what functionality the controller has. This is important in the design/diagnostic world so that the machine knows what it can and can't send to the ECU with tools made to work with a bunch of ECUs.

The data coming back from the ECU is called a packet, because it's a bunch of bytes of data all in received in one foul swoop. It's a sentence spoken by the ECU in response to the question you've asked it. Your internet works the same way, just in the scale of Gigabits per second instead of bytes per second.

It may sound goofy, but I wanted to make sure I understood the data coming back in order to craft a sentence in English to be translated into ECU speak, so I wrote each byte of the packet sent to my controller and translated it into English.

From here we can see exactly what the ECU is telling me, and when compared to the actual ROM hex file, we see the data it's actually polling. This not only allowed me to understand the ECU, but also see that the response packet was genuine and my controller was interpreting it correctly. I was stoked.





Along with the memory being shown, there are also capability bits... but feel free to read about them on ROMraider since they aren't super important for this project. Well, they are, but the fact they are all documented is pretty much the extent that I care about for it. Anyways.

With the ECU initialized and ready to give me more information, me understand how to translate English to ECU, I put together a simple packet to send to the ECU to request vehicle speed.



Seeing the response from the ECU made me all sorts of happy, so I took a video just showing off the vehicle speed in the diagnostics console I made:


After that success I decided to merge the graphics and the communications elements to together and just get something displayed on a screen. It was a bit challenging as I had to isolate the data from just throwing up on to a diagnostics screen and actually process it, but I made quick work of that with the help of the ROMraider logger XML and some easy math to store data in the controller. I THINK I can store it quicker and faster using flashmem/ram more effectively.. but that's another day's worth of writing.

I also cobbled together the most garbage looking LCD display in the world that just displayed BASIC numbers slowly and here it is!




After that success I gathered up some more code to revise my packet to request for battery voltage too (read: power supply voltage) and that worked wonderfully! Unfortunately just for not wanting to waste a ton of time getting stuff up and running, the voltage is displayed as an integer and not a float, so no decimal points. However, I was able to print a float on in the diagnostics and it's got accuracy to .01v. I think it's more accurate than my chinesium power supply voltage display. Cool!



Tonight I just went through the code some more and made a lot of things way more efficient to run and easier for me to read and understand when I look back at it. I also was able to get the ECUpolling much more reliably.


Moving forward on this project:

I would really like to work on the graphics display portion a lot more as we've seen that the data is super easy to get and SEEMS (hah, careful..) to be reliably working. I may also consider moving back to the old screen since ECU parameters are SUPER basic and it may be much quicker and easier to interface with. Time and experimentation will tell.

Communications wise, I would like to port the software over to a bit bigger of a controller, and something with dedicated serial buses for ECU communications, diagnostic display, and graphic display. I am using a software based serial port for talking to the ECU right now, and it works using controller interrupts (look it up on google) as opposed to a proper serial buffer (also look it up on google), which I think is making things less efficient and less reliable. This is a roadblock I wasn't really expecting to have, but it seems pretty easily overcome with a bit of research and cash.

I will post any updates on this as I make more progress on it.. and it's already working better than I could have imagined!
 
2061 - 2080 of 2558 Posts
Top