yashsingh1/xdaforums huggingface dataset:
[G Tablet General] rajeevvp:
Try replacing only the com.android.location.provider.jar so that you can at least boot.

No. This has nothing to do with the kernel.

Do an echo -n 1 > /sys/devices/platform/gps_control/enable. Then, do a hexdump -C /dev/ttyHS3. Only if you don't get any data from ttyHS3 will it be a kernel problem. The kernel's job is just to provide data to that port and to enable and disable GPS when asked to do so.

That should not enable or disable the GPS. Doing so would be a drain on the battery--for example: the user can enable it and then not use Maps app for days on end, right? No--the GPS enable/disable should be application controlled--ie. enabling Maps or a similar app should enable it, and backgrounding or exiting the app should disable it. We've already seen that this is the case with Froyo.

My guess is that we have the right libgps.so file with the NI Adam version, but, we don't yet have the right Java apps or libs that load and call it. Try copying over NI Adam's /system/lib/hw/gps*.so and /system/lib/hw/sensors*.so too.

And, it's a good idea to stay with the nightly--both the NI beta and the CM nightly are 2.3.4.

One thing to keep in mind: If you use any of NI Adam's Java files, make sure you rename the NI Adam libgps.so back to libadam_gps.so because that's how the Java apps/libs will expect it to be named.
[G Tablet General] fosser2:
I have done that also. It boots but it does not work. I did notice that when just that one file is switched over, on boot the tablet says something about gapps has force closed.

I will post the rest of the results in just a bit.

EDIT: after doing hexdump yet again :p there is data read from the chip...now if only we can get it to interface w/ the software
[G Tablet General] rajeevvp:
Stop press! Copy the NI Adam's /system/lib/libandroid_servers.so file into CM's /system/lib/--It looks tasty:

nm -D -g ni-adam/system/lib/libandroid_servers.so | fgrep -i gps | c++filt
0000ebc4 D android::sGpsCallbacks
0000ebf0 D android::sAGpsCallbacks
0000ebf8 D android::sGpsNiCallbacks
0000ec00 D android::sAGpsRilCallbacks
0000ebe8 D android::sGpsXtraCallbacks
0000b671 T android::register_android_server_location_GpsLocationProvider(_JNIEnv*)

Also, edit /system/build.prop and add this line to it somewhere (not really necessary, as I can see from libadam_gps.so that if a device name is not supplied, /dev/ttyHS3 is used by default. Still, it doesn't hurt to add it):

ro.kernel.android.gps=ttyHS3

Another jar file you might try copying over: /system/lib/services.jar. Again, boot loops may result from this one.

EDIT: I just had a horrible thought--are these individual jar files signed? If they are, they'll have to be installed somehow and not just copied over.
[G Tablet General] fosser2:
haha ok will do, I'll report back in just a few.

EDIT: Crap, changing out that file just makes the tablet freeze at the "Android" screen before the ROM starts to load...

[offtopic]what program are you using to view the .so files?[/offtopic]

Well I sure hope that they are not...
[G Tablet General] rajeevvp:
strings filename.so | fgrep -i gps

and

the "nm -D -g filename.so | fgrep -i gps" from above.

"fgrep -ir gps directory-name" for recursive searches.
[G Tablet General] fosser2:
So do you think those files are signed? And what else could I try right now. I feel like we're overlooking something ̶s̶m̶a̶l̶l̶.

haha edited ;)
[G Tablet General] rajeevvp:
Rajeev throws up his hands, shrugs his shoulders, and is heard muttering, darkly, "Java-schmava--all these new fangled languages are the same. Interfaces piled upon interfaces! Only Cthulhu knows!"

Something small :mad:.!?!? At this rate, by the time we're done, we'll have replaced every file in that CM nightly. How can you call that small, young Fosser?!

Seriously though, it's time to do it the old fashioned way--intelligently, by figuring out how each part works. I'll get back to the reading and the test programs I was trying out.
[G Tablet General] fosser2:
Haha thanks for that. Is there any way that we could take the "code" from before:

nm -D -g ni-adam/system/lib/libandroid_servers.so | fgrep -i gps | c++filt
0000ebc4 D android::sGpsCallbacks
0000ebf0 D android::sAGpsCallbacks
0000ebf8 D android::sGpsNiCallbacks
0000ec00 D android::sAGpsRilCallbacks
0000ebe8 D android::sGpsXtraCallbacks
0000b671 T android::register_android_server_location_GpsLocationProvider(_JNIEnv*)

I looked into the CM Nightly file (libandroid_servers.so) and found the same thing:

