The Subaru BRZ (also produced for Toyota as the GT86) is a snappy sportster but [megahercas6]’s old US version had many navigation and entertainment system features which weren’t useful or wouldn’t work in his native Lithuania. He could have swapped out the built in screen for a large 4G Android tablet/phone, but there’s limited adventure in that. Instead, he went ahead and built his own homemade Navigation system by designing and integrating a whole bunch of hardware modules resulting in one “hack” of an upgrade.
The system is built around a Lenovo 4G phone-tablet running android and supporting GPS, GLONASS as well as the Chinese BeiDou satellite navigation systems. He removed the original daughter board handling the USB OTG connection on the tablet, and replaced it with his version so he could connect it to his external USB board via a flat ribbon cable. The USB board contains a Cypress 4-port USB hub. One port is used as the USB HID device to allow external buttons for system control — Power, Volume Up/Down, Fwd/Rev, Play/Pause, and Phone Answer/Hangup. The second port is used as a regular USB input to allow connecting external devices such as flash drives. The third one goes to a reversing camera while the fourth port goes to a USB DAC.
The USB DAC is another hardware board by itself and also includes a Bluetooth module which integrates his phone’s audio and control functions with the on-board system. There’s also an audio mixer which allows him to use the phone audio without having to miss out on the navigation prompts from the tablet. Both boards also contain several peripheral circuits such as amplifiers and DC power supplies. Audio to the speakers is routed through six LM3886 based power amplifier boards. And the GPS module receives its own special low-noise amplifier board to ensure extremely strong reception at all times. That’s a total of ten boards custom built for this project. He’s also managed to source all the original harness connectors so his system is literally a snap in replacement. The final assembly looks pretty dashing.
For some strange reason, the Lenovo tablet uses 4.35V as the ‘fully charged” value for its LiPo instead of the more common 4.20V, so even with the whole system connected to a hefty 12V lead acid battery from which he’s deriving the 4.20V charging voltage for the tablet, it still complains about “low battery” — and he’s looking for advice on how he can resolve that issue short of blowing up the LiPo by using the higher charge voltage. Besides that, he’s (obviously a kickass) hardware designer and a little bit rusty on the software and programming side of things, for which he’s looking for inputs from the community. His introductory video is almost 30 minutes long, but the shorter demo video after the break shows the system after installation in his car. He’s posted all of his Altium hardware source files on the project page, but until he shares PDF versions, it would be difficult for most of us to look at his work.
Continue reading “Homemade Subaru Head Unit is Hidden Masterpiece”
Whenever I end up with a new vehicle I ultimately end up sticking in a new GPS/Receiver combination for better sound quality and a better GPS.
I am quite at home tearing into a dashboard as I was licensed to install CB radios in my teens as well as being the local go-to guy for 8-track stereo upgrades in the 70’s. I have spent a portion of my life laying upside down in a puddle on the car floor peering up into the mess of wires and brackets trying to keep things from dropping on my face. If you remember my post on my Datsun 280ZXT, I laid in that same position while welding in a clutch pedal bracket while getting very little welding slag on my face. I did make a note that the next time I convert a car from an automatic to a manual to do so while things are still disassembled.
Swapping out a factory radio usually involves choosing whether to hack into the existing factory wiring wire-by-wire, or my preference, getting a cable harness that mates with the factory plug and making an adapter out of it by splicing it to the connector that comes with the new radio.
Usually I still have to hunt down a few signals such as reverse indicator, parking brake indicator, vehicle speed sensor and the like. In my last vehicle the Vehicle Speed Sensor (VSS) wire was supposed to be in the factory harness, but driving experience showed it must not be as the GPS would show me driving 30 feet to the right of the highway. That and the calibration screen on the GPS verified that it was not receiving speed pulses.
Continue reading “Bil Herd Asks OBD “How Fast am I Going?””
Sometimes you use a Raspberry Pi when you really could have gotten by with an Arudino. Sometimes you use an Arduino when maybe an ATtiny45 would have been better. And sometimes, like [Bill]’s motorcycle tail light project, you use exactly the right tool for the job: a 555 timer.
One of the keys of motorcycle safety is visibility. People are often looking for other cars and often “miss” seeing motorcyclists for this reason. Headlight and tail light modulators (circuits that flash your lights continuously) are popular for this reason. Bill decided to roll out his own rather than buy a pre-made tail light flasher so he grabbed a trusty 555 timer and started soldering. His circuit flashes the tail light a specific number of times and then leaves it on (as long as one of the brake levers is depressed) which will definitely help alert other drivers to his presence.
[Bill] mentions that he likes the 555 timer because it’s simple and bulletproof, which is exactly what you’d need on something that will be attached to a motorcycle a be responsible for alerting drivers before they slam into you from behind.
We’d tend to agree with this assessment of the 555; we’ve featured entire 555 circuit contests before. His project also has all of the tools you’ll need to build your own, including the files to have your own PCB made. If you’d like inspiration for ways to improve motorcycle safety in other ways, though, we can suggest a pretty good starting point as well.
Car lifts used to be a tool reserved for professional mechanics. Times are a-changing though. With the advent of reasonably priced four-post hydraulic lifts, more and more shade tree mechanics are joining the five-foot high club. Installing a lift in a home garage creates a few hazards, though. What happens when a family remotely opens the garage door while there is a car up on the lift? Garage door and lifted vehicle will meet – with expensive and/or dangerous results. [Joe Auman] saw this problem coming a mile away. He built the LiftLocker to make sure it never happens to him.
At its core, LiftLocker is a set of switched extension cords. Two cast-aluminum boxes hide the electronics. One box plugs in-line with the lift. The other box plugs in-line with the garage door opener. Each box includes a Sparkfun Redboard Arduino compatible, an RFM22 433 MHz Radio, and a relay. Input comes from a security system magnetic reed-switch. Both boxes are identical in hardware and code.
Operation is simple. One box and reed switch goes on the lift, the other on the garage door. If the lift is going up, its reed switch will open. The lift’s Arduino detects this and commands its RFM22 to send a signal to the other box on the garage door. Upon receiving this signal, the garage door controller will open its relay, disconnecting power to the garage door opener. Communication is two-way, so if the Lift controller doesn’t hear an ACK message from the garage door controller, everything will shut down. Click past the break to see the system in action.
Continue reading “LiftLocker Keeps Your Lift Safe from Attacking Garage Doors”
If you know me at all, you know I’m a car guy. I’m pretty green as far as hardcore wrenching skills go, but I like to tackle problems with my vehicles myself – I like to learn by doing. What follows is the story of how I learned a few hard lessons when my faithful ride died slowly and painfully in my arms over the final months of 2016.
For context, my beast of a machine was a 1992 Daihatsu Feroza. It’s a 4WD with a 1.6 litre fuel injected four-cylinder engine. It had served me faithfully for over a year and was reading around 295,000 kilometers on the odometer. But I was moving house and needed to pull a trailer with all my possessions on an 800 km journey. I didn’t want to put the stress on the car but I didn’t have a whole lot of choice if I wanted to keep my bed and my prized Ricoh photocopier. I did my best to prepare the car, topping up the oil which had gotten perilously low and fitting new tyres. I’d had a hell of a time over the winter aquaplaning all over the place and wasn’t in the mood for a big ugly crash on the highway. Continue reading “Fixing My 4×4: The Battle of the Bent Valves”
The US National Highway Traffic Safety Administration (NHTSA) report on the May 2016 fatal accident in Florida involving a Tesla Model S in Autopilot mode just came out (PDF). The verdict? “the Automatic Emergency Braking (AEB) system did not provide any warning or automated braking for the collision event, and the driver took no braking, steering, or other actions to avoid the collision.” The accident was a result of the driver’s misuse of the technology.
This places no blame on Tesla because the system was simply not designed to handle obstacles travelling at 90 degrees to the car. Because the truck that the Tesla plowed into was sideways to the car, “the target image (side of a tractor trailer) … would not be a “true” target in the EyeQ3 vision system dataset.” Other situations that are outside of the scope of the current state of technology include cut-ins, cut-outs, and crossing path collisions. In short, the Tesla helps prevent rear-end collisions with the car in front of it, but has limited side vision. The driver should have known this.
The NHTSA report concludes that “Advanced Driver Assistance Systems … require the continual and full attention of the driver to monitor the traffic environment and be prepared to take action to avoid crashes.” The report also mentions the recent (post-Florida) additions to Tesla’s Autopilot that help make sure that the driver is in the loop.
The takeaway is that humans are still responsible for their own safety, and that “Autopilot” is more like anti-lock brakes than it is like Skynet. Our favorite footnote, in carefully couched legalese: “NHTSA recognizes that other jurisdictions have raised concerns about Tesla’s use of the name “Autopilot”. This issue is outside the scope of this investigation.” (The banner image is from this German YouTube video where a Tesla rep in the back seat tells the reporter that he can take his hands off the wheel. There may be mixed signals here.)
There are other details that make the report worth reading if, like us, you would like to see some more data about how self-driving cars actually perform on the road. On one hand, Tesla’s Autosteer function seems to have reduced the rate at which their cars got into crashes. On the other, increasing use of the driving assistance functions comes with an increase driver inattention for durations of three seconds or longer.
People simply think that the Autopilot should do more than it actually does. Per the report, this problem of “driver misuse in the context of semi-autonomous vehicles is an emerging issue.” Whether technology will improve fast enough to protect us from ourselves is an open question.
[via Popular Science].
There is a rule of thumb to follow when looking at product announcements at the fringes of the motor industry that probably has something in common with crowdfunding campaigns. If the photographs of the product are all renders rather than real prototypes, walk away. It is said that small volume vehicle production is a space that attracts either crooks or dreamers, and parting with your money to either can be a risky business. So when yet another electric vehicle platform makes its debut it’s always worth looking, but too often the rendered images outnumber anything from the real world and you know you’ll never see one on the road.
It is with interest then that we note an exciting announcement made last week at CES, that the French carmaker Renault are to release an open-source vehicle platform. It is called the POM, and it is based upon their existing Twizy electric buggy platform. If this last point causes you to snort with derision because the Twizy is a tiny and not very fast in-line two-seater with awful weather protection better suited to the French Riviera than an American Interstate, remember that the car itself is not the point of this exercise at this stage. Instead the access to the technology will spark fresh innovation in the open electric vehicle sector that will transfer into better systems for more practical open source vehicles in the future. (Incidentally, we’re told by people who’ve tried the Twizy that it can be something of an unexpected gem to drive. It seems the lowish top speed doesn’t matter in the twisties when you have a low centre of gravity and quite impressive acceleration in a tiny machine.)
Partnered with Renault are OSVehicle, ARM, Pilot Automotive, a manufacturer of automotive accessories, and Sensoria, who will be working on wearable accessories. It’s probable that you won’t see many POMs on the road if you don’t live in a territory that already has the Twizy, but it’s certain you’ll see its technological legacy in other vehicles.
We’ve covered plenty of electric cars in the past here at Hackaday, and this isn’t the first one with an open source angle. We’ve had a very nice Mazda-derived ground-up build, and an astounding home-made hub motor.