A-GPS für die Canon SX280

Manchmal muss man alte Beiträge nochmal ausgraben.

Canon hat letztes Jahr angekündigt, ab 1. Januar 2020 keine A-GPS-Daten mehr für die SX280 anzubieten. Diese ermöglichten, einen Cold Start des GNSS-Empfängers auf wenige Sekunden zu verkürzen. Die Meldung ging an mir komplett vorbei, nicht aber Andreas, von dem der Hinweis kam.

Er konnte auch direkt bestätigen, dass auf den Servern von Canon die Datei zwar noch angeboten wir, der Inhalt aber einen Stand vom 05.01.2020 aufweist.

Um es kurz zu machen: Zum Stand meines alten Artikels hat der Download von http://epodownload.mediatek.com/EPO.DAT funktioniert und entsprach der Datei \DCIM\CANONMSC\GPS\CAGM01.EED auf der Speicherkarte der Kamera. Das ist auch heute noch so.

Keine Ahnung, was man mit dieser Information anfangen kann…

Zugegebenermaßen: die olle Knipse verwende ich nicht mehr wirklich, hat sich im Urlaub vor zwei Jahren aber noch ganz passabel als Notfallkamera und vor allem als GPS-Logger bewährt.

GPS-Logging habe ich bisher nicht mit dem Telefon gemacht, da es zumindest früher immer wahnsinnig Akku gesaugt hat – aber auch hier hat Andreas einen Tipp: https://gpslogger.app – ohne, dass ich es bis jetzt getestet habe.

Noch ein weiterer Hinweis von ihm:

[…] scheint täglich um 05:55

(tDiff +6h, dh kurz vor TW-Mitternacht!?) upgedatet zu werden.

Info zur Struktur der Datei gefunden:

https://github.com/mru00/crane_gps_watch/tree/master/snoops

[…]

Noch eine andere Anmerkung (meinerseits) zur Thematik: „It’s all fun and games, until they shut down the servers.“ – Bei enorm vielen neuen Geräten sind Dienste im Internet mehr oder weniger zwingend erforderlich oder ein Teil des Produkts – wie man schon ein paar Mal gesehen hat und in Zukunft noch viel öfter sehen wird: irgendwann ist das Zeug zu legacy oder schlicht und ergreifend die Firma hinter dem Produkt zu Pleite und die Investition ist verloren.

Daher ist meine Meinung: Wenn ein Produkt nicht mehr unterstützt oder gar begraben wird, sollte es oder deren Services an die Community übergegeben werden. Der IP (intellectual property) ist für den Hersteller eh nicht mehr interessant oder zumindest überholt und so kann Landfill und Sicherheitslücken vermieden und die die Kunden bei Laune gehalten werden. Natürlich entspricht das nicht dem Ziel gewinnorientierter Firmen, deswegen sollte hier auch etwas aus der Regierung kommen.

…und er loggt doch.

Nachdem ich gestern nun die Dose des Neo geöffnet habe, gab es nichts mehr zu verlieren.

Da die Leiterbahn zum (de-)aktivieren des externen Flashs auch unter dem GNSS-Chip mit Masse verbunden ist, muss der erst einmal runter. Ich habe zwar schon einen BGA mit knapp 1200 Balls und extremer thermischer Masse erfolgreich getauscht, allerdings mit entsprechendem Equipment. Bei Tausch von kleinen QFNs habe ich mich bis jetzt aber erstaunlich blöd angestellt. Entweder zu viel Flussmittel oder zu viel Lötzinn. Dabei tanzt der Chip beim Erhitzen lustig vor sich hin, senkt sich aber nicht richtig ab. Dann ist ein Re-Rework fällig. Schlecht fürs Material aber meistens klappt es.

Aber zuerst muss der IC runter. Mit Heißluft bei etwa 380-400 °C und niedrigem Luftstrom (damit es keine anderen Bauteile wegpustet) um die Bauteile kreisen um die Komponenten nicht zu schnell zu erwärmen. Kurz nachdem das noch vorhandene Flussmittel verflüssigt, sieht man auch eine leichte Glanzveränderung am Lötzinn – der „sweet spot“ zum Herunterpicken der Bauteile ist kurz danach.

Nach etwas Geduld zum Abkühlen der Leiterkarte sieht man, dass nur ein einziger verdammter Pin mit der Massefläche verbunden ist. Man muss nicht raten, welcher das ist:

Mit etwas Flussmittel und Entlötlitze kommt das bleifreie Zeug zunächst runter, um es anschließend mit einer dünnen Neuauflage Sn60Pb40 zu ersetzen. Dabei habe ich den Pads außenherum mehr Zinn gegeben als der Massefläche unter dem Chip. Natürlich darf das Auftrennen der Masseverbindung zu Pin 29 nicht fehlen. Wer den Unterschied zwischen bleifrei und bleihaltig nicht kennt: Bildvergleich – bleifrei (oben) ist ziemlich matt, bleihaltig glänzt deutlich stärker:

