Atom Poor: Atom Fast App (Bluetooth) mit anderem Geigerzähler benutzen

[DG0MG]

Kleiner Versuch aus Interesse:

Im Quellcode der ProtonBridge.c steht der Name "AtomFast":

Code Auswählen Erweitern

  // complete name
  0x0A,   // length of this data
  GAP_ADTYPE_LOCAL_NAME_COMPLETE,
  0x41, // A
  0x74, // t
  0x6f, // o
  0x6d, // m
  0x46, // F
  0x61, // a
  0x73, // s
  0x74, // t
  0x20,

Diesen habe ich mal testweise zu "AtomPoor" geändert und neu compiliert.
Leider verbindet dann die App nicht mehr zum BLE-Device und meint, das sei ein unbekanntes Gerät.  Das geht also nicht.

[Henri]

Das ist dann wahrscheinlich die "Authentifizierung"

[DG0MG]

Für einen Batteriebetrieb ist es ja wichtig, den Akkustand zu kennen. Eine diesbezügliche Anzeige existiert in der App auch und man kann das auch vom Arduino aus steuern. Dazu muss der Arduino die Betriebsspannung erstmal messen. Der Gedanken, die Batterie einfach direkt auf einen Analogeingang zu legen, ist zu kurz gedacht. Der ATMEGA328P hat an den Eingängen interne Klemmdioden, die Überspannungen ableiten sollen. Liegt die zu messende Spannung aber noch am Analogeingang an und fehlt die Betriebsspannung, dann saugt das den Akku leer. Ich habe also von der Batterie zum Eingang einen 1MOhm-Widerstand eingefügt und am Analogeingang einen 2,2µF-Tantal-Elko nach GND, der kurzzeitig den Strom zum Messen liefert.

Der betreffende zusätzliche Softwareteil sieht so aus:

Code Auswählen Erweitern


#define PIN_VBATT A0
#define REF_VOLTAGE    5.15
#define PIN_STEPS   1024.0

void setup() {
pinMode(PIN_VBATT,INPUT);                 // Batteriespannung
}

void loop() {
    BluetoothPutRAD(measureBattVoltage());
    BluetoothPutBattPercent(measureBattVoltage());
}


void BluetoothPutBattPercent (float battmV) {
  int value;
  byte * p = (byte *) & value;           // e ist ein Pointer auf ein Array von Bytes
  value = (int)((battmV - 2.5) * 59) ;     // 2.5 V sind "leer"
  if(value>100)value=100;
  if(value<0)value=0;
  Serial.write(0xA0);                    // SCHREIBEN!
  Serial.write(0x04);                    // 0x04: Batterieprozentsatz (0..100),%           
  Serial.write(p,1);                     // Serial.write(buf, len)

}


float measureBattVoltage () {
  return analogRead(PIN_VBATT)*REF_VOLTAGE/PIN_STEPS;
}


Die Analogmessung an Pin A0 funktioniert dabei mit der Betriebsspannung (5,15 V) als Referenz. Das ist nicht optimal, aber es muss ja auch keine Hochpräzisionsmessung sein. Der A/D-Wandler liefert Werte von 0 .. 1023, wobei 1023 der Betriebsspannung entsprechen. Dabei wird angenommen, dass bei 2,5 V (das ist wirklich tief) der LiIon-Akku leer ist. 4.20 V sind dann 100%. Der Prozentsatz wird von 0 .. 100 begrenzt und in das entsprechende Register geschrieben (0xA0, 0x04, 0x..). Zum Debuggen kann man sich auch gleich mal die Spannung in Volt als Dosisleistung in µSv/h anzeigen lassen

In der App kann man das grafische Akkufüllstandssymbol durch drauftippen auf die Anzeige des Prozentsatzes umschalten.

[DG0MG]

Mir ist dabei aufgefallen, dass die Anzeige in "CPM" in der App anscheinend auf dem Smartphone generiert und direkt aus der übermittelten Dosisleistung berechnet wird!
Denn der Wert wird immer so angezeigt, als würde der Detektor ca. 5 cps bei natürlichem Hintergrund liefern.
Vielleicht erkennt er an der Bluetooth-Kennung, um was für ein Gerät es sich handelt, und bedient sich dann fest konfigurierter Kalibrierfaktoren?

