Related
I saw this product mentioned on infosync, and it got me thinking that with your growing knowledge of the Phone Edition's inner workings that something like this might be possible on the XDA:
PsiLOC+ miniGPS
(in case you don't want to visit the page)... Basically they are using information about which cell towers are in range to trigger events. They give some nice examples, like having an alarm go off when you get close to your train stop (that way even if the train's delayed and you're asleep you still get the "wake-up call" when you're near your destination.) Or how about having the phone turn the volume down (and switch to vibrate) automatically whenever you're in church or your favorite movie theater.
You could do the XDA a great service just making details of how to get at the relevant information (area ID and cell ID) public, if they aren't already...
CellID and other network info
At the lowest layer, there seem to be no AT commands to get network-related information. And at the TAPI layer (the only one an application can easily get to), this information is, as far as we know, unavailable.
We're working on understanding the modem better, and one of the aims of this endavour is precisely this: getting the CellID for location-based stuff.
Stay tuned (but don't hold your breath)
Surely not?
Surely the only communication with the radio stack isn't via AT commands. Is there no low level api, IO ports, DMA, interrupts etc? How, for example, is the voice stream delivered to the radio stack?
Would it be possible to write a kernel mode driver for these services?
I won't teach you to suck eggs, but maybe a few ideas.
Well... As we see it now all communication with the modem may well be multiplexed in one serial 115.200 bps serial stream. We're working on it...
On my Nokia 6210 I've installed Network-monitor. It shows easily this kind of information.
see this:
http://www.logomanager.co.uk/help/Tools/NetMonMenus.html
localization??? it's already there!
look:
http://www1.o2.ie/products_services/location_services
Re: localization??? it's already there!
kimmie said:
http://www1.o2.ie/products_services/location_services
Click to expand...
Click to collapse
These services are network based: i.e. the network knowing where the phone is. This is different than the phone autonomously figuring out where it is, without help from the network.
Depending on the provider, maps with cellIDs may be available.
serial stream.
XDA Developer, I'd like to be involved in the investigation of the modem. This interests me a great deal.
Not hot on hardware, but I can do some dissassembly and stuff like that.
[email protected]
Disassembly would be a lot easier if you set yourself up with a dev system for ATI Nucleus (which I'm told is the embedded OS for the radio stack).
I have a Nucleus setup here but it's geared toward PowerPC as the target. Anybody know what kind of processor is in the radio module? Is the DSP ("TI HERCROM") what's running Nucleus? According to ATI's site all of the dev tools for that port are maintained by TI. The chip has a JTAG interface, so that would make emulation a possibility, and might help. TI's tools for these things are historically free (they want you to buy chips, after all) but I haven't dug any deeper than this right now.
A 4 meg code space is quite a lot to have to wade through, and it's looks like they're using most of it.
Anyone who upgraded their T-Mobile device using the latest update has easy access to the radio stack ROM image, since it lives in the Windows directory after the CE OS upgrade and never gets deleted. There's a file called rsupgrade.cp64 (3.83 MB) which contains the code being squirted into the radio module's ROM by rsupgrade.exe after the first soft-reset.
Hello XDA Developers!
tl;dr I need either a solid, light OS replacement for Android 2.3 on my Atrix, or I need a video streaming and virtualization app with no lag that works between android devices and either windows or linux desktop.
First I'd like to say how impressed I am with you folks. Massive amounts of work most be done on a regular basis, and so I tip my hat to you in thanks for looking at my potential problem/question.
I've got two devices that I'd like to make some serious software changes to, one of them my Atrix (the other is a Flytouch Tablet ARM11 with Android 2.3, but that's for a different forum). Let me start by saying that I like to think of myself as very technically literate, but when it comes to linux I just don't have nearly as much experience as I do with windows/mac, and it is about to really show.
What I want to do is load a light Linux OS on these devices. Normally, if I was going to install a new windows kernel on a machine I would copy an ISO to a USB thumb drive and make the drive bootable (using the MS program Windows 7 USB/DVD maker), then startup the PC and either through the BIOS or by hitting the proper button during the startup sequence I would ask the PC to boot into the drive and begin the installation.
Questions:
What is the image file type for mobile OS's?
How would one choose the right type of linux OS for an Atrix?
What is the difference between flashing a ROM and installing and OS?
Why is it when I updated my phone recently that it became unrooted?
(and) Is there any way to revert this process to make rooting easier?
Is there any way to capture a video output (like a stream) and broadcast it to these mobile devices so I can avoid changing their software alltogether?
(and) Could I just remotely control another PC from the mobile device, letting it do all the actual computing?
Can I use the Webtop Dock as a monitor for my desktop if I can find the proper HDMI cable to connect it to the HDMI output on my desktop video card?
(and) Can I also connect the Micro USB and use the keyboard/mouse (hooked into my desktop motherboard) on it as well?
(and finally) Can I use my Atrix as a prototype omni-tool by docking it in a docking station, attaching various tools that work with a linux operating system (wide-spectrum ultrasound imaging, temperature monitors, vital monitors, electronic laser saw (USB) (with separate power attachment of course) and extendable, movable USB cameras?) and then strapping it onto my wrist with a cool leather bracer design?
My end-goal is to have all three of these devices on the same network, with the ability to seamlessly access my data between them. For example, if I'm working on a document, I'd like to be able to access the document in a document editing program across all the platforms (imagine google docs with multiple users) however with one MAJOR stipulation: I'll be on a local network with NO INTERNET ACCESS!
Briefly (to better help you understand just what I'm trying to do) I am a freelance archaeologist/deep sea explorer/ROV tinkerer about to do a series of surveys mostly by myself in some VERY remote locations. I'll have a Wi-Fi network to link all of my devices together running out of my boat, but it's only for data sharing between each other, and since Satellite Internet is a joke, I can't think of any way to get data out there, and I've decided to live without it while I'm away.
I have a webtop dock for my Atrix, and the environment developed by Motorola is far too restrictive. I've tried countless fixes to try and get the webtop2SD to work, but I must be doing something wrong (Maybe the latest update screwed it?). I think since I'd like to use some linux applications while on the mobile devices, I would rather install a custom OS for both.
OR (preffered)
Even more simply, I'd like to stream the video feed and remotely control my desktop PC (located on the boat) on the mobile devices, but with yet another stipulation: I can't have FPS lag (I usually get 1-2 FPS with all the virtualization and remote control apps I've tried). This would in some senses be the preferred option, since I really don't want to spend oodles of hours trying to get some program to work in a difficult, restricted environment like these mobile device's current OS's. Is there a good, non-lagging version of desktop virtualization for Android OS?
About that webdock: I can't seem to find a female-to-female micro HDMI cable anywhere on the internet, thought I did find one Micro HDMI extension cable, and bought it promptly. I could buy another, but cut the male ends off and splice the female parts together (**** just got kinky). But if I could, would this work?
Phew that was a lot! Again thanks so much for thinking for me!
I've personally never found any kind of remote desktop software that works without lag, but it might be possible to find some. Someone else might know what to tell you there.
After doing some basic searching, the only collaborative document solution that I've found has been Etherpad Lite. You could set up a desktop or laptop running linux as the server, and all the other devices on your small network could (theoretically) run a browser based client similar (but far less advanced) than Google Docs. This way, everything on your LAN/WLAN could access the application, if it's stout enough to support your needs.
https://github.com/Pita/etherpad-lite
http://en.wikipedia.org/wiki/Collab...Real-time_collaborative_text_editing_software
Everything you're looking for just seems to be limited for Android, I wish you the best of luck.
I have always found Teamviewer great for remote PC control from my Atrix. They have a nice app and free license for home/personal use. I get minimal lag controlling my PC at home when at work, but that's over WiFi. Not very fast and pretty laggy if I am on data with my Atrix.
BTW............I can work on documents, transfer files to and from PC's and laptops, print documents on my wireless printer, etc. across my home network from my Atrix, all routed through a Netgear WNR3500L running stock firmware (dd-wrt actually slowed my network down and reduced WiFi range considerably, so I reverted to stock).
First, there is no "magic" within the lapdock device. It is a nice HDMI screen, a couple crappy input devices on the USB side, and a battery. The standard Moto software does recognise the usb device and do some software magic, but certainly you could use the dock on it's own w/o the phone.
As to completely replacing the /osh webtop OS that Motorola provides, that is challanging.
There are 2 basic ways to open it up though. Go to the developers subforum and look for webtop2sd and "full Debian".
Somebody did post recently with an attempt to fully replace the webtop OS. he was using gentoo, so look for that and you should find it. But I suspect it is early, and likely to be a significant WP.
As to learning all this ****. If you do some Linux developement or heavy hacking (which it kind of sounds like) you should set up a full full blown 'droid dev platform and start playing. It is big and bulky, but you will learn faster that way than just searbhing around.
EDIT: just reread your post that you are light on Linux. if you want to do anything more than just follow along, it might be a good idea to setup something like an Ubuntu and get familiar there. 'Droid is way different looking (it really basterdises things around) but yoiu need to know both if you want to play with webtop hacks.
Thanks all. I'll look around again to see if I can find the threads you mentioned. I've tried Webtop2SD but to no success so far.
Thanks again.
Has anyone had any luck find the source code for the MTCB MCU? I'd like to mod the shutdown timer such that it leaves the device fully operational for the timer duration. Or if anyone has info on the instruction set used, I could perhaps made the mod using assembly or bitbanging.
This may help. It uses an 8051 instruction set
KLD2-v277 "source"
I have been studying and commenting the MCU code for a few months now -- specifically the KLD2-2.77 version. I used darksimpson's mcu decryption tool on the mcu.img file to get the 8051 binary file, then used the D52 disassembler to create "source" code from that.
Studying this code is an ongoing, very slow process but still I have made significant progress.
A few observations (any of which may contain errors!):
1) The original source appears to be written in a higher level language, probably C (not sure which compiler).
2) It appears to communicate with the Android CPU using Serial Port 2 and also an SPI port. There are two I2C buses that the MCU uses to control the various peripheral chips such as the radio, sound processor, and video matrix.
3) Serial data is in the form of packets consisting of a 3 byte preamble followed by one or more bytes of data and ending with a checksum. The specific form of the packet and checksum can vary and is determined by the preamble.
4) Serial packets mostly go from MCU to Android. The MCU can receive packets too, but that capability doesn't seem to be used much, if at all.
5) The primary method of control from Android to MCU seems to be through the SPI port. This consists of 16 bit command words that are handled by a very large CASE statement. Each command word can be followed by additional data (depends on the command) and may also cause the MCU to send data back, either through SPI or more commonly by serial port packets.
6) It appears to me that the designers have nearly maxed out the code space. In other words there is very little room left for additional code, and also evidence that they did things to try to squeeze more code into the available space.
7) Finally -- and not to bash the Chinese designers in any way (tremendous effort contained in this code) -- there are some obvious bugs and also significant room for improvement.
If anyone wants more specific details on what I've learned please PM me. If anyone wants to dive in and study as well, please share what you learn!
One thing that would help me tremendously would be more information on the actual hardware environment. My HU is an 8133 with 480x800 display (specifically a Pumpkin C0235) but it is already installed in my car and I really like it there instead of on a workbench. . So if anyone is in a position to provide hardware details (such as clear photos and schematic diagrams -- either partial or complete, handmade is ok!), sharing them here will help a lot! The code does a lot with MCU I/O pins and without knowing what is connected to those pins it is difficult to really understand their true purpose.
Zipped text file is attached
dhmsjs said:
I have been studying and commenting the MCU code for a few months now -- specifically the KLD2-2.77 version. I used darksimpson's mcu decryption tool on the mcu.img file to get the 8051 binary file, then used the D52 disassembler to create "source" code from that.
Studying this code is an ongoing, very slow process but still I have made significant progress.
A few observations (any of which may contain errors!):
1) The original source appears to be written in a higher level language, probably C (not sure which compiler).
2) It appears to communicate with the Android CPU using Serial Port 2 and also an SPI port. There are two I2C buses that the MCU uses to control the various peripheral chips such as the radio, sound processor, and video matrix.
3) Serial data is in the form of packets consisting of a 3 byte preamble followed by one or more bytes of data and ending with a checksum. The specific form of the packet and checksum can vary and is determined by the preamble.
4) Serial packets mostly go from MCU to Android. The MCU can receive packets too, but that capability doesn't seem to be used much, if at all.
5) The primary method of control from Android to MCU seems to be through the SPI port. This consists of 16 bit command words that are handled by a very large CASE statement. Each command word can be followed by additional data (depends on the command) and may also cause the MCU to send data back, either through SPI or more commonly by serial port packets.
6) It appears to me that the designers have nearly maxed out the code space. In other words there is very little room left for additional code, and also evidence that they did things to try to squeeze more code into the available space.
7) Finally -- and not to bash the Chinese designers in any way (tremendous effort contained in this code) -- there are some obvious bugs and also significant room for improvement.
If anyone wants more specific details on what I've learned please PM me. If anyone wants to dive in and study as well, please share what you learn!
One thing that would help me tremendously would be more information on the actual hardware environment. My HU is an 8133 with 480x800 display (specifically a Pumpkin C0235) but it is already installed in my car and I really like it there instead of on a workbench. . So if anyone is in a position to provide hardware details (such as clear photos and schematic diagrams -- either partial or complete, handmade is ok!), sharing them here will help a lot! The code does a lot with MCU I/O pins and without knowing what is connected to those pins it is difficult to really understand their true purpose.
Zipped text file is attached
Click to expand...
Click to collapse
Great work! Thank you! I'm not profound in this MCU programming but I really believe that it is of great importance to hack that code and mod it in order to squeeze more from these units. A applause you and hope other will join your effort.
Open source implementation could be interesting down the road
Wonder if we could steal any of the tricks from old days of DSS cards and double up code by using lookup tables for some references to make more room for improvement code.
webdude12 said:
Wonder if we could steal any of the tricks from old days of DSS cards and double up code by using lookup tables for some references to make more room for improvement code.
Click to expand...
Click to collapse
There is a lot of "wasted" space (duplicate initialization data for instance) so there's plenty of room available if the software is written efficiently. However modifying what is there, other than small tweeks, is probably not likely to succeed. It looks to me like there is a lot of "band aid" fixes in there and (in my experience anyway) modifying that kind of code often ends up creating more subtle, unforeseen problems than it fixes.
Yes an open-source rewrite will be the best long term solution but that will require a thorough understanding of both the MCU and the Android side of the interface. On the other hand we have potentially a large group of international talent to apply to the task, and no hard deadlines either. It is certainly possible to do.
The MCU processor itself is well known. The peripheral devices are well known (or knowable). So reimplementing those interfaces can be largely independent of the Android-MCU interface. But knowing what the Android CPU expects, and accommodating that for all variants is currently the big unknown for me.
dhmsjs said:
There is a lot of "wasted" space (duplicate initialization data for instance) so there's plenty of room available if the software is written efficiently. However modifying what is there, other than small tweeks, is probably not likely to succeed. It looks to me like there is a lot of "band aid" fixes in there and (in my experience anyway) modifying that kind of code often ends up creating more subtle, unforeseen problems than it fixes.
Yes an open-source rewrite will be the best long term solution but that will require a thorough understanding of both the MCU and the Android side of the interface. On the other hand we have potentially a large group of international talent to apply to the task, and no hard deadlines either. It is certainly possible to do.
The MCU processor itself is well known. The peripheral devices are well known (or knowable). So reimplementing those interfaces can be largely independent of the Android-MCU interface. But knowing what the Android CPU expects, and accommodating that for all variants is currently the big unknown for me.
Click to expand...
Click to collapse
Well that is great to hear. So what I would think that needs to be done first is a complete comment dis-assembly. This has been completely useful in other "hacking" attempts as it allows you to fully understand step by step what the original coders were doing. It also allows for debuggers / emulators to written.
From there it can be determined if it makes sense to re-write sections, re-route code, or completely re-write from scratch providing the same functions.
webdude12 said:
Well that is great to hear. So what I would think that needs to be done first is a complete comment dis-assembly. This has been completely useful in other "hacking" attempts as it allows you to fully understand step by step what the original coders were doing. It also allows for debuggers / emulators to written.
From there it can be determined if it makes sense to re-write sections, re-route code, or completely re-write from scratch providing the same functions.
Click to expand...
Click to collapse
While it is by no means complete, I've worked through enough of this MCU code that I think I have a pretty good high-level understanding of how and what the MCU does. As I said above, what I'm missing now is much of the hardware context (for example which MCU pins connect to what, some of the peripheral chip #s, etc), and also the Android software context -- specifically the code that sends commands through SPI to the MCU. I have looked briefly at some of the Android code (for example MTCManager.apk) but didn't find anything useful there. It seems like the SPI interface is lower level -- perhaps as in a device driver??
This is just a dumb question because you guys would be so far away from modifying mcu code, yet I'm going to ask it.
Could some of the hardware hacks (Using different sound processor for radio, mic mods) be accomplished through software, if you got a good handle on things?
DRidilla said:
This is just a dumb question because you guys would be so far away from modifying mcu code, yet I'm going to ask it.
Could some of the hardware hacks (Using different sound processor for radio, mic mods) be accomplished through software, if you got a good handle on things?
Click to expand...
Click to collapse
Sound processor yes since that is just sending different commands to the sound processor. Mic mod no since that is a hardware mod only (as far as I can see it anyway).
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal? Hypothetically of course.
Would be amazing if down the road those sort of mods could be done on the software side.
Also add "Control radio before android boots" to my dream list.
DRidilla said:
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal? Hypothetically of course.
Would be amazing if down the road those sort of mods could be done on the software side.
Also add "Control radio before android boots" to my dream list.
Click to expand...
Click to collapse
My understanding of the mic hardware interconnection is not good enough to say one way or the other. Probably varies from model to model as well (I don't seem to have a big problem with my external mic).
Control radio before Android boots might be tough since most all of the radio user interface comes through Android anyway. Might be possible to restore previous radio config before Android is up, but that might also not be such a great thing for many users. Not sure I'd want my radio to come up blasting away if I don't also have a way to silence it.
Then again with an open source solution, all you would really need is the will to make it so. I guess we all have our own dream lists, no?
DRidilla said:
Isn't the problem with the mic though that even when you use an external mic, the internal does not shut off? Could you send a message stating that an external mic exists, close off internal?
Click to expand...
Click to collapse
Both microphones are hardwired together. It is not possible to "shut off" one with software. There's also a modification to improve the radio's frequency response by replacing some capacitors. Again, not possible with software.
dhmsjs said:
...
Click to expand...
Click to collapse
Wow, nice work!! I typically have a few KGL units on the bench. Attached are a few images to get you started. These are of the 1024x600px resolution units.
Next time I'm at the office, I'll check out which I/O expansion chip(s) are being used and see if I can identify some of the lines.
Aaaron16 said:
Wow, nice work!! I typically have a few KGL units on the bench. Attached are a few images to get you started. These are of the 1024x600px resolution units.
Next time I'm at the office, I'll check out which I/O expansion chip(s) are being used and see if I can identify some of the lines.
Click to expand...
Click to collapse
Thanks! Really appreciate the photos. Difficult to read the chip #s though.
I know the radio device is similar to a TEF6624 - maybe a TEF6686?
Pretty sure the sound processor is a BD37531 or BD37534.
Not sure what the video matrix switch is -- FMS6502 maybe?
These all connect to the MCU via I2C. Interested in identifying the other devices that connect via I2C too. I can see the I2C addresses they use to communicate with the chips, but I can't generally look up a chip # by its I2C address. The goal is to find the data sheets for each device so that I can understand exactly what the I2C comm is doing. I have data sheets for the devices listed above.
Also as an update: I stated above that the MCU is controlled by Android through an SPI channel. I've been studying this more closely and it is clear that it is not actually SPI. Looks more like a custom 3 wire interface. Uses pins 1, 2 and 3 of the MCU (the IAP15F2K61S2 device).
Pin 1 (P0.5) is data (or ACK) to Android from MCU, driven by MCU
Pin 2 (P0.6) is the clock, which can be driven by either side (open collector with pullup?)
Pin 3 (P0.7) is data (or ACK) to MCU from Android, driven by the Android CPU
It would be helpful to know which pins these connect to on the Android CPU.
Each bit sent must be acknowledged by the receiver before the next bit is clocked out. There is debouncing and timeouts applied to the signals and the transfer is aborted if either fails. Maximum bit rate is around 1MHz I think, and probably slower in actual use. If anyone recognizes this as a particular comm standard, let me know! Otherwise it must be custom for these HUs.
Component Listing (KGL Mainboard)
I noticed the KGL devices use different radio modules even across the same model. I have some units with TEF6624 modules and others with TDA7786 modules. The following are the IC part numbers for the newer 1024x600px KGL main board (date code 2014-07-20):
1. AU6258J61-JES-GR (USB 2.0 Controller)
2. 15L2K61S2 (MCU)
3. FMS6502MTC (Video Sw Matrix)
4. BD37033FV (Sound Processor)
5. GM8283C (? - 10+ traces going to 50-something pin IDC display connector)
6. T132BT (TFT Video Controller)
7. WM8751L (Stereo DAC) - markings rubbed off. See attached photo.
I couldn't find an I/O expander chip on the main board, so I'm guessing the MCU drives most of the I/O lines directly (aside from those handled by their respective audio/video controllers).
Possibly related, I found this document which seems to include many of the same components:
http://p.globalsources.com/IMAGES/PDT/SPEC/216/K1127159216.pdf
MCU Memory Map/Resource Use
So attached below is a document containing a partial memory map, resources used, and I/O pin assignments as I currently understand it from studying the MCU code. The document changes every day as I learn more.
Again this is a KLD2 unit and the V2.77 version of MCU code I'm studying. For Aaaron16 or anyone else who has the ability to explore the hardware of a KLD2 head unit, what will help me a lot in this effort is understanding what the I/O pins connect to. They are listed at the top of the document.
If you explore your hardware, post what you find in this thread and I'll add it to the doc. TIA!
Could Malaysk make modified MCU with redisigned sound processor and sleep mod fo MTCB-MD-V2.67:angel:. I cant post download link
drive.google.com/file/d/0B9-2UI8L0wScel92bUFlaExkWnc/view?usp=sharing
dhmsjs said:
So attached below is a document containing a partial memory map, resources used, and I/O pin assignments as I currently understand it from studying the MCU code. The document changes every day as I learn more.
Again this is a KLD2 unit and the V2.77 version of MCU code I'm studying. For Aaaron16 or anyone else who has the ability to explore the hardware of a KLD2 head unit, what will help me a lot in this effort is understanding what the I/O pins connect to. They are listed at the top of the document.
If you explore your hardware, post what you find in this thread and I'll add it to the doc. TIA!
Click to expand...
Click to collapse
How is this progressing @dhmsjs ?
I am trying to develop an easily reconfigurable soft keyboard or IME for the disabled. My son has CP and only has use of one hand. As such, it is hard for him to work computers at school. The therapist said no one makes a disabled keyboard because there are too many configuration requirements based upon disability. So, I figured using a touchscreen tablet with configurable IME in place of a keyboard would be an "easy" fix.
Plus it gives 7",8", 10" of geography to work with instead of a small portion of the bottom of the screen.
How realistic that is remains to be seen. But if I can get it to work, there is a community out there which will benefit from the ability to make specialized keyboards to meet their specific needs without spending thousands of dollars on specialized, and generally, poor functioning medical interface equipment.
Android tablet and some open source App, $50-100. Smile on a kids face - priceless
Hi guys!
I'm working on a Car PC software and I'm looking for contributors. You can find the project on github: https://github.com/viktorgino/headunit-desktop
More about the project:
HeadUnit Desktop is a based free and open source software that is intended to be run on computers built into cars. This software is currently under active development and lot of the features are experimental. As of now there are three main features:
Media player with a media library and media scanner
Android Auto™ client
DAB radio (integrating welle.io)
Proposed features:
FM radio
CAN bus sniffer with a customizable profile for each car.
Click to expand...
Click to collapse
Some screenshots of the GUI: http://imgur.com/a/pnrpy
And a screen recording: https://www.youtube.com/watch?v=26EYhQuH-Xs
I'm using the C++ and Qt for this project, the front end is QML.
If you are interested in helping with this project, then PM me here, hit me up on Gitter https://gitter.im/headunit-desktop or drop me an email on [email protected]
Pretty excited about this, wish I could help
very interesting project today I try it on my p9 lite. any help files regarding steering wheel controls and buttons?
This is exactly the type of experience that I was looking for, something that allows AA but also maintains AM/FM radio so this can be used as a replacement to the current stereo.
I've been trying to get this installed, but running into some issues in the instructions.
I have the PI all setup, and now following the instructions here:
I'm stuck on this step:
After you’ve installed Qt add the lib folder its installed in to the library load path, the bin folder to your PATH and the lib/pkgconfig folder to the pkg-config path.
I'm not really sure what it's telling me to do here or how to do it.
Can anyone help?
So i got this up and running, this has a lot of potential.
Hopefully development of it can continue soon.
I have a few questions I'm hoping someone can answer.
Questions on current build
1. How is the progress for the FM radio going? Do you know what hardware requirements will be to use AM/FM?
This was the biggest draw to me, to allow me to use this as a replacement to a standard head unit.
2. With Android Audio, when I push the button to go into AA mode. When I plug my phone in, nothing happens? I have AA installed on my phone and it works on other devices.
3. I have a red box at the bottom of the screen that says 'no valid device found use Null device instead.'
What is this trying to tell me? Message is there regardless if phone is plugged in or not.
4. How do you enable the bluetooth so it can connect to the phone contacts etc?
Features I would like to see:
1. Customization navigation bar.
This will be going in an older car, with old fashion lever type heater controls, so I really don't need the climate control button on the screen. Be nice to be able to swap that out for something else.
Also I don't think DAB radio is available in the US, so that would be another one that I would like to remove. Any plans on HD radio for those in the US?
2. Will this support wireless AA at some point?
3. Suppress the Pi Login/Password screen on boot. It seems if you wait about 20 seconds it skips over it automatically. Would be nice in the settings if there was a way to turn that on/off.
So I think this is almost exactly what I have been looking for as a carpc setup, but I had a couple of questions/suggestions. It would be great if you could customize the "action menu" on the right to open other apps that are installed on the system. Like chrisfromwa said above, I have an older car and have no need for the A/C controls, but would I do have an aftermarket fuel injection system and have tuning software currently running on my Raspberry Pi that I would like to be able to open from the "desktop" environment. Also, while I realize that you can do mapping through Android Auto, it would be great if you could launch a navigation system that is installed on the Pi itself like Navit. That way I could have fully offline maps and navigation via a USB GPS dongle and not have to worry about my phone having a signal to have mapping info.
Ultimately I'm really just looking for a "launcher" of sorts that can do FM radio, navigation, and open my tuning app, but that has a nice interface that is easy to use in a car with the 7" touchscreen I have. This is one of the most promising I have seen and would love it if it could launch other apps from the main screen.
i would like to ask a question, and please know that i mean ABSOLUTELY no disrespect by this, but why build one? I ask because there are many head units that are double din, touchscreen, can play darn near every file known to man, have android auto, can interface easily with your car itself, much less the steering wheel controls (cheap interface built with the molex plugs needed for plug-n-play use. Again, i mean no disrespect as i tried doing this a few years back. I gave up because to do it properly, i found that i would have to pretty much rewrite the kernel so that it could idle when necessary and go into full-on ready in seconds vs a full boot every time. Creating an output section thats worth a damn would also prove to be expensive, which is what inexorably led me back to the pioneers, kenwoods etc etc etc of the world. I guess if youre wanting full, unrestricted access to what android has to offer while driving, that would explain it then. But you can also achieve this with some automated processes in your phone to lie to the deck and tell it that youre not moving etc etc. Anyways, just curious of your reasoning for doing this
Youdoofus said:
i would like to ask a question, and please know that i mean ABSOLUTELY no disrespect by this, but why build one? I ask because there are many head units that are double din, touchscreen, can play darn near every file known to man, have android auto, can interface easily with your car itself, much less the steering wheel controls (cheap interface built with the molex plugs needed for plug-n-play use. Again, i mean no disrespect as i tried doing this a few years back. I gave up because to do it properly, i found that i would have to pretty much rewrite the kernel so that it could idle when necessary and go into full-on ready in seconds vs a full boot every time. Creating an output section thats worth a damn would also prove to be expensive, which is what inexorably led me back to the pioneers, kenwoods etc etc etc of the world. I guess if youre wanting full, unrestricted access to what android has to offer while driving, that would explain it then. But you can also achieve this with some automated processes in your phone to lie to the deck and tell it that youre not moving etc etc. Anyways, just curious of your reasoning for doing this
Click to expand...
Click to collapse
I've built my own and after you see so many people having issues with their official head units, it is nice to know that you have the control and aren't at the mercy of a car manufacturer or company. Also, I can use it to play retro games and more. Plus I have a unique dashboard that I have helped design in some ways. Honestly I've tried this project and while it was heading in a good direction there wasn't enough for me to use it as it is currently. I have something else and don't have to pay for like Openauto pro. It's called OpenDash and while it functions as is, it is continuously adding functionality and customizations that you can't find in anything commercial.
talon_dgnr8 said:
I've built my own and after you see so many people having issues with their official head units, it is nice to know that you have the control and aren't at the mercy of a car manufacturer or company. Also, I can use it to play retro games and more. Plus I have a unique dashboard that I have helped design in some ways. Honestly I've tried this project and while it was heading in a good direction there wasn't enough for me to use it as it is currently. I have something else and don't have to pay for like Openauto pro. It's called OpenDash and while it functions as is, it is continuously adding functionality and customizations that you can't find in anything commercial.
Click to expand...
Click to collapse
Right on. What model car?