Stuff like this is why I muse about building a RPi based head unit. The biggest thing for me is I enjoy HD Radio (LA has a great 80s Rock HD2 station) but there's no chip readily available (for hobbyists) I'm aware of that implements the HD Radio spec (AM/FM being A-OK). All I really want in a head unit is:
- AM/FM/HD Radio
- iPod/iPhone compatibility with preferences for how and when it will turn itself on
- Simple to use Nav with easily, cheaply (or free), upgraded maps
- No bloat or bizarre features I'll never need
- Backup (and perhaps curb clearance) camera support
- A touch UI designed for actual use in a car that's moving i.e. big pancake buttons and nobs for tactile control
- A quality Amp with actual EQ settings
- Carplay and/or Native App support of some kind
- An oscillator/vibrator in the screen to give some tactile feedback (road quality allowing)
A RPi with a peripheral/support board running some combination of XBMC and an App switcher would probably handle that.
Most of these features, save for the UI and Bloat-less experience are available on the AVIC and other aftermarket head units... Just not always in the same unit (HD radio seems to be either not listed on spec sheets or not as common as I'd hope). I have MyLink in my Camaro, which mostly works fine, save for lacking HD radio and its tendency to default to XM when I unplug my phone. My car didn't come with a backup camera which means I may or may not need to get the radio reprogrammed (Via a USB cable and GM software) to use one ($200 or so depending on the dealer). A lot of the on screen controls aren't available via physical buttons and the buttons are too small to blindly tap at.
Stuff like that is just frustrating since a lot of other consumer electronics (i.e. Phones) have improved so much UI/UX wise. A lot of open source projects aren't known for good UI/UX but I feel like an OSS solution would go a long way to fixing these issues.
You should check OpenStreetMap.org's quality in your area. (iPhones use it, last I heard.) Los Angeles should be pretty good.
The other option, Google Maps over a cell data connection, might be workable but that's competing with just getting an Android tablet and mounting it on the dash with cables to connect it to your existing audio head unit.
HD Radio in an RPi-accessible format is an interesting one I hadn't thought of before. A quick google gives me a few decent hits:
I've found these chips but a lot (all?) of them require a large purchase order and an NDA. I presume because of the encoding or something silly. I believe the HD Radio tech is obnoxiously patent encumbered. Meanwhile AM/FM chips are dirt cheap. C'est la vie.
The problem is the complete lack of front end filtering. They're easily overpowered by a strong station. You're better off building you own with real filters.
That would work, but it's more elegant to dig into the bootloader. As long as you don't have the pw you'd have to repeat this approach. Suppose you manage to put your own system on the SD, the bootloader would still have the lock.
Edit, even simpler: hook up a logic analyser and the password should be among the first captures.
(For those that have no idea without reading the article, the AVICs are a series of car stereo made by Pioneer.)
Granted, most of this is probably driven by "can I do it?", but that's a lot of effort and expense to get rid of a nag screen. Though I find the nag screen annoying enough on my AVIC-6000 to have read to the end of the article...only to find out that he hasn't cracked that nut yet. :-(
But if you have one of the NEX series, you can watch DVDs as you drive down the road: http://avic411.com/index.php?/topic/38589-official-avic-nex-.... For diagnostic purposes only, of course. Or, if you're like me, you just wanted to get rid of the "OMG, the parking brake wire isn't hooked up correctly!" message because you just grounded that wire instead of actually connecting it to the parking brake switch. Now if I could just get it to stop whining about the speed sensor wire.
He mentions Pioneer violated the GPL by not making the source code available. Is that the case with selling embedded hardware? I thought that rule applies only if you are selling the software.
For example, many wireless access points use Linux, but you never see the source for those.
This seems to be Pioneer's GPL source code site: http://www.oss-pioneer.com/car/navi/files/ . I don't see AVIC-5000NEX there, but a variety of other AVIC devices are listed.
The GPL mandates the code be made freely available, it doesn't say how. It may require a written request sent to corporate headquarters. I don't think there is enough info in the post to say they are ignoring the license terms, but they certainly aren't living up to its spirit.
I'm pretty sure there must be an offer of source and the license needs to be somewhere. Usually for things like router manufacturers you'll see a notice in the manual somewhere and a link on the support site.
The GPL'd portions of software must be made available. They have been distributed, therefore source must be given under the terms of the license.
The GPL doesn't necessarily affect everything on the box, I'm not 100% clear on what happens if you sell a system using (for instance) GNU/Linux and put proprietary software on top of it, with regard to the source of the proprietary software. But you would have to make linux available.
The proprietary software is unaffected by the GPL so long common sense (ie in layman terms) tells you that they are a separate program with the GNU/Linux parts.
The problems comes when people want to stretch the definition of separate programs. In those cases, contacting lawyers and seeking out the authors intent seems to be the only viable option (for example, the case with Linux modules).
That was what I thought was the case, but wasn't 100%.
I worked for some folks who were making an ubuntu based network-monitoring appliance a couple of years ago, one day they freaked out about the GPL and decided (absent any legal advice) to make us port the project to NetBSD. They refused to consult a lawyer because it would be too expensive apparently, but would have been far cheaper than all the developer time... I suppose at least I got to add NetBSD porting to my cv :)
The news section mentions many embedded devices, and the court cases give you some idea about what you are allowed to do with the code for those devices.
Talking of "surprising internal SD cards" - the Kobo eReaders use an internal MicroSD card. This makes hacking and tinkering really easy.
They bizarre and frustrating Kobo set up procedure (connect the Kobo to a computer; connect the computer and the Kobo to the Internet; download software update for the Kobo and software for the PC; set up accounts) can be avoided with a simple bit of SQL. This and other tinkering is mentioned here: http://uscoffings.net/clc/tech/embedded/kobo-touch/
- AM/FM/HD Radio
- iPod/iPhone compatibility with preferences for how and when it will turn itself on
- Simple to use Nav with easily, cheaply (or free), upgraded maps
- No bloat or bizarre features I'll never need
- Backup (and perhaps curb clearance) camera support
- A touch UI designed for actual use in a car that's moving i.e. big pancake buttons and nobs for tactile control
- A quality Amp with actual EQ settings
- Carplay and/or Native App support of some kind
- An oscillator/vibrator in the screen to give some tactile feedback (road quality allowing)
A RPi with a peripheral/support board running some combination of XBMC and an App switcher would probably handle that.
Most of these features, save for the UI and Bloat-less experience are available on the AVIC and other aftermarket head units... Just not always in the same unit (HD radio seems to be either not listed on spec sheets or not as common as I'd hope). I have MyLink in my Camaro, which mostly works fine, save for lacking HD radio and its tendency to default to XM when I unplug my phone. My car didn't come with a backup camera which means I may or may not need to get the radio reprogrammed (Via a USB cable and GM software) to use one ($200 or so depending on the dealer). A lot of the on screen controls aren't available via physical buttons and the buttons are too small to blindly tap at.
Stuff like that is just frustrating since a lot of other consumer electronics (i.e. Phones) have improved so much UI/UX wise. A lot of open source projects aren't known for good UI/UX but I feel like an OSS solution would go a long way to fixing these issues.