Zwischen dem Verzinnen und wieder Bestreichen mit Flussmittel einmal mit Isopropanol waschen – Beim Ent-, Ver- und wieder Entzinnen entsteht Zunder und manchmal backt das Flux fest – das will man nicht unter Bauteilen haben. Anschließend ist der Chip dran, der ebenfalls vom Bleifrei-Lot befreit wird. Mit dopptelseitigem Klebeband auf dem Tisch bleibt er auch nicht am Lötkolben hängen.

Hier im Prozess: vertrocknetes Flux und noch nicht ganz verzinnte Pins. kleine Zinnkleckse auf der Massefläche (hier rechts oben) sollten entfernt werden, da sie den Lötprozess stören.

Nun kann der IC wieder platziert und verlötet werden. Wieder mit Heißluft mit wenig Pust und schön warm. Das Ergebnis ist gut aber nicht perfekt – der Käfer ist etwas verschoben, was aber kein Problem sein sollte:

Um vorab zu testen ob der Empfänger noch funktioniert, habe ich Pin 29 wieder gebrückt und das Modul mit Strombegrenzung (!) an den PC angeschlossen. Alles kommt hoch und nach ein paar Minuten habe ich einen GPS-Fix. Zu Glonass-Empfang lässt sich das Teil aber nicht bewegen, vielleicht aufgrund des fehlenden Shieldings?! 😉

Ok, Grundlegend funktioniert es also, aber wird der Empfänger auch mit externem Flash spielen? Ich konnte einen QSPI-Flash von Winbond ergattern. Mal schauen, ob es funktioniert.

Laut Hardware Integration Manual des UBX-G7020 (!) ist die Anschlussbelegung wie folgt (ob sie auch mit dem M8030 funktioniert?):

  • PIO0 (25) -> DI/IO0
  • PIO4 (26) -> CLK
  • PIO2 (27) -> !WP/IO2
  • PIO1 (28) -> DO/IO1
  • PIO5 (29) -> !CS
  • PIO3 (30) -> !HOLD/!RESET/IO3

GND sollte klar sein, Vcc habe ich aus Ermangelung anderslautender Tatsachen einfach an die Versorgung des Chipsatzes geklemmt.

Wieder ans Netzteil mit Strombegrenzung geklemmt: Keine Auffälligkeiten – was aber noch nicht heißt, dass es auch funktioniert. Die Wahrheit erfährt man erst, wenn man den Speicher nutzen kann, also ran an den PC und u-center wieder öffnen. Die Firmware findet sich – im Gegensatz des vollen Datenblatts – auf der Website von u-blox. Nach Anstoßen des  Updates und nicht ganz einer dreiviertel Minute warten liegt schon fast ein NEO-M8N auf dem Tisch (wären da nicht die Fädeldrähte):

Nun funktioniert auch das Logging – Mission accomplished! 🙂

u from the blox

Ich wollte schon immer mal mit GNSS-Modulen von u-blox arbeiten. Mittlerweile liegen auch ein paar Module herum. Beim „aktuellsten“ sollte es ein NEO-M8N werden, hauptsächlich, weil es relativ stromsparend in den internen Flash loggen kann und auch ansonsten relativ viel zu bieten hat.

Da die Module zwar direkt vom Hersteller erhältlich, in kleinen Stückzahlen aber sehr teuer sind, ein Blick auf eBay. Mit Antenne, kleiner Leiterkarte und und Versand mit dem Namen „GY-GPSV3-NEO“ gibt es sie schon für um die 12 Euro, also her damit! Bis es der Empfänger aus China hierher geschafft hat dauert zwar 4-8 Wochen, ohne besonderen Leidensdruck kann man das aber gut abwarten.

Packung auf und mit einem USB<>UART-Adapter an den PC – nach kurzer Zeit gibt es einen Fix und ich kann zusehen, wie die Position im Umkreis von ein paar Metern umher eiert, so weit, so gut.

Als ich in u-center (der Software zum Testen und Konfigurieren der Empfänger) Logging testen wollte passierte – nichts.

Ok, vielleicht ist eine alte Firmware drauf. Es gibt eine neuere, diese lässt sich aber nicht flashen, auch mit verschiedenen Einstellungen. Hmpf. Bin ich einem Fake aufgelaufen?

Wie sich herausstellt: ja!

Schaut man sich das Label auf dem Modul an, fällt auf, dass das Firmenlogo ausgefranst und alle runden Symbole nicht wirklich rund sind. Die Schrift passt ebenfalls nicht. Hmm, warum hat das Modul auf der eBay-Seite eigentlich die genau gleiche Seriennummer? Ist das die Nummer für die gesamte Serie?!? Klickt man sich durch die Google-Bildersuche sticht ins Auge, dass alle Module eine Datamatrix haben. Mein Modul dagegen hat einen QR-Code. Was steht da eigentlich drin? Kurz mit dem Handy gescannt: „NEO-6M-0-0001 […]“ – ich dachte, das wäre ein M8N? Nanu? Gibt man dem Modul Strom, nachdem es per UART am PC angeschlossen ist, bekommt man Infos vom Bootloader. Dort steht wiederum M8:

$GNTXT,01,01,02,u-blox AG - www.u-blox.com*4E
$GNTXT,01,01,02,HW UBX-M80xx 00080000 *43
$GNTXT,01,01,02,ROM CORE 2.01 (75331) Oct 29 2013 13:28:17*4A
$GNTXT,01,01,02,PROTVER 15.00*01

eBay-Käuferschutz zum Glück bekomme ich, nachdem mich der Händler dann doch nochmal versucht abzuziehen („Bitte den Fall schließen, damit wir das Geld auszahlen können“ – ja ne, is klar), kam das Geld zurück. Aber was nun mit dem Modul? Richtig nutzlos ist es nicht, aber doch irgendwie – weil es eben die Funktionen, für die ich es gekauft habe, nicht kann.

Aber wenn da schon ein M8 drin ist, dann sollte das doch grundsätzlich funktionieren. Gleichzeitig wäre auch interessant, was da überhaupt drin ist. Im Forum von u-blox konnte ich zumindest ein Foto mit Original und Fälschung finden. Auf dem Original sitzt ein 25Q16DV (QSPI-Flash) von Winbond, auf dem Fake nicht.

Also runter mit dem Kopf! Aber bitte so, dass es danach noch funktioniert.

Hier mal eine kleine und überaus dilettantische Collage des Shieldings von allen vier Seiten:

Am gleichmäßigsten geht es wohl runter, wenn man alles mit Heißluft erwärmt und dann den Blechdeckel abhebt. Bei meinen Fähigkeiten rutscht es in der Regel aber erst mal zur Seite und nimmt ein paar SMD-Komponenten bei denen man nie wieder herausfindet, wie sie mal drauf waren.

Nachdem das Shielding nur an ein paar Punkten aufgelötet ist, geht es auch mit dem Lötkolben. Lötzinn als Wärmebrücke auf das Blech, Schraubendreher in den Spalt einklemmen und anschließend erhitzen und vorsichtig hebeln. Leider lässt sich die Leiterkarte erstaunlich leicht delaminieren, hat es aber augenscheinlich ganz gut überstanden:

Kein Flash. In den Unweiten des Internets lässt sich keine Pinbelegung des M8030-KT finden. Wohl aber des Vorgängers G7020 (im Hardware Integration Manual, um zumindest ein Suchwort zu geben). Die Chips gleichen sich der Beschaltung ziemlich stark – warum sollte man auch ein bestehendes – durchaus komplexes – Design ohne Not ändern?

Wie auch immer, Pin 25-30 (rechts oben am Chip im Bild) sind IOs und werden – zumindest beim 7020er – für externen Speicher genutzt. Pin 29 definiert, wenn auf GND gezogen, dass nur der interne ROM verwendet wird. Die 3 Pins darunter legen in dieser Konstellation ein paar Konfigurationen fest. Das Bild im u-blox-Forum korreliert zumindest soweit man es erahnen kann mit dieser Information. Wäre nicht dieser dämliche Pin 29 mit der Massefläche verbunden. Bleibt zu hoffen, dass er das nur von außen und nicht auch von hinten ist. Ich befürchte aber, …

Ein Schnitt mit dem Skalpell später und „pieeep“ sagt das Multimeter – meh. 🙁

Ende für Teil 1.

Ganz Problemfreie Software?

Einen Nachtrag muss ich zur GPS-Geschichte meiner Canon-Kamera noch machen: der Support hat mir versichert, dass die A-GPS-Daten auch bei der fehlenden Anzeige des Gültigkeitsdauer an das Modul weitergegeben werden. Das wollte ich zunächst nicht so wirklich glauben, aber auch nicht beweisen. Die „Gute“ soll zu bleiben.

Einen Unterschied der beiden Kameras habe ich noch gefunden: Aufgrund von Problemen bei der Akkulaufzeit während Videoaufnahmen gab es mal ein Firmware-Update. Die „gute“ hat es, die andere nicht. Nachgezogen habe ich noch nichts, aber es wäre noch einen Versuch wert – allein um zu sehen, ob das Verhalten konsistent ist und um auszuschließen, dass die Firmware der „guten“ einen Knall hat.

Um das vermeintliche Problem mit den Assist-Daten zu checken, habe ich mehrfach die TTFF (time to first fix), also die Dauer vom Einschalten des Empfängers zum Ermitteln der Position, gestoppt. Mit und ohne A-GPS-Daten. Um verlässliche Ergebnisse zu erhalten, gab es mehrere Messläufe. Zwar unter dem Dachfenster aber mit freiem Blick in den Himmel. Die Scheibe ist nicht metallisiert, hat also nicht allzu viel Dämpfung. Das Tablet braucht an der Stelle (ok, mit genauer Zeit und Hilfsdaten) nur wenige Sekunden für einen Fix.

