Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

@David: Carbono hat doch außerhalb vom Forum vor 2-3 Tagen mit einem Edge? und GSC-10 diese Geschwindigkeiten sekündlich erfasst. Ich hab nur die Graphik daraus gemacht, die einzelnen schwarzen Punkte sind die Geschwindigkeiten.

Carbono Auslauf 4 Reifen mit Edge.jpg


Sieht doch hervorragend aus, was meinst Du dazu ? Was hat er denn besser gemacht, anderes Gerät also ein Edge 705 anstatt eines Edge 800 ? Liegt es nur daran dass die neuen Geräte nicht mehr so "gut" sind ?

Möchte mal wissen wie "gut" mein GPSmap62 dafür ist, hat auch ANT+ Erfassung.

***

Allerdings sehe ich in der Graphik an manchen Stellen Knicks drin, die eigentlich nicht erklärbar sind. Ich müsste wohl besser so wie Du es gemacht hast, mehrfach die Geschwindigkeit ändern und gleichzeitig zB. mit meinem Polar als Kurve darstellen um die tatsächlichen Unterschiede zu sehen, oder ?


Gruß Leonardi
 
Zuletzt bearbeitet:
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Sieht doch hervorragend aus, was meinst Du dazu ? Was hat er denn besser gemacht, anderes Gerät also ein Edge 705 anstatt eines Edge 800 ? Liegt es nur daran dass die neuen Geräte nicht mehr so "gut" sind ?
Beim Edge 705 hat es viele Firmware-Interationen gebraucht, bis er vernünftig gearbeitet hat. Beim Edge 800 scheint es genauso zu sein. Wieso z.B. 1 sec Aufzeichnung auf dem 800 zunächst unmöglich war, ist mir völlig schleierhaft, wo man doch wusste, wie wichtig das für Leute mit Leistungsmesser ist.

Möchte mal wissen wie "gut" mein GPSmap62 dafür ist, hat auch ANT+ Erfassung.
Nach http://www.thisisant.com/directory ist das Device-Profile für den Geschwindigkeits- oder Geschwindigkeits/Trittfrequenzsensor im GPSmap62x nicht implementiert.

Allerdings sehe ich in der Graphik an manchen Stellen Knicks drin, die eigentlich nicht erklärbar sind. Ich müsste wohl besser so wie Du es gemacht hast, mehrfach die Geschwindigkeit ändern und gleichzeitig zB. mit meinem Polar als Kurve darstellen um die tatsächlichen Unterschiede zu sehen, oder ?
Vielleicht kommen die Knicke zustande, weil die Zeitgeber in Sensor und Aufzeichnungsgerät auseinander driften und ab und zu wieder synchronisiert werden müssen.
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Genau die gesendeten Daten meine ich.
Ist ja toll, dass du das, was in diesem Thread hier beschrieben ist, bereits realisiert hast :)
Das war nicht weiter schwierig, da die eigentliche Arbeit bereits getan war. Wir haben hierzu quarqd verwendet, einen Deamon, der sich einerseits mit einem ANT+ Stick verbindet und auf der anderen Seiten einen TCP Socket öffnet. Auf diesem Sockel wird ein Protokoll definiert, das es erlaubt, beliebige ANT+ Sensoren (bis zu 4) auszulesen. Das einzige was wir hier noch gemacht haben, ist die Art und Weise zu ändern, wie der Stick angesprochen wird. Verwendet haben wir das ganze um eine SRM Kurbel auszulesen.

Besteht Interesse an dieser Lösung? Ich kann ja einmal eine Testfahrt mit einem O-Synce-ANT+ Geschwindigkeitssensor protokollieren. Dann können wir sehen, ob die Daten etwas taugen.

Viele Grüße,

Alex
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Besteht Interesse an dieser Lösung? Ich kann ja einmal eine Testfahrt mit einem O-Synce-ANT+ Geschwindigkeitssensor protokollieren. Dann können wir sehen, ob die Daten etwas taugen.
Oh ja bitte!
Am Besten auf eine hohe Geschwindigkeit beschleunigen (z.B. bergab?) und dann ausrollen lassen, dann kann man Ausreißer erkennen.
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Besteht Interesse an dieser Lösung? Ich kann ja einmal eine Testfahrt mit einem O-Synce-ANT+ Geschwindigkeitssensor protokollieren. Dann können wir sehen, ob die Daten etwas taugen.

