Datenlogger auf ARDUINO- Basis

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • @Zitronenfalter

      Jetzt, wo du darauf aufmerksam machst, fällt mir auch der Unterschied in der Bestückung auf, siehe Bild Vergleich.

      Beide grünfarbigen Module sind gleich bestückt. Sollte ich sie so umbauen, wie im Sparkfun Original? Wäre einen Versuch wert, oder?

      Ich könnte auch einen neuen 328 einbauen

      Gruß
      Ulrich
      Files

      The post was edited 1 time, last by Ulrich ().

    • Ulrich wrote:

      Sollte ich sie so umbauen
      Würde ich nur als ganz letzte Maßnahme machen.
      Das ist ja auch ein anderer Bauteil, kann also sein, dass das sogar passt und zum darunterliegenden Spannungsregler gehört der eventuell etwas anders konstruiert ist.

      Viel wichtiger ist es zu vergleichen was auf dem Chip (lt. Schaltplan ein ATMEGA328P) steht und was auf dem Quarz (lt. Schaltbild 16MHz).
      Den Atmega gibt es als 328, 328P und 328PB in dieser Gehäusebauform, das HEX-File ist aber wohl für den 328P.
      Bascom weigert sich sogar wenn der definierte Controller nicht mit dem tatsächlich verbauten übereinstimmt zu flaschen, kann das aber nur direkt aus seiner Umgebung nicht aber wenn der Speicher mit HEX-Daten überschrieben wurde (im HEX-File stehen keine Informationen zum Controller).
      Wenn die Chips und die Quarze von beiden Modulen ident sind, könntest du aber das Original komplett über den ISP-Anschluss auslesen (also sowohl Flash als auch EEPROM und die Fusebits und dann anschließend die so gewonnen Daten in den Klon ebenfalls mit der ISP-Schnittstelle übertragen.
      Sonst fällt mir eigentlich nicht mehr viel ein.
    • @Zitronenfalter

      Könnte es sein, dass sich der Begriff "OpenLog" nur auf das Format der gespeicherten Log-Datei bezieht?

      @Ulrich

      Ich hatte anstelle des Log-Moduls ein I2C-EEProm (z.B. 500kBit) benutzt und dort die Daten (binär, also platzsparend) geloggt.
      Macht deutlich weniger Ärger und man muss sich nicht um die Befehle für ein externes Modul kümmern.

      Zur Übertragung an den PC hätte ich die Daten seriell an ein Terminal-Programm oder ein selbst gestricktes VB.Net Programm übergeben.
      Im Falle eines Terminal-Programms hätte man die Daten dann am Controler zum Senden im CSV-Format geschrieben.
      Damit wäre das direkt in Excel importierbar.

      Aber hey! Warum einfach, wenns kompliziert auch geht.

      Mir ist schon klar, dass das Modul auf eine Speicherkarte schreibt, die man dann einfach in den PC steckt.
      Aber solange werden keine Daten geloggt.

      Mit EEProm und dem Fifo-Prinzip kann man auch während der Übertragung an den PC loggen.

      Hat alles seine Vor- und Nachteile.
    • @Zitronenfalter

      kannst du aus den Bildern heraussehen, ob und was da bei dem grünfarbigen Modul schiefläuft?
      Dem entgegen sehe ich wiederum im Schaltbild der originale Sparkfun-Module keine Diode, so wie sie im Foto bestückt ist. Was ist da los? a_17_af3b400f

      @Mitch64

      Einen Vorteil dieser Openlog Module, neben der Größe, sehe ich auch darin, dass man sie einfach mit TX-Signalen beschicken kann, und diese mit dem Flow CSV Viewer einlesen kann, womit alle Signale mit ihrem grafischen Verlauf sofort dargestellt werden, da müsste man in Excel erst mehrere Schritte vollziehen, um sowas ähnliches zu errreichen. Auch ist die Datenmenge zur Darstellung beim Flow CSV Viewer nur vom Speicher des PC's begrenzt.

      Ich hatte zuvor schon die AVR-Dos SD-Card Variante eingesetzt, ist auch eine passable Möglichkeit, jedoch ist dort ebenfalls ein extra-SD-Card Modul erforderlich, welches zudem noch ein wenig größer ausfällt.

      Wenn also die OpenLog-Module das tun, wofür sie gedacht sind, halte ich das für eine gute Lösung. a_58_b54cfdb4

      Wenn gewünscht, zeige ich mein Programm, welches auf Basis der von Zitronenfalter gelieferten Schnipsel läuft. Dieses kann zur Laufzeit mehrere Files anlegen kann und funktioniert mit dem Sparkfun Modul.

      Gruß
      Ulrich
    • Ulrich wrote:

      Einen Vorteil dieser Openlog Module, neben der Größe, sehe ich auch darin, dass man sie einfach mit TX-Signalen beschicken kann, und diese mit dem Flow CSV Viewer einlesen kann, womit alle Signale mit ihrem grafischen Verlauf sofort dargestellt werden, da müsste man in Excel erst mehrere Schritte vollziehen, um sowas ähnliches zu errreichen. Auch ist die Datenmenge zur Darstellung beim Flow CSV Viewer nur vom Speicher des PC's begrenzt.
      Mir scheint, dass du dich mit Excel nicht so gut auskennst.
      Da kann man auch, einmal konfiguriert, diese CSV direkt in eine vorbereitete Vorlage lesen mit dem Effekt, dass alles direkt angezeigt wird.

      Aber sei's drum.

      Muss jeder selber wissen, welche Variante für einen die beste ist.

      Mir ist der Syntax für die Steuerung der Log-Module schon zu umständlich.
      Da muss man sich auch erst durch-fuchen. - Nichts für mich.

      Hat's jetzt eigentlich geklappt mit dem HEX-File?
    • Ulrich wrote:

      keine Diode
      Kann gut sein, dass beim Klon die Stromversorgung anders aufgebaut ist und das deshalb dort eben anders aussieht.
      Viel wichtiger wäre der Vergleich der Chipdaten und der Quarze (das kann ich auf den Bildern leider nicht erkennen.
      Es gibt sonst keinen logischen Grund warum die HEX-Datei nicht läuft auf den Klonen außer eben Differenzen bei den Bauteilen oder eine andere Beschaltung..
      Im Prinzip könntest du ja die Verbindungen anhand des Schaltplans vergleichen und kontrollieren. Wenn bei beiden die gleichen Ports verwendet werden müsste das ja funktionieren.
      Natürlich unter der Voraussetzung das die Bauteile ident sind.

      Mitch64 wrote:

      Aber hey! Warum einfach, wenns kompliziert auch geht.
      Also ich habe das z.B. letztens dazu verwendet um Messdaten eines Impulsschreibers abspeichern zu können. Der registriert Impulsfolgen die innerhalb von Sekunden ankommen (eine Art Wahlimpulsfolge mit allfälligen Kontaktprellungen die wiederum zu Störungen kommen könnte).
      Um das dann später auswerten zu können musste ich die irgendwo zwischenspeichern und nicht erst nach einer Impulsfolge den speicher auslesen um dann weitermessen zu können.
      Da es eine serielle Schnittstelle bereits gab an der ich die Messprotokolle ausdrucken konnte, bot sich das OpenLog direkt an und habe gar nicht erst überlegt ob ich da irgend einen I2C-Speicher vorsehe.Wie man sieht gibt es durchaus Anwendungen die Sinn machen.
      Inzwischen habe ich den fernbedienbar gemacht und steuere den über eine App wo ich dann die Daten auswerten, grafisch ausgeben un auch speichern kann.
    • @Mitch64

      Mitch64 wrote:

      Hat's jetzt eigentlich geklappt mit dem HEX-File?
      wie ich in Post#39 beschieben hatte, hat es mit deiner ausführlichen Beschreibung prinzipiell schon funktioniert, jedoch scheint das no-name Modul nicht mitzuspielen. Das Modul ist zwar wieder erwacht, liefert aber nichts.

      Ich bin erst vor kurzem auf den Flow CSV Viewer gestoßen, ich finde ihn perekt für solche schnellen grafischen Darstellungen, zumal wenn man bei Excel kein Spezialist ist. Vielleicht kannst du mal so eine entsprechende Excel-Vorlage zeigen, wie sowas aussieht? Wie es ausehen könnte kann man im Flow CSV Viewer mit seinen vielfältigen Zoom-Möglichkeiten sehen.


      Mitch64 wrote:

      Mir ist der Syntax für die Steuerung der Log-Module schon zu umständlich.
      Da kann ich dir nur beipflichten,besonders wenn man wie ich diese no-name Produkte austesten wollte, die nicht mal das liefern was beschrieben steht, da bekommt man schon die Krätze. Und besonders dann noch, wenn man mehr als nur einfach aufzeichnen möchte. Hat ein wenig reinfuchsen gedauert, aber nun funktioniert es ja. Dank auch an Zitronenfalter.

      Wichtig, wenn man nur ein einziges file nach einem Powerup benötigt, dann hat man mit der Syntax absolut nicht zu tun. Modul einschalten und per TX , z.B. tagelang senden, fertig.

      Nichts für ungut, Mitch, wie du schon sagtest, jeder muss selber wissen, welche Variante für einen das Beste ist.

      Dennoch vielen Dank für deine Unterstützung.

      Gruß
      Ulrich
    • Zitronenfalter wrote:

      Also ich habe das z.B. letztens dazu verwendet um Messdaten eines Impulsschreibers abspeichern zu können. Der registriert Impulsfolgen die innerhalb von Sekunden ankommen (eine Art Wahlimpulsfolge mit allfälligen Kontaktprellungen die wiederum zu Störungen kommen könnte).
      Wer ist der? Der Logger bekommt doch seriell nur Daten? Der Controller erfasst die Pulse mit Prellen?

      Zitronenfalter wrote:

      und habe gar nicht erst überlegt ob ich da irgend einen I2C-Speicher vorsehe.Wie man sieht gibt es durchaus Anwendungen die Sinn machen.
      Tolle Begründung.
      Aber ich will niemanden etwas absprechen.

      Ich kenne ja nicht die Anwendungen.

      Von daher muss man selber wissen, welche Variante man anwendet.

      Mir wäre jedenfalls ein extra Modul, nur um zu Loggen, als Letzte Alternative eingefallen.

      Ulrich wrote:

      wie ich in Post#39 beschieben hatte, hat es mit deiner ausführlichen Beschreibung prinzipiell schon funktioniert, jedoch scheint das no-name Modul nicht mitzuspielen. Das Modul ist zwar wieder erwacht, liefert aber nichts.
      Ja ich habe den Post gelesen.
      Ich habe mich aber gefragt, ob das denn fehlerfrei in den Controller (mit Verify) übertragen wurde.
      Hast nichts erwähnt, daher tabbe ich da im dunkeln.

      Wenn du über die ISP-Schnittstelle arbeitest, was bei dem Hex-Brennen Voraussetzung ist, sollte das eigentlich funktionieren.
      Ist da evtl noch ein Bootloader im Logger-Modul integriert?

      Kannst du denn die Fusebits am Logger auslesen?
    • @Mitch64

      Mitch64 wrote:

      Kannst du denn die Fusebits am Logger auslesen?
      Ist meine Annahme richtig, dass wenn per write Buffer into chip das verify im selben Menue den Inhalt des Chips mit dem Inhalt des Buffers vergleicht?
      Wenn das der Fall ist, sehe ich immer einen Vergleichsfehler.

      Mit dem in Post#37 erwähnten Diamex Prommer lassen sich die Fusebits einwandfrei auslesen und auch modifizieren.

      Dennoch mögen die no-names das OpenLog_V43.hex umsetzen. OpenLog_V43.hex gibt es auch mit Bootloader, habe ich auch schon probiert, Ergebnis unverändert schlecht.

      Ich habe mir soeben weitere Sparkfuns bestellt. Mal sehen ob sie denn alle funktionieren.



      Zu deinem Einwand mit dem extra Modul: ja wie denn sonst, für die SD-Card benötigt man immer ein extra Modul, und ein OpenLog Modul kann viel Arbeit einsparen, oder wie ist dieser Einwand zu verstehen?

      Mitch64 wrote:

      Mir wäre jedenfalls ein extra Modul, nur um zu Loggen, als Letzte Alternative eingefallen
      Liebe Grüße
      Ulrich

      The post was edited 2 times, last by Ulrich ().

    • Mitch64 wrote:

      Ich kenne ja nicht die Anwendungen.
      Die Anwendung ist im Prinzip ein Wachsstreifenschreiber nur in elektronisch (im Prinzip ein Mega1284p mit Display).
      Solange der Prüfling innerhalb seiner Toleranzen arbeitet ist es für das Ergebnis und die Fehlereingrenzung unerheblich wie viele Millisekunden da was abweicht.
      Da wird als Ergebnis im Prinzip dann nur am Display OK und die errechneten Ergebnisse ausgegeben.
      Sind das aber Impulsfolgen (die jetzt von einer Wahlscheibe oder aber auch von Wallboxen (Fernsteuerungen von Jukeboxen) kommen stellt man das nicht mehr so einfach auf einen Display dar sondern speichert erstmal die erhobenen Daten irgendwo zwischen um die anderswo aus- und verwerten kann. Das kam eben erst durch die Anwendung selbst heraus weil man immer neue oder vielleicht sogar bessere Ideen hat. Das in der Folge sogar dann eine Android-App herauskam die dann das Gerät (über die serielle Schnittstelle) fernsteuerte (weil die Messung selbst eben nicht trivial ist wenn man die exakte Impulsfolge mitschreiben möchte) und die so erhobenen Messdaten dann grafisch aufbereiten konnte war ja nur Beiwerk und machte das OpenLog dann sogar überflüssig weil die App alle Möglichkeiten in Android bietet.
      Das ganze habe ich eigentlich nur deswegen entwickelt, weil ich in einer anderen Anwendung (MP3-Jukebox mit Wallboxen) genauere Informationen brauchte um das Impulstelegramm welches jeder Hersteller wiederum anders liefert, korrekt auswerten konnte. Weil aber eine Wallbox gleichzeitig fehlerhaft arbeitete machte dann erst genauere Messmethoden notwendig.
      Meine mir zur Verfügung stehenden Speicher-Oszi können aber auch nicht sekundenlang (so ein Impulstelegramm läuft mehrere Sekunden weil Übertragungszeit bei Jukeboxen kein wichtiger Faktor war) speichern und nur für diese Anwendung investiere ich dann auch nicht in ein teures Oszi.
    • Also, wenn sich die Fusebits auslesen/ändert lassen und nach dem Brennen der HEX ein Verify auch ok ist, dann war auch die Übertragung in Ordnung.
      Man kann dann davon ausgehen, dass die HEX 1:1 und korrekt übertragen wurde.

      Wenn dann das Modul trotzdem nicht funktioniert, muss ich @Zitronenfalter zustimmen,
      dann passt wohl die Firmware nicht zu dem Modul.
      Hardware-Abweichungen waren ja schon angesprochen.


      Ulrich wrote:

      Ist meine Annahme richtig, dass wenn per write Buffer into chip das verify im selben Menue den Inhalt des Chips mit dem Inhalt des Buffers vergleicht?
      Wenn das der Fall ist, sehe ich immer einen Vergleichsfehler.
      Ein Verify vergleicht den Buffer mit dem Inhalt des Chip.
      Wird ein Verify-Fehler ausgegeben, hat was beim Proggen nicht geklappt.

      Verify muss man in dem Fall, weil fremdes Hex-File geladen wurde, direkt nach dem Flashen durchführen. Das Fenster (Manuell Programmieren) darf zwischendurch nicht geschlossen werden. Denn sonst ist im Buffer wieder das Compilierte Testprogramm und nicht das Hex-File.

      Ist da vielleicht ein Lockbit oder sowas gesetzt?
      An welcher Adresse meldet das Verify einen Unterschied?
    • 00002 ist ganz vorn. Sicher das überhaupt etwas geschrieben wurde? Das 'Erase Chip' nicht vergessen?
      Wie sehen die Fuses aus?
      Hier kommen die falschesten schon bis 00016, ein identisches, nur andere Version-Nr bis 0121E
      Läßt er sich auslesen? Dann könnten die Hex(bin) verglichen werden. Das Bascom Verify gibt beim ersten Fehler auf.

      PS Das ganze geht auch ohne "Dummy Code" . Einfach auf Neu und die Warnmelungen weg klicken. Dann erfragt er selbst den Chip und brennt was auch immer im Buffer ist. Ein weiterer Vorteil. In der Hex Ansicht stehen nur FF . So ist es sofort ersichtlich ob er was lesen konnte.
      PPS Immer zuerst auslesen und sichern. Falls der Chip so gar nicht passt kann er dann wieder im Orginal Zustand versetzt werden.

      The post was edited 1 time, last by Pluto25 ().

    • Genau,
      Pluto hat es richtig erkannt.
      An Adresse 2 tritt schon die Differenz auf.
      Kannst kannst ja mal die ersten 6 Byte aufschreiben und vergleichen mit den ersten 6 Byte aus der zu flashenden HEX.

      Offensichtlich lässt sich der Chip nicht beschreiben, oder die Übertragung ist fehlerhaft.
      Ersteres könnte auf ein Fuse/Lockbit hindeuten, was das Schreiben verhindert.

      Lies doch mal die Fuses aus von dem Modul und poste den Screenshot.
      Vielleicht sieht man dann schon die Ursache.

      Noch ein Tip:
      Schalte in der Programmer-Einstellung das Verify nach dem Flashen an. Dann bemerkst du auch, wenn das Programm nicht korrekt im Chip abgelegt wird.
    • Hallo Pluto, Hallo Mitch

      von euch kann ich noch sehr viel über Bascom dazu lernen.

      Anbei die Fusebit-Tabelle die ich auslesen konnte, sowie der Buffer-Inhalt nach Load File into Buffer.

      Load into Buffer hat ausschließlich nur mit der Vorgehensweise nach Mitch's Anweisungen funktioniert.

      Beim Chip/write Buffer into chip sehe ich, dass der grüne Fortschrittsbalken (Quadrate) so wie bei einer normalen und erfolgreichen Programmierung zu sehen ist.

      Ich hoffe, diese beiden Dateianhänge unten können bei der Interpretation hilfreich sein.

      Viele Grüße

      Ulrich
      Files
      • Fusebits.JPG

        (206.14 kB, downloaded 11 times, last: )
      • Buffer2.JPG

        (294.21 kB, downloaded 10 times, last: )

      The post was edited 1 time, last by Ulrich ().

    • Der Buffer vom Verify und Buffer 2 ist identisch in den ersten 10 Bytes.
      Im nachhinein auch klar, denn der Buffer, was man im Fenster sieht, wird ja beim Verify nicht geändert.

      Ich hatte da einen Denkfehler.

      Gehe nochmal in das manuelle Programmierfenster und dade das zu flashende Hex. Und dann im Menü auswählen Flash in den Buffer einlesen.
      Dann wird der Buffer überschrieben. Dann bitte nochmal ein Screenshot einstellen.

      Ich vermute, dann wird sich der Unterschied in den ersten 10 Bytes finden.

      Die Fuses sind so eingestellt, dass es keine Einschrenkungen bezüglich Flash auslesen oder schreiben gibt.

      Wenn sich also beim auslesen des Flash in den Buffer eine Änderung zeigt,
      stimmt etwas beim Flashen nicht. Vielleicht zu lange Kabel, zu hoher Takt oder etwas ähnliches.
      D.h. die Daten kommen beim Schreiben wohl nicht korrekt am chip an. Könnte aber auch beim Lesen passieren.

      Kannst du die Einstellungen von deinem Programmer auch mal als Screenshot einstellen?

      Also Programmereinstellung und der Buffer nach dem Auslesen des Flash?
    • Hallo Mitch,

      das werde ich morgen noch mal checken und berichten.

      Daran habe ich noch nicht gedacht, dass eventuell die Prommer geschwindigkeit zu hoch sein könnte. Werde diese mal auf Standard herab setzen.

      Die Kabel sind, wie beim Prommer mitgeliefert, ca. 20cm lang.

      Mitch64 wrote:

      Vielleicht zu lange Kabel, zu hoher Takt oder etwas ähnliches.
      D.h. die Daten kommen beim Schreiben wohl nicht korrekt am chip an. Könnte aber auch beim Lesen passieren.


      Gruß
      Ulrich
      Files

      The post was edited 2 times, last by Ulrich ().

    • Mitch64 wrote:

      denn der Buffer, was man im Fenster sieht, wird ja beim Verify nicht geändert.
      Wohl manchmal auch nicht genutzt ?(
      Ich hab hier einen seltsamen Effect
      Zwischenablage02.gif
      Die 221.bin ist der vorher gesicherte Flashinhalt, also präzise das was beim Buffer read rauskommt.
      Dennoch Fehler sofort (00000) . Nach neu einlesen von der Festplatte dann das richtige Verfied OK.
      @Ulrich vielleicht ist doch richtig gebrannt worden? Lies mal das Hex neu von der Festplatte vor dem Verify
      PS Brennen geht nicht wenn der Chip rot erkannt wird. Vorsicht Fuses ändern geht trotzdem.
      Das Hex enthält einen Bootloader? Das rote Modul arbeitet richtig? Dann mal dessen Hex auslesen und mit dem des grünen vergleichen oder/und mit dem Neuen.
    • @Pluto25

      Pluto25 wrote:

      Das rote Modul arbeitet richtig? Dann mal dessen Hex auslesen und mit dem des grünen vergleichen oder/und mit dem Neuen.
      Ja, das rote arbeitet richtig. Mit dem Auslesen warte ich noch bis ich weitere rote (Sparkfuns's) habe. Denn ich muss ja, wie bei dem grünen Modul, an den 328-Pins feine Drähte anlöten. a_48_7237538e
      Solange der rote noch funktioniert, kann ich mit ihm weitertesten.

      Viele Grüße
      Ulrich
    • Ulrich wrote:

      Hallo Mitch,

      das werde ich morgen noch mal checken und berichten.

      Schon gecheckt?
      Was kommt raus, wenn du das nicht funktionierende Modul ausliest? Screenshot Buffer-Anfang?

      Deine Programmer-Einstellung würde ich mal auf einen kleineren Takt herabsetzen. Z.B. 500kHz oder noch weniger (vlt. 200kHz).

      Beide Timeouts für Serial und USB hatten bei mir mit 100ms schon manchmal Probleme gemacht.
      Ich würde hier mal 1000ms einstellen, bis die Ursache gefunden ist.

      Ich kenne den Effekt aus früheren Zeiten, Flashen ging, und dann beim Verify Fehler.

      Ursache war, dass die Signale Mosi, Miso, SCK, Reset zu geringe Pegel hatten.
      Am besten lässt sich das beim Brennen mit dem Oszi kontrollieren. Die Pegel (Mosi, Miso, SCK, Reset) sollten unter 0,3V und über 90% von VCC des Controllers gehen.

      Manchmal sind die ISP-Pins beschaltet, was die Signale belastet oder verschleift. Da kann z.B. ein PullUp an der Leitung helfen (3k3 oder 4k7).
      Einmal hatte ich auch mit Reset-Leitung Probleme. Der PullUp war zu hochohmig und der Pegel erreichte nur ca. 3,5V anstatt 5V.

      Kannst also mal die Pegel oder die Beschaltung der ISP-Relevanten Pins prüfen.