onderdelen GPS string PICBASIC

ik zou niet weten wat voor string je gps module uitdraait maar ik kan je wel een tip geven.

zet eronder Serout metdezelfde string die je net ontvangen had, en bekijk je data op een terminal via de seriele poort.

Op die manier kun je andere dingen ook makkelijk debuggen.

30 Bytes is veel te weinig voor een GPS string.
De eerste serin wacht op de $ die op de eerste positie van elke NMEA string staat.
De tweede serin leest vervolgens 30 bytes binnen, die kun je gewoon in je programma verwerken.
Ik ga er van uit dat de bytes die nog volgen (na die 30 dus) gewoon verloren gaan.

ook zal er afhankelijk van gps tot gps na de '$' een andere zin komen.

In mijn gps experiment van een aantal jaar terug heb ik de module aan mijn com poort gehangen zodat ik kon zien wat er uit komt. Dan kan je ook simpel zien wat waar komt. Denk er ook aan dat de zin geen vaste lengte heeft. Je kan dus niet simpel zeggen wat waar komt, hierdoor zul je de komma tekens moeten tellen.

MVG

Ojeke

hoe weet je dan welke zin komt?
ik heb de EM-406 van futurlec. deze geeft de strings GGA, GSA, GSV, RMC, VTg en GLL...

kun je je module niet serieel vertellen welke zin hij uit moet braken? ik zie in de sheet (www.futurlec.com/EM-406A.shtml ! url-en werkt niet!),in artikel D:

This command is used to control the output of standard NMEA message GGA,GLL, GSA, GSV,RMC, VTG. Using this command message, standard NMEA message may be polled once, or setup for periodic output.

nu heb ik eigenlijk de TX functie nodig op mijn PIC. maar ik kan een klein dpdt relaisje erop zetten( heb ik niet meer. twee AND-poorten misschien? halen die 38000baud?), die aan het begin naar de gps switcht en vertelt om periodiek op een bepaalde frequentie de $GPGGA string te laten zenden. ( daarna weer terug naar de andere ontvanger)is dit mogelijk? dan kan ik daarna, omdat ik dan de lengte van de gpgga string weet, elke keer de juiste lengte uitlezen.

zit ik in de goede richting, of er helemaal naast? mijn ervaring met GPS is er klein, dus een beetje coaching zal wel nodig zijn ben ik bang...

Ik heb dat stukje programma later nog aangepast, onderstaande werkt beter dan het oude stukje:

Dim GPS_Info[71]   As Byte
...
For i = 0 To 71
    GPS_Info[i] = 0
Next
SerIn gps_tx,188,1000,gps_error,[Wait("$"), Str GPS_Info\70]
gps_error:

If GPS_Info[0] <> 0 Then
;doe iets
endif

Ik heb mijn GPS ingesteld om alleen de $GPGGA string uit te sturen (niet zeker dat het die was, het is al een tijdje geleden).

omdat ik dan de lengte van de gpgga string weet,

Strikt genomen weet je die lengte niet. De lengte van de velden kan variëren.
Een eenvoudig voorbeeld is als je omschakelt van 2 naar 3 (of 4) cijfers achter het decimaalteken. Maar er kunnen ook andere oorzaken voor een afwijkende stringlengte zijn.

Je hoort steeds karakters te blijven binnenhalen tot aan de eerstvolgende komma. Zo weet je zeker dat je het hele veld hebt. - Na de checsum komt geen komma, maar CR/LF.

Denk om de Valid indicator: V= Invalid. A= Valid.

In de datasheet staat aangegeven wat je kunt veranderen aan de output. Als je alleen de GGA string wilt hebben moet je dus de andere uitzetten.
Je vertelt niet waarvoor je een GPS gaat gebruiken, dus het is maar gissen of je met alleen de $GPGGA de juiste gegevens ophaalt.

Ik zou zelfs geen strings willen uitzetten.
Laat je software gewoon alles zien wat er is, en er zelf de gegevens uitpikken die benodigd zijn.
Iedere string heeft zijn eigen naam aan kop staan, en hoewel de lengte niet vast is, is per string de indeling, dus de volgorde van de velden, dat wel.

