Baud rate

[Nemelis]

Sorry voor de snelle post achter alkaar, ik had geen idee hoe jou quote in mijn vorige bericht te passen met de edit knop.

 

Wel effe off-topic: Je kunt bij meerdere berichten op de 'quote' knop klikken. Vervolgens via add-reply een bericht toevoegen. Alle berichten die je qe-quote hebt staan er dan als quote in. Vaak zul dan echter e.e.a. nog moeten editen om het een beetje duidelijk te maken is mijn ervaring.

/* Ook off-topic */

Hmm, weer wat geleerd Ik kende alleen de edit manier om van meer mensen een quote toe te voegen (en dat kan ik redelijk goed, vind ik )

22 oktober 2008 bewerkt door Nemelis

[deBruineBeren]

Tenzij het zo langzaam is dat de positieberekening een grote vertraging heeft. Maar hoe ik daar ooit achter kom.....?

De communicatie tussen de GPS en de Software verloop via het NMEA-0183 protocol.

In dit protocol zijn een aantal zinsopbouwen beschreven.

Zo zijn er bijvoorbeeld de zinnen:

 

$GPRMC Recommended minimum specific GNSS data

De meest nuttige informatie in 1 NMEA-sentence. Hierin staan de coördinaten, tijd, datum, grondsnelheid en -richting en of de data "Valid" is.

 

$GPGGA Global positioning system fixed data

Hierin staat onder andere de tijd, de breedte- en lengtegraad, Noord/Zuid, Oost/West, de hoogte, aantal satellieten, HDOP en of er een "fix" is en zo ja of dat een 2D of 3D-fix is.

 

$GPGLL Geographic position - latitude / longitude

Een vrij korte NMEA-sentence met de coördinaten en de tijd.

 

$GPGSA GNSS DOP and active satellites

Informatie over de gebruikte satellieten, diverse DOP-waardes en of er een "fix" is.

 

$GPGSV GNSS satellites in view

Gedetailleerde informatie over de satellieten die in beeld zijn. Dit kan zelfs verdeeld zijn over maximaal 3 NMEA-sentences.

 

$GPVTG Course over ground and ground speed

Deze (vaak korte) NMEA-sentence geeft aan wat de koers en snelheid (in knopen en/of km/u) is.

 

Elke seconden worden deze zinnen verstuurd door de GPS.

De GPS bepaalt dus je positie niet de software.

 

De vraag is dus uit hoeveel informatie (karakters) bestaan deze zinnen en past dat in 2400 Baud.

 

Standaard is voor het NMEA protocol 4800 Baud, ik dacht dat bij Sirf 9600 baud werd gebruikt.

Maar omdat Sirf ook NMEA ondersteund werkt 4800 Baud meestal altijd.

 

Als de communicatie te langzaam zou zijn zou de software niet elke seconde je juiste positie kunnen weergeven.

 

Met programma’s als OziCE kan je de NMEA zinnen bekijken.

 

Ik zie net dat een zin maximaal 82 karakters mag hebben en dat er ongeveer 6 zinnen zijn dus dat is maximaal 492 karakters.

22 oktober 2008 bewerkt door deBruineBeren

[roderick_schmitz]

Ok, ook weer wat bijgeleerd

 

Al met al KAN de baudrate dus wel verschil uitmaken. In hoeverre dit nou te merken is moet ik maar error en trial achterhalen. Denk dat ik vanmiddag even met de tram heen en weer zal gaan en dan eens bekijken of de snelheid een vertraging heeft ten opzichte van het display dat de bestuurder heeft . De ene keer met mijn GSM-GPS en terug met mijn BT-GPS.

 

Maar dan weer terug komend op het probleempje dat deze vraag bij mij los heeft doen komen. Waarom geeft GeoScout aan de mijn BT-GPS op COM6 zit (wat klopt) maar op 2400 Baut zit (wat volgens de doos dus niet klopt). Dit alles dus als ik de autodetect knop gebruik. Ik kan ook zelf instellen welke compoort en welke baud hij gebruikt, maar of dit dan ook zo werkt vraag ik me af.

 

Met VitoNavigator II kan ik ook autodetect doen, maar dan krijg ik de melding dat COM7 niet te vinden is. Als ik in Vito dan zelf COM6 aangeef wil het nog wel werken.

 

Iemand nog enig idee met welk programmatje ik voor mijn GSm kan downloaden wat de compoorten doorzoekt? Komt dit ook weer op baud 2400 uit dan zit er toch ergens iets niet goed.

 

[edit]

ik zie nu dat ik met geoscout ook de NMEA kan bekijken. Hier komt om de 2 sec weer nieuwe regels bij. Met zo heel zo nu en dan een pauze van 6 sec.

[/edit]

22 oktober 2008 bewerkt door roderick_schmitz

[deBruineBeren]

[edit]

