GpsPasSion LIVE!
This is a Flickr badge showing public photos from GpsPasSion Live !. Make your own badge here.




- -

Pour vous guider sur la Route :
GPS Mobile (SEM)
GPS Intégré
Voter  -  Résultat des votes
Votes : 2402

Club GpsPasSion
Soutenez le site!

USA: (US$)
Guide Paypal

GpsPasSion Forums
Home | Profile | Register/Enregist. | Active Topics | Search/Recherche | FAQ
Save Password
Forgot your Password?

 All Forums
 Advanced Topics
 General Technical Discussions
 SiRFdemo tutorial (static navigation)

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkInsert EmailInsert Image Insert CodeInsert QuoteInsert List

* Forum Code is ON
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

  Check here to include your profile signature.
Check here to subscribe to this topic.

T O P I C    R E V I E W
gpspassion Posted - 20 mars 2005 : 16:36:53
SiRFdemo for PCs (and PocketPCs*)
Advanced configuration for SiRF based GPS receivers!


Before proceeding, download the latest version of SiRFdemo
PC Version (advanced) : v3.87 - PPC Version (basic): v1.16


  1. Introduction
  2. Configuration
  3. Navigation Parameters
  4. Configuring 'Static Navigation'
  5. Back to NMEA
  6. Links of interest


Why use SiRFdemo ?
  1. To take a peek at the advanced settings of your GPS receiver and to see how it was set in the factory, or modify some of these settings

  2. Your GPS is behaving oddly and you want to reset it to factory defaults

  3. You want to verify the revision of the Firmware loaded on your GPS receiver - (insight on SiRF FW naming)

<!> Beware <!>
While using this software will normally not damage your receiver, please realize that some actions not covered in this tutorial might misconfigure your receiver and likely void your warranty. In any case, GpsPasSion will not be held responsible if your GPS receiver stops responding from the use of this software


  1. To use SiRFdemo you need a PC or a laptop and a way to connect your GPS receiver. For a compact flash GPS, you can use a PCMCIA/CF adapter, for a wired GPS, a DB9 serial port or USB via a USB/DB9 adapter and of course a Bluetooth GPS receiver with built-in BT or a dongle
  2. You need to identify the correct COM port used by your GPS. It will be COM1 for a serial GPS generally and for a Bluetooth GPS, a right click on the connection will show you the port
  3. Launch SiRFdemo - choose the correct COM port and select 4,800 (or 38,400 for a Bluetooth GPS) (fig 1)
  4. SiRFdemo only provides detailed information in SiRF mode so do \Action\Switch to SiRF (fig 2) and you will see the various windows "light up"(fig 3)

Fig.1 Fig.2 Fig.3


A modern GPS receiver is a full blown "computer" equipped with a CPU - baseband chip (ARM), an RF chip (signal processing), ROM (rewritable flash) and RAM - but unlike a "normal" computer it is highly specialized and has been programmed accordingly. Some of these parameters are visible as the "Navigation Parameters"; to make them appear in the "Response View" window, do \Poll\Navigaton Parameters. Let's take a brief look at them :

Fig.4 Fig.5

  1. Operating Mode (Degraded/Altitude Hold/Dead Reckoning) : défines the operating mode when optimal reception (4+ satellites) is no longer available
  2. Track Smoothing : wrill smoothen the track to remove the "jumps" resulting from the natural "inaccuracy" of the GPS system (10/15 meters) - disabled by default
  3. Static Navigation : will "freeze" the position at very low speed to cancel out the drifting resulting from the natura "inaccuray" of GPS - should be disabled for pedestrian use - see below for details
  4. DOP : filtering based on the quality of reception
  5. DGPS : controls the activation of SBAS (WAAS in the US and EGNOS in Europe) - since SA (Selective Availability) was removed in May 2000, mainly useful to check the integrity of the GPS signal for critical use in planes and in shipts - available on SiRFstar III with FW 3.1 and above
  6. Power : to configure power saving trickle modes

Note : To show the firmware version loaded in your GPS in the top window, do \Poll\SW Version - GSW3.0...with the SiRFIII Globalsat BT-338 GPS I was using.


While most settings are best left untouched unless you want to experiment (always risky !), "Static Navigation" is one that should be looked at closely especially with the arrival of the new SiRFstarIII based receivers, as these ultra-powerful receivers take GPS reception to a new level and can work with very weak signals but when that happens, accuracy can be impacted. Observations over a 24 hour period show that with good signals, 95% of the positions reported by the GPS will be within a 15 meter radius, while with weak signals, 95% of the positions will be within a radius of 50 meters.

Current road navigation software is designed for GPS receivers that only operate with good signals so accuracy will be in the 15 meter area. Such software will "snap" the position to the closest road so in a dense urban area, with degraded accuracy it's going to be easy to make the wrong decision and produce "uncosmetic" results and possibly force a trip recalculation.

Instead of redesigning navigation software to take this account (one could imagine some type of dynamic filtering based on DOP) and risk increasing the processing load on the PDA and hurt user experience, the easy fix is to implement this fix directly by having GPS manufacturers activate "Static Navigation" by default and therefore freeze the position using some complex algorithms mainly speed dependent. The problem with this is that this will considerably hurt low speed pedestrian use, with the speed staying on "0" and 50 meter jumps (update threshhold). If you want to use your GPS receiver outside your car, you'll need to disable SN, this is how to do it :

Fig.6 Fig.7

  1. \Navigation\Static Navigation\ (fig. 6)
  2. Click on "Disable" then SEND (fig. 7)
  3. Verify that the change has been recorded by the GPS by calling the Navigation Parameters
  4. Please note that the default setting will return with a "factory reset" command or when the battery runs out
  5. Analyzing: As you can see in 9a, representing a walk with silumtaneaous logging, the impact of SN on a SiRFstarIII GPS is pretty significant, better accuracy, better distance measurement, with Xtrac 2 there is no notable impact and its status as a "non-pedestrian" friendly GPS remains.

BEFORE - AFTER - On the Field

Fig.8 Fig.9 Fig.9a


NMEA being the universal GPS language, best not to forget to return to that mode after looking up the advanced settings and possibly modifying them. There are two ways to proceed:
  1. To keep your settings : \Action\Switch to NMEA Protocol\ select 4,800 then Send (fig. 10 et 11)
  2. To set your GPS back to its factory settings : \Action\Initialize Data Source\Factory Reset then Send (fig. 12 et 13)

Fig.10 Fig.11

Fig.12 Fig.13


  1. "Technical Forums" - >>HERE<<

* PocketPC owners can also try this application that I have found to work as well although not with WM2003SE. For WM2003SE you can use this program to toggle SN and also or CE Monitor and GPSTweak for SBAS settings - 02/2006 : here is a new "tweaker", SiRFtech.

Discounts and Assistance/Réductions et Assistance (Club GpsPasSion) / Où commencer?
150   L A T E S T    R E P L I E S    (Newest First)
zgroza Posted - 16 juil. 2013 : 23:15:09
(it's hard to believe to me, but it really works)

I've found a solution by accident, on a one of Polish biker's blog. That man wrote: "when you connect with SirfDemo in NMEA mode, select: Transmit serial message, type: PSRF100,0,9600,8,1,0 and choose NMEA protocol wrapoer" - and when I've done this, I saw at last standard behavior described on this forum (and many others): flowing output in the response view...

I don't understand how it works (and why option "switch to Sirf protocol" doesn't work) but it doesn't matter to me: finally I could switch off StaticNav., switch on SBAS - and poll Nav parameters to make sure that it works.

If it would be useful to anyone of you: I've checked first communication with SirfTech for PC - and I was able to switch to Sirf without problem & switch off StaticNav. - but I wasn't sure the result: I couldn't find an option to check if this command was completed succesfully. And next thing: both SirfDemo and SirfTech, when used with PortMon running (thanks for remind me, that such application exist), show, that communication occur all the time until I disconnect the device: even when SirfDemo shows nothing after switching to Sirf protocol (choosen from menu "action"), PortMon still shows, that everything is ok. - all commands (synchronizing baud rates etc.) are completed with success! Only SirfDemo shows no output... I don't understand this (I'm not a programmer) and I don't even try: I'm really happy that my module works fine :))) (and yesterday I thought of throwing it away...)

Anyway, thanks a lot for your help :)))
zgroza Posted - 15 juil. 2013 : 09:14:20
Thanks a lot for your replies!
Unfortunately today I left the receiver at my friend for further testing (I don't expect anytning), I'll have it back tomorrow and then I'll follow your advices.

I'll let you know if there's any progress or none (by the way: I didn't realize that there's a separate version of SirfTech for PC).
Carl@SiRF Posted - 12 juil. 2013 : 18:42:35
What you describe is pretty classic for losing baud rate matchup. The fact that the LED continues to blink means that the unit is still sending out data. When you command the unit to change protocol and baud rate, SiRFDemo does the same thing with you, so if the command was not acted upon for whatever reason, you lose communication.

There are a couple things that could be wrong: either the receiver rejected or did not act upon the command, or it responded incorrectly. That latter is not very likely, so let's concentrate no the former. The basic GSC3 chip has two serial ports, although one may not be connected. If the software in the receiver is set to handle both ports, then as a byproduct of that you are stuck without being able to switch protocols - there is a rule in the software that only one copy of a protocol may exist and in a two-port build NMEA is already on one port and SiRF binary is on the other. I suspect that is your issue.

To verify if that is correct, issue the command to switch baud rates only. If you keep contact with the chip, then issue the command to switch protocol but at the same baud rate. If the receiver continues to talk in NMEA, most likely the two-port build is the culprit and you can't switch to binary. Chect your module and see if maybe somewhere on the circuit board the other serial port is present - look with a scope on any test points for serial data.
saimhe Posted - 12 juil. 2013 : 17:46:25
After switching to Sirf protocol, nothing happens: GPS module behaves as if it was disconnected (green led blinking slowly), there's nothing in response view, in error view or receiver output view and when I try to send any command to the module I can't even check if anything was send.

Try the PC version of SirfTech ( It behaves more transparently than SiRFdemo. Additionally, you can run PortMon ( to see what was actually sent and received.
zgroza Posted - 12 juil. 2013 : 13:56:06

Need some help if you can :)
I've tried to disable Static Navigation (Nokia LD-3W; SirfDemo 3.87 & earlier, e.g. 3.30a, 3.36, 3.40 - no difference) with no result. I can connect with GPS module and I have output in debug view (NMEA protocol behaves as if everything was ok.), but when I switch to Sirf Protocol - I'm loosing connection with the module (when I switch back, I have output in debug view again). After switching to Sirf protocol, nothing happens: GPS module behaves as if it was disconnected (green led blinking slowly), there's nothing in response view, in error view or receiver output view and when I try to send any command to the module I can't even check if anything was send. The only thing that changes is baud rate: always 57600 (yes, I switched "set main serial port" settings - with no effort). I've tried to log in if anything changes, but there's nothing valuable in the log file). Receiver initialization doesn't make any changes too.

I've tried to solve it by myself:
First of all, I've read SirfDemo User Guide (trying to find some troubleshooting or some hints to my problem) - nothing found. Then, I've read this forum to find any solution - the only hint I've found was to install Alpsirf on PocketPC - but I haven't got any... only standard PC (and mobile phone running java apps). I've tried to change bluetooth COM port number and other settings, change bluetooth drivers (Widcomm & Bluesoleil, on different PC's), I made reset of GPS receiver (on the device - software can't do it), in SirfDemo: I made protocol & baud rate synchronization, tried to set different baud rates by hand, switched on (or off) time sync, changed target software (I don't know which version my Nokia has) with or without auto-detection. And no result: always the same. I feel helpless...