nm -D -g libandroid_servers.so | fgrep -i gps | c++filt
0000ebc4 D android::sGpsCallbacks
0000ebf0 D android::sAGpsCallbacks
0000ebf8 D android::sGpsNiCallbacks
0000ec00 D android::sAGpsRilCallbacks
0000ebe8 D android::sGpsXtraCallbacks
0000b4e5 T android::register_android_server_location_GpsLocationProvider(_JNIEnv*)

Yes you are right...we have attempted copying about every file possible. I will keep pressing away as soon as I can get my tablet back up and running. For some reason it totally crapped out on me. I am repartitioning sd card as we speak. Ok got it back up and running.

EDIT: Here are the differences between libadam_gps.so and CM (Nightly) libgps.so

libadam_gps.so

gps_get_hardware_interface
libgps.so
gps_set_position_mode
gps_set_fix_frequency
gps_state_start
gps_start
gps_state_stop
gps_stop
gps fix frquency set to %d secs
gps.power_on
/sys/devices/platform/gps_control/enable
no gps power interface name using default gps_control
gps power state = %c
could not open gps power interfcae: %s
gps sent to device: %s
gps dev start initiated
gps dev stop initiated
gps thread running
gps status callback: 0x%x
gps thread received %d events
gps control fd event
gps thread quitting on demand
gps thread starting location_cb=%p
could not create gps timer thread: %s
gps thread stopping
gps fd event end
gps entered timer thread
gps timer exp
gps fix cb: 0x%x
gps sv status callback
gps timer thread destroyed
gps send quit command
gps waiting for command thread to stop
gps deinit complete
gps semaphore initialization failed! errno = %d
ro.kernel.android.gps
no kernel-provided gps device name using ttyHS3
gps serial device name too long: '%s'
could not open gps serial device %s: %s
gps will read from %s
could not create gps thread: %s
gps state initialized

libgps.so

gps_get_hardware_interface
libgps.so
libGPS
gps_get_interface
gps_get_extension() name=%s
gps_set_position_mode
gps_set_position_mode with AGPS mode(%d) which we donot support
gps_delete_aiding_data
gps_inject_location
gps_inject_time
open_gps_fd failed: errno=%d(%s)
gps_control
gps_state_thread start to run...
GPS thread get CMD_QUIT
GPS thread get CMD_START
GPS thread get CMD_STOP
epoll return gps_fd
gps_cleanup
gps_state_start
gps_start
gps_state_stop
gps_stop
gps_state_init IN
Cannot open gps_fd
/sys/devices/platform/gps_control/enable
gps_state_init OUT
gps_state_init FAILED
gps_init

I'm not really sure about a lot of this but the NI one just looks like it is more advanced.

I also found this post, it was an interesting read. http://groups.google.com/group/andr...read/thread/c67550378823a0d4/a0b63c0a6ff794bd
[G Tablet General] rajeevvp:
You're right. The files look roughly the same--they're even the same size: 61540 bytes. If they weren't, I would've said that the CM7 file contained just stub functions and not the implemented versions. But, even if they're the same size, substituting that NI Adam file for the CM 7 file messes with the system for some reason...

And, that's the our problem in a nutshell--we don't have an exact picture of what calls what and how. The interfaces between the various pieces are poorly documented and those interfaces change quite a bit between the various Android versions.

I've been slowly working my way back from libgps.so by writing small test programs to call each layer according to the specs that I've found, and I hadn't yet made my way back to libandroid_servers.so.

There is an obvious shortcut here: The source for herbert1's BlueGPS4Droid is available. It should not be too hard to make it use /dev/ttyHS3 (onboard GPS) instead of /dev/ttyHS2 (bluetooth GPS) for its NMEA data, and also make it toggle the /sys/devices/platform/gps_control/enable file when its running/not running. I'd hoped to avoid doing this, but, I can try to put my poor Java skill to use. The main problem with this approach I've already mentioned in one of my previous posts: you'll have 2 programs (well, maybe not on Gingerbread ;)) reading from the same device at once with unpredictable consequences.

Yeah, I noticed that. The libadam_gps.so is also 4k larger than the CM 7 version.

We're sidestepping the issues in that post since we're using NI Adam's working libadam_gps.so file. No--we'll have to look elsewhere.
[G Tablet General] fosser2:
It would be amazing if herbert1 could help us understand the connection between the files. I did not realize he was the developer of bluegps.
[G Tablet General] fosser2:
Ok back to the hardware for a bit. Today I got another G-tablet and I installed the GPS chip into this one also. (yes I plan on selling one with pre-installed gps, but thats for a later date) When installing U22 3.3vdc Bkpbatt Reg - MCP1700T1802ETTCT-ND again the tablet did not turn on. So that is now two different chips and two different tablets. I'm banking on that I did not get a faulty chip 2 times in a row. That says that this chip at location U22 does not work! Although data sheets say otherwise, just jumper this pin and it will work fine. Just thought I should share this bit of info.