ik zie nu dat ik met geoscout ook de NMEA kan bekijken. Hier komt om de 2 sec weer nieuwe regels bij. Met zo heel zo nu en dan een pauze van 6 sec.

[/edit]

Dit lijkt mij niet goed.

Stel met de hand de boel in op Com6 en 4800 Baud en kijk dan eens of het (goed) werkt.

[roderick_schmitz]

OK, ik heb baud op 4800 gezet, dit geeft geen verschil.

 

Maar ik dacht laat me het eens met de GPS van de GSM proberen. Ook hier wordt hij met de autodetect van geoScout op de juiste compoort gevonden (COM4) maar neemt hij zelf de baud van2400 aan. Dit toen maar handmatig op 4800 gezet (wat volgens het boekje de baud van de GPS in de GSM is). En wat blijkt, deze ververst veel sneller, minder dan een seconden bijna.

 

Echter wil ik die in me GSM liever niet gebruiken vanwege het mindere bereik en de static navigation..

[Team Gelaen]

Om nog even op die baudrate terug te komen. Waarschijnlijk is bij deze gps nmea communicatie de baudrate-bps verhouding 1 op 1. Dus per signaal wisseling (baud), wordt 1 bit verstuurd. Gelijk aan de oorspronkelijke modems van 50 baud en hoger.

 

Lijkt dus inderdaad dat 2400 te weinig is. Zoals DeBruineBeren als zegt, is 4800 de snelheid die het protocol zelf aangeeft. Langzamer zal dus naar alle waarschijnlijkheid problemen geven met hogere snelheden.

22 oktober 2008 bewerkt door Team Gelaen

[roderick_schmitz]

ben nu even wat testjes doen in de tram. Zal later weer met de resultaten terugkomen. In ieder geval bedankt so far, als er nog iedeen zijn, altijd welkom!

[kalkendotters]

Eigenlijk slaat de baudrate in ons geval helemaal nergens meer op...

 

Vroeger waren GPS ontvanger vaak voorzien van een seriele poort, en werden daarmee aangesloten op de PC/PDA/Phone/etc. Daarbij is de baudrate van belang om te zorgen dat de snelheid van zenden overeenkomt met de snelheid van ontvangen; anders wordt het niet verstaan.

Tegenwoordig zit daar vaak een BlueTooth interface tussen: die hebben aan de ene zijde een BT-signaal en aan de andere kant een Seriele poort. Op de PDA/PC/Phone wordt dit BTsignaal weer beschikbaar gesteld als een virtuele seriele poort. Dat is dus geen echte seriele poort, maar een stuk software dat net zo aangeroepen wordt als een echte seriele poort. Het gehele systeem ziet er dan zo'n beetje als volgt uit:

GPS-serieel-BT ..lucht... BT-virueelserieel-PC

 

Er is dus sprake van 2 'seriele' verbindingen die beide een baudrate kunnen hebben:

Tussen de GPS en BT, deze staat door de fabrikant vast ingesteld en is niet te wijzigen; zodra je deze omzet krijg je een mismatch tussen de baudrate van de GPS en BT waardoor je niet meer kunt communiceren met de GPS

De virtuele seriele poort: deze baudrate kun je onbeperkt wijzigen omdat er niets mee gedaan wordt; het signaal wordt namelijk niet echt omgezet naar serieel. Omdat het een 'seriele' poort nadoet, krijg je er ook instellingen bij om deze poort in te stellen, zoals baudrate, databits,stopbits; daar wordt echter helemaal niets mee gedaan door de 'seriele'poort.

 

Ook als de GPS ingebouwd is in een telefoon/PDA zal er gebruik gemaakt worden van een virtuele seriele poort, en ook daar maakt de baudrate dus niets uit.

[deBruineBeren]

De virtuele seriele poort: deze baudrate kun je onbeperkt wijzigen omdat er niets mee gedaan wordt; het signaal wordt namelijk niet echt omgezet naar serieel. Omdat het een 'seriele' poort nadoet, krijg je er ook instellingen bij om deze poort in te stellen, zoals baudrate, databits,stopbits; daar wordt echter helemaal niets mee gedaan door de 'seriele'poort.

 

Ook als de GPS ingebouwd is in een telefoon/PDA zal er gebruik gemaakt worden van een virtuele seriele poort, en ook daar maakt de baudrate dus niets uit.

 

Ik ben het niet helemaal met je eens, de juiste instellingen zijn soms zeker van belang.

Wel is het zo dat een virtuele seriële poort vaak terug communiceert op met de zelfde instellingen als dat je hem aanroept.

Het lijkt dan of dat het allemaal niet uitmaakt, maar en zijn grenzen en beperkingen.

 

Anekdote:

Door het met een verkeerde Baudrate aansturen van de interne GPS in mijn TyTN II was de GPS zo in de war dat alleen een factoryreset uit komst bood.

[Team Gelaen]

Ik sluit me bij DeBruineberen aan.

 

