enh: Possibility to issue commands to gps

[GoogleCodeExporter]

Some gps's (mine) doesn't have a timer before a cold reset is issued.  The
result is that if I have moved far away with the GPS off, it will never get
a satellite lock.

To remedy this a cold reset command is issued over the serial (bluetooth) link.
-or leave the batteries run out, or break the warranty - open the thing and
remove the battery (oh well, I've already done that a few times but.. ).
Neither of them are a good option 'in the field'.
Anyway..

It would be great if some GPS control view was available on the menu where
one can define a few (NMEA) strings that can be sent to the GPS on user
request.
If it can calculate the nmea checksum that would be even better.

I believe these are manufacture specific messages, but one could possibly
add some usual suspects, for instance sirf.

Original issue reported on code.google.com by ttyri...@gmail.com on 9 Mar 2009 at 10:43

[GoogleCodeExporter]

You anticipate future development. I've been thinking of adding support for Sirf
binary protocol recently. 

Original comment by gdjo...@gmail.com on 10 Mar 2009 at 11:39

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Note that I was not talking about the sirf binary protocol. Most chips have
implemented some NMEA proprietary extensions for device control. For instance 
"$PSRF101,0,0,0,000,0,0,12,6*12" will cold start sirf chips. Some firmware do 
this
cold start automatically after a few minutes without a fix, some (like my 
device)
needs a manual command from software.

I am not discouraging you, but is there really any gain from the sirf binary? Is
there something one can not do with standard NMEA? I ask because I'm generally
skeptic to redundant functionality on limited devices.
Anyway, as stated, the enhancement request was not for sirf binary.

Original comment by ttyri...@gmail.com on 11 Mar 2009 at 8:36

[GoogleCodeExporter]

As a side note. switching between NMEA and sirf can be a "dangerous" game. It 
seems
like typical BT devices have a fixed baud rate between the bluetooth and gps 
chip. 

Switching back and forth between NMEA and sirf requires you to specify that 
baud rate
and it's typically not (by my experience) the standard 4800bps for nmea / 19200 
for sirf.

If you get it wrong there is only rubbish on the gps output until you can hard 
reset
the device.

It may be better to further discuss this in a "enh: add sirf binary protocol" 
issue.

-- T

Original comment by ttyri...@gmail.com on 11 Mar 2009 at 8:47

[GoogleCodeExporter]

I take your comments, and apologise for redirecting your issue ;-)
To bring it back on track, I understand what you are asking for and agree it 
could be
a worthwhile addition.

Original comment by gdjo...@gmail.com on 11 Mar 2009 at 6:27

[GoogleCodeExporter]

Nice feature to send commands to the GPS.
My Holux M1000 understands the following commands (capture from the 
Holux-Viewer):
"Hot Start" :$PMTK101*32
"Warm Start":$PMTK102*31
"Cold Start":$PMTK103*30.. $PMTK605*31 (2 cont. commands)
and there are several other commands, which are sent at the startup.

Original comment by andreas....@gmx.at on 12 Mar 2009 at 8:23

[GoogleCodeExporter]

I've implemented a version of this idea in the latest source (1.15+). It's 
called
'Gps Messages' and is in the development menu of the application.
It doesn't come with any prebuilt commands, instead it offers the option to 
create
and manage your own list of commands,which are saved to the recordstore. You 
can give
each command a name, and an NMEA string. It will take care of the checksum so 
you
only supply the main command ie. $<this bit>*checksum. You can select several
prewritten commands and send them to the device at once.

It has not been rigorously tested, but it works for me, so could do with some 
other
eyes looking at it.

Original comment by gdjo...@gmail.com on 23 Mar 2009 at 2:39

[GoogleCodeExporter]

I've tested the send-feature and it's working.
For my SE W610i (JP-7 platform) I've the following condition, because my phone
doesn't support it:
"dev instanceof Jsr179Device"
There's one issue:
When I select several commands I can't define the order.
The view- and send-order is independant from the definition-order and also from 
the
selection-order.
It would be nice if the commands are sent in the same order as I've selected the
commands.

Original comment by andreas....@gmx.at on 23 Mar 2009 at 8:55

[GoogleCodeExporter]

Thanks for the feedback.

Yeah it's using a hashtable, so there is no specific ordering. That's fixable. 

The 'dev instanceof Jsr179Device' is supposed to guard against people trying to 
send
commands to a jsr179 device, but is really unnecessary. I'll fix that too.

Original comment by gdjo...@gmail.com on 24 Mar 2009 at 9:31