Google
  Web www.gpspassion.com


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

www.NaviBlog.com



Versions

Links/Liens




Portal/Portail
Rechercher

- -

Polls/Sondages
Sondage
Pour vous guider sur la Route :
GPS Mobile (SEM)
GPS Intégré
Smartphone
Autre
Voter  -  Résultat des votes
Votes : 1952




Club GpsPasSion
Soutenez le site!

USA: (US$)
EUROPE: (€)
Guide Paypal


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

 All Forums
 Advanced Topics
 General Technical Discussions
 SiRFdemo tutorial (static navigation)
 New Topic  Reply/Répondre
 Printer Friendly
Previous Page | Next Page
Author Previous Topic Topic Next Topic
Page: of 39

Carl@SiRF

USA
159 Posts

Posted - 08 mars 2006 :  22:14:56  Show Profile  Reply with Quote
The error message you see regarding SRAM control flags simply means that the battery backup voltage has been lost. So that means we need to do a full factory restart (when you lose BBRAM you lose the crystal frequency -- not a big issue with SS3). That also means the receiver lost its last position and the current time, so it can't predict which satellites are visible, and when it finds one it can't give an az/el. All of this is normal when BBRAM is lost, so nothing diagnostic there.

The fact that you can only get 18 to 24 dB-Hz signal strength means two things: 1, that you can't download any data from that satellite -- signal strength must be at least 27 dB-Hz for us to do that; and 2, that either the satellites you have seen so far are really obscured or your receiver has a problem with the RF front end, like loss of the LNA. So if you are in open sky and no SVs are seen with reasonable (above 30 dB-Hz) signal strength, I would suspect problems in the RF section.

Carl - SiRF Customer Support
Go to Top of Page

frankz

6 Posts

Posted - 08 mars 2006 :  22:28:43  Show Profile  Reply with Quote
Now I see my BT-338 receiver has identified 5 satellites and has acquired elevation data for all of them. It also sync'ed the GPS clock after picking up the fifth satellite. No azimuth information, though. And no fix, of course.
Francesco
Go to Top of Page

frankz

6 Posts

Posted - 08 mars 2006 :  22:42:34  Show Profile  Reply with Quote
Thank you for the information, Carl. Since the receiver has a view on the open sky and the sky is clear, following your advice I must suspect too that my receiver has a RF problem. I think the best thing to do for me now is to stop playing with SiRFDemo and contact the manufacturer for a repair under warranty.
Again, thank you for your time and insight.
Francesco
Go to Top of Page

Carl@SiRF

USA
159 Posts

Posted - 08 mars 2006 :  22:57:01  Show Profile  Reply with Quote
Francesco,

Good luck with the repair. Note that during a startup like you are seeing, when the receiver reports elevations but no azimuths, the numbers you see are artificial, put there simply to arrange the satellites on the Radar View display.

Carl - SiRF Customer Support
Go to Top of Page

whmwhm

USA
14 Posts

Posted - 11 mars 2006 :  14:23:33  Show Profile  Reply with Quote
I've tried using the latest (3.81) version of SirfDemo to enable WAAS on a GlobalSat BT-338, but the program repeatedly freezes (ie not responding) after issuing a command regardless of the baud rate I select. My PC is a Dell Inspiron-6000 with built-in Bluetooth. If anyone knows a fix to this frustration, I would appreciate the advice.

Thank you.
Go to Top of Page

Carl@SiRF

USA
159 Posts

Posted - 13 mars 2006 :  17:51:08  Show Profile  Reply with Quote
I suspect your receiver is native NMEA output. Unless the software was prepared specially, when you change to binary it tends to want to go to 57600 baud, and with Bluetooth that is death. I think you are going to be unable to ever change that receiver to binary.

Carl - SiRF Customer Support
Go to Top of Page

admin_0

1 Posts

Posted - 14 mars 2006 :  00:23:33  Show Profile  Reply with Quote
We need carrier data for a precision displacement system for a guidance application. We have a system that works well with Garmin 35, extendable to Garmin 18, but for compatibility with other projects would prefer to use SiRF. Better still would be to embed our computation inside a SiRF engine.

Where is the 'split' in the SDK, as far as access to parameters and variables in the navigation computation are concerned?

Cheers

John



quote:
Originally posted by Carl@SiRF

