Tag Archives: repareren

Alles over de Qstarz BT-Q1000XT GPS-logger

Jaren terug kocht ik een GPS logger: zo’n klein apparaatje dat niet helpt om te weten waar je bent maar wel om terug te vinden waar je was. Mits je voldoende goed wist waar je was en vervolgens de weg naar huis en de PC hebt weten te vinden.

In dit verhaal: “Stuk”, over hoe een defecte Qstarz te repareren, “Vol” over de juiste instellingen voor een lange race, en “Leeg” over het uitlezen van de logger als de originele software daar faalt.

Aanleiding was dat ik had gelezen dat je geen GPS met scherm mocht gebruiken bij oriëntatiewedstrijden, maar dat ik wel wilde weten waar ik had gelopen en hoe snel. Dus geen Garmin met kaarten, in de hand, maar ook geen GPS om de pols die een kruimelspoor laat zien, en formeel ook geen hardloophorloge waarop je de afgelegde meters kan zien. Hoewel ik nog geen wedstrijd heb meegemaakt waar dat laatste niet werd toegestaan, en nog geen situatie heb meegemaakt waar het kijken op mijn horloge voordeel had opgeleverd. Maar goed. Ik kocht een tracklogger.

Er zijn overigens wel meer voordelen ten opzichte van een hardloophorloge met GPS, en de belangrijkste daarvan is de levensduur van de batterij en de capaciteit van het geheugen. Er is simpelweg geen horloge dat daar aan kan tippen. Noem maar eens een ander apparaat dat 32 uur continue elke seconde een locatie kan opslaan zonder tussentijds uitlezen en opladen. Heb je dat nodig dan? Ja, ik wel. Soms.

Dus, omdat ik niet kon kiezen en de verschillen wilde onderzoeken kocht ik …

Twee GPS trackers

Aanvankelijk was ik niet enthousiast, en schreef ik een paar maanden later:

GPS trackers vallen tegen

Maar dat kwam doordat ik nog niet de specifieke voor- en nadelen realiseerde. Een GPS hardloophorloge gebruik je voor trainingen en wedstrijden van hooguit een paar uur, voor de routineuze loopjes waarbij je snel je tracks wilt downloaden, uploaden, en analyseren. Het moet vooral praktisch zijn; liefst zet je horloge de handel direct op Strava zodra er WiFi in de buurt is. En ik heb, zoals gezegd, nog geen wedstrijd meegemaakt waar mijn TomTom Multi-sport Cardio of mijn Garmin Forerunner 305 verboden was.

En voor de langere wedstrijden, zoals Adventure Races en Orienteering Challenges van 8 uur of langer, is een GPS logger ideaal vanwege zijn uithoudingsvermogen en formaat, en daarbij is bij die lange afstanden -veelal over paden- de sub-meter-nauwkeurigheid minder belangrijk voor het analyseren van de tracks in Quickroute dan voor korte urban sprints. Dus voor elke toepassing heb ik het ideale apparaat. Min of meer.

Stuk

Naar tevredenheid gebruikte ik de dingen waar ze voor bedoeld waren, naar mijn mening, tot er wat stuk ging. Als eerste begaf de iGotU het. Dat was dat witte apparaatje. Niets meer. Geen verbinding met de PC, niet meer laden, geen garantie. Nou was ik daar toch al het minste over te spreken wat betreft nauwkeurigheid, maar het was een handig ding om na een dagje skiles van de kinderen te zien waar ze allemaal geweest waren. Maar toen de Qstarz er mee ophield was ik meer van mijn stuk gebracht. Hij was niet meteen helemaal dood, maar wilde niet meer opladen en communiceren met de PC. Openmaken en kijken wat er in zit is al sinds jongs af aan een hobby van me, maar ik vond het euvel zelf niet meteen en ook online schoot men niet te hulp toen ik mijn verhaal deed op Circuitsonline.

Probleem

