| Versions |
  |
|
| Author |
 Topic  |
|
Carl@SiRF
USA
158 Posts |
 Posted - 18 mai 2006 : 18:11:09
|
The issue I think most of you are seeing is caused by a combination of SiRFDemo (SD) and the receiver software. SD was not designed for general usage, but rather as a tool for SiRF to demonstrate receivers to customers and to help us in our development. To make things easier, it has some built-in "intelligence" (others will dispute that word) that jumps up and bites you now and then. When you tell SD to switch protocol to SiRF binary, it assumes the receiver will go to either 38400 or 57600 baud, depending on the software version it is dealing with. When the receiver has been configured to go to some other baud rate, SD appears to get lost. When you manually send the baudrate command, SD doesn't analyze what you composed, so it stays at its present baud rate and all is well. There are many more little "features" like that in SD that cause it to do things you aren't expecting. Again, they are there to make SD a useful tool for us rather than a general purpose utility for everyone.
General rule: if you see garbage characters or comm errors reported, SD is probably at a different baud from the receiver. The recovery is either use the Synchronize Protocol and Baud Rate command in the Action menu, or manually search among the baud rates with SD until you find the match.
Carl - SiRF Customer Support |
 |
|
|
Russel
Australia
49 Posts |
Posted - 18 mai 2006 : 19:00:32
|
Carl,
I think the most odd thing about SirfDemo is that it simply doesn't have a window showing what *it* actually sends. That would probably solve a lot of problems. My background is in industrial control and several upcoming projects happen to use gps (as a small part of the system). Hence I have no formal relationship with Sirf and no access to their developer materials. And this isn't the only occasion that SirfDemo hasn't shown off the best side of their products. Yes.. I know. give customers enough rope and...
Btw.. did you notice the question I posed you in the other thread on the sirf nav message? :-)
|
|
|
|
Carl@SiRF
USA
158 Posts |
Posted - 18 mai 2006 : 19:22:45
|
SiRFDemo does not have such a window, but I agree, if it were a development tool that would help. Want to know what SD sends to the receiver? Open a log file and then do your thing. When done, the log file will show you lines like Tx: A0A2 ... showing exactly what was sent to the receiver.
Send me a link to the question you posed and I'll see if I can answer it.
Carl - SiRF Customer Support |
|
|
|
Russel
Australia
49 Posts |
Posted - 18 mai 2006 : 19:31:47
|
The link is this one:
http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=54336
If you like, you can send me an email. (Your profile has no contact details).
:-)
Incidentally the offending unit when it dies, cannot be talked to at any baud with any type of terminal, and yes, on further testing, it dies whenever I try to change it to anything over 38400, even using other software. Fortunately pulling the battery is an easy fix.
|
|
|
|
Leif
Sweden
141 Posts |
Posted - 18 mai 2006 : 22:02:22
|
quote:
Originally posted by Carl@SiRF
When you tell SD to switch protocol to SiRF binary, it assumes the receiver will go to either 38400 or 57600 baud, depending on the software version it is dealing with.
I think you are wrong there. According to the SiRF NMEA Reference Manual there is no command to change protocol from NMEA to SiRF binary without specifying which baudrate to switch to. Instead it must be SiRFDemo who switches the receiver to SiRF at whichever baudrate it sees apropriate for the version it is dealing with.
So if SiRFDemo switches the receiver to 57600 baud, the Bluetooth link is still expecting 38400 baud and receives "garbled" characters. There is no way to recover. The SiRF chip listens at 57600 baud which the Bluetooth driver cannot relay without garbling characters.
To handle this situation gracefully the Bluetooth link should have to be very clever. Either listen to transmitted NMEA and SiRF commands and if a command to change baudrate was discovered it should change it's own baudrate accordingly. Or scan different baudrates and settle when correct SiRF or NMEA frames are detected.
Or the SiRF firmware should have been modified not to accept baudrate changes when connected through a fixed baud communication link.
The same problem should be for any, in between, byte oriented communication driver with limited baudrate selection.
I suspect Globalsat SD-502 SDIO GPS to have similar problems. See leifurh's and cristianomc's posts http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=39968&whichpage=5.
|
Edited by - Leif on 18 mai 2006 22:17:36 |
|
|
|
Carl@SiRF
USA
158 Posts |
Posted - 19 mai 2006 : 00:01:39
|
You are partly right. SiRFDemo uses the presumed software version of the receiver (either input by operator, or learned from a Poll S/W Version message, or in the absence of either, presumed to be one of the GSW2 versions) and composes the message with that baud rate in it. It then switches itself to that rate. But if the receiver is a Bluetooth unit, there is a good chance the manufacturer set it up to ignore the baud rate in the protocol switch message, and the receiver should stay at 38400 or whereever. If the manufacturer forgot that little step ...
Carl - SiRF Customer Support |
|
|
|
dantexas
3 Posts |
Posted - 19 mai 2006 : 06:40:19
|
| I've finally bit the bullet and removed the battery. Sure enough, it reset my receiver, which is now recognized again, and got a fix in a minute or so. thanks all for your help. I learned not to play with things that i don't understand.... |
|
|
|
codor
Yugoslavia
3 Posts |
Posted - 29 mai 2006 : 11:02:05
|
Hello everyone,
I am new to this forum which looks great. We are using a custom developed hardware (based on Lantronix Dstni) which uses FALCOM JP10 GPS receiver. To be able to check what is going on with GPS positioning, we designed simple serial pass-thru software on Lantronix CPU (what comes in from PC is passed to GPS and vice versa). With this we are able to communicate with GPS using SIRFdemo and NMEA.
Problems appear when we try to use SIRFdemo to switch to SIRF binary protocol -> cannot do that (we manage that via terminal software by issuing NMEA command to switch to SIRF binary).
Once we have SIRF binary as active protocol, SIRFdemo is working properly and shows all information. However, we are not able to issue any command to GPS receiver (poll menu). LED on our hardware shows that something is sent to the GPS receiver but there is no related response (for example, poll command to get navigation parameters does not return in response view the expected MID 19).
Falcon GPS receiver has the following firmware version: GSW3.1.0-SDK_3.1.00.07-C24P.00
SIRFdemo version 3.81
Any ideas what could be the reason for this?
Thanks all. |
|
|
|
codor
Yugoslavia
3 Posts |
Posted - 29 mai 2006 : 12:08:56
|
quote:
Originally posted by Russel
Is there someone who can give the definitive explanation regarding baud rates, bluetooth and Sirf versions?
Hi Russel,
Try using serial port monitor PORTMON by www.sysinternals.com. It's a low level device driver with UI front end (can monitor tx/rx).
When you check SIRFdemo log file, you will see that SIRFdemo (when switching to SIRF binary) reconfigures a baud rate to 57600. This is clear why it is not working (if you used different baud rate before switching to binary).
However, when poll nav params is sent, correct SIRF binary telegram is sent and it does not have anything to do with baud rate but there is no response from GPS receiver with nav params data. Why is that?
|
|
|
|
gpspassion
93392 Posts |
Posted - 29 mai 2006 : 21:53:06
|
I was going to suggest baudrate problems, but since you can't send instructions in SiRF mode either, seem to go deeper than that. The SW3.1.0-SDK_3.1.00.07-C24P.00 might be at fault, don't remember seeing that version actualy, maybe on the first Holux 236 run, all the current systems run on 3.1.1, maybe you can get Falcom to upgrade it for you.
_________________________________________________________________________
Discounts and Assistance/Réductions et Assistance (Club GpsPasSion) / Où commencer? |
|
|
|
codor
Yugoslavia
3 Posts |
Posted - 02 juin 2006 : 09:16:15
|
| An update to previous problem. We implemented the code (on Lantronix CPU) to switch to SIRF binary protocol and then use polling commands and it works properly. Baud rate is 38400 bps. |
|
|
|
admin_0
1 Posts |
Posted - 19 juil. 2006 : 09:47:36
|
Hi
Has anyone gotten SiRFDemo to work on a BT-74s (generic brand)?
Once I've opened the data source, I get information showing up in 'debug view'. But when I try to switch to SiRF protocol, all the windows go blank and the GPS stops working. I need to remove the battery and short the terminals for it to work again.
All I want to do is enable static navigation. Is there some way I can do this?
Thanks |
|
|
|
gpspassion
93392 Posts |
|
|
frder
Italy
45 Posts |
|
|
gpspassion
93392 Posts |
Posted - 20 juil. 2006 : 01:23:30
|
Good find, that rings a bell, Wondeproud possibly ? I suspect the problem might be to switch at its "native" BT/GPS baudrate, 38400 might work.
_________________________________________________________________________
Discounts and Assistance/Réductions et Assistance (Club GpsPasSion) / Où commencer? |
|
|
|
Topic |
|
|
|
| This page was generated in 0,86 seconds. |
 |
|
- 
- 
SiRFdemo tutorial (static navigation)