helaas... maar ik moet berekeningen gaan uitvoeren met de waarden... ( gorder dan, kleiner dan, elseif)

??? Daarom mag je ze toch nog wel correct inlezen?

Je zult eerst alle karakters van een getal moeten hebben voordat je er een getal van kunt maken lijkt me.
Ieder taal waarin je strings en getallen kunt inlezen kan ook strings naar getallen converteren. En anders doe je het zelf; zo'n mirakel kan dat toch niet zijn?
(sprak hij onwetend )

En weet je al uit welke strings je die waarden moet halen?

Even de discussie terzijde: de eerste byte komt in de eerste byte, de tweede in de tweede, etc. Het kenmerkende van een string is dat de karakters in volgorde erin staan. Als je dus wacht op een '$' krijg je de eerste 30,70,1000 karakters daarna (ik weet niet zeker of $ zelf ook mee komt)

de hoofdvraag kan nu nog even achten, maar ik heb nog een tweede probleem.
op de RX pin van de PIC zit de GPS. deze is 4800baud. op de TX pin zit een zender, met 38400baud, en dan moet ik nog ( op een andere pin? kan/mag dit?) een andere TX pin naar de gps hebben, die alleen actief zal zijn in het begin van het programma, voor het versturen van de gewenste settings.
hoe moet ik dan switchen tussen de twee baudrates en kan ik voor de GPStx een andere pin nemen?

Je concept is brak.
Laat die GPS gewoon op z'n defaults draaien - anders bak je iets wat het alleen met deze GPS doet.

Vervolgens haal je elke string binnen, en kijk je of die een identifier heeft die jij kunt gebruiken. Zo ja, dan parse je dat ding, zo nee, dan mik je 'm weg.

