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

[Henri]

Ach, die sind ja super!!! 

Kannst Du den Quelltext mal in eine Text-Datei kopieren und dann hier hochladen? Vielleicht können wir das ja zusammen irgendwie enträtseln.

[DG0MG]

Syph3er schreibt, er habe nicht alle Funktionen getestet. Auch sein Windows-dotNET-Programm, das Testdaten erzeugt, funktioniert nur in der Richtung in den CC2541 HINEIN.

Eine Sache, nach der man jetzt im Quellcode mal schauen könnte, ist, ob denn die seriellen Daten überhaupt aus dem dokumentierten Anschluss des CC2541 herauskommen, oder ob das nicht einfach ein anderer ist. Laut dem Schaltplan ist "TxD" der Anschluss "P1_6". Das muss also irgendwo im Programmcode wiederzufinden sein, dass aus einem Bit6 Daten rauskommen.

Hier ist ein Quellcode-Schnipsel, um sogar ZWEI UARTs zu bedienen (uns reicht einer  ), da sieht man, wie das gemacht sein könnte:

https://sunmaysky.blogspot.com/2016/09/how-to-use-two-uart-ports-in-cc2530-z.html?m=1

[DG0MG]

Noch eine Idee: Es könnte sein, dass irgendeine Form von Hardware-Flußkontrolle (FLOW-CONTROL) in der eingebundenen Serial-Bibliothek eingeschalten ist - mglw. muss man also ein bestimmtes anderes Pin (CTS?) erst auf Low setzen, bevor die Daten heraussprudeln. Das erscheint mir fast noch naheliegender.

Das in Antwort #12 verlinkte Datenblatt enthält tatsächlich auch RTS/CTS-Beschriftungen neben Rx und Tx.

[DG0MG]

Kleiner Zwischenbericht:

Wenn ich die aus den Sourcen selbst compilierte Firmware reinflashe, kommen serielle Daten, mit der von SypH3r geposteten Protonbridge.bin kommen keine. Warum das so ist, weiß ich nicht. Ist aber auch egal. Es ist also der richtige UART-Anschluss, auch ein Flow-Control ist nicht schuld und es ist auch nichts kaputt. SypH3rs Protonbridge.bin ist um die 256 KB, die selbst übersetzte ist nur ca. 120 KB groß.

Die Daten, die kommen, sind leider leer. d.h. es stehen in den Variablen die Werte drin, die zu Programmbeginn initialisiert werden - sie ändern sich aber bei einer Änderung in der App nicht mit. Ich weiß auch warum, aber das ist die nächste Baustelle. Die "Rückwärts"-Funktion ist noch gar nicht implementiert gewesen. Es gibt erstmal ein neues Problem: Die Daten kommen immer doppelt! Ein Zwei-Byte-unsigned int kommt zwei mal nacheinander, ein testweise gesendeter String kommt auch zweimal nacheinander. Das klingt eigentlich wie ein einfacher Fehler: Irgendein Aufruf oder eine Schleife wird zweimal durchlaufen werden, bisher ist mir aber noch nichts aufgefallen.