Egal was man bei cps2 übermittelt, es hat keinen Einfluss auf die CPM-Anzeige.

Das hab ich auch mal untersucht. Zuerst mal nur im SEARCH-Fenster. Die Dosisleistung wird so wie gesendet angezeigt, ist klar.
Der cps2-Wert repräsentiert ja die Ticks in 2 Sekunden. Er wird durch 2 geteilt angezeigt, wenn man die ANzeige auf cps stellt.
Er ist also unabhängig von der übermittelten Dosisleistung. Für das Foto habe ich FEST einen Wert von 200 übermittelt, der dann richtigerweise (counts pro SEKUNDE) als 100 angezeigt wird.
Nun könnte man ja denken, dass die cpm durch Multiplikation mit 30 errechnet werden, das ist aber nicht so. Die cpm ändern sich, obwohl die cps "fest" bleiben, wie Du schon festgestellt hast. Woher er jetzt den Wert nimmt, weiß ich nicht genau. Eine Änderung des Kalibrierwertes, wie weiter oben vorgeschlagen, ändert jedenfalls nichts.

[Henri]

Für einen Batteriebetrieb ist es ja wichtig, den Akkustand zu kennen. Eine diesbezügliche Anzeige existiert in der App auch und man kann das auch vom Arduino aus steuern. Dazu muss der Arduino die Betriebsspannung erstmal messen. Der Gedanken, die Batterie einfach direkt auf einen Analogeingang zu legen, ist zu kurz gedacht. Der ATMEGA328P hat an den Eingängen interne Klemmdioden, die Überspannungen ableiten sollen. Liegt die zu messende Spannung aber noch am Analogeingang an und fehlt die Betriebsspannung, dann saugt das den Akku leer. Ich habe also von der Batterie zum Eingang einen 1MOhm-Widerstand eingefügt und am Analogeingang einen 2,2µF-Tantal-Elko nach GND, der kurzzeitig den Strom zum Messen liefert.

Hallo,

also das mit der Betriebsspannung messen hängt ein wenig davon ab, ob der Arduino direkt an der Spannungsquelle hängt oder ob noch ein Spannungsregler dazwischen ist. Wenn er nämlich direkt an der Spannungsquelle ist (und auch nicht über den RAW-Eingang, also den eingebauten Spannungsregler), kann man die anliegende Betriebsspannung intern umleiten und direkt messen, ohne dass es einen Analogeingang bräuchte. Entsprechend entfällt dann auch die Notwendigkeit, für einen Backpowering-Schutz zu sorgen. Mit einer einzelnen Li-Ion Zelle läuft der Prozessor immer noch mit 8 MHz.

Ich mache das in so einem Fall bislang so (atmega328):

Code Auswählen Erweitern


void setup(){
ADMUX |= (1<<REFS0);                          // VCC als Referenzspannung für den AD-Wandler
ADMUX |= (1<<MUX3) | (1<<MUX2) | (1<<MUX1);   // 1.1V Referenzspannung als Eingang für ADC 
delay(10);                                    // warten bis sich die Referenzspannung eingestellt hat
ADCSRA |= (1<<ADEN);                          // ADC aktivieren
}

void loop(){
  ADCSRA |= (1<<ADSC);  //Messung starten

  while (bitRead(ADCSRA, ADSC));  //warten bis Messung beendet ist
  //Ergebnisse des ADC zwischenspeichern. Wichtig: zuerst ADCL auslesen, dann ADCH
  adc_low = ADCL;
  adc_high = ADCH;

  adc_result = (adc_high<<8) | adc_low; //Gesamtergebniss der ADC-Messung
  vcc = (1125300L / adc_result)/1000;  //Versorgungsspannung in V berechnen (1100mV * 1023 = 1125300)
}


Wenn es genau werden soll, kann man noch ein Kalibrierfaktor für die interne Spannungsreferenz bestimmen, weil der Bandgap ja eine ziemlich große Bauteilstreuung aufweist. Außerdem nehme ich meist 5-10 Werte direkt hintereinander auf und mittele dann, weil die ersten 1, 2 gemessenen Werte meist etwas daneben liegen. Danach wird es besser. Bzw. ich schmeiße die ersten 3 Werte weg und mittele dann über den Rest.