GPS module is brand new (with valid warranty). And it has no other sockets to connect - only bluetooth.

Is there something I could omit?
Can you at least tell me for sure, that my GPS module is damaged? That would be usefull.

Thanks a lot in advance :)
Carl@SiRF Posted - 23 avr. 2013 : 01:54:42
The message that says Unk: 4002131400........00000002 means that SiRFDemo has parsed a binary message, removing the header and trailer, but that it doesn't know how to interpret the payload. SiRFDemo has been replaced by SiRFLive for newer chips like the GSD4e, so it was never taught how to interpret message ID 64, subID 2 (0x40 0x02 for the first two bytes).

MID 64 is the new message group of advanced navigation library data.
saimhe Posted - 12 nov. 2012 : 19:05:21
Not enough data. With some 1-2 KB it would be easier.

Basically this message means that SiRFDemo was unable to detect neither NMEA format nor SiRF binary format. To my eyes this definitely isn't NMEA, too many non-text values. As for the binary, the protocol allows to craft a packet that's 32 KB in length and still valid, and a packet boundary would not be found earlier.

But in practice this is more similar to a bitrate mismatch. SiRFDemo likes to switch to higher bitrate among with the binary protocol. Some Bluetooth modems support a single bitrate only and in such case communication becomes impossible until the entire GPS receiver is reset properly (for example, by disconnecting the internal backup battery).
jeensii Posted - 25 oct. 2012 : 13:39:02

Can anybody explain to me what the output in sirf mode in the debug view of SiRFDemo exactly means? I mean those:

Unk: 4002131400........00000002

thanks in advance,
testerics Posted - 13 avr. 2012 : 12:23:56
There is a command line for changing "Message Rate" on NMEA? I want to start GSA=1 and GSV=1 on my Navigon with a script before launching the Primo or iGO8 to have the possibility to see the signal bars on this applications (for now, Navigon is starting only GGA and RMC).
JulienS Posted - 26 janv. 2011 : 22:26:37
Do you know where I could get the other SIRF tools (SiRFGetEE, SiRFView...) ?
JulienS Posted - 26 janv. 2011 : 13:43:33
Thanks Alan,
SirfTech works fine. I also managed to run SiRFDemo 3.87 from my laptop through ActiveSync. For this I use :
- Franson GPSGate on the laptop (input = ActiveSync)
- Franson GPSGate 2.6 build 347 BETA for Windows CE .NET on the device (output = activesync)
Allycat Posted - 25 janv. 2011 : 19:44:24

SiRFdemoPPC was intended to run with Windows Mobile and generally the "stripped down" Win_CE devices have too many software modules missing.

It depends what you want to do, but have you seen/tried "SirfTech" which manages most of the SiRF functions and has wider platform support:

Cheers, Alan.
JulienS Posted - 25 janv. 2011 : 19:16:10
Hi Everyone, and especially Carl@sirf if you're still there:
I'd need to run SirfDemoPPC on a windows CE 6.0. I could hardly download the software from the internet, as is not available anymore. I installed it, and it doesn't seem compatible with my OS. Is there a way to make it work ?
If someone has experience about this...
jukivili Posted - 07 déc. 2009 : 01:28:36
Nokia LD-4W (GSWLT3.2.5NOK_3.3.01.01-CL31B1.00):

"Action -> Switch to SiRF Protocol" works fine (bt link goes down, after reconnect it is running in sirf-mode).

"Action -> Switch to NMEA Protocol" does NOT work (bt/gps go out of sync, need to power cycle), but manual NMEA switch works with 0 baud.

"Action -> Transmit Serial Message...": a0 a2 00 18 81 02 01 01 00 00 01 01 05 01 01 01 00 00 00 01 00 01 00 01 00 01 00 00 00 93 b0 b3
bogdan.dumitru Posted - 30 oct. 2009 : 11:29:19
just for the knowledge base:
Nokia LD-3W
transmit serial message:
sirf mode: PSRF100,0,38400,8,1,0
nmea mode: A0A20018 81020101 00010101 05010101 00010001 00010001 00019600 012BB0B3
scalor Posted - 05 juil. 2009 : 08:55:31
i try 2400 that work the nmea protocol in the other baudrate i can't view the nmea string

When i try to change protocol i obtain only this

in error view

warning setcommstate()failed in CSerialComm::open
warning SetComm(0x1000)() failed
warning SetupComm()failed


i have an other question, the 1 PPS output it's enable when there is the fix or must be enable by sirfdemo ? because i have wired the probe of the oscilloscope but there isn't the 1pps signal !
saimhe Posted - 04 juil. 2009 : 23:41:45
Originally posted by scalor

only this string in the receiver output view

255(0xFF) Error Data

and in the error view

Comm CE_break

Did you try every possible baudrate at this point?
scalor Posted - 04 juil. 2009 : 21:38:28
i have a problem, in a usglobalsat mr350P gps that work perfectly in nmea output, when i try to switch between nmea output and sirf output, i obtain only this string in the receiver output view

255(0xFF) Error Data

and in the error view

Comm CE_break

gpspassion Posted - 20 mars 2009 : 20:28:03
No chance, not sure what your problem is, but you should check out the topics in the Garmin section for tips on how to fix it.
spiiiguy Posted - 20 mars 2009 : 20:25:28
does anybody know how to connect to a garmin c550 using this software and usb or bluetooth? My sirf firmware needs a downgrade since webupdater did me in. I tried installing sirfdemo & the uart/usb software

I get error code 10 just trying to start the driver.
glaros Posted - 20 mars 2009 : 11:23:05
Ok, thanks for the quick reply,that's great.
GT31 works at constant baud rate of 38400.
I wished it could change down to 4800, since
I want to use it with MS Autoroute 2007 as a real
time GPS receiver, but this application is only
compatible with GPS at 4800 baud.
Anyway, that's another story.
gpspassion Posted - 20 mars 2009 : 11:15:45
No as long as you don't send any commands you should be ok. The older versions of SiRFdemo also forced you to switch to a SiRF binary and that could create problems as the baudrate was changed in the process, now you can get detailed info too in NMEA mode.
glaros Posted - 20 mars 2009 : 11:09:15
I think I know what you may mean. You believe
there might be a problem if i simply run the
application as it is (without setting/changing
parameters, etc), watching only signal level,
response and debug views. Will GT31 come out
of synch even then?
gpspassion Posted - 20 mars 2009 : 09:55:21
Sure, make sure you don't "desynch" it though, these dataloggers probably react differently than a "simple" GPS receiver.
glaros Posted - 20 mars 2009 : 06:20:18
Thanks a lot for the link. I have now managed to
download the application. I will interface this
program with GT31 GPS from Locosys.
gpspassion Posted - 18 mars 2009 : 13:29:40
Odd, maybe related to the merger ?

Still available here :
glaros Posted - 18 mars 2009 : 09:59:22 website does not have SiRFDemo.exe program available.
how do you download it?
saimhe Posted - 29 nov. 2008 : 16:15:14
Of course it might.

The URL in the post just before yours still works :)
HebsHowie Posted - 29 nov. 2008 : 15:40:21
Hi, I have built a GPS receiver based on an EM 406A receiver. I am trying to find out if it is processing SBAS corrections and was wodering if SiRF Demo might assist me? How can I download a copy?
Lion Posted - 08 oct. 2008 : 10:33:51
Yes, you are right but if you scroll down I
found under "References" the link to SirfDemo.

Just found a link to SirfDemo v3.87

Allycat Posted - 07 oct. 2008 : 13:44:06

That link is to SirfTech not SirfDemo, but that IMHO is a rather "safer" application to play with.

However, particularly if you find SirfDemo, do read more in these forums BEFORE doing much, because it is VERY easy to kill Bluetooth devices, even with apparently simple baud rate commands.

Cheers, Alan.
Lion Posted - 07 oct. 2008 : 13:29:22
Never mind, found it in this forum
Thanks saimhe.
Lion Posted - 07 oct. 2008 : 13:18:58
I am new on this forum and have not yet read all the pages....
But I am looking for a link for the program "Sirfdemo" for my
Laptop running Windows XP.
The link on the first page is dead.

Could someone please help me ?
papa71 Posted - 23 juil. 2008 : 13:52:18
I have a rbt2001 gps. My problem, the blue led is flash, but the devices (pda, computer, mobil) not found the gps. I don't set nothing. Yesterday worked, today don't work. :( Any idea?
SamMan Posted - 03 avr. 2008 : 12:01:46
Originally posted by Leif

When you switch protocol and at the same time choose a new baudrate

With baudrate I have totally detective history. Look - I almost sure that baudrate configuration of the PORT4 itself doesn't have any influence on communication speed for SiRFdemo/SirfTech soft. To clear this thought:
1. I open device manager(on the notebook), open "COM4 Property" window, set up baudrate=4800(for example). Save this setting.
2. Open SirfTech, open Communication dialog, select COM4 and press "Find Baud". SirfTech try all possible values(include 4800!) and stop at 115200 only. From this moment SirfTech begin works normally(in NMEA protocol).
3. Close Communication(via button "Close"), close SirfTech, repeat step1, but for this time set up baudrate=9600, for example.
4. Repeat step2 with the same result - on the 115200 only SirfTech begin normal work.

So, first of all, let's decide - is it normal situation where COM-port-adjustment totally ignored by software?

P.S. Of course, when I try to switch to SiRF protocol I choose(among other) 115200. And, of course, with the same result - all stop work.
Leif Posted - 02 avr. 2008 : 22:27:12
When you switch protocol and at the same time choose a new baudrate you have to follow with clicking the '=Baud' button to change the baudrate your serial port is using for listening.

Try fixing it by going to the Com dialog. Close the port and use 'Find Baud' button.

It is possible that the GPS side of the USB bridge only handles one baudrate and if that was not the first one you choose you have lost the connection. See the help message in the 'Set serial port' dialog for hints on "safe" baudrate.

Best Regards
Dennis Gröning
SamMan Posted - 02 avr. 2008 : 21:38:14
Thanks for reply!

You may have a "weird" communications port/driver.

Hmm… May be. But GPS inserted in ordinary COM4 port, driver for this port also look commonplace like



Already done. And - know what? - I got absolutely identical behaviour!! In short - when I test NMEA protocol all & everything work fine. As soon as I try to execute "\NMEA\Set serial port(Switch to SiRF)" menu item all stop working. This dialog(Switch to SiRF) ask me for baudrate. Since I wasn't sure about this moment I just try all values(one-by-one) from "Baudrate" dropdown list, from 1200 up to 115200. Nothing. Nope. Stop works with any value.

Yes, OEMs can leave many things out.

I am very afraid that you just right about this for my case.
saimhe Posted - 02 avr. 2008 : 10:24:51
Originally posted by SamMan

I get a sense that my GPS-module just doesn't support SiRF protocol.

You may have a "weird" communications port/driver. SiRFDemo does lots of unexpected things which require a standard multi-baud serial port. Try (there is also a PC version in the Downloads section) for a more complete test.

is it possible at all that module constructed on fairly modern chip(SirfStar III) CAN'T work by this proprietary protocol(SiRF)?

Yes, OEMs can leave many things out. But don't hurry to make that assumption.
SamMan Posted - 02 avr. 2008 : 06:39:17

I have the sub-notebook with GPS-module. This module definitely made on SirfStar III chip.
Now, when I launch SiRFdemo it's start works with this module by NMEA protocol. And work just fine - I see satellites on RadarView, see GPS messages on Debug View, etc.(I only wonder - why I get "Warning: SetupComm() failed" in ErrorView if all works fine?; but it's trifle).
Good, now I want to switch on SiRF protocol and select \Action\Switch to SiRF menu. All I get - another "Warning: SetupComm() failed" and all stop works!! I don't see satellites or GPS's messages anymore! If I open \View\Messages\Output in this mode it's also totally blank. I try "Synchronizing Protocol and Baud Rate" menu also in this mode - and again with no luck. So - I get a sense that my GPS-module just doesn't support SiRF protocol. And I want ask you - is it possible at all that module constructed on fairly modern chip(SirfStar III) CAN'T work by this proprietary protocol(SiRF)? What do you think?