Het probleem van het niet-opladen was betrekkelijk: de accu is de Qstarz BT Q1000xt is gelijk aan een Nokia BL-6C, en laat die nou net in mijn prehistorische Nokia 2700 Classic passen, zodat ik de accu ook buiten de GPS logger om kan opladen. Maar zonder uitlezing heb je er nog niet veel aan. Tijd voor wat meer expertise. Laat ik nou toevallig de beschikking hebben over een 2e Qstarz van het zelfde type omdat ik m’n vader er jaren eerdere een cadeau had gedaan om zijn fotoverzameling te geo-taggen. En door de signalen op de printbanen van de twee, de werkende en de defecte, te vergelijken kan ik vaststellen waar een essentiële afwijking zit. Het blijkt eenvoudiger dan gedacht. Even voorbij de ingang van de USB-voedingssignalen valt de spanning weg. Een minuscuul onderdeel, ter grootte van een zandkorrel (een of ander SMD-component) onderbreekt de stroomkring waardoor er niet meer opgeladen wordt, en -vreemd genoeg- ook niet meer met de PC gepraat als de logger daarop wordt aangesloten. En het uitlezen van het geheugen van de logger gaat niet via bluetooth, helaas. Dus het probleem moet wel verholpen worden, of het gadget kan het raam uit.

Weer vergelijk ik de twee loggers, maar nu door het betreffende component op het werkende exemplaar door te meten. Hij lijkt een weerstand van 0 Ω te zijn. Dat kan maar een paar dingen betekenen. Of het is een shunt weerstand die gebruikt wordt om de laadstroom te meten (maar dat lijkt me in dit geval vrij nutteloos), of het is een draadbrug die als discreet component is uitgevoerd omdat er niet genoeg ruimte of lagen in de PCB printsporen beschikbaar waren (maar gezien de ruime plaatsing van de onderdelen is dat ook niet aannemelijk), of het is een zekering. En dat laatste ligt nog wel het meest voor de hand. En ook waarom dan juist dat onderdeel in de kapotte logger defect is.

En ik heb zo mijn hypothese hoe dat komt: in de goede oude tijd, vroegâh, za’k maar zeggen, waren er nog geen USB laders die 2 A of meer uitspuugden. 500mA, daar hield het mee op, netjes gereguleerd door de USB host in de PC. Maar nu USB de de facto standaard is voor het opladen van phones en tablets, is die limiet opgerekt. Mijn GPS logger verwacht dat niet, en gaat uit van een externe begrenzing bij het laden van de interne accu. Maar als de stroom nu ineens niet meer begrensd wordt en de accu kan trekken wat die wil, brandt de zekering door. Want kennelijk heeft wel iemand bedacht dat onbegrensde stromen niet goed zijn.

De vervangende zekering zit met twee draadjes op het printje gesoldeerd omdat dat in de toekomst makkelijker te vervangen is, en bovendien de nieuwe zekering helemaal niet paste op de oorspronkelijk plek. Maar het werkt wel.

Oplossing

Dus, nu was het defect en de oorzaak daarvan gevonden. De oplossing is simpelweg de doorgebrande zekering vervangen door een draadje, en gaan met die banaan. Of wacht, misschien zit die zekering er niet voor niets. Ik stop er een nieuwe in.

Dat werkte een maand, en toen was het oorspronkelijke probleem terug. Nogmaals openen van de GPS logger leerde dat de nieuwe zekering van 500 mA ook doorgebrand was. Oplossing 2 werd dan ook iets geavanceerder dan oplossing 1: een iets vrijgeviger zekering van 750 mA, en een sticker op de GPS logger dat hij niet aan een lader mag die meer dan 500 mA kan leveren. En zo doet hij het inmiddels al weer een jaar of 2.

Beknopte instructies indien logger niet laadt of praat:

  1. Verwerf een SMD weerstand van 500 mA of 1 A (bijvoorbeeld).
  2. Verwijder accu, en pruts behuizing open met behulp van een plectrum oid. De bovenkant moet naar buiten gebogen worden om de klem-palletjes los te maken.
  3. Soldeer twee korte flexible dunne draadjes aan de zekering.
  4. Soldeer de andere kanten van de draadjes aan de uiteinden van de minuscule zekering op de printplaat, zoals in de foto’s hier boven. Het is niet nodig de defecte zekering los te solderen, want die doet het toch niet meer. En de nieuwe heeft ook geen polariteit, dus hij kan ook niet verkeerd om zitten.
  5. Zorg dat de nieuwe zekering niet in de weg zit bij het dichtmaken van de GPS logger.
  6. Laad de logger op en ga er vervolgens 32 uur mee rennen. Stel vast dat het apparaat het langer volhoudt dan jij zelf.