Carrier phase is definitely measured in the GSW3-based receivers (that is the only software you will normally see in a SiRFstarIII receiver; the alternative is only used in embedded applications like cell phones), and it is used in the position fixes. But it is not output in Message ID 28. The choice was made to make that available only as a premium product, meaning that it would require an additional license at additional cost. If you have a specific requirement for that data, you need to contact your SiRF sales representative.

Carl - SiRF Customer Support

Go to Top of Page

Carl@SiRF

USA
159 Posts

Posted - 14 mars 2006 :  01:05:39  Show Profile  Reply with Quote
Whatever data comes out is available in the SDK for customer access through the API (application program interface). With respect to nav parameters and the likes, much is available as well. But carrier phase is still not accessible in the standard code. Anything that is blocked in binary output is blocked in the API as well. Other that that, you can access results of the nav, raw pseudoranges, raw 50 bps data, etc.

Carl - SiRF Customer Support
Go to Top of Page

saimhe

Lithuania
135 Posts

Posted - 14 mars 2006 :  13:22:37  Show Profile  Reply with Quote
quote:
Originally posted by Carl@SiRF

during a startup like you are seeing, when the receiver reports elevations but no azimuths, the numbers you see are artificial

I recently discovered that XTrac 2.0.2 reports negative elevations sometimes during startup, for example "-3" regardless of usual range, "00"..."90". Is this documented in recent versions of NMEA Protocol Manual? It isn't in the Revision 1.3.

Edited by - saimhe on 14 mars 2006 13:23:49
Go to Top of Page

MikeAngel

Bulgaria
2 Posts

