Liebe Forumsmitglieder und Helfer ;-) Hallo erstmal von meiner Seite - da dies mein erster Post ist, eventuell kurz zu mir. Ich bin der Michael und komme aus Österreich / Grenze zu Deutschland. Ich beschäftige mich mit Programmierung unter C/C++ bereits seit ca. 8 Jahren. In den mC Technik habe ich vor ca. 6 Jahren meine ersten Erfahrungen mit einem Roboter (Hexapod) gemacht. Seitdem habe ich eher nebenbei ein wenig mit verschiedenen Geräten experimentiert. Zum einen ist das dass Teensy USB Board und zum anderen natürlich das Arduino. Mit meiner Matura (für euch Abitur ;-) ) hatte ich auch 3 Jahre Elektrontechnik, indenen ich sicherlich die Grundlagen gelernt habe. Bevor ich mein Projekt poste, möchte ich noch dazu sagen, dass ich mich natürlich ein wenig in die Thematik eingelesen habe, und mich mit der Materie befasst habe. Ich würde von euch gern Machbarkeitsanalysen / Vorschläge und ein paar Antworten auf offene Fragen bekommen, falls dies möglich ist :) Ich bedanke mich jetzt schoneinmal fürs Lesen und eventuell beantworten. Danke! Nun zu meinem Projekt... Und zwar möchte ich ein Gerät designen, welches in die Hosentasche passt -> Scheckkartengrösse wird angestrebt, das folgende Dinge erledigen kann: <> Temperaturwerte bestimmen <> Luftfeuchtigkeit bestimmen <> Erkennen ob der Träger gerade läuft joggt rennt und die Schritte zählen (ungefähr) <> Bluetoothmodul, um die Daten an das Smartphone / App senden zu können Zur Stromversorgung: Da das Gerät ja relativ klein ist und mit einigen Sensoren bestückt ist, ist mir auch klar, dass die Stromversorgung nicht ewig hält. Mir reichen allerdings ca. 12 Stunden. Danach sollte ein aufladen möglich sein. Zu den Sensoren: Ich habe an folgenden Ablauf gedacht: Temperat / Luftfeuchtigkeitssensor sollten jede 10 Minute einmal einen Wert messen und diesen in eine Variable / Array speichern. Um zu erkennen ob gerade gejoggt / gelaufen wird, habe ich an einen Beschleunigungssensor gedacht. Dazu habe ich mir folgende Bachelorarbeit durchgelesen: (eventuell interessiert es wen) https://west.uni-koblenz.de/theses/ba-milker-bewegungserkennung-smartphones Das Bluetoothmodul muss natürlich ebenfalls nicht dauernd funken. Wird ein "Knopf" auf dem Gerät gedrückt, so sollte das Bluetooth (Low Energie !!!) mit dem Handy syncen und sich dann wieder in den Ruhezustand versetzen. Zu meinen offenen Fragen: Welchen Atmega würdet ihr mir für solch ein Projekt empfehlen? Je kleiner dimensioniert, desto optimaler für mich. Seht ihr irgendwelche kritischen Wegpunkte in diesem Projekt? Mit welchen Problematiken muss ich mich genauer auseinandersetzen? Ich vermute dass die Stromversorgung interessant / knifflig werden wird. Wie groß muss der RAM des Atmega definiert sein? Überschlagsmässig will ich lediglich die ungefähre Anzahl der gelaufenen Schritte festhalten - dies würde ja keinen großen Speicher benötigen. Die Thero / Hydro werte würden mich allerdings ebenfalls interessieren. Jede 10 Minuten würde bedeuten: 120 Werte / Stunde --> 1440 Werte auf 12 Stunden. Wenn es Raum nach oben geben würde, wäre ich eher froh ;-) So danke schonmal für eure Einschätzungen Ideen Kritiken. schöne Grüsse
Mach mal nicht alles auf einmal und setz dir sinnvolle Zwischenschritte. Z.B ein klobiger Prototyp der die Funktion erfüllt, aber noch nicht die Abmessungen oder den angestrebten Stromverbrauch oder gar Ladereglerelektronik. So kannst du z.B erst einmal Erfahrungen im Zusammenspiel der Komponenten sammeln und des Auswerte-Algorithmus sammeln. Danach erst sollte man die Industrialisierung in Angriff nehmen... Daher z.B. 3,3v target, überdimensionierter Atmega , BT222 wegen einfacher Anbindung (uart, virtual com-port), adxl335 (leicht zu haben) und temp/hygro sind idR zusammen auf einem Sensorboard, einfach mal nach "Taupunkt bestimmen" suchen und du findest einiges dazu. Und wenn das mal läuft und Erfahrungen gebracht hat, reden wir weiter... Und dann will da noch die App für das Smartphone geschrieben werden...
Welche Luftfeuchtigkeit willst du messen? Die in der Hosentasche oder die Umgebungsluft? Wenn jemand verschwitzt ist, so wird man zwangsläufig einen falschen Wert messen.
Hallo, Vielen Dank für die Informationen - da kann ich mal googeln und bezüglich der Umsetzung überlegen. Eine Frage hätte ich noch: Welche Atmega würdet ihr empfehlen? Das mit dem Taupunkt war übrigends ein spitzen Hinweis - Danke.
Gibt es schon fertig fast so, wie Du es haben möchtest: http://www.wut.de/e-971w1-ww-dade-000.php Die Jogging-Erkennung kann das Smartphone alleine erledigen, das hat doch Beschleunigungssensoren. Frank
Hallo, Das ist mir klar, dass es soetwas bereits in irgend einer Form gibt. Nichts desto trotz würde ich mein Projekt trotzdem gerne selbst realisieren :) Natürlich kann man mit dem Smartphone die Bewegung erkennen, die Bachelorarbeit, welche ich oben gepostet hat, hat genau dies zum Thema. Welchen Atmega würdest du verwenden? Danke :)
Wie René schon geschrieben hat, würde ich auch ersteinmal mit einem überdimensionierten µC anfangen. Damit kannst Du dann ermitteln was Du tatsächlich an Resourcen benötigst. Vielleicht reicht für diese Aufgabe schlußendlich auch bereits ein ATTiny.
Michael Holdon schrieb: > Welchen Atmega würdest du verwenden? > Danke :) Da nich' für. Du solltest dir Gedanken über die Menge der anfallenden Daten machen. Da du sammeln willst und das alles erst zu einem späteren Zeitpunkt 'loswerden' willst, muss der MC genügend RAM haben, um das alles zu speichern, es sei denn, du integrierst gleich eine SD Karte als Massenspeicher. Ich habe einen ähnlichen Datenlogger auf der Basis des Xplained A1 Evalution Board von Atmel gemacht, da dieses einen 8MB SDRam enthält. Der Beschleunigungssensor speichert seine Daten mit Zeitstempel in dem RAM. Während der Datenerfassung läuft der XMega mit 2MHz, um Strom zu sparen, beim Auslesen und direktem Konsolenbetrieb dann mit 32MHz. Gespeist wird das Board von einer Li Zelle, die beim Anstecken der USB Verbindung geladen wird. Bluetooth allerdings habe ich bei mir nicht dran gehabt.
:
Bearbeitet durch User
Frank schrieb: > Wie René schon geschrieben hat, würde ich auch ersteinmal mit einem > überdimensionierten µC anfangen. Damit kannst Du dann ermitteln was Du > tatsächlich an Resourcen benötigst. Tut mir leid - mein Fehler, ich hab das was überlesen! Matthias Sch. schrieb: > Ich habe einen ähnlichen Datenlogger auf der Basis des Xplained A1 > Evalution Board von Atmel gemacht, da dieses einen 8MB SDRam enthält. Das Projekt wäre ja sehr interessant. Falls du da ein wenig Details / Informationen hast (falls es überhaupt öffentlich ist), würde mir das sicherlich weiterhelfen. Danke auf jeden Fall mal für die Antwort.
Puh, bevor du mit externem SDRam anfängst, lass es lieber bei einer einfachen SD.Card-Implementierung, das ist wirklich simpel, wenn du sowieso auf 3,3V arbeitest. Dazu gibt es in Verbindung mit dem Atmega sogar reine SW-Lösungen mit freier Pinbelegung.
Um mal einen konkreten Controller zu nennen, ich empfehle da einen Xmega32E5. Ist das leistungsfähigste was Du noch selber auf das kleinstmögliche TQFP32 Plätzchen selber löten kannst.
René B. schrieb: > Puh, bevor du mit externem SDRam anfängst, lass es lieber bei einer > einfachen SD.Card-Implementierung, das ist wirklich simpel, wenn du > sowieso auf 3,3V arbeitest. Dazu gibt es in Verbindung mit dem Atmega > sogar reine SW-Lösungen mit freier Pinbelegung. Danke für den Hinweis. Ich habe bereits über eine SD Karte nachgedacht, diese Idee jedoch wegen den Gesichtspunkten: -> Hoher Stromverbrauch -> Eigener Dateisystem Treiber verworfen. Wie ich jedoch mit ein wenig googeln herausgefunden habe, existieren fixe Libraries dafür. Moby (Gast) schrieb: > Um mal einen konkreten Controller zu nennen, ich empfehle da einen > Xmega32E5. Ist das leistungsfähigste was Du noch selber auf das > kleinstmögliche TQFP32 Plätzchen selber löten kannst. Vielen Dank für die Information, ich werde mir mal das Datenblatt durchlesen.
schau dir mal von Atmel folgende Seiten an, die Sensorhersteller mit denen Atmel zusammenarbeitet haben echt gute Treiber und Beispielprogramme für die XPlain Serie zusammengestellt: http://www.atmel.com/products/microcontrollers/avr/sensors_xplain.aspx Diese kleinen Boards lassen sich dann z.b. auf das ATxmega256A3BU Xplain board draufstecken, im Atmel Studio bekommst du dann fertige Demo Programme und Treiber. HIer eine kleine Auflistung (unter Sensor) http://asf.atmel.com/docs/latest/search.html?board=XMEGA-A3BU%20Xplained Wenn Du Deinen Prototypen darauf baust, wirst du bestimmt ziemlich schnell zu einem recht guten Ergebnis kommen. Danach kannst Du je nach Flash/SRAM Verbrauch entweder auf eine (pinkompatible) kleinere Version aus der A3U Serie wechseln, oder auf den XmegaE5 der vom Stromverbrauch nochmal niedriger liegt und dazu noch sehr schön klein ist. :)
Ich habe etwas ähnliches als Logger für mein Raumklima gebaut. Meine Zutaten: - MSP430F2274 (bei den MSP430 ist es besonders einfach, stromsparend zu programmieren) - Sensirion SHT11 Sensor für Temperatur/Feuchte - SPI Flash als Datenspeicher - MAX3221 Schnittstellentreiber für RS232 (der läßt sich abschalten, wenn nicht in Benutzung) - LP2950 LDO - EA DOGL Grafikdisplay (rein reflektiv, keine Hintergrundbeleuchtung, auch abschaltbar) Der durchschnittliche Stromverbrauch lag im nA-Bereich, mit einer normalen 4.5V Flachbatterie lief das Zeugs monatelang. Heutzutage würde ich als Speichermedium FRAM nehmen, das braucht beim Schreiben noch weniger Energie als EEPROM oder Flash. Nichtflüchtig wie EEPROM, aber praktisch wie SRAM benutzbar - auch mit der Geschwindigkeit. Es gibt schöne MSP430, die FRAM anstelle von Flash als Programm/Datenspeicher haben. Das hätte mir damals gereicht - ich brauchte nachher nur 32kB. Das mal so als Idee. Es gibt noch ein Leben jenseits von AVR. fchk PS: http://www.ti.com/lsds/ti/microcontroller/16-bit_msp430/fram/overview.page?paramCriteria=no Ich sehe gerade, dass bei 16kB Schluss ist. Schade, aber auch so sind die Dinger interessant.
:
Bearbeitet durch User
@ Frank K. (fchk)
>Das mal so als Idee. Es gibt noch ein Leben jenseits von AVR.
Aber es ist sinnlos! ;-)
Für solche Anwendungen sieht dieser Sensor ziemlich interessant aus: https://www.bosch-sensortec.com/en/homepage/products_3/environmental_sensors_1/bme280/bme280_1 Allgemein zum Thema: Ich würde so ein Projekt nicht mehr mit einem AVR umsetzen. Viele der Sensoren benötigt 32Bit Arithmetik zur Auswertung, für welche ein AVR schlicht und einfach nicht geeignet ist. Mein letzter Versuch, einen Drucksensor anzusteuern, endete mit 4kb Code alleine für die Kompensationsbereichnungn. Dieses hätte ein 32 Bit-Controller mit 1kb hin bekommen. Bei den Inertialsensoren sieht es ähnlich aus.
Tim schrieb: > Mein letzter > Versuch, einen Drucksensor anzusteuern, endete mit 4kb Code alleine für > die Kompensationsbereichnungn. Dieses hätte ein 32 Bit-Controller mit > 1kb hin bekommen. Möglicherweise kann das Projekt vom TE auch nur die Rohdaten speichern und die ganze Rechnerei findet hinterher in der App auf dem Smartphoine statt. Frank
Frank K. schrieb: > Der durchschnittliche Stromverbrauch lag im nA-Bereich, mit einer > normalen 4.5V Flachbatterie lief das Zeugs monatelang. Da würde ich aber eher eine jahrelange Laufzeit erwarten ... vermutlich wäre die Batterie aber eher durch Selbstentladung verstorben :-)
Hallo, Nun noch eine Antwort auf die offenen Punkte :) Danke erstmal für den Bosch-Sensor Link, klingt recht verlockend. Über den Preis muss ich noch Informationen beschaffen. Frank hat mit seiner Aussage Recht. Die Daten werden lediglich (wo auch immer RAM / SD Karte) gespeichert. Die Auswertungen erfolgen dann auf der APP. Ich denke dass ist so mit AVR schon zu realisieren. Bitte gerne um Korrektur, wenn ich hier falsch liegen sollte :)
Hallo, erst vor Kurzem habe ich ein ähnliches Projekt umgesetzt. Bei mir werden Analogwerte gemessen umgerechnet und an ein Smartphone gesendet. Das (Android) Handy sammelt die Daten wertet sie aus und sendet die Informationen dann weiter. Als uC habe ich einen Mega8L genommen, der lag noch in der Schublade. Das BT-Modul ist ein BT222 - also prinzipiell die Kindergartenausstattung und besser bestimmt möglich. Das Zusammenlöten bis zum ersten Versenden von Daten hat nicht lange gedauert. Da war ich nach einem Wochenende (bin kein Profi) gut aufgestellt. Schwieriger hat sich das Programmieren der App gestaltet und diesen Punkt habe ich wohl am meisten unterschätzt. Falls Du auch auf Android-Basis mit Java programmierst kann ich Dir nur das frei verfügbare Bluetooth Chat Projekt von Android Developers zum "dran lang hangeln" empfehlen. Bei der uC-Programmierung und mit uart wirst Du bei Deinen Vorkenntnissen wohl weniger Probleme haben. Da bietet das Tutorial hier auf der Seite aber auch alles was man benötigt. Auf jeden Fall kann ich meinen Vorrednern nur zustimmen und auf Teiletappen setzen - auf keinen Fall an 27 Baustellen gleichzeitig zu arbeiten und immer step by step kleine Aufgaben meistern. Überforderung motiviert ja meistens nicht zum Weitermachen. Sonniger Gruß JP
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.