Hallo, ich hätte den Beitrag wohl auch 'just another GPS-Logger' nennen können ;-) Das ist sicher nicht der erste GPS-Logger, da ich mir hier aber vor einiger Zeit ein paar sinnvolle Tipps geholt habe, möchte ich das fertige Ergebnis nun nicht vorenthalten. Außerdem denke ich, dass es doch eine runde Sache geworden ist und würde mich freuen, wenn es noch jemand anders nützlich findet. Features: - ATmega8 konvertiert GPS-Daten ins GPX Format und speichert auf FAT16-formatierter SD-Karte - Versorgung über Li-Ion Handyakku - selbsttätiges Abschalten bei niedriger Batteriespannung - Laden des Akkus in der Schaltung - kompakte Abmessungen (ca. 8 x 5,5 x 2,5cm) Details unter http://friedrichs-bs.net/GPX-Logger.html hier kann man bei Interesse auch die Software sowie das Layout herunterladen. Schönen Abend noch! Arne
Angehängte Dateien:
-
Schaltplan.png
12 KB -
20100614_167.jpg
70 KB -
20100619_183.jpg
79 KB
Ich hätte übrigens auch noch geringe Anzahl Platinen für den Logger übrig. Bei Interesse bitte melden. Gruß Arne
Hallo, Ein schönes Projekt :) Genau das wollte ich als nächstes auch bauen.. Ich hätte Interesse an 1-2 Platinen ;) Wieviel soll da eine kosten? Viele Grüße, Johannes
Hallo, hab die bei HAKA als XXS Zwilling fertigen lassen und habe 8 Platinen für insges. 48€ bekommen. Ich würde sie für 6€/Stück plus Porto abgeben. Grüße Arne
Okay, danke, ich melde mich dann mal per email bei dir ;) Hast du vielleicht noch ein Bild von der unterseite der Platine? Also die Seite, auf der die SD Karte sitzt, weil ich überlege ob meine SD-Sockel bei deiner Platine passen ;)
ja, sind noch welche da. Bitte kurze Mail. @Johannes: Fotos der Platine kann ich morgen noch mal posten. Sonst evtl. mal das Layout mit Eagle ausdrucken und testen. Zumindest der SD-Sockel von Pollin passt. Gruß Arne
Kann man bei dem GPX-Standard auch PIOs mit abspeichern ? Für mich wäre es interessant, wenn man den Weg mitlogt und durch einen Tastendruck die aktuelle Position zusätzlich in einer Liste abspeichern könnte. IO-Kanäle für den Taster wären ja genug da. Gratuliere zu diesem sehr schönen Project.
Ok, ich bin nur gerade an einem PC ohne Eagle, deshalb kann ich das Layout gerade nicht anschaun... Ich schreib dir dann morgen noch eine email ;)
@ado: ja, im GPX kann man sogenannte Waypoints speichern, allerdings nur außerhalb einer Trackaufzeichnung. D.h. entweder müsste man die Trackaufzeichnung kurz unterbrechen, einen Waypoint speichern und danach einen neuen Track beginnen. Oder man könnte innerhalb eines Tracks bestimme Trackpoints gesondert markieren.
Angehängte Dateien:
-
20100916_005.jpg
93 KB
hier nochmal wie versprochen ein Foto beider Platinenseiten (das Kriseln sind keine Fehler in der Platine, sondern JPG-Artefakte). Die Rückseite habe ich an zwei verschiedene SD-Kartenhalter angepasst, einer davon der von Pollin für 1,50€.
Hi, hat die Software schon jemand getestet? Die FAT_Init() Funktion läuft nicht. Nach aktivieren von #define FAT_ENABLE_ERROR_TRACE 1 #define FAT_ENABLE_DEBUG_TRACE 1 #define USART_FEAT_WRITE_ACCESS 1 meldet es mir übers Terminal: FAT_Init<\r><\n> SD init failed!<\r><\n> Studenlange Fehlersuche. Verkabelungsfehler kann ich auschließen, da eine andere FAT Library problemlos läuft! Karte (256MB) habe ich als FAT16 formatiert (sowohl unter Linux als auch unter Windows). Ed
Hallo, die SW läuft bei mir mit mehreren verschiedenen Karten, hatte aber keine Karte < 1GB zum Testen. 2 Blöde Fragen: - Ist es eine SD oder MMC Karte? - Verwendet die andere Lib dieselben Pins (insb. für SD Chip Select)? Kommt der Fehler sofort, oder erst nach einiger Verzögerung? Evtl. braucht die Karte länger zum Initialisieren. Ich würde zum Test mal die SPI-Geschwindigkeit auf Minimum setzen und die SD-Traces ansehen: #define SDC_ENABLE_ERROR_TRACE #define SDC_ENABLE_DEBUG_TRACE Falls die Karte sich gar nicht meldet, ggf. das Timing in SDC_init() entschärfen und SDC_MAX_RETRIES hochsetzen:
1 | uint8 SDC_Init() |
2 | {
|
3 | SDC_TRACE_DEBUG_STRING("SDC_Init\r\n"); |
4 | |
5 | uint8 tries = SDC_MAX_RETRIES; |
6 | |
7 | // init SPI
|
8 | SPI_Init(); |
9 | |
10 | // wait 10ms and send > 74 clock cycles to enter SD card SPI mode
|
11 | _delay_ms(10); |
12 | uint8 i; |
13 | for (i=0; i<20; i++) |
14 | {
|
15 | _delay_us(5); |
16 | SPI_WriteChar(0xff); |
17 | }
|
Gruß Arne
Hab' hier grad noch eine 512MB MMC Plus Karte gefunden, mit der läuft's auch einwandfrei. Wie sieht denn die Schaltung aus? Wird der µC mit 3,3V betrieben? Taktfrequenz?
Hi Arne, danke vielmals für deine Tips! Es war die Lösung dabei! Alles funktioniert bestens. Der Hinweis mit den Pins war goldrichtig. Ich bin zwecks Codegröße auf einen Atmega32 ungestiegen und habe nicht darauf geachtet, dass der SPI Port da woanders liegt. Blöder Fehler, ich dachte die sind noch Pinkompatibel! In der sdcard.h die Pins angepasst und nun läuft es EINWANDFREI! Echt nettes und einfaches Stück Software. Vielen Dank dafür und für deine Hilfe. Besten Dank, mit freundlichen Grüßen Ed
Ich habe eben versucht Waypoints einzutragen. Prinzipiell funktioniert die geänderte GPX-Datei. Nur die automatisch generierten Trackpunkt-Namen bei Google Earth, sind nicht ideal. Bei jeder neuen Sequenz fängt die Namensnummer wieder bei 0 an. Aber die Namen der Trackpoints sind, so glaube ich, auch nicht so wirklich interessant. Ansonsten kann man diese ja bei der Erzeugung der GPX-Datei geziehlt angeben. In der neuen Sequenz nach einem Waypoint muß die letzte Position nocheinmal eingetragen werden. Sonst gibt es eine Unterbrechung des Tracks. Ich hoffe ich finde demnächst Zeit diese Schaltung nachzubauen.
Hallo Arne, tolles Projekt. Eine Frage habe ich: wie bekomme ich den code in ein hex file welches in die 8k im mega8 paßt? Irgendwie komme ich nicht unter 20k.
@conquistador: Falls du mit dem AVRStudio compilierst, dann kann man Optimierung einschalten. Höchste Stufe (ich glaube ist -os) wenns keine Probleme macht.
Hallo zusammen, gibt es denn noch eine Platine - dann würde ich gerne eine oder zwei nehmen!? Beste Grüsse Michael
Bin gerade auch auf das Projekt gestossen und würde gerne auch eine LP nehmen, wenn's noch welche gibt! Helmut.
Hallo, @ conquistador: ja, wie beschrieben mit "-Os" compilieren, dann macht WinAVR ca. 7,5KB Code daraus (wobei das Hexfile an sich als Datei durchaus eine Größe von 20KB hat, das entspricht nicht der Codesize) @Michael,Helmut: Ich habe noch 1-2 Platinen da, bei Interesse bitte kurze Mail. Falls es wider Erwarten doch noch mehr Interessenten gibt, könnte ich auch noch mal welche machen lassen. Grüße Arne
@Arne and warrior, Ja, danke, ich bin einfach nur ein Trottel, das hex paßt hervorragend in den mega8 und am Ende sind noch jede Menge Freie Felder FF :-).
Hi, SEHR FEIN ;) Ernsthaft... inspiriert durch den GLogger hier aus dem Forum wollte ich schon seit geraumer Zeit meinen eigenen GPS Logger bauen. Ich bin dieser Tage genaugenommen dabei die letzten "Vorbereitungen" zu treffen (Entwurf der fehlenden Bauteile und Sockel in Eagle, zusammentragen der Materialien etc). Anders als bei dessen Nachfolger wollte ich jedoch unbedingt bei FAT nd Standart-Daten bleiben. Da kommt mir Dein Projekt gerade recht... FAT16, das gleiche GPS Module das ich auch schon hier liegen habe, MAX1811 Aufbau ähnlich (ich hab mir die MIC2920A aus dem Glogger Projekt besorgt)... wir funken auf der selben Welle ™ ;) Ich freue mich schon darauf mich die Tage durch Deinen Code/Schaltplan zu lesen. Ich bedanke mich schon jetzt parallel zu den GLogger-Nasen ;) auch bei Dir herzlichst, immerhin sollte ich mit so viel guter Vorarbeit meinen eigenen Logger inklusive meiner "Modifikationen" bzw. Änderungen in einem Bruchteil der Zeit (verglichen damit, Hard- und Software von Grund auf komplett selbst auf die Beine zu stellen) fertig stellen können. Ich habe mir damals sicherheitshalber ein Sortiment größerer AVRs zugelegt, ich denke ich werde da einen 32k oder 64k Typ und evtl. ein paar zugängliche I/Os auf der Platine vormerken. Das lässt Platz für spätere Erweiterungen der Funktionalität...Nichts desto trotz Respekt davor, das ganze in einen Mega8 unterzubringen! Am überlegen bin ich, ob ich den USB Anschluß zum Laden des Akkus nicht gleich voll Nutze um - entweder via FT232 oder softwarebasiert - Daten auch direkt übertragen zu können. Wer ähnliches vor hat und evtl. noch das eine oder andere alternative Package braucht - ich hab ein paar SD und mircoSD Halter von ATTEND in eagle erstellt - ebenso einige andere Packages die ich nicht finden konnte. Ich merke mir den Thread jedenfalls mal vor und werde mein Ergebnis posten, sobald ich weiter fortgeschritten bin. Ciao...
Hallo, mein Nachbau mit der Platine von Arne läuft seit heute. Gelötet hatte ich schon letztes Wochenende, aber es funktionierte nicht. Nach längerem Suchen mit dem Oszi merkte ich, daß der Logger die seriellen Daten des GPS Moduls (9600 Baud) nicht richtig verstand. Offensichtlich sind die 2Mhz des internen Oszillators nicht genau genug. Bei meinen eigenen Projekten setze ich schon seit längerem aus diesem Grund Quarz ein, wenn ich RS232 brauche. Jetzt weis ich wieder, warum ;-)) Werde den Logger heute noch ernsthaft ausprobieren. Gruß und Danke an Arne Bernhard
Hi, mal eine kurze Zwischenfrage an die Profis ;) Ich hab heute den ersten Prototypen aufgebaut und soweit scheint meine Variante (100% SMD, 501ETTL und diverse andere Abweichungen vom Originalentwurf) zu funktionieren. Gut finde ich die Wahl des Spannungsreglers mit Shutdown, allerdings werde ich den wohl nicht mehr rechtzeitig hier haben (Samstag steht eine einwöchige Reise an und da soll die "Version 2" des Prototyps schon mitloggen). Danach ist genug Zeit um die finale Version in Ruhe und "professioneller" aufzubauen. Wie auch immer, ich werde wohl den ZLDO330 nicht schnell genug bekommen und wollte auch V2 mit dem MIC2920A (von denen ich genug habe) aufbauen, allerdings um eine Ein- bzw. Abschaltung erweitert wie im Original implementiert. BSS138 habe ich ebenfalls ausreichend, daher frage ich mich, ob zu Überbrückung eine möglichst einfache Ersatzschaltung realisierbar wäre. Auf anhieb fällt mir jedoch keine Lösung ein die das auch nur mit einem Taster erledigt - vielleicht sehe ich ja aber auch nur den sprichwörtlichen Wald vor lauter Bäumen nicht ^^ Denkbar wäre sonst wohl einfach einen zweiten Aus-Taster vorzusehen. Der Bisherige Eingang hält nach dem Einschalten durch seinen Pullup wie gehabt den BSS138 aktiv, den Aus-Taster gegen Masse frage ich über den nächsten freien Pin des gleichen Ports ab und veranlasse damit die Abschaltung. Wäre das ein brauchbarer Ansatz? Die Akkuladung via MAX1555 oder MAX1811 würde 1:1 umgesetzt bleiben. Lediglich der Spannungsregler der parallel zum LIPO die restliche Schaltung versorgt soll per Taster zugeschaltet werden und sich dann über den AVR bis zum Shutdown selbst halten. Neben dem 501ETTL (ca 65mA) und der SD Card wären es noch der AVR und maximal 2 (ggf. 3) gleichzeitig betriebene LEDs. der Gesamtstrom sollte vorsichtig geschätzt noch deutlich unter 200mA liegen. Da der BSS138 220mA Dauerstrom kann, sollte das doch im grünen Bereich liegen, oder? Wie gesagt, den ZLDO330 halte ich nicht zuletzt wegen seiner Verfügbarkeit bei Reichelt für eine sehr gute Wahl, aber wenn ich optimistisch 2-3 Tage Lieferzeit ansetze bleibt mir kaum Zeit die Schaltung aufzubauen und ausreichend zu testen bevor es am Samstag auf Tour gehen soll. Daher plane ich diesen erst für die dritte und vermutlich endgültige Version des Loggers ein. Eine vorrübergehende Ersatzschaltung mit verfügbaren Bauteilen könnte ich dagegen schon im Laufe des Dienstags fertigstellen (bei reinen SMD Schaltung geht das Layouten, Ätzen und Löten glücklicherweise sehr fix und sauber, (sauberes) Bohren hat mich schon immer anteilig die meiste Zeit und Nerven gekostet ;) ) und hätte gleich mehrere Tage um ggf. am Code zu feilen und Dauertests durchzuführen. Für Ratschläge und/oder konstruktive Kritik in Punkto Ersatz-"Ein"Schaltung wäre ich euch dankbar... Ciao...
Hi nochmal... während ich über meine Selbsthaltung meditiere ^^ hab ich mich weiter durch die einzelnen Projektdateien gelesen... Bin ich reif fürs Bett oder stimmt da was mit der Baudrate nicht ganz? Laut Datenblatt (Formel wie auch die Tabelle der gebräuchlichen Baudraten) sollte bei 2MHz und 9600 UBBRn=25 sein um auf 0.2% Fehler zu kommen, also demnach doch UBRRL = 25 UBRRH = 0 ? die USART.c enthält aber UBRRL = 24; // 9600 Baud @ 2 MHz @ 3,3V UBRRH = 0; Stehe ich jetzt so sehr auf dem Schlauch oder müsste dieser Wert nicht eine erheblich größere Abweichung im Bereich 4.2% ergeben? Das läge doch erheblich neben der Soll-Baudrate, oder wo liegt mein Denkfehler?
Hallo Maxx M. die Werte für UBRRL sind bewusst so gewählt. Die Baudrate ist abhängig von der Versorgungsspannung, daher war für 3.3V eine Anpassung von 25 auf 24 notwendig. Ich erinnere mich vage an ein Diagramm im Datenblatt, kann das aber auf die Schnelle nicht finden. Ich hatte vor dem Einsatz des ZLDO330 auch diverse andere Varianten durchdacht/durchprobiert, u.a. Pufferung/Verzögertes Ausschalten mit Goldcap - hat sich aber alles nicht wirklich bewährt. @Bernhard: ja, mit einem Quartz ist man auf der sicheren Seite. Ich hatte aber mit der Genauigkeit des internen Oszillators (wie auch der interen ADC-Referenz) auch bei Temperaturschwankungen bisher nie Probleme, daher habe ich drauf verzichtet. Bei evtl. größerer Ungenauigkeit durch Serienstreuung sollte sich das durch Setzen des Oscillator Calibration Value (oder notfalls halt auch UBRRL) kompensieren lassen. Gruß Arne
Hallo Maxx M., ich sehe gerade, dass Du den NL 501 ETTL verwendest. Dieser arbeitet laut Spec mit einer Versorgungsspannung von 3,3V-4,2V. Der Logger geht bis zum Abschalten wg. niedriger Batteriespannung noch bis 3.0V herunter. Funktioniert der Empfänger bei 3V noch zuverlässig? Arne
Hi, habe ich bisher noch nicht "ausgereizt". Ich kann das aber bei nächster Gelegenheit einfach "künstlich" erzeugen und testen. Zuvor steht erstmal der neue Prototyp an, nachdem ich nun auch ein paar ZLDO hier habe. Ausserdem hatte ich beim ersten Aufbau meinen "eigenen" tKeepOut bei dem einfachen MicroSD-Verbinder nicht eingehalten. Erst als der Logger zwar nitialisierte aber mit der SDCard Probleme hatte fiel mir das auf. Mal sehen wie ich das Routing drum herum hinbekomme, ansonsten nehm ich eben einen der anderen (hatte mir vor einiger Zeit ein paar einfache "hinged" (also mit Schiebe-Verriegelung) und push-push besorgt und die Packages dank der freundlichen Zusendung der Datenblätter in einer eigenen Eagle-lib zusammengefasst). Die hinged sind einfacher zu Löten und boten sich fuer Prototypen an - da muss es ja nicht immer Luxus sein ;) Ich hatte sowieso einige kleine Änderungen vorgesehen und mir auch den Punkt mit der unteren Akkuspannung bereits zwecks kleiner Anpassung vorgemerkt.
Hallo, ich habe nun Feedback von jemanden bekommen, der den Navilock NL-507 ETTL verwendet. Obwohl dieser für 3.3-4.2V ausgelegt ist, scheint er auch bis knapp unter 3V noch stabil zu laufen. Da der u-blox Chipsatz leicht unterschiedliche Koordinatenformate verwendet (mehr Dezimalstellen) und die NMEA-Sentences in anderer Reihenfolge sendet, habe ich bei der Gelegenheit die Software angepasst. Sie ist nun generischer und dadurch auch zu anderen GPS-Modulen kompatibel. Außerdem habe ich noch eine Testsoftware ergänzt, die nur die LEDs blinken lässt, das hilft u.U. bei der Inbetriebnahme der Platine. Grüße Arne
Falls man den internen Oszillator verwendet um den Quarz zu sparen , sollte man sich einen 32kHz quarz goennen, und den internen Oszillator auf den synchronisieren. Sonst wird das mit der Baudrate nie was. Advanced waere natuerlich auf das GPS zu synchronisieren. Mit einem Timer auf die Meldungen warten.
Hallo, Quint Oschi schrieb: > Sonst wird das mit der Baudrate nie was. Gewagte These... Ich habe nun drei von den Dingern gebaut, und alle laufen zuverlässig. Kalibrierung des internen Oszillators macht auf jedem Fall Sinn, war bei mir aber in keinem Fall notwendig. Man kann sich viele schöne Sachen überlegen, das im laufenden Betrieb automatisch zu kalibrieren, habe ich damals auch drüber nachgedacht, aber letztlich verworfen, weil es auch so problemlos lief. Sonst lieber gleich einen Quartz einbauen und fertig. Würde mich natürlich trotzdem mal interessieren, ob ob jemand, der die Schaltung nachgebaut hat, mit der Baudrate (mit/ohne Kalibrierung des internen Oszis) Probleme hatte. Arne
Der interne Oszillator ist nicht genau genug spezifiziert fuer serielle Kommunikation. Die Frequenz haengt von der Spannung, sowie von der Temperatur ab. Zur Powerup Kalibration mit einem Uhrenquarz ... http://www.ibrtses.com/embedded/avrosccal.html .. koennte auch zur laufenden Kalibration umgebaut werden. Es macht durchaus Sinn fuer Stromsparanwendungen nur mit dem Uhrenquarz zu arbeiten und nicht mit einem richtigen.
Wenn man den Diagrammen im Datenblatt glauben mag, hat der interne Oszillator bei -20° bis +60° und 3-3,3V eine Drift von ca. +/-3%. Klingt für mich ganz annehmbar. Hat da jemand genauere Erfahrungen? Das mit dem Uhrenquartz mag für Stromsparanwendungen sinnvoll sein. Bei den 50-70mA, die das GPS-Modul verbrät, fiele wohl der 2MHz Quartz nicht mehr ins Gewicht. Eine einfache Möglichkeit zur automatischen Kalibrierung wäre natürlich das PPS (Pulse-Per-Second) Signal, leider bieten das diese GPS Module nicht... Arne
Die seriellen Schnittstellen benoetigen eine Frequenzgenauigkeit von kleiner 2%, strikt. Das GPS Modul laesst man doch nicht durchlaufen... das hat doch einen Standby. Nein ?
Solange der Logger läuft, ist natürlich auch das GPS Modul aktiv. Ich schalte hier nicht den µC in Standby, sondern den Spannungsregler. Der ist angegeben mit 11µA, mehr sparen geht wohl kaum :-)
Interessant. Mein Modul zieht gemaess Datenblatt 25mA tracking, 50mA acquisition, 75mA enhanced acquisition. Was auch immer das nun bedeutet. Fuer einen Hot Start benoetigt es 1 sekunde. Dh wenn ich alle 15 sekunden einen Punkt nehme, kann ich es 14 sekunden schlafen legen.
Da hab' ich halt andere Anforderungen, ich möchte wirklich jede Sekunde die Position aufzeichnen und 12-15h Batterielaufzeit sind für mich allemal ausreichend. Nur für eine von 15 Sekunden einschalten halte ich für nicht realistisch (der NL504 braucht länger), zumindest wird's der Genauigkeit nicht dienlich sein.
Dann wuerd ich dir mein Modul empfehlen. Zumindest vom Datenblatt her. Es braucht die Haelfte, und das PPS Signal ist auch moeglich. Es ist das Skytrack ST-22. Hab's aber noch nicht verbaut.
Ja, das Datenblatt klingt recht vielversprechend. Wo kann man diese Module beziehen?
Einse Suche nach GPS im Markt Forum hier : Beitrag "[V] Mini GPS Module - SkyTraq Venus 6 (22x22x8mm)" Der erste Post enthaelt die email. Um die 22 Euro.
Den Beitrag habe ich gestern Abend noch gefunden. Was mich etwas stutzig macht: wenn die Teile so gut sind, warum hört/findet man sonst kaum was darüber? Bei den dort angebotenen Modulen handelt es sich um die Variante ohne "Backup Supply"? Dann wird es wohl etwas schwierig mit einem Hot Fix in 1sec, oder hast Du etwas nachgerüstet? Ob dafür nur eine Batterie oder auch Flash benötigt wird, wurde mir zumindest auf den ersten Blick nicht klar. Hattest Du das Modul schonmal in Betrieb? Hat sonst schon jemand Erfahrung mit den Dingern?
Es gibt den Power Save mode. Dann kann man Parameter lesen und schreiben. Dh wenn ich neu starte und das Datum, sowie die Ephimeris Daten schreibe, dann muss die Einheit das schon mal nicht rausfinden. Den AVR Controller lasse ich natuerlich durchlaufen, der kann sich das alles merken. Ich hab die Hardware, aber noch nicht eingeschaltet. Liegt wegen Dringenderem zZ auf Eis.
Ich hab grad bei u-Blox nachgeschaut. Deren (zB Lea6) Verbrauch und Ansprechzeiten liegen auch in diesem Rahmen. Ich hab das ST22 wegen dem Sekundenpuls fuer eine Timinganwendung gewaehlt, und mach noch einen Tracker nebenher, ohne dringend darauf angewiesen zu sein.
Ich würde u.U. noch mal Platinen machen lassen. Hätte jemand Interesse? (6€ + Porto)
Hab mir nun auch mal ein Skytrack ST-22 bestellt. Zitieren hier alle nur aus dem Datenblatt, oder hat den auch schonmal jemand ausprobiert? Ok, ist sehr klein und günstig. Aber habe heute mal eine erste Fahrt damit aufgezeichnet und muss sagen, dass es mich nicht vom Hocker gehauen hat: auf der Autobahn war die Position für einige Zeit > 100-200m im Off, deutliche Überschwinger und Geschwindigkeit gemessen 170km/h bei gefahrenen 100km/h. Hat jemand ähnliche oder bessere Erfahrung damit? Werde bei Gelegenheit mal beide Logger mit verschiedenen Empfängern parallel fahren.
falls es weitere Erfahrungen gibt, nur zu. Wir lesen sehr interessiert mit. Wo kauft man günstig ein NL-504ETTL?
-> Preissuchmaschine, ca. 30-35€ Hab jedesmal woanders geordert, gibt wohl keinen konstant günstigen Händler.
Nochmal Feedback zum SkyTraq ST22: Nach Umkonfiguration auf "enhanced acquisition mode" und Backup-Versorgung über einen Goldcap sieht das Ergebnis nun ganz passabel aus. Insbesondere was die aufgezeichnete Höhe anging, war er im Vergleich zum NL-504 aber etwas unruhiger. Für meinen Anwendungsfall aber allemal ausreichend. Ohne Backup-Versorgung initialisiert der Empfänger Datum/Zeit immer mit 28.06.2006 11:59. Was insofern nervig ist, da ich aus der Uhrzeit den Dateinamen erzeuge. Es gibt im NMEA auch kein Flag, das die Gültigkeit der Uhrzeit anzeigt. Man muss dann also auf den ersten GPX-Fix warten, um eine gültige Zeit zu bekommen. Daher macht das Nachrüsten einer Backup-Versorgung auf jeden Fall Sinn. Ich lade demnächst noch eine aktualisierte Firmware für den Logger hoch, die das Problem mit gleichem Startdatum/-zeit des ST22 umgeht.
Hallo Arne, super Projekt! Ich habe für Testzwecke noch ein SkyTraq ST01 Modul auf einer Prototypplatine ständig am Fenster liegen. Ich hätte eventuell auch Interesse an 1/2 Platinen. Nimmst du da noch eine Layoutänderung bezüglich den Skytraqs vor? Ist ja aber eigentlich nicht notwendig. Kennt jemand den Unterschied zwischen dem ST01 und dem ST22 ohne groß die Datenblätter zu wälzen. SD-Kartenhalter habe ich auch einige und müßte vorher noch prüfen ob ich die da ranbringe. So könnte ich mein gefrickel etwas ordnen. Ich benutze bisher nur die serielle Schnittstelle zum PC (mit Adapter) für PC Testzwecke.... MfG Achim
Hallo Achim, eine Layoutänderung sollte nicht nötig sein. Ich habe bewusst GPS-Modul, Ladebuche, Taster etc. über Kabel mit der Platine Verbunden, um nicht von ganz bestimmten Bauteilen abhängig zu sein. Ich kenne den Skytraq ST01 nicht. Laut Datenblattblatt Vcc 3,3V, RX/TX vermutlich TTL level, (zusätzlich sogar SPI), NMEA u.a. GGA und RMC, sollte also passen - nichts, was sich nicht notfalls in der SW ändern lassen sollte. Platinen habe ich noch nicht machen lassen, bisher haben sich noch keine weiteren Interessenten gemeldet. Ich bräuchte aber auch noch eine, da mein Logger zusammen mit meiner Kompaktkamera 'verschwunden' ist... :-( Also wer noch Interesse an Leerplatinen hat, bitte melden. Bei genügend Interessenten würde ich nochmal ordern. Grüße Arne
Ich habe nun doch noch eine automatische Kalibrierung des RC-Oszillators implementiert. Zuerst habe ich probiert, die Kalibrierung anhand der Pulsweiten des seriellen Signals durchzuführen. Während das mit dem Skytraq einwandfrei funktionierte, hatte ich mit dem NL-Modul Probleme. Stattdessen synchronisiere ich nun auf die sekündliche GPS-Datenübertragung (in der Annahme, dass diese gemittelt über mehrere Sekunden hinreichend genau ist) und führe OSCCAL laufend nach. Hierzu muss INT1 mit RXD verbunden werden, alternativ könnte natürlich auch ein evtl. vorhandener 1PPS Ausgang des GPS-Moduls verwendet werden. Das funktioniert nun sehr gut. Beim Testen hat sich aber gezeigt, in welchem weiten Bereich von OSCCAL-Werten die USART-Übertragung dennoch fehlerfrei funktioniert, so dass auch ein einmalig abgestimmter Oszillator bei der zu erwartenden Temperaturdrift wohl ausreichend genau wäre, aber so ist es natürlich noch schöner. Als weitere Änderung werden die USART-Daten nun gepuffert über Interrupts eingelesen. Die neue Software gibt's wieder hier: http://friedrichs-bs.net/GPX-Logger.html So, nun ist der mega8 endgültig ausgelutscht, mehr passt wohl wirklich nicht... Falls ich noch mal einen baue, kommt da wohl gleich ein mega328 drauf ;-)
Hallo,
ich habe ein Problem bei der Auswertung der NMEA Daten.
Habe die Software auf ATmega88PA portiert. Soweit funktioniert auch
alles gut. Bis auf die Auswertung der GGA/RMC Daten.
Ich sende über UART NMEA Testdaten an den Controller. Allerdings schlägt
der Vergleich in NMEA_IsDataComplete() immer fehl. (Füge ich hier ein
return 1 ein, dann werden Daten auf die Karte geschrieben)
Mit folgender Debug Ausgabe in NMEA_IsDataComplete():
--------------
USART_WriteChar(nmea_time_rmc[0]);
USART_WriteChar(nmea_time_rmc[1]);
USART_WriteChar(nmea_time_rmc[2]);
USART_WriteChar(nmea_time_rmc[3]);
USART_WriteChar(nmea_time_rmc[4]);
USART_WriteChar(nmea_time_rmc[5]);
USART_WriteString("-");
USART_WriteChar(nmea_time_gga[0]);
USART_WriteChar(nmea_time_gga[1]);
USART_WriteChar(nmea_time_gga[2]);
USART_WriteChar(nmea_time_gga[3]);
USART_WriteChar(nmea_time_gga[4]);
USART_WriteChar(nmea_time_gga[5]);
USART_WriteString("\n");
if ( (nmea_time_rmc[....
-------------
bekomme ich bei diesem Datensatz:
$GPGGA,100052.939,5408.0683,N,01346.0447,E,1,07,1.2,36.8,M,,M,,*7D
$GPRMC,100052.939,A,5408.0683,N,01346.0447,E,2.794507,126.959198,200804,
,*01
folgendes (terminalprog.):
100052-100052
100052-7<\0>0052
100052-100052
100052-7<\0>0052
100052-100052
100052-7<\0>0052
100052-100052
100052-7<\0>0052
Obwohl die gesendeten Daten immer zusmamen passen hakt es irgendwie. 1x
greift der Vergleich und es werden Daten auf die Karte geschrieben aber
anschließend ist die GGA timestamp irgendwie verstümmelt.
Woran kann das denn liegen? Bzw. wo kann ich ansetzen um eine Lösung zu
finden?
Danke!
Welche SW-Version verwendest Du? Welches GPS-Modul? Oder sendest Du direkt vom PC an den Controller? Schaue ich mir heute Abend im Code mal genauer an. BTW: die Mega 88/168/328 haben meines Wissens eine abweichende interne ADC Referenzspannung (1,1V ?) Der Spannungsteiler zur Messung von Vcc muss entsprechend angepasst werden.
Ich verwende Version 1.2 und hab die Schaltung + Software auf den mega88 angepasst. (1.1V Referenz, 8MHz int. RC Osc ...) Änderungen SW: SPI config auf 1MHz, UART Registernamen, Vcc_min 218, HW: R4-4k7, R2-100k, R1-220k Alles was SD-Card schreiben und Schalter ON/OFF betrifft, funktioniert schon. Lediglich die Sache mit den den Daten nicht. Ich sende momentan per PC (Terminalprogramm HTerm), da ich das GPS Modul nich nicht hab. Wenn ich wie beschrieben die Funktion NMEA_IsDataComplete() auf return 1 setze, dann schreibt er mir alle Datensätze richtig in das GPX File auf der SD Karte.
Hallo Arne, nur aus Neugierde. Wäre es da wegen dem Timing nicht einfacher gewsen noch einen Quarz (SMD) drauf zu machen, Platz wäre doch noch da? Oder was spricht dagegen? Vielen Dank Rainer
Hallo Rainer, nein, es spricht nichts gegen einen Quartz. Hatte nur keinen vorgesehen und es geht halt auch ohne. Gruß Arne
Hallo unrouted, ich würde testweise den µC auf 2MHz einstellen, zumindest die Kalibierung ist darauf ausgelegt. Die Kal. kannst Du dann auch mal abschalten -> #define CLKCAL_FEAT_OSC_CALIBRATION auskommentieren. Wie sendest Du die Daten über das Terminalprog.? Ganze Datei in einem Rutsch oder hast Du irgendein Timing? --> evtl. probehalber Zeilenweise von Hand reinkopieren, so dass der µC nicht komplett geflutet wird. Gruß Arne
Hallo Arne, die Kalibrierung hab ich gleich am Anfang komplett rausgeschmissen. Habe mehrere Varianten probiert. Komplettes File auf einmal und auch GGA+RMC-->lange_Pause-->GGA+RMC-->lange_Pause... Auch RMC und GGA vertauscht. Hat anscheinedn ein wenig Einfluss. Habe nun außerdem die Debug-Ausgabe über UART direkt in parse_RMC/GGA eingebaut und dann bringt er immer die richtige Uhrzeit. So einfach geht das mit den 2MHz nicht, da sich der interne Oszillator nicht auf 2 stellen lässt.
Habe zumindest noch ein Problem gefunden: die Arrays nmea_speed und nmea_course sind für Dein NMEA-Format zu klein dimensioniert (wer rechnet schon mit 6 Nachkommastellen... ;-). Für die anderen Felder habe ich die Array-Size beim Lesen berücksichtigt, bei diesen steht leider noch ein 'todo' im Code - ärgerlich --> dann wird's wohl doch noch mal ein neues Release geben... Die letzte Ziffer von Speed "2.794507" schreibt dir vermutlich den GGA-Timestamp kaputt. Zwei Möglichkeiten: Entweder die Arrays auf mindestens 11 Zeichen vergrößern, oder besser das memcpy für speed und course in NMEA_ParseRMC auskommentieren. Die Felder werden ohnehin nicht verwendet (gleiches gilt für hdop und satellites). Reihenfolge von RMC und GGA ist egal: Mittels NMEA_IsDataComplete() wird nach jedem Datensatz geprüft, ob RMC und GGA denselben Zeitstempel haben. Daher jedes 2. Mal NMEA_IsDataComplete()==0! Nur bei gleichem Zeitstempel werden Daten ausgewertet und auf SD-Karte geschrieben.
Danke! Das war ein guter Tip! Hab beides auskommentiert. Funktioniert nun einwandfrei!
na wunderbar! Für den Fall, dass ich evtl. doch mal einen mega 168/328 verbauen sollte: könntest Du mir den an den mega88 angepassten Quellcode per Mail schicken? Würde mir etwas Arbeit ersparen - danke.
Habe wg. des möglichen Array-Überschreibers eine neue Software Version 1.3 hochgeladen (Link s.o.). Wer ebenfalls ein GPS-Modul verwendet, dass sich zutraut, Kurs und Geschwindigkeit mit mindestens 6 Nachkommastellen zu berechnen, sollte die neue Software verwenden - alle anderen können getrost darauf verzichten... ;-)
Angehängte Dateien:
-
20111229_068.jpg
46 KB
Ich hätte grad noch eine Platine übrig. AT mega8 ist bestückt und programmiert, sonst nackt (s. Bild). Würde ich für 10€ inkl. Porto (Brief, D) abgeben, bei Interesse bitte melden.
Ich habe heute einen wichtigen Hinweis erhalten: In die ursprüngliche Beschreibung der Fuses hatte sich ein Fehler eingeschlichen. Das Fuse High Byte darf natürlich nicht 00 sein, sondern wurde von mir gar nicht programmiert. Richtig sind folgende Einstellungen: - Int. RC Osc. 2 MHz; Start-up time: 6 CK + 64ms - enable Brown-out detection at VCC=2.7 V Fuse bytes: low: 0xA2 high: 0xD9
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.