Vol

Toen mijn logger het weer deed was het tijd om het geheugen te vullen. En dat lukte aardig, maar ik wist niet wanneer het precies vol zou zijn. Terwijl ik testte hoe lang de accu mee ging, onderzocht ik meteen ook maar hoeveel datapunten hij kon opslaan. En dit is wat ik vond:

Datapunten

Er kunnen standaard maximaal 230000 punten worden opgeslagen. Maar dat is wel afhankelijk van welke gegevens er bewaard worden. Met de bijgeleverde software Qtravel kan je een aantal gegevens weglaten of toevoegen. Het grappige is overigens dat je niet alles kan instellen, maar als je met een ander programma de gelogde gegevens aanpast, dat dan wel weer door Qtravel wordt weergegeven. Een ander programmaatje is bijvoorbeeld  MTKutillity voor Android, of BT747, maar daarover later meer. Laten we niet afdwalen. Waar het om gaat is dat als je minder gegevens per gelogde positie opslaat, er simpelweg meer punten in het geheugen passen.

Als je je tot een minimum wilt beperken, en je snelheid en koers wel uit de posities en de tijd kan berekenen, heb je alleen tijd (6 bytes), lengte- (8) en breedtegraad (8), en hoogte (4), en dan is er nog een fix mode waarde (2), samen goed voor 28 bytes per punt. Daar kunnen dan ongeveer 330000 van worden opgeslagen, wat neerkomt op ongeveer 8 MB geheugen. Daar lach je nu om, met de huidige prijs van SD kaartjes; maar 10 jaar terug toen dit ding op de markt kwam was dat eigenlijk ook niet veel. Waarom ze er niet meer in hebben gestopt?

Let overigens op dat de diverse programma’s geen weet blijken te hebben van de grootte van het daadwerkelijke geheugen. Als de logger vol is (bij 58 bytes per punt) zegt BT747 “Memory used: 158993 pts (54%)”, terwijl er ergens anders staat “160059 records estimated”, wat niet consistent is. En intussen roept MTKutility per datapunt “58 bytes, max 72315 records”. Alleen die 160000 klopt ongeveer. En zo kom ik op 8 MB voor deze logger.

Gelogde gegevens

Het geheugen gebruik wat betreft track-opslag is vrij goed te voorspellen. Online kan je vinden hoeveel bytes elk punt vergt, bijvoorbeeld hier. En een app als MTKutillity of een programma als BT747 laat ook zien hoeveel bytes elk punt kost, terwijl je deze instellingen maakt. Maar voor wie het liever met de hand uitrekent heb ik de belangrijkste signalen hier onder opgesomd:

naam bytes  omschrijving
 UTC 6  datum en tijd (afgerond op hele secondes)
 VALID 2  GPS status
 LATITUDE 8  breedtegraad
 LONGITUDE 8  lengtegraad
 HEIGHT 4  hoogte [m]
 SPEED 4  snelheid [km/h]
 TRACK 4  koers [graden]
 NSAT 2  aantal satellieten (zichtbaar, en gebruikt)
 MILLISECOND 2  tijd, achter de komma
 DISTANCE 8  afstand tussen punten

De tabel geeft aan per gelogd stukje informatie hoeveel bytes het in beslag neemt. Één byte is 8 bits, een bit is een één of een nul, en een nul is niks. Maar een byte wel en neemt op een chip uit de tijd dat de Qstarz BT-1000XT werd ontworpen iets van 1 triljoenste vierkante meter in. Het hele geheugen past dus op een een vijfde van een vierkante millimeter. Anyway, als je opslagruimte wilt besparen kan je de gelogde gegevens tot een minimum beperken: sla alleen de tijd, locatie, en hoogte op, dus UTC + LATITUDE + LONGITUDE + HEIGHT als de GPS een fix signaal heeft. De snelheid, helling, afstand en koers kan je dan uit deze vier gegevens afleiden.

Afgeleide gegevens

