Hallo, mein Name ist J. Geis, ich bin 18 Jahre alt und beginne in wenigen Monaten Physik zu studieren. Vorab: Ein Grundverständnis zu Mikrocontrollern (insbesondere die Arduino-Umgebung) habe ich, sehr viel mehr leider noch nicht. Mein Anliegen: Ich möchte einen GPS-Logger bauen und die empfangenen GPS-Daten auf einer Micro-SD-Karte speichern. Herz des Loggers wird ein AVR sein, vermutlich der Atmega1284p. Die Daten werden in eine .txt-Datei geschrieben. Nun möchte ich die SD-Karte nicht nach jedem Laufen aus dem kleinen Gehäuse friemeln, sondern eine Micro-USB-Buchse in meinen Schaltkreis integrieren, über den die .txt-Datei auf den Computer geladen werden kann. Doch ich weiß nicht so ganz wie ich das sowohl hardware- als auch softwaretechnisch umsetzen kann. Ich habe mich bereits zu UART und USB-UART Wandlern informiert (zB.: Beitrag "USB<->UART Wandler?" ), weiß aber nicht, ob ich auf dem richtigen Weg bin. Ich möchte euch die Zeit und Mühe ersparen, ellenlange Erklärungen zu verfassen. Schickt mir lieber passende Links, über die ich mir das Know-How selber aneignen kann. Vielen Dank und Viele Grüße, J.geis
:
Bearbeitet durch User
Jonathan G. schrieb: > Ich möchte einen GPS-Logger bauen und die empfangenen GPS-Daten auf > einer Micro-SD-Karte speichern. Herz des Loggers wird ein AVR sein, > vermutlich der Atmega1284p. Völlig überdimensioniert, der Speicher ist ja die SD-Karte. Für den Rest genügt ein viel kleinerer µC auch völlig. > Die Daten werden in eine .txt-Datei > geschrieben. > Nun möchte ich die SD-Karte nicht nach jedem Laufen aus dem kleinen > Gehäuse friemeln, sondern eine Micro-USB-Buchse in meinen Schaltkreis > integrieren, über den die .txt-Datei auf den Computer geladen werden > kann. Doch ich weiß nicht so ganz wie ich das sowohl hardware- als auch > softwaretechnisch umsetzen kann. Sinnvoll wäre dann USB-Storage. Kann man z.B. mit einem ATMega32U2 umsetzen. Der genügt dann auch, um den restlichen (vergleichsweise ziemlich trivialen) Kram zu implementieren, also die Ansteuerung der SD-Karte und des GPS-Sensors. > Schickt mir lieber passende Links, über die ich mir das > Know-How selber aneignen kann. https://www.usb.org/documents
c-hater schrieb: > Völlig überdimensioniert, der Speicher ist ja die SD-Karte. Für den Rest > genügt ein viel kleinerer µC auch völlig. Ist doch egal, ob das ding 3 € oder 5 € kostet. Alles jenseits eines Trabbi ist auch überdimensioniert um von A nach B zu kommen. Trotzdem sind SUV äußerst beliebt.
Karl schrieb: > c-hater schrieb: >> Völlig überdimensioniert, der Speicher ist ja die SD-Karte. Für den Rest >> genügt ein viel kleinerer µC auch völlig. > > Ist doch egal, ob das ding 3 € oder 5 € kostet. Ja, aber es ist halt nicht unwichtig, ob er ein USB-Interface hat, mit dem man das hier offensichtlich angestrebte USB-Storage-Device umsetzen kann. Und das hat der M1284P halt nicht. Ist Scheisse, aber ist eben so. Capisce?
c-hater schrieb: > Ja, aber es ist halt nicht unwichtig, ob er ein USB-Interface hat So isses. Alternativ könnte man noch über sowas wie VUSB nachdenken, aber ich würde in jedem Falle einen AVR mit existierender USB-Hardware den Vorzug geben.
c-hater schrieb: > Ja, aber es ist halt nicht unwichtig, ob er ein USB-Interface hat, mit > dem man das hier offensichtlich angestrebte USB-Storage-Device umsetzen > kann. Und das hat der M1284P halt nicht. Ist Scheisse, aber ist eben so. Hat aber nichts mit "überdimensioniert" zu tun. Ggf. könnte man auch der Meinung sein, dass ein USB 2.0 Anschluss "völlig überdimensioniert" ist. Wenn du meinst, dass ein µC mit USB besser ist, dann schreib das doch und nicht, dass der andere "überdimensioniert" ist. Vielleicht möchte der TO auch nicht gleich zu Beginn SMD löten.
Karl schrieb: > Vielleicht möchte der TO auch nicht gleich zu Beginn SMD löten. Dann soll er sich eins der existierenden Breakout-Boards beschaffen. Aber "nicht SMD löten wollen" ist eher ein Problem der Generation Ü50, nicht der Jungen. Nur erstere sind stolz darauf, auch heutzutage irgendein Projekt noch ausschließlich mit THT-Bauteilen gemanaget bekommen zu haben.
Nimmst einfach ein STM32F1 mit USB. Da gibts genug Mass storage Device Beispiele bei Github und ST
Beitrag #6198589 wurde von einem Moderator gelöscht.
Timmo H. schrieb: > Da gibts genug Mass storage Device Gibt's aber auch für den genannten USB-AVR, das ist nun wirklich nicht das Problem.
c-hater schrieb: > Völlig überdimensioniert, der Speicher ist ja die SD-Karte. Für den Rest > genügt ein viel kleinerer µC auch völlig. Du vergisst, dass der µC nicht nur dazu dient, die Daten von der SD-Karte zum PC übertragen soll, sondern sicher auch die Daten vom GPS in Richtung SD-Karte transportieren soll. Da muss man schon überlegen, ob die Sache klar geht, wenn die SD-Karte wegen "Aufräumarbeiten" zwischenzeitlich keine neuen Daten aufnimmt. Dann müssen die Daten vom µC voll gepuffert werden. Wenn der Logger blind zum Mitschreiben funktionieren soll, ohne das GPS umzukonfigurieren, kommt es dann schon auf den Umfang der zu loggenden Daten und die Wiederholrate beim GPS an. Und dann ist es sicher nicht verkehrt, so einen Logger gleich so auszulegen, dass er einen kompletten NMEA0183-Bus mitschneiden kann. Mit AIS kommt da bei voller Slot-Belegung noch ein bisschen mehr zusammen.
Hallo, c-hater schrieb: > mit dem man das hier offensichtlich angestrebte USB-Storage-Device > umsetzen kann. Wo steht das? Ich entnehme seinem Eröffnungsbeitrag, das er die Positionsdaten eines GPS-Empfängers auf eine Micro-SD-Karte speichern und anschließend mittels einer Schnittstelle, die über eine Micro-USB-Buchse verfügt, auf einen Auswerterechner übertragen will. Es liegt nahe das es sich bei der Schnittstelle um eine USB-Schnittstelle handelt. Es ist aber nirgendwo die Rede davon der Logger die Funktionalität eines USB-Storage-Device aufweisen soll. Im einfachsten Fall kann man Jonathans Anforderungen auch mit der seriellen Schnittstelle des AVRs und eines seriell<->USB-Konverters erfüllen. rhf
Jörg W. schrieb: > Timmo H. schrieb: >> Da gibts genug Mass storage Device > > Gibt's aber auch für den genannten USB-AVR, das ist nun wirklich nicht > das Problem. Stichwort: LUFA (https://www.google.com/search?q=LUFA+usb)
Roland F. schrieb: > Im einfachsten Fall kann man Jonathans Anforderungen auch mit der > seriellen Schnittstelle des AVRs und eines seriell<->USB-Konverters > erfüllen. Kann man, aber dann bastelt man massiv noch auf der PC-Seite herum. Oder man implementiert irgendwas wie Kermit auf dem Controller. Das Mass Storage Device wäre da sicher die einfachere Lösung.
Roland F. schrieb: > c-hater schrieb: >> mit dem man das hier offensichtlich angestrebte USB-Storage-Device >> umsetzen kann. > > Wo steht das? Das steht nirgends. Wie auch? Der TE hat ja ein Problem vorgestellt und nicht auch (s)einen angestrebten Lösungsweg. So wie das sein soll. > Ich entnehme seinem Eröffnungsbeitrag, das er die Positionsdaten eines > GPS-Empfängers auf eine Micro-SD-Karte speichern und anschließend > mittels einer Schnittstelle, die über eine Micro-USB-Buchse verfügt, auf > einen Auswerterechner übertragen will. Es liegt nahe das es sich bei der > Schnittstelle um eine USB-Schnittstelle handelt. Es ist aber nirgendwo > die Rede davon der Logger die Funktionalität eines USB-Storage-Device > aufweisen soll. Wenn die Funktion eines USB MSD gebraucht wird, dann liegt es nahe, das auch so zu implementieren. Natürlich könnte man die Daten auch proprietär (sprich: ohne Filesystem) auf der Karte ablegen. Und für den Download zum PC könnte man ein CDC Device in Verbindung mit sagen wir mal dem Z-Modem Protokoll verwenden. Ich würde das aber als Frickelei bezeichnen. Proprietär. Nicht sinnvoll erweiterbar. Und nachdem es ja offensichtlich nicht [1] um ein praktisch nutzbares Gerät geht, sondern um den Spaß am Lernen und Bauen, ist es auf jeden Fall sinnvoll, gleich noch etwas über USB Geräteklassen und Dateisysteme zu lernen. [1] GPS-Tracker kann man für kleines Geld kaufen. Man kann sie selber weder billiger noch besser bauen. Ganz im Gegenteil. Ein GPS-Tracker zum Joggen sollte klein sein und wasserdicht. Der Akku sollte lange halten. Zusätzliche Sensoren, etwa für Herzfrequenz und Schrittzähler will man früher oder später auch haben. Das kriegt man heute in der Größe einer Armbanduhr. Es muß ja auch keine Garmin Forerunner sein. Ein Xiaomi Mi-Band tuts auch. Oder nur das Smartphone.
Zuerst einmal vielen Dank für die vielen Antworten, top Engagement! Die Umsetzung mittels eines Atmega32U2 erscheint mir plausibel und ich habe mich dazu entschieden eine Art USB-Storage-Device bauen. Ich werde mich jetzt mal ausführlich mit UART, USB und SD-Karten sowie AVRs (besonders die mit USB-Hardware) beschäftigen. Bei Bedarf möchte ich den Mikrocontroller, der (nebenbei in SMD) auf der Platine angelötet ist, programmieren können. Das könnte ich mit einem Arduino-UNO als ISP umsetzen. Doch wieso nicht gleich über die Micro-USB-Schnittstelle? Außerdem wäre es natürlich genial wenn ich den Akku (derzeit 3,7V 380mAh LIPO) auch über die USB-Schnittstelle laden könnte. Allerdings müsste dann ich dann in meinen Schaltkreis extra ein System zur Ladung des recht sensiblen Akkus integrieren, die Dinger können ja sogar explodieren.. Ist die Umsetzung meiner ganzen Ideen (für mich) möglich? Ich muss das ganze in SMD löten, da es sonst nicht meinen Platzanforderungen gerecht werden kann. Den Mikrocontroller möchte ich über die Arduino-IDE programmieren, da ich damit sehr gut vertraut bin. Als GPS-Receiver stelle ich mir soetwas wie den NEO-M8N der Firma UBLOX vor. Ich möchte nicht das Modul, sondern den hier als SMD anlöten: https://www.u-blox.com/en/product/neo-m8-series Mich interessiert lediglich die RMC- und die GGA-Zeile des NMEA-Protokolls. Es sollen momentane Geschwindigkeit, Durchschnittsgeschwindigkeit, momentane Beschleunigung, gelaufene Distanz und Anzahl an Sprints, Standzeit berechnet werden und danach grafisch veranschaulicht werden. Die Umsetzung davon bekomme ich mit C++ prima hin. Klar, es gibt bereits fertige und sehr gut entwickelte Systeme zu einem geringen Geld, doch es geht mir hauptsächlich um das Lernen und Verstehen der Materie. Viele Grüße, Jonathan
:
Bearbeitet durch User
Jonathan G. schrieb: > Doch wieso nicht gleich über die Micro-USB-Schnittstelle? Die neueren USB-AVRs haben meines Wissens leider keinen Bootloader mehr vorinstalliert. Man bekommt ihn aber noch, und ab da, wenn er drauf ist, kann man die Firmware auch über USB aktualisieren. Die älteren AT90USB162 oder AT90USB1287 (wenn es größer sein soll) haben einen USB-fähigen Bootloader sogar ab Werk drin (DFU / FLIP).
Jonathan G. schrieb: > Mich interessiert lediglich die RMC- und die GGA-Zeile des > NMEA-Protokolls. <Offtopic> Sicher, dass Du nicht direkt mit dem perfekt dokumentierten uBlox subSystem reden willst, indem Du das UBX-Protokoll nutzt, anstatt den NMEA overhead zig mal/sekunde zu dekodieren? (Wir nutzen selbst den NEO7-P für eines unserer älteren Tracking Devices, UBX Protokoll via SPI, 10Hz Aquisition-Rate) </> Ansonsten nutzt das o.g. Device die oben als ‚Gefrickel‘ bezeichnete USB Kommunikation: CDC gegen WinPC mit dortiger proprietärer SW. Kommt halt immer auf den Use-Käs und die Spec an;) VG Stephan
Jonathan G. schrieb: > Die Umsetzung mittels eines Atmega32U2 erscheint mir plausibel und ich > habe mich dazu entschieden eine Art USB-Storage-Device bauen. Ich werde > mich jetzt mal ausführlich mit UART, USB und SD-Karten sowie AVRs > (besonders die mit USB-Hardware) beschäftigen. Schau Dir das hier an: https://www.pjrc.com/store/teensy36.html Da hast Du ca 80% Deines Problems bereits gelöst: Prozessor, uSD-Slot direkt mit drauf, natives USB vorhanden. Was noch offen ist, ist der Anschluss Deines GPS-Moduls an passende Pins sowie die Stromversorgung über Akkus und fertige Ladeschaltungen, die Du zuhauf von irgendwelchen Chinesen bekommst. Beides sollte auch für Dich machbar sein. fchk
Weitere Gedanken: 1. Warum SD-Karten? Brauchst Du die Kapazität? Wie viele GBytes willst Du denn bei Deinen Ausflügen erzeugen, jetzt mal so realistisch gesehen? Ich lege Dir jetzt mal etwas ganz anderes nahe: https://www.microchip.com/wwwproducts/en/23LCV1024 Das ist ein 128k-SRAM. Viel einfacher anzusteuern als eine SD-Karte, viel schneller (d.h. Dein Prozessor kann viel schneller wieder in den Ruhezustand gehen), und viel weniger Stromverbrauch als eine SD-Karte. Und 128k sollten eigentlich reichen, oder? Klar, das ist ein RAM, und wenn Strom weg ist, sind die Daten auch weg, aber (a) hast Du ja eh einen Akku und (b) hat der Chip einen VBat-Pin, wo Du eine Knopfzelle oder so anschließen kannst. Solange da die Spannung nicht unter 1.8V fällt, sind die Daten sicher. 2. Wenn Du selber löten und Dir nicht die Finger brechen willst: https://www.microchip.com/wwwproducts/en/PIC24FJ64GB002 Ist jetzt kein AVR. Kennst Du nicht. Ist aber auch nicht weiter schlimm, Du willst und sollst ja was lernen, auch dass es noch eine Welt abseits von Arduino gibt. Dieser Prozessor ist einigermaßen stromsparend (reine 3.3V Technik, läuft intern mit 2V), hat USB eingebaut, hat auch sonst alles, was Du so brauchst, hat in etwa die dreifache Rechenleistung eines AVR, und es gibt ihn auch in DIL. Das SRAM von eben übrigens auch. Wenn Du nicht unbedingt TQFPs im 0.5mm Raster löten willst, hast du also auch Alternativen. Microchip ist eine der wenigen Hersteller, die noch relativ viel im DIL-Gehäuse im Angebot haben, und nicht nur alte Sachen, sondern auch sowas wie PIC32MX. Fertige Bibliotheken für UART, SPI, USB etc hast Du dort auch, und die Debugging-Möglichkeiten sind viel besser als bei AVR. Denke einfach mal drüber nach. fchk
Jonathan G. schrieb: > Nun möchte ich die SD-Karte nicht nach jedem Laufen aus dem kleinen > Gehäuse friemeln > Mich interessiert lediglich die RMC- und die GGA-Zeile des > NMEA-Protokolls. > Es sollen momentane Geschwindigkeit, Durchschnittsgeschwindigkeit, > momentane Beschleunigung, gelaufene Distanz und Anzahl an Sprints, > Standzeit berechnet werden Das heißt, die Datenrate und die Aufzeichnungszeit "am Stück" sind nicht soo hoch. Unter den Umständen würde ich statt der SD-Karte ein NOR-Flash-IC verwenden, z.B. IS25LP128/256/512. Die sind wesentlich robuster, innen wie außen (kein Sockel), brauchen weniger Strom (max. 35 mA) und brauchen maximal 1ms um einen Block (256 Byte) zu schreiben -- auch noch nach 100000 Schreibzyklen. Im SO-8 gibt es 16 MByte, im SO-16 auch 32 und 64 MByte; oder in 8x6 mm ohne Pins, aber noch lötbar. > Ich möchte nicht das Modul, sondern den hier als SMD anlöten: > https://www.u-blox.com/en/product/neo-m8-series Ein Modul hätte aber schon eine korrekt angepasste Antenne... Das ublox PAM-7 Modul ist kaum größer als die Antenne und brauch weniger Strom als die ublox8. > Außerdem wäre es natürlich genial wenn ich den Akku (derzeit 3,7V > 380mAh LIPO) auch über die USB-Schnittstelle laden könnte. > Allerdings müsste dann ich dann in meinen Schaltkreis extra ein > System zur Ladung des recht sensiblen Akkus integrieren, > die Dinger können ja sogar explodieren.. LiFePO4 explodiert nicht ganz so oft und läßt sich einfacher laden.
@Stephan ("Sicher, dass Du nicht direkt mit dem perfekt dokumentierten
uBlox subSystem reden willst, indem Du das UBX-Protokoll nutzt, anstatt
den
NMEA overhead zig mal/sekunde zu dekodieren?
(Wir nutzen selbst den NEO7-P für eines unserer älteren Tracking
Devices, UBX Protokoll via SPI, 10Hz Aquisition-Rate"):
Gute Idee, das erspart mir Programmierarbeit und dem Mikrocontroller
viel Arbeit!
@Frank K.("Schau Dir das hier an:
https://www.pjrc.com/store/teensy36.html
Da hast Du ca 80% Deines Problems bereits gelöst: Prozessor, uSD-Slot
direkt mit drauf, natives USB vorhanden. Was noch offen ist, ist der
Anschluss Deines GPS-Moduls an passende Pins sowie die Stromversorgung
über Akkus und fertige Ladeschaltungen, die Du zuhauf von irgendwelchen
Chinesen bekommst. Beides sollte auch für Dich machbar sein."):
An sich ein guter Vorschlag, nur leider möchte ich den gesamten
Schaltkreis von Hand aufbauen, um so noch mehr zu lernen und alles zu
verstehen. Der Weg ist mein Ziel, trotzdem danke.
@Jörg W.("Die neueren USB-AVRs haben meines Wissens leider keinen
Bootloader mehr vorinstalliert. Man bekommt ihn aber noch, und ab da,
wenn er drauf ist, kann man die Firmware auch über USB aktualisieren."):
Ich habe mich dazu gerade informiert und eine nette Seite entdeckt. Dort
wird erklärt, wie man mit den USB-fähigen AVRs umgeht (in Form eines
Berichtes). Er hatte die Erfahrung gemacht, dass nicht auf allen AVRs
der Bootloader bereits drauf war. Nur behauptet der Autor, dass der
Bootloader über eine ISP-Schnittstelle auf den AVR gebrannt werden muss,
und nicht über die vorhandene USB-Schnittstelle. Laut ihm ist diese
dafür da, um den eigentlichen Code auf den Flash zu spielen. Der
Schaltkreis weiter unten zeigt dies. Wenn ich eine ISP-Schnittstelle in
meinen Schaltkreis integriere, kann ich aber direkt über den Arduino den
AVR programmieren und benötige garkeinen Bootloader. Dann bringt mir die
USB-Schnittstelle nur zum Übertragen der Daten in der .txt-Datei etwas
und evtl. zum Laden des Akkus. Wäre schade, trotzdem vermute ich, dass
der oben beschriebene Weg nicht der einzige Weg ist. Was meint ihr?
https://helentronica.com/2015/07/23/getting-started-with-atmega8u2-and-other-avr-usb-microcontrollers/
Viele Grüße,
Jonathan
Jonathan G. schrieb: > Nur behauptet der Autor, dass der Bootloader über eine ISP-Schnittstelle > auf den AVR gebrannt werden muss, und nicht über die vorhandene > USB-Schnittstelle. Wie geschrieben: die älteren USB-AVRs haben bereits einen mit drauf. > Wenn > ich eine ISP-Schnittstelle in meinen Schaltkreis integriere, kann ich > aber direkt über den Arduino den AVR programmieren und benötige > garkeinen Bootloader. Ist halt u.U. bequemer, das gleich über das USB-Kabel machen zu können, statt jedesmal erst den ISP-Programmer anstecken zu müssen.
@Bauform B.: Ich möchte die Daten in einer minimalen Frequenz von 2 Hz speichern. Das wären bei einem 2-stündigem Training (etwas übertrieben) 14400 Eintragungen auf dem NOR-Flash-IC oder der SD-Karte. Zwar ist es schön wenn der Baustein etwas weniger Strom verbaucht, aber ich kann nicht einschätzen ob das reicht.. Ist die Genauigkeit der Positionsdaten usw. ähnlich, wie die des Neo-m8n? Den Angaben des Herstellers kann man leider nicht immer vertrauen. Was mir am 8er gefällt ist die Tatsache, dass zu mehreren Satelliten-Systemen eine Verbindung aufgebaut werden kann und so die Genauigkeit und Zuverlässigkeit steigen sollte. Was hast du so für Erfahrungen mit dem Modul gemacht? Viele Grüße
:
Bearbeitet durch User
Jonathan G. schrieb: > Ist die Genauigkeit der Positionsdaten usw. ähnlich, wie die des > Neo-m8n? Den Angaben des Herstellers kann man leider nicht immer > vertrauen. Was mir am 8er gefällt ist die Tatsache, dass zu mehreren > Satelliten-Systemen eine Verbindung aufgebaut Hallo Jonathan, meiner unmaßgeblichen Erfahrung nach, kann man den Datenblättern und appNotes von uBlox sehr wohl vertrauen. Man muss natürlich wissen wann man wo und wie abweichen kann.... Auch bei MultiConstellation GNSS ist die Antennenauswahl, Matching und Montierung der Schlüssel zum Erfolg. Das ganze natürlich Modulo Deiner Anforderungen zur bspw Gerätegrösse. Wenn also eine schicke Trimble Choke Ring Antenne nicht möglich sein sollte (was ich mal vermute) sinkt die eff. erzielbare Genauigkeit, DOP, aber auch TTFF mit der Verkleinerung und Anpassung der Antenne. Wenn das alles erstmal nicht im Fokus steht, würde ich Dir auch erstmal zu einem fertig abgestimmten Modul raten, bei den GPS/GNSS Modul, Antenne, SAW, LNA schon herstellerseitig vorhanden/abgestimmt sind. Alternativ versuche den GPS/GNSS Teil zunächst so einfach wie möglich zu gestalten, um dann eine (viele Versuchsantennen ;)) Antenne per SMA oder U.Fl Verbindung anzukoppeln. Später kannst Du dann über eine PCB-Montage der Antenne nachdenken. Wenn das Gerät nicht nur ein einmaliges Corona Hobby Projekt sein soll, beziehe die Antenne möglichst früh in alle Deine Betrachtungen ein. Hersteller Empfehlung: ANTENOVA. Interner Speicher: ich würde auch wie oben bereits vorgeschlagen, keine SD Karte samt Halter nehmen, sondern einen NOR Flash und die Daten hier selbst zu organisieren. Du willst die SD Karte ja nicht herausnehmen, um sie mit einem Kartenleser am PC zu lesen... So ein GNSS-Tracker kann eine eine komplexe Sache werden ... Vg Stephan
Jonathan G. schrieb: > @Bauform B.: > > Ich möchte die Daten in einer minimalen Frequenz von 2 Hz speichern. Das > wären bei einem 2-stündigem Training (etwas übertrieben) 14400 > Eintragungen auf dem NOR-Flash-IC oder der SD-Karte. Zwar ist es schön > wenn der Baustein etwas weniger Strom verbaucht, aber ich kann nicht > einschätzen ob das reicht.. RMC und GGA sind zusammen ca. 150 Byte, also 1 MByte pro Stunde, der kleinste Chip reicht also locker. Der braucht zweimal pro Sekunde für 1 ms 35 mA, die restliche Zeit unter 50 uA. Ich glaube, man müsste die SD-Karte komplett abschalten, um auch nur in die Nähe zu kommen. RMC und GGA enthalten beide die Position und die Zeit. Man könnte die Sätze zusammenfassen und nur die wirklich interessanten Daten speichern. Gerade Datum und Zeit braucht man wirklich nicht in jedem Eintrag. Wahrscheinlich kann man die Daten von 5 Sekunden in einen 256-Byte Block packen. Das reduziert den Stromverbrauch nochmal fast 10-fach. Die Daten von 2 Stunden würden dann sogar ins RAM vom uC passen (na gut, STM32L496 aufwärts). > Ist die Genauigkeit der Positionsdaten usw. ähnlich, wie die des > Neo-m8n? > Was mir am 8er gefällt ist die Tatsache, dass zu mehreren > Satelliten-Systemen eine Verbindung aufgebaut werden kann und so die > Genauigkeit und Zuverlässigkeit steigen sollte. Der ublox7 kennt überhaupt nur GPS, aber als DCF77-Ersatz ist er sehr pflegeleicht ;)
noch eine Variante: ein Cortex-M mit mbed-os. HW : https://de.aliexpress.com/item/4000069263843.html Ein STM32F411 mit reichlich Power, so groß wie das Bluepill board. Auf der Unterseite kann ein Flash IC aufgelötet werden, dann hat man mit einem W25Q128 schonmal 16 MByte on Board. https://de.aliexpress.com/item/32540622038.html SW: https://os.mbed.com/docs/mbed-os/v5.15/apis/usbmsd.html ist ein Beispiel für USB MSD mit einer SD Karte. Das SDBlockDevice gegen SPIFBlockDevice ausgetauscht und schon funktioniert das mit dem Flash IC. Dann hat der F411 immer noch genug Resourcen um auch ein kleines Farbdisplay anzusteuern, etwa ein IPS mit ST7735 (sowas was in Fitbit & Co drin ist). https://de.aliexpress.com/item/32964854513.html
Jonathan G. schrieb: > Den Angaben des Herstellers kann man leider nicht immer > vertrauen. Hauptsächlich hängt die Genauigkeit davon ab, wie gut die Antenne ist, ob du in tiefen Häuserschluchten, in einem Wald (eventuell auch noch mit feuchten Blättern), in der Nähe von Radarstationen oder auf dem freien Feld/Wasser deine Position bestimmen willst. EGNOS/WAAS verbessert die Genauigkeit. Und wenn du im Radius von ein paar Kilometern auf eine Genauigkeit von um die 1 Zentimeter kommen willst, brauchst du ein RTK-Empfangssystem.
Jonathan G. schrieb: über den die .txt-Datei auf den Computer geladen werden > kann. Doch ich weiß nicht so ganz wie ich das sowohl hardware- als auch > softwaretechnisch umsetzen kann. Ich habe mich bereits zu UART und > USB-UART Wandlern informiert (zB.: > Beitrag "USB<->UART Wandler?" ), weiß aber nicht, ob ich > auf dem richtigen Weg bin. Eine Lösung wäre die Textdatei, die auf SD-Karte liegt zeilenweise auszugeben über UART, und die einzeln ausgeben Zeilen mit einem Script am Rechner wieder zusammen zu setzten. TR.OLL
TR.OLL schrieb: > Eine Lösung wäre die Textdatei, die auf SD-Karte liegt zeilenweise > auszugeben über UART, und die einzeln ausgeben Zeilen mit einem Script > am Rechner wieder zusammen zu setzten. Dann würde sich NMEA anbieten, da es schon Text ist, der eine Anfangs- ("$") und Ende-("\r\n") Markierung und ggf. auch eine Checksumme besitzt. Damit kann man problemlos "defekte" Strings aussortieren.
TR.OLL schrieb: > Eine Lösung wäre die Textdatei, die auf SD-Karte liegt zeilenweise > auszugeben über UART, und die einzeln ausgeben Zeilen mit einem Script > am Rechner wieder zusammen zu setzten. So so. Du möchtest also nicht nur die Errungenschaften der 2000er Jahre wie USB Speichergeräte ignorieren, sondern auch die der 1980er Jahre wie Kermit oder Z-Modem? Dann kann es ja nicht mehr lange dauern, bis jemand vorschlägt, die Nachrichten in kleine Tontäfelchen einzuritzen ... Für das anwesende Jungvolk: es gab vor dem Internet mit Web- und FTP-Servern auch schon Datenfernübertragung. Das Netz war das Telefonnetz und die Server hießen "Mailbox". Statt eines Webbrowsers verwendete man ein Terminalprogramm. Und wenn man eine Datei herunterladen wollte, dann ging das über ein dafür vorgesehenes Protokoll wie Kermit oder (X, Y, Z)-Modem.
Axel S. schrieb: > TR.OLL schrieb: >> Eine Lösung wäre die Textdatei, die auf SD-Karte liegt zeilenweise >> auszugeben über UART, und die einzeln ausgeben Zeilen mit einem Script >> am Rechner wieder zusammen zu setzten. > > So so. Du möchtest also nicht nur die Errungenschaften der 2000er Jahre > wie USB Speichergeräte ignorieren, sondern auch die der 1980er Jahre wie > Kermit oder Z-Modem? Dann kann es ja nicht mehr lange dauern, bis jemand > vorschlägt, die Nachrichten in kleine Tontäfelchen einzuritzen ... Ist ein bisschen zu aufwendig zum bauen.
Wenn man schon die Schaltung selber macht, würde ich empfehlen, die ISP-Schnittstelle auf jeden Fall nach außen zu legen, ob nun mit USB-Bootloader oder nicht. Bei den Atmegas brauchst Du das sowieso, bei den STM32s hast Du dadurch die schöne Möglichkeit, das Programm zu debuggen. Zu diesem Zweck würde ich noch zwei bis vier LEDs vorsehen - die werden in der Entwicklungszeit nützlich sein und im Dauergebrauch muss man die ja nicht unbedingt einschalten. Übrigens, wenn man das Ding richtig wasserdicht bekommen will, kann man ja induktiv laden und per Bluetooth die Daten übertragen. Ich seh's schon, bei mir hat der Feature Creep wieder eingesetzt. (Ggf. könnte man eine große kaltweiße LED ins Zentrum der Leiterplatte einbauen und die Ansteuerung dafür so programmieren, dass diese angeht, wenn ein bestimmter Bereich betreten wird. Wenns durch das Gehäuse durchscheint, kann man Freunden erzählen, man hätte einen elfischen GPS-Tracker... der leuchtet, wenn Orks in der Nähe sind :) )
Hallo, ich habe mich mal an einem Schaltplan versucht. Wäre super wenn ihr drüber schauen könntet! Viele Grüße
Jonathan Geis schrieb: > ich habe mich mal an einem Schaltplan versucht. Wäre super wenn ihr > drüber schauen könntet! Das wird nix. Lt. Datenblatt benötigt der 32U2 4.5V, um bei 16MHz garantiert stabil zu laufen. Sprich: du planst, grob geschätzt, ihn mit ca. 40% Übertaktung zu betreiben. Das würde ich nicht tun... Außerdem betätigt das RST-Signal von der ISP-Schnittstelle lt. deiner Zeichnung überhaupt nix, zumindest jedenfalls nicht den Reset-Pin des Mega... Tu dir einen Gefallen und nutze einfach ein Wire, um sowas zu verbinden. Das mit den Labels macht man, wenn ein Signal, verstreut über die ganze Schaltung, an 'zig Stellen gebraucht wird. Ansonsten ist es nicht hilfreich, sondern absolut kontraproduktiv.
Sicher, dass D1 richtig herum eingebaut ist? SW1 "ANSchalter" gibts nicht: gibt NUR AUSschalter ;) U1.27(UCAP) fehlt Serientermininierung USB D+/- fehlt (Complete Datasheet: Figure 20-5) Und: es fehlt sicher noch der eine oder andere Puffer kondi Und: wenn Du den U1 mit VUSB (+5V) betreibst, wird das NEO-7M Modul nicht lange leben (das darf nur MAX! 3V6); Du brauchst also eine Versorgungslösung für das NEO Modul UND einen Levelshifter für RxD/TxD. Steht aber alles HIER: NEO-7_DataSheet_(UBX-13003830)-1.pdf und ATmega8U2/16U2/32U2 - Complete Datasheet
und da:
W25Q128JW_RevB_11042019-1761358.pdf
das Flash darf auch nur 3V3 ("W25Q128JVSIM")!
Das alles mit Levelshiftern vollzukleistern ist aber sicher nicht
zielführend:
also darf VCC nur 3V3 sein.
Was dann aber wieder den Einwand von c-hater nochmal relevanter macht...
Alles klar, ich überarbeite den Schaltplan und schicke ihn dann nochmals. Danke für eure Tipps!
c-hater schrieb: > Außerdem betätigt das RST-Signal von der ISP-Schnittstelle lt. deiner > Zeichnung überhaupt nix, zumindest jedenfalls nicht den Reset-Pin des > Mega. … an dem wiederum ein Taster hängt, der nichts tut: /RESET muss gegen GND gezogen werden, um einen Reset auszulösen.
>überarbeite den Schaltplan
Klingt wie eine Drohung.. ;)
Spass beiseite...
Es hat sich nicht nur bei mir bewährt, komplexe Zusammenhänge zunächst
als Blockschema zu entwerfen... (auch erstmal BLACKboxes, wenn man eine
Funktion erstmal nicht näher durchdringen/beschreiben/versteht
will/mag/kann).
Also: Versorgungsspannungsdomänen (hier sicher 3); einzelne
Funktionsblöcke wie eben der µC, Speicher (hier FLASH), Peripherie (GPS
...), und deren Kommunikationswege.
Das dann erstmal durchdenken, Datenblätter lesen und verstehen, ggf den
Use-Case anpassen... und dann kommt irgendwann ein konkreter
Schaltplan...
Es sei Dir wirklich zugute gehalten, nicht gleich ein PCB Layout "zur
Überprüfung" geschickt zu haben...
Jörg W. schrieb: > … an dem wiederum ein Taster hängt, der nichts tut: /RESET muss gegen > GND gezogen werden, um einen Reset auszulösen. Vollkommen korrekt. DAS hatte ich glatt übersehen, kein Witz.
Hier erstmal die verbesserte Version ohne Pegelwandler. Zur Übertaktung des Atmega32U2: http://ww1.microchip.com/downloads/en/DeviceDoc/7799S.pdf Laut dem Datenblatt ist die Versorgungsspannung von 2,7V bis 5,5V. Wegen der oben erwähnten Übertaktung bedingt durch die zu niedrige Versorgungsspannung des AVR kann ich das natürlich nicht so lassen... Ich müsste wirklich einige Pegelwandler einbauen, um das Problem zu lösen und alle verbrauchen zusätzlich Energie. Was würdet ihr mir in so einer Situation raten? Eine höhere Versorgungsspannung durch ein Austauschen des LIPO-Akkus (zB: gegen einen 7,4V LIPO) wäre für mich schlüssiger. Trotzdem bräuchte ich ja dann die Pegelwandler bei den Peripheriegeräten und die 7,4V müssten auch erstmal 5V Versorgungsspannung werden... Ich wäre auch flexibel und kann ein Bluetoothsystem integrieren und gleichzeitig einen 3,3V-AVR nehmen. Per Bluetooth könnten die Daten auch übertragen werden, sind ja nicht soviele Bytes. Was meint ihr? Ziel ist es, das ganze möglichst klein, leicht und komfortabel zu gestalten (5x4x2cm). Auch in SMD-Größe kann ein oben genannter Schaltkreis mit den Pegelwandlern und einer Ladeelektronik für den LIPO-Akku groß werden. Mit zweiseitigen PCBs habe ich leider noch keine Erfahrung gemacht. Ich möchte die Platine selber ätzen und anschließend bestücken. Viele Grüße und tausend Dank!
Jonathan G. schrieb: > Wegen der oben erwähnten Übertaktung ...willst Du ein ziemlich eigenartiges Versorgungsspannungskonzept machen. Ich würde dann doch lieber an den 16MHz arbeiten. Da Du m.E. noch garnicht so genau weisst, was Dein µC eigentlich tun soll, ist also die Takfrequenz des µC Deine geringste Sorge... Wie weiter oben gesagt: Du hast 3 Versorgungsspanungsdomänen: 1.) 5V USB: die brauchst Du als USB-VCC für die µC USB Peripherie (unter beibehaltung dieses µC Typs) und als Input für die (noch fehlende Ladeschaltung des LiPo) 2.) die "3,7V" des LiPo: das ist ja garnicht so, denn ein vollgeladener LiPo hat 4.2V (+/- je nach Typ) und geht runter bis ~3V oder wann immer die im LiPo eingebaute Schutzschaltung abschaltet (steht im DB des LiPo Akkus). 3.) ... und aus diesen beiden Domänen (mindestens aus der LiPo Domäne) solltest Du m.A. nach Deine 3V3 machen (via U-LowDrop Linearregler oder einer kombinierten Buck/Boost-Regler-Lösung (z.B. TI TPS63802)) DAS muss erstmal alles (konzept und technik) passen, bevor Du jetzt auch noch BT/BLE ins Spiel bringst... (herrje, die Jugend)... VG, Stephan
Stephan schrieb: > 5V USB: die brauchst Du als USB-VCC für die µC USB Peripherie Nein, siehe Bild 20-6 im Datenblatt. Er kann das ganze Teil mit 3 oder 3,3 V betreiben und es ist trotzdem USB-fähig. Dann gehen natürlich nur 8 MHz Systemtakt, aber das sollte allemal ausreichen zum Rechnen (wenn nicht: dann doch einen ARM stattdessen benutzen), und die 8 MHz sind auch exakt das, was die USB-PLL benötigt, um ihre 48 MHz draus zu machen. Da es Baugruppen gibt, die nicht die volle LiPo-Spannung von maximal 4 V vertragen, würde ich einen Lowdrop-Regler wie den MCP1825 vorschlagen, der bei Unterschreiten der gewünschten Ausgangsspannung Ein- und Ausgang praktisch miteinander durchschaltet (bis zu ca. 2,0 V hinab), sodass man dann direkt mit der Batteriespannung arbeitet. Bei ca. 3,0 V pro Zelle wird man dann sowieso abschalten wollen.
Den Rest wollte ich wohl garnicht lesen... >Ziel ist es, das ganze möglichst klein, leicht und komfortabel zu >gestalten (5x4x2cm). Klar - genau... => Mal so aus dem realen Leben: unsere kleinsten Tracking-Lösungen sind pi*daumen in dieser Grösse, und alleine das Antennen-Design ist bei der PCB-Grösse eine Wissenschaft für sich (ok, unsere Tracker können auch fallweise von GPRS bis LTE und/oder WLAN und BT und GNSS Multiband/-Constellation z.T. QI-Ladetechnik integriert). Ich mache das jetzt seit vielen Jahren und kann Dir nur raten: lerne sehr schnell und sehr viel... sonst wird das nix. >Mit zweiseitigen PCBs habe ich leider noch keine Erfahrung gemacht. Super Voraussetzung! Bei der gewünschten Grösse des Devices wirst Du mit einer 2-lg PCB auch nicht mehr klar kommen... >Ich möchte die Platine selber ätzen DAS möchstest Du ganz bestimmt nicht! ... oder die Strukturen sind SO klein, dass Du das nicht mehr (zumal OHNE jegliche Erfahrung) selber ätzen kannst. Von der Problematik einer 2 und mehrlagigen PCB mal abgesehen. >und anschließend bestücken. Mag sein, dass Du das hinbekommst. Was hast Du für eine Ausstattung? Mein Tipp und Dein Ehrgeiz in allen Ehren: Vergiss die PCB. Kaufe Dir ein paar Module (wegen mir beim hier so viel zitierten Ali). Stecke das alles auf einem Steckbrett zusammen. Lerne viel über Stromversorgungen und LiPo Ladetechnik. Lerne möglichst viel über die benötigten Schnittstellen (I2C, UART, SPI) und GNSS-Grundlagen. Vielleicht ein kleines bisschen zu Antennen/HF (alleine DAS ist Lern-Jahre-füllend (nein, es reicht nicht, den Rothammel als ePub auf dem Smartphone zu haben). Dann lerne viel über (die) Programmierung (mit oder ohne "OS") eines µC. vg, Stephan
Hat schon jemand geschrieben, das der ICSP Verbinder falsch belegt ist? 1 - MISO 2 - +VCC 3 - SCK 4 - MOSI 5 - RESET 6 - GND
Ok alles klar Stephan, ich merke du bist etwas in Rage :D die Maße und das eigene Ätzen haben wohl das Fass zum Überlaufen gebracht.. Trotzdem hast du mit deinen Punkten wahrscheinlich recht. Ich werde das Projekt erstmal auf Eis stellen und mich zu den ganzen Dingen noch ausführlicher erkundigen. Ich habe trotzdem einiges von euch gelernt und vielen Dank!
Jonathan G. schrieb: > Hier erstmal die verbesserte Version ohne Pegelwandler. Wer Mikrokontroller-Schaltungen ohne Abblock-Kondensatoren aufbaut, nachmacht oder verfälscht, insbesondere bei existierenden Schaltungen die Abblock-Kondensatoren weglässt oder falsch verschaltet oder selbst solche Schaltungen entwirft, in Verkehr bringt und/oder aufbaut ohne Abblock-Kondensatoren nach Hersteller- Empfehlungen zu verwenden, wird mit Zugangs-Ausschluss vom Mikrokontroller-Forum nicht unter zwei Jahren bestraft.
Jonathan G. schrieb: > ich merke du bist etwas in Rage :D Hi Jonathan, nein, das hättest Du gemerkt:) Ich muss nicht, aber ich möchte Dich vor viel verschwendeter Zeit und Geld schützen (die Dir bzw. der Lernkurve am Ende aber ganix nutzen) Wie gesagt: ich verstehe Deinen Ehrgeiz und ich war (vor xx Jahren) genauso ;) Aber Du solltest das Projekt soweit ein-kürzen, dass Du zumindest an einer Stelle "sicheren Boden" hast... von dort kannst Du dann weiterarbeiten... s.o.: vergiss das mit der PCB und nehme zunächst fertige Module (blabla ...) VG, Stephan
Jonathan G. schrieb: > Ich werde das Projekt erstmal auf Eis stellen und mich zu den ganzen > Dingen noch ausführlicher erkundigen. Du kannst dir auch einfach mal ein Evalboard mit einem Controller kaufen und damit ein bisschen spielen. Dann kannst du dir Stück für Stück das Thema erarbeiten.
Jonathan G. schrieb: > Ich werde das > Projekt erstmal auf Eis stellen und mich zu den ganzen Dingen noch > ausführlicher erkundigen. Natürlich fehlt ihm einiges an Wissen, aber deswegen muss man ihm das Projekt doch nicht gleich madig machen. Jeder fängt Mal klein an...
Jörg W. schrieb: > Er kann das ganze Teil mit 3 oder 3,3 V betreiben und es ist trotzdem > USB-fähig. > > Dann gehen natürlich nur 8 MHz Systemtakt, aber das sollte allemal > ausreichen zum Rechnen (wenn nicht: dann doch einen ARM stattdessen > benutzen), und die 8 MHz sind auch exakt das, was die USB-PLL benötigt, > um ihre 48 MHz draus zu machen. Bei Batteriebetrieb möchte man doch einen möglichst niedrigen Takt haben. Sollten das evt. 16 MHz werden, weil der Quarz dann kleiner ist? Ein Keramik-Resonator mit 8 Mhz ist 1.3 x 3.2 mm groß und da sind die beiden Kondensatoren schon integriert. Wegen USB geht leider nicht jeder, aber ein CSTNE8M00GH5L000R0 oder CSTNE8M00GH5C000R0 von Murata sollte passen. Für das GPS-Modul sollte ein Spannungsregler min. 100 mA liefern können, auch wenn es im Mittel nur 30 mA sind. Außerdem sollte diese Versorgung gut gefiltert sein. Längswiderstände in Datenleitungen wären auch nicht schlecht.
Bauform B. schrieb: > Sollten das evt. 16 MHz werden, weil der Quarz dann kleiner ist? Du bekommst alle möglichen Quarzfrequenzen kleiner, als man sie mit der Hand verlöten möchte. Wenn's sein muss, bekommst du mittlerweile in der Größe auch einen 32-kHz-Quarz (wenngleich dann meist mit miserablem ESR). Das ist also wirklich kein Argument. > Ein > Keramik-Resonator mit 8 Mhz ist 1.3 x 3.2 mm groß und da sind die beiden > Kondensatoren schon integriert. Genauer gesagt: er braucht keine. Aber die Kondis machen das Kraut nicht unbedingt fett, dennoch ist so ein Resonator OK, solange er die von USB geforderten Toleranzen einhält. Bei Fullspeed-USB ist das aber auch nicht so schlimm, was da gefordert wird.
Bauform B. schrieb: > Bei Batteriebetrieb möchte man doch einen möglichst niedrigen Takt > haben. Nein, nicht unbedingt. Kommt auf die Anwendung an. In vielen Fällen ist es effizienter, mit dem höheren Takt zu arbeiten. Nach dem Motto: Wer schneller rechnet, darf auch eher wieder pennen... Aber leider: gerade das konkrete Projekt ist so eins, wo die Faustregel nicht passt, jedenfalls nicht "von alleine". Das liegt daran, dass die involvierte Peripherie vergleichsweise langsam ist, insbesondere die UART-Schnittstelle des GPS-Teils. Das ist aber nicht wirklich schlimm. Man nutzt für solcherart entstehende Wartezeiten halt fortgeschrittene Programmiertechniken. Im konkreten Fall würde der energetisch optimierte Code etwa so laufen: Starte den UART-Transfer und puffere die Nachricht im RAM. Gleichzeitig (natürlich nur quasi-gleichzeitig): verarbeite das zuletzt geholte Datenpaket und, wenn fertig, starte den Transfer der aufbereiteten Daten in den externen Flash. Damit ist wenigstens erstmal ein Teil der Wartezeiten auf die langsame Peripherie optimal genutzt. Der Rest ist dann "stottern". Es werden nur noch die IRQs der beiden laufenden Transfers (GPS->RAM und RAM->ext. Flash) behandelt. Die restliche Zeit verbringt die MCU im Idle-Mode. Erst wenn beide Transfers abgeschlossen sind, wird statt im Idle-Mode dann endlich wieder im PowerDown-Mode geschlafen. Das ist dann insgesamt etwas, was weit weg von der hier oftmals empfohlenen Strategie der C-Leute ist, die am liebsten alles in main() abwickeln. Aber es ist eigentlich DER EINZIGE Weg zur Optimierung des Energieverbrauchs, sobald signifikante Wartezeiten, bedingt durch die Peripherie auftreten...
Beitrag #6202790 wurde von einem Moderator gelöscht.
Als reines Übungsprojekt mag der USB-Kabelsalat ja Sinn machen, für den "Ernstfall" ziehe ich meine GPS-Routen lieber wireless ins Phone. Bei vernünftiger Filterung und Speicherung der GPS-Daten spart ein ESP8266 mit seinen internen 3MB-Flash auch die SD-Karte. Zusätzlich liefert er per Web ein komfortables User-Interface. Man will ja auch mal was umstellen und verwalten. Ja, eine Autobatterie in der Nähe ist von Nutzen. ;-)
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.