Die Messung selbst ist etwas nervig – die Kamera schaltet nach 30 Sekunden das Display ab und man sieht nicht mehr, ob ein Fix zustande gekommen ist. Eine Anzeige der Details zum Status des Empfängers hat sich der Hersteller nämlich gänzlich gespart. Das Drücken zu automatisieren habe ich mir gespart. Also blieb nichts anderes übrig als alle 25 Sekunden irgendeine Taste zu drücken. Um gleiche Ausgangsbedingungen zu schaffen wurde vor jeder Messung der Akku entnommen und ungefähr 10 Sekunden gewartet.

Nach längerem Warten war ich zumindest etwas schlauer: ohne Hilfe bis zu 17 Minuten, mit zwischen 4 und 7 Minuten. Aufgrund der nicht sonderlich großen Reihe und den nicht idealen Bedingungen sind die Werte allerdings mit Vorsicht zu genießen. Für verlässliche Messungen müsste das Ganze unter freiem Himmel, bei gutem Wetter und gleichbleibender Satellitenkonstellation durchgeführt werden – mal schauen, ob dafür die nächsten Tage Zeit übrig bleibt.

Auch wenn der TTFF – verglichen mit anderen Empfängern – einigermaßen bescheiden ist, scheint A-GPS zu funktionieren. Mein Anfangsverdacht Nr 2 hat sich also verhärtet: jemand in der Software hat es verkackt. Könnte schlimmer sein, aber schön ist es trotzdem nicht.

Über Spannungen und deren (Einschalt-)folgen

Was ist cooler als ein Logic 16 von Saleae? Natürlich ein Logic Pro 16!

Neben den 16 Kanälen, die (bei 4 Kanälen) mit bis zu 500 MS/s samplen können (100 MS/s bei 16 Kanälen) kann man selbige auch analog aufzeichnen lassen. Das macht die Sache zwar langsamer und es benötigt sehr viel Speicher, aber es bieten sich interessante Möglichkeiten. Nein, es wird kein Oszilloskop daraus. Auch wird es kein Datenlogger. Das Gerät eröffnet wie ich finde eine neue Geräteklasse – einen Hybriden, der es ermöglicht, für Oszilloskope zu breite Busse digital zu analysieren und dabei – wohl bemerkt in den gegebenen Grenzen – auch das Analogverhalten der Signale anzusehen.

Es gibt einen Anwendungsbereich, für den der Pro wie geschaffen ist: Power-up-Sequenzen. Als Bastler kennt man sie nicht, weil man sie nicht braucht. In komplexeren Systemen gibt es oft viele Spannungen, deren Einschaltreihenfolge und teilweise auch die Art des Einschaltens von großer Wichtigkeit ist, da sonst Komponenten entweder nicht richtig funktionieren oder sogar Schaden nehmen. Nehmen wir einfach mal ein Handy: Beim Einschalten bekommt die CPU nicht einfach Strom, zunächst muss das Power Management hochfahren, das den Rest regelt. Anschließend bekommt der Arbeitsspeicher Strom, dann der Prozessor. Dann kommt der Takt. Danach kann langsam die Peripherie hochgefahren werden – Sensoren, Audio, Display und alles andere.

Um es sehr einfach zu umreißen: Würde das Display bzw. dessen Hintergrundbeleuchtung als aller erstes Strom bekommen, würde man als allererstes – weil der ganze Rest noch gar nicht läuft – irgendwelchen Mist auf dem Display sehen. Bei meinem alten China-Scope (Unitrend 2042) war das zum Beispiel der Fall. Wertig wirkt das nicht.

Um das GPS-Modul etwas besser kennenzulernen, sollte man wissen, wann es wo welche Spannung braucht. Mittlerweile habe ich auch den letzten Fädeldraht angelötet. Um keine Kurzschlüsse am Konnektor zu erzeugen, kratzte ich (schweren Mutes) die Flex zum Empfänger auf und verging mich an ihr – mal hoffen, dass der Draht und die Flex hält:

gnss_powerseq_Leitung4

Das GNSS-Modul ist zunächst getrennt – um zu sehen, welche Spannungen die Kamera zur Verfügung stellt. Zu Beginn der Messung ist die Kamera vom Strom getrennt und wird anschließend über das Akkufach versorgt und bleibt für den Benutzer auch aus. Trotzdem tut sich was:

gnss_powerseq_aus

An Pin 1 – im Foto oben (wie in den Posts von gestern) links liegen 3 V an. Pin 2 ist GND und daher in diesem Kontext uninteressant. Pin 3 hat 3,3 V. Pin 4 bis 7 floaten vor sich hin – das dürften alles Datenleitungen sein. An Pin 8 liegen wiederum 2,43 V an.

Im nächsten Screenshot sieht man die Stärke des Pro:

gnss_powerseq_aus_timing

