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)
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.
We know that z ultra have internal Fm transmitter module
But I have a question why sony haven't any app to use this feature?
And I have some app that I fond in other thread butt after install
I get force close
What is the solution???
This is not a development thread at all. Go and post this question in a correct section. Reported.
SpiritTransmit by @mikereidis should work.
Nimadroid said:
We know that z ultra have internal Fm transmitter module
But I have a question why sony haven't any app to use this feature?
And I have some app that I fond in other thread butt after install
I get force close
What is the solution???
Click to expand...
Click to collapse
The thread where you posted in my Spirit2 forum may be the best place to discuss this: http://forum.xda-developers.com/apps/spirit-fm/q-fm-transmitter-app-z-ultra-t3056747
Transmit capability in Sony Qualcomm FM/combo chip devices may be an "accident".
To transmit, the so called "Internal Antenna" pin of the chip must be connected to wired headset as the antenna. Most other Qualcomm chipped devices use the "External Antenna" pin which can only receive.
I'm not sure why Sony used the "Internal Antenna" pin. Hypothetically, the electrical characteristics, like impedance, of that ping may have suited the designers better.
But I lean towards the idea that designers wanted to be able to provide an FM transmit ability, while management did not want the extra costs associated with app creation and testing for this.
T-Mobile did this with a phone once; I have a leaked transmitter app and it works on 2 of my now very old phones. They changed their minds.
If nothing else, you can get a phone to market faster without additional testing, and the smartphone market has been fiercely competitive to get their devices out first.
mikereidis said:
The thread where you posted in my Spirit2 forum may be the best place to discuss this: http://forum.xda-developers.com/apps/spirit-fm/q-fm-transmitter-app-z-ultra-t3056747
Transmit capability in Sony Qualcomm FM/combo chip devices may be an "accident".
To transmit, the so called "Internal Antenna" pin of the chip must be connected to wired headset as the antenna. Most other Qualcomm chipped devices use the "External Antenna" pin which can only receive.
I'm not sure why Sony used the "Internal Antenna" pin. Hypothetically, the electrical characteristics, like impedance, of that ping may have suited the designers better.
But I lean towards the idea that designers wanted to be able to provide an FM transmit ability, while management did not want the extra costs associated with app creation and testing for this.
T-Mobile did this with a phone once; I have a leaked transmitter app and it works on 2 of my now very old phones. They changed their minds.
If nothing else, you can get a phone to market faster without additional testing, and the smartphone market has been fiercely competitive to get their devices out first.
Click to expand...
Click to collapse
Tnx man for your guide <3
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