Die Software für den CC2541 verwendet eine ziemlich umfangreiche Texas-Instruments-Entwicklungsbibliothek (https://www.ti.com/tool/BLE-STACK) für BLE, in der scheint aber nicht rumgeändert worden zu sein.

[DG0MG]

Die Daten kommen immer doppelt![..] wie ein einfacher Fehler: Irgendein Aufruf oder eine Schleife wird zweimal durchlaufen werden, bisher ist mir aber noch nichts aufgefallen.

Es ist auch ein einfacher Fehler - wenn man es weiß!  Eigentlich ist es gar kein Fehler.
Die Routine im CC2541, die eingehende serielle Daten verarbeitet, wird zyklisch(!) aufgerufen, alle 1000 ms. Wenn man also vom Arduino aus einen Lesebefehl gesendet hat, kann es im ungünstigsten Fall fast eine Sekunde dauern, bis Antwort kommt. Ich hatte vom Arduino im 500msec-Rhythmus den Lesebefehl gesendet, so dass die Routine, die alle 1000 msec ausgeführt wird immer schon zwei Befehle in ihrer Queue hatte und diese dann ASAP nacheinander abgearbeitet hat. Die Definition für den zyklischen Abstand ist in der protonBridge.c Zeile 47:

Code Auswählen Erweitern

// How often to perform periodic event
#define SBP_PERIODIC_EVT_PERIOD                   1000

das ändern wir vorsichtshalber mal auf 500 msec:

Code Auswählen Erweitern

// How often to perform periodic event
#define SBP_PERIODIC_EVT_PERIOD                   500


[Henri]

Da bist du ja schon ganz schön weitergekommen!

Es gibt eine gute Nachricht: meine neuen Module sind da   Und eine schlechte: ich bin dieses Wochenende anderweitig eingespannt und werde sie nicht testen können. Aber in der nächsten freien "Minute" gehe ich das mal an.

Außerdem hat mein Telefon Android 10. Da muss ich dann auch erst mal schauen, dass mir das keine Steine in den Weg legt...

Viele Grüße!

Henri

[DG0MG]

Damit Daten auch "rückwärts" aus dem Bluetooth-Profil gelesen und an den Arduino gesendet werden können, müssen bei einer Änderung im BT-Profil auch die zugehörigen "normalen" Variablen upgedatet werden. Der entsprechende Code ist schon da, nur verwendet er ANDERE Variablen, nicht die, die dann auch am UART gesendet werden.

In Zeile 1052 der protonBridge.c gibt diesen Code:

Code Auswählen Erweitern

static void protonProfileChangeCB( uint8 paramID )
{
  uint8 newValue1[10];
  uint8 newValue2[10];
  uint8 newValue3[10];
  uint8 newValue4[8];
  uint8 newValue5[18];
  uint8 newValue6[17];
  uint8 newValue7[20];

  switch( paramID )
  {
    case PROTONPROFILE_CHAR3:
      ProtonProfile_GetParameter( PROTONPROFILE_CHAR3, &newValue1 );
      break;

    case PROTONPROFILE_CHAR4:
      ProtonProfile_GetParameter( PROTONPROFILE_CHAR4, &newValue2 );
      break;     
     
    case PROTONPROFILE_CHAR5:
      ProtonProfile_GetParameter( PROTONPROFILE_CHAR5, &newValue3 );
      break;
     
    case PROTONPROFILE_CHAR6:
      ProtonProfile_GetParameter( PROTONPROFILE_CHAR6, &newValue4 );
      break;       
     
    case PROTONPROFILE_CHAR7:
      ProtonProfile_GetParameter( PROTONPROFILE_CHAR7, &newValue5 );
      break;       
     
    case PROTONPROFILE_CHAR8:
      ProtonProfile_GetParameter( PROTONPROFILE_CHAR8, &newValue6 );
      break;         
     
    case PROTONPROFILE_CHAR9:
      ProtonProfile_GetParameter( PROTONPROFILE_CHAR9, &newValue7 );
      break;         
     
    default:
      // should not reach here!
      break;
  }
}

Der wird geändert zu:

Code Auswählen Erweitern

static void protonProfileChangeCB( uint8 paramID )
{

  switch( paramID )
  {
    case PROTONPROFILE_CHAR3:
      ProtonProfile_GetParameter( PROTONPROFILE_CHAR3, &charValue3 );
      break;

    case PROTONPROFILE_CHAR4:
      ProtonProfile_GetParameter( PROTONPROFILE_CHAR4, &charValue4 );
      break;     
     
    case PROTONPROFILE_CHAR5:
      ProtonProfile_GetParameter( PROTONPROFILE_CHAR5, &charValue5 );
      break;
     
    case PROTONPROFILE_CHAR6:
      ProtonProfile_GetParameter( PROTONPROFILE_CHAR6, &charValue6 );
      break;       
     
    case PROTONPROFILE_CHAR7:
      ProtonProfile_GetParameter( PROTONPROFILE_CHAR7, &charValue7 );
      break;       
     
    case PROTONPROFILE_CHAR8:
      ProtonProfile_GetParameter( PROTONPROFILE_CHAR8, &charValue8 );
      break;         
     
    case PROTONPROFILE_CHAR9:
      ProtonProfile_GetParameter( PROTONPROFILE_CHAR9, &charValue9 );
      break;         
     
    default:
      // should not reach here!
      break;
  }
}

Danach spuckt der UART auf Anforderung auch Werte aus, die sich ändern, wenn man in der App was ändert.
Mein Ziel war ja eigentlich "nur", den Schalter "No Sound/Clicks/Beeps" übertragen zu bekommen. Ich sende also vom Arduino aus 0xB0 ("Lesen"), 0x51 ("Ticklänge") und bekomme eine 2-Byte-(integer)-Antwort zurück:

• "No sound" ==> 0
• "Clicks" ==> 1
• "Beeps" == 20

Im Anhang die aktuelle Version der Protonbridge.bin.

[Henri]

 

Tja, wie soll ich sagen... Ich konnte es nicht abwarten und habe umdisponiert 

Diesmal wollte ich beim Flashen der Module alles richtig machen. Also: schön einen Level Shifter an den Arduino Nano gepackt und außerdem noch eine gesonderte 3.3V Festspannungsquelle ans Modul angeschlossen, da angeblich der 3.3V Regler des Arduino zu wenig Strom liefert. Das Flashen erfolgt dann also mit 3.3V Betriebsspannung und 3.3V Signalpegeln.

Dann habe ich noch mal in der Schrottkiste gewühlt und mein uraltes Notebook mit Windows XP wieder ausgegraben. Läuft noch! 

Und dann, Firmware flashen mit CCLoader.exe:  nüscht. Startet nicht.

Alles 20x kontrolliert. Dann rüber zur Linux-Kiste. Auch nüscht.

Irgendwann bin ich dann mal wieder ungeduldig geworden und habe den Levelshifter rausgeschmissen: Betriebsspannung fürs Modul + Signalpegel 5V. Ist ja egal...

Und dann: hat es angefangen zu flashen!! Also, mit 5V flasht es, mit 3.3V nicht. Interessant!!!

Geflasht habe ich auf der Windowskiste. Es fällt auf, dass dort jedes geflashte Byte einzeln angezeigt wird. Auf der Linux-Kiste passiert immer sekundenlang gar nichts, und dann wird ein ganzer Schwung angezeigt. Vielleicht funktioniert das Linux-Flashprogramm nicht richtig. Ich will das aber nicht ausprobieren, damit ich mir nicht versehentlich noch das Modul wieder zerschieße.


Ich habe natürlich die alte Firmware geflasht, weil ich den letzten Post hier nicht gelesen hatte 

Aber: Nun klappt es, ich bekomme schön 0.14µSv/h auf der App angezeigt!

Tatsächlich lief es auf Android 10 aber nicht ohne Freigabe der "Location Based Services". Hat vielleicht was mit der Corona-App Schnittstelle zu tun?

Dann habe ich alles noch mal umgelötet und die korrigierte Firmware aufgespielt, die Kommunikation in beide Richtungen kann.
Die ist nur halb so groß wie die aus dem Forum. Ich meine, ich habe da mal gelesen, dass man immer auf 512 Byte auffüllen soll.
Bei mir läuft sie super (großes Dankeschön!),  aber vielleicht, weil ich zuerst die aus dem Forum mit 512 Byte aufgespielt hatte?
Wenn jemand ein frisches Modul gleich mit der kleineren Version bespielt und es dann Probleme geben sollte, könnte man hier vielleicht mal schauen. Oder vielleicht sind 256 byte einfach auch OK.

Jedenfalls bin ich sehr froh, dass es nun endlich läuft. Das BT-Modul, auf die Rückseite eines Arduino Pro Mini 3.3V geklebt, passt so ziemlich in jedes Gerätchen noch rein und kann es ans Smartphone anbinden.



Viele Grüße!

Henri

[DG0MG]

Prima, dass Du nun auch ein Erfolgserlebnis hast! Jetzt fehlt erstmal nur noch ein gescheites Stückel Code im Arduino.

Das mit dem Auffüllen hab ich auch gelesen, aber nicht verstanden. Die "IAR Embedded Workbench" (also der Compiler) produziert ein *.hex-File (Intel-Format), das mit einer srec_cat.exe zu einer *.bin konvertiert werden kann, die dann der CCLoader liest und flashen kann. Ich hab das immer ohne irgendwelches "auffüllen" geflasht und kein Problem damit festgestellt.

[Henri]

Prima, dass Du nun auch ein Erfolgserlebnis hast! Jetzt fehlt erstmal nur noch ein gescheites Stückel Code im Arduino.

Das mit dem Auffüllen hab ich auch gelesen, aber nicht verstanden. Die "IAR Embedded Workbench" (also der Compiler) produziert ein *.hex-File (Intel-Format), das mit einer srec_cat.exe zu einer *.bin konvertiert werden kann, die dann der CCLoader liest und flashen kann. Ich hab das immer ohne irgendwelches "auffüllen" geflasht und kein Problem damit festgestellt.

Na ja, dann scheint das Auffüllen der Bytes ja nicht so wichtig zu sein.


Ich habe gerade ein wenig an einem Sketch für den Arduino gebastelt. Dabei ist mir noch aufgefallen, dass die akkumulierte Dosis ja auf dem AtomFast zusammenintegriert und dann als fertiger Wert an die App übertragen wird. Wenn man diese dann mit "Reset the dose" zurücksetzen möchte, muss dies also auf dem Arduino geschehen.
Außerdem ist die Dosis natürlich weg, wenn man den Arduino zusammen mit dem Detektor abschaltet. Da das ggf. sehr ungünstig sein kann, müsste man die Dosis noch nichtflüchtig speichern. Da die Anzeige in ganzen µSv erfolgt, also mindestens bei jedem vollen µSv.

Und noch was ist mir aufgefallen: die Clicks bzw. Beeps bei jedem Ton werden ebenfalls auf dem AtomFast generiert. Wenn man das haben möchte, muss also permanent übertragen werden und nicht nur jede Sekunde. Bei hohen Zählraten wird es spannend. Es gibt ja auch einen Button "Reconnection sounds", also haben sie da sicherlich einen Trick verwendet. Man kann ja nicht 1000x pro Sekunde ein Datagramm schicken.

Gleiches gilt leider wohl auch für den Alarm: bei Überschreiten der Alarmschwelle vibriert das Telefon zwar, aber es erfolgt keine akustische Ausgabe. Oder ist das ein Problem seitens meines Telefons? Denn im Gegensatz zu den clicks/beeps sehe ich keinen Grund, warum das nicht auf dem Telefon geschehen sollte.


Blöderweise werde ich von der Kartenfunktion gar nichts haben. Hatte nicht mehr dran gedacht, dass ich gar keine Google Play Services drauf habe... oder gibt es vielleicht eine tolle Openstreetmap App, die sich als Google ausgibt? 

Viele Grüße,

Henri

[DG0MG]

Hier nochmal der Stand dokumentiert in einem Video. Das war eigentlich das, was ich von Anfang an machen wollte, stattdessen muss ich mich erstmal mit der Programmierung des CC2541 rumschlagen .. :

Der dazugehörige Arduino-Code sieht inzwischen so aus, an ein paar Stellen fand ich, dass das eleganter zu lösen geht. Ansätze für die Strahlungsmessung in Form von Impulszählung sind auch dabei:

Code Auswählen Erweitern

//
// credits to Nikita71 from Kiew, Ukraine
// http://forum.rhbz.org/topic.php?forum=80&topic=98
//
#define CalFactor 3.4                    // Calibrierungsfaktor in  cps / 1 mR/hr

int PIN_GMZ_count_INPUT     =   3;       // Interrupteingang für Impulse (fallende Flanke) has to be capable of "interrupt on change"

unsigned long Ticks3,Ticks2,Ticks1,Ticks0;
unsigned long new_millis;
unsigned long old_millis;
unsigned long counter;                   // Impulszähler für die Interruptroutine


void setup() {
Serial.begin(115200);
attachInterrupt(digitalPinToInterrupt (PIN_GMZ_count_INPUT), isr_count, FALLING);
pinMode(LED_BUILTIN, OUTPUT);
digitalWrite(LED_BUILTIN, LOW);          // LED aus
BluetoothPutRAD (0.0);                   // Sende den Strahlungspegel an das Telefon DEMO
delay(3000);
BluetoothPutRAD (111.11);                // Sende den Strahlungspegel an das Telefon DEMO
delay(3000);
BluetoothPutRAD (222.22);                // Sende den Strahlungspegel an das Telefon DEMO
delay(3000);
BluetoothPutRAD (333.33);                // Sende den Strahlungspegel an das Telefon DEMO
delay(3000);
BluetoothPutRAD (444.44);                // Sende den Strahlungspegel an das Telefon DEMO
delay(3000);
BluetoothPutRAD (555.55);                // Sende den Strahlungspegel an das Telefon DEMO
delay(3000);
BluetoothPutRAD (0.0);                   // Sende den Strahlungspegel an das Telefon DEMO
}

void loop() {
  new_millis = millis();
  if (new_millis - old_millis >= 1000) { // immer nach 1000 ms führen wir folgendes aus:
    old_millis = new_millis;
    Ticks3 = Ticks2;                     // FIFO 4 Werte
    Ticks2 = Ticks1;
    Ticks1 = Ticks0;
    Ticks0 = counter;                    // Der Messwert der letzten Sekunde
    counter = 0;                         // Der Impulszähler wieder auf 0, für die nächste Messung
                       
    unsigned int param_1 = BluetoothGetParam1();
    if (param_1 >= 20) {                 // LED dauerhaft an (Einstellung "Beeps")
      digitalWrite(LED_BUILTIN, HIGH);   
    }
    else if (param_1 >= 1) {             // LED blinkt (Einstellung "Clicks")
      digitalWrite(LED_BUILTIN, HIGH); 
      delay(10);                       
      digitalWrite(LED_BUILTIN, LOW); 
      delay(10);                       
    }
    else {
      digitalWrite(LED_BUILTIN, LOW);    // LED aus (Einstellung "No sound")
    }
    BluetoothPutRAD ((Ticks0+Ticks1+Ticks2+Ticks3)*2.5/CalFactor);                // Sende den Strahlungspegel in µSv gemittelt über 4 Sekunden (4 Messungen) an das Telefon
    BluetoothPutCPS (Ticks0+Ticks1);                // Sende die Anzahl der Impulse in 2 Sekunden von der Geigersonde zum Telefon (für den Messmodus benötigt)
  }
}

void BluetoothPutRAD (double value){     // Strahlungsniveau in µSv/h
  byte * p = (byte *) & value;
  Serial.write(0xA0);                    // SCHREIBEN!
  Serial.write(0x02);                    // 0x02: Dosisleistung in µSv/h
  Serial.write(p,4);                     // Serial.write(buf, len)
}

void BluetoothPutCPS (double value){     // Anzahl der Impulse von der Geigersonde für 2 Sekunden
  byte * p = (byte *) & value;           // e ist ein Pointer auf ein Array von Bytes
  Serial.write(0xA0);                    // SCHREIBEN!
  Serial.write(0x03);                    // 0x03: Anzahl der Impulse in den letzten 2 Sekunden
  Serial.write(p,4);                     // Serial.write(buf, len)
}

unsigned int BluetoothGetParam1 () {     // holt einen Parameter der Gerätesteuerungscharakteristik (0x51 , 2 Byte µint, ==> Länge des Ticks in msec
  byte buf[4];

  Serial.write(0xB0);                    // LESEN!
  Serial.write(0x51);                    // 0x51, 2 Byte uint, ==> Länge des Ticks in msec // 0x53, 2 Byte uint, ==> Länge der Schwingungsdauer in msec
  Serial.setTimeout(500);                // Nach max. 500 msec. sollten die Daten gekommen sein
  unsigned int rlen = Serial.readBytes(buf, 2);
  unsigned int resultat = *((unsigned int *) buf);  // https://forum.arduino.cc/index.php?topic=30322.0
  if (rlen >= 2) {return resultat;  }
}

void isr_count()                         // in der Interruptroutine ..
{
  counter++;                             // .. wird nur ein Impuls-Zähler bewegt, weiter nichts.
}

[Henri]

Ich war heute Vormittag auch etwas produktiv und habe mir einen "AtomSwift für Arme" gebaut, aus einem STS-6 Zählrohr, einem Theremino Geiger Adapter, einem Arduino Pro Mini 3.3V, dem besagten AT-09 Bluetooth-Modul mit neuer Firmware, und einem   > 0.7v to 3.3V DC/DC Wandler. Klappt soweit ganz gut!   

Das STS-6 schafft ca. 1 cps bei 100 nSv/h, also ca. 50 CPM bei normalem Hintergrund. Wenn man diese niedrigen Zählraten so an die App schickt, springt die Anzeige nur wild hin und her. Deshalb lasse ich den Arduino einen gleitenden Mittelwert über 10 Sekunden berechnen und schickt den dann.

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?

Im Arduino Beispielsketch liefert man ja jede Sekunde 3 Werte an die App:

- Dosisleistung in µSv/h
- Dosis in mSv
- Anzahl Counts in 2 Sekunden ("cps2")

Egal was man bei cps2 übermittelt, es hat keinen Einfluss auf die CPM-Anzeige.
Selbst im "Search-" Modus geschehen seltsame Dinge, die ich noch nicht recht verstanden habe.  Wenn ich meinen intern bestimmten CPS-Wert mit 2 multipliziere und dann sende, oder mit 0.01 multipliziere wie im Beispiel-Sketch - es hat keinen Einfluss auf die angezeigten Counts! Auch kommen beim Counts-Zähler ca. 5 pro Sekunde hinzu, obwohl das Zählrohr nur ca. 1 erzeugt. Ich vermute, dass auch diese Zahl rein aus der übermittelten Dosisleistung bestimmt wird, denn die angezeigte DL im Search-Mode ist korrekt!

Viele Grüße,

Henri

[Henri]

Hier nochmal der Stand dokumentiert in einem Video. Das war eigentlich das, was ich von Anfang an machen wollte, stattdessen muss ich mich erstmal mit der Programmierung des CC2541 rumschlagen .. :

Ach, das ist ja super! 

Wie löst Du denn die serielle Abfrage? Der Arduino muss ja ständig aufpassen, ob Daten über die serielle Schnittstelle eingehen, und ist beim Lesen dann auch erst mal blockiert. OK, das kommt natürlich nur alle Jubeljahre mal vor, wenn man mal eine Einstellung ändert, und dann verliert man halt ein paar counts.

Jedenfalls geht's voran!

Hast Du akustischen Alarm auf Deinem Telefon bei Grenzwertüberschreitung?

Viele Grüße,

Henri

[DG0MG]

habe mir einen "AtomSwift für Arme" gebaut, aus einem STS-6 Zählrohr, einem Theremino Geiger Adapter, einem Arduino Pro Mini 3.3V, dem besagten AT-09 Bluetooth-Modul mit neuer Firmware, und einem   > 0.7v to 3.3V DC/DC Wandler. Klappt soweit ganz gut!   

Hervorragend! 
Betreibst Du den GA500 dann mit nur 3,3V? Er ist ja eigentlich für 5 V vorgesehen?

Egal was man bei cps2 übermittelt, es hat keinen Einfluss auf die CPM-Anzeige.
Selbst im "Search-" Modus geschehen seltsame Dinge, die ich noch nicht recht verstanden habe.

Das hab ich nicht weiter untersucht. Es ist aber wohl so, dass die DL im SEARCH-Fenster und der CPS2-Wert im MEASURE-Fenster benutzt werden. Wahrscheinlich ist auch die Bezeichnung "CPS" irreführend, denn es sind wohl eher "Counts in 2 Sekunden".

Vielleicht erkennt er an der Bluetooth-Kennung, um was für ein Gerät es sich handelt, und bedient sich dann fest konfigurierter Kalibrierfaktoren?

Nein, sicher nicht. Das Bluetooth-Profil kennt ja den Kalibrierfaktor, der ist im AF selbst hinterlegt. Eventuell musst Du den erst beschreiben, damit die App richtig rechnet.  Das ATOMSERVICE BLE-pdf aus dem Eröffnungsbeitrag kannst Du mit Google übersetzen lassen und mit etwas Phantasie lesen. Der übersetzte Forenbeitrag von "SypH3er" hilft auch.

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

Die 0x60 werden im CC2541 auf charValue7[0..3] gemappt, also ebenfalls ein 4-Byte-Wert.

Im PDF auf Seite 22 steht dann die Erklärung: Ein 4-Byte-Wert(float), der die Impulse pro µR angibt. Der Wert soll für ein SBM-20 78.0 sein.

Du könntest also eine neue Prozedur einführen, die 0xA0 (SCHREIBE!), 0x60 (Kalibrierwert) und 4 Byte FLOAT sendet. Damit ist der Kalibrierwert im BT-Profil und die App kann damit arbeiten.

Etwa so:

void setup() {
BluetoothPutKalib (78.0);                   // Sende den Kalibrierfaktor
}

void BluetoothPutKalib (double value){
  byte * p = (byte *) & value;           // p ist ein Pointer auf ein Array von Bytes
  Serial.write(0xA0);                    // SCHREIBEN!
  Serial.write(0x60);                    // Kalibrierwert
  Serial.write(p,4);                     // Serial.write(buf, len), 4 Byte
}

Wie löst Du denn die serielle Abfrage? Der Arduino muss ja ständig aufpassen, ob Daten über die serielle Schnittstelle eingehen, und ist beim Lesen dann auch erst mal blockiert. OK, das kommt natürlich nur alle Jubeljahre mal vor, wenn man mal eine Einstellung ändert, und dann verliert man halt ein paar counts.

Schau in den kompletten Arduino-Code oben. Impulse dürften nicht verloren gehen, da die Zählung interruptbasiert ist. Das "Warten" auf die serielle Antwort scheint sich mit Serial.setTimeout(500); begrenzen zu lassen, wenn innerhalb 500 msec nichts gekommen ist, dann passiert halt nichts.

[Henri]

Ach OK!! Ja, ich war bislang etwas zu faul, mich mit dem Protokoll weiter auseinanderzusetzen. Spätestens jetzt sollte ich mal damit anfangen :-)