I thank in advance for your answers!
dcastan Posted - 31 mars 2008 : 11:19:47

I´m using a Jupiter 21. It has 12 channels but when I´m using SiRfDemo I only can see one satellite. I don´t know what´s the problem. In the Error View window I read "SRAM backup not done: Too few SV´s used in a solution". It seems that the antenna doesn´t work but that´s not true because it´s working with other GPS receiver. Anyone can help me ? Thank you.
saimhe Posted - 28 févr. 2008 : 20:36:59
Binary Protocol Reference Manual 2.1 (pdf, 2920 KB), lots of patience, creativity. The main problem: this NMEA simply has no equivalents for some navigational data (EHPE for example), let alone for mode bits in MID2 and other chip internals. Don't forget that SiRFDemo sometimes requests a few MIDs, and that may mean that you'll be forced to emulate them, too.
Doovede Posted - 28 févr. 2008 : 15:03:28
Got it to work after some hours, and the SiRF codes looks nice, aswell as the NMEA. But how do I convert the NMEA data, so I can get Latitude and so on in SiRFdemo?

Cheers Doovede
saimhe Posted - 28 févr. 2008 : 02:27:59
I don't know anything about that module and still haven't enough experience with AVRs. However both ends must be compatible, that is, either TTL or RS-232 (and - just in case - of the same polarity). If you'll peek at the stream with, say, Hyperterminal or similar software and see inverted bit values, then it's definitely the case.
Doovede Posted - 28 févr. 2008 : 01:21:04

I'v downloaded SiRFDemo 3.83 and trying to connect to the gps module
(EM - 408 through Atmel STK 500 by using the RX and TX on the board. Have seen others have the same problem as me, which is CE_BRAKE and CE_FRAME.

CE_BRAKE and CE_FRAME is poping up at any baudrate. I'm trying to get the baudrate to 4800 in NMEA beacuse i'v programmed a microcontroller (Atmega 16) to send the data to the PCM-Encoder and so on. And the MC has a baudrate atm on 4800.

Any ideas what might be the problem?

Cheers DVD
simonicemans Posted - 19 déc. 2007 : 21:55:40
I think I broke my GPS :(

BR355 receiver. Connected to SiRFDemo. Works fine. Switch to binary protocol, still working fine. Try to set power mode to trickle for our low power application. Now It wont respond or change modes or anything.

Normal operating current (I have it on the bench psu) was ~80mA and varied by perhaps 5 to 10mA. Now it seems stuck on 25mA - I assume it's asleep.

How can I revive it/set it back to normal continuous mode?

While writing this, it seems to have woken up, determined a fix and gone back to sleep again! I guess that's to be expected as that's how it is supposed to work and the whole idea of low power mode. The unexpected bit was that you can't get it out of this mode. I wonder if it will respond to commands the next time it wakes up? Half hour intervals isn't it? It's going to be a long nite... ;)

Ok I caught it when it woke up and I think it's back in continuous mode now :)

tomlouie Posted - 14 déc. 2007 : 14:03:01
Regarding the sticky at the top of this thread, the linked to SirfDemo.exe installer isn't version 3.83 as posted, but rather 3.82. You can double check by downloading the zip file, unzipping the file and then right-click Properties on setupSiRFDemo.exe. Under File Version, you'll see that it says 3.82.
simonspt Posted - 24 nov. 2007 : 13:47:50
Hi to all! I have a Magnex NAV20BT Bluetooth receiver with SirfIII Chipset.

I have a Nokia N70 with tomtom but the connection between the devices is very unstable.. I searched all around and I tried the method of changing the baud rate to 19200 using SirfDemo.

The problem is that SirfDemo doesn't switch in Sirf Protocol..
denti13 Posted - 12 nov. 2007 : 21:10:17
gpspassion, Leif,
Thanks for your help. I found factory reset menu, but not work.
Leif solution work well (PSRF100,1,115200,8,1,0).
Leif Posted - 12 nov. 2007 : 13:42:32
It's the same PSRF100 as is used to switch to SiRF. Just keep NMEA by setting protocol to 1.
denti13 Posted - 12 nov. 2007 : 11:20:28
Thanks Leif,
Which is the nmea command to change baudrate (Sorry, I searched but find nothing).
Leif Posted - 12 nov. 2007 : 09:37:42
You can switch back to NMEA at 57600 and then change to 115200 in NMEA.
denti13 Posted - 12 nov. 2007 : 07:17:19

Thanks for your reply.
I switched in sirf mode to check (and modify) some parameters (as SN, SBAS mode, firmware version).
In Nmea 57600 mode, nmea work well but when I try to use data download utility (comming from royaltek) impossible to connect to the GPS.
I didn't find for the factory reset command.
Finally I disconnect AA batery and the GPS go back to Nmea 115200 mode.
But I suppose a (new?) Sirf messsage exist to do the switch as there is the possibility to use NMEA 115200 mode.
gpspassion Posted - 12 nov. 2007 : 03:34:35
Does the switch to SiRF/57,600 work ok ? To go back to the default baudrate/procotol you could send a factory reset command, but then you would lose the settings you've changed, are you trying to change something in particular?
denti13 Posted - 11 nov. 2007 : 21:49:58
Hello all,
Sorry if this question have already been posted. I searched without succeed :-(
Have a new GPS in test (Royaltek RGM 3800) based on Sirf III chipset.
This GPS is configured by default to NMEA 115200. If i switch in Sirf Mode I cannot go back in Nmea 115200. Is there an alternative to Message ID 129 where baudrate have only 2 bytes for codification (no place for 115200) !!! Is there a solution ?

Allycat Posted - 30 oct. 2007 : 16:49:54
Hi guzya,

Most of the answers are already in this thread. SiRF allow the end-manufacturer to choose many "configuration options" and they can enable/disable various functions. So Nokia may have crippled the SiRF protocol functionality in their product.

BeelineGPS may have SBAS/SN "tick boxes", but are you sure they actually do anything? SirfTech and MM-SirfSetup *do* work with most systems, so if you can't make them work, then the Nokia probably can't be (usefully) controlled.

You'd do better to read gpspassion's comments on the (non-) usefulness of SBAS, than waste your time trying to use it. Certainly I can see no useful improvement with EGNOS here in the UK.

Even (or particularly) Carl@Sirf admits that SirfDemo does "unexpected" things because it is trying to be "intelligent". IMHO SirfTech is a much more useful application for what you're trying to do.

Cheers, Alan.
saimhe Posted - 30 oct. 2007 : 16:34:45
Regarding "Go to Top of Page", blame your browser :)

Regarding SiRFDemoPPC, I don't remember whether it was something serious, however subjectivelly it has too many bells and whistles -- whereas SirfTech does exactly what I need and doesn't strive for more.
guzya Posted - 30 oct. 2007 : 16:07:17
what do you think, why it is so difficult? Nokia use SiRF but it it not available for SiRFDemo?
BeeLineGPS is able to switch WAAS/EGNOS and Static Navigation, is it true for LW-3D or not? What should i do the check real EGNOS here in Europe and to check real Static navigation of my LW-3D?

What do you mean by "I was already disappointed with SiRFDemoPPC and chose SirfTech.
Go to Top of Page"?
saimhe Posted - 30 oct. 2007 : 13:44:07
To make the selection easier, SiRFDemoPPC only displays available ports

That's it -- despite the fact that M$'s BT stack doesn't even bother to make them "available". Does it mean that SiRFDemo developers only knew something better, like Widcomm stack? :)

On a HTC TyTN, I've seen the same problem both under WM5 and WM6. The former was compatible to some freeware port splitter application (forgot its name) that was able to create "visible" outgoing ports. SiRFDemoPPC was happy with them.

WM6 has the "External GPS" applet which does the same (outgoing ports are "visible"). However, it was too late: I was already disappointed with SiRFDemoPPC and chose SirfTech.
Leif Posted - 29 oct. 2007 : 21:05:08
I have made several debug versions of SirfTech in cooperation with various LD-3W users trying to make it able to switch to SiRF binary protocol and then be able to communicate to get and set settings but I have failed. So obviously it is too difficult for my programming ability so far.

Then if you manage to switch to SiRF and change some setting which is possible with aplsirf, I think the change is lost when the receiver is reset the next time at power off or perhaps even when changing back to NMEA.

Best Regards
Dennis Gröning
guzya Posted - 29 oct. 2007 : 15:53:33
From SiRFDemoPPC manual

Select the port that the GPS product is connected to from the Port pulldown menu.
To make the selection easier, SiRFDemoPPC only displays available ports as well as the description assigned to that port.
guzya Posted - 29 oct. 2007 : 12:59:25
What do you mean - difficult. It's possible or impossible. Are they using custom build sirf firmware?
Leif Posted - 28 oct. 2007 : 22:28:43
Nokia LD-3W is difficult to get into SiRF binary protocol for making setting changes. The aplsirf Pocket PC program is known to work with Nokia LD-3W.
guzya Posted - 28 oct. 2007 : 21:19:31
No it isn't editable, just a drop-down to choose. How could i get my port into that list?
saimhe Posted - 28 oct. 2007 : 14:47:39
in SiRFDemo there is no port 4 in a dropdown list

As a rule of thumb while working with COM ports, if programmers weren't lazy they made the list editable -- you can merely type in "COM4:" and that will work.
guzya Posted - 28 oct. 2007 : 14:38:22
I have LOOX C550 and Nokia LD-3W, so i installed SIRFDemo for PPC.
My pda and nokia are paired using com4. But in SiRFDemo there is no port 4 in a dropdown list. Only: serialcable com1, com8, com3 Infrared Port, com2 Native IR, BT UART on COM5. Check all... none of those are working.
What should i do to connec those devices?

Does Nokia uses custom build sirf firmware?

Allycat Posted - 25 oct. 2007 : 23:10:34
Originally posted by trollianer

Next time I'll read more _before_ ordering the receiver ;)


The problem is that it's almost impossible to find any information on these subtle details. One of my main complaints about this issue is that the NMEA and SiRF protocols communicate different numerical values (not just a different format or resolution), yet nowhere in any specifications will you find any mention of this.

The Holux 236 has been manufactured with at least 4 different versions of firmware (all with apparently different NMEA "threshold" speeds), yet the Holux specification has not changed. But IMHO the specification is largely nonsense anyway; for example it claims far higher accuracy in SBAS mode, yet early firmware versions didn't even support SBAS! It could be said that SBAS can be made available by upgrading the firmware (another feature claimed in the specification) but Holux have never officially released any firmware upgrades.

Thanks pyxis and Carl for your comments, but I must reiterate that this is not an issue with the gps engine (nor poor reception conditions) but occurs in the "translation" of the velocity data from the SiRF to NMEA protocol. Yet the vast majority of users will be using NMEA protocol, since many applications don't even support SiRF protocol.

Cheers, Alan.
trollianer Posted - 24 oct. 2007 : 10:22:58
Hi all,

thanks for your help and good suggestions. I still didn't find out how it could work for me so I gave up and sent it back to the store :( Next time I'll read more _before_ ordering the receiver ;)

Carl@SiRF Posted - 19 oct. 2007 : 00:48:30
Since you are seeing static nav off, and since there are cases where the velocity is reported as a null field (... ,, ...) that is clear indication that the velocity is considered unreliable at the lower speeds and therefore not reported. If we activate Static Nav, you will see the same thing in some software versions -- velocity < some arbitrary limit = unreliable, do not report. It makes detecting static nav harder!
pyxis Posted - 18 oct. 2007 : 15:06:31
See pages 3-51 and 3-52 in the PC SIRFDemo User Guide, particularly the Track Smoothing and Dead Reckoning options under the Navigation Mode. It is not clearly stated whether the Static Navigation or the Track Smoothing option is preemminent. Static Navigation is a feature that was called for by early users who did not like to see their map position indicator jitter while stopped. Wishes are not always perfect!
trollianer Posted - 18 oct. 2007 : 11:19:18
Hi Carl and AllyCat,

thanks for your replies. It can't be the reception, I also observe this behaviour with 10-12 satellites and 0.8-1.2 DOP.
Also the speed values in the RMC string are not exactly zeroed, they're completely left out, while the heading stays unchanged:
("x" inserted by me)

Unfortunately my PPC Software doesn't understand SIRF Code directly


For the record (in case someone else is searching the web for information on the same device):
To communicate with the device over bluetooth, the connection speed has to be set to 9600 baud. To switch the device to sirf mode using sirfdemo , use "Transmit Serial Message", check the "NMEA"-radiobutton and insert "PSRF100,0,9600,8,1,0" (got it from this great thread, thanks!).
If the communication is screwed up (e.g. setting the wrong baud rate) it is sufficient to remove the battery for about 15 minutes.

Allycat Posted - 18 oct. 2007 : 04:26:18
Hi Carl,

Well, the NMEA "zeroing" is still there with Holux's 3.2.4 firmware! (although with a somewhat lower threshold than in the original version). And I think I've seen it even with good GPS reception (note the other complaint at the foot of my thread, when 12 satellites are "visible").

But why is it present only in the NMEA protocol, and when (optional) Static Navigation is available to do the job properly, if the user really wants to mask "unreliable" data?

Cheers, Alan.
Carl@SiRF Posted - 18 oct. 2007 : 02:03:42
If you switch back to binary and the static nav setting is still turned off, your problem is not static nav. Under some situations the velocity will be set to zero in the reporting. These conditions are, generally, when the receiver is using less than 4 satellites, or some other type of degraded nav solution. I seem to recall some earlier versions that zeroed out NMEA velocity when it was below a threshold since velocity tends to get quite unreliable below some arbitrary limit. I checked our latest code and could not find that setting in it, but there is a nagging in the back of my head of earlier versions that did that.
Allycat Posted - 18 oct. 2007 : 00:14:53
Hi Trollianer,

I think you will find SN is off, but it's a bug/feature of the SiRF NMEA protocol (which depends on the exact manufacturer's build). Take a look at my thread below, although I never got a satisfactory response from SiRF:

If this is also your problem, then it looks as if nothing can be done, because it's embedded in the firmware.

Cheers, Alan.
trollianer Posted - 17 oct. 2007 : 23:46:20
Hi all!

After a week of reading through fora and installing tons of new software, I'm desperate.
I'm trying to deactivate Static Navigation on my Navibe GM732 Bluetooth GPS Receiver. Using aplsirf on my PocketPC or sirfdemo on my PC I can switch to SIRF mode, and deactivate SN. A status request shows, that SN is off. Also (in sirfdemo) I can see that small velocities are displayed as well as a changing heading if SN is off, both values go to zero if SN is on.
So far so good, but when I switch back to NMEA mode, I have the same problem as before, velocities below 6 km/h are not shown.
Back to SIRF Mode again the receiver seemed to have remembered my SN-setting.

Does anyone have a clue what I could do to deactivate SN in NMEA mode? Or is this receiver just not usable for hiking/geocaching?

Or else, is there a program for the PPC that translates SIRF Code to NMEA Code and writing it to a virtual COM port?

Carl@SiRF Posted - 25 sept. 2007 : 01:38:10
To Danreetz: setting up the software so its default baud rate is 4800 requires that you get a build of the software that sets that default and program it in using SiRFFlash. The battery-backed RAM holds any settings you make beyond the defaults, and that is lost when you lose the battery. The defaults themselves must be set in the software at compile time. Unless you can get your manufacturer to give you a new build, there is no other way.

Why not get a receiver without the BT to do this? Then you won't have to throw away half the package? I know the GPS is the "best" part of the unit, but ...
danreetz Posted - 24 sept. 2007 : 21:39:44
saimhe, thanks. i'll try desoldering the board, as it is not obvious where or what pin has the power/ground connections.
saimhe Posted - 16 sept. 2007 : 15:16:37
The best way to disable BT permanently is to desolder it :) (of course if the main goal is extended battery life)

Cutting power _and_ ground is also an option (input protection diodes shouldn't interfere afterwards if there is no corresponding reference voltage). If the modem is on a separate piece of PCB, it might be easier to remove the board instead.
danreetz Posted - 13 sept. 2007 : 16:48:30

I have a Holux GPSlim 240. I've managed to hook it up to my serial port by soldering some connections inside and using a level shifter.

I would like to do two things.

1. Set the default baud rate to 4800, such that removing the battery won't reset it -- I want the unit to "wake up" in NMEA mode.

2. Disable the bluetooth radio (possibly permanently). I don't use it anyway.

Can I do this using SirfDemo or SirfFlash? If not, what tools should I use?
scalor Posted - 30 août 2007 : 20:48:37
I have a mainnav mg910s bluetooth gps receiver, i have a problem , i can't switch from NMEA to sirf protocol, someone has successful to do this ?

thanks for the answer
sal.fresco Posted - 15 août 2007 : 01:17:46

Forgot to put the revision # of the board
GPSlim236 Rev B

sal.fresco Posted - 15 août 2007 : 01:12:07

The wired use is not via PC or PPC.
It is to use with a "tracker" wich will be used with my Ham Radio, in Search & Rescue operations, to track me when i'm out on the field running, etc.

The software on the tracker does not allow NMEA data at other rate than 4800. I've allready mailed the author, and he did a "special version" but with no results. So i'm back to re-programming the GPS unit.

Thanks to all that answered.


Allycat Posted - 14 août 2007 : 11:45:20
Hi Sal,

Saimhe seems to have explained the difficulty well; there are just a few comments that I can add:

I believe the firmware is actually written by SiRF and Carl has explained earlier in this (long!) thread what the serial port(s) can and cannot do.

There are at least two versions of the Holux circuit board / hardware, so your version number might be important.

Do you definitely need to run the wired port at 4800 baud? If it is for a program that runs on the PC (or PPC?) then you may be able to use "gpsgate" to convert the baud rate, as described here:

Cheers, Alan.

saimhe Posted - 11 août 2007 : 00:41:18
The following are mainly assumptions because I still am afraid to break my GR-236 by opening it the wrong way :)

Apparently the BT modem there works only at 38400, and both the modem and TTL port are wired to the same UART 0 so baudrate change is common for them -- and if the modem can't do baudrate detection like traditional telephone line modems, it won't understand anything from now on.

I know little about these modems so I'll use only BGB203 (made by Philips) as an example. This one has a dedicated baudrate change command, AT+BTURT, and settings can be preserved in internal Flash.

Provided that the modem in GR-236 can also be dynamically configured for different baudrate, the reason of "only 38400 bps" may be simple OEM laziness, that is, Holux did not add the corresponding code to the GSC3f.

The ideal scenario:

1. Open the unit and identify the modem.
2. Find its datasheet (at least the part that describes SPP operation) and confirm the possibility of baudrate change.
3. Disconnect modem's TX and RX from remaining circuitry.
4. Hook up TTL/RS232 from a computer to them (a level converter is required).
5. The modem may already accept commands while the RF link is down. Otherwise you must switch to command mode, which usually involves some software protocol or activating a hardware pin. The datasheet should explain that.
6. Play a bit with the modem according to the datasheet :)

Yes, it involves disassembly and soldering. If the modem and the USB socket are really wired to the same UART, that effectively prevents configuring the modem via the serial cable. Just look at a typical wiring solution:

BT-TX ------+
            (wired-)AND ---->-- GSC3-RX
USB-TX ---- +

BT-RX ---------+------------<-- GSC3-TX
USB-RX --------+
A permanent fix might require a couple of logic gates and some luck.
sal.fresco Posted - 10 août 2007 : 21:46:12
Hi everybody!

Sorry if this is a little off-topic, but I'n in despair.

How can I make my GPSlim 236 to work the following way:
Get NMEA data at 4800bps via the TTL/RS232 port while still get the data via Bluetooth.

I've allready managed to put the RS232 at NMEA 4800, but i've lost Bluetooth. I did it with SIRFdemo and the serial cable, using the menu
"Set UART configuration" and selected UART 0 to NMEA 4800 and UART 1 to SIRF binary at 57600.


jimmynz Posted - 02 juil. 2007 : 08:07:49
Hi all,

I would just like to draw some of your attention to this other thread instead of adding to this thread incase it was considered slightly off-topic...

Any input from Carl, GPSPassion and any other veterans in this field would be much appreciated!

Anglepoise Posted - 12 juin 2007 : 21:48:27
Thank you very much Carl
Carl@SiRF Posted - 12 juin 2007 : 01:45:44
If you just run SiRFDemo you are not going to have any problems. Connect it to the receiver, set the expected baud rate and see if you see data either in the Debug view window (if the receiver outputs NMEA), or in the signal, map and radar views (if in SiRF binary mode). If you get "comm: CE_FRAME" or similar in the error view window, your baud rate is set wrong. Click on the first icon (one that looks like a gear wheel) and select another baud rate. Keep this up until SiRFDemo matches your unit. All of the above is safe.
Anglepoise Posted - 12 juin 2007 : 01:04:10
Quick question from a New Member.
I have Pharos iGPS-500 receiver hooked up to my laptop.