Wenn noch ein Spannungsregler dazwischen sitzt, muss tatsächlich ein AI verwendet werden. Als Schutz gegen Backpowering nehme ich einen Transistor (oder FET), der die Verbindung vom AI-Pin zur Batterie schaltet und dessen Basis vom Betriebsstrom angesteuert wird. Alternativ könnte man die Basis auch über den Sketch per DO schalten, wodurch sich etwas Strom sparen lässt. Es reicht ja, jede Minute mal kurz zu messen.

Schwierig wird es bei galvanischer Trennung von Batterie und Ausgang des Reglers. Bei manchen Reglern darf man ja die Massen nicht einfach zusammenschalten. Der AD-Wandler ist aber auf eine gemeinsame Bezugsmasse angewiesen. Da habe ich bislang noch keine kompakte und kostengünstige Lösung für gefunden.

Viele Grüße!

Henri

[Henri]

Mir ist dabei aufgefallen, dass die Anzeige in "CPM" in der App anscheinend auf dem Smartphone generiert und direkt aus der übermittelten Dosisleistung berechnet wird!
Denn der Wert wird immer so angezeigt, als würde der Detektor ca. 5 cps bei natürlichem Hintergrund liefern.
Vielleicht erkennt er an der Bluetooth-Kennung, um was für ein Gerät es sich handelt, und bedient sich dann fest konfigurierter Kalibrierfaktoren?

Egal was man bei cps2 übermittelt, es hat keinen Einfluss auf die CPM-Anzeige.

Das hab ich auch mal untersucht. Zuerst mal nur im SEARCH-Fenster. Die Dosisleistung wird so wie gesendet angezeigt, ist klar.
Der cps2-Wert repräsentiert ja die Ticks in 2 Sekunden. Er wird durch 2 geteilt angezeigt, wenn man die ANzeige auf cps stellt.
Er ist also unabhängig von der übermittelten Dosisleistung. Für das Foto habe ich FEST einen Wert von 200 übermittelt, der dann richtigerweise (counts pro SEKUNDE) als 100 angezeigt wird.
Nun könnte man ja denken, dass die cpm durch Multiplikation mit 30 errechnet werden, das ist aber nicht so. Die cpm ändern sich, obwohl die cps "fest" bleiben, wie Du schon festgestellt hast. Woher er jetzt den Wert nimmt, weiß ich nicht genau. Eine Änderung des Kalibrierwertes, wie weiter oben vorgeschlagen, ändert jedenfalls nichts.

Ah, dann hast Du mal etwas genauer hingeschaut als ich. cpm bin ich gar nicht so "gewohnt" und habe die noch gar nicht genutzt.

Auf jeden Fall etwas sonderbar - auch, dass die Werte von 2 Sekunden verwendet werden. Dabei sind die Zählraten ja eh so niedrig, dass man bei niedrigen Dosisleistungen irgendwo mit einem gleitenden Mittelwert arbeiten muss. Sonst springt die Anzeige zu sehr. Aber ob der auf dem AtomFast oder in der App generiert wird? Ich habe den Eindruck, auf dem AtomFast, da bei meiner Geiger-Müller-Version mit knapp 1 cps ziemlich wilde Sachen rauskommen, wenn man die ungemittelten 2-s-Werte schickt. Also macht mein Arduino den Mittelwert und schickt den dann an die App. Ich find's auch sonderbar, dass Dosisleistung und Zählrate getrennt voneinander übertragen werden UND es dann auch noch einen Kalibrierfaktor gibt. Da kann es doch schnell sein, dass das nicht mehr zusammenpasst. Meine Hypothese ist, dass die Dosisleistung gemittelt wird und die Zählrate "roh" kommt, damit das Gerät im "search" Modus schneller anspricht. Na ja, die haben sich auf jeden Fall was bei gedacht. Da müssen wir nur hinterkommen.

Viele Grüße!

Henri

[DG0MG]

Ja, da hast Du recht.
Etwas durcheinander ist das alles schon. Die cps werden direkt angezeigt, die cpm werden mMn aus den µSv/h zurückgerechnet. Ich weiß inzwischen auch wie:

"SypH3er" hat im Quellcode der Protonbridge die Variable des Kalibrationsfaktors (über 0x60 zu erreichen) mit dem Faktor für ein "AtomFast 7735" vorbelegt. Der beträgt 1700 Imp/µR. Für ein SBM-20 beträgt er 78 Imp/µR.

Im Atom Fast (und auch im "Atom Poor") findet nun folgende Rechnung statt:

DL[µSv/h] = 0,01 * Imp2sek / K[Imp/µR] * 1800

In Worten:
Die Dosisleistung in µSv/h ergibt sich aus 0,01 mal (Umrechnung µR/h nach µSv/h) die Impulse der letzten 2 Sekunden (falls man denn so misst) geteilt durch den Kalibrierfaktor K (bis hierher haben wir die Dosis in 2 Sekunden) mal 1800 (damit wir auf die Dosis pro Stunde kommen). Falls man irgendwie mittelt, sieht die Rechnung natürlich etwas anders aus.

Diese DL wird an die App gesendet.

Die hat über Bluetooth Zugriff auf den Kalibrierfaktor und rechnet offenbar die cpm-Anzeige rückwärts aus den µSv/h aus:

obige Formel umgestellt nach den Impulsen in 2 Sekunden:

Imp2sek = DL[µSv/h] * K[Imp/µR] / (0,01 * 1800)

Wenn wir die Impulse pro Minute wollen, multiplizieren wir noch mit 30 (1 min = 2sek*30) und dann kürzen sich die Faktoren raus:

Ipm = DL[µSv/h] * K[Imp/µR] / 0,6

Diese Verfahrensweise finde ich etwas "strange", aber nagut. Der cpm-Wert ist demzufolge vom Glättungsalgorithmus im Messkopf betroffen, der cps-Wert nicht.

Es scheint also für den Arduino-Code "good practice" zu sein, den eigenen Kalibrierfaktor gleich in Imp/µR zu definieren und den dann sowohl in den eigenen Rechnungen für die Dosisleistung zu verwenden und auch über "0x60" an die Protonbridge zu senden und damit die vorbelegten 1700 imp/µR zu überschreiben, damit die App darauf zugreifen kann.

[DG0MG]

Eine ganze Weile habe ich mich mit dem MEASURE-Mode beschäftigt. Der ist nicht so pflegeleicht, wie der SEARCH-Mode, es hat einige Versuche gebraucht, bis MEASURE realistische Daten angezeigt hat.

Dazu muss man erstmal wissen, wie die Anzeige zustandekommt. Nun sie soll ja genauer sein (4 Nachkommastellen!)als bei SEARCH, also muss die Messzeit länger sein. Es werden vom Atom Fast/Poor die Impulse in 2 Sekunden übermittelt, ebenso gibt es einen Gesamt-Impulscounter mit 8 Byte Länge sowie noch einige andere Variablen, die irgendetwas mit Impulsen und Zeit zu tun haben. Und natürlich der Kalibrierfaktor. Nun wäre es doch naheliegend, beim Tippen auf "START MEASUREMENT" den Gesamtimpulscounter auszulesen, sich diesen Wert zu merken und die ab da zunehmenden Impulse mit dem Kalbrierfaktor zu verrechnen. Alternativ die übermittelte 2-Sekunden-Impulszahl aufsummieren und verrechnen. Aber egal, was ich wie in die Impulsregister geschrieben habe, es kam nichts Gescheites dabei heraus. Es war also erstmal zu klären, was muss man genau senden, dass das hinhaut.

SypH3r hat ja ein Windows-Programm geschrieben ("ProtonBridgeTestApp.exe", siehe rhbz.org-Link weiter oben), das realistische Daten produziert, die man an die ProtonBridge senden kann (anstelle des Arduino) und dann in der App angezeigt werden. Mit diesem Programm kommen brauchbare Werte im MEASURE-Mode, also konnte es kein Fehler im ProtonBridge-Code sein. Also mit einem Terminalprogramm mal geschaut, was denn das Windows-Programm so sendet:

A0 00 00 A0 01 7E 3C BC 40 A0 02 66 66 E6 3F A0 03 AA 00 A0 04 41 A0 05 17 A0 60 00 80 D4 44
A0 00 00 A0 01 7F 3C BC 40 A0 02 79 B0 E3 3F A0 03 A8 00 A0 04 41 A0 05 17 A0 60 00 80 D4 44
A0 00 00 A0 01 80 3C BC 40 A0 02 66 66 E6 3F A0 03 AA 00 A0 04 41 A0 05 17 A0 60 00 80 D4 44
A0 00 00 A0 01 81 3C BC 40 A0 02 79 B0 E3 3F A0 03 A8 00 A0 04 41 A0 05 17 A0 60 00 80 D4 44
A0 00 00 A0 01 82 3C BC 40 A0 02 66 66 E6 3F A0 03 AA 00 A0 04 41 A0 05 17 A0 60 00 80 D4 44
A0 00 00 A0 01 83 3C BC 40 A0 02 79 B0 E3 3F A0 03 A8 00 A0 04 41 A0 05 17 A0 60 00 80 D4 44

A0 00 00             Flags
A0 01 7D 3C BC 40    Dosis in mSv
A0 02 79 B0 E3 3F    Dosisleistung in µSv/h
A0 03 A8 00          Anzahl der Impulse in den letzten 2 Sekunden
A0 04 41             Batterieprozentsatz
A0 05 17             Temperatur
A0 60 00 80 D4 44    Kalbrierfaktor in Imp/µR

Ahaa, es werden ausser den Impulsen in 2 Sekunden gar keine weiteren Impulsvariablen übermittelt!?
Aber warum gehts dann?

Weil in der App zum Errechnen der DosisLEISTUNG die übermittelte DOSIS herangezogen wird!
Aus der Erhöhung der Dosis seit Start der Messung wird rückwärts über den Kalibrierfaktor die Dosisleistung ausgerechnet. Ebenso die hier auch angezeigten cps- und cpm-Werte. Das ist schon sehr ungewöhnlich, weil man eigentlich mehrere Fließkommarechnungen nacheinander vermeidet - nicht nur, dass die langsam sind - durch Rundungsfehler wird das Ergebnis immer ungenauer. Das ist wie früher beim Tonband: Je öfter man einen Titel "überspielt" umso schlechter ist die Kopie - mehrere Kopien hat man besser immer wieder vom gleichen Ursprungsband gezogen.

Um die Dosis hatte ich mich bisher in meinem Arduino-Sketch noch gar nicht gekümmert, deswegen ging das nicht.

Man führt also am besten im Arduino einen Gesamtimpulszähler vom Typ uint_64 der alle Impulse aufsummiert. Aus diesem lässt sich die Dosis mittels Multiplikation mit dem Kalibrierfaktor errechnen, die man übermittelt.

[Henri]

Das ist ja echt eine Detektivarbeit!!  Schon wirklich sonderbar, wie da wild hin- und hergerechnet wird. Vielleicht hängt das damit zusammen, dass verschiedene Geräte (AtomFast in mehreren Varianten; AtomSwift) mit ebenfalls verschiedenen Apps zusammenarbeiten sollen. Ist wahrscheinlich alles etwas mit der heißen Nadel gestrickt...

[DG0MG]

