CFW: Data Logger
Forumsregeln
Bitte beachte die Forumsregeln!
Bitte beachte die Forumsregeln!
CFW: Data Logger
Wie integriert man am besten in die CFW eine Funktion damit man Daten auf der SD-Karte loggen kann?
Via Microcontroller ging das z.B, mit SDFileSystem.h
Via Microcontroller ging das z.B, mit SDFileSystem.h
-
- Administrator
- Beiträge: 583
- Registriert: 26 Dez 2015, 23:49
- Wohnort: Rhein-Main-Gebiet
Re: CFW: Data Logger
Einfach mit den "normalen" Dateifunktionen in der Programmiersprache Deiner Wahl - also in Python z.B. mitchehr hat geschrieben:Wie integriert man am besten in die CFW eine Funktion damit man Daten auf der SD-Karte loggen kann?
Code: Alles auswählen
with fopen('/home/ftc/data.log', 'w') as file:
file.write('Hier kommen die Daten!\n')
Am besten schreibst Du in eine Datei irgendwo unterhalb von "/home/ftc" - da sind die Daten dann per SSH leicht zugänglich, und /home/ftc ist auch in der Default-Konfiguration ohne zusätzliche Rechte beschreibbar.
In der CFW brauchst Du für die SD-Karte und das Deteisystem keinen speziellen Treiber nachrüsten - das macht da der Linux-Kernel.chehr hat geschrieben:Via Microcontroller ging das z.B, mit SDFileSystem.h
- MasterOfGizmo
- Beiträge: 2720
- Registriert: 30 Nov 2014, 07:44
Re: CFW: Data Logger
Wenn Du statt "/home/ftc" z.B. unter Python os.path.join(os.path.expanduser("~") nimmst, dann macht das auf dem TXT keinen Unterschied, aber Dein Programm läuft auch auf einem normalen PC und schreibt die Daten dort auch in das Home-Verzeichnis des aktuellen Users. Das macht die Programmentwicklung ggf. etwas einfacher.richard.kunze hat geschrieben: Am besten schreibst Du in eine Datei irgendwo unterhalb von "/home/ftc"
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32
Re: CFW: Data Logger
Wie kommt man am schnellsten (z.B. via einem Button klick) an die gespeicherten Sensor Daten ran?
Am liebsten wäre mir wenn man über http die Daten downloaden könnte und zwar auf dem "web-interface", weil da gibt es auch schon den upload button.
Zur Info, die Sensor Daten werden direkt in ein Excel file auf SD-Karte gespeichert.
Das Python Programm des BNO055 ist momentan hier (der Speicherpfad muß noch angepasst werden):
https://github.com/chehr/ftc-apps/blob/ ... enshot.png
Noch eine weitere Frage, kann man am PC den smbus simulieren, damit der code auch auf dem PC läuft?
Am liebsten wäre mir wenn man über http die Daten downloaden könnte und zwar auf dem "web-interface", weil da gibt es auch schon den upload button.
Zur Info, die Sensor Daten werden direkt in ein Excel file auf SD-Karte gespeichert.
Das Python Programm des BNO055 ist momentan hier (der Speicherpfad muß noch angepasst werden):
https://github.com/chehr/ftc-apps/blob/ ... enshot.png
Noch eine weitere Frage, kann man am PC den smbus simulieren, damit der code auch auf dem PC läuft?
-
- Administrator
- Beiträge: 583
- Registriert: 26 Dez 2015, 23:49
- Wohnort: Rhein-Main-Gebiet
Re: CFW: Data Logger
Wenn ich mir die App unter https://github.com/chehr/ftc-apps/ anschaue, dann sollte es eigentlich reichen wenn Du im Manifest zusätzlich die folgende Zeile einfügst:chehr hat geschrieben:Wie kommt man am schnellsten (z.B. via einem Button klick) an die gespeicherten Sensor Daten ran?
Am liebsten wäre mir wenn man über http die Daten downloaden könnte und zwar auf dem "web-interface", weil da gibt es auch schon den upload button.
Code: Alles auswählen
html: Datalogger.xls
Kommt drauf an, mit welchem Betriebssystem der PC läuft, und was Du mit "simulieren" meinst. Für Linux würde ich mal nach einem USB-nach-I2C/smbus-Adapter suchen (z.B. den hier: https://www.silabs.com/documents/public ... asheet.pdf - ich hab damit allerdings keinerlei Erfahrung, das Ding kam halt bei Google als Antwort auf "USB smbus converter linux" raus). Damit sollte das eigentlich ganz ohne Simulation auch direkt mit dem echten Sensor funktionieren...chehr hat geschrieben:Noch eine weitere Frage, kann man am PC den smbus simulieren, damit der code auch auf dem PC läuft?
- MasterOfGizmo
- Beiträge: 2720
- Registriert: 30 Nov 2014, 07:44
Re: CFW: Data Logger
Interessant. Was ähnliches habe ich neulich für BMX055 gemacht: https://github.com/harbaum/cfw-apps/tre ... ges/bmx055 . Ggf. kann man das alles kombinieren und hat dann eine App, die mit diversen Sensoren dieser Art funktioniert.chehr hat geschrieben: Das Python Programm des BNO055 ist momentan hier ...
Unter Linux nutze ich meinen alten i2c-tiny-usb. Als Hardware-Basis kann man den Digispark nehmen, der kostet nur ca 1 Euro und wird per USB abgschlossen: https://github.com/harbaum/I2C-Tiny-USB ... /digisparkchehr hat geschrieben: Noch eine weitere Frage, kann man am PC den smbus simulieren, damit der code auch auf dem PC läuft?
Unter Linux gibt es dafür einen Kernel-Treiber. Damit sieht der vom Geräte bereitgestellte I2C/SMBUS am PC identisch zu den anderen smbus'en aus und Deine App würde auf dem PC den Sensor 1:1 ansprechen können. Habe ich neulich gerade mit einem rfid-Leser gemacht. Die App dazu läuft auf dem TXT, dem R-Pi oder dem PC und kann auf allen Systemen den i2c-RFID-Sensor direkt ansprechen.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32
Re: CFW: Data Logger
Einfach genial, damit geht es super einfach.
Vielen Dank Richard für den Tipprichard.kunze hat geschrieben: Wenn ich mir die App unter https://github.com/chehr/ftc-apps/ anschaue, dann sollte es eigentlich reichen wenn Du im Manifest zusätzlich die folgende Zeile einfügst:Dann solltest Du das Excel-File im Webinterface bei den Details der App unter "Application pages" finden.Code: Alles auswählen
html: Datalogger.xls
Re: CFW: Data Logger
Hi Mog,
Ich hatte die Hoffnung, das die I2C Treiber schneller in Python geschrieben sind im Vergleich zu Robo Pro, weil es div Codes schon gibt. Leider habe ich die Hoffnung aufgegeben. Die vorhandenen div Codes sind meist halbfertig und sehr unterschiedlich. Der Aufwand ist fast so groß, wie den Treiber neu zu schreiben. Deshalb macht ein vernünftiges grundgerüst Sinn für div Sensoren dieser Art.
Zunächst bin ich aber noch an prinzipielle Probleme dran immer im Hinblick auf eine hohe Samplingrate. Ist die Liste geeignet bevor man alle Daten auf SD schreibt?
Das finde ich eine gute IdeeMasterOfGizmo hat geschrieben: Interessant. Was ähnliches habe ich neulich für BMX055 gemacht: https://github.com/harbaum/cfw-apps/tre ... ges/bmx055 . Ggf. kann man das alles kombinieren und hat dann eine App, die mit diversen Sensoren dieser Art funktioniert.
Ich hatte die Hoffnung, das die I2C Treiber schneller in Python geschrieben sind im Vergleich zu Robo Pro, weil es div Codes schon gibt. Leider habe ich die Hoffnung aufgegeben. Die vorhandenen div Codes sind meist halbfertig und sehr unterschiedlich. Der Aufwand ist fast so groß, wie den Treiber neu zu schreiben. Deshalb macht ein vernünftiges grundgerüst Sinn für div Sensoren dieser Art.
Zunächst bin ich aber noch an prinzipielle Probleme dran immer im Hinblick auf eine hohe Samplingrate. Ist die Liste geeignet bevor man alle Daten auf SD schreibt?
Re: CFW: Data Logger
Hallo,
dank der genialen Community Firmware funktioniert das Data Logging auf die TXT SD-Karte nun schon ganz gut.
Die Daten werden gleich im Excel Format gespeichert. Die Daten sind für mich wichtig für die Auswertung, Steuerung und Regelung bzgl autonomes Fahren.
Ein Bildschirmfoto anbei mit 10Hz sampling rate: Leider entspricht die Samplingrate mit max ca 25Hz noch nicht meiner Erwartung. Deshalb die frage, wie man diese höher und zwar über 100Hz bekommt. An die visuelle Anzeige zu verzichten habe ich schon gedacht. Aber ist der QTimer die beste Methode oder gibt es bessere in Python? Ist der I2C Bus im High Speed mode?
Außerdem verstehe ich nicht warum die gespeicherten Datenzeilen immer weniger sind wie theoretisch via Samplingrate und Zeit errechnet. Die Anzahl der Datenzeilen sind Zufällig (z.B 1330 oder 327 Zeilen). Ein überlauf der Liste bzw das der TXT nicht genügend RAM hat denke ich ist nicht die Ursache für diesen Fehler. Ich vermute mal das der I2C Bus mit der Kommunikation abbricht. Leider gibt Python keine Fehlermeldung aus.
Das Python Programm ist da:
https://github.com/chehr/ftc-apps/blob/ ... /bno055.py
dank der genialen Community Firmware funktioniert das Data Logging auf die TXT SD-Karte nun schon ganz gut.
Die Daten werden gleich im Excel Format gespeichert. Die Daten sind für mich wichtig für die Auswertung, Steuerung und Regelung bzgl autonomes Fahren.
Ein Bildschirmfoto anbei mit 10Hz sampling rate: Leider entspricht die Samplingrate mit max ca 25Hz noch nicht meiner Erwartung. Deshalb die frage, wie man diese höher und zwar über 100Hz bekommt. An die visuelle Anzeige zu verzichten habe ich schon gedacht. Aber ist der QTimer die beste Methode oder gibt es bessere in Python? Ist der I2C Bus im High Speed mode?
Außerdem verstehe ich nicht warum die gespeicherten Datenzeilen immer weniger sind wie theoretisch via Samplingrate und Zeit errechnet. Die Anzahl der Datenzeilen sind Zufällig (z.B 1330 oder 327 Zeilen). Ein überlauf der Liste bzw das der TXT nicht genügend RAM hat denke ich ist nicht die Ursache für diesen Fehler. Ich vermute mal das der I2C Bus mit der Kommunikation abbricht. Leider gibt Python keine Fehlermeldung aus.
Das Python Programm ist da:
https://github.com/chehr/ftc-apps/blob/ ... /bno055.py
- MasterOfGizmo
- Beiträge: 2720
- Registriert: 30 Nov 2014, 07:44
Re: CFW: Data Logger
Sowas habe ich bei meinem Sensor auch. Du kannst mal ein paar-tausend Sensor-Abfragen direkt in einer Schleife machen und mit Python-Timer-Board-Mitteln die Zeit messen. Das war bei mir immernoch recht langsam, also haben weder Bildschirmausgabe noch QT-Timer damit was zu tun. Und die Zeit korrelliert recht gut mit den pro I2C-Transfer übertragenen Bytes, das ist also kein "setup-Overhead" oder so.chehr hat geschrieben: Leider entspricht die Samplingrate mit max ca 25Hz noch nicht meiner Erwartung.
Nachgemessen habe ich's nicht, aber der i2c scheint nicht sehr schnell zu sein. Kann aber durchaus CFW-spezifisch sein. M.E. hat sich nie einer den I2c im Detail angeschaut. Ging halt einfach ...
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32
Re: CFW: Data Logger
Der Console Befehl
liefert bei mir folgenden Fehler:
Error: Can't use SMBus Quick Write command on this bus
Der Befehl:
zeigt auch an das SMBus Quick Command nicht implementiert ist.
Es scheint mir dass die Übertragungsrate von 100 kbit/s definiert ist und nicht im High Speed mode mit 400 kbit/s.
Wie kann man in den High Speed Mode umschalten?
Code: Alles auswählen
sudo i2cdetect -y 1
Error: Can't use SMBus Quick Write command on this bus
Der Befehl:
Code: Alles auswählen
i2cdetect -F 1
Es scheint mir dass die Übertragungsrate von 100 kbit/s definiert ist und nicht im High Speed mode mit 400 kbit/s.
Wie kann man in den High Speed Mode umschalten?
Zuletzt geändert von chehr am 12 Jul 2017, 11:37, insgesamt 1-mal geändert.
-
- Administrator
- Beiträge: 583
- Registriert: 26 Dez 2015, 23:49
- Wohnort: Rhein-Main-Gebiet
Re: CFW: Data Logger
Im DTS steht für beide definierte I2C-Busse ein Bustakt von 400000Hz, genau wie im DTS aus der originalen Firmware von Fischertechnik.MasterOfGizmo hat geschrieben: Nachgemessen habe ich's nicht, aber der i2c scheint nicht sehr schnell zu sein. Kann aber durchaus CFW-spezifisch sein.
Ob man da beim externen Bus (müsste i2c1 sein, aber keine Garantie) gefahrlos an der Taktrate drehen kann müsste man mal im Treiber und in den Hardware-Specs nachschauen...
Re: CFW: Data Logger
Ist der 1er. Der 0er hängt am Power Controller. Da würde ich besser nix hinschicken.richard.kunze hat geschrieben:(müsste i2c1 sein, aber keine Garantie)
Raphael
Re: CFW: Data Logger
Hi Richard,
die Messung des SCL-Takt hat mit der CFW >100kHz und mit RoboPro <400kHz betragen. Kann man noch irgendwo den Fast Mode aktivieren?
die Messung des SCL-Takt hat mit der CFW >100kHz und mit RoboPro <400kHz betragen. Kann man noch irgendwo den Fast Mode aktivieren?
Re: CFW: Data Logger
Mehr als https://github.com/ftCommunity/ftcommun ... t.dts#L130 ist nicht drin. Also der fast mode ist an. Eventuell musst du python oder so mitteilen, dass du auch den fastmode nutzen willst.
Raphael
Raphael
Re: CFW: Data Logger
Der TXT hat sowohl interne Pull-Ups, als auch welche im AM335x. Liegt es vielleicht an einem insgesamt zu kleinen Pull-Up?
Raphael
Raphael
-
- Administrator
- Beiträge: 583
- Registriert: 26 Dez 2015, 23:49
- Wohnort: Rhein-Main-Gebiet
Re: CFW: Data Logger
Hmm. "CFW > 100kHz" klingt danach, dass der Bus schon im Fast Mode ist (sonst müsste das <= 100kHz sein). Da steckt das Limit dann wohl eher woanders...chehr hat geschrieben:Hi Richard,
die Messung des SCL-Takt hat mit der CFW >100kHz und mit RoboPro <400kHz betragen.
Ich würde mal folgendes probieren
- Timings mit RoboPro auf der CFW messen (also in der CFW die "FT GUI" starten). Wenn das ähnlich schnell ist wie in der Original-Firmware liegt das Limit schon mal nicht im Kernel
- Timings in Python in einer simplen Schleife (ohne GUI, Threads und Timer) messen (wie von MoG schon vorgeschlagen). Wenn das langsam ist, liegts vermutlich an Python.
- Als Gegenprobe das ganze als C-Programm implementieren und nochmal messen. Das sollte dann ähnlich schnell (bzw eigentlich schneller) sein als RoboPro, und wenn das so ist, dann ist definitiv Python die "Bremse".
Re: CFW: Data Logger
Hallo Richard,
habe mal Messungen mit RoboPro mit und ohne CFW durchgeführt und es gibt reproduzierbar einen Geschwindigkeitsunterschied von ca 20%, wobei die CFW etwas langsamer ist.
Via WLan Verbindung ist natürlich diese die Schwachstelle aber auch im Downloadbetrieb jeweils mit und ohne CFW gibt es den Unterschied.
Weitere Infos anbei Zur Info:
Angeschossen war der BNO055 Sensor
Zeitdauer gemessen nach 1000 Lesezyklen a 9 x 16bit Sensorwerte - RoboPro Programm ist im Bild anbei.
Einen Geschwindigkeitsunterschied mit 100kHz oder 400kHz I2C Lesegeschwindigkeit in den RoboPro Settings konnte ich nicht feststellen.
habe mal Messungen mit RoboPro mit und ohne CFW durchgeführt und es gibt reproduzierbar einen Geschwindigkeitsunterschied von ca 20%, wobei die CFW etwas langsamer ist.
Via WLan Verbindung ist natürlich diese die Schwachstelle aber auch im Downloadbetrieb jeweils mit und ohne CFW gibt es den Unterschied.
Weitere Infos anbei Zur Info:
Angeschossen war der BNO055 Sensor
Zeitdauer gemessen nach 1000 Lesezyklen a 9 x 16bit Sensorwerte - RoboPro Programm ist im Bild anbei.
Einen Geschwindigkeitsunterschied mit 100kHz oder 400kHz I2C Lesegeschwindigkeit in den RoboPro Settings konnte ich nicht feststellen.
ich muß mich korrigieren, ich meinte eigentlich <100kHz mit der CFWchehr hat geschrieben:>100kHz mit CFW
-
- Administrator
- Beiträge: 583
- Registriert: 26 Dez 2015, 23:49
- Wohnort: Rhein-Main-Gebiet
Re: CFW: Data Logger
Hmm. Wenn ich mich nicht verrechnet habe kommst Du da dann auch beim schnellsten Lauf (Originalfirmware, 1,88 Sekunden) nur auf etwa 76Kbit/s. Da muss irgendwas anderes bremsen als der I2C-Bus...chehr hat geschrieben:Zeitdauer gemessen nach 1000 Lesezyklen a 9 x 16bit Sensorwerte - RoboPro Programm ist im Bild anbei.
Verdacht nach Bauchgefühl: Die CPU ist am Anschlag (würde auch dazu passen dass die CFW etwa 20% langsamer ist - da braucht der Launcher schliesslich auch etwas CPU)...
- MasterOfGizmo
- Beiträge: 2720
- Registriert: 30 Nov 2014, 07:44
Re: CFW: Data Logger
Naja, 1000*16*9/1.88 ist 76k ... so weit zwar richtig, aber:
Wenn man am I2C ein Byte übertraägt, dann hat das jeweils noch ein Ack-Bit. Bei jedem Transfer geht vorher noch die Chip- und die Registeradresse über den Bus sowie das Start- und Stoppbit. 9*16 Daten-Bit sind also insgesamt mindestens 9*18 + 2 * 9 + 2 Bit. Da kommt man auf 1000 * (9*18 + 2 * 9 + 2) / 1.88 = 97kBit/s. Da ist er also schon echt nah an den 100kbit/s dran.
Wenn man am I2C ein Byte übertraägt, dann hat das jeweils noch ein Ack-Bit. Bei jedem Transfer geht vorher noch die Chip- und die Registeradresse über den Bus sowie das Start- und Stoppbit. 9*16 Daten-Bit sind also insgesamt mindestens 9*18 + 2 * 9 + 2 Bit. Da kommt man auf 1000 * (9*18 + 2 * 9 + 2) / 1.88 = 97kBit/s. Da ist er also schon echt nah an den 100kbit/s dran.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32