The Max

Yep, working with the OEM touchscreen is the ultimate goal here. Not terribly happy that we've only got composite video to work with, as it won't be as sharp as a VGA signal, which is what the screen seems to natively support. If it shits me enough, the BridgeX device can convert to VGA as well, so I would be OK from a conversion standpoint. Only thing that would be needed after that is to have it intelligently switch the screen to the VGA signal when I press the Aux button but to switch back when I tap into another screen, including the side camera, or engage the reverse gear. Keep It Simple Stupid comes to mind for now. :) I really don't want to start implementing additional switches for flicking the touchscreen between devices, more so for the sake of keeping the installation as clean and factory as possible. That's why if I'm going to implement it at all, I want to leverage existing switches in the dash to take advantage of that, perhaps steal one of the useless GPS buttons that's in the button panel in front of the screen to switch it, but that will be another circuit design for another time. Best to attack this one step at a time so that I don't go wasting money and development time on an overall mediocre result. I'm busy enough with my job as it is. It's a miracle I've found any time at all to work on any of this.

That's an interesting find (Crankshaft). Totally different to what I've been gradually working on the last few months or so. I, too, am leveraging the OEM system as much as possible. My design entails: Gigabyte i7 NUC with 1TB SSD (and custom-designed ignition sensing power management circuit, controlling an eBay Hong Kong sourced 19V buck-boost converter) Digital Forecast BridgeX HDMI to Composite converter Microchip's now deprecated AR1100 resistive touchscreen USB interface Garmin 18x-5Hz GPS antenna with MapFactor navigation software JDS Labs EL-DAC with Foobar2000 audio player, running what I hope will be a good overlay for 7" screens Custom-designed regulated power supplies to power both the video converter and the audio DAC - the video converter probably didn't need the 12VDC regulated supply but I couldn't get anyone from the Korean manufacturer to confirm the highest possible voltage that their regulation circuitry would allow The reason for all that horsepower instead of a Raspberry Pi is largely for the GPS software. I've looked at the (rare) Linux alternatives but I've found that MapFactor works extremely well. Since it's only suited to the Windows platform, that forced my hand to run Windows 7. Being GPS, I figured I wanted faster calculation speed than most dedicated GPS units out there (and especially Android apps on phones!), so I threw as much horsepower as was practical out of a NUC that would fit in the boot. The AR1100 is readily recognised with the appropriate drivers but I have yet to plug it into the touchscreen overlay to see how well it does work. Backup plan for that will be a Bluetooth mouse in the interim until a touchscreen solution is figured out. The ultimate goal here is to use the NUC for navigation and entertainment (for the sake of receiving voice assistance while music is blasting), while maintaining the OEM phone hands-free Bluetooth interface. I'm happy to forego the ability to dial phone numbers manually with the touchscreen for the moment, until I can be bothered to research the connectivity differences between the AR1100 and the OEM headunit, for the purposes of designing a splitter that can share the touchscreen between both devices. Once the project is eventually at a reasonable state of progress, I'll start a little write-up on it, like I did with my amp and speakers upgrade thing a long while ago. In the meantime, I'd like to see more of these projects being published here for comparison (and just a good learning exercise) for everyone.

I'm not talking about delays in operation. I'm talking about reliability overall. Last thing I want is for the air con to completely stop working on a hot day. That's just one example.

Looks to me like it takes over the climate control as well, even though they have kept the physical buttons underneath, which could just be a careless Photoshop job. If it were only for the entertainment and possibly navigation system, then I might not be so dismissive. But when it taps into critical systems, hell no. Android is not the ideal operating system for embedded applications, which is why typically QNX (and similar operating systems) are the OS of choice in embedded systems - they're extremely lean, so they load up fast and they are far more robust. A lot of money and R&D goes into developing these OSes and their relevant software applications that sit on top. Nobody in China is going to put in the same effort unless they're contracted to do so by a reputable manufacturer. To summarise my answer, not a chance in hell.

Got to love a stereo system that can boof you while you're driving.

If you want to be sure, components like that will typically have a part number stamped on them. See if you can find it on that canister and if it doesn't match what Rusty's told you, search for it on http://nissan.epc-data.com or otherwise just Google it.

