Hallo,
Ich habe gerade ein "witziges" Problem.
Vielleicht kennen hier einige den Voltcraft PM-60V/20A, ein billiger
(60€) Gleichstromzähler für den Modellbau etc.
Eigentlich ein feines Teil, loggt automatisch Spannung, Strom und Zeit
sowie ein paar min./max. Werte und errechnet daraus z.b. die
Akkukapazität etc.
Nun verfügt das Dingen noch über einen serielle Schnittstelle, über die
sich die geloggten Daten auf den PC laden und recht übersichtlich
plotten lassen.
Allerdings läuft die Zeit auf dem Gerät zu langsam, sobald die
Schnittstelle verbunden ist (und somit die Werte auf dem Software
Display aktualisiert werden). Während des Downloads steht die Uhr ganz.
Sobald der Stecker gezogen ist, passt die Zeit, sonst verliert sie je
Minute 15-17 Sekunden!!!
Das führt natürlich zu völlig wirren Kapazitäten, die da rauskommen.
Habe das gemerkt, als ich zwei neue Akkupacks "vermessen" habe. Das eine
hatte plätzlich 20Wh weniger Kapazität als das, das ich offline gemessen
habe.
Da müssen mal wieder äußerst pfiffige Programmierer am Werk gewesen
sein!
Hat das Problem schon mal wer gehabt und evtl. eine alternative Firmware
gezaubert? Sollte eigentlich kein großes Dingen sein. Ein offizielles
Firmwareupdate habe ich nicht finden können.
Ansonsten das hier nur als Hinweis für andere, die ähnliche
Überraschungen mit dem Teil erleben. Wird auch unter anderem Label
verkauft.
Euer
Akkutester
Thorsten Legat schrieb:> Wie soll denn bitteschön die RTC durch eine RS232 beeinflusst> werden?
Wer sagt dass die interne Uhr über eine richtige RTC läuft, und da nicht
irgendwo ein Task läuft:
1
while(1){seconds++;sleep(1);}
und der halt weniger Zeit bekommt, wenn nebenher noch was anderes läuft?
Man ist allgemein viel zu optimistisch bzgl. der Qualität von
Industrie-Software, da ist unglaublich viel zusammengefrickelter Schrott
drunter.
Bei einem Markenhersteller gehe ich ja mal davon aus, dass das nicht so
billig gemacht ist. Habe ein Multimeter von denen, das geht sehr sehr
genau. Die sitzen immerhin in De.
Wie sollte der denn messen und anzeigen auf dem LCD, wenn er die ganze
Zeit wartet?
Ich glaube eher, der TE hat eine falsche Baudrate eingestellt. Zu hoch.
Und dann passt das Timing nicht mehr.
Thorsten Legat schrieb:> Bei einem Markenhersteller gehe ich ja mal davon aus, dass das nicht so> billig gemacht ist.
Haha, so wie die Software bei VW? Oder die von Microsoft (zum Glück
mittlerweile gebessert)? Software-Struktur sieht man nicht, da wird
gerne gepfuscht. Aber irgendwann fällts dann doch auf. Man schaue doch
mal nur hier im Forum, was für Frickellösungen als "Produktiv" genutzt
werden. Das fängt ja shcon damit an, dass unbedingt die "einfachsten"
(am wenigsten mächtigsten) Tools verwendet werden müssen, um sich den
Lernaufwand zu sparen.
Thorsten Legat schrieb:> Die sitzen immerhin in De.
Und das heißt... was? Dass die Entwicklung nicht nach Indien
outgesourced wurde? Dass aus deutschen Hochschulen nur die perfekten
Entwickler kommen, und langfristig planende Manager? Wenn ein Programm
zu funktionieren scheint, wird es doch ausgeliefert, und bloß kein
Gedanke daran verschwendet, ob die Grundidee nicht doch eine Katastrophe
ist.
Thorsten Legat schrieb:> Wie sollte der denn messen und anzeigen auf dem LCD, wenn er die ganze> Zeit wartet?
Kann doch sein, dass die ein RTOS verwenden. Ein Task hat die o.g.
Schleife, ein anderer macht den UART, und wenn letzterer beschäftigt
ist, geht dem anderen die Zeit aus.
Thorsten Legat schrieb:> Ich glaube eher, der TE hat eine falsche Baudrate eingestellt
Die Baudrate des UART soll die RTC beeinflussen? Das klingt ja nach noch
seltsamerer Programmierung.
Kleine Anekdote:
An meiner Hochschule gab es als Forschungsprojekt eine Art
Frequenzzähler für eine besondere Anwendung. Dieser wurde auf einem AVR
umgesetzt. Weil es aber zu anstrengend war, im Datasheet nahczulesen wie
der Input Capture funktioniert, wurde das halt in Software gemacht durch
fleißig Zyklen zählen usw. Wenn man also auf die Idee kommt noch eine
andere Funktion hinzuzufügen - Kommunikation per UART z.B. - kommt das
Timing durcheinander. Das Projekt war natürlich super und kam gut an.
Nur weil man das vernünftig machen kann - mit Input Capture - heißt
das noch lange nicht, dass das auch gemacht wird!
Akkutester schrieb:> Allerdings läuft die Zeit auf dem Gerät zu langsam, sobald die> Schnittstelle verbunden ist (und somit die Werte auf dem Software> Display aktualisiert werden). Während des Downloads steht die Uhr ganz.
Dann wird wohl ein delay(1000) die Länge der Sekunden bestimmen und die
serielle Übertragung nicht asynchron ablaufen.
Dr. Sommer schrieb:> Kann doch sein, dass die ein RTOS verwenden. Ein Task hat die o.g.> Schleife, ein anderer macht den UART, und wenn letzterer beschäftigt> ist, geht dem anderen die Zeit aus.
Freunde, es geht um dieses Gerät:
https://www.conrad.de/de/voltcraft-pm-60v20a-dc-leistungsmessgeraet-pm-60v20a-spannung-500-6000-vdc-000-6000-vdc-mit-externer-spannungsversorgung-strom-001-20-a-101668.html
Da drin muckelt ein offensichtlich räudig programmierter PIC irgendwas
vor sich hin, kein RTOS.
Wär schön, wenn ein sicher vorhandener Timer auch genutzt würde. Es
dürfte aber wirklich eher eine einfache wait Funktion in der Schleife
sein, evtl. angepasst auf die ADC Messungen und die LCD Ausgabe. Denn
nur damit passt die Zeit recht genau, soweit ich das bisher beobachten
konnte.
Wieso für die Ausgabe der paar Daten auf den UART 17(!) Sekunden je
Minute vertrödelt werden können, ist mir allerdings völlig schleierhaft.
Wie schafft man denn sowas wohl? Oder ist das ein Feature vom PIC?
Kenne persönlich nur die AVRs und da wüsste ich kaum, wie das gehen
sollte.
Akkutester schrieb:> Da drin muckelt ein offensichtlich räudig programmierter PIC irgendwas> vor sich hin, kein RTOS.
Gibt's dafür kein RTOS? Damit kann man doch so einfach und schnell
programmieren (hust)!
Akkutester schrieb:> Wieso für die Ausgabe der paar Daten auf den UART 17(!) Sekunden je> Minute vertrödelt werden können, ist mir allerdings völlig schleierhaft.
Gar kein problem, wenn man synchron sendet, d.h. nach jedem byte in
einer while-Schleife wartet bis es weg ist (busy waiting). Die
allermeisten Programme hier im Forum sind doch genauso geschrieben. Wenn
man jetzt viele Bytes sendet, und die meiste Zeit des Prozessors mit
Warten auf Fertigstellung vertrödelt, passiert genau sowas, völlig
unabhängig von AVR / PIC / whatever. Besonders beliebt ist dieses
Vorgehen auch bei den LCD-Routinen oder SD-Karten-Ansteuerungen, die mit
Warteschleifen das Programm blockieren.