Het signaal wordt volgens mij nl wel serieel (in tegenstelling tot parallel) gemaakt. Bluetooth zit tussen de apparaten ipv een kabeltje, staat los van de manier waarop het signaal gestuurd wordt. En ook informatie die over bluetooth gestuurd wordt zal gesynchroniseerd moeten worden om e.e.a. correct te laten verlopen, dmv van klokpulsen. Dus die baudrate blijft van belang.

 

Edit: vandaar ook het probleem dat DeBruineberen schets.

 

Echter, aangezien veel meer in software plaatsvindt, zal diezelfde software ook meer dingen kunnen checken en corrigeren.

22 oktober 2008 bewerkt door Team Gelaen

[roderick_schmitz]

Ben terug van mijn testjes.

 

Snelheid verversen:

BT: Deze ververst de snelheid om de 2 a3 seconden. Van 0,7 km per uut tot omhoog 35 km per uur (in de tram dus)

 

GSM: Deze ververst de snelheid om de seconde. maar, 3 km per uur tot 35 km per uur (in de tram)

 

Dus de static navigation heeft zeker invloed, onder de 3 km per uur doet hij helemaal niets!!

 

Positie berekening:

BT: Ook om de 2 seconden met afwijking van max 2 meter (Volgens GeoScout)

 

GSM: Om de seconde, maar met een afwijking van max 27 meter!! (Ook volgens GeoScout)

 

 

Allebij dus nadelen en voordelen. Ik heb geeeen idee meer wat ik moet doen.

Of ik moet een BT-GPS vinden die gewoon goed zijn werk doet, geen static navigation en snel verversen. Deze kostte 60 euro

Of ik breng deze BT-GPS terug en ik koop een simpele losse hiking GPS, ij de B*ver Sport had ik de geodkoopste gezien deze was 100 euro.

 

Wat zouden jullie doen?

[deBruineBeren]

Ben terug van mijn testjes.

 

Snelheid verversen:

BT: Deze ververst de snelheid om de 2 a3 seconden. Van 0,7 km per uut tot omhoog 35 km per uur (in de tram dus)

 

GSM: Deze ververst de snelheid om de seconde. maar, 3 km per uur tot 35 km per uur (in de tram)

 

Dus de static navigation heeft zeker invloed, onder de 3 km per uur doet hij helemaal niets!!

 

Positie berekening:

BT: Ook om de 2 seconden met afwijking van max 2 meter (Volgens GeoScout)

 

GSM: Om de seconde, maar met een afwijking van max 27 meter!! (Ook volgens GeoScout)

 

 

Allebij dus nadelen en voordelen. Ik heb geeeen idee meer wat ik moet doen.

Of ik moet een BT-GPS vinden die gewoon goed zijn werk doet, geen static navigation en snel verversen. Deze kostte 60 euro

Of ik breng deze BT-GPS terug en ik koop een simpele losse hiking GPS, ij de B*ver Sport had ik de geodkoopste gezien deze was 100 euro.

 

Wat zouden jullie doen?

 

Altijd lastig al het niet goed werkt, 2 a 3 sec. wachten op een nieuwe positie lijkt mij niet juist.

Maar wat werkt er nu niet goed de BT van de Phone, de GPS of beide.

Kan je de BT GPS ook op een andere PPC/Phone/Laptop proberen ?

 

Een losse hand GPS is voor geocaching altijd het beste.

Of je voor die van € 100 moet gaan weet ik niet, dat ligt aan het buget.

[Team Gelaen]

Daarnaast is een handgps volgens mij wat zuiniger ivm batterijen.

[roderick_schmitz]

Ik zal de BT-GPS eens aan de pc hangen hier, heb wel een BT dongle hierzo liggen. Moet ik wel nog even een stukje software voor de pc vinden die de NMEA kan lezen op de pc, kan ik eens kijken hoe snel die dan update.

 

Butget is toch echt max 100 tot 150 euro. Ben net student af en aan me baantje begonnen, maar als leerkracht basisonderwijs breng ik nog niet zoveel geld in het laadje.

 

[edit]

Nou daar komt hij dus, op de pc ververst hij eigenlijk per direct. Als ik de BT-GPS in het raam legt heeft hij 10 satellieten. Boud is wel 9600

 

Nu zit ik dus nog steeds in dubio. Zal het aan de telefoon liggen dat hij zo langzaam ververst, of komt het omdat GeoScout de boud rate niet op 9600 kan zetten?

 

Was net zo blij met geoScout omdat je daarmee gelijk de caches in de buurt op je telefoon kan laden.

 

Daarnaast is een handgps volgens mij wat zuiniger ivm batterijen.

Dat is wel zo, maar had al gemerkt dat de mijn TyTn II het wel een halve dag volhoudt.

[/edit]

22 oktober 2008 bewerkt door roderick_schmitz

[deBruineBeren]

Probeer OziExplorerCE eens.