Is dat net zo nauwkeurig? Dat heb ik ook onderzocht. Als je de snelheid uitrekent op basis van de locatie (graden uit de logger heb ik eerst omgezet in UTM coördinaten, en daaruit heb ik de afstand tussen opeenvolgende punten berekend) en het tijdsinterval, komt er een redelijk signaal uit, dat aardig overeenkomt met de snelheid die de logger zelf heeft weggeschreven. Alleen is de blauwe lijn in de grafiek een stuk strakker dan de rode, de berekende. Kennelijk weet de GPS zijn snelheid beter dan zijn locatie. Of wacht: de locatie wordt maar in een beperkt aantal decimalen -cijfers achter de komma- opgeslagen. Misschien ligt het daar aan? Een regel uit de log bevat 51.322957,N,5.476575,E en dat betekent dat er tot op een miljoenste van een graad wordt gerekend. Op onze breedtegraad is dat 6.5 cm in de lengte en 11 cm in de lengterichting. Wat bij een interval van 1 sec neer komt op ongeveer 0.4 km/h. De ruis in de grafiek lijkt meer dan dat. Sterker nog, de standaarddeviatie van het verschil tussen gemeten en berekende snelheid is 1.4 km/h. Dus één van beide zit er naast. Opvallend genoeg is de door de GPS gemeten snelheid dikwijls lager dan de berekende snelheid, méér dan je op basis van de nauwkeurigheid van de graden-representatie zou verwachten. Een andere test, waarbij ik kijk naar de gelogd afstand tussen de punten, laat zien dat het dáár niet aan ligt; de door Pythagoras berekende afstand tussen elk paar punten is met een afwijking van hooguit 0.1 m, de verklaarbare afwijking, gelijk aan de door de GPS gelogde. Mijn conclusie is daarom dat de variatie in de tijd zit. Jitter op de regelmaat van de klok. Ik zou dat kunnen onderzoeken als ik ook de millisecondes van elk sample zou laten opslaan; het is me ook al opgevallen dat ik als ik de waarde van ‘fix every… ms’ op bijvoorbeeld 200 zet in plaats van 1000 (kan via BT747), er meerdere punten met dezelfde timestamp worden bewaard; het is dus niet zo dat er precies elke seconde iets gebeurt in het ding, het kan best vaker zijn, óf onregelmatiger. Je kan op die manier trouwens ook een BT-1000EX maken van de 1000XT, door hem op “fix every 100ms” te zetten, en “log every 1.0m”, en je krijgt bij snelheden boven 10 m/s een datapunt met een frequentie van 10 Hz. Maar ik vind het wel goed zo. Afhankelijk van waar ik de gegevens voor ga gebruiken zal ik de gemeten snelheid al dan niet opslaan, door de logger tevoren te configureren.

En de richting? Ook daar heb ik naar gekeken. Uit de vector van elk paar opgeslagen punten kan ik de richting berekenen(atan(dy/dx)) en die vergelijk met de gelogd koers, krijg je wat je ziet in deze grafiek:

Dat lijkt aardig te kloppen, qua trend, maar er zitten ook veel afwijkingen in. Idealiter zou het een strakke rechte lijn zijn (zoals de groene onderbroken lijn aangeeft) maar dat is dus niet zo. Alleen is het hier prima te verklaren uit de resolutie van de opgeslagen locatie waardes -het beperkte aantal cijfers achter de komma-. Bij lage snelheden zijn de afstanden tussen de punten relatief klein ten opzichte van de discretisatiestappen. En dat kan een enorme afwijking bij die punten opleveren voor de berekende koers.

Dus, moet je nou wél of niet de snelheid, koers en afstand opslaan? Het antwoord is simpel: waar ga je de gegevens voor gebruiken? Om de afhankelijkheid van de loopsnelheid ten opzichte van de helling van het terrein te bepalen, of om te kijken hoeveel effect een bochtig parcours heeft op het looptempo? Dan zou ik deze drie SPEED, TRACK en DISTANCE loggen. Om de route gevolgde op de kaart te plotten, en gewoon te zien waar je liep en hoe hard en hoe hoog, dan is tijd en locatie plus hoogte genoeg om alles met voldoende nauwkeurigheid uit te halen. Wat in elk geval niet werkt is uit de snelheid en richting de gelopen route bepalen, want dan kom je door opgestapelde afrondingsfouten heel ergens anders uit. Dus de locatie moet altijd onderdeel van de gelogde gegevens zijn.

