Hi chaps,
I'm just wondering which GPS chipset the device uses, and therefore what the spec sheet numbers are for cold start, etc.
jimcpl kindly posted the device's dmesg output in this thread: http://forum.xda-developers.com/showthread.php?p=20531460
but there's no sign of the GPS. Would someone mind posting the dmesg output (or just the tail end) with the GPS up and running so I can see if there's anything in there?
On the Tab 7 the GPS is integrated with the modem, but presumably the Player lacks a modem so it will have the GPS connected somewhere else perhaps more easily accessible from Linux (though one never knows - it might be cheaper to use an existing package even if it's not fully activated)
Thanks
Hi,
I just checked and did another dmesg with the GPS enabled, and also running Navfree, but I don't see anything in the dmesg re. GPS. Do you know what to look for?
Jim
No not really.
I suppose the GPS chip may be directly connected to one of the GPIOs and the firmware and setup is all handled by a userspace library talking to it through a sysfs/dev entry (which are automatically setup by the kernel, without necessarily any indication of what's attached).
Looking at the sysfs might give some clues, but really don't worry too much, I'll do some digging once mine turns up.
Ah, I see that the GPS comms are handled by a library called libgps*.so (can have different suffixes depending on the hw manufacturer), so doing some reverse engineering of this file is probably the next step in order to work out where the chip is attached and what it is.
Interestingly the GPS comms pass through libril as is the case on devices with a modem.
Also vaguely interesting is the fact that "Cell Standby" has used 67% of my battery use (which is ~20% of the battery) overnight. Does anyone know where the UI gets this info from? If it's just summing the CPU time used by some process attached to libril*.so (which would normally handle modem comms, as well as the GPS) that would be fair enough, otherwise it's a conundrum (I guess we don'[t really have a modem in the device which we just can't access....)?
Re chipset, I didn't spot anything in the strings of the various libraries, but I only had a quick look. It is, however, a Broadcom chipset as I can see the function entry points to the static library that Broadcom supply built into libgps*.so.
I must see whether Broadcom supply source (very unlikely) or binaries to the general public and not just large companies....
lardman said:
Interestingly the GPS comms pass through libril as is the case on devices with a modem.
Also vaguely interesting is the fact that "Cell Standby" has used 67% of my battery use (which is ~20% of the battery) overnight. Does anyone know where the UI gets this info from? If it's just summing the CPU time used by some process attached to libril*.so (which would normally handle modem comms, as well as the GPS) that would be fair enough, otherwise it's a conundrum (I guess we don'[t really have a modem in the device which we just can't access....)?
Re chipset, I didn't spot anything in the strings of the various libraries, but I only had a quick look. It is, however, a Broadcom chipset as I can see the function entry points to the static library that Broadcom supply built into libgps*.so.
I must see whether Broadcom supply source (very unlikely) or binaries to the general public and not just large companies....
Click to expand...
Click to collapse
No. Broacom is one of the least open-source friendly companies on the planet.
I was considering the Galaxy Player, but if the GPS is from Broadcom I'm not touching it with a ten foot pole.
Assuming it uses the same version of the GPS as the Galaxy S and Galaxy Tab (no way I can see to recognise it from the strings in the binary, but if anyone has any ideas I'm all ears), then this is also the same chipset as the Nokia N950 uses, and the N950 runs Maemo/Meego which makes things nicer.
Namely there's a kernel driver for the chipset, but this is just a gateway and one requires the firmware and userspace binary to talk to the GPS chip. On the N950 this is in a binary-only daemon.
So not ideal, but at least a kernel driver possibly exists (I've not checked whether it works on the Tab or Player), so it's a step in the right direction; just some reverse engineering to do now (or for my usecase, which is porting Meego to the device, just see if the binary will run)
lardman said:
Assuming it uses the same version of the GPS as the Galaxy S and Galaxy Tab (no way I can see to recognise it from the strings in the binary, but if anyone has any ideas I'm all ears), then this is also the same chipset as the Nokia N950 uses, and the N950 runs Maemo/Meego which makes things nicer.
Namely there's a kernel driver for the chipset, but this is just a gateway and one requires the firmware and userspace binary to talk to the GPS chip. On the N950 this is in a binary-only daemon.
So not ideal, but at least a kernel driver possibly exists (I've not checked whether it works on the Tab or Player), so it's a step in the right direction; just some reverse engineering to do now (or for my usecase, which is porting Meego to the device, just see if the binary will run)
Click to expand...
Click to collapse
It's pretty rare for there to be a kernel driver for anything but reset/power management GPIOs - most of these devices use a serial interface that the GPS libs or userspace daemon talk to.
I can't find any YP-G70 teardowns for more details... Got kinda tempted at BBY today... If it's Broadcom I'm staying away, if it's something else I might go for it.
Entropy512 said:
It's pretty rare for there to be a kernel driver for anything but reset/power management GPIOs - most of these devices use a serial interface that the GPS libs or userspace daemon talk to.
Click to expand...
Click to collapse
Yep, certainly there's still work to do, but knowing how to power the device up is a nice freebie, rather than needing to reverse engineer that too.
Entropy512 said:
I can't find any YP-G70 teardowns for more details... Got kinda tempted at BBY today... If it's Broadcom I'm staying away, if it's something else I might go for it.
Click to expand...
Click to collapse
It's definitely Broadcom I'm afraid, the libgps.so strings contains a load of functions that appear to come from Broadcom (I can't list any right now, it's on a different computer, but can do so this evening if you're interested)
Related
The BCM4330 has a number of listed features that our SGS2s do not appear to have. For instance, the chip in question has listed support for Bluetooth 4.0+HS (so, I assume the Bluetooth low power standard) and FM Transmission/Receive, however all sources state that the SGS2 only supports up to Bluetooth 3.0, does not have Bluetooth high speed (virtually the same as Wifi direct, I'm told, but may not have the same level of uptake) and there are no references to FM transmission.
Without relevant APIs or sources I assume none of these unused features can be utilised. Is it a possibility that Samsung removed some components of the chip to reduce bulk?
What's confused me about this entire situation is that the original Galaxy S and the iPhone4 feature this same chipset, but there's not even a mention of Bluetooth3.0 even though they appear to support it . . . weird. Perhaps I've completely failed to understand the nature of these chipsets, but if I'm not being completely stupid then it'd be nice to explore how one could fiddle with our precious phones to extend its capabilities.
Bump
Sent from my GT-I9100 using XDA Premium App
HazzBazz said:
The BCM4330 has a number of listed features that our SGS2s do not appear to have. For instance, the chip in question has listed support for Bluetooth 4.0+HS (so, I assume the Bluetooth low power standard) and FM Transmission/Receive, however all sources state that the SGS2 only supports up to Bluetooth 3.0, does not have Bluetooth high speed (virtually the same as Wifi direct, I'm told, but may not have the same level of uptake) and there are no references to FM transmission.
Without relevant APIs or sources I assume none of these unused features can be utilised. Is it a possibility that Samsung removed some components of the chip to reduce bulk?
What's confused me about this entire situation is that the original Galaxy S and the iPhone4 feature this same chipset, but there's not even a mention of Bluetooth3.0 even though they appear to support it . . . weird. Perhaps I've completely failed to understand the nature of these chipsets, but if I'm not being completely stupid then it'd be nice to explore how one could fiddle with our precious phones to extend its capabilities.
Click to expand...
Click to collapse
Example:
Back then, at MWC 10, Samsung introduced the Samsung Omnia HD (i8910) which has alot of things AND an FM transmitter, when the device was actually launch, it didn't have the FM transmitter, modders and coders saw & knew that this device have the component, even proved with a secret code and an app they build, but no one has ever managed to get it to work.
So far of being a costumer at Samsung corp. I noticed 2 mistakes that they are repeating:
1. Samsung can't manage to get solid 30fps at 720p devices and 1080p.
2. Samsung rls products with an FM transmitter but they never support it and doing everything that we won't manage to get it work.
The fact that this chip is capable of performing all those tasks does not mean it is capable of doing all those task simultaneously. There might be some hardware challenges/contradictions between the different roles.
For instance, bluetooth 4.0 requires filtering above 3GHz of more than 10dB, while at the same time the chip is capable of Wifi on 5GHz; both are supposed to be on the same antenna so either you can not use the chip for Bluetooth 4.0 AND wifi 5GHz or you have to use some very complicated filter depending on which mode you're using. If they have not supplied this filter inside the chip then it becomes a bit complicated to use both modes.
The FM transceiver could very well be connected to the same internal power amplifiers as wifi but a wifi antenna does not look like an FM antenna.
It is not always possible (actually seldom) to use all the specifications of a chip at the same time with the same hardware setup. (Though often the user won't notice because it is not able to check the specification, like ultra low power and high speed often conflict.)
The features you mention are integrated into the chip itself, so it's not possible to "offload" them. However, they may leave out necessary off-chip components and/or enabling software.
For example, FM is popular in Korea. Many Samsung models targeted to the Korean Market include FM capability. It requires extra hardware though, including a rather primitive looking FM antenna. The corresponding models for other parts of the world leave this out. I presume Samsung doesn't see the popularity of FM in other parts of the world to be enough to make up for the extra cost in the handset.
Drivers and such require work, too. So while the chip may support the capability, they may postpone the software development for various reasons. If the hardware support is fully intact, it might be possible to make something work, but it could require some very deep hacking.
requist's response is interesting and seems like a possibility, although a quick reading of the Broadcom product page seems to suggest they've accounted for mixing capabilities in the chip design. Hard to tell without more detailed info.
Disclaimer: I'm not an official spokesperson. Opinions expressed here are mine and not those of my employer.
requist said:
The fact that this chip is capable of performing all those tasks does not mean it is capable of doing all those task simultaneously. There might be some hardware challenges/contradictions between the different roles.
For instance, bluetooth 4.0 requires filtering above 3GHz of more than 10dB, while at the same time the chip is capable of Wifi on 5GHz; both are supposed to be on the same antenna so either you can not use the chip for Bluetooth 4.0 AND wifi 5GHz or you have to use some very complicated filter depending on which mode you're using. If they have not supplied this filter inside the chip then it becomes a bit complicated to use both modes.
The FM transceiver could very well be connected to the same internal power amplifiers as wifi but a wifi antenna does not look like an FM antenna.
It is not always possible (actually seldom) to use all the specifications of a chip at the same time with the same hardware setup. (Though often the user won't notice because it is not able to check the specification, like ultra low power and high speed often conflict.)
Click to expand...
Click to collapse
time division multiplexing.
Dirty_Jerz said:
time division multiplexing.
Click to expand...
Click to collapse
That does not solve hardware conflicts.
Hi all, new poster here.
Up until recently I wasn't very much interested in acquiring a smartphone. As I'm rather curious, I finally decided to make that technological leap.
Having read about inherent insecurity of such devices, wanted to know what can be done to make them more... ehm, "safe".
Going for android, there seem to be lots of ways hardening the system, but what about baseband RTOS? As I understand, no amount of security
can stop it from controling phone's funcionality. Cryptophone seems to deploy a hardware based firewall on older Samsung phones where
CPU and baseband don't share direct memory, what are the possibilities of doing the same with SOC that shares it? XEN?
Second point - SIM security. Having read Nohl's research on its vulnerability, is it possible to code TurboSIM to reject OTA updates?
If there is no way of separating baseband from CPU, how practical can one be by combining battery powered mifi dongle in one pocket,
and airplane-mode enabled smartphone in the other? Any recommendations?
For starters, I'm considering Moto G - what can I do in order to secure it?
Should I go for newely presented Blackphone instead? Is it all just hype or a real deal?
Perhaps I should wait for Neo900? Quote from their website: "Neo900 won't share system RAM with the modem and system CPU will always have
full control over the microphone signal sent to the modem. You can think of it as a USB dongle connected to the PC, with you in full control
over the drivers, with a virtual LED to show any modem activity."
Apologies for somewhat lenghty post. All help is much appreciated.
bump
I've read that the snapdragon 400 chip natively support GPS.
Is it possible to active it in a custom rom ?
doud1357 said:
I've read that the snapdragon 400 chip natively support GPS.
Is it possible to active it in a custom rom ?
Click to expand...
Click to collapse
No, while the processor chip may have support for GPS, the watch does not have the required sensors needed to get a GPS lock and to feed data to the processor.
If the sensor was actually in the device? Certainly there would be a way to enable it with a custom ROM, but that still dictates that the sensor would need to be built into it.
doud1357 said:
I've read that the snapdragon 400 chip natively support GPS.
Is it possible to active it in a custom rom ?
Click to expand...
Click to collapse
It means it natively has support for a GPS, it doesn't mean it has one embedded within the Snapdragon 400 SoC.
How about a portable gps reciever it's small and you can take with you. I have a nexus 6 and a LG G not GPS when I go for a run I have to take my phone to track my run could there be a way to bluetooth a GPS reciever to work with G watch. Like the way some people use there tablets and GPS same Idea?
What about Wi-Fi?
Many sites I follow are currently suggesting that the smartwatches powered by the Snapdragon 400 might have built in Wi-Fi antennas. The LG G Watch has a Snapdragon 400 APQ8026 but this SoC doesn't seem to have it. Can anyone confirm this?
matteo.gee said:
Many sites I follow are currently suggesting that the smartwatches powered by the Snapdragon 400 might have built in Wi-Fi antennas. The LG G Watch has a Snapdragon 400 APQ8026 but this SoC doesn't seem to have it. Can anyone confirm this?
Click to expand...
Click to collapse
When I looked at the teardown, the radio chipset is solely BT 4.0 :\ no wifi hardware in sight. However while the SoC supports it, without the hardware, that support is useless. Sorry to say
I read the watches have wifi but no antennas. Is it that they actually have the needed hardware but lack the circuitry for an antenna? Maybe a hardmod? Or no?
player911 said:
I read the watches have wifi but no antennas. Is it that they actually have the needed hardware but lack the circuitry for an antenna? Maybe a hardmod? Or no?
Click to expand...
Click to collapse
No. What you are reading is that they have the hardware to SUPPORT a wifi module (Some do actually only lack the antenna, however those will also lack drivers since the OEMs are not likely to make them). Not that there is one built into the SoC. As with the GPS above, even though your SoC supports something, doesn't mean it already has the hardware needed built into it.
@LittleLX: I actually attempted this and attempted to sideload a Bluetooth GPS receiver app to the watch, unfortunately because almost all of them use the Android ActionBar, it refused to start up. Android Wear is restricting applications to the swipe to dismiss action and forbidding the actionbar on versions of Android with Swipe to Dismiss on. That said, there is definitely room for this type of application to be developed for Android Wear, I had sideloaded CF.Lumen and ES File Manager, and while CF.Lumen doesn't open because of it's ActionBar, I had put together a tasker app factory app to attempt to play around and trigger (I had manually installed the CF.Lumen driver) it, it did show that it would work if I had been able to set up location services inside the app (choose the location for the automatic dimming..)
So Android Wear has potential to be a very powerful and extensible platform, developers just aren't interested in it yet it seems. We as a people seem to be stuck looking at a smartwatch as a watch rather than a wrist computer.
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
Update 27/07 - did not improve the radio enough to recommend this modification/change.
Apparently the TEF6686 module has better performance than the TDA7786 - e.g. 7786 poor sensitivity, selectivity, multipath issues etc. My JY TDA7768 is terrible, even with an RF amp, so to find out if the TEF is any better, thought I would try and investigated swapping tuner modules. Reviewing the GS board I have as a spare part against my JY, I identified the modules are pin-for-pin compatible.
Sucessfully swapped the Radio module from a donor GS board containing a TEF6686 Module into my JY board originally containing a TDA7786. The GS board was quite difficult to unsolder the module, perhaps due to leadfree solder, fortunately the JY board was easy, the desolder wick readily desoldering the module.
As for results, I have bench tested and RDS, tuning, audio etc is OK, I am yet to test in the vehicle. Will update this thread with results.
See attached images. Note that the JY case had additional mounts that over time might short out against the non-ground PCB tracks, resulting in complete failure of the unit!
Welcoming any questions.
Did the reception really improved?? And RDS AF fuction is working well with malaysyk V3 firmware?
also interested in this outcome
Sent from my Pixel XL using Tapatalk
Hi,
The tef6686 appears marginally better, is more sensitive and appears to handle multipath better. Im not sure if I would call it out as a worthy upgrade just yet - need more time.
wonder if it can be bought on its own.. seems like just the chip itself which is surfaced mounted on the riser card as pictured above.. so this would prove difficult to install
Sent from my Pixel XL using Tapatalk
stinger4321 said:
wonder if it can be bought on its own.. seems like just the chip itself which is surfaced mounted on the riser card as pictured above.. so this would prove difficult to install
k
Click to expand...
Click to collapse
Ive seen a suitable module available on aliexpress that would need some modification to swap a couple of pins. That is the TEF6686-TDQ-230V-186 (10 pin) - a whole $6 bucks US.
http://s.aliexpress.com/QBfay
Next week this module come to me , so in the next weekend I have time to swap.
https://www.aliexpress.com/store/pr...32809641460.html?spm=2114.12010612.0.0.y1ZYeS
cupi1234 said:
Next week this module come to me , so in the next weekend I have time to swap.
https://www.aliexpress.com/store/pr...32809641460.html?spm=2114.12010612.0.0.y1ZYeS
Click to expand...
Click to collapse
That's great, don't forget these are not pin-pin identical and will have to figure out swapping pins. Search for the manufacturer PDF and check against the mtcd schematic. I'll upload the module PDF later today.
Hi, final thoughts - the upgrade in my experience was marginally better - not worth it!
marchnz said:
Hi, final thoughts - the upgrade in my experience was marginally better - not worth it!
Click to expand...
Click to collapse
could be something else in the implementation, not just the chip itself.
i have 2 boxes, one with 7786, the other with 6686 and the difference in reception is worlds apart. I mean even with the powered antenna not connected to 12V, i had no hiss on any station received.
7786 with powered antenna is just fine, don't get me wrong, but 6686 is better.
zerozoneice said:
could be something else in the implementation, not just the chip itself.
i have 2 boxes, one with 7786, the other with 6686 and the difference in reception is worlds apart. I mean even with the powered antenna not connected to 12V, i had no hiss on any station received.
7786 with powered antenna is just fine, don't get me wrong, but 6686 is better.
Click to expand...
Click to collapse
I had thought about that but there's no difference in implementation I can see after comparing from schematic. Perhaps I had a 'good' 7786.
- MCU is latest HA
- Both modules are digitally controlled by MCU/i2c bus.
- same supply
- latest HA android 6.
There's really not much to it, 5volts, antenna connection, i2c comms and audio out. I get multipath noise/crackles from stations between 99 and 102mhz. Same between both tda and TEF.
Can you clarify what you mean by 'better'.
Hi!
Maybe there are some differences in the Radio Software used in the different HU. The Chip is controlled by I2C and it seems to be possible to activate or change some behavior of FM Reception through some commands.
Is it maybe possible to extract the radio Software from the good HU so we can try it out on different devices (with TEF 6686).
It would be really nice if it would be possible to control some of the possible configuration of the chip manually...
Stephan
netguru said:
Hi!
Maybe there are some differences in the Radio Software used in the different HU. The Chip is controlled by I2C and it seems to be possible to activate or change some behavior of FM Reception through some commands.
Is it maybe possible to extract the radio Software from the good HU so we can try it out on different devices (with TEF 6686).
It would be really nice if it would be possible to control some of the possible configuration of the chip manually...
Stephan
Click to expand...
Click to collapse
No differences in android and same MCU, MCU controls radio module via I2c. The "upgrade " has no discernable difference.
Any more details? I need a more sensitive tuner. I have a full power mast but my car is all SMC so the radio needs all the help it can get.
Sent from my iPhone using Tapatalk
-=Jeff=- said:
Any more details? I need a more sensitive tuner. I have a full power mast but my car is all SMC so the radio needs all the help it can get.
Click to expand...
Click to collapse
Sure - there are two different tuner modules and neither of them are 'better'. I suspect its hit and miss in the production of either modules.
If you have a proper external antenna, which is properly connected, there's nothing you can do apart from using internet streams or DAB if available for best quality.
thanks, do you know if these unit have the 7786 or the 7786M IC?
netguru said:
Hi!
Maybe there are some differences in the Radio Software used in the different HU. The Chip is controlled by I2C and it seems to be possible to activate or change some behavior of FM Reception through some commands.
Is it maybe possible to extract the radio Software from the good HU so we can try it out on different devices (with TEF 6686).
It would be really nice if it would be possible to control some of the possible configuration of the chip manually...
Stephan
Click to expand...
Click to collapse
marchnz said:
No differences in android and same MCU, MCU controls radio module via I2c. The "upgrade " has no discernable difference.
Click to expand...
Click to collapse
Are you sure ? Cos on MTCB/C units the AF doesnt work and the PTY is plain wrong (I have an MTCD unit now but I havent tested the radio yet, its still on the bench), but someone (deffo Italian I remember that) made some changes and got PTY to work correctly and I thought he did it by modding the app ratehr than anything on the MCU side. Sadly I cant remember exactly what thread it was in, or who it was.
-=Jeff=- said:
thanks, do you know if these unit have the 7786 or the 7786M IC?
Click to expand...
Click to collapse
Unfortunately the only way to tell on MTCD untis is to open it up, unlike the MTCB/C units where you can select the tuner type in facory settings, which is strange cos MTCD MCUs are much more powerful 32 but compared to MTCB/C's 8bit . . .
. . . or maybe there is a way ? - @marchnz's dmesg output mentions "6686" in the first post.
Hi,
Can someone help with radio module pins schematic for XD-6686AF-0. This is same radio module that @marchnz has swaped. I am forced to change main that is not pin to pin identical to TEF6686-TDQ-230V-86-TDQ-230V-86-R that I have from aliexpress.
Thank you
P.S.
https://forum.xda-developers.com/android-auto/mtcd-discussion-questions-development/mtcd-schematic-t3637816
I guess this is what I am looking for.
Leaving a tip for everyone looking for this schematic.
Thanks to @marchnz
skf123 said:
Hi,
Can someone help with radio module pins schematic for XD-6686AF-0. This is same radio module that @marchnz has swaped. I am forced to change main that is not pin to pin identical to TEF6686-TDQ-230V-86-TDQ-230V-86-R that I have from aliexpress.
Thank you
Click to expand...
Click to collapse
Do you have a datasheet? Shouldnt be too hard to match up against schematic.
marchnz said:
Do you have a datasheet? Shouldnt be too hard to match up against schematic.
Click to expand...
Click to collapse
Radio module that comes from aliexpress has description on every pin.
Can be seen on the picture that is provided in this link.
I can make a new photo if someone needs clear image of this module.