EDIT: Prolly shouldn't put this here, but here's the marketplace link http://xdaforums.com/showthread.php?t=1121551
[G Tablet General] mbamberg:
Fosser2,Rajeevvp,

Being the brave adventurer, I have purchased and installed the parts from your "upgrade" into my G Tablet. Here are my results:

At the time I installed the parts, my ROM was BoS 4.1 and everything was working fine. After installing the parts, the tablet booted fine into Bos and I was elated (until I re-read your posting that Bos was not able to access the GPS).

Ok, I can do this, use Titanium to back up my apps and settings. Recover to BC and Bob's-your-uncle we're ready to rock.

Start the app restore with Titanium and part way through, the screen kind of "twinkles" some multi-colored pixels and starts alternating black screen and black-and-white horizontal stripes. This can't be good and I hold down the power button to shut it off.

Wait a moment, then power on, half-way through the boot, the screen "twinkles" again. Shut it down.

Try a recovery, nothing, no CWM, no standard recovery. I'm now introduced to NVflash, as quoted many times on the internet, "it can fix ANYTHING".

Except my unit.

I have tried every suggestion I can find on both the XDA and slatedroid forums. Tried the recovery to CWM, tried the recovery to 1.1 bootloader. APX mode and I are good buddies now, much to my dismay.

Still no bootable unit.

I have tried moving the USB cable to different ports on my system, disconnected the battery and power, waited hours, re-powered, several times.

Each time the recovery seemed to proceed further but hang at the bootloader initialization, or a partition format or image copy. I have gotten completely through the whole NVflash recovery batch file, once. The system rebooted, screen twinkled, and black-screened.

I pulled the unit apart, brushed it clean with a clean flux brush, blasted it with an air-can, reinspected all my solder joints (I have been soldering since 1962, yes I was a child then) none cold or missing.

I'm at my wits end. Open for all suggestions. Sorry for the long post but I wanted to insure you all knew the details and I could reduce the superfluous questions.

Mike
[G Tablet General] mbamberg:
Fosser2,

I also discovered that the system would not boot with the "battery-backup" voltage regulator installed. But this may in fact point to the problem I'm having.

In a discussion with one of my friends, he commented that maybe the reason the GPS was not installed on the board was due to problem encountered, by the manufacturer, during the testing. He commented that on some of his system boards, some items, originally designed into the board, were un-populated in the final released product due to instabilities or power loading issues when every device was installed.

I wonder if the addition of the 1.8v regulator pulls the voltage down just enough to hang the system at boot? Maybe even with that device removed, my system has marginal power and cannot run with the GPS powered.

Originally you mentioned another person that used other power locations to provide power to the GPS. Maybe I need to do that too. If I remove the 3.3V regulator it should shut off the GPS.

Tomorrow afternoon I'll remove the 3.3V regulator and see if I can boot my system.

Mike
[G Tablet General] nelomen:
Good luck

This sounds a out of my expertise but sounds awesome
[G Tablet General] fosser2:
Yes you are correct. If you remove the 3.3v regulator the GPS will be turned off. I would most definitely jumper the location instead of using that chip. As for power consumption. I highly doubt that your unit doesn't have enough power. Viewsonic took the GPS out to save money, not because it wouldn't run. I am even surprised that your tablet started up w/ the 3.3v regulator. I hope nothing fried. I updated the tutorial yesterday, saying just to jumper that location. I hope that this is solvable... And about BoS and higher ROMS, we're working on enabling GPS. I really would like to use it also on these ROMS so you're not in the dark.
[G Tablet General] mbamberg:
The 3.3 regulator is the one powering the the GPS. That is the actual voltage regulation of the chip. not 5V as you note on the parts list. It takes 5V in and returns 3.3V regulated.

The one you have listed as 3.3V takes 3.3 in and regulates to 1.8V for the "battery backup" function. That is the one that prevented the board from booting, until I replaced it with the jumper as you suggested.

The spec sheet from Linx lists a range of voltages for both the power and the backup. Up to 4.2V for power and 6V for backup