Hierzu muss man nochmal nachdenken, ob das vielleicht nicht sogar ein ernsthafteres Problem darstellen kann, auch für den originalen Atom Fast? Eine Float-Variable (über die die Dosis übermittelt wird) besteht aus 4 Byte, also 32 Bit (1 Bit Vorzeichen, 8 Bit Exponent und 23 Bit Mantisse. Float-Variablen haben eine Genauigkeit von 6-7 signifikanten Stellen.

Da die Dosis in mSv gespeichert wird sieht das für 7 Stellen bestenfalls so aus:

0,1234567 mSv
        ^
        |
        +--- Wertigkeit von 0,1 nSv

Man kann also die errechnete Dosis auf 0,1 nSv genau speichern. Für die Dosis selbst dürfte das mehr als ausreichend sein, für die weitere Berechnung der Dosisleistung braucht man es aber so genau wie möglich. Ist nun die bereits aufgelaufene Dosis > 1 mSv, so fällt rechts eine Stelle weg:

1,234567 mSv
       ^
       |
       +--- Wertigkeit von 1 nSv

Und bei >10 mSv:

12,34567 mSv
       ^
       |
       +--- Wertigkeit von 10 nSv

Könnte es also sein, dass die Genauigkeit von MEASURE umsomehr sinkt, je größer die bereits gespeicherte Dosis ist? Im dritten Beispiel hätten wir BESTENFALLS noch eine Genauigkeit von 10nSv, vielleicht auch eine Zehnerpotenz schlechter (100 nSv). Und ob man 0,2 oder 0,3 µSv/h "MISST", ist schon ein erheblicher Unterschied.

Hab ich einen Denkfehler drin?

[Henri]

Hab ich einen Denkfehler drin?

Also, ich würde erst mal sagen, nein? 

Allerdings kommt es im Alltag selten mal dazu, dass man ein mSv voll bekommt. In der Regel wird man ja die Dosis über einen Tag, oder vielleicht mal über eine Woche Tschernobly-"Urlaub", oder vielleicht 10 Stunden Flugreise bestimmen und sie danach zurücksetzen. Dann wirkt es sich noch nicht aus. Oder man hat es tatsächlich mal für ein paar Stunden mit höheren Ortsdosisleistungen zu tun, und dann spielt es keine Rolle, ob das 100 nSv/h mehr oder weniger sind. So genau wird das Gerät eh nicht kalibriert sein.

Aber grundsätzlich sieht das schon nach einem unschönen Designproblem aus. Die Entwicker freuen sich sicherlich über einen kleinen Bugreport   

Viele Grüße!

Henri

[DG0MG]

Es gibt in der App unter "Settings" noch den "1/10"-Schalter. Der bewirkt laut Beschreibung wohl, dass nicht JEDER, sondern nur JEDER ZEHNTE Tick akustisch ausgegeben wird. Für ein Szintillationsmessgerät, das viele Impulse liefert, ist das eine sinnvolle Sache.

Man kommt über die Variable 0x50 an diesen Schalter heran, er hängt aber irgendwie mit dem Auswahlfeld "Nosound/Clicks/Beeps" zusammen (siehe Antwort #40).

Auswahlfeld 1/10  0x50 0x51
---------------------------
nosound    OFF    08   00
clicks     OFF    01   01
beeps      OFF    01   14
beeps      ON     E1   01
clicks     ON     01   01
clicks     OFF    E1   00

Die letzte Stellung ist extrem unlogisch. Im BLE SERVICE-Dokument steht, dass das in 0x50 übermittelte Byte eine Art "Befehl" oder Kommando darstellt. "E1" fehlt aber, vermutlich, weil das Dokument zu Zeiten des "Atom simple" entstanden ist, also der Version nur mit einem SBM-20-Zählrohr. Da war ein Teiler für die Ticks noch gar nicht nötig. Man kann das Arduino-Programm aber so gestalten, dass es trotzdem unter den Gegebenheiten funktioniert.

[Henri]

Ich bin gerade wieder ein wenig am basteln und habe den thread mal für mich zusammengefasst, da er ja doch mittlerweile schon recht umfangreich ist:


SEARCH-Modus:

- Dosisleistung wird in der App angezeigt wie vom AtomFast/Arduino gesendet

- gesendeter cps2 Wert wird in der App halbiert und dann angezeigt. Man sendet z.B. cps2 = 200 und es wird in der App 100 cps angezeigt.

- Dosisleistung und cps-Anzeige sind in der App unabhängig voneinander

- CPM-Anzeige wird in der App NICHT aus den cps bzw. cps2 errechnet, sondern aus der Dosisleistung. In der Firmware des AT-09 Bluetooth Moduls ist der Kalibrierfaktor für einen ein AtomFast 7735 = 1700 Imp/µR fest hinterlegt. Dieser wird von der App ausgelesen und zur Berechnung der CPM aus der empfangenen Dosisleistung verwendet.


MEASURE-Modus:

- Dosisleistung wird von der App aus dem Anstieg der seit dem Start übermittelten DOSIS (!) zurückgerechnet



Das Datagramm besteht aus einem einleitenden HEX-Wert für entweder senden oder empfangen. Danach folgt ein HEX-Wert, der den übertragenen Parameter beschreibt. Daraufhin folgt der Wert des Parameters.

Also z.B.
A0 02 79 B0 E3 3F   // A0=Senden 02=Dosisleistung Rest=Dosisleistung_in_µSv/h

Code Auswählen Erweitern



0xA0    Zur App senden
0xB0    Von der App lesen


0x01:  // Dosis in mSv
0x02:  // Dosisleistung in µSv/h
0x03:  // Anzahl der Impulse in den letzten 2 Sekunden
0x04:  // Batterieprozentsatz (0..100),%
0x05:  // Temperatur   


Auswahlfeld 1/10  0x50 0x51
---------------------------
nosound    OFF    08   00
clicks     OFF    01   01
beeps      OFF    01   14
beeps      ON     E1   01
clicks     ON     01   01
clicks     OFF    E1   00


0x51: // 2 Byte uint, ==> Länge des Ticks in msec
0x53: // 2 Byte uint, ==> Länge der Schwingungsdauer in msec


0x60: // Sensorempfindlichkeit
0x61: // Hintergrundzählung des Sensors
0x62: // Sensortotzeit
0x63: // Zeitpunkt der Dosisleistungsmessung
0x64: // Passwort zum Schreiben der Kalibrierung in den RAM




Kleine erfreuliche Ergänzung noch:

Das AT-09 BT LE Modul ist für 3.3V Betriebsspannung spezifiziert, funktioniert aber bereits ab 1.8V. Das bedeutet, man kann es direkt an einen mit 1 MHz getakteten Arduino anschliessen und diesen  mit 2 NiMH-Akkus betreiben. Der Arduino kann dann auch seine eigene Betriebsspannung messen (s.o.) und diese an die App verfüttern 

[Henri]

Kleine erfreuliche Ergänzung noch:

Das AT-09 BT LE Modul ist für 3.3V Betriebsspannung spezifiziert, funktioniert aber bereits ab 1.8V. Das bedeutet, man kann es direkt an einen mit 1 MHz getakteten Arduino anschliessen und diesen  mit 2 NiMH-Akkus betreiben. Der Arduino kann dann auch seine eigene Betriebsspannung messen (s.o.) und diese an die App verfüttern 

Hmmm doch nicht so erfreulich. DG0MG, weißt Du zufällig, ob man die 115200 baudrate ändern kann? Die ist wahrscheinlich in der protonbridge vorgegeben, oder? Auch in der App? Mit 1 MHz bekommt man nämlich die 115200 nicht hin... Nicht mal als Hardware Serial. Da hatte ich gar nicht dran gedacht.

Ich wollte heute übrigens mein zweites AT-09 Modul flashen, aber es funktioniert nicht!    Es hat ein leicht unterschiedliches Layout zu dem Modul, bei dem ich Erfolg hatte, und ist identisch zu dem allerersten Modul, bei dem es bei  mir auch nicht geklappt hatte. Bei den "Nieten" sind auf einer Seite 3 Pins des Chips über eine Lötbrücke verbunden, bei dem wo es funktioniert hat fehlt die Brücke...

[DG0MG]

weißt Du zufällig, ob man die 115200 baudrate ändern kann? Die ist wahrscheinlich in der protonbridge vorgegeben, oder? Auch in der App? Mit 1 MHz bekommt man nämlich die 115200 nicht hin... Nicht mal als Hardware Serial. Da hatte ich gar nicht dran gedacht.

Ja, die Baudrate ist in der Protonbridge im Quelltext vorgegeben. Die App hat damit nichts zu tun. Das sollte man also ändern können. Die paar Bytes wird man soch auch in 9k6 übertragen können. Oder was anderes?

Ich wollte heute übrigens mein zweites AT-09 Modul flashen, aber es funktioniert nicht!    Es hat ein leicht unterschiedliches Layout zu dem Modul, bei dem ich Erfolg hatte, und ist identisch zu dem allerersten Modul, bei dem es bei  mir auch nicht geklappt hatte. Bei den "Nieten" sind auf einer Seite 3 Pins des Chips über eine Lötbrücke verbunden, bei dem wo es funktioniert hat fehlt die Brücke...

Aber ein CC2541 ist erstmal drauf? Hat denn die "Brücke" Verbindung zu einem der drei Programmierpins?