Hallo allerseits, ich möchte mich in Sachen Mikrocontroller einarbeiten (Vorkenntnisse bereits vorhanden) und wollte gerne, da ich leidenschaftlicher Biker bin mir einen Fahrradcomputer mit Display-Anzeige (entweder 2x16 mit HD44780 oder 128x32 Pixel mit SED 1520 Controller) bauen. Meine Frage ist es nun, welchen Mikrocontroller ich am besten nehme, der die folgenden Eigenschaften hat: -immer wieder Programmierbar -wenig Außenbeschaltung (zwecks Schaltungsgröße) -viel Speicher, der beim wegnehmen der Spannungsversorgung erhalten bleibt (für die Datenaufzeichnung der Fahrdaten einer Fahrt) -Auslesen, umprogrammieren, und parametrieren alles vom PC über RS232 oder USB -integriertes Uhrmodul -A/D Wandler für Temperatursensor und Herzfrequenzempänger- Schwingkreis (Hier ist die Frage wie empfindlich der A/D Wandler wäre da der Empfängerschwingkreis für den Brustgurt nur einige mV liefert) -niedriger Stromverbrauch Zusätzlich sollen folgende Daten im Controller am Display (beim Grafikdisplay event. Grafische Auswertung) angezeigt und zur späteren Auswertung am PC aufgezeichnet werden: Herzfrequenz vom Brustgurt (+AV +MAX) Geschwindigkeit in km/h über Reed-Sensor (+Max +AV +AV/Gesamt +km/Tag km/Gesamt) Trittfrequenz in 1/min über Reed-Sensor (+Max +AV +Umdrehungen +Umdrehungen/km) Uhrzeit mit Datum Stoppuhr (Tag-Stopp +Gesamtfahrzeit Abtastrate variabel, z.B. alle 10s Das ganze kann über zwei Eingabetasten erfolgen. Ich habe leider nur Erfahrung mit dem Programmieren von PC-Software. Nun möchte ich mit meinen fortgeschrittenen Elektronik-Kenntnissen (jedoch nicht in Sachen Mikrocontroller) ein derartiges Projekt starten. Vielleicht habt Ihr einen interessanten Link oder gebt mir einen Ratschlag, welchen Controller ich nehmen sollte. Vielen Dank für eure Hilfe. Gruß und schönen Sonntag noch. Jan P.
Für solch geringe Anforderungen findest Du bei so gut wie jedem Hersteller passende Controller. Geh einfach mal auf die Seiten von Atmel, Motorola, Renesas, Mitsubishi, Philips, etc...
Hallo Dieter, kannst du deine Aussage etwas spezifizieren. Ich habe mal gehört, dass es auch Controller ohne externen Quarz gibt. Ich bräuchte wie gesagt einen leistungsfähigen mir wenig Außenbeschaltung. Am besten wollte ich die Daten noch über eine IrDa-Modul übertragen. Kannst du mir einen Vorschlag machen, welchen Controller ich nehmen sollte, dass ich einen Anhaltspunkt habe, und mich weiter informieren kann. (Ich hab leider überhaupt keine Marktübersicht über derartige Mikrocontroller) MfG Jan
Hi, nimm' doch einen Atmel Mega8. Der hat einen internen Quarz (muß man per Fuse einstellen) und es gibt eine AppNote, wie man eine RTC (Real Time Clock) damit bauen kann. Hast Du das mit dem Brustgurt schonmal versucht? Das würde mich nun sehr interessieren! Einige mV muß man dann wohl per OPV verstärken. Sebastian
na ja, Quarz intern ist das nun nicht gerade, oft reicht die Genauigkeit aber.
Hallo Sebastian, das mit der Pulsmessung von einem herkömmlichen, analogen Brustgurt funktioniert mit einem Empfängerschwingkreis, der etwa auf 5 kHz abgestimmt ist problemlos. Ich habe bereits eine funktionierende Testschaltung damit aufgebaut. Das Signal habe ich mit einem OPV verstärkt, und dann digitalisiert und eine LED bei jedem Pulsschlag leuchten lassen. Wenn du Interesse hast, dann kann ich dir mal den Schaltplan mailen. Vielleicht kannst du mir dann mit dem Programmieren des Controllers weiterhelfen (LCD Ansteuerung, Berechnungen, Datenlogging etc.) Jan
Hi Jan, ja ich hätte auf alle Fälle Interesse an Deiner Schaltung! Ist das mit den 5kHz so ein Quasi-Standart, oder woher weiß man das denn?!? Ich kann Dir dafür zur RTC (hab' ich schon auf 'nem Mega8 laufen) und zum Loggen noch weiterhelfen. Und vielleicht hab' ich sonst noch ein paar Tips. Sebastian
Hallo, nur kurz noch mal die Frage an Alle: Kennt vielleicht jemand eine entsprechende Internetseite Jemand, der ein solches Projekt (Fahrradcomputer mit Datenlogger) schon durchgeführt hat? Ich wäre für jeden Link oder Hilfe dankbar. MfG Jan P.
Hallo Jan Hätte Interesse an deiner Schaltung für den Empfänger der Herzfrequenz. Kann dir dafür bei dem Progr. helfen, soweit ich das kann. Schreib doch mal, wo es happert. Dann finden wir bestimmt eine Lösung. In welcher Sprache programmierst du denn ? MFG Dieter
Schaltungen für den Empfänger findet man über google. Ist ein 5kHz-Magnetimpuls.
Hi Wollt mal wissen wie weit du mit deinem Projekt bist. Ich hab mir sowas auch schon überlegt. Ich würd auch den Butterfly nehmen ,oder später ein farbdisplay vom Handy. Bin allerdings auch neuling. Ich programmier in in c mit gcc (winavr). kann das nur empfehlen. gruß lcdtastatur
Hallo @Jan kannst Du mal Deine Schaltung ins Forum stellen? Gibt es schon Erfolgsmeldungen? Viele Grüße Achim
Hallo! Vorhin habe ich im Wiki gesehen, daß einer ein Projekt Fahrradcomputer eingestellt hat (http://www.mikrocontroller.net/wiki/Fahrradcomputer). Da ich an einem ganz ähnlichen Projekt arbeite, dachte ich mir, kann ich den Kollegen ja mal kontaktieren. Leider hab ich dann keine Möglichkeit gefunden und deshalb mal das Forum durchsucht. Der Thread hier scheint ja zu passen, also wer von Euch an einem ähnlichen Projekt bastelt - ich würde mich über einen Gedankenaustausch freuen. Ich verwende aufgrund vorheriger Erfahrungen einen 8051, Stromversorgung momentan noch Akkupack, später Nabendynamo (mit Akku-Pufferung), Messung per Reed-Kontakt, Display 4x16, Datenspeicherung temporär in 64kB SRAM, SmartMedia habe ich nicht zum Laufen gekriegt und will also demnächst mal MMC/SD probieren. GPS ist bis auf Weiteres nicht vorgesehen, es soll aber eine gewisse Routenführung über die gefahrene Distanz eingebaut werden. Momentan funktioniert das aber noch nicht - logging hingegen schon. Bye, Burkart
Hallo Burkart, die Wiki-Seite (http://www.mikrocontroller.net/wiki/Fahrradcomputer)stammt von mir. Ich hatte zwar zuvor nach Ähnlichem auf mikrocontroller.net gesucht, aber diesen Thread wohl übersehen. Den Butterfly habe ich mir gerade erst bestellt, ich hoffe er kommt nächste Woche. Dann kann ich mal die ersten Programmteile ausprobieren und uploaden. Programmierst Du auch in C? Ich befürchte, daß wir nicht zuviel Gemeinsames hinbringen. Vielleicht können wir ja bezüglich Datenlogging und -Auslesen was Einheitliches machen. Das PC-Interface könnte ja dasselbe sein. mfg Thomas
Hallo, Thomas! Ich programmiere in Assembler, einfach weil ich da fit bin und noch nie nen Microcontroller in C programmiert habe. Gerade hinsichtlich der Interrupt-Tricksereien habe ich die Einarbeitung in C bisher gescheut. Hinsichtlich der Portabilität ist es da natürlich Essig. Aber über grundsätzliche Dinge können wir uns ja sicher mal unterhalten bzw. dann auch gemeinsam am Wiki-Artikel arbeiten. Mich würde beispielsweise interessieren, wie Du aus dem Nabendynamo ein Tachosignal gewinnst und wie gut das klappt. Ein einheitliches Datenformat wäre auch eine Sache, über die wir mal nachdenken könnten. Genauso ein allgemeiner Ideenaustausch von der Stromversorgung über die Funktionalität und das user interface bis hin zur Montage. Nun bin ich in der Hinsicht nicht sehr erfahren: Labern wir die anderen hier bloß mit Detailkrams voll und sollten das lieber "privat" per Mail machen oder könnte es andere auch interessieren und daher eine öffentliche Diskussion interessanter sein? Wie ist denn eigentlich Dein Stand der Dinge, Thomas? Bisher nur Planung (-> Butterfly gerade erst bestellt) oder bereits eine teilweise Realisierung? Bye, Burkart
ich will auch eine fahradcomputer mit pulsuhr und loggfunktion baunen. ich hab schon eine schaltung in eagle und ein passendes board: http://www.mikrocontroller.net/forum/read-2-111311.html#new mehr Infos gibts im wiki: http://www.mikrocontroller.net/wiki/Projekt_Pulsuhrempf%e4nger_mit_avr-butterfly wir können uns ja alle zusammentun. ein link zu einem fertigen projekt: http://homepages.compuserve.de/SIGIBORST/
Wir sollten uns wirklich zusammentun. Es muß ja nicht alles identisch sein. Anstatt hier Details auszudiskutieren, würde ich vorschlagen, da gleich im Wiki zu machen. Ich habe natürlich nichts dagegen, wenn Ihr die Fahrradcomputerseite modifiziert. Burkhart, willst Du für Dein Projekt eine eigene Wikiseite anlegen? Für Detailpunkte, wie das Datenübertragungsformat u.a. können wir ja wieder eine extra Seite anlegen und darauf verlinken. Für meinen Fahrradcomputer steht das Grundgerüst. Den Butterfly bekomme ich morgen. Wenn der mit dem Fahrradcomputerprogramm das erste Lebenszeichen von sich gibt, würde ich es uploaden? Den Schaltplan des Pulsmessers habe ich angeschaut. M.E. müßte der "virtuelle GND" noch abgeblockt werden. Ich habe noch keinen Brustgurt (bei Obi gibt's grad einen billigen). Mit der Pulsmessung wollte ich mir aber noch Zeit lassen, bis der Rest hinreichend funktioniert. Muß halt aufpassen, daß mir noch Resourcen dafür übrig bleiben.
Servus! Mal eine grundsätzliche Frage: An welche Ausrichtung hattet Ihr denn bei Euren Fahrradcomputern gedacht? Mein Eindruck war, daß es ähnlich dem von Sigi Borst darum gehen soll, Trainingsfahrten aufzuzeichnen und später zu analysieren. Stimmt der Eindruck oder nicht? Mein Fahrradcomputer entspringt jedenfalls einer anderen Überlegung: Ich habe schon ein paarmal mit Freunden Radurlaub gemacht, dabei haben wir dann teilweise per Papier Ortschaften, Strecken usw. mitgeschrieben. Dies ließe sich denke ich elektronisch besser machen. Darüberhinaus bin ich die letzten Jahre immer Ostern mit dem Rad zu meinen Eltern gefahren. Da diese Strecke im Prinzip immer gleich ist, ließe sich ja anhand des Fahrtenbuches der ersten Fahrt eine Art Routenplaner realisieren. Soviel zu meiner Motivation. Entsprechend der Designvorgaben habe ich mich für ein großes Display entschieden (beim Butterfly ist diesbezüglich ja wenig los), dann habe ich noch einen Lichtsensor drin, damit die stromhungrige LCD-Hintergrundbeleuchtung nur eingeschaltet wird, wenn's auch wirklich dunkel ist. Die Logfunktionen scheinen mir in meinem Entwurf ausgeprägter, wohl von dem Ansatz des "Tourtagebuchs" her. Bei Euch war zusätzlich der Brustgurt zur Pulsmessung drin. Den würde ich während einer Sommertour nicht tragen mögen g. Die Kurbeldrehzahl ist natürlich grundsätzlich interessant, für eine gemütliche Tour aber auch wieder sehr viel weniger als für eine Trainingsfahrt. Ähnlich verhält es sich wohl bei der Höhenmessung. Hinsichtlich dieser bzw. der differentiellen Höhenmessung nochmal nachgehakt: Geht das? Klar, der Druck nimmt mit der Höhe ab, Formel habe ich nicht mehr im Kopf, läßt sich aber nachschauen. Aber der Druck verändert sich ja auch in der Ebene (-> Tief-/Hochdruckgebiet). Hier sollte man vielleicht vorher klären, wie stark sich die beiden Effekte im Vergleich zueinander auswirken. Darauf, daß es in der Fliegerei zu funktionieren scheint, würde ich mich nicht verlassen wollen, geht es dort doch um ganz andere Dimensionen. Noch ein Tip: Der Reedkontakt muß entprellt werden! Das geht beispielsweise mit einem Kondensator und nachgeschaltetem Schmitt-Trigger. Ohne Entprellung schien mein Fahrradcomputer abzustürzen. Vermutlich ist entweder der µC hardwareseitig nicht mit dem Signal klargekommen, oder aber es gab Probleme, weil der Trigger-Interrupt ständig aufgerufen wurde. Was das von Thomas vorgeschlagene direkte Bearbeiten des Wiki-Artikels angeht: Ich weiß nicht recht. Das Wiki ist ja toll, für die gemeinschaftliche Bearbeitung eines Projektes finde ich es aber weniger geeignet. Wie würdest Du Dir das vorstellen? Eine neue Seite für "meinen" Fahrradcomputer einzurichten ist nicht vorgesehen. Gut möglich, daß ich das Projekt auf meiner Website veröffentliche, wenn es noch weiter fortgeschritten ist. Und wer vorab irgendwelche Infos haben will - einfach melden :-) Ohne wie gesagt direkt drin rumändern zu wollen, hier noch ein paar Kommentare zum Wiki-Artikel: - Verstehe ich das richtig, der AVR läuft also mit 38kHz? Hm... Also mein 8051 läuft mit 11,0592 MHz, d.h. mit knapp 1 MIPS. Auch ich habe mich damals für einen regelmäßigen Timer-Interrupt entschieden, allerdings aus dem Bauch heraus für 1000 pro Sekunde statt für 1024, aber der Unterschied ist ja marginal. Für einen Interrupt hätte ich also ca. 1000 Maschinenbefehle. Brauche ich nicht, aber nebenher sollen ja auch noch andere Sachen laufen (der Trigger-Interrupt, Ein-/Ausgabe, Spielereien und vor Allem relativ zeitaufwändige Mathe-Routinen für 16/24/32/40-Bit-Zahlen auf einem 8-Bit-Prozessor). Bei einer meiner ersten Software-Versionen habe ich mal grob die Auslastung ermittelt; soweit ich mich erinnere, lag sie für die Grundfunktionen bei einer Größenordnung von 75%. Sicher kann man da noch was optimieren, war vielleicht meine Messung nicht sehr exakt usw. Was ich sagen will: Mit 38 "kIPS" und dem Interrupt alle 1/1024 Sekunde bleiben für den Interrupt max. 37 Assembler-Befehle! Und weil ja eigentlich noch was nebenher laufen soll, sind es deutlich weniger. Entweder Du schaffst es, enorm geschickt zu programmieren, oder Du brauchst einen schnelleren Quarz. - Zur geschätzten SON-Frequenz von 5 ~ 200Hz: Bei meinem Shimano-Nabendynamo und 28"-Rad kriege ich bei 10 km/h ca. 17 Hz und bei 20 km/h ca. 33 Hz. Wobei die Werte nur anhaltsmäßig stimmen. - In der Schaltung gehört vor den 78L05 bestimmt noch ein Ladeelko. - Nochmal der Schaltplan: Wie soll denn die Frequenzmessung funktionieren? Wie ich das verstehe, wird doch aufgrund der Diode über den Widerstand der Kondensator aufgeladen. Und zwar wegen der Z-Diode nur bis 3V, aber wenn erstmal 3V erreicht sind, bleiben es doch (unter Vernachlässigung der minimalen Leckströme) auch 3V. - 20-Zoll-Rad? Bißchen klein, oder? - Das Datenformat unterscheidet sich zwischen uns enorm... Ich habe mich von den Größenordnungen moderner Speicherkarten leiten lassen und wenig Wert auf Effizienz gelegt. Einfachheit war mir da wichtiger, entsprechend gibt es 16-Byte-Datensätze. Bei einem Datensatz pro Sekunde und 10 Betriebsstunden pro Tag (Szenario Sommertour) reicht eine 32MB-Karte dann für 58 Tage. Ich kann mein Format ja mal zum Vergleich anhängen. Noch ein paar Worte an lcdtastatur: Wie sieht es denn bei Dir hinsichtlich des Fahrradcomputers aus? Also hast Du dahingehend schon was realisiert und was sind Deine Vorstellungen? Was den virtuellen GND des Pulsmessers angeht, es wird verschiedentlich empfohlen, das mit einem Op-amp zu puffern. Das hat den Vorteil, daß der Spannungsteiler de facto nicht belastet wird. Siehe beispielsweise d.s.e.-FAQ unter http://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.9.2 Bye, Burkart
Ich werde erst mal die pulsuur mit logger bauen. über den Fahrradfunktion hab ich mir noch keine näheren gedanken gemacht. Die schaltung ist nur für den test und zur funktionsüberprüfung. In der endversion werde ich den Gnd, wie du auch empfelst über einen op erzeugen. allein schondesswegen weil's weniger strom braucht.
Hallo Burkart, Ausrichtung: mir ist beides wichtig. Leistungsorientiertes Datenlogging und Tourenlogging. Das Tourenlogging mache ich z.Zt. mit einem Garmin etrex legend. Das Gerät braucht aber viel Strom, im Wald und im Gebirge (Schluchten) sind die Daten oft schlecht. Über die Daten des Fahrradcomputers hoffe ich, die Routenvariante auf meinem Arbeitsweg erkennen zu können (Kilometer und Steigung). Auf eine Lenkeinschlagsmessung werde ich verzichten. Das Display ist für mich Nebensache. Das Endziel ist u.a. ein im Lenker, Rahmen oder Scheinwerfer fest montierter Datenlogger ohne Display. Übrigens gibt es bei Pollin auch verschiedene BilligLCDs. Eine barometrische Höhenmessung ist sehr stark von den Wetterbedingungen abhängig. Deshalb wollte ich ja auch nur die Luftdruckänderung messen. Bei den hohen Auflösungen, die mir vorschweben (besser als 0.1m/sec), ist aber mit diversen Problemen zu rechen (Luftdruckschwankungen durch Wind, Kfz-Druckwellen,elektrische Genauigkeitsprobleme...). Dann ist da noch das Problem der nichtlinearen Luftdruckänderung über die Höhe. Vielleicht muss man da zur Kompensation doch noch die ungefähre Höhe durch Luftdruckmessung bestimmen. Die Entprellung der Reedkontakte mache ich zur Zeit sw-mäßig, das ist wirklich ein bißchen doof. Wie langsam die Anstiegsflanke an den normalen Prozessorports und wie groß somit der Kondensator und Vorwiderstand sein darf, weiß ich (noch) nicht.X.Han hat mich drauf hingewiesen, daß es besser ist, zwei Reedkontakte zu verwenden, um das eventuelle Hin- und Herschalten zu vermeiden, wenn der Magnet in der Nähe des Reedkontakts zu stehen kommt.Ist halt aufwendiger. Der Atmel hat einen internen 8MHz-Oszillator, der über einen Teiler heruntergeteilt werden kann - je nach Auslastung. Der 38kHz-Oszillator taktet die RealTimeClock. Der Timerinterrupt kommt alle 250ms. Die 1/1024 Sekunden-Auflösung kommt durch das Auslesen des HW-Zählers. Die Nabendynamofrequenzen könnten schon ungefähr stimmen. Wenn ich langsam fahre, sehe ich die Lampe flimmern. Zur Frequenzmessschaltung: Du hast recht, da muß doch noch ein Widerstand nach Masse. 20-Zoll Rad: Von meinen Fahrrädern haben die meisten 20"-Vorderräder (http://www.hpv.org). Da Du Speicherkarten einsetzen willst, brauchst Du wohl gar keine Radcomputer<->PC-Kommunikation? Ich bin gerade am Überlegen, ob ich das X-Modem Protokoll dafür verwenden soll. mfg Thomas
Gerade habe ich im Wiki die Version 0.0 (!) meines Fahrradcomputers hochgeladen. Damit wir mal richtig diskutieren können. http://www.mikrocontroller.net/wiki/Fahrradcomputer#Software
Hallo Jan, könntest Du vielleicht den Schaltplan für den Pulsschlag-Empfänger hier ins Netz stellen? Ich würde ihn gern nachbauen. Vielen Dank günther
Servus! @lcdtastatur: Klingt gut. So braucht nicht jeder alles selbst zu machen sondern kann ein wenig bei anderen Projekten abschauen. @Günther: http://www.mikrocontroller.net/wiki/Pulsuhrempf%E4nger_mit_AVR_Butterfly @Thomas: Zur Entprellung der Reed-Kontakte verwende ich folgende Schaltung: +5V | +-+ | | R1 | | +-+ | __ |\ +--|____|--+--| >o--- µC /INT | R2 | |/ o | 1/6 74HC14 (Schmitt-Trigger NOT) \ Reed --- o --- C | | GND GND R1 beträgt 4k7 (oder 10k oder sowas um den Dreh). Mit R2=120k und C=100nF kann ich leider nur Geschwindigkeiten bis ca. 17,7 km/h messen - alles darüber wird von der Schaltung "entprellt" :-) Von daher werde ich auf 33nF oder 25nF umlöten. Hab ich bisher noch nicht gemacht, weil bei meinem Laboraufbau das simulierte Tachosignal 50% duty cycle hat und damit alles funktioniert (Fahrrad hingegen: geschätzt 5% duty cycle). Das mit den zwei Reed-Schaltern ist natürlich eine pfiffige Idee. Ich habe es trotz einiger Versuche nicht hingekriegt, auf dem Oszilloskop den Reed-Schalter prellen zu sehen. Nichtsdestotrotz tut er es offensichtlich, daher kann ich mir auch prinzipiell vorstellen, daß es zu Problemen kommen kann, wenn der Reed-Sensor (bzw. der Magnet) mal genau an der prellenden Stelle zum Stehen kommt. Auf der anderen Seite wie gesagt, selbst als ich's drauf angelegt habe, ließ sich dieser kritische Punkt nicht finden. Und auch bei professionellen Tachos habe ich noch nie einen zweiten Reed-Kontakt gesehen. Von daher wird's meinerseits bei 1 Reed-Kontakt bleiben. Nochmal wegen der Frequenzmessung per Nabendynamo. Ich befürcht, die Schaltung funktioniert immernoch nicht. Im Anhang mal das Ergebnis einer PSpice-Simulation bei f=35Hz (was bei meinem Dynamo und Radumfang 28" ca. 20km/h entspricht). Rot ist dort das Signal vom Nabendynamo, grün die Spannung über dem Kondensator. Da dieses Signal an den Komparatoreingang des AVR gehen soll, stellt sich nun die Frage, was denn am anderen Eingang des Komparators hängt. Ich vermute mal, das direkte Signal vom Nabendynamo? Hierdurch bekäme man jetzt ein Tachosignal in der Frequenz des Nabendynamos. Prima. Da das Signal des Nabendynamos aber auch negativ werden kann, würde der mit 5V/GND gespeiste Komparator/AVR doch vermutlich kaputtgehen. Also vielleicht besser ein Abgriff hinter der Diode, also nur die positiven Halbwellen. Da die Diode in Sperrichtung einen nahezu unendlich hohen Widerstand hat, liegt nun jedoch an beiden Komparatoreingängen fast das gleiche Signal an. Nur fast, von daher könnte es noch grade so gehen, darauf würde ich mich jedoch nicht verlassen wollen. Vorschlag: Hinter die Diode, also parallel zum Spannungsteiler einen weiteren Spannungsteiler einbauen und dann dort die zweite Komparatorspannung abgreifen. Hat gleich den angenehmen Nebeneffekt, daß die Spannung von ungesunden 8Vp auf verträglichere z.B. 5Vp abgesenkt werden kann. Sollte das zu ungenau formuliert gewesen sein, bitte melden, dann mache ich noch ein Bildchen. Aber auch wenn das jetzt schön klingt, selbst bei dieser Schaltungsversion habe ich noch starke Bedenken. Denn alle Überlegungen habe ich mit einer Wechsel_spannungs_quelle gemacht. Tatsächlich verhält sich ein Dynamo aber eher wie eine Stromquelle. Das bedeutet, daß der Nabendynamo bei zügiger Fahrt nicht 6Vrms liefert sondern eben 500mArms. Und wenn man diese 500mA durch einen Widerstand von z.B. 2*27k=54k fließen läßt, gibt das einen Spannungsabfall von sage und schreibe U=I*R=27kVrms. Bei meinem Nabendynamo war ein Schalter dabei, der in derartigen Überlastsituationen (das gleiche passiert beispielsweise, wenn der Frontstrahler durchbrennt) einfach abschaltet. Wie das beim SON ist, keine Ahnung. In jedem Fall dürfte die Schaltung nicht mehr so funktionieren, wie sie soll. Lösungsvorschlag: Mit Dauerlicht fahren. Durch den Parallelwiderstand des Frontstrahlers von ich glaube ca. 8 Ohm bleibt die Spannung dann im Nennbereich. 20": Liegerad hab ich nicht bedacht, sorry. Bezüglich Speicherkarten und PC-Kommunikation: Ich stehe diesbezüglich vor einem gewissen Dilemma. Erstens habe ich bisher noch keine Speicherkarte zum Funktionieren gekriegt, brauche also für die Vorabversion mit Speicherung in SRAM oder EEPROM auf jeden Fall eine PC-Kommunikation. Aber selbst wenn es dann irgendwann mit MMC/SD statt SmartMedia klappen sollte, bleibt das Dilemma, ob ich einen USB-Card-Reader verwende oder die Daten seriell auf den PC überspiele. Card Reader hat den Vorteil erhöhter Geschwindigkeit, erfordert aufgrund des proprietären Dateiformats aber vermutlich Low-Level-Zugriff, noch dazu unter Windows, da kenne ich mich also gar nicht aus. RS232 wäre schön einfach, das kann ich sowohl auf µC- als auch auf PC-Seite, dafür ist es aber furchtbar langsam (zumindest wenn man ein x Megabyte Fahrtenbuch übertragen will). Dritte Möglichkeit wäre noch, den µC FAT-konform auf die Speicherkarte schreiben zu lassen, was sicher die beste aber auch die arbeitsintensivste Lösung wäre. Aber das mit der Speicherkarte ist momentan eh noch Zukunftsmusik, es wird also zumindest provisorisch ein serielles Übertragungsprotokoll geben. Ob nun binär oder beispielsweise gleich als CSV, keine Ahnung. Bei einer früheren Testversion habe ich glaube ich irgendein quick'n'dirty Mittelding gemacht. X-Modem, war das nicht dieses Protokoll, wo es zwei Zeichen für XON und XOFF gab? Was macht man da, wenn man genau diese Werte übertragen muß? Wo siehst Du denn die Vor- und Nachteile dieses Protokolls? Dein Fahrradcomputer soll ja ziemlich klein werden, wenn er beispielsweise im Lenker eingebaut werden soll. Da dürfte dann sicher in der Miniaturisierung viel Kniff stecken. Kannst Dich ja ein wenig an dem von Sigi Borst orientieren. Bei mir wird's wohl eher auf ein Riesenteil rauslaufen. Bei der Miniaturisierung und auch beim Höhenmesser werde ich Dir wohl kaum mehr helfen können, als Dir viel Erfolg! zu wünschen. Bye, Burkart
Hi Burkhart, Entprellung: Das Prellen verursacht m.E. zwei Probleme: Fehlzählung: Kann sw-mäßig ausgeschlossen werden (Timer). Überlastung des Prozessors durch viele Interruptrequests: Könnte sw-mäßig auch ausgeschlossen werden (temporär gesperrte Interrupts). Wenn es damit wirklich Problem gibt, könnte man den Kondensator in Deiner Schaltung über einen Open Collector Port sw-gesteuert entladen. Das Dauerprellen, wenn der Magnet in der Nähe des Kontakts zur Ruhe kommt, ist vielleicht auch wg. der Hysteres des Kontakts kein ernstes Problem. Nabendynamo: Vielen Dank für die Spice Simulation. Den anderen Eingang des Analog Komparators wollte ich auf eine feste Spannung legen (UB/2 oder interne Ref). Dann müßte er mit der grünen Kurve aus Deinem Bild sauber funktionieren. Aber auch hier gibt es ein "Prell-"Problem. Wenn das Signal verrauscht/gestört ist, kommen bei einem Durchgang auch mehrere Interrupts. Aber auch das sollte sw-mäßig abfangbar sein. Wg. der Stromquellencharakteristik des Dynamos habe ich die Z-Diode anstelle eines reinen Widerstandsteilers eingebaut. Die Spannung des Nabendynamos wird nicht auf 27kV ansteigen, schon weil ich diese 13.5kW nicht ertreten kann. Mit Dauerlicht fahre ich sowieso, die Schaltung soll aber bei durchgebranntem Scheinwerfer auch noch gehen. Ein Eingangsspannungsschutz des 78L05, bzw. eine allgemeine Spannungsbegrenzung im Lichtnetz des Fahrrads ist sinnvoll. Speicherkarten: passen leider nicht in den Fahrradlenker. Eben weil RS232 relativ langsam ist, will ich die Daten binär übertragen. Zur Fehlervermeidung ist das X-Modem Protokoll schon sinnvoll. Ich habe das Gegenstück der AVR350 programmiert. Zusammen mit einem selbsgeschriebenen PC-Testprogramm geht's. Aber nicht mit lrzsz und auch nicht mit Minicom. Ist aber auch nicht wo wichtig. Wenn es mit meinem eigenen PC-Programm geht, reicht das ja. Höhenmesser: Auf der Fahrradcomputerseite habe ich einen Link auf ein Variometer mit dem Atmel eingefügt. Dort werden die Drucksensordaten einfach über einen 24bit ADC eingelesen. Einfach! Die schaffen damit 20cm/sec. D.h. mit einem analogen Differenzierer davor sollten die <10cm/sec Auflösung schon möglich sein. Die Genauigkeit ist aber noch offen. mfg Thomas
Hy there Viele "Tüftler" schreiben immer nur über eine mögliche Schaltung zum Empfang der gesendeten Signale für die im Handel erhältlichen Brustgurte. Hat vielleicht schon mal jemand versucht, eine Schaltung zum eigentlichen Messen des Herzschlags (sprich der Sender eines solchen Brustgurtes) zu entwickeln bzw. nachzubauen ??? sincerely, Chris
Bzgl. Spannung am Nabendynamo: Das Thema hat mich spätestens nach dem zweiten teuren Standrücklicht, das der Nabendynamo zerschossen hat, auch beschäftigt. Erstmal hat ein Dynamo ja neben dem inneren Widerstand ja auch eine innere Induktivität, so daß mit der Frequenz nicht die Spannung immer weiter steigt, sondern irgendwann der Wechselwiderstand nur noch durch die Induktivität bestimmt wird, also der Widerstand mit der Frequenz ansteigt -> dann müßte aus der Stromquelle Dynamo (langsame Fahrt) eine Spannungsquelle werden. Offenbar liefert der Nabendynamo aber doch höhere Spannungen als der Seitenläufer, für den so ein Standrücklicht dimensioniert ist. Wenn ich nun eine niedrigere Spannungsbegrenzung wünsche, wollte ich lieber eine Spule davor hängen, damit ich bei schnellerer Fahrt nicht sinnlos mehr Verlustleistung in einer Spannungsbegrenzung verheize, sondern lieber den Strom drossel. Habe ich recht oder ist da noch ein Denkfehler drin?
Hallo Philipp, eine Spule als frequenzabhängiger und damit geschwindigkeisabhängiger Vorwiderstand ist eine gute Idee. Aber: Will ich bei 500mA 50V abfallen lassen, brauche ich 100 Ohm, bei 50Hz sind das 300mH. Außerdem darf der SON dann wirklich keine Stromquelle mehr sein. Vielleicht wäre ein Parallelkondensator besser: Die Beleuchtung hat einen Widerstand von ca. 6V/500mA=12 OHm. Das wären dann ca. 200uF parallel. Man könnte auch einen Schaltregler einsetzen. Die Frage ist, wie der mit der "Stromquelle" zurechtkommt. Übrigens: Viel kann an dem Diodenrücklicht nicht kaputt sein. Eine Reparatur lohnt sich bestimmt. mfg Thomas
Parallelkondensator? Gut, sollte einen ähnlichen Effekt haben: die Leistung steigt dann zwar weiter, aber der Kondensator verschiebt die Phase entsprechend, so daß irgendwann nur noch die Blindleistung ansteigen sollte. Als zusätzliche Sicherheit kann man ja noch eine Z-Diode die Elektronik schützen lassen. Im wesentlichen fehlt mir aber noch die Testfahrt mit Meßgerät, wo ich überhaupt mal eine Meßkurve "Spannung über Geschwindigkeit" aufnehmen sollte. Aber mein "Hauptrad" mit dem Nabendynamo weilt halt seit einigen Wochen in der Werkstatt, wo der Händler vergeblich versucht, ein Ersatzteil für meine geliebte 3x7-Nabe zu bekommen. Solange rutscht der Seitenläufer im Schneematsch und ich muß froh sein, überhaupt Licht zu haben. Die Diodenrücklichter liegen übrigens in der großen Kiste mit der Aufschrift "lohnt zu reparieren". Wenn das Holz für den Winter gesägt ist, der Hühnerstall fertig (die Hennen weigern sich, zu Schneehühnern zu mutieren) und die Kinderschar mich kurz in Frieden läßt, werde ich wohl nochmal reingreifen können ... (-: Gruß, Philipp.
Hallo, miteinander! Nach langer, langer Abstinenz habe ich diesen Thread wiedergefunden. Mein Fahrradcomputer hat inzwischen übrigens ein wenig über ein Jahr Entwicklungszeit auf dem Buckel (mit Pausen, versteht sich). Ich habe für die nächste Zeit geplant, das Log zusätzlich zum PC auch auf dem Fahrradcomputer selbst anzeigen und ein paar Statistiken berechnen zu lassen. Dann fehlt noch die Ansteuerung der MMC/SDC und ein weniger labor-mäßiger Aufbau. Damit bin ich dann hoffentlich bald in der Lage, mal wieder einen Praxistest zu machen. Wie sieht's bei Euch aus? @Thomas: Mit dem Prellen hast Du denke ich recht. Entprellen per Software ist natürlich schicker als eine Hardwarelösung. Bei mir kann die Platine glücklicherweise auch größer werden, also spare ich mir mit einem IC, den ich sowieso brauche, und ein paar passiven Bauteilen gern den Software-Mehraufwand. Kannst ja dann mal schreiben, wie das Entprellen per Software in der Praxis funktioniert. Das mit der Kondensatorentladung per open collector port habe ich nicht verstanden. Bitte nochmal erläutern. Frequenzmessung per Nabendynamo: UB/2 (1,5V o.ä.) klingt gut, nur ginge es dann nicht auch einfacher? Also Spannungsteiler und das war's? Die Z-Diode ist also wegen der Stromquellencharakteristik drin, hm... Und wofür ist der Kondensator? Ich kapier's irgendwie nicht. Wenn Du das nochmal (vielleicht gleich im Wiki?) erklären könntest, wär's prima. Ansonsten Hauptsache es funktioniert :-) Das mit den 13,5kW, um ja... Da hab ich wohl glatt den Innenwiderstand des Nabendynamos übersehen. Peinlich. Hierzu weiter unten mehr. RS232 und XModem: In einer früheren Praxistest-Version habe ich mal jedes Byte aus dem Log als Hex-Zahl mit folgendem Leerzeichen übertragen. Auf der Empfängerseite (PC) hat dann ein Programm eine CSV-Datei draus gemacht, die sich per Tabellenkalkulation weiterverarbeiten ließ. Ist nicht unbedingt die schönste und effizienteste Möglichkeit der Datenübertragung, hat hier aber voll und ganz gelangt und ließ sich außerdem ruckzuck programmieren. Und für 64kB braucht es bei drei übertragenen Byte pro Nutzbyte und einer Übertragung mit 115200 Baud auch nur 17 Sekunden für das komplette Log. Somit ist dies auch in der aktuellen Version das Mittel der Wahl. Ich tendiere für die Zukunft dahin, die Daten direkt als CSV zu übertragen. Da braucht es auf Empfängerseite dann lediglich ein Terminalprogramm, das den Datenverkehr in eine Datei schreibt (z.B. HyperTerminal von Windows) und eine Tabellenkalkulation. Und auf dem µC ist's auch kein großer Aufwand. Speicherkarten kannst/willst Du nicht verbauen. Welches Speichermedium kommt denn dann infrage? Die 512kB DataFlash des Butterfly? 64kB I²C EEPROM? µC-internes EEPROM? @Philipp: Meine eigenen Messungen der Nabendynamo-Kenndaten waren leider mangels besserer Ausrüstung sehr grob. Im Internet habe ich nach langer Suche unter folgender Adresse ein sehr ausführliches Dokument zu u.a. diesem Thema gefunden (416 Seiten sprechen für sich): http://www.enhydralutris.de/Fahrrad/#beleuchtung Natürlich hat ein Nabendynamo einen Innenwiderstand. Schande über mich, daß ich bei meiner Rechnung von oben mit den 27kV eine ideale Stromquelle angenommen habe. Dieser rangiert laut oben genanntem Dokument übrigens in dem Bereich von 2 bis 4 Ohm. Die Inneninduktivität liegt abhängig vom Dynamotyp um die 40 mH. Was die hohen Spannungen angeht, Innenwiderstand hin oder her. Ich habe bei Leerlauf auf dem Oszilloskop einen deutlichen Spannungsanstieg erkennen können. Dummerweise ist in dem Schalter zu meinem Nabendynamo eine seltsame Schutzschaltung integriert, die bei Überschreiten von ca. 8V die Leitung kurzschließt, bis man wieder komplett anhält. Wie hoch die Spannung am Nabendynamo selbst also wird, weiß ich nicht. Ich erinnere mich jedoch, daß in der Betriebsanleitung stand, es könnten gefährliche Spannungen erreicht werden. Gemäß der Untersuchung aus dem Internet entspricht die Spannung in Volt im Beinahe-Leerlauf (R = 800k) knapp der Geschwindigkeit in km/h. Zumindest gilt dies im realistischen Geschwindigkeitsbereich; bei 200 km/h sind's dann nur noch 120 V. Eine gewisse spannungsbegrenzende Wirkung scheint die Inneninduktivität also zu haben. Bye, Burkart
Könntest du im http://www.mikrocontroller.net/wiki/Fahrradcomputer bitte dein kompletten schaltplan veröffentlichen. Würd mich interesieren
@123: Wen meinste denn jetzt? Thomas' Fahrradcomputer läuft soweit ich weiß auf dem Atmel Butterfly (siehe Wiki) ohne besondere Außenbeschaltung. Meiner läuft auf einem 8051er mit externem SRAM, MAX232, 4x16-Zeichen-Display und weiter oben aufgeführter Entprellschaltung für die zwei Buttons und den Reed Kontakt. Die LCD-Hintergrundbeleuchtung läßt sich noch über einen FET an- und ausschalten, soweit also nix Exotisches. Bye, Burkart
Hallo, Ich wollte mal fragen, ob es Neuigkeiten gibt, der letzte Kommentar scheint ja schon Länge her zu sein. Ich hab die Schaltung mal aufgebaut um die Frequenz des Nabendynamos (Shimano Alfine) mit einem Arduino Nano Clone auszulesen. Nur den Teil für den Signaleingang, die Stromversorgung ist erstmal zweitrangig. Da beim Abgreifen von nur einer Phase viele Fehlimpulse dabei waren, war meine Überlegung, die Gegenphase ebenfalls zu überwachen und das Signal nur akzeptiert wird, wenn vorher das jeweilige Gegensignal kam. Das funktioniert ganz gut, nur leider nicht gut genug für den Nabendynamo. Mit zunehmender Geschwindigkeit nimmt leider auch die Zahl der nicht erkannten Impulse zu. Habt Ihr Eure Projekte in funktionsfähigen Zustand gebracht? Mit welcher Schaltung?
paul schrieb: > Ich wollte mal fragen, ob es Neuigkeiten gibt, der letzte Kommentar > scheint ja schon Länge her zu sein. Na ja, wenn ich daran denke, wann ich zur Schule gegangen bin sind 14 - 15 Jahre nun auch nicht so viel ;-) > Das funktioniert ganz gut, nur leider nicht gut genug für den > Nabendynamo. Mit zunehmender Geschwindigkeit nimmt leider auch die Zahl > der nicht erkannten Impulse zu. Hast Du mal einen Optokoppler verwendet? Da prellt nichts und er ist schnell genug. Wenn Du Arduino verwendest, sollte in Deinem Programm keine delay() vorkommen. Ich sehe da kein Problem.
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.