For the past few days I have been racking my brain and searching multiple forums for the answer(s) and I finally turn to XDA to hopefully help answer.
The thought: I would love to be able to take my DroidX connect it via HDMI to a 7" monitor in my car to have a nice view of the navigation, access to my music and all of the other items that the phone has to offer (which include data connection and accurate GPS). Sure I can buy an android based headunit or build a carPC but why when I have what all of that has to offer in my pocket? Then I got to thinking, to take it a step further, why not use a 7" touchscreen monitor so that I am not just passing video and sound via the HDMI but that the monitor registers touches to the phone.
WebTop is a great middle of the road solution as it would output the HDMI and allow the user to utilize the phone as the mouse touchpad on the screen. Sadly it is only offered for a select few phones. So on to my questions.
1. Did I some how miss a WebTop project being worked on that would do what I am talking about?
2. Am I wrong in thinking that drivers need to be worked out depending on the phone AND which 7" TS was used?
3. Most, if not all, android phones have video out capabilities, so outputting to the screen would be workable, but is there a better way to get the input hurdle worked out.. not a question just an open suggestion box.
Looks like a few more days or looking would have helped. Customgadz has what I need.
so what did you find? I searched for Customgadz, with no results. did you use hdmi mirroring with Android, or does this work with webtop?
Looks like the australian website has a solution to control an android device with a 4 wire external touchscreen using a module.
search for "customgadz remote touch"
Only pre-order now and the website states they start delivering end of januari
Hey Guys
First post here....
I am looking for info on how to set up a Xbox 360 wired (USB) controller on my Motorola Photon 4g. While searching around, i came to the conclusion that i'll need a Kernel that supports USG OTG or USB Host Mode, and, i think in theory,
http://dl.dropbox.com/u/15806590/diagram2.png (also attached)
the above diagram should work. (Courtesy [Guide] USB Gaming on Nexus S Thread )
The problems are
i) my photon is on its way home, so i cant test anything here atleast for the next 3-4 days.
ii) I do not know of a kernel compatible with photon that supports USB Host mode.
iii) in the above diagram, the supply from the USB charger/Adapter goes to both the Phone's USB, as well as the Controller's USB power lines. Would that not be a problem for the phone? i mean why should i be inputting +5V on the power lines of the phone's USB? could it potentially damage the phone? I've played with an iPod's USB, and i am scared.
Can u guys help me in the points above?
P.S the above image was taken from Nexus S USB Gaming Thread on xda forums.
Also, i wont be buying a 99USD HD Docking Station to use the Controller or other Peripherals.
Regards
USB Host is not the issue as the Photon supports USB Host out of the box so any blur based rom should work just fine. Not sure about the CM7 or CM9 family of roms. I remember having to push pretty hard just to get BT mouse support for CM7 on the Evo.
The main issue you will run into is driver support for the controller. The XBox controller gives a device not recognized. PC controllers may be hit or miss but I've tried four or five with no success. Your best options are WIImote w/ classic controller or PS3 controller running over Bluetooth. If cost is a concern then look at off brand WII and PS3 controllers or get one used.
Another thing you will need to consider is game support. You would think a game like Galaxy on Fire 2 would support controllers but it does not. Only a handful of games support controller input directly the rest require custom input mapping and third party apps like "Sixaxis Controller" or "Wiimote Controller", to name a few. You will also find that proper analog mapping is generally limited to pay apps and when using the controller it acts as you input for the phone and not just games.
I guess I could put together a "Photon as game console" guide but am a bit buried in projects right now.
@Lokifish Marz,
does that mean even in USB Host Mode, the Photon 4G would require Device Drivers to be ported for android first and then it'll be able to work with the device? Its a little strange because i have read a lot on these forums, and none pointed out that we needed any drivers, all the posts said was that USB OTG/ USB Host Mode is required. (all the Nexus S gaming threads just ask one to install a particular kernel having USB Host Support, which the Photon already has, and plus an app in market namely USB Host Controller by SzTupY)
Game support ofcourse has been taken in mind.A few Tegra 2 games support Controllers, i mean the ones that actually need a controller (as in it would be better to play them with a controller)
Apart from the drivers (which with all due respect to u, i need to be reassured about, because of what i have read in the posts, plus, on other Android phones, specially the Nexus S, people have reported other Controllers working too) what about the Schematic diagram i made above? would it work fine according to you?
Please don't mind if i said anything offensive in the post, i respect all you are doing for the projects you are working on, especially the photon projects and u must be knowing way better than me
Regards
Plug an XBox360 controller into the USB port on a lapdock or HD Dock. Result, "USB Device not recognized. Supported devices includes USB Storage, keyboards and mice." In short, no drivers. If you see somebody using a usb controller on a phone, pay close attention to the phone that's being used. Example, the GS III is a freak of nature. I'd kill for 500GB external drive support.
Different phones support different things. The original Nexus had a mod that allowed for use of usb graphics cards. The original Evo's hardware supported usb host but drivers were never written for it.
Again, your best and most trouble free option is a bluetooth controller.
If it helps give you an idea as to where I'm coming from. I've been trying to get a phone/tabletdock/lapdock/mediapc/carpc/gameconsole built since about 2003 so I feel your pain.
@Loki
Would a build of CM9 help me getting the controller working? i mean the CM9 beta builds or CM7.2 ? as i already have a Wired controller, i'd want support for that only.
plus what can be some other controllers supported?
Now i want the Photon 4G gaming guide u know....I bet everyone who has a Photon would be glad if u make one.
Regards
psgarcha92 said:
plus what can be some other controllers supported?
Regards
Click to expand...
Click to collapse
I believe he already answered this when he said to use bluetooth controllers. Use a p3 or a wii controller.
@rexxxgg
when i asked him what others are supported, i meant what controllers else than the PS3 bluetooth and the WIImote controller are supported. On IM it was clarified that any Generic/non Sony but -for PS3- controller should be working fine with this phone, and that was what i was precisely asking.
Hello everyone,
I have a Erisin S2046B in my 2001 BMW E46 and found information, that the RK3188 has several external buses which are partly currently not used in the device. Being an electrical engineer and having some projects in my mind which require some sort of external communication to e.g. microcontrollers, I would like to make use of them.
Did anyone go through the effort to use one of these interfaces?
I read in the sound processor thread (http://forum.xda-developers.com/and.../mtc-sound-controlling-bd37xxx-sound-t3234660), that I2C is used there but only limited information on what is done exactly, as it is just a matter of reconnecting the bus lines from the mcu to the rk3188.
I'm not quite sure, if this is the right section, but I would not really consider this "software development". Anyway, if one finds it inappropriate, I would kindly ask a mod to move it to another section
This is great, hopefully it's with guys like yourself tinkering away at these devices we end up with a how new sub-section of interesting mods that can be done for those that like to take stock and improve on it..
Bookmarked for reading as you go through this ... Look forward to some.positive outcomes...
@LC4T, can you be more clear as to what do you plan to achieve? It is no problem to attach another slave (or more) to existing I2C bus, as this bus is a multi-slave in its nature. There's no need to find any interfaces not in use, you are free to use existing, well known one.
As I already mentioned in my posting, I personally plan to connect an external microcontroller and exchange data between the µC and the RK3188. As I don't want to fit the circuitry inside the erisin enclosure, I2C is not the preferable solution.
The principle of I2C and its architecture is known to me, I have already build hardware using I2C But as the existing I2C bus is already connected to at least one slave device, I would be careful with hooking up another one without knowing exactly, what's happening on the bus already. Worst case would be to make the whole existing system unstable. I'd rather use SPI oder UART for my purpose.
In general, this thread should not be seen limited to my intentional use but some sort of collection of information on which buses are present, usable and in use - knowledge base style, so to speak
What's the first solution that comes to your mind when you think of doing something interesting with your I2C?
Some of these units do CANBUS. I'm not sure if there is separate hardware in them or just hookups.
I plan on installing an engine block heater (webasto thermo top c). With the universal wiring kit and control unit, you're only able to set three starting times with a fixed heating time. Additional control units for remote control are quite limited in range and functionality, the "cheap ones" (~200€) only offer "start" and "stop" with the only feedback if the command reached the unit being a blinking led, the ones with the ability to set the starting time from the distance (they claim it works up to 1km depending on the building density) is 350€... There are also GSM units available but also quite expensive and with few functions.
So including a microcontroller would fix all that
If I got it right, the CAN unit is a standalone device, that only decodes relevant data (e.g. gearbox in reverse), so no communication with the android device itself
LC4T said:
I plan on installing an engine block heater (webasto thermo top c). With the universal wiring kit and control unit, you're only able to set three starting times with a fixed heating time. Additional control units for remote control are quite limited in range and functionality, the "cheap ones" (~200€) only offer "start" and "stop" with the only feedback if the command reached the unit being a blinking led, the ones with the ability to set the starting time from the distance (they claim it works up to 1km depending on the building density) is 350€... There are also GSM units available but also quite expensive and with few functions.
So including a microcontroller would fix all that
If I got it right, the CAN unit is a standalone device, that only decodes relevant data (e.g. gearbox in reverse), so no communication with the android device itself
Click to expand...
Click to collapse
I believe there are can bus controllers for that device.
You could take a look at IOIO-OTG boards. it might offer some features.
You can make your own can bus for the devices you want to control and use available can bus adapters.
If you're talking about the webasto heater, yes, there are control units with CAN functionality but they are OEM specific (e.g. VW/Audi, Mercedes, BMW,...) and not universal. Also, adding just another interface is not what I intended to do when there are several of them, mostly unused already available
Again: I don't want to use this thread for my specific problem but as a general thread on using the interfaces already present in the unit
LC4T said:
If you're talking about the webasto heater, yes, there are control units with CAN functionality but they are OEM specific (e.g. VW/Audi, Mercedes, BMW,...) and not universal. Also, adding just another interface is not what I intended to do when there are several of them, mostly unused already available
Again: I don't want to use this thread for my specific problem but as a general thread on using the interfaces already present in the unit
Click to expand...
Click to collapse
Sure. Sure. I like the idea of tapping into the onboard hardware, but it might be good to talk about the limitations and optimal use cases for doing so.
For your case I think you can solve your need without tapping in if the objective is to get it working quickly. If the geek factor is more important then its a moot point.
You could probably tap in using something like this:
sandboxelectronics.com/?product=active-i2c-long-cable-extender-p82b715-module
That might help cut down on noise if you want to run it around the car.
Here's my thoughts.
If you need to control some external DIY device, you need to go with USB ports, which are already available in our devices.
They are just designed to communicate with external world, opposite to I2C or SPI, which are designed for in-system communications only.
Here we have two options:
1. Use native USB communication:
On the headunit side - libusb library which is well-known in Linux world. It might even happen that it is already compiled into the kernel (need to check); otherwise, a libusb.ko module needs to be compiled and loaded.
Nowadays there are many microcontrollers with USB onboard for direct use; and even simpliest MCUs like AVR attiny/atmega can use USB via V-USB library (I've done some just-for-fun projects with it).
2. Use a cheap USB-Serial converter to get a new serial port on a headunit's side. On the MCU side, you'll get a standard UART, which is much simplier than USB for MCU programming.
And returning to your @LC4T idea.
Are you planning to use head unit only as a control panel for your device, so that you only need a big touch screen with a nice UI to set up your externa DIY device, then go off letting that device to work alone? Don't you plan having your head unit always turned on to track time and on/off your heater? Because latter solution is really bad, as our head units are very power hungry.
7floor said:
Here's my thoughts.
If you need to control some external DIY device, you need to go with USB ports, which are already available in our devices.
They are just designed to communicate with external world, opposite to I2C or SPI, which are designed for in-system communications only.
Here we have two options:
1. Use native USB communication:
On the headunit side - libusb library which is well-known in Linux world. It might even happen that it is already compiled into the kernel (need to check); otherwise, a libusb.ko module needs to be compiled and loaded.
Nowadays there are many microcontrollers with USB onboard for direct use; and even simpliest MCUs like AVR attiny/atmega can use USB via V-USB library (I've done some just-for-fun projects with it).
2. Use a cheap USB-Serial converter to get a new serial port on a headunit's side. On the MCU side, you'll get a standard UART, which is much simplier than USB for MCU programming.
Click to expand...
Click to collapse
The IOIO OTG solution gets you here plus there are established libraries etc.
github.com/ytai/ioio/wiki
The OTG version allows it to be powered from the host also. That could make it easy to develop and move around.
github.com/ytai/ioio/wiki/Getting-To-Know-The-IOIO-OTG-Board
pounce said:
The IOIO OTG solution gets you here plus there are established libraries etc.
github.com/ytai/ioio/wiki
The OTG version allows it to be powered from the host also. That could make it easy to develop and move around.
github.com/ytai/ioio/wiki/Getting-To-Know-The-IOIO-OTG-Board
Click to expand...
Click to collapse
From $20 for the board on AliExpress to almost $40 elsewhere? No, thanks These guys want too much for their solution. This is the price of a Raspberry PI, a complete computer.
For that price, I would prefer putting a Raspberry under dashboard, connect with WiFi, for example, and have much more flexibility than gives the IOIO.
As to IOIO - as a prototyping board it might be useful, but not for a well-finished DIY project based on a single cheap MCU with a minimum of components, where total cost of it would be much lower than cost of that board.
It is like using ATmega256-based Arduino boards for the purpose of watching a button and blinking a LED, where the $0.5 worth ATtiny13 is an overhead.
Such a boards are probably good for Hackaton events, where you have to show something working after a few hours of quick-and-dirty work, but not for thoroughly designed DIY project.
Depends on how much you value your time and what an existing product offers you for your solution. Many people aren't as price sensitive. I certainly wasn't suggesting the IOIO as the only solution, but for an open ended or more generic solution to get hardware support external to the head unit is generally fits the bill. Established libs for interacting saves some time. Nice bunch of people put it together and there have been some fun projects.
Like I mentioned before, it might be a good idea to discuss what the objective would be to adding smart hardware in the solution through, I2C, USB, bluetooth, wifi or whatever. I think the OP is looking to discuss the general idea and not super specific solutions that might lead a person to pic a very specific ic and com. Well, I know that was the purpose because the OP has redirected me to the point.
You bring up a good point though. You say you would rather put Pi under the dash. I would also for controlling things. In fact Pi or some duino realtime solution is always going to be better for interacting with an auto. This is especially the case when the purpose might be controlling something that is powered like a motor or something life critical. At this point though we are not talking about android or these head units. You are talking about perhaps the method of communication between two systems. Not really for this forum.
---------- Post added at 01:05 PM ---------- Previous post was at 12:46 PM ----------
I'd like to have more input/output trigger wires for events. We have a backup wire, but I'd like more for other things. An example might be to support a passenger side view camera. Sure, there are ways to hack it in by switching the backup video input, but that's a simple example. Power on a wire sends an event in android on the unit.
Do we have GPIO possibility on any of these units?
CanBus via Uart?
Does anyone know how the CanBus connection works? My MTCB Unit came with an adapter box which turns some messages into external signals (like illumination, reverse), but also seems to forward messages via serial into my Head Unit. At least that's how i guess that the steering wheel buttons are working.
Now, there are some messages that i wish to interpret and send, and also some i would interpret different. My idea was to get some kind of filter (maybe software, maybe a dedicated micro controller) in between the CanBus adapter and the service on my head unit. But right now, i have no idea how to verify my understanding of the setup, since no tty device on the HU seems to directly reflect my button presses. There's one, that pours out something unreadable on key press, but this also does it if i touch the screen, so i guess that's not the CanBus adapter itself.
I suspect that the information in already interpret before it gets into the android system, and only the relevant messages are forwarded, or even pre-processed. I suspect that the only way to get to the signals is to listen on the CanBus adapters RX/TX lines, and maybe finally put an microcontroller in between. If unlucky, the adapter might also filter out messages before i can get them, and i need to access the CanBus directly.
htt p://i.imgur.com/P1QzXta.jpg?1 << CanBus Adapter
I would appreciate any hints on this topic, especially information on the CanBus Adapter.
From what I can see on the PCB and I have read about the can adapter:
The adapter itself only interprets data from either can bus or analog signals and forwards them to the android unit via some sort of serial interface, most probably UART. As you have almost no way to get an inside look into the software running on the microcontroller, I would suggest to design a seperate device, that way you can be 100% sure to get all the messages and filter yourself.
I ordered some can bus adapters to see what i can read. Maybe i will first have a look into the data on the serial line when i finished moving house and had time to unpack my gear
I have a can bus HU, when i listen to the radio or music player, i haven't information on display of my car (CLK MERCEDES). I read the new units have dual can bus and information of radio appears on car display. Ther's a way to modify my HU to dual can bus? I have to change a can bus decoder? My can bus decoder is B200.
Regards
7floor said:
.... There's no need to find any interfaces not in use, you are free to use existing, well known one.
Click to expand...
Click to collapse
Well known interfaces - that's the keyword.
For example I would like to output current FM-frequency, radio station name, song title to the existing (factory) FIS display in a car. Via CAN bus, because the display talks CAN.
Now I would at least have to know which units have CAN capability.
Yes, I could go the USB to RS232 to CAN dasy-chain-adapter route, but I consider that all but a clean solution
Oskar
please delete this thread I just realised that I'm not allowed to post questions here
berzerk428 said:
please delete this thread I just realised that I'm not allowed to post questions here
Click to expand...
Click to collapse
Why so? This forum is even called Android Q&A, Help & Troubleshooting. If it is a question, it is a Q&A (question and answer) and if you need help, it is still part of the forum and if you need troubleshooting it is also part of the forum.
RAZERZDAHACKER said:
Why so? This forum is even called Android Q&A, Help & Troubleshooting. If it is a question, it is a Q&A (question and answer) and if you need help, it is still part of the forum and if you need troubleshooting it is also part of the forum.
Click to expand...
Click to collapse
oh ok, I must've misread it then : ) well, here goes..
I am planning to buy a new DAP which can also work as a DAC, and there are actually quite a few Gadgets out there that combine DAPs and DACs into one as some of you might know.
My question now is, is Android 5 Lollipop upwards able to work with External DACs that use Asynchronous Data Transfer? I am asking this because I have heard that Android 5 had USB Audio Playback integrated, which leads me to the (maybe farfetched) assumption that the newer Android OS should also work with Asynchronous DACs, is that possible?
To be a bit more specific, I am thinking about getting a FiiO x5ii in order to use as a standalone DAP now and again, but I mainly wana use the device as an external DAC for my Note 7. In their official forums FiiO says the FiiO X5ii can not be used as a DAC for Android Smartphones because the Smartphone expects Synchronous Data Transfer whilst the X5ii is designed for Asynchronous Data Transfer. Now I know there's an App called USB Audio Player Pro which bypasses the Android OS and allows Asynchronous DACs like the X5 (specifically mentioned in their compatibility list) to function but I rely on ID3 Tags that only Rocket Player can give me.
I have been doing a lot of research on the internet about this topic but I havent found a clear answer yet that would justify spending 350 bucks on a device that might not work for what I intend it to. The alternative would be to just get an Audioquest Dragonfly (which is not a DAP I'm aware of that) because I have read a lot of good things about them and they are pretty small, but I can imagine having a cable stuck from the bottom of my Note 7 with a USB Stick hanging from it can be a bit awkward and unpractical when I walk around having to grab my phone from my pocket frequently in order to rate songs on my screen or whatever.
Any input or thoughts on this would really be appreciated : )