Accu levensduur

Maar over het algemeen is het geheugen niet de beperkende factor, tenzij je een maand vakantie in één keer wilt loggen. Doorgaans is de batterij eerder leeg. De bijgeleverde batterij van het merk Helix (HX-N3650A-G) houdt het tussen de 34 en 38 uur vol; in de loop van de jaren gaat hij wat achteruit, wat te verwachten is. Een nieuwere Nokia BL-6C, uitwisselbaar, houdt het bijna 43 uur vol. Genoeg voor een bizar lange adventure race. Ik vroeg me alleen af of het nog uit maakt hoe vaak hij logt. Want allereerst kost het beschrijven van flash geheugen wat energie, dus hoe meer er gelogd wordt, hoe sneller de batterij leeg is, en ten tweede zou hij wel een in een slaapstand kunnen gaan tussen de punten in, als ik het update interval langer maak. Dus dat heb ik getest.

log interval
[s]
batterij levensduur opgeslagen punten
 1 37:35 135262
5 36:43 26443
10 37:32 13626

Accelerometer

De batterij gaat dus niet langer mee als je minder punten opslaat. Maar er is nog een andere mogelijkheid: selectief opslaan. De logger heeft een zogenaamde accelerometer, een versnellingsopnemer. Die kan de GPS wakker maken als hij beweging detecteert, nadat het apparaatje eerder in een slaapstand was gegaan omdat de snelheid onder een bepaalde waarde was gekomen gedurende een zekere tijd. Zo wordt én de batterij gespaard, én het aantal nutteloze datapunten beperkt. Een testje leerde dat hij op die manier een krappe 7 dagen kon loggen op 1 acculading (mits er niet te veel bewogen wordt, want dan moet het ding gewoon aan het werk).

Toch werkt de accelerometer een beetje vreemd, is mijn bevinding. Een paar keer loopt er een meting van ruim een uur terwijl de GPS min of meer stil staat. Maar meestal is dan wel de ontvangst slecht en schiet de positie heen en weer. Het lijkt er op dat hij op basis van de GPS detecteert dat hij beweegt (ten gevolge van ruis) en dus niet stil lijkt te staan. Maar als hij dan stilstand detecteert gaat hij inderdaad in slaap modus gaat, tot de accelerometer weer wat ziet gebeuren. Maar het duurt soms 12 seconden om een weer een GPS fix te krijgen, soms wat korter, soms langer. Maar meestal klopt het aardig. Een paar keer is het 1e punt dat wordt opgeslagen één km verderop, omdat dan de GPS error nog groot is. Maar dat kan je redelijk wegfilteren. Je mist in elk geval erg weinig punten met de accelerometer aan, en als het voorlaatst punt niet te lang geleden is gaat de positionering ook vloeiend over in de de volgende track omdat dan de GPS locatie nog nauwkeurig is. Dus dat principe werkt goed om accu te sparen, en vooral om geheugen vrij te houden.

Toepassingen en instellingen

Ik houd zelf de volgende instellingen aan voor de verschillende toepassingen:

 toepassing  maximale tijd / afstand  afstand ≥  tijd ≥  snelheid ≥  accelerometer
Oriëntatieloop  95 uur / 340 km  1 m  1 sec  0  off
Adventure race  95 uur / 685 km  2 m  1 sec  0  off
Week skiën  190 uur / 685 km  2 m  2 sec  3 km/h  on
Zomervakantie met auto  39 dagen / 6800 km  20 m  10 sec  5 km/h  on
Analyse (incl. extra data)  54 uur  / 190 km  1 m  1 sec  0  off

Ik ben in de tabel uitgegaan van een dataset met UTC, LATITUDE, LONGITUDE, HEIGHT (in totaal 26 bytes) en voor een Analyse daarnaast nog VALID, SPEED, TRACK, DISTANCE, MILLISECOND (in totaal 46 bytes).

Leeg

Een enkele keer gaat er iets fout. Ik heb wel eens na een activiteit bij het inlezen van de track in QTravel de melding gekregen dat er helemaal niets te downloaden viel. Dat is heel onthutsend; ga je die race van 32 uur nog een keer overdoen omdat de tracklog ontbreekt? Dat kan toch niet? Mijn vermoeden was dat de gegevens wel opgeslagen waren maar dat de software ze niet meer kon lezen.