In de spec staat meen ik dat een string max. 82 characters lang kan zijn (even nakijken!). Meer mem hoef je dus niet te reserveren (als het meer wordt, is die string hoe dan ook stuk, dus kun je 'm weg mikken).

loop
  waitfor '$'
  while (len<MAX) && (in!=CR of LF)
    store in
    len+1
  whileend

  was last CR of LF then process stored data
  len=0 en store leeg
endloop

Zoiets dus.
Daar zijn variaties op mogelijk, door bijvoorbeeld gelijk aan het begin al te kijken of je de juiste identifier hebt, maar je code wordt er niet leesbaarder van (en de performance winst is doorgaans niet de moeite waard, tenzij je erg krap in je timing komt te zitten).

In die processing kijk je eerst of je checksum klopt. Als dat zo is, kun je naar een identifier gaan kijken.
Als die ook klopt, kun je gaan parsen. Dat doe je door op seperators te zoeken (de ',' in jouw geval). De lengte van de velden is variabel...

err... je hebt 4800 Rx en 38400 Tx naar een andere module terwijl je een losse Tx naar je GPS wilt hebben die ook weer op 4800 draait... ben je niet extreem moeilijk aan het doen?

Gebruik het Tx/Rx paar van je microcontroller op 4800 naar de GPS en gebruik een tweede Tx naar je 38400 device.

die tweede TX van 4800 baud zal ik slechts een keer gebruiken.\
ik weet niet of als je de gps configureert, dat de instellingen voor altijd zo blijven totdat je ze weer verandert, maar bovenaan mn code komt een kort stukje dat de GPS instelt.

daarna gebruik ik de 4800 Tx niet meer, en de Rx wordt 38400 baud.

uhm... even kijken:

je GPS zend op 4800 Bdps, maar je stuurt via 4800 Bdps een commando om naar 38400 Bdps te gaan. Daarna lees je dus op je Rx op 38400Bdps van de GPS en zend je naar iets anders op 38400Bdps vanaf je Tx...
heb ik het dan juist op een rijtje?

In dit geval zou ik gewoon je eerste UART op 38400Bdps zetten, de ontvangen data zal initieel niet kloppen (baudrate klopt niet), maar je moet toch nog initialiseren. Een tweede UART zet je op 4800Bdps (of je gebruikt een bitbanging software UART, kan ook) die de GPS instelt. Zo hoef je nooit te switchen van baudrate, de eerste UART zal vanzelf correcte data gaan ontvangen nadat je de GPS ingesteld hebt.

yep dat is het hele idee.
ik heb geen tweede uart aan boord ( 16F877) maar ik kan daar een ander commando voor pakken toch?

ik ga overmorgen op vakantie. helaas kan ik dan niet reageren, maar het idee van wat ik dacht is duidelijk toch?

Geen tweede uart, dus dan zou ik de 4800Bdps Tx in software doen. De truck is dat je een serieel signaal nadoet door goed getimed de uitgang van 0 naar 1 of andersom te zetten. Er zijn vast genoeg stukjes code te vinden, maar het principe is als volgt:
Een serieel signaal (uart) is in rusttoestand 1, vervolgens wordt er 1 bitperiode een 0 gestuurd, gevolgd door je databits (beginnend met je LSB (de meest rechter bit)) en dan een eventuele parity bit en dan 1 of twee hoog bits. Bijvoorbeeld

43 = 2B hex = 00101011 binair
hoog ~------+     +-----+-----+     +-----+     +-----+           +--------~
        rust|start|bit 0 bit 1|bit 2|bit 3|bit 4|bit 5|bit 6 bit 7|stop/rust
laag        +-----+           +-----+     +-----+     +-----+-----+

de truck is dus om de periode van iedere bit precies 1/4800 seconde (zo'n 208us) te laten duren. Meestal wordt hiervoor een timer gebruikt die telkens de volgende bit naar buiten stuurt, al kan je ook met delays werken als er verder niets anders gebeurt, de laatste methode is meestal minder nauwkeurig.
Let erop dat UART een hoog signaal (1) als rust gebruikt, dus na gebruik moet je deze pin hoog laten, niet laag.

In Proton heb je ook commando's voor seriele communicatie die in de software (voor je) wordt opgelost. Dat hoef je helemaal niet zelf te programmeren. Gewoon in de manual zoeken.

Denk erom dat op de RS232 kabel (bijv. aan een COMpoort van een computer) het signaal geïnverteerd is. Daar is het dus in rust (dus ook het stopbit) een negatieve spanning, en het startbit is een positieve spanning.

De meeste COMpoorten werken ook met 0V als rustspanning inplaats van een negatieve spanning. Maar dat is eigenlijk niet correct, al is het soms handig.

Wat FET zegt: de hoog/1 wordt in RS-232 'mark' genoemd, en de laag/0 'space'. Een mark is volgens de specificatie tussen de -3 en -15 volt (grofweg, er zijn minimum en maximum waarden voor zowel zenden als ontvangen), terwijl een space tussen de 3 en 15 volt ligt. Tussen de 3 en -3 is volgens diezelfde spec ongeldig.
Ik weet niet of je GPS module 0-3.3, 0-5 of RS-232 gebruikt voor de signalen (de mijne gebruikt 0-1.8), dus daar zul je zelf even naar moeten kijken. Als je module RS-232 gebruikt, kan je het beste een MAX-232 o.i.d. gebruiken om hem aan je microcontroller te koppelen.

ik ben weer terug uit noorwegen

de GPS heeft 0-2.85V TTL. wat is de beste manier om het uitgangssignaal naar de PIC te sturen?

wat zijn de minst ruimte innemende methoden om dit goed te doen?
voor de GPS-rx naar de pic kan ik gewoon weerstanden nemen. alleen de waarden weet ik niet, ik heb wel gevonden, r1=0.75r2, en txd-r1-rxgps-r2-gnd.
maar terug weet ik niet zodirect.

ik ga weer testen, mocht ik iets niet weten...

Als je alleen de GGA wil, kun je toch gewoon op $GPGGA wachten ipv op $? Dan hoef je niks in te stellen...