Hallo Leute! Ich bin mir nicht sicher ob mein ATMega ganz richtig tickt (wahrscheinlich liegt aber der Fehler wie immer bei mir ;) ) Mein Setup: ATMega88 Master am SPI, mode 0. U-Blox GPS-Modul als Slave. Ich kann die Ausgaben des Slave in den AT einlesen und auf einem Display darstellen. Alles ok. Aber der Slave scheint mit meinen Eingaben vom Master nicht zurecht zu kommen. Ich habe mir die Signale per Oszi angesehen und festgestellt, dass der Master den Pegel auf Mosi zwischen den SCK-Pulsen auf high zieht, der Slave dagegen Miso zwischen den SCK-Pulsen auf low. Siehe Anhang. Kann das Kommunikationsproblem hier liegen? Falls ja: Wie teile ich meinem AT mit, dass er mosi zwischenzeitlich auf low ziehen soll (wie es der slave ja auch tut)? CPOL beeinflusst ja nur SCK, genau so eine Einstellungsmöglichkeit bräuchte ich dann aber ja für mosi. Oder muss ich den SPI dann softwareseitig implementieren? Vllt erledigt sich damit auch mein letzter Post:Beitrag "U-Blox Problem mit UBX CFG-MSG Set" Ich wäre dankbar für jegliche Anregung, weiß langsam echt nicht mehr was ich noch ausprobieren könnte... VG David
Angehängte Dateien:
-
oszi.jpg
88 KB
Zumindest Maxim scheint das anders zu machen als mein AT hier, vgl: http://media.maxim-ic.com/images/appnotes/3891/3891Fig03.gif
Hm. Habe den SPI als Software selbst nachgeschrieben und ziehe den mosi zwischen den sequezen nun auf low. No effect :( Also werde ich wohl weitersuchen warum nix geht....wenn irgendwer schonmal mit einem u-blox modul gearbeitet hat wäre ich dankbar für jede Hilfe!
Hallo David. >Vllt erledigt sich damit auch mein letzter >Post:Beitrag "U-Blox Problem mit UBX CFG-MSG Set" .... >Ich bekomme die NMEA-Messages TXT, RMC und VTG, aber kein GGA.... Das klingt aber sehr merkwuerdig. Wenn das Teil korrekt implementiert wurde sollte es zunaechst mal so sein: Default messages: GSV, RMC, GSA, GGA, GLL, VTG, TXT Da muss man lt. Datenblatt nix konfigurieren. Mit "mode 0" meinst Du das hier ?: The CFG_GPS0 pin is shared with the SPI Clock pin. When using Eco Mode and SPI, pull CFG_GPS0 low during startup and then release it. Irgenwie scheint in Deiner SPI-Mimik ein Fehler zu stecken. Wenn Du die Konfiguration aenderst: Any messages in Class CFG sent to the receiver are acknowledged (with Message ACK-ACK (0x05 0x01) ) if processed successfully, and rejected (with Message ACK-NAK (0x05 0x00) ) if processing the message failed. Bekommst Du eine der beiden Messages als Antwort? Ich wuerde es erstmal so versuchen um den Fehler einzugrenzen: Auf SPI-Versuche verzichten und stattdessen Kommunikation via UART, mit CFG_COM0/1 pins auf 1 und 9600-8N1, ohne Eco Mode zu aktivieren. Erst wenn das funktioniert (also alle default messages ausgegeben werden) wuerde ich mit SPI weitermachen. Konfigurationsaenderungen halte ich aber fuer komplett ueberfluessig da das Modul per default bereits GGA ausgeben muss, mehr wolltest Du ja nicht, oder? juergen
Hallo Jürgen! Vielen Dank für Deine Mühe! Ich hatte schon befürchtet, dass sich hier sonst niemand mit dem u-blox befasst :) > sollte es zunaechst mal so sein: > > Default messages: > GSV, RMC, GSA, GGA, GLL, VTG, TXT > Da muss man lt. Datenblatt nix konfigurieren. Ganz am Anfang als ich noch keine Befehle rausgeschrieben habe kamen TXT, RMC, VTG und GGA aber kein GSA oder GSV. Nicht so schlimm, ich hätte eh nur RMC und GGA gebraucht. Ich wollte GGA gern auf eine andere Rate umkonfigurieren, also habe ich eine CFG-MSG mit der Cls/id der GGA gesendet. Ergo: GGA wurde nicht mehr gesendet. Auch nicht nach einem Powercycle (also Strom aus, Strom an). Und das obwohl ich nie CFG-CFG zum speichern gesendet habe....sehr seltsam alles. Um dieses Verhalten zu verifizieren habe ich das gleiche mit VTG gemacht, wieder habe ich es "geschafft" die Message dauerhaft zu deaktivieren. Egal welche Rate oder welchen Port ich in der CFG-MSG spezifiziert habe, die Messages werden einfach nicht mehr ausgegeben. :( Ich habe das ganze schon dem u-blox support geschildert, deren Vermutung ist dass es ein "general communication problem" gibt ;) > Mit "mode 0" meinst Du das hier ?: SPI-Mode 0 meint CPOL=0 CPHA=0. > The CFG_GPS0 pin is shared with the SPI Clock pin. When using Eco Mode > and SPI, pull CFG_GPS0 low > during startup and then release it. Hm, das habe ich zwar gelesen, bislang aber nicht in meine Überlegungen mit einbezogen, guter Hinweis! > > Irgenwie scheint in Deiner SPI-Mimik ein Fehler zu stecken. Hmpf, ja, scheint so. Da ich den Hardware-SPI im Atmel benutzt habe und die gleichen Ergebnisse mit meinem selbst geschriebenen Software-SPI bekomme muss irgendwas grundsätzliches falsch sein... > Wenn Du die Konfiguration aenderst: > Any messages in Class CFG sent to the receiver are acknowledged (with > Message ACK-ACK (0x05 0x01) ) if processed successfully, and rejected > (with Message ACK-NAK (0x05 0x00) ) if processing the message failed. > > Bekommst Du eine der beiden Messages als Antwort? Nein, leider nicht. Das Modul ändert sein Verhalten dahingehen, dass die NMEA-Message die im Befehl erwähnt wird einfach nicht mehr gesendet wird. Das Modul gibt ansonsten keinerlei Reaktion. Es sendet die verbliebenen NMEA-Messages und dann nur noch 0xff. > Ich wuerde es erstmal so versuchen um den Fehler einzugrenzen: > Auf SPI-Versuche verzichten und stattdessen Kommunikation via UART, mit > CFG_COM0/1 pins auf 1 und 9600-8N1, ohne Eco Mode zu aktivieren. > Erst wenn das funktioniert (also alle default messages ausgegeben > werden) wuerde ich mit SPI weitermachen. OK, wird wohl das beste sein. Ich hatte gehofft dass der spi vergleichsweise einfach zu händeln ist. Dann mach ich mich mal wieder ans löten, nen rs232 adapter bauen. > Konfigurationsaenderungen halte ich aber fuer komplett ueberfluessig da > das Modul per default bereits GGA ausgeben muss, mehr wolltest Du ja > nicht, oder? Eigentlich nicht, ich wollte das Modul halt gern verstehen, ggf. überflüssige Nachrichten abschalten (txt, vtg,...). Zu viel dran rumgespielt, ups ;) Vielen Dank für Deine Beteiligung, ich werde berichten wie sich das ganze weiterentwickelt. VG David
Hallo David. >...Ich hatte schon befürchtet, dass sich hier sonst niemand mit dem u-blox >befasst :) Tu ich auch nicht, ich benutze Motorola M12M. Aber gelegentlich schau ich mir an was u-blox und anderen Herstellern so einfaellt. :) >Ich habe das ganze schon dem u-blox support geschildert, deren Vermutung >ist dass es ein "general communication problem" gibt ;) Ei wer haette das gedacht :) >Ganz am Anfang als ich noch keine Befehle rausgeschrieben habe kamen >TXT, RMC, VTG und GGA aber kein GSA oder GSV. Nicht so schlimm, ich >hätte eh nur RMC und GGA gebraucht. Ich wollte GGA gern auf eine andere >Rate umkonfigurieren, also habe ich eine CFG-MSG mit der Cls/id der GGA >gesendet. Ergo: GGA wurde nicht mehr gesendet. Auch nicht nach einem >Powercycle (also Strom aus, Strom an). Und das obwohl ich nie CFG-CFG >zum speichern gesendet habe....sehr seltsam alles.... Hast Du mal CFG-CFG clear probiert um die default Konfiguration wieder herzustellen? Hast Du eine back-up Batterie am Modul? Falls ja nutzt power on/off nix, dann speichert das Modul auch ohne CFG-CFG. juergen
Hi! > Tu ich auch nicht, ich benutze Motorola M12M. Aber gelegentlich schau > ich mir an was u-blox und anderen Herstellern so einfaellt. :) Hey, der sieht auch spannend aus :) Bekommt man den relativ leicht irgendwoher? Wenn ja: wo? Hast Du bislang gute Erfahrungen damit gemacht (habe ja keinen Treueeid u-blox gegenüber geschworen ;) )? > Hast Du mal CFG-CFG clear probiert um die default Konfiguration wieder > herzustellen? Nee, habe mich noch nicht getraut Befehle zu senden die sich auf mehr als eine einzelne Message beziehen ;) > Hast Du eine back-up Batterie am Modul? > Falls ja nutzt power on/off nix, dann speichert das Modul auch ohne > CFG-CFG. Nope, nur ein Netzteil. Das ist ja das seltsame. VG David
Hi. >Hey, der sieht auch spannend aus :) Bekommt man den relativ leicht >irgendwoher? Wenn ja: wo? Hast Du bislang gute Erfahrungen damit gemacht >(habe ja keinen Treueeid u-blox gegenüber geschworen ;) )? Ich hatte mich anfangs intensiv mit den Manuals und Specs und vor Allem den proprietaeren Protokollen von u-blox, Trimble und Motorola auseinandergesetzt und dann fuer Motorola entschieden. Ich habe den M12M (und den Vorgaenger M12+) als engineering samples im Einsatz, sowohl die Timing Engine als auch die Positioning Engine. Laufen seit 3 Jahren in handheld GPS-Geraeten fuer extreme Temperaturbedingungen klaglos, auch noch unter -40 Grad. Kaufen kann man den M12M inzwischen bei Synergy oder BFI Optilas. http://www.synergy-gps.com/ >> Hast Du mal CFG-CFG clear probiert um die default Konfiguration wieder >> herzustellen? >Nee, habe mich noch nicht getraut Befehle zu senden die sich auf mehr >als eine einzelne Message beziehen ;) Das kann man auf einzelne messages begrenzen ;) lg juergen
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.