The Max

Well, since you brought it up, I'll update my post about the Bosch Icon blade I imported from the US. I haven't bothered to reverse the housings. I've left them as is and they're doing great after two years. When the time comes, screw OEM, I'm sticking with Bosch Icon.

Now take a look at your door trim and consider what is sitting halfway across the door. Those will be your possibilities, as well as something internal, like a loose screw left behind, stone that fell into the seal or even perhaps a dislodged electrical connector or harness clamp.

But if we don't know where the scratch is, it could honestly be a number of protrusions.

Pull it apart again so you can see what is lined up with the scratch. You'll then have a better idea of what it was than non-psychic me.

Second one seems to describe the vehicle correctly - import, V35, 3.5L, fuel injection. Why not call them and get it straight from the horse's mouth? That's the easiest and safest approach. If we get it wrong here, you're up shit's creek. If they get it wrong, they need to fix it for you.

You're going to need an oscilloscope, not just a multimeter, as you need to measure the voltage, frequency and duty cycle of the square wave produced by the sensor.

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.