Cursor A1, B1 und C1 liegen so gut wie möglich aufeinander. A2 zeigt die Verzögerung von Pin 3 zu 1 und 8, wobei man darüber streiten kann, ob hier tatsächlich eine Sequenz gefahren wird – schließlich sind es nur knapp 120 µs Unterschied. Was man mit einem normalen Logic Analyzer nicht gesehen hätte – und mangels Kanälen an einem Oszi auch nicht ist das Verhalten beim Hochfahren der Spannungen aller Kanäle. Bei Pin 1 dauert das ca. 6,35 ms, bei 3 und 8 ca 8,8 ms, wobei Pin 8 etwa eine drittel Sekunde früher komplett hochgefahren ist. Ich wollte aber niemanden mit Cursorn erschlagen.

Auch nach einer Viertel Stunde ändert sich nichts. Das Modul wird also dauerhaft mit Strom versorgt. Das ergibt auch Sinn – um einen schnellen GPS-Fix zu erhalten, ist es wichtig, dass die Uhr im Empfänger dauerhaft läuft. Die Auswirkung auf die Betriebsdauer des Akkus spürt man so gut wie gar nicht, weil man den Unterschied nicht kennt 😉

Schaltet man die Kamera ein, zeigt sich folgendes Bild:

gnss_powerseq_an

Es ändert sich lediglich was an Pin 5 – das ist der UART-Tx (zum GNSS-Modul). Im „Stüpfel“ weiter rechts, werden ein paar Byte übertragen:

gnss_powerseq_nebensprechen Leider kann man keine Analyzer auf Analogsignale anwenden – das fehlt dem Logic noch. auf Pin 6-8 sieht man leichtes Nebensprechen – ob es tatsächlich an den Signalen oder meinem bescheidenen Aufbau liegt, kann ich nicht sagen, vermute aber letzteres.

Wenn man in den Kameraoptionen die GPS-Funktion abschaltet, tut sich erst einmal nichts. Im Gegenteil, alle Stromversorgungen bleiben an. Allerdings ist nicht sicher, ob es einen Enable gibt und dieser auf Kameraseite ein Open Drain mit Pull-up im Modul ist.

Interessant ist ebenfalls, dass die Kamera auch nach dem Ausschalten noch eine ganze Weile mit dem Modul zu kommunizieren versucht. Entweder ist es der klägliche Versuch, das Modul in den Tiefschlaf zu schicken oder etwas anderes. Auf jeden Fall bleibt der UART noch relativ genau 30 Sekunden aktiv, bevor er abschaltet. Die Versorgungsspannungen bleiben aber – wie erwartet – danach aktiv.

So, nun einmal mit Modul – wieder zunächst das Anklemmen der Versorgung im Akkufach:gnss_powerseq_mit_modul_aus

Ok, ein leichter Unterschied. Die Versorgungspins bleiben wie erwartet gleich. Pin 4 dümpelt nach wie vor vor sich hin (hätte ich ihn wirklich anlöten müssen?) Pin 5 hat nun auch hier seine 1,8 V. Da muss wohl ein Pull-up im Modul verbaut sein. Pin 6 ist nun auch aktiv. Nach dem kleinen Knick bei ca. 0,75 s steigt die Spannung übrigens von 1,7 auf 1,8 V – vielleicht der Pull-Up des Prozessors der Kamera? An Pin 7 liegen nun dauerhaft 1,8 V an. Entweder der Ausgang eines GNSS-internen Spannungsreglers oder Interrupts oder sonstwas?

Nach nicht ganz einer Sekunde ist der Spuk auf jeden Fall vorbei, die Kamera ist wieder im Tiefschlaf. Was vorhin nicht zu sehen war: Bis auf der Versorgung an Pin 3 werden alle abgeschaltet. Das muss für die Uhr im Empfänger sein.

Um nicht mit ganz so vielen Screenshots zu spammen, hier mal Power-up und Power-down zusammengefasst und dazu die absoluten Zeitstempel. Wer rechnen will, gerne:

  • A1: 0,604856 s (versteckt hinter B1)
  • B1: 0,604999 s
  • A2: 0,611305 s
  • B2: 1,560646 s
  • C1: 1,560977 s

gnss_powerseq_mit_modul_aus_zoom

Kommen wir nun zum Einschalten der Kamera mit Modul:

gnss_powerseq_mit_modul_an

Das meiste ist bereits bekannt, ich hab nach wie vor keine Ahnung, was Pin 4 macht. Vielleicht wird er ja high, wenn es einen GPS-fix gibt? Nächste Frage. Nun gibt es auch auf Pin 6 und 7 ein Signal. Pin 6 ist augenscheinlich der Rx vom Application Processor, also Tx vom GNSS. Der bisschen breitere Block an Pin 5 ist das Hochladen der Almanach-Daten. Die sporadischen Stüpfel an Pin 6 die Bestätigung davon. An Pin 7 liegen konstant 1,86 V an. Sieht entweder nach dem Ausgang eines Spannungsreglers oder doch einem anderen Signal aus. Bis jetzt konnte ich dort nichts beobachten.

