I've noticed a couple of other threads around the 'net mentioning this problem. I wanted to report my progress on reporting it to Archos and to get anybody else experiencing this problem to pile on the thread.
The problem is that the Archos 101 (and other models?) occasionally freeze when using an external GPS receiver.
My particular receiver is a QSTARZ 818XT. I love the receiver and it works fine on the other 5 android devices I've tested it with.
So in trying to track down this problem I tried several options: The factory wipe of the device, setting the "Power Management" up to "Overdrive", and using an app to tether the GPS. None of those helped.
Now the QSTARZ has the ability to run at 1hz and 10hz. I always assumed if 1hz didn't work, 10hz sure as heck wouldn't, but I was wrong. 10hz works fine. I ran for a full 24 hours without issue at 10hz. So today on a whim I set up a logcat log on my pc and set the receiver back to 1hz. Lo and behold about an hour later it crashed and I got some meaningful data.
Without posting the full stack trace, it appears that, at 1hz, the tablet isn't busy enough to stay interested and something (I can't tell what from the trace, but possibly the cpu itself) goes to sleep or downclocks. The next incoming bluetooth serial packet wakes it back up again but a page fault occurs. This repeats over and over never ending (thus the appearance of a hang, no handlers left to respond to button presses).
At 10hz, the sleep/crash cycle never happens since the unit is busy keeping up with the data stream. This makes some sense to me since things like A2DP and bluetooth data transfer seem to work ok. They are higher bandwidth than the pitiful 4.8 Kbps GPS stream.
I shipped the stack trace off to Archos but I have no way of knowing if they are really going to look at it or not. It took me several e-mail exchanges until the tech support person I received would admit Archos could possibly have a fault in their firmware. I have a ticket number that I won't share publicly but we can possibly cross reference if people want to open their own tickets.
So here I have provided some data and a workaround... if you are having this problem and can increase the data output rate of the receiver, it might help your situation. Also, if you have experience this issue please post here so we can get a head count of interested individuals to show to Archos.
Thanks, Matt
The problem is that the Archos 101 (and other models?) occasionally freeze when using an external GPS receiver.
My particular receiver is a QSTARZ 818XT. I love the receiver and it works fine on the other 5 android devices I've tested it with.
So in trying to track down this problem I tried several options: The factory wipe of the device, setting the "Power Management" up to "Overdrive", and using an app to tether the GPS. None of those helped.
Now the QSTARZ has the ability to run at 1hz and 10hz. I always assumed if 1hz didn't work, 10hz sure as heck wouldn't, but I was wrong. 10hz works fine. I ran for a full 24 hours without issue at 10hz. So today on a whim I set up a logcat log on my pc and set the receiver back to 1hz. Lo and behold about an hour later it crashed and I got some meaningful data.
Without posting the full stack trace, it appears that, at 1hz, the tablet isn't busy enough to stay interested and something (I can't tell what from the trace, but possibly the cpu itself) goes to sleep or downclocks. The next incoming bluetooth serial packet wakes it back up again but a page fault occurs. This repeats over and over never ending (thus the appearance of a hang, no handlers left to respond to button presses).
At 10hz, the sleep/crash cycle never happens since the unit is busy keeping up with the data stream. This makes some sense to me since things like A2DP and bluetooth data transfer seem to work ok. They are higher bandwidth than the pitiful 4.8 Kbps GPS stream.
I shipped the stack trace off to Archos but I have no way of knowing if they are really going to look at it or not. It took me several e-mail exchanges until the tech support person I received would admit Archos could possibly have a fault in their firmware. I have a ticket number that I won't share publicly but we can possibly cross reference if people want to open their own tickets.
So here I have provided some data and a workaround... if you are having this problem and can increase the data output rate of the receiver, it might help your situation. Also, if you have experience this issue please post here so we can get a head count of interested individuals to show to Archos.
Thanks, Matt