I run marine mapping software and S&T. Is it safe for me to run Surf demo
just to see how my receiver is working. I have read that , push the wrong button, can disable
the receiver etc, etc.
Carl@SiRF Posted - 11 juin 2007 : 22:41:30
Sorry for your troubles. I can only guess what is going on. Some manufacturers do not apply battery backup voltage, except for connecting the primary power to that pin when the system is turned on. In that case, when you power down, after a very short time when the filter capacitor bleeds off, you lose all changes. If that is the case, the only way to fix things is to modify the hardware, something I never encourage anyone to do as it would void your warranty with the manufacturer. Sorry!
Lukappaseidue Posted - 11 juin 2007 : 17:18:35
:( It seems a nightmare!!!!
Ok Carl, it seems that my GPA isn't able to store the modify I've done.
This is what happen:
Connected sirfdemo to my GPS (strings appear)
type the string of above in "Action menu AT Transmit Serial Message" NEMEA
Ok Gps is linked
then I change the value of SBSSrc from none to SBAS thenm after just one minute, I Clich on EXIT to close sirfdemo.
Now the GPS is locked.. I can't do anything. I can't switch off the GPS, the only thing to do is remove battery and then modify go away.
Ok. I do all the thig of above again but at the after changed to SBAS, i go to action and then to SWITCH to NMEA protocol and ... "Error.... as my first post"...... This is the only way to store changhes to the GPS...
After some days of non use, I switched on my GPS, and even battery is charged, SURPRISE, SBAS is become none...


Excuse me Carl, but You are my only help
Thank you as always.
Regards Luca
Carl@SiRF Posted - 07 juin 2007 : 01:00:10
When you send a command to the receiver to change some default (examples: change the protocol, baud rate, message output rate, SBAS setting, static navigation setting, etc.) that change is automatically saved in BBRAM, assuming it is such a variable. (All the settings I just mentioned are such variables.) In reality, it is saved 2 places: in RAM from which we operate, and in BBRAM. The saving in RAM is immediate, but the updating of BBRAM may take a couple seconds, longer if something significant is taking place that has a higher priority. So when you make a change, give the receiver a few seconds before you yank power. Otherwise, when the receiver comes alive again you will find the old setting reappearing.

And it might be worthwhile to reiterate something I have written before about SiRFDemo: it is just a tool that communicates with the receiver over a serial line and displays the normal output messages from the receiver. But it does do things you don't expect. For example, if you call up a menu to change some setting, SiRFDemo sends a message to the receiver to learn the current setting of that parameter. If you open a log file to record receiver operations, it sends two messages to the receiver to query the software version and the navigation parameter settings. There are many things that it does you are not necesarily expecting, so be careful. If you are not careful SiRFDemo will change things without you expecting it. A review of this topic's history should point out a few of the "features."
Lukappaseidue Posted - 06 juin 2007 : 23:58:27
Thank You very much again Carl@SiRF
Ok I set back to 8
The question about closing SirfDEMO is following:
After I connect to my antenna and configured the waas egnos sbas option, what have I to do to store changes into BBRAM?
Have I only to click on "SEND" a nothing more?
Have I to un-flag the "OPen Data Source"?
I've seen that sometimes i can't switch off the GPS, I must remove battery and sometimes, when I try to connect flagging "Open Data Source" I don't need to type Your string as the connection is just established (?).
Any way, now I'm very very happy to have buyed a SiRFSTAR 3 GPS and I'm very happy to have known You Carl.... thank You very much!!!
Carl@SiRF Posted - 06 juin 2007 : 20:58:11
Great news that you are doing what you want. One MAJOR correction: that 8 in the message I gave you is the number of data bits, not the port number. Apparently we didn't accept the 6 so it was ignored, but set that back to 8!

Why didn't your setting stay after you removed the battery? We have something called Battery-Backed RAM (BBRAM) where we store user settings. Anything like that which you change goes into BBRAM. As long as you keep battery power, we remember your setting. Remove the battery, we forget and revert back to the settings built into the software.

You asked about closing SiRFDemo: if you mean the log file, then click on the diskette icon you used to open it. If you really want to close SiRFDemo, just click on the X in the upper right corner of the window like you would any other window. Or you can select 'Exit' from the Setup menu. But you won't hurt anything by just closing the window with the X icon.

GPS time is very close to UTC or Greenwich Mean Time. It actually differs by about 14 seconds at present (GPS doesn't implement leap seconds like UTC does -- discontinuities in navigation systems are highly discouraged). I have seen customers implement local time zones, but the basic system does not, so you get either UTC or GPS time, not local time.
Lukappaseidue Posted - 06 juin 2007 : 18:46:35
Stupid question
Why the GPS time isn't the same of my country time? there are 2 hours over
Lukappaseidue Posted - 06 juin 2007 : 17:11:39
This is what Sirfdemo log file show me:
SiRFDemo Version 3.83 log file opened 06/06/07 17:05:07
SiRFDemo Build Date: Feb 16, 2005

Tx PC Time=1181142307.972
Tx: 0xA0A2000284000084B0B3
Tx PC Time=1181142307.982
Tx: 0xA0A2000298000098B0B3
SW Version: GSW3.2.4Pat2_3.1.00.12-SDK001P1.00
Ack: MID_PollSWVersion
Polling Navigation Parameters
AltMode: auto
AltSource: last KF alt
Altitude: 0
DegradedMode: TThenD
DegradedTimeout: 0 s
DRTimeout: 10 s
TrkSmoothMode: disabled
StaticNav: enabled
3SV LSQ: enabled
DOPMaskMode: disabled
ElevMask:5.0 deg
PwrMask: 12 dBHz
DGPSMode: auto
DGPSTimeout: 18 s
Continuous power enabled
User tasks disabled
MaxAcqTime = 120000 ms; MaxOffTime = 30000 ms

Ack: MID_PollRxMgrParams
GeoNav PC Time=1181142308.499

Tx PC Time=1181142311.067
Tx: 0xA0A2000298000098B0B3
Polling Navigation Parameters
AltMode: auto
AltSource: last KF alt
Altitude: 0
DegradedMode: TThenD
DegradedTimeout: 0 s
DRTimeout: 10 s
TrkSmoothMode: disabled
StaticNav: enabled
3SV LSQ: enabled
DOPMaskMode: disabled
ElevMask:5.0 deg
PwrMask: 12 dBHz
DGPSMode: auto
DGPSTimeout: 18 s
Continuous power enabled
User tasks disabled
MaxAcqTime = 120000 ms; MaxOffTime = 30000 ms

Log file closed 06/06/07 17:05:19

I've seen that when I remove the battery del DGPSSrc become again NONE.
I think that I'm not be able to store the changes to the antenna.
AM I wronging?
Lukappaseidue Posted - 06 juin 2007 : 16:30:39
Carl@Sirf YOU ROCK!!!!!!! YOU ARE GREAT!!!!!!
Ok I've done as You said.
I connect data source selectinf com 6 and 9600 baudrate
So I Go to "Transmit Serial Message" at Action menù
Entered PSRF100,0,9600,6,1,0 at NMEA format adn then SEND (I've changed the 8 You suggested to 6 as my free com port)
For First time I've seen all tha data displayed..... and so I've seen that my GPS firware is 3.2.4 and EGNOS WAS disabled...
I go to "NAVIGATIO" and then DGPS Source and than activated SBAS ENGOS .....
Everything works fine
Only one question.
I've tryed to set "Switch to NMEA Protocol" ma always the same error fo above!
Anyway the change has been stored (Or better It seem so)
I've just checked after removed battery and It seems that SBAS was NONE again, perhaps must I close sirfdemo right?
Many many thanks
P.S.: what is the right step to close the SiRFDEMO
Carl@SiRF Posted - 04 juin 2007 : 23:34:48
I'm going to let the experts elsewhere on this site answer the Bluetooth questions. Let me speculate on what is happening with the receiver.

When you tell SiRFDemo to change to SiRF protocol, it specifies the baud rate without giving you a chance to control it. That may do one of two things: the reciever may try to comply, or it may reject the message. However, SiRFDemo changes its baud rate to the one it commanded the receiver to use. As noted many times here, many Bluetooth modems only accept one baud rate as the input (often 38400). If you tell the receiver to go to 57600 (common in "switch to SiRF protocol" commands), and if the receiver tries to comply, you will potentially lose contact with the receiver as it is talking at a rate the modem doesn't accept. Time to remove the backup battery and let the BBRAM go dead!

If the receiver either ignores the command, or switches to SiRF protocol without changing baud rate, the result is that the receiver works just fine, but at a different baud rate than you are listening. Probably not what happened since you appear to have lost the ability to find the receiver at any baud rate.

If you get everything working again and want to try again, don't use that menu button "switch to SiRF protocol." Instead, use the Action menu option "Send Serial Message." That gives you a menu screen where you can compose your own meny without SiRFDemo trying to interpret things or changing itself. In the lower-left corner, select NMEA format. That will allow SiRFDemo to put in the $ and the checksum, <CR> and <LF> for you. Then enter this command in the message box:


In the above example, I specified 38400 baud. If that is not the right rate, substitute what is (9600, 19200, etc.). Then click on SEND. You should already be at the baud rate you specify (should be able to see what that is on the top bar of the SiRFDemo window), and SiRFDemo won't change its baud rate as it doesn't try to interpret that hand-entered command. Hopefully that will get you to SiRF protocol without losing the receiver.
Lukappaseidue Posted - 03 juin 2007 : 18:16:54
Hi folk,
I'm writing 'cause I've a great problem to connect my HAMLET GPS HBTGPS20 (SiRF 3 20

channels) to Sirfdemo latest version.
This is what I've done.
S.O. Windows XP PRO SP2 or VISTA
disable Antivirus and Firewall (NOD32 and ZoneAlarm)
Bluetooth dongle (blutonium BCM2035 model BTU02D)
Installed the BT dongle (GPS is viewed and linked with passkey 0000)
Windows shows that the bluetooth dongle have two com port; the N.6 COM OUTCOMING and n.7 COM

Installed the sirfdemo ver. 3.83
Starded Sirfdemo and selected COM 6, and baudrate (from min to max rate).
selected "Connect to data source" and soon Sirfdemo shows a lot of strings at Debug View
Then I go to Action and try to Switch to SiRF Protocol....
The display freezes for just one second or less and soon a pop-up show Error.. Cannot create

UART handle....... ect.ect.
I've tryed all the baudrate setting, but always the same errors.
So I try the n. 7 COM. and after entering sirdemo, I see that Switch to SiRF Protocol is

greyed out and I can select Switch to NMEA Protocol....
What Can I do to link my GPS to SiRFDEMO?
I want to enable ENGOS / WAAS SBAS end see which is my installed firmware release.
May thank to everybody in advance..
PLease, HELP ME!!!!!
Carl@SiRF Posted - 02 juin 2007 : 02:04:12
Hi All,

Sorry for the delay in answering everyone -- vacation time!

I saw some comments on software versions vs. chip types. Early versions like 3.1.1 were specific to the chip they supported. But as the later chips have been added, we try to merge the software so one build supports all chips. 3.2.x supports one-chip and 2-chip versions as long as the 1-chip version is GSC3. After 3.2.4 came out, we introduced the GSC3LT and GSC3LTi one-chip versions, and they are not yet merged. But you aren't likely to see those chips in consumer models -- they are targeted to cell phones.

Ken asked about clock drift and what else can cause a long TTFF. The fact that your clock drift is not exactly 96.25 kHz simply means your crystal is not exactly 16.369 or 24.5535 MHz. Since crystals are typically not exact, that is normal. Further, over temperature and time they vary, so if you see 94 kHz today, you might see 94.1 kHz tomorrow -- again normal. So if the long TTFF is not caused by crystal frequency, what else might it be? Hard to say without log files to analyze. There could be something keeping the receiver from seeing strong enough signals. For example, if there is a jamming source nearby, or if the receiver's antenna and LNA aren't together giving a strong enough signal. See if there is a way to see C/No. For example, if using NMEA, look for the GSV message. If C/No is not at least 27 dB-Hz we won't trust the data being downloaded, and it can take multiples of 30 seconds to capture missed data.

The questions on SiRFDemoPPC: the latest version is always available on, so check there. The install file is pretty large, like 10 MB, because not only is there an assortment of .DLL files to spread around, but there is also the loader itself. I'd like to see those files much smaller, but I think with the way the installer works we are stuck with what we have. Sorry.
accumulator Posted - 30 mai 2007 : 17:42:20
Thanks. I followed the link you provided, tried out CEMonitor, which was mentioned as a potential fix, and found that it was unable to see the COM port where the GPS is connected. So, unless there are other options, I'm going to just leave the thing unplugged for a week or more and give it another try. Oh, well.
Leif Posted - 30 mai 2007 : 10:34:07
Sounds very much like the problems of cristianomc and leifur with SD-502 in this thread:
I think the explanation is that SD-501 and SD-502 only supports one baudrate much like Bluetooth units. Then when setting the SiRF chip to another baudrate you are lost.
Dennis Gröning
accumulator Posted - 29 mai 2007 : 20:24:45

I recently picked up a SDIO-based unit from USGlobalSat. It's the SD-501, SIRF-II XTrac (version I plugged it into my HP Ipaq 2215, and while running SIRFDemo, I accidentally put the thing into SIRF binary mode.

At that point, my Ipaq immediately lost communication with the unit, and I haven't been able to re-establish communication. At all. SIRFDemo "automatic" speed detection doesn't find it, and I've tried (manually) to select every possible communication speed from 4800 to 38400 to 57600...

Since none of that worked, I left the thing unplugged / completely unpowered for 4.5 days. Still no luck; it powers up, the status LED behaves appropriately (solid initially, then blinking to indicate fix) but it won't talk to the Ipaq - or at least, I can't figure out how. Any suggestions? Anyone? I just want it to go back to speaking NMEA...

I also tried SIRFTech, but still had no luck in getting the unit to go back to NMEA. SIRFTech appeared to be uncertain of the protocol the unit was speaking, because it showed -- for protocol in communications window.
thaigps Posted - 29 mai 2007 : 09:04:53
Originally posted by einstein-a-go-go

I'll try and explain a little bit clearer.

After sending a Switch to Sirf Protocol via SurfDemo or otherwise, all communication stops on all baud rates, but also the GPS Receiver Green LED (flash - fix, steady - no fix) goes out.

Solution to fix this, is to short out pins, remove battery for 24 hours.

Sending a cold reset, does restart comms, and doesn't resume NMEA mode.

I remouve battery and short circuit the battery pin in the PCB. Now everything is OK again thanks for this useful tread.

Thanks for any help
Squaredancer Posted - 18 mai 2007 : 23:08:05
Thanks for the list Saimhe. I am going to copy it and file it away in case I ever need to use it.

In today's design environment, I don't know why they didn't use the "sandbox" technique, so all their files would be in one place.
saimhe Posted - 18 mai 2007 : 13:22:43
Originally posted by Squaredancer

After installation, the disturbing thing is that in searching, I could only find 1 folder in Main Memory/program files called SiRF. That folder only has a 380K executable in it. I don't have any idea where the rest of the 10Mb is located. My guess is that they are scattered thru the Windows, and Windows System directories.

I was able to determine file sizes and names only; target directories remain unknown (MSI installers are cryptic compared to good ole' _setup.xml). Try searching for these.

389120	SiRFDemoPPC.exe
195584	mirasteru.dll
207360	MXintl50.dll
20480	SPOT.RHD
18432	HALO.RHV
159232	TIFF.RHL
3756544	MAPX50.DLL
39936	MapXADODS.dll
25600	MSafeArrayDataset.dll
1561	MapInfow.fnt
12	\Program Files\MapInfo\MapX Mobile\GeoDict.dct
62976	MasterRes.dll
328704	MiDlg50.dll
30208	MiDlin50.dll

The total amount is a bit less, 5410 KB.
Squaredancer Posted - 17 mai 2007 : 22:05:56
Hi Carl,
I have downloaded SiRFDemo for PPC, Version 1.16 and love it. This seems to be the best place to make suggestions and get questions answered. The main question is, IS This the Latest Version?

Comments: I had major problems installing it because of the size. It also seems to try to force me into installing it in Main Memory as opposed to putting it on the Storage Card. Since the setup file is 10 MB, that means there has to be greater than that free in Main Memory, because it will store it in a temp file until it expands it and installs it in it's preferred location. After installation, the disturbing thing is that in searching, I could only find 1 folder in Main Memory/program files called SiRF. That folder only has a 380K executable in it. I don't have any idea where the rest of the 10Mb is located. My guess is that they are scattered thru the Windows, and Windows System directories. The biggest problem with that is, if my uninstall file gets corrupted (which has happened many time), I will be stuck with 10 MB of "orphaned" DLL's. At that point, the only way to clean the PDA would be a hard reset and re-installation of all the files. I'd suggest to the developers, that the next revision put all dll and other files WITHIN the SIRF directory, and also allow the installation on a Storage card.

I mentioned of the difficulty I had installing it. To get it installed, I had to REMOVE a number of programs from the PDA (Verizon XV-6700), so the Main Memory would have enough free space to expand and install the files. Additionally, I can't reinstall some of those apps because SIRFDEMO take up so much space. Eventually, I may have to uninstall it (and hope the uninstall file works), just to give me more space. I would really hate to do that because I do like the program.

Thanks for listening, and I hope that you will pass this on to your software team.

Allycat Posted - 10 mai 2007 : 14:42:19
Hi ron2000uk,

It looks as if gpsgate (on PC) could solve your problem. It's mainly intended for splitting COM ports, but also seems to convert baud rates if required. You can try before you buy:

Cheers, Alan.
ron2000uk Posted - 10 mai 2007 : 14:16:46
The thing is:
I want to connect it to PC via cable and BT to a PDA at the same time!
It can do that right now with no problem if I use other software on the PC that can accept NMEA at 38400.
But the special application I want to use only accept "standard" 4800.

So may be I have to look for another GPS that can do what I want, be it not a sirf3.
Any one lese has any idea?
Allycat Posted - 10 mai 2007 : 12:41:53
Hi ron2000uk,

I believe the 3.2.x firmware is intended for different (single-chip) hardware, so Holux don't want to risk loading it into the earlier (two-chip) hardware. Some people have returned their 236s to Taiwan to be exchanged for a later version with 3.2. firmware.

My 236 was also upgraded with the firmware from Holux UK, so we probably have the same. I've now connected my 236 to PC via a serial cable and the results are rather strange. It makes me wonder if Holux have a clue what they're doing (see also my "faulty data" thread).

As far as I can see, the wired port is locked at 38400 baud, but the BT port runs at any standard baud rate. And if you use a BT command to change to SiRF protocol (I used SirfTech), then the wired port also changes to SiRF protocol (still at 38400 baud). However, I cannot be sure that I sent the correct NMEA baud rate command via the wired port. I entered the following data in the "send serial message" facility in SirfDemo, but got no response:

So, ron, your best solution might be to use a USB-BT dongle on your PC. However, if your application only accepts 4800 baud, then it might not support the higher port numbers usually associated with BT drivers.

Cheers, Alan.
ron2000uk Posted - 09 mai 2007 : 18:13:56
My understanding of or v.3.1.1... is that they are the srif chip firmware which is not changeable?
I think mine is something like 3.1.1 (have no access to it at the moment). It is over a year old.

I did use the firmware on the UK Holux site to update my 236 to v5, and that is the firmware which can be updated and performing such update is recommended by everyone.

No matter what I did with it (through SirfDemo) it can only communicate to a PC at 38400 baud at NMEA mode, and no other.
Allycat Posted - 09 mai 2007 : 17:47:28
Hi ron1000uk,

We really need a special thread for Holux GPSs as there seem to be so many issues, particularly with the 236 (or are they just the most popular). But here are a few quick answers:

What is the firmware version of your 236? I believe those with firmware use different hardware, which may be your problem. Mine is v.3.1.1... I really don't recommend changing the firmware, but you may still find my v3.1.1 here (although Holux UK are no longer trading):

I haven't needed to bother myself with the NMEA commands to change baud rate, as "it just works" at any baud rate (e.g. using Memory Map). Perhaps this is because BT GPSs use the "outgoing" port (i.e. from the PC/PPC), so the comms are under the control of the PC. However, I did have some problems connecting to the Holux, until I found the correct drivers (or BT stack) to use with the BT dongle on my PC.

As Carl has said several times in this thread, SirfDemo sometimes sets baud rates that are different to those selected, or wanted, so I recommend using something else. Here is the URL for SirfTech, where you will also find a link to the SiRF NMEA Reference Manual, which includes the command to switch baud rate in NMEA (100-SetSerialPort):

Cheers, Alan.

KenAdam Posted - 09 mai 2007 : 08:42:18
Originally posted by Carl@SiRF

In a SiRFstarIII receiver, the receiver's speed and the use of 0.5 ppm TCXOs (Temperature Compensated Crystal Oscillator)means that the number is not going to make much difference.
with GSW3 software, you cannot input that frequency, and can cause problems if you try.

Thanks for the reply.
The Loox has GSW3 software, but I find that the clock value (on the sample I'm testing - the others are deployed) settles at about 94.4kHz rather than the default 96.25kHz. This seems to be the only detectable difference after a switch on (from PDA completely off) compared to a "cold start", and in this case the GPS takes 2-5 minutes to get a fix.
If it is unlikely to be the clock drift that is extending the TTFF, what else would you suggest I look at?
I'm also trying to understand what we need to look out for in selecting a replacement PDA/GPS device.
ron2000uk Posted - 09 mai 2007 : 04:33:37
Thank you Alan.
I am sure the only remedy is a change of firmware with defuat baud at 4800. But where can I find this firmware? Holux does not seem to encourage such change.
I have been using USB cable with a PC to try to change the baud rate without success. Are you saying that it can be done via BT with a PDA? with which SirfTech software?

I have not tried using NMEA (send NMEA in SirfDemo) text to change the port baud rate. Would it be more reliable than using the change NMEA baud in SirfDemo? What exactly is the text I should put in?
As for hyperterminal, once again is it more reliable than using send NMEA sentence in SirfDemo? and what is the command?

Thank you in advance.

Originally posted by Allycat

Hi ron2000uk,

There are a number of Holux 236 firmware versions in circulation (which bears on my problem in another thread), and two hardware versions (two and one-chip solutions), but certainly my Holux 236 runs at 4800 baud (NMEA and SiRF). Also, at most baud rates from 1200 up to 38.4k (and I even risked 57.6k NMEA which seemed ok), all via BlueTooth to my PC. Perhaps this wide range of baud rates is why Holux's seem rather more prone than some other GPSs in getting stuck in SiRF mode, or even never-never land.

So the 236 seems to meet all your requirements, but the data on the BT and wired ports is identical. Have you tried selecting NMEA 4800 baud via the BT PDA (I prefer the SirfTech application) and then "listening" on the wired port? Or setting the baud rate on the PC using another application (maybe just Hyperterminal)?. For my trial above, I used Memory Map.

Cheers, Alan.

Allycat Posted - 09 mai 2007 : 04:09:15
Hi ron2000uk,

There are a number of Holux 236 firmware versions in circulation (which bears on my problem in another thread), and two hardware versions (two and one-chip solutions), but certainly my Holux 236 runs at 4800 baud (NMEA and SiRF). Also, at most baud rates from 1200 up to 38.4k (and I even risked 57.6k NMEA which seemed ok), all via BlueTooth to my PC. Perhaps this wide range of baud rates is why Holux's seem rather more prone than some other GPSs in getting stuck in SiRF mode, or even never-never land.

So the 236 seems to meet all your requirements, but the data on the BT and wired ports is identical. Have you tried selecting NMEA 4800 baud via the BT PDA (I prefer the SirfTech application) and then "listening" on the wired port? Or setting the baud rate on the PC using another application (maybe just Hyperterminal)?. For my trial above, I used Memory Map.

Cheers, Alan.
Carl@SiRF Posted - 08 mai 2007 : 23:05:15
I see being away lets those questions stack up. Sorry, I've been busy.

Clock drift (the proper name) is directly related to the frequency of the GPS crystal. In a SiRFstarIII receiver, the receiver's speed and the use of 0.5 ppm TCXOs (Temperature Compensated Crystal Oscillator)means that the number is not going to make much difference. But in SiRFstarII, running standard GSW2 software, the manufacturer can use a simple XO (uncompensated crystal oscillator). Over temperature, those can vary by as much as 12 ppm. Add in an initial frequency offset (crystals aren't perfect), and aging, and the frequency search to find a satellite can take minutes rather than seconds. In those cases, saving the last frequency from binary message ID 7 and restoring it using input message ID 128 can save lots of time. But if you have XTrac software or SS3 with GSW3 software, you cannot input that frequency, and can cause problems if you try. So verify what you have first. Simply poll the software version with SiRFDemo and look at the output. GSW3 will say that; GSW2 may also say that, but the version number will start as 2. followed by more numbers. If you have XTrac, it will either say XTrac in the number, or there will be an X.

For baud rate changes on that Holux, I wouldn't go there. Most of the Bluetooth modems require a fixed baud rate into them, and the manufacturers typically block any baud rate changes to the receiver so you don't lose contact with them. Looks like that is what Holux has done.
ron2000uk Posted - 08 mai 2007 : 10:29:53
May be Carl or other technical guru can answer my queries.

I have a Holux GPSlim 236, and also a newer 240.
These BT GPS also have wired output which I can use to connect a PC simitaneously with BT to a PDA.

One prolbem I have is that my PC application accepts only 4800 baud and these Holux output only at 38400.

I have been trying to use SirfDemo to change the GPS NMEA output buad to 4800 without success. I could change the baud to 4800 while in sirf mode by changing the main serial port. But I could not get it to change the NMEA to 4800 and it always resulted in crashing the PC when I tried to do that.

Is possible? If yes, how?
If not possible with the Holux, is there any other BT GPS that meet my requirement? which are:
1. BT GPS with Sirf III chip.
2. Wired output at 4800 baud (RS232 or TTL), similtaneously with BT.
with optional requirement:
3. replaceable battery
4. external antenna connection (this is handy as I do a lot of tests indoors).
5. A physical on/off switch - whitout which problem may occur if I connect only with cable and not BT.

The Holux GPSlim236 seems to meet all my requirement except that I have been unable to change the baud rate to 4800. Would it require a change of firmware (the manufacturer one, not sirf)? I had not been able to obtain any answer from Holux Taiwan.
KenAdam Posted - 24 avr. 2007 : 13:00:26
Probably a question for Carl:
We are using Fujitsu Loox N520 devices as field navigation tools, but some users will turn the PDA off completely (rather than "sleep").
When they switch on (reboot, restart app) the GPS takes "15 minutes" (they claim, more typically 6 minutes in my tests) to acquire.
I've been experimenting with SiRFDemo and SiRFTech, and it seems to me that the difference between this and a (SiRFDemo invoked) Cold Start is that the Clock Offset has been lost and reset to 96250Hz (presumably because the N520 has no backup battery). (In both cases the RTC and backup position are shown as invalid).
The question is: Could we speed this up by storing the clock offset outside the GPS and forcing it in after power on? If so, how recent would it have to be? (i.e. how much would it vary over time/temperature for a given chip).
I'm wondering whether we could have a one-off calibration procedure for new devices to establish their typical clock offset and just store that or would we have to grab it very frequently to be of any use?
(I realise it would be preferable to recalibrate the users, probably with the aid of a baseball bat, but that is not an option).

Is there anything else I should be looking at or changing with SiRFDemo that might help me track down what the issue is (assuming I'm wrong about he clock offset)

I hope you are able to provide some data on this, since otherwise I'll be spending many happy hours checking this value on a sample set of PDAs under different conditions.....

Leo Starrenburg Posted - 16 avr. 2007 : 18:05:16
My Holux GR-213 is dead as well, I set it to 'User 1 protocol' and now it's waiting forever for a non-existant command.

Checking the Holux user manual gives:
1/ "an up to 500h back up battery" (3weeks)
2/ "not using your receiver for a month will give loss of all data"

So I will be patient and wait for a month to see if it will reboot(?) and start sending and receiving data again, hopefully by that time I'll know what to do.

regards, Leo.
Carl@SiRF Posted - 12 avr. 2007 : 18:01:00
The documentation shows that value 01 means to do a hot start and that all the other fields are valid. Actually, bit 0 means that the data in the message are valid, while all the other bits relate to things like "ensure that ephemeris is invalidated" or "don't trust the RTC." The binary protocol manual for message ID 128 does a much better job showing how the bits are really interpreted -- I recommend that you use that. Even though it is not stated explicitly, the reset configuration byte in MID 128 and in NMEA 101 are the same.
ndharris Posted - 12 avr. 2007 : 12:31:29
Originally posted by Carl@SiRF

No, it should not.

Carl, final 2 questions (I hope):

1. Is there an NMEA output message that will indicate the chip is in deep search mode? We are not sure how to decide when to send the message.

2. According to the SiRFmessages.pdf documentation, the reset options are 1, 2, 3, 4 or 8. 0 is not listed but this is what you have suggested. I just want to make sure that you meant 0, and not perhaps 1 (which is a hot start)?

Thank you for your time. Neil.
Carl@SiRF Posted - 11 avr. 2007 : 22:15:49
No, it should not.
ndharris Posted - 11 avr. 2007 : 20:18:43
Originally posted by Carl@SiRF

Any should work, but I recommend: $PSRF101,,,,,,,12,0 (that is a string of 7 commas). This does a simple restart without changing anything internally.

Thank you Carl. If we are move to a firmware version later than 3.1.1, will this workaround be necessary at all?
Carl@SiRF Posted - 11 avr. 2007 : 20:14:27
Any should work, but I recommend: $PSRF101,,,,,,,12,0 (that is a string of 7 commas). This does a simple restart without changing anything internally.
ndharris Posted - 11 avr. 2007 : 19:53:08
Originally posted by Carl@SiRF

1. Versions after 3.1.1 (we are currently supplying 3.2.4) fix this issue.
2. Sending a restart command (binary message 128, NMEA message 101) terminates the deep search and allows fast recovery.


Thank you for the information. Are you saying that sending a 101 message will fix the problem on firmware version 3.1.1? If so, exactly which 101 message? - there are several to choose from! We would like to send the message that will allow the chip to continue tracking with the least possible recovery time (e.g. a hot start if possible). We would also like to be able to pass such a message without having to know the current gps time, last known position or any other data - is this possible? We are running in NMEA mode.

Regarding versions beyond 3.1.1, I am assuming it will not be necessary to send a 101 message, and that the deep search issue is no longer present. is this the case?

Thanks, Neil.
Carl@SiRF Posted - 11 avr. 2007 : 19:32:17
1. Versions after 3.1.1 (we are currently supplying 3.2.4) fix this issue.
2. Sending a restart command (binary message 128, NMEA message 101) terminates the deep search and allows fast recovery.
ndharris Posted - 11 avr. 2007 : 10:02:03
Originally posted by ndharris

Originally posted by Carl@SiRF

Guillaume is correct. The issue has been addressed, at least in part. There will likely be more changes in that area as we keep refining how we do things. But the overall fix for receivers that have 3.1.1 software is simply to cycle power.

Carl, is there any update regarding this? We are experiencing the same "deep search" problem (device takes up to 30 minutes to recover from a lost fix when left on indoors). We embed your SiRF III into our device, and cycling the power on our device will not cycle the power on the SiRF chip because it is still connected to the batteries. Have you guys released a software fix to the problem, and if so, what version?

Thanks, Neil.

Hi all,

Has anyone found how to take SiRF III out of "deep search" without cycling the power? Surely there must be a fix/workaround to such a critical issue?

Thanks, Neil.
Carl@SiRF Posted - 11 avr. 2007 : 00:02:26
We do have versions that output binary and NMEA on the same port at the same time. Can you capture the version string (Poll menu, Poll S/W Version)? I would be very surprised if you actually have one of those versions, though. I am going to guess that you have a unit with some "customization" in the software that has hosed it pretty good.
ShawJohn Posted - 09 avr. 2007 : 15:23:11

Well I've got the strangest thing happening now...

It outputs Sirf at 57600 still, no matter what! But if I change to NMEA mode using SD then it starts outputting NMEA data at 38400, BUT still carries on outputting Sirf data at 57600 at the SAME TIME!

I cannot change the baud rates on either protocol.

My GPS programs will now work on either protocols though, AT THE SAME TIME!

Has anyone experienced this before?
ShawJohn Posted - 06 avr. 2007 : 19:20:57
Right, I'm sick to death of this now so I just got medieval with the case and my dremel... It was glued shut :(

I tried to remove the battery and the top just fell off it, the insides of the battery look all chared and sooty, anyway the battery mno longer function anymore :D I made sure of that ;)

So how long is it likely to need powered off to reset he chip?

Its in the freezer wrapped in cling film now to speed up the disharge process :)
ShawJohn Posted - 06 avr. 2007 : 18:40:51
It does seem to perform a reset though... Just not a full one for some reason.

It clears all the sat data, just doesn't reset the protocol :(
ShawJohn Posted - 06 avr. 2007 : 18:37:51
I tried both of those methods, each time sirfdemo changes to the new settings and I get the following error messages:


These repeat over and over until I change the main serial port info back to 57600, then it all starts reading Sirf data again :(

I had a quick read of the sirf manual and apparently it should output some message that it was unable to carry out the command and it isn't doing.

I know I can rip the fecker open and remove the battery but all attempts to do this without trashing the case have failed!
Carl@SiRF Posted - 06 avr. 2007 : 18:16:29
Using SiRFDemo, go to the Action menu and select Switch to NMEA Protocol. You will get a menu to set message rates and baud rate. If that doesn't work for some reason, on the Action menu open the Initialize Data Source menu, and on that menu, select Factory Start in the lower-left corner, then SEND. Watch in the Response View window for the ACK of your command. If instead you see NAK, something has gone wrong with the command, or the receiver is unable to comply.

Final option: find a way to remove the battery long enough to kill BBRAM.
ShawJohn Posted - 06 avr. 2007 : 17:49:17
I have a Holux GR-213 GPS mouse which after some tinkering in SirfDemo (3.75 & 3.81) will no longer receive commands and will only output Sirf Mode at 57600.

It makes no difference if I factory reset it.
All this does is clear the sat. data, it continues to output Sirf Mode regardless.

My problem is that most of my GPS software is NMEA only... The only reason I ever put it into sirf mode was to turn on Track Smoothing, now its stuck there!

I've had a try at opening the case in order to try out removing the backup battery, but it looks impossible to gain entry without trashing the case :(

Could I send a binary message to reset it back to NMEA? If so what is the command?

I have tried contacting Holux both in TW and UK with no luck and no responses :(

Can anyone help?
frder Posted - 01 avr. 2007 : 13:59:21
Originally posted by ricfranz

When I try to connect my Gps BT receiver, after activating BT on Com 7, I receive this error message:
Cannot create UART handle.
Com port is not avalaible or is nt in use.

What can I check to resolve?

Pannello di Controllo->Dispositivi Bluetooth->Periferiche
Select your GPS BT device listed in "Tutte le altre periferiche"
check if "Porta Seriale (SPP) Serial Port" is activated and which is the associated COM Port
Check if there are other applications using that Com Port
Try to connect with Sirfdemo at all the possible Baud rate.

ndharris Posted - 31 mars 2007 : 20:58:15
Originally posted by Carl@SiRF

Guillaume is correct. The issue has been addressed, at least in part. There will likely be more changes in that area as we keep refining how we do things. But the overall fix for receivers that have 3.1.1 software is simply to cycle power.

Carl, is there any update regarding this? We are experiencing the same "deep search" problem (device takes up to 30 minutes to recover from a lost fix when left on indoors). We embed your SiRF III into our device, and cycling the power on our device will not cycle the power on the SiRF chip because it is still connected to the batteries. Have you guys released a software fix to the problem, and if so, what version?

Thanks, Neil.
ricfranz Posted - 31 mars 2007 : 17:36:46
When I try to connect my Gps BT receiver, after activating BT on Com 7, I receive this error message:
Cannot create UART handle.
Com port is not avalaible or is nt in use.

What can I check to resolve?
Carl@SiRF Posted - 30 mars 2007 : 19:18:49
Periodically, SiRFDemo will query the receiver for various settings (typically during log file collection). MID_Nak means that the receiver was unable to comply with the request. Typical reasons why it would NAK are 1) incoming message failed parity, 2) some field of the incoming message had invalid data, 3) the receiver was not in a position to comply (e.g., receiver was asked for data that does not exist in that type of software).

I can only speculate on what you are seeing here, as I haven't seen it before. This has the feel of a receiver that is overloaded with some internal user task, running right near the limit for capabilities, and that whatever the incoming message is, it puts things over the limit and the system crashes. A second possibility (although symptoms don't quite match expected) is that this receiver has a demonstration copy of premium software that has reached its preset life.