Was die Spannung an Pin 8 macht ist mir ehrlich gesagt auch nicht klar. Sie springt auf 1,6 V hoch um kurzzeitig wieder auf die ohne Modul beobachteten 2,41 V zu schalten, wieder runterzugehen und dann doch wieder kurz auf 1,6 V zu springen. Die kurze „high-Phase“ fällt mit den ersten zwei gesendeten Blöcke zusammen. Diese waren das „Hello world“ des Chipsatzes (siehe vorletzter Blogpost). Vielleicht gehört das zur Initialisierung. Wenn man bedenkt, dass hier mutmaßlich der Spannungsregler stärker belastet wird und dadurch einbricht: tolle Initialisierung.

Um vielleicht doch noch herauszufinden, wofür Pin 4 und 7 sind habe ich im Menü Geotagging ein- und ausgeschaltet – ohne Auswirkung auf auf die Signale.

Nachdem die Kamera nun seit 1 Milliarde Samples bei 1 MHz, also etwas mehr als 16 Minuten, keine Regung beim GNSS-Icon zeigte, muss ich leider davon ausgehen, dass entweder der Empfänger oder die Kamera einen Schuss weg hat. Das Mistding versucht anscheinend noch nicht einmal, Satelliten zu suchen.

Aus den Traces habe ich die UART-Daten extrahiert und einem NMEA-Parser zum Fraß vorgeworfen. Mehr als leere RMC- und GGA-Botschaften kam nicht heraus. Hmpf – da ist wohl wirklich nix zu reißen – und nun auch nichts mehr zu verlieren. Mit meiner Lieblingslötspitze (der Hohlkehle) geht es an das Shielding.

Nanu, da ist ein Bauteil nicht ganz so, wie es sein sollte:

gnss_powerseq_noshieldEtwas mit der Pinzette gezupft und das andere Pad vom Kondensator war abgehoben. Bzw. blieb eher auf der Leiterkarte hängen. Ich bin mir sehr sicher, dass das nicht ich war. Beweisen kann ich es aber nicht. Wieder notdürftig angelötet tut sich… …nichts.

Das Oszi spricht: beide Quarze schwingen. der oben im Bild mit 32 kHz, der unten mit ca. 16,4 MHz. Klingt plausibel.

Jetzt ist auch sicher, welcher Chip verbaut ist – ein MTK3339AV. Google spuckt zwar kein Datenblatt aus, aber das Teil wird mit ähnlicher Antenne flächendeckend verkauft. Adafruit hat ein Datenblatt zu einem Modul mit diesem Chipsatz.

Der Versuch, das Teil zum Laufen zu bekommen wäre damit (vorerst) beendet, leider.

Drei verschwendete Abende? Nein. es war auf jeden Fall interessant, das Modul zu erforschen, auch wenn es sich schlussendlich als Kaputtnik herausgestellt hat.

The strangest deal

Gestern war es mal wieder so weit. Friedrichshafen ruft!

Dieses Jahr war die HAM Radio gefühlt wieder besser besucht, obwohl das Wetter nicht ganz so stabil war wie die Jahre zuvor.

An ein paar Ständen gab es wie auch die Jahre zuvor kaputte Digiknipsen. Darunter auch „meine“ Canon SX280. 15 Euro für eine kaputte Kamera? Ein Argument zum Handeln gab es: der Blitz fehlte. Also den Händler anquatschen und 10 Euro geboten. „Aber da fehlt der Blitz!“ – „ok, dann 8 Euro“. Gut, wenn er meint, dann bekommt er halt nochmal 2 Euro weniger als ich ihm eigentlich geben wollte.

Warum ich sie wollte? Zum einen bietet Canon keine Almanachdaten mehr an, zumindest keine aktuellen mehr. Wenn ich weiß, welcher Chipsatz verbaut ist, lässt sich vielleicht eher etwas finden. Zudem hat das Objektiv zwar eine Delle, scheint ansonsten aber noch intakt zu sein. Immerhin hat es Kleinbild-Äquivalent verrückte 28-500 mm Brennweite. Die Blende ist dann zwar ziemlich zu und die Abbildung nicht mehr ganz so perfekt, aber für den angepeilten Verwendungszweck an der Raspberry Pi-Cam, who cares? Ich hatte schon ein Canon EF-Objektiv am Pi. aus 200 mm Brennweite werden knapp 3000 mm KB-Äquivalent. Den Mond muss man damit ziemlich feinfühlig ansteuern und trotzdem haut er recht schnell ab. Leider ist das Objektiv bei offener Blende nicht ganz so knackig, zum Schließen selbiger braucht’s allerdings zusätzliche Hard- und Software…

Aber ich schweife ab. Don’t turn it on, take it apart? Naja, vorher möchte ich zumindest sehen, was die Kamera noch macht, schließlich habe ich alle Betriebsmittel daheim. Resultat: Der Bildschirm bleibt dunkel, das Objektiv fährt nur kurz aus, dann ist wieder Stille. Aber immerhin tut sich etwas.

Also, auf den Apparat! Alle Schrauben gelöst, braucht man nur noch sanfte Gewalt um die Gehäusehälften voneinander zu trennen. Die Innereien sind erstaunlich aufgeräumt – GPS und WLAN sind erwartungsgemäß Module, wodurch der kleine Schwester SX270 einfach die beiden Platinchen mit Funk fehlen.