OK guys (and Happy New Year). It took me a while but that's only because I'm on break from work, finally! In short, I fixed it. In long, our V36 has a Pop-Up Bonnet module hiding in the boot, immediately behind the back seat (see photo). You need to remove the false flooring to get to it but once it's uncovered, it's easy to remove. One 10mm bolt holds it in place. Unbolt, unplug and remove the two philips head screws bolting the mounting bracket to the module casing. With a T15 Torx driver, remove the four screws holding the back cover down and remove the housing. Then you can remove the rear plate which had the Torx screws going through it and there you will find the 24C08 EEPROM that needs to have its crash data wiped. Easiest way to do this is with an EEPROM programmer that can do ICSP (In-Circuit Serial Programming). I already had one in my toolkit from a long while ago for past projects. If you're interested in the one I use, it can be found here: https://www.reveltronics.com/en/products/revelprog-is-serial-memory-programmer-usb I bought it with the 8-pin in-circuit IC clip required for the job. You can also do the chip work by desoldering the IC from the PCB but you need a decent hot air SMD rework station and even then, Bosch use an adhesive to keep the chip in place, so it's a bit of a bastard to get it off the board, with the confidence that you won't destroy any of the solder pads. In the end, why make it harder for yourself? ICSP is the way to go here! As this was my first time wiping crash data from any automotive device, I was not sure what to look for in the hex code. So, I visited another site, www.tachosoft.com, who sell airbag reset hex data for a wide variety of vehicles, and yes, they do also have listed the Nissan Skyline V36 (not as an Infiniti) with the JK40A Bosch module. I think it was around $40 for the service. I simply read the hex code in the EEPROM using my programmer, saved it to a file, uploaded it to their site (after paying up) and received the fixed file within seconds. Clearly there's some kind of known pattern which they are aware of and have it in a script to modify in your module's code. I then wrote the newly modified hex code back to the EEPROM and verified the code once more for posterity. Put the module back together and back in the vehicle. No more permanent warning light on my dash, only for the first few seconds upon starting the car. Ran my Consult3+ tool to be sure and no DTCs were active, so you won't even need to visit a dealership to get any DTCs cleared for it. I have checked the differences between the "crashed" code and the "clear" code. What I've found is that all they've done is erased (set to 0xFF) a small chunk of data just after the header, for all of about 176 bytes or so (see screenshot). Not much in it at all. And to think, I fixed it myself for $40, though if you include the cost of the programmer and in-circuit clip, you're looking at around another $180 or so. Even then, $220 is a small price to pay compared to the $2500 that some others have been quoted. So, now you know what to do to solve your pop-up bonnet problems without forking out a massive wad of cash. Of course, if you're insured, may as well just let them deal with it but otherwise, I hope my experience helps you guys out.

So in other words, he's going to get a steel pipe, hammer and gut the contents. The guy is so full of manure, he could fertilize a farm.

Dude, buy a set of high flow aftermarket cats. You don't "regenerate" or rebuild cats. You replace them. Don't be tight about it.

If they're the OEM rotors and have a fair few miles on them, check to see if they have a little bit of a lip on them. If so, then it's possible that your pad wear indicator (that little bit of spring steel that scrapes the edge of the rotor when low) is prematurely activated by the pad sinking deeper into a thinner disc, thereby making contact with the lip a lot sooner than it should be. Otherwise, as per Dashyy's suggestion, if you don't already have the adhesive between your shims and the pads' backing plate, then you really do need it. My V36 already had that stuff on the shims when I changed my pads, though I'm not sure if that was the work of the compliance workshop here or if that was from the factory. At any rate, the stuff stayed on the shims when I removed them from the previous crappy pads, so I simply clipped them onto the new EBCs with the adhesive intact and I'm still squeal-free to this day.

What discs are you using?

