[ntp:questions] Sure GPS: Programming it now works
unruh at wormhole.physics.ubc.ca
Fri Apr 8 21:09:40 UTC 2011
On 2011-04-08, unruh <unruh at wormhole.physics.ubc.ca> wrote:
> On 2011-04-08, E-Mail Sent to this address will be added to the BlackLists <Null at BlackList.Anitech-Systems.invalid> wrote:
>> unruh wrote:
>>> a more complete set of instructions that can be sent under
>>> the MTK protocol is in
>> There is slightly newer one here:
> Yes, I have that one too. The main change seems to be a Huge MTK
> CONFIDENTIAL NO DISCLOSURE Release Version for Transystem in English and
> Chinese plastered across every page.
>> LeadTek, (I have used several thousand of their chips)
>> appears to also have a newer one:
> Nope. They list a far smaller set of commands than does the SATEV of
> Transcend. (20 commands vs 35 in the other lists. Of course I have not
> checked to make sure that the Sure responds to all those extra commands)
Actually, on looking more closely, Leadtek do have one command listed
221 PMTK_SET_INTMT -- set the system to run intermittently. You can
set it up to wake up for say 1/2 sec and obtain a fix, and then go to
sleep for up to 86 sec before it wakes up again and repeats. No idea if
the Sure supports that command or not, and I do not really want to test
The example is
which has the machine wake up for 5 sec (5000ms) and then sleep for 5
sec. The second argument is the total time of run plus sleep. each in
msec. (The second interval must be less than 86400 ms)
There may be some overlap with PMTK320-- Power save mode, but the docs
do not say at all what this power save mode is all about, and anyway,
they say (Caution:This command is for internal test only) for 320.
>>> the Sure chip does seem to respond to a number of those commands.
> That is not of much help for the MTK commands.
>> I would have thought the SKG16B datasheet or manual would
>> have told you all you need to know about supported commands.
>> However the most recent datasheets for the SKG16B,
>> at first glance seems like they might be a bit lacking
>> in full protocol information; Skylab didn't seem to
>> have a separate protocol doc either, (to cover their
>> proprietary "custom protocol" commands).
> I guess they take the MTK proprietary claims seriously. And stupidly.
More information about the questions