Mike
[G Tablet General] fosser2:
The way that the parts list is labeled is input voltage. So at location "U29 5vdc VCC Reg" there is 5vdc in and 3.3vdc out. That is a proper operating voltage for the main power for the GPS. Now for the part that doesn't work. U22 3.3vdc Bkpbatt Reg does have 3.3vdc in on that pin that is numbered "2" Like you said, according to the data sheet for chip "MCP1700T1802ETTCT-ND" the input voltage it can take varies from 2.3v to 6v. Since the input is 3.3v that should work. That chip outputs 1.2v to 5v. Also like you said before the operating range of Vbackup for the GPS chip ranges between 1.3-6v. So although we might be close to the bottom output that chip will most likely work there too. I just find it weird at that location that it would make the tablet shut off/not start. My only guess is that the chip is going straight to ground for some reason and basically shorting the tablet causing it not to turn on...But according to all of the data sheets the originally speced chip should work.

EDIT: since just using a jumper pin there is still feeding the GPS chip 3.3v I guess that works fine. I still don't understand how it can't function with 1.8v.
[G Tablet General] mbamberg:
Re-reading some previous posts I saw a comment regarding caps possibly being installed backwards. Are any of these caps polarized? Other than the IC parts, is anything polarized? I know resistors are not and I don't thing the Ferrite bead is, that only leaves the caps and coax connector which is installed only one way.

Looking for any ideas.

Mike
[G Tablet General] fosser2:
I honestly have no idea. Although I purchased the parts, I never actually installed the caps or resistor. Is your tablet still not working?
[G Tablet General] fosser2:
rajeevvp,

I did have one other idea about 2.3.4+. I'm not even sure that a working ROM exists but I know the community behind the Z-tab is also pretty large. I know that they did port honeycomb to their tablet as well. If someone got gps working on that tablet than it would be an easy port to the g-tab. It was just a thought. I looked through some of their forums on www.ez-pad.net/ but I'm struggling w/ the language barrier :p
[G Tablet General] rajeevvp:
Go ahead and try that path if you want, and if you require any help, just ask.

I'm trying a different tack--for now. I've got herbert1's BlueGPS4Droid source and have setup the Eclipse IDE to start building my own Android packages. I'll modify the BlueGPS source so that it reads directly from /dev/ttyHS3 and also toggles GPS power via the `gps_control/enable' file. The rest of herbert1's code and technique--setting up a mock location provider and feeding data into it--I'll keep.

I didn't like this method initially, but now, the more I look at it, the more I like it, because this looks like a technique that will work on all Android versions. The Mock Location facility is an application-level feature that Google will try very hard to keep even in future versions. What we were originally planning (fixing the Android source files) depends on Android's internal APIs, which can change between major versions--as, in fact, it has between Froyo and Gingerbread.

I'll pursue the "official" path after I'm done mutilating the BlueGPS source. As I see it now, the "official" way needs changes to some of the core java framework files and its associated native libraries--which means that those changes might, ultimately, have to be made to the source by every ROM provider (because I don't think files like framework.jar from CM7 can be used on, say, Evervolv--both GB ROMs).
[G Tablet General] fosser2:
Dang! sounds like some work. Hopefully it isn't as complicated as it sounds :p I'll keep everyone updated on what I'm doing. I probably won't be around as much now because I start working 12hr days. I will update at least once daily. :)
[G Tablet General] m_elias:
I'm getting my parts today and hoping to run the internal GPS on Bottle of Smoke. Let me know what I can do to help this along.
[G Tablet General] m_elias:
Which pin is #1 on the level translator chip

So I soldered in the parts, writing 1 to /sys/devices/platform/gps_control/enable starts up the gps chip, the LED blinks rapidly and eventually settles. Opening and closing maps also starts and stops the gps chip. So that looks good.

Now, I ran into some problems while soldering in the jumper besides the voltage level translator chip. In the process of cutting off my jumper wire I tore off the pad for the trace that runs under the translator chip. I can't quite figure out which is pin one on the chip so I don't know for sure if I managed to get my jumper to work or not. I'd like to install the jumper straight to the correct pin on the translator chip. I'd appreciate if anyone could tell me which pin is #1.

I do get some data when running hexdump but I'm not sure how to convert it to something readable on Windows.
[G Tablet General] rajeevvp:
Since the data is NMEA output--and therefore plain text--just use the cat command instead of `hexdump -C'.

I originally suggested hexdump because I didn't know what format the output would be in (SiRF 3 output, I believe, is binary).
[G Tablet General] fosser2:
Looking through the data sheet, I'm guessing both VCCa and VCCb need to have voltage on them. Use a multimeter and see if they do. Pins 3 and 7.

