Forum: Mikrocontroller und Digitale Elektronik Bau eines Fahrradcomputers mit Anzeige und Datenlogger

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

Schaut euch mal die Seite hier an.


http://www.ricksunfinishedstuff.com/

Gruß
Chriss

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

Nur, weil's noch keiner geschrieben hat:

Kauf' Dir 'n AVR Butterfly.

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.