Posted - 14 mars 2006 :  14:27:29  Show Profile  Reply with Quote
Hello all,
I just bought from Taiwan the latest (I've been told) holux GPS rceiver: MODEL: GPSlim236b. It paired with all my bluetooth devices, laptop, pda, N70 and it worked fine.

On the laptop it automatically detected COM ports 11 as Outgoing HOLUX GPSlim236 "SPP Slave" and COM 12 as Incomming HOLUX GPSlim236. I tried to connect it to SiRFDemo on use COM 11 baud rate 38400 and 9600 and 4800 but it always gave me error when trying to open data source "Error... Cannot create UART handle. Comm port is not available or may be in use" I tried to connect to port 12, and there was no error, but when I opened the data source there was no information. The protocol was automatically switched to SiRF, but I still could not read anything from the device. When I try to switch to NMEA, the SiRFDemo just stops responding. When I tried to initialize the receiver with Factory Reset, SiRFDemo again stops responding. Any ideas why I can't connect?

Thanks
Mike

Edited by - MikeAngel on 14 mars 2006 16:07:30
Go to Top of Page

MikeAngel

Bulgaria
2 Posts

Posted - 14 mars 2006 :  15:57:35  Show Profile  Reply with Quote
Just to add to my previous post,after the above described "playing around" with the SiRFDemo, now when I connect the GPS to my N70, the power navigation tool and bluesky tools (simular functionality like GpsViwer) detect the GPS coordinates, obtain 3D fix, but can't display the individual satellites signal level.Still the apps read the GPS signal as a good level and it still works receiving the coordinates while moving.

Could I have done something wrong while playing with SiRFDemo ? Then only actions were to try changing to NMEA and initializing the receiver. Thanks in advance.

Edited by - MikeAngel on 14 mars 2006 16:06:00
Go to Top of Page

Carl@SiRF

USA
159 Posts

Posted - 14 mars 2006 :  17:22:53  Show Profile  Reply with Quote
For Saimhe:
During startup, if the receiver knows its last position and the current time, it can predict where satellites are located in the sky (warm start). It then searches for both satellites expected to be visible and for some not expected (those with negative elevation). That way if you had hopped on an airplane since you last navigated with the receiver, it could still find enough satellites to get a new fix. Regarding NMEA spec, it has always been very flexible. For elevation, the only limitation is "90 degrees maximum." It specifies the field as "xx" which translates to "Fixed length field of numeric characters," and which is further modified by a note "A negative sign "-" is the first character in a Field if the value is nagative. When used, this increments the specified size of fixed length fields by one. The sign is omitted if the value is positive." So reporting negative elevations is normal and permitted. I don't have NMEA specifications prior to version 2.00, but from 2.00 through 3.01 these definitions have not changed.

Carl - SiRF Customer Support
Go to Top of Page

Carl@SiRF

USA
159 Posts

Posted - 14 mars 2006 :  17:39:27  Show Profile  Reply with Quote
For Mike Angel: Congratulations on your new Holux receiver. Because others on this site have much more experience with setting up PCs to talk on Bluetooth than I do, I'll limit my comments to what you might have done to the receiver. Since you have a Bluetooth interface in the receiver, I am going to assume that the interface between the receiver and the Bluetooth modem must be at a fixed baud rate (38400 is a common rate). When you change protocol on the receiver, either you specify the baud rate (when going from binary to NMEA) or it is to a default value (when going from NMEA to binary). "Beyond here there be dragons!" Specify the wrong baud rate and the receiver follows your directions (unless Holux has blocked this option and forced baud rate to always be the same) and you lose communications because the modem no longer follows the interface change. Second problem: SiRFDemo has a "smart" interface that is automatically changed to what it expects a receiver to do. If you use it to send a factory restart, and if SiRFDemo knows you are using a SiRFstarIII, it will assume the receiver will go to 57600 baud, the "factory default" setting. Surprise! Your receiver probably goes to 38400, and you lose communications. By simply telling SiRFDemo to go to 38400, all is well. Similarly, if Holux has blocked baud rate changes, when it receives a command to go to NMEA at a different baud rate it can either reject the message (by sending back a NAK message, message ID 12) or it can accept the message and ignore the specified baud rate. In the latter case, the receiver would switch to NMEA, but stay at 38400 baud rate, while SiRFDemo would switch to whatever rate you specified. Again the fix is simply to change SiRFDemo's baud rate.

After playing around, did you do something to block satellite signal levels? Probably. When switching to NMEA, you specify message rates for all the various NMEA messages. Signal levels are part of NMEA GSV message. When you specified message rates, be sure that one is set to 1 second update rate. The default in SiRFDemo is 5.

Carl - SiRF Customer Support
Go to Top of Page

whmwhm

USA
14 Posts

Posted - 14 mars 2006 :  19:52:23  Show Profile  Reply with Quote
quote:
Originally posted by Carl@SiRF

I suspect your receiver is native NMEA output. Unless the software was prepared specially, when you change to binary it tends to want to go to 57600 baud, and with Bluetooth that is death. I think you are going to be unable to ever change that receiver to binary.

Carl - SiRF Customer Support



Carl,

I'm a newbie so bear with me. Was your response a reply to my question . . . reprinted here:

I've tried using the latest (3.81) version of SirfDemo to enable WAAS on a GlobalSat BT-338, but the program repeatedly freezes (ie not responding) after issuing a command regardless of the baud rate I select. My PC is a Dell Inspiron-6000 with built-in Bluetooth. If anyone knows a fix to this frustration, I would appreciate the advice.

If so, tech support at USGlobalsat recommends SirfDemo to adjust parameters on their BT-338 (Bluetooth) GPS, so I'm not clear as to why the program locks up everytime I issue a command. I set the baud rate to 38400 when the source is opened. Why would the speed change to 57600?

Thank you.
Go to Top of Page

Carl@SiRF

USA
159 Posts

Posted - 14 mars 2006 :  20:40:09  Show Profile  Reply with Quote
If GlobalSat recommends using SiRFDemo to adjust parameters, then it is almost certain that they have set up the baud rate properly. Then the issue is with SiRFDemo. SiRFDemo was set up to be a tool for SiRF internal use in many aspects, and it has some built-in smarts. If it learns that it has a SiRFstarIII attached, it knows that the default baud rate for a SiRFstarIII in binary mode is 57600. So when you switch to SiRF binary, SiRFDemo sends the command to the receiver, then switches itself to 57600. Since the receiver is programmed to stay at 38400, or whatever baud rate the BT interface needs, you lose communications. There are a couple of solutions: manually switch SiRFDemo to the right baud rate (click on the icon just below the Setup menu, the one that looks a bit like a yellow gear wheel and select the baud rate you want, then reconnect to the port), or (if the baud rate is 38400) tell SiRFDemo you really have version 2 software: click on the Setup menu, select Target S/W and then select 2.3. Since SiRFstarII software defaults to 38400 baud in binary (unless you turn on debug messages), if SiRFDemo thinks you have a SS2 it will go to 38400 when you go to binary.

Carl - SiRF Customer Support
Go to Top of Page
Page: of 39 Previous Topic Topic Next Topic  
Previous Page | Next Page
 New Topic  Reply/Répondre
 Printer Friendly
Jump To:
GpsPasSion Forums © 2002-2014_GpsPasSion/Manzanite Go To Top Of Page
This page was generated in 2,16 seconds. Powered By: Snitz Forums 2000 Version 3.4.05