SX280_module

Funkmodule der Canon SX280, links: WLAN, rechts: GPS

Auf dem WLAN-Modul ist WYSBCVCXA eingraviert. Eine kurze Suche ergibt: Es ist ein Modul von Taiyo Yuden – nicht die ganze Leiterkarte sondern nur das kleine Teil mit Blechdeckel. Alles außenrum stammt augenscheinlich von Canon, zumindest deutet der Aufkleber auf der Rückseite darauf hin. Im inneren werkelt ein Marvell 88W8787, der mit dem Prozessor über SDIO kommuniziert. Bluetooth und 2,4G-WLAN kann grundsätzlich über die die gleiche Antenne arbeiten, auch scheint das Modul die entsprechenden Bauteile für den Betrieb zu besitzen. Müsste ich nur noch die Anschlussbelegung herausfinden, dann wäre das tatsächlich etwas für den Raspberry Pi. Noch ein kurzer Ausflug: Warum macht man ein Modul auf ein Modul und nicht zumindest den Funkchip direkt auf das eigene Modul? Ganz einfach, und manche kennen es vielleicht schon von den ESP8266-Modulen: Zertifizierung. So muss nur das eigentliche Funkmodul durch die vollständige Zerti. Die Antenne und das andere Außenrum muss man zwar trotzdem noch checken, aber das geht bedeutend schneller und günstiger.

SX280_gnss

Beim GPS-Modul (oder korrekter: GNSS) sieht es leider nicht ganz so gut aus. Auf dem Shielding steht zwar, dass es ein GYCFDMAXX von Canon sei aber bis auf Typenzulassungen findet man nichts im Netz, die Daten auf der Oberseite kommen rein aus der Produktion und das Shielding herunternehmen gefährdet die Elektronik darunter. Nebenbei: wen die Kerben an der Patchantenne irritieren – das war nicht ich mit dem abgerutschten Schraubendreher – das muss so! So werden die Antennchen bei der Produktion getrimmt.

Also keinerlei Infos. Ublox, Broadcomm, Sirf, SkyTraq, Qualcomm, Mediatek oder noch was exotischeres? Keine Ahnung. Da ist mehr Detektivarbeit vonnöten. Im Foto oben sieht man noch leicht die Flex vom Modul – die zwei linken Leiterbahnen sind etwas dicker – das MUSS die Stromversorgung sein. Ich definiere links einfach mal zu Pin 1. Nachdem Pin 2 auf die große Fläche geht, müsste das die Masse sein. Pin 1 ist also die Versorgung. Beim Rest bleibt die Ahnungslosigkeit. Klassischerweise sprechen GNSS-Chips UART oder I²C. Manche auch USB, was aber eher für PC-Empfänger und R&D-Zwecke verwendet wird. Jedes Interface benötigt aber lediglich zwei Leitungen, das Modul ist allerdings mit 8 angebunden. Bei UART kann noch RTS und CTS dazukommen. Was ich mir noch vorstellen könnte wären ein Enable, Interrupt, 32 kHz-Takt oder ein 1-Pulse-per-Second-Signal.

Es hilft nix, da muss ein Messgerät ran – Ich hab da mal was vorbereitet:

SX280_engine

Hab ich erwähnt, wie aufgeräumt das Design in der Kamera ist? Zu meinem weiteren Erstaunen ist die kleinste Bauteilgröße 0402. Ich hätte erwartet, dass Canon im Jahr 2013 schon alles mit 0201 zupflastert. Schön für Bastler, da ist das Umbauen deutlich angenehmer.

Folgende Bauteile sitzen auf der Leiterkarte:

  • Elpida B2064B3PB-8D-F – RAM
  • Macronix MX29GL256FHX01 – Flashspeicher (kein eMMC)
  • Analog Devices ADV7528 – HDMI-Transmitter
  • Renesas (?) R2A30447 – Motortreiber (?)
  • 4957 323A – ???

Vom eigentlichen Prozessor sieht man nichts. Er ist unter dem RAM versteckt – Stichwort Package-on-Package. Zum R2A30447 konnte ich nichts eindeutiges finden, aber Bauteile mit ähnlichen Bezeichnungen sind alles Motortreiber. Zudem deuten die dickeren Widerstände, größere Kupferflächen (um die Wärme wegzubekommen) und die Nähe zum Objektivkonnektor sehr explizit darauf hin. Neben dem Motor für das Objektiv und den Blitz könnte der Chip auch die Aktuatoren für Blende und Voicecoils für den Autofokus und Bildstabilisator ansteuern. Was der Chip mit der Gravur 4957 323A macht, konnte ich nicht herausfinden. Ich vermute, dass es ein IMU, also Accelerometer und Gyroskop ist. Accelerometer, um die Orientierung der Kamera (zum automatischen Drehen der Bilder, was Canon noch immer nicht „richtig“ in den Exif-Daten ablegt) und als Komponente für den Bildstabilisator verwendet. Was noch auffällt: Links unten im Bild befindet sich ein Footprint für einen unbestückten Konnektor. Hmmmm, könnte das vielleicht der Debug sein? 🙂

