Routinen zur Justierung der Waage im Hauptprogramm (Firmware)

Entwicklung / Development Firmwareschmiede / Firmware development
1

Ich persönlich fände den Einbau des Kalibrierungscodes in das Hauptprogramm cool, weil ich es in letzter Zeit bei ein paar anderen Sketches so gesehen habe: Sowohl bei dem von Nathan Seidle (OpenScale) als auch bei dem von relayr, glaube ich.

2

Ja die Funktion ist schick, macht aber nur Sinn, wenn sie durch ein externes Event getriggert wird (Knopfdruck oder so). Denn sonst müsste man immer die Bienen runterheben, weil mal der Akku getauscht wird, was kein_e Imker_in machen wollen würde.

3

Was dafür spricht:

  • wir haben den code quasi schon drinnen, die Abfrageroutinge der Wägezelle ist identisch im Justierungs-Sketch und im Prodkutivsketch bis auf den Parameter mit wie viel Werten der Median gebildet wird
  • ein sketch weniger und 1x Hochladen weniger

Was dagegen spricht:

  • eine Justierung ist sehr selten nötig, wenn das Volk mal draufsteht ist der Null-Punkt gesetzt, ggf. kann man am kg-Divider nach nachjustieren
  • entweder wir justieren “halbautomatisch” - alles muss ohne Userinteraktion, z.B. Die Eingabe des Testgewichts, zeitbasiert (!) stattfinden, dann sind wir unflexibel, oder wir brauchen eine Möglichkeit der Interaktion, sprich Schnittstelle. Wie soll das gehen? Extra dafür ein Display und Knöpfe? Oder Internetbasiert - viel Aufwand!? Per Serieller?! dann kann ich auch gleich einen eigenen Sketch dafür nehmen.
  • weiter “belastet” die ganze Interaktion zur Justierung unseren geringen Speicher.
  • wenn wir die ermittelten Werte power-fail-sicher speichern wollen, müssen sie ins EEPROM, Vorteil wäre sie überdauern auch eine neu installierte firmware, Nachteil: es wird intransparenter.
  • wenn die Zahlen fest im Hauptsketch stehen ist das transparent

Mein Vorschlag wäre die beiden Parameter zum Nullpunkt setzen und zur Definition von 1 kg als “remote”-Variable zu gestalten. Sprich, man kann sie per Server - wie das update-intervall oder anderes - ändern, aber auch auslesen. Wenn ich nun merke, dass 10560 nicht ganz 1 kg sind könnte ich remote das auf 10580 ändern, ggf. das updateintervall auf 1 Minute temporär festlegen und nun iterativ den Wert anpssen.

Das bring uns die Flexibilität nachträglich noch Anpassungen durchführen zu können. Kalibrierung im Hauptsketch dafür ist mir der Speicher zu wichtig.

P.S.: Wir justieren hier, Kalibrieren ist etwas anderes: http://blog.wika.de/know-how/kalibrieren-oder-justieren-wo-liegt-der-unterschied/ und Eichen sowieso.

4

Das halt ich generell für eine gute Idee. Das Programm könnte ja schauen, ob was im EEPROM liegt, wenn nicht greift die Justierungsfunktion, für die dann entsprechend auch die Werte im Sketch hinterlegt sind. Transparenz hätten wir damit auch wieder. Zusätzlich sollte sich das durch einen Knopf am Gerät erzeugen lassen. Da ich jedoch noch mindestens eine andere Anwendungen für einen IRQ durch einen externen Taster sehe (annotations), müssen wir schauen wieviele IRQ pins wir haben, bzw, wie die triggerroutine jeweils aussieht… mehrmaliges drücken und ob wir dann wiederum Feedback für den/die User_in brauchen.

Ja, das wäre schön… Dafür müssten wir aber erstmal an einem Rückkanal für alle beteiligten forschen; node, (transceiver), gateway, backend, frontend… Ist nen haufen Asche.
Das würde ich in dieser Art erst angreifen, wenn wir alle einen konsistenten Publisher ( Terkin ?) verwenden.

1 Like
5

Die QTouch® Technologie

Der neue ATmega128 ab Revision 2467W-05/11 kann sogenanntes “Capacitive touch sensing” über die QTouch® Technologie:

  • Capacitive touch buttons, sliders and wheels
  • QTouch and QMatrix acquisition
  • Up to 64 sense channels

Siehe auch http://www.atmel.com/images/doc2467.pdf.

Weitere Details I

Atmel offers the QTouch® library for embedding capacitive touch buttons, sliders and wheels
functionality into AVR microcontrollers. The patented charge-transfer signal acquisition offers
robust sensing and includes fully debounced reporting of touch keys and includes Adjacent Key
Suppression® (AKS™) technology for unambiguous detection of key events. The easy-to-use
QTouch Suite toolchain allows you to explore, develop and debug your own touch applications.

Weitere Details II

The Atmel QTouch Library provides a simple to use solution to realize touch sensitive interfaces
on most Atmel AVR microcontrollers. The QTouch Library includes support for the QTouch and
QMatrix acquisition methods.

Touch sensing can be added to any application by linking the appropriate Atmel QTouch Library
for the AVR Microcontroller. This is done by using a simple set of APIs to define the touch channels
and sensors, and then calling the touch sensing API’s to retrieve the channel information
and determine the touch sensor states.

The QTouch Library is FREE and downloadable from the Atmel website at the following location:
www.atmel.com/qtouchlibrary. For implementation details and other information, refer to the
Atmel QTouch Library User Guide - also available for download from the Atmel website.

Nachteile

Das ist natürlich eine proprietäre Technologie und daher vermutlich mit einem Espressif Chip oder anderen nicht einsetzbar, deswegen mangelt es an der Universalität. Was sagt @weef dazu?

6

Hier noch was zu QTouch: qtouch - sekt oder selters - Mikrocontroller.net für mich momentan zu viel Hokuspokus. [weil gestern Gründonnerstag war noch ein zusätzlicher Link: Hokuspokus – Wikipedia ]. Nur für die Justierungs-Routine finde ich den Aufwand - alleine für das Userinterface - viel zu hoch, wenn wir über Alarmfunktionen reden, die deaktiviert werden müssen, und zwar realtime, kann das wieder anders sein.

7

Ich denke auch, dass sich das mit einem Magnetsensor und einer LED, oder Ton oder Vibration locker regeln ließe.