EDIT: ps that really sucks about the trace. I guess since it is just an enable pin you will be able to enable it elsewhere.
[G Tablet General] m_elias:
cat /dev/ttyH3

puts out gibberish, definitely not intelligible nmea strings. I took a look at the datacheet too and I had poked around with a multimeter. It showed that pin 3 & 6 are connected to the jumper or its pin 2 & 7 that are common with the jumper. I may have to pull the main board back out and take another look. I could have forgotten the exact details.

The other thing I'm not sure of is exactly what files need modifying to get this GPS mod to work with Brilliant Colors 1.2.1. I have replaced libgps.so but have not touched anything else. What is required to make sure the baud rate etc are correct? I was reading of another file (the name escapes me right now) that some guys were fiddling with. Not sure if that applies to BC.
[G Tablet General] fosser2:
in BC 1.2.1 internal gps is literally drop it in and replace libgps.so and it works. Baud rate is already set and everything. If you're willing we need the help attempting to find a way to get it working android 2.3+
[G Tablet General] m_elias:
I believe the stripe is on the same end as pin 1 & 8.

Pin 1 - B2, can't remember

Pin 2 - confirmed GND

Pin 3 - VCCa, 1.8V continuous

Pin 4 - A2, 1.8V

Pin 5 - A1, fluctuating

Pin 6 - My connection seems good, is 1.8V, common with VCCa

Pin 7 - VCCb approx 2.5V when GPS is enabled

Pin 8 - B1, fluctuating

cat /dev/ttyHS3

At one point I was getting some nmea data but it looked corrupt, unusual characters in the data stream. After redoing the Level Translator's enable connection, I don't get any data output on ttyHS3. I've triple checked my connections, maybe I have damaged something. I can't really justify spending a bunch more time on it now but I'm tempted to sniff the GPS serial line with a TTL->USB adapter and/or hook up the scope to see what the deal is.
[G Tablet General] fosser2:
What ROM are you running?

When I run the command

cat /dev/ttyHS3

It functions perfectly. Here is what it outputs.
[G Tablet General] rajeevvp:
If the binary output on /dev/ttyHS3 is not a hardware problem, we can fix it in software.

According to the datasheet, the Linx RXM-GPS-SG module can output either NMEA (ASCII) or SiRF (binary) data.

First, check that it's not a baud-rate incompatibility (although libgps.so should have taken care of this as NMEA is generally output at 9600 baud). Force /dev/ttyHS3 to 9600,8,N,1:

$ su
# stty -F /dev/ttyHS3 speed 9600 cs8 -parenb -cstopb

After this, cat /dev/ttyHS3. Check if you get NMEA data.

If you don't, then the GPS module might be in SiRF (binary) mode. Run the attached shell script (needs busybox) which sends the SiRF binary commands to switch to a standard NMEA mode (read script for the details).

$ su
# sh /some/path/switch-to-nmea.sh

Try the cat command again to see if the switch to NMEA mode worked.
[G Tablet General] m_elias:
I'm running Brilliant Corners 1.2.1.

Reading the GPS datasheet I noticed the two modes and was wondering myself if that was the case. Thanks for the script and baud settings, I will take another look at it soon.

For troubleshooting purposes, how important is it that the GPS module has good satellite reception? My "hacking cave" is in the basement. Like other GPS units I've played with I expect it should output nmea strings even if it's not acquiring much signal.

I will also reflash BC as I was already playing around with the gps.conf file. It is my understanding that with BC I should only need to replace libgps.so with the file attached to the original post.
[G Tablet General] fosser2:
You will need to be by a window for sure. I can almost guarantee that you will have no satellite reception in the basement.
[G Tablet General] m_elias:
Is sat reception necessary for the GPS module to output nmea strings?
[G Tablet General] fosser2:
Yes it is. You have to be connected to get data.
[G Tablet General] fosser2:
rajeevvp,

How is the modification of the BlueGPS source code going? How much code has to be changed in the program to get it to read from ttyHS3(GPS) instead of ttyHS2(Bluetooth)? I looked through the source code for the program but it was over my head programming wise. I have a feeling that people are going to like this edited version of the program, because everyone running Adam Ink's on honeycomb need something like this too.
[G Tablet General] rajeevvp:
I can give you a simple (ie. hardcoded) version to test this weekend. The full-featured one (where the user can change the device, port params, etc) I'll need a few days more.

The modifications were not hard, but the source is written in Java, and I'm having to mentally translate from the C++ which I learned (and forgot) ~13 years ago to that language; along with figuring out the needed Android APIs which are completely new to me.:p