Zurück zum GNSS – Solderporn gefällig?

SX280_gnss_conn

Eigentlich gar nicht so spekakulär – wie gesagt: die Widerstände sind im 0402-Package. Pin 1, die mutmaßliche Versorgung ist hier rechts. Im letzten Bild sieht man: an ihm hängt auch das Oszi. Pin 4 konnte ich nicht richtig anlöten, weil es anscheinend auf keinen Widerstand unten führt. Vielleicht der in der zweiten Reihe? keine Ahnung. auf jeden Fall kommt jeder Pin an den Logicanalyzer.

Sobald die Kamera Strom bekommt regt sich auch etwas:

SX280_gnss_LA1

Kanal 4 und 5 sieht sehr interessant aus und der Screenshot oben ist schon verräterischer als ich beabsichtigte:

SX280_gnss_LA2

We got signal! UART 115200 Baud, 8N1. Die Signale auf Kanal 5 sind offensichtlich Glitches durch Nebensprechen.

Der GNSS-Receiver meldet:

$PMTK011 MTKGPS*08\r\n$PMTK010 001*2E\r\n

$PMTK010 002*2D\r\n

Wir haben es mit sehr großer Wahrscheinlichkeit mit MediaTek zu tun, der NMEA 0183 spricht. So weit, so gut.

Auf der Suche nach Mediatek und Almanac bin ich auf eine Seite von Gizmochina gestoßen. Darauf ein Link auf http://ftp.epo.mediatek.com. Allerdings ist der Server offline. Aber zumindest gibt es eine Fährte. Auf der Suche nach Mediatek und epo fand ich die Sourcen eines Updaters für Android. Man muss etwas wühlen, aber schlussendlich läuft es auf folgende Ressource hinaus: http://epodownload.mediatek.com/EPO.DAT. Datei heruntergeladen, und neben die aktuelle CAGM01.EED der Kamera gelegt (Die Datei befindet sich auf der Speicherkarte im Ordner \DCIM\CANONMSC\GPS\)  – zumindest die Dateigröße ist gleich. BeyondCompare sagt: Inhalt ebenfalls identisch. Ich habe ein Bingo!

Ok, im Nachhinein hätte ich das auch einfacher haben können. Denn, meine Fritzbox kann Netzwerkverkehr mitschneiden. Der Vollständigkeit halber habe ich das nun auch nachgeholt.

Kurz und knapp baut die Kamera auch eine Verbindung und sendet folgenden Header:

GET /rmds/ic/agps/cagm01.eed HTTP/1.1

HOST: gdlp01.c-wss.com:80

CONNECTION: close

Funktioniert auch im Browser. Als Antwort kommt, wie erwartet, die Datei von oben. Nur zeigt die Kamera noch immer „Gültigk.zeitr. d. A-GPS-Dat.: –.–‚– – –.–.‘–“ an. (warum eigentlich so stark abgekürzt, da wäre noch elendig viel Platz auf dem Bildschirm…)

Vielleicht funktioniert auch nur die Anzeige des Gültigkeitszeitraum nicht?! Naja, zumindest der TTFF liegt irgendwo bei 2 Minuten – ich bin mir also nicht sicher.

In den Untiefen meiner Festplatte konnte ich ältere Versionen der Datei finden. Mit richtiger Dateizeit. Hmmm – was macht wohl die Kamera damit? Also eine von 2014 kopiert, die Karte in die Kamera gelegt und siehe da: ich habe für den damaligen Zeitraum A-GPS-Support. Was passiert nun, wenn ich aktualisiere? Die Kamera behauptet was zu laden, nach dem Update steht aber der alte Zeitraum auf dem Display. Zurück am PC: Ja, die Datei wurde nicht überschrieben.

Bleibt eine Frage: Warum? Drei Ideen hätte ich:

  • Canon hat nur eine zeitlich begrenzte Lizenz von Mediatek oder deren Zulieferern für die Daten (Die Datei wird für andere Produkte auf dem Server aktualisiert oder wurde schlichtweg vergessen)
  • Jemand in der Software-Entwicklung hat es verkackt
  • Canon will, dass eine neue Kamera mit integriertem GPS-Empfänger (die es nicht gibt) gekauft wird

Für den zweiten Fall könnte man sich vertrauensvoll an den Support wenden. So motiviert wie ich sämtliche Consumer-Produkte-Hersteller mittlerweile kennengelernt habe, wird ein Standardschreiben zurückkommen: „Wir haben das Problem weitergeleitet. Ob und wann eine Fehlerkorrektur zur Verfügung steht, können wir zum aktuellen Zeitpunkt allerdings nicht sagen“. Wenn die Person, die diesen Textbaustein geschrieben hat, je Verwendung einen Cent bekommen hätte – sie oder er wären reich. Sehr sogar. 🙁

Und nun: sorry für die Länglichkeit. Wer hat es bis hier geschafft? Schreibt einfach einen kurzen Kommentar!