Betreibst Du den GA500 dann mit nur 3,3V? Er ist ja eigentlich für 5 V vorgesehen?

Der Theremino GA500 ist  eigentlich von 3.5- 6V spezifiziert, aber tatsächlich läuft er bis runter auf 1.8V. Allerdings habe ich nicht überprüft, ob die Hochspannung dann noch stimmt oder eventuell sogar einbricht bei höheren Zählraten, aber bei 1.8V schwingt die Schaltung noch an und liefert in der Größenordnung eine korrekte Anzahl von Impulsen pro Zeit. Mir ging es vor allem um den Betrieb bei 3.3V, und die sind kein Problem. Aber es wird auch interessant, wenn man einen Arduino auf 1 MHz runtertaktet und dann mit 2x AA Akkus in Reihe betreibt. Die Eneloops haben ihr Ende der Entladekurve bei 1.20V, danach geht's steil bergab. Wenn die Schaltung also zwischen 2.8 und 2.4V läuft, kann man ihre Kapazität fast komplett ausnutzen.  Wenn man beim runtergetakteten 3.3V Arduino dann noch die Power-LED auslötet und eines dieser superstromsparenden Electronics Assembly "DOGS" Displays zur Anzeige nimmt, kommt man incl. Geigeradapter auf unter 1.5mA  Stromverbrauch bei normalen Zählraten. Das heißt, mit einer Akkuladung läuft der selbstgebaute Geigerzähler dann kontinuierlich ca. 6 Wochen durch.
Verglichen mit dem GammaScout ist das natürlich nicht wirklich spektakulär, aber für den "Hausgebrauch" unter Verwendung fertiger Komponenten durchaus interessant.
Solarzellenbetrieb ist auch kein Problem.

Wenn man die Stromsparfunktionen von BT LE noch zum Laufen kriegen würde, würde man damit ähnliche Laufzeiten wie beim AtomFast hinbekommen.

Viele Grüße!

Henri