GM251+ met Cetus

[star]

Ik ben geen techneut maar een enthousiaste palmgebruiker. Volgens mij is er wel iets aan de hand, maar ik snap niet wat. Gaat mijn pet te boven.
Test gedaan buiten in de tuin: NMEA Mon 2.0 melde 4 satelieten, de GPS meter van RMcN gaf er 3 aan. Cetus versie 1.0 zegt: GPS receiver unknown en geeft geen fix. Versie 1.1b13 erop gezet, zegt No GPS detected.Tomtom werkt gewoon.
Test gedaan in de auto (op de accu): resultaten gelijk, echter Cetus geeft ongeveer 1 minuut lang een weergave van een 3DFIX (die voor zover ik kan bekijken klopt), die vervolgens verdwijnt. Kijk ik bij GPS dat staat er weer hetzelfde, unknown.

Wie weet wat er aan de hand is?

[patrickl]

Hebben jullie dit al gemeld bij de programmeur van Cetus? Blijkbaar doet hij iets met de seriele poort waardoor de GM-251 op hol slaat. Misschien kan hij meer vertellen.

De keuze voor "no fix", 2D fix en 3D fix wordt overigens gemaakt door de GPS. Niet door Cetus. De GPS geeft dat door in het GPGSA bericht.

Van de RandMcNally GPS weet ik bijvoorbeeld dat de DTR pin op de seriele poort aan moet staan om de GPS in te schakelen. Waarschijnlijk heeft de Holux GM251 ook zo'n soort mechanisme. Maar dan met een andere pin ofzo. De RandMcNally schakelt ook na een minuut uit als de DTR niet aan blijft.

De software kan verder gewoon geen invloed hebebn op de kwaliteit van de GPS ontvangst. Het kan niet zo zijn dat je in DigiMap met 1 satelliet kunt navigeren en met Cetus nog met 10 niet. Of dat de signaalsterkte zou afnemen ofzo. De software stuurt die GPS niet aan. De GPS stuurt alleen maar data naar de PDA.

Ik denk dat je het toch iets meer in de electronica hoek zullen moeten zoeken. En het eneige wat mijn dan logisch lijkt is dat er iets op de seriele poort moet gebeuren met signalen.

Bijvoorbeeld als je van programma wisselt dan gaat zeker de seriele ppoort uit. Als je dan een programma start wordt de seriele poort weer gereset. Daar zien jullie dan blijkbaar ook iets van terug op de GPS. Dat het GPS signaal na 1 minuut wegvalt is ook wel heel toevallig.

Je zou er eigenlijk een keer een kabeltje tussen moeten hebben en dan een break-out-box ertusen dat je kunt zien welke RS232 signalen van belang zijn.

Overigens dat unknown GPS krijg ik ook bij Cetus. Ik weet niet of Cetus uberhaupt wel eens de GPS herkent. Bij mijn GPS (RandMcNally en Holux GM-82) werkt het verder wel.

[star]

Dank voor het uigebreide meedenken.
Zoals gesuggereerd heb ik het issue inmiddels ook aan Kjeld doorgegeven. Als ik antwoord krijg, zal ik het zeker laten weten.

Als ik iets met poorten (?) moet uittesten heb ik meer instructie nodig, ben mijn pet nu kwijt voor zover ik die al had.

[Rudy]

Dat de soft geen invloed op de ontvangst van de gps heeft, zou kunnen, alhoewel we dat niet zeker weten, serieel is bidirectioneel, maar laat ons ff aannemen dat dit zo is. FEIT IS , dat er iets verandert , telkens bepaalde handelingen op de palm gebeuren, refresch / bepaalde software, gaat het lampje op mijn holux stoppen met knipperen. Het is reproduceerbaar, dus vrij duidelijk. Misschien is het het hoog of laag zetten van een dtr of zo, kan zijn, maar er is iets dat invloed heeft op de gps.
Ii ben van plan de seriele connectie naar buiten te brengen van de holux, dan lees ik de seriele statussen wel eens uit met de laptop, en dan weten we weer ietsje meer.
Rudy

[patrickl]

Je blijft het niet vertrouwen hè, Rudy Serieel is inderdaad bi-directioneel, maar je kunt een GPS bijna niet sturen. Er zijn wel wat configuratie boodschappen, maar niet in NMEA. Het enige dat je kunt sturen naar de GPS (in NMEA) is:
- de GPS aanzetten door de tekst ASTRAL te sturen (alhoewel dat eigenlijk nooit meer hoeft)
- de GPS een startpositite geven met $PRWIINIT,V,,,5217.7660,N,00450.7000,W,,0.0,M,0,0.T,*4C

Wat de GPS dan terugstuurt is iets als:

$GPGLL,5217.2242,N,00449.6816,E,121427.383,A*38
$GPGGA,121427.38,5217.2242,N,00449.6816,E,1,03,3.3,00000,M,,,,*2D
$GPRMC,121427.38,A,5217.2242,N,00449.6816,E,00.0,000.0,110601,03,W*5F
$GPGSA,A,2,29,02,20,,,,,,,,,,03.3,03.3,*16
$GPGSV,3,1,10,11,85,142,41,20,54,235,46,29,41,066,42,14,34,055,*7A
$GPGSV,3,2,10,07,24,312,48,31,21,171,,02,14,279,51,01,07,184,*76
$GPGSV,3,3,10,21,04,060,,25,04,107,,,,,,,,,*7C

Hierin zie je:
- de coordinaten (GPGLL/GPGGA/GPRMC)
- dat het een 2D fix is en dat er 3 satellieten in gebruik zijn (GPGSA/GPGGA)
- 10 satellieten in zicht en de bijbehorende signaal ruis ratio's (GPGSV)

Bijvoorbeeld op deze pagina staat een uitleg van de NMEA berichten.

Je kunt het een beetje zien als een uitzending op TV. Als ze de gevallen lottonummers opnoemen kun je aan die nummers ook niets veranderen. Je kunt eigenlijk alleen je TV aan of uit zetten.

Maar inderdaad een kabeltje ertussen zou handig zijn. Dan kun je echt zien wat er gebeurt. Ik zal zo anders nog wel even kijken wat Cetus doet met de RS232 signalen op mijn RandMcNally.

[Rudy]

Hey Patrick, natuurlijk blijf ik volharden, ik geloof wel wat jij zegt, maar hoe verklaar je dan het gedrag van de holux?? zoals ik zei, er is IETS, maar ik weet ook nog niet wat, misschien zelfs interferentie of iets dergelijks, dat zou ook kunnen.
Rudy

[patrickl]

Er is uiteraard IETS. Daar heb ik zelf ook wat sugegsties voor gedaan. Ik geef alleen aan dat je het niet in de NMEA communicatie hoeft te zoeken en dat het ook niet mogelijk is dat DigiMap een betere GPS kwaliteit levert dan andere programma's (Cetus even daargelaten)

Ik kreeg het gevoel dat jij het idee had dat je een GPS ontvanger nog kunt sturen vanuit de software. Ik probeer dus aan te tonen dat de software via normale communicatie geen invloed heeft op de kwaliteit van de GPS.

[r. dohmen]

Citaat:

Oorspronkelijk geplaatst door patrickl
Ik probeer dus aan te tonen dat de software via normale communicatie geen invloed heeft op de kwaliteit van de GPS.

En daar is geen speld tussen te krijgen. Overigens Patrick, werkt de init-string ook voor de RandMaNally's?

Overigens, dat "iets" zou misschien kunnen zitten in de manier waarop een GPS de coordinaten bepaalt uit de radiosignalen. Het is een bekend fenomeen dat kleine variaties in de start- of meetwaarden grote gevolgen kunnen hebben voor de oplossing van vergelijkingen.
Dat de coordinaten behoorlijk fluctueren als er nog geen fix is, is daar misschien een aanwijzing voor.

Als er een fix is, helpen de meetwaarden "vanzelf" mee om een oplossing te geven in een stabiel gebied (=klein, weinig veranderend). Vandaar - denk ik - dat het slim is om in een programma als Cetus steeds aan te geven dat je alleen ge-fix-te coordinaten wilt gebruiken.

Dat zou een wiskundige verklaring voor het fix=stabiliteit-gevoel kunnen zijn.

[patrickl]

De init string werkt juist voor de RandMcNally's. De Sirf II chipsets in de Holux hebben zo snel een fix dat eje het verschil waarschijnlijk niet eens zou bemerken. Ze hebben ook meestal een batterij aan boord en dan onthouden ze het zelf wel een tijdje. Alhoewel de RandMcnally ook een soort geheugen lijkt te hebben (merkte ik bij mijn laatste test). Ik kon bij herhaald snel na elkaar een fix bepalen geen verschil zien. Was altijd iets rond de 20 seconden.

Ik ben nog steeds een keer van plan om de init tijden te meten als de GPS langer uit staat. Dat is alleen een nogal langdurige test. De GPS moet dan steeds een lange tijd uit staan en je moet hem dus ook niet nodig hebben in de tussentijd. Uit zo'n test zou je het verschil kunnen zien tussen wel of geen init.

Met de init beinvloed je overigens alleen de snelheid van de fix. Niet de nauwkeurigheid. Een foute init kan niet zorgen voor een fluctuatie in de coordinaten. Dan duurt het alleen eventueel wat langer.