Suggestion: Open SiRFDemo, open a log file, then connect to the receiver, then apply power to the receiver. You should be able to log everything in this setup. When the crash occurs, you should have a record of what message was sent to the receiver. It will be logged in hex, but you can decode it using the binary protocol manual.
admin_0 Posted - 30 mars 2007 : 05:58:01
I am currently setting up a USGlobalSat ET-102 for GPS research (logging the CNo/50bps data over time specifically) using SiRFDemo 3.83 to test it during the setup phase. However, it seems to have some serial communications problems. Using the manual baud rate changing trick in this thread removed various CE_Errors and it successfully navigates in NMEA and SiRF Binary mode upon powering up, reporting satellites and signal strength and calculating a fix.

However, after 30 seconds-1 min SiRFDemo reports "Rejected:MID_Nak" errors in the Response window and stops navigating (signal, map and radar go blank). Resetting the receiver either by cycling power or pulling the reset pin low causes it to begin navigating again for the same short length of time. In addition, logging incoming navigation messages does not work and polling is very slow.

Is there any reference for the cause of the MID_Nak error (I tried these forums and Google with no results) and do you think this is a SiRFDemo issue or a problem with the receiver HW/Firmware?

einstein-a-go-go Posted - 29 mars 2007 : 00:41:32
Thanks for your reply.