Viele Grüße,

Alex

Ich fände es interessant zu wissen, was wirklich und wie häufig vom Geschwindigkeitssensor gesendet wird. Kannst Du gleichzeitig mit einem vertrauenswürdigem Messgerät messen, um eine Referenz zu haben, und vielleicht auch noch mit einem Edge705/800/810 aufzeichnen, um zu sehen wie der die Daten "interpretiert"?

Auch interessant: Synthetische Daten eines simulierten Geschwindigkeitssensors an den Edge705/800/810 senden und gucken, ob das Richtige aufgezeichnet wird. Durch das Vorgaukeln eines Leistungsmessers mit ANT+-Stick hat man einige Firmwarefehler aufzeigen können.
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Ich habe das alles mit Python + numpy / scipy / pandas / matplotlib / ipython gemacht.

Oh, tausend Dank für die Links, werde ich mir mal ansehen... da ich als Privatier keinen Zugriff auf mein geliebtes Origin mehr habe :-(

BTW.: Die Tage kam ein Fernsehbeitrag über Geschwindigkeitsmessungen an Distelfaltern (vmax ca. 50 km/h!) mit aufgeklebtem präzisions-GPS. Soweit ich verstanden habe, werden die für die hohe Genauigkeit erforderlichen Zwischenwerte mittels eines Beschleunigungssensors per Koppelnavigation ermittelt!
 
Zuletzt bearbeitet:
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Sag Ich das nicht schon die ganze Zeit. Navis sind Müll und meine GPS Uhr taugt dafür.
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Oh ja bitte!
Am Besten auf eine hohe Geschwindigkeit beschleunigen (z.B. bergab?) und dann ausrollen lassen, dann kann man Ausreißer erkennen.
Aktuell kann ich nur drinnen Messungen machen, weil ich noch eine mobile Stromversorgung für die Raspberry-Pi besorgen muss. Ich habe mal auf dem Zentrierständer eine Beispielmessung gemacht. Hier Anhang anzeigen speed2.txtist ein Protokoll einer Messung im "Rohformat". Es gibt einen Eintrag pro Radumlauf. Der Timestamp ist in Sekunden (Auflösung in Micro-Sekunden, gerundet dargestellt), wobei diese jedoch auf dem Raspberry-Pi ermittelt sind und nicht vom Sensor kommen. Hier noch einmal ein Plot der Datenspeed.png

Viele Grüße,

Alex
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Habe jetzt mal aus den 'Timestamps' die Zeit bis zur nächsten Radumdrehung herausgezogen.
Noch schlechter als die 'RPM' in deinem Diagramm:
Radumdrehungszeit delta t.PNG
Diese sind im Viertelsekundenraster - aber nicht mal dies genau: oft sind es 0,01 Sekunden weniger - bei den hohen Werten auch mal 0,02s.
So kann man das vergessen. Ursache?
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Habe jetzt mal aus den 'Timestamps' die Zeit bis zur nächsten Radumdrehung herausgezogen.
Noch schlechter als die 'RPM' in deinem Diagramm:
Anhang anzeigen 55395
Diese sind im Viertelsekundenraster - aber nicht mal dies genau: oft sind es 0,01 Sekunden weniger - bei den hohen Werten auch mal 0,02s.
So kann man das vergessen. Ursache?
Hi,

mir ist nicht ganz klar, was Du genau auf den Achsen aufgetragen hast. Die Werte der Timestamps sind auf 0,01s gerundetet Mikrosekunden. Die kann ich problemlos auch exakt ausgeben, bin mir aber nicht sicher, was diese überhaupt aussagen, da Linux ja kein Echtzeitbetriebssystem ist, kann man die Werte eigentlich vergessen.

Die RPM-Werte sind da vermutlich schon für zuverlässiger, sind allerdings nur Integer und bei rounds per minute wohl nicht genau genug. Genaueres wird man wahrscheinlich per ANT+ leider nicht bekommen.

Alex
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Die kann ich problemlos auch exakt ausgeben, bin mir aber nicht sicher, was diese überhaupt aussagen, da Linux ja kein Echtzeitbetriebssystem ist, kann man die Werte eigentlich vergessen.
Wir benötigen aber mindestens die Millisekunden zwischen zwei aufeinanderfolgenden Sensor-Ereignissen: Bei 1,5m Radumfung und einer Geschwindigkeit von 20m/s dauert eine Radumdrehung nur 75mS. Wird als nächster Wert dann 76ms gemessen, dann kommt 19,74m/s also 0,26m/s oder fast 1km/h weniger heraus. Damit können keine Werte zwischen 71 und 72km/h mehr aufgelöst werden.
Wenn da lediglich die absoluten Unix-Sekunden seit 1970 abgespeichert werden, dann kann man diese natürlich vergessen.
Die RPM-Werte sind da vermutlich schon für zuverlässiger, sind allerdings nur Integer und bei rounds per minute wohl nicht genau genug.
Ja, zwischen 799 U/min und 800 (~72km/h) liegen 60 Umdrehungen pro Stunde, also 90m oder fast 0,1km/h; das mindeste was wir benötigen.
Genaueres wird man wahrscheinlich per ANT+ leider nicht bekommen.
Da kann doch nur ein Zähler hochgezählt werden. Auf Grund der 0,25s-Rasterung nur mit einer Frequenz von 4Hz? :eek:
Dann wäre die mögliche Auflösung ja lediglich 1,5m/4 also 0,37m/s oder 1,35km/h :(:mad:
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Wenn da lediglich die absoluten Unix-Sekunden seit 1970 abgespeichert werden, dann kann man diese natürlich vergessen.Ja, zwischen 799 U/min und 800 (~72km/h) liegen 60 Umdrehungen pro Stunde, also 90m oder fast 0,1km/h; das mindeste was wir benötigen.
Da kann doch nur ein Zähler hochgezählt werden. Auf Grund der 0,25s-Rasterung nur mit einer Frequenz von 4Hz? :eek:
Dann wäre die mögliche Auflösung ja lediglich 1,5m/4 also 0,37m/s oder 1,35km/h :(:mad:
Kann natürlich sein, dass der O-Synce Sensor nicht die beste Hardware verwendet und daher die 4Hz kommen. Auch bei voller Zahlenauflösung ist diese 4Hz Rasterung vorhanden.
Ich schaue mir den Code des quarqd morgen noch einmal genauer an, vielleicht wird ja auch darin ein select mit einem timeout von 250ms gemacht? Ein solches (mit Timeout 1s) habe ich heute bereits entfernt.

Wenn nichts dabei herauskommt, bleibt möglicherweise nur noch eine dezidierte Hardware zu verwenden. Für alle Sensoren außer der SRM-Kurbel haben wir hier sonst dezidierte Hardware entwickelt.

-- Alex
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Da kann doch nur ein Zähler hochgezählt werden. Auf Grund der 0,25s-Rasterung nur mit einer Frequenz von 4Hz? :eek:
Dann wäre die mögliche Auflösung ja lediglich 1,5m/4 also 0,37m/s oder 1,35km/h :(:mad:
Leider steht im Standard "Ant Message Protocol and Usage":

"The default message rate is 4Hz, which is chosen to provide robust performance as described below. It is recommendedthat the message rate be left at the default to provide more readily discoverable networks with good power and latencycharacteristics."

Schade!

-- Alex[/FONT]
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Leider steht im Standard "Ant Message Protocol and Usage":

"The default message rate is 4Hz, which is chosen to provide robust performance as described below.
Schade!
Das heißt also bei 4 Radumdrehungen pro Sekunde beginnt er sich bereits "zu verschlucken". Das sind bei unseren 20"-Laufrädern nicht mal 6m/s also 21,6km/h.
Das darf doch nicht wahr sein :( Und ich hätte mir fast so ein ANT+ System gekauft :dagegen:
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Das heißt also bei 4 Radumdrehungen pro Sekunde beginnt er sich bereits "zu verschlucken".

Nein, das heißt nur, dass die Übertragung der Nachrichten nur im 4 Hz Raster erfolgt und, in diesem Fall, der Sensor scheinbar nicht mehr auflöst.

Das könntest Du ja durchaus ändern, in dem Du bspw. einen Arduino nimmst, diesen zählen/loggen lässt und die Rohdaten dann per Bluetooth an Dein Smartphone schickst (oder auf Smartcard schreibst).

Ich denke die Rohfassung eines solchen Loggers sollte man in ein paar Stunden geproggt haben. Notfalls fragst Du Jenkie nebenan ... ;).
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Nein, das heißt nur, dass die Übertragung der Nachrichten nur im 4 Hz Raster erfolgt und, in diesem Fall, der Sensor scheinbar nicht mehr auflöst.
Scheinbar oder anscheinend? Ich fürchte ich hab's noch nicht genau verstanden: Es geht jedenfalls um einen Ant+ Sensor?
Der speichert in 1/4 sec. einen Impuls. Überträgt ihn. Das bedeutet ~20km/h. Im nächsten Intervall hat er zwei Impulse registriert. Also ~40km/h. Dann wieder zwei ~40km/h, dann drei ~60km/h. Macht bis jetzt vier Intervalle und 8 Impulse, also im Schnitt 40km/h.
Soll das so ablaufen? Das macht doch keinen Sinn - zumindest nicht für die hier notwendige Erfassung.
Das könntest Du ja durchaus ändern, in dem Du bspw. einen Arduino nimmst, diesen zählen/loggen lässt und die Rohdaten dann per Bluetooth an Dein Smartphone schickst (oder auf Smartcard schreibst).
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Der speichert in 1/4 sec. einen Impuls. Überträgt ihn. Das bedeutet ~20km/h. Im nächsten Intervall hat er zwei Impulse registriert. Also ~40km/h. Dann wieder zwei ~40km/h, dann drei ~60km/h. Macht bis jetzt vier Intervalle und 8 Impulse, also im Schnitt 40km/h.
Soll das so ablaufen? Das macht doch keinen Sinn - zumindest nicht für die hier notwendige Erfassung.

Nein, das funktioniert so natürlich nicht. Der Sensor berechnet mit den gemessenen Impulsen die Rotationsfrequenz des Rades und überträgt diese standardmäßig im 4 Hz-Raster an den Tacho, der mit dem eingetragenen Radumfang die Geschwindigkeit ausrechnet und anzeigt.
Funktioniert auch über 20 km/h recht genau, allerdings gibt es in der Anzeige eine merkliche Verzögerung, sehe ich besonders bei der Leistungsanzeige mit Hilfe meiner Powertap, aber auch bei starken Bremsungen.

Gruß,

Tim
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Nein, das funktioniert so natürlich nicht. Der Sensor berechnet mit den gemessenen Impulsen die Rotationsfrequenz des Rades und überträgt diese standardmäßig im 4 Hz-Raster an den Tacho, der mit dem eingetragenen Radumfang die Geschwindigkeit ausrechnet und anzeigt.
Gut. - Aber wo was gerechnet wird ist ja nicht entscheidend, sondern mit welcher Auflösung die Information (herrührend aus den ursprünglichen Impulsen) abgespeichert werden kann. Und da kann nur das Ergebnis aller Ereignisse innerhalb eines 0,25-Sekunden-Intervals weitergegeben werden.
Ob der Sensor jetzt die Zahl der Impulse bei >20km/h (1, 2, 3, 4, oder gar 5) oder die Frequenz (4Hz, 8Hz, 12Hz 16Hz oder 20Hz) weitergibt macht keinen prinzipiellen Unterschied.
 
AW: Diskussion der Messungen vom Rolltest Elfershausen am 28.12.2013

Die RPM-Werte sind da vermutlich schon für zuverlässiger, sind allerdings nur Integer und bei rounds per minute wohl nicht genau genug. Genaueres wird man wahrscheinlich per ANT+ leider nicht bekommen.
Danke für die Messung.

Wenn die Auflösung so zu gering ist, kannst Du ja einfach mehrere Magnete nehmen.

Es wäre interessant, die Grenze des Sensors Richtung hoher Frequenz auszuloten. Wenn man die Obergrenze kennt, kann man sofort die zur erwarteten Höchstgeschwindigkeit passende Anzahl an Magneten nehmen. Wenn er bis 1000 rpm mit 1 rpm Auflösung messen würde, wäre das ja schon ganz anständig.

David
 
Zurück
Oben Unten