I can imagine the cost of the module would be pretty hefty. Add to that the cost of the rams and all the labour involved, plus the sparkie or dealership to do the CAN diagnostics reset after the fact, I can see why it would add up so quickly. Well, screw them! I'll happily be the guinea pig on this one. After all, I've wasted $500 already on a new IPDM, inherently turning my original one into a spare (since I can't be bothered changing them back over again). What's another $50 on a bit of EEPROM code to flash? Lucky for me, I've already got the hardware to do all this stuff myself, so no further investment there. Hopefully I'll get onto it soon and I'll put the information out for everyone else to take advantage of as well. There's no reason why we should be so wasteful over the idea of a pedestrian slamming their head on one's bonnet. Yes, I am a horrible human being at times. It is what it is. :)

Apologies for once again resurrecting this thread but I need to correct the information that I read in that 370Z link, as well as a couple other sites. It's not the IPDM that needs replacing, as I had read in an R35 UK forum. There is another module, which lives somewhere in the back of the V36, similar in functionality to the SRS Airbag control module. This is the control module the dude in the 370Z link above was referring to. In the case of the 370Z, I believe it's a little easier to get to, as it lives somewhere under the dash, I believe. I'm going to embark on my project of installing a mini computer as my GPS and audio centre soon, in which case I expect to also take the opportunity to find out where the diagram from Nissan is actually pointing to, as it's hard to tell if they're talking about somewhere towards the rear of the cabin or in the boot space. The good news is that once I do find it, I'll be able to remove the EEPROM from the module, read the contents, send the data to a mob in the UK called TachoSoft (www.tachosoft.com), who seem to know which part of the code is the crash data that needs to be erased, as I honestly cannot be bothered wasting however many hundreds of dollars on a circuit that otherwise is still likely to be in good working order. I'll be sure to keep my bonnet open when I plug the battery back in after it's all said and done, just in case. :P

As you can see, MyBrains, you're looking at this all wrong. Remapping an ECU is not a cheap task, even if you can get your hands on a generic map to avoid the dyno. The math dispels any theory for cost savings. The engine is mechanically set up to perform. If you're actually prepared to lose even 10kW of performance, then you really don't want or need a performance vehicle. Obviously, there's no point in doing an engine swap to an SR20DE (HA!) because of the math we spoke of before. So that leaves you with a few options: Drive with a much lighter foot Sell the car and downgrade to a less-thirsty vehicle Rip the motor and drivetrain out and pedal it like Fred Flintstone That's the reality. Personally, I'm not made of money and I'm not happy about the rising fuel costs but I love my car too much to give up anything about it and potentially damage it.

That's surprising.

That's what I heard on the grapevine as well, to the US, if I'm not mistaken.

Talk to UpRev or ECUtek about whether or not they support your vehicle's ECU and for a tuner closest to your area. That's how I do my homework.

...and so many ungrateful buggers wanted to tap into it for nothing. The guy still needed to earn a living for his efforts and experience that gained him that valuable knowledge.

What a spastic installer. That's one guy to avoid in the future. So few appreciate the amount of care required to be taken before, during and after installations. Even fine details like cable pulling lubricant, self-amalgamating tape and glue heatshrink make all the difference in ensuring not only a reliable installation but also a vehicle that doesn't have its existing reliability compromised.

Think about what you unplugged and check those plugs again.

Why not pay a tuner to remove it from the ECU code and while you're at it, get a dyno tune?

Putting two and two together, this only happened after you had an amp installed. The simplest explanation is typically the most likely one. Whoever told you it was the BCM either isn't aware of the events that led up to this problem or he's taking stabs in the dark.

First, forget about your line-level converters. They are a passive device and don't require any power from your vehicle's power circuits. Their job is to reduce the voltage from your speakers down to something friendlier for your amp and no external power is required to make that happen. Not sure what you mean by testing the plate lights wire and you don't say how. If you turn on your parking lights, with your multimeter set up to measure DC voltage, you should be seeing 12V at your plate lights. Now, hopefully you're taking the initial measurement by putting the probes on each of the two terminals that feed the plate lights. If you have nothing there, the next thing to check is if the ground is OK or not. The way to do this is to keep one of the probes on what should be the 12V wire and touch the other probe on a bare metal object nearby, such as a bolt, chassis, reinforcement bar behind the bumper, etc. If you get the 12V reading I described above, that means the light is getting power and the grounding has been buggered up. In which case, you need to trace the ground wire and see where it has been severed or perhaps not even bolted into the body/frame to begin with! I dare say it's going to be something as simple as that. Judging from what you've mentioned so far about the audio install, your installer probably used the bolt that grounds the lights for your amp and didn't put the lights back under that bolt as well. Take a look at where your amp is physically installed - follow its ground wire and see if there's anything floating around near where it's bolted to your car that looks like it should be actually attached. Confirm it with your multimeter by doing a continuity test, to be sure it's actually going to your lights. As for a short circuit, trust me, if you say that your fuses are OK, it's not shorting out anything, otherwise you'd be blowing fuses constantly. This is the opposite of a short circuit, or what we call in the business, an air gap.

Also, get your hands on a multimeter. Visual inspection alone isn't going to solve this.

Wait. You mean the power source for some of your aftermarket audio components is being drawn from the lighting circuit? Nothing should be intercepting your taillights. They should be left alone and a more suitable power source should be obtained, preferably from the head unit's source instead.