Je krijgt voor zover ik weet ook alleen maar coordinaten als je een fix hebt. Als je naar de output van de GPS kijkt dan zie je eerst alleen GSV berichten en pas als je een fix hebt komen de andere berichten (met de coordinaten) binnen.

Je kunt wel een GPS hebben die zelf, bij verlies van de fix, nog een tijdje zelf de coorinaten doorberekend op basis van de laatste locatie, richting en snelheid. Het is inderdaad de vraag of je daar wat aan hebt. In de Cetus tracks zet ik inderdaad ook die no-fix log uit. Maar dat heeft eerlijk gezegd geen enkele invloed op de log van mijn GPS. De Sirf II chipset kan dat wel doen, maar dat staat bij mijn Holux GM-82 GPS model standaard niet aan.

[patrickl]

Ik heb nog even gekeken met de Break-out-box wat Cetus nou precies doet op de seriële poort. het enige wat gebeurt is dat de DTR aan gaat. Verder niets. Ik heb het geprobeerd met alleen de HotSync cable (van de Palm Vx) en met de RandMcNally GPS er aan.

De DTR is ook het enige wat er aan gaat bij Atlas, Mapviewer etc.

Het zou kunnen dat de GM-251 dus op een andere pin zit te letten en dat ik die niet kan zien met mijn kabeltje. De RandMcNally heeft bijvoorbeeld alleen RD, TX en DTR aangesloten. Dab kan ik dus ook alleen die signale volgend. Van de HotSync cable weet ik niet wat er aangesloten is.

Ik ben bang dat de enige die hier wat verheldering in zouden kunnen geven de leveranciers zijn. Holux voor de GPS en Kjeld voor Cetus. Je kunt anders wel blijven gissen.

[Rudolf]

Grappig is wel dat ik met mijn M505 en GM201 GPS muis totaal geen probleem heb met het uitschakelen van de palm bij gebruik van Cetus. Ben toch bang dat de oorzaak in de GM-251 gezocht moet worden.

[patrickl]

Nou het is dus waarschijnlijk een combinatie. Het gaat fout bij Cetus en GM251. Cetus werkt goed met andere GPS programma's en de GM-251 werkt blijkbaar ook weer goed met andere GPS programma's. Samen werken ze alleen niet goed.

[star]

Van Kjeld (de ontwerper van Cetus) heb ik inmiddels een reactie ontvangen. Hij heeft me verzocht om een aantal tests te doen en daarvan de debug rapporten naar hem door te sturen. Dat heb ik net gedaan. Als hij verder een reactie geeft hou ik jullie op de hoogte.

[oldy]

Blijft toch vreemd.

Vandaag tijdens het woonwerkverkeer 2x 20 minuten bijna continue een 3d fix. Hedenochtend met de nieuwe software en vanmiddag met oude versie.

Bij een tunneltje is hij de fix even kwijt.

De combinatie is een Palm505 GM251+ met actieve antenne.
Zonder actieve antenne geen 3d fix (ruit is ook warmte werend).

[lette]

Over hetzelfde probleem vinden jullie ook mijn ervaringen in de thread GM251+ met DigiMap.
jammer genoeg nog geen oplossing gevonden

Groet,

[star]

Ik heb inmiddels contact met Kjeld gehad over het bekende issue.

Hij heeft een aantal tips gegeven om e.e.a. zelf te kunnen testen, en erachter te komen wat er aan de hand is. Bij mij werkt Cetus v1.0 nu prima. De latere versie nog niet, die geeft steeds NO GPS aan terwijl ik zeker weet dat de aansluiting OK is en ik 4 satelieten ontvang (middels NMEA Mon).

Zie hier zijn info:
You can perform a simple test yourself. Find a situation where you are pretty sure that Cetus GPS should show data but instead shows "----". Then save a debug memo and look into it.

Find the place in the memo data where you see a "RMC" sentence (one that starts with $GPRMC) like for instance:

$GPRMC,111003.244,A,5213.3378,N,00509.8511,E,0.00,87.83,130802,,*34

In this sentence you will find either an A or a V. A means active, and V means Warning. If you finde some containing an V then Cetus GPS is supposed to ignore the data and show "----". Due to transmission delays there may be a few times that your debug memo does not record the same data as Cetus GPS shows, but in general this should hold.

Many consumer GPS receivers try to predict the position and altitude if they receive a V rather than informing the user that the GPS do not send data. Some Garmin GPS receivers are known to do this extrapolation for up to 30 seconds.

To the unexperienced user this looks like a more stable GPS, but it is not. Cetus GPS has been written with professionals in mind and therefore it shows what the GPS returns and nothing else (unless you set the fix loss delay to something else than zero).

Then in order get the least "no fix" problems with Cetus GPS I suggest you switch off the "satellite fix" in the general preferences and in the navigate preferences set the fix loss delay to at least 10 sec (my preferred setting)