En dat bleek te kloppen. Kennelijk stond er ergens een bitje verkeerd waardoor de bijgeleverde software geen kaas meer kon maken van de data. Maar er zijn alternatieven, zoals de eerder genoemde BT747 of diverse Anddroid apps. Mijn favoriet op de PC is BT747 vanwege de veelzijdigheid -maar je kan ook weer verdwalen in het aantal opties-, terwijl MTKutility op de smartphone wel weer erg handig is om onderweg tijdens een vakantie een tracklog op te slaan voor als het geheugen onverhoopt vol loopt.

Met BT747 is het me tot nu toe altijd gelukt om alles dat opgeslagen was terug te halen en op te slaan voor verdere bewerking.

QTravel

Dit is de bijgeleverde software, die je ook los kan downloaden. Alleen heb je een product-key nodig om het te gebruiken, dus zonder een Qstarz logger heb je er niet veel aan. Het is wel de enige mogelijkheid die ik heb gevonden om een schema in te stellen van hoe laat tot hoe laat en op welke dagen van de week de logger actief moet zijn. Maar om alle logging opties in te kunnen stellen heb je weer andere, zoals onderstaande, software nodig.

BT747

Een handig PC tool om alle instellingen aan te passen en data over te halen en op te slaan. Bij mij werkt op Win7-64 de 64 bit versie niet; alleen de 32 bit versie is in staat verbinding te maken met de GPS logger.

MTKutility

Er zijn meerdere Android apps om met een MTK tracklogger als de Qstarz BT-1000XT te praten, maar mijn ervaring is dat ze niet allemaal even stabiel werken. En deze app werkt bij mij perfect om de instellingen te wijzigen, en de data over te halen. Installatie via Google Play Store.

GPSbabel

GPSbabel is het Zwitsers zakmes voor verwerking van GPS data, en het kan ook direct met een aantal apparaten praten. Ik heb eens onderstaande batch file geschreven die eerst opzoekt via welke COM poort de GPS logger is verbonden en dan een track inleest en opslaat. Zo maak ik mijzelf overbodig, en heb ik meer tijd om te lopen. Wel heb ik eerst een versie van devcon.exe en sed.exe, en natuurlijk gpsbabel.exe geinstalleerd. Allemaal makkelijk online te vinden.

@echo off
bin\devcon find * | bin\sed -n "s/.*GPS.*(COM\(.*\))/set gpsport=\1/p" > %temp%/gpsport.cmd
call %temp%/gpsport.cmd
echo GPS verbonden met %gpsport%.

rem Windows datum format doet er toe! Moet staan op dd-MM-yyyy
rem set trackdatum_=%date:~10,4%%date:~7,2%%date:~4,2%
set trackdatum_=%date:~6,4%%date:~3,2%%date:~0,2%
set trackdatum=
set /p trackdatum= Wat is de datum (in formaat YYYYMMDD; default %trackdatum_%)?
if "%trackdatum%"=="" set trackdatum=%trackdatum_%
set /p loper= Wat is je naam (zonder spaties)?
set /p omloop= Hoe heet de omloop (zonder spaties)?
set datadirectory=
set datadirectory_=\tracks
set /p datadirectory= Waar wil je de files opslaan (%datadirectory_%)?
if "%datadirectory%"=="" set datadirectory=%datadirectory_%

set gpsfile= %datadirectory%\%trackdatum%_%omloop%_%loper%.gpx
echo Opslaan GPS data in %gpsfile%; even geduld...

@echo on
bin\gpsbabel\gpsbabel.exe -t -i mtk,csv= -f COM%gpsport% -x nuketypes,routes,waypoints -x track,start=%trackdatum%000000,stop=%trackdatum%235959,title=%loper%^#%%Y%%m%%d -o gpx -F %gpsfile%

Meer…

Dit is een levend document. Vermoedelijk ga ik hier nog een en ander bij schrijven en verbeteren. Dus als je geïnteresseerd bent, houd deze pagina dan in de gaten. Je kan je aanmelden voor updates per email via onderstaande link:


 

En mocht je aanvullingen of verbeteringen hebben, schroom niet om die hier onder via een opmerking achter te laten, of neem direct contact met mij op.