I think the answer here, is don't purchase hokey cokey 9000 units from Taiwan, and purchase a well known brand, but I've also seen well known brands that also don't support Binary Sirf Data. So it looks like "some companies" are trading on Sirf's Good name to sell product!

and the result is the end user willpay the price.

Thanks for your time Carl.

off to purchase a real Sirf Binary GPS...

I assume the real mcoy Tom Tom GPS is!
Carl@SiRF Posted - 29 mars 2007 : 00:36:12
The tracking and navigation algorithms are still 100% SiRF, as is the hardware. The only flaw is that your manufacturer chose some of the settings for you and didn't trust customers enough to allow them to change things. I don't know UK law, but here in the "colonies" I don't think you would get too far in court ...
einstein-a-go-go Posted - 29 mars 2007 : 00:32:11
Carl - Thanks for your prompt reply.

So how can you tell if the Sirf III Chipset GPS you are purchasing has a "full implementation" of the Sirf III Protocol to configure? i.e. turn off/on static navigation for use with walking and running, these GPS's would be of no use or not accurate (not fit for this purpose). But okay for vechile tracking Tom Tom etc

It's a little misleading to the end user, purchaser, for the Seller to advertise Sirf Chipset logos all over the product, only to find, it's not 100% Sirf!

In the UK, this is mis-representation of the product I believe.

Carl@SiRF Posted - 29 mars 2007 : 00:17:50
You are right -- simply switching protocol does not cause loss of fix. However, they may have removed SiRF protocol and not removed the command to switch (I've seen that done more than once). Solution: don't switch protocol! I know that leaves you without abilities to change parameters, but that is manufacturer's choice.
einstein-a-go-go Posted - 28 mars 2007 : 20:01:34
I would have throught that Switching to Sirf Protocol, would still cause it to retain GPS fix, and continue sending Sirf data, although you may have the wrong baud rate selected.
einstein-a-go-go Posted - 28 mars 2007 : 19:59:52
I'll try and explain a little bit clearer.

After sending a Switch to Sirf Protocol via SurfDemo or otherwise, all communication stops on all baud rates, but also the GPS Receiver Green LED (flash - fix, steady - no fix) goes out.

Solution to fix this, is to short out pins, remove battery for 24 hours.

Sending a cold reset, does restart comms, and doesn't resume NMEA mode.
Carl@SiRF Posted - 28 mars 2007 : 19:01:24
SiRF protocol is simply a communications protocol. Yes, customers of ours can disable it, but few do. I am not sure what you mean when you say you can still send cold resets. Either you have communciation with the receiver or you don't. And there is no reason the receiver should work in NMEA mode and not in SiRF binary protocol. If you can talk to it in binary protocol, send it a factory reset command with SiRFDemo and you should restore all default settings.

einstein-a-go-go Posted - 28 mars 2007 : 16:53:20
I've spent the last few hours, reading the 29 pages on very helpful information from Carl, I used to work in the Martime Industry, when GPS receivers were coming into the market in the Late '80s (replaced Decca and Loran C recivers in the UK!).

I have a question for you Carl, I've just picked up a few "clone" Taiwan Sirf III Chipset receivers YTEC-GPS-1210s, (FCCID: TJU-GPS-1210),

If I switch it to Sirf Mode using SirfDemo or any terminal program or my comms application, it appears that the receiver dies.

The flashing fix (green led), doesn't light or flash anymore. I can still send cold resets to the device.

Only shorting or waiting 24 hours wakes up the device.

Can OEMs remove the sirf protocol.

So this is not quite a fully implemented Sirf II Chipset? How does the Sirf protocol/command set function?

Is this just a case, of the GPS not intializing correctly, when sent the command to run the Sirf protocol.
NoSmoke Posted - 28 mars 2007 : 02:42:36
Originally posted by Carl@SiRF

SiRFstarIII firmware can support SBAS if the manufacturer chooses for it to do so -- it is his choice with conditional compiles in the code. To determine if your receiver supports SBAS, try turning it on (DGPS Source = SBAS). If it starts tracking an SBAS, it is enabled.

OK, thanks for the clarification. I tried as you suggested and nothing new was shown in the DGPS view so I guess S&T did not enable it (for some reason).
Carl@SiRF Posted - 28 mars 2007 : 00:51:47
SiRFstarIII firmware can support SBAS if the manufacturer chooses for it to do so -- it is his choice with conditional compiles in the code. To determine if your receiver supports SBAS, try turning it on (DGPS Source = SBAS). If it starts tracking an SBAS, it is enabled.

From the looks of the SiRFDemo screen, it appears that corrections have not been learned yet from PRN 126. State 2D means that we have code lock, but not carrier phase lock on the signal (may be normal) and that we do not have an ephemeris from it (may also be normal). It can take some time to get corrections from an SBAS -- parts of the corrections are only broadcast every 5 minutes, so have patience. Be sure to leave the system in Test mode, not Integrity, as EGNOS is still sending test messages on all birds, and any test message means that satellite is in test mode. We won't use it if we are set to Integrity.
denti13 Posted - 28 mars 2007 : 00:13:33
Hi all,

Need help to understand why SBAS correction is not applied in my config.

Have a Sirf 3 with firmware GSW3.2.2_3.1.00.12-SDK003P1.01a.

Read lot of information in GPSpassion but not found answer.

Set DGPS correction to SBAS. Set SBAS parameter to PRN126/Integrity/Default (tried also PRN126/Testing/Default and other EGNOS)

Any ideas viewing my screenshot : >> LINK <<
NoSmoke Posted - 27 mars 2007 : 05:57:16
I have posed this question on another thread, and elsewhere, with opinions but no definitive answer received yet. Perhaps someone here(Carl?) could respond:

"Was wondering if my SiRF III receiver that came bundled with S&T 2007 can be WAAS enabled and, if so, can it be enabled using SiRFDemo?

TIA for any information...."

Laurie Forbes

GpsPasSion Forums © 2002-2015_GpsPasSion/Manzanite Go To Top Of Page
This page was generated in 2,05 seconds. Powered By: Snitz Forums 2000 Version 3.4.05