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

[Henri]

Hallo,

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?

das sind ja gute Nachrichten!

Aber ich habe noch mal ein wenig dazu gelesen. Um den eigentlich mit einem externen 8 MHZ Resonator ausgerüsteten Pro Mini auf 1 MHz runterzutakten, muss ich auf den internen Oszillator zurückgreifen. Der ist aber nicht sonderlich genau und driftet auch gerne mal. Und bei 1 MHz bekommt man z.B. für 9600b auch schon keine gute Übereinstimmung bezüglich des Timings hin. Das führt dann wohl dazu, dass 9600b bei 1 MHz nicht richtig läuft.

Aber mit 19200b ist die Grund-Übereinstimmung schon mal etwas besser und wäre einen Versuch wert. Könntest Du mir das vielleicht gelegentlich mal kompilieren?
Ich werde es allerdings erst ausprobieren können, wenn die neuen AT-09 Module da sind, die ich heute bestellt habe. Die kommen aus China, weil ich sie ohne Levelshifter-Platine haben möchte.  Das eine funktionierende, das ich habe, hüte ich jetzt wie einen Augapfel und werde es nicht noch einmal flashen.

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

Ja, ein CC2541 ist drauf und sieht auch "original" aus. Die 3 verbundenen Pins sind nur AVDD4, AVDD1 und AVDD2, was laut Schaltplan auch korrekt ist. Auf dem anderen Board sitzt die Brücke anscheinend woanders. Ansonsten sieht alles "sauber" aus.

Ich hatte 2 Module bestellt. Die kamen nicht ESD-geschützt verpackt. Vielleicht ist der Händler ja vorher mit den falschen Schuhen über den Teppich geschlurft...

So richtig verstanden habe ich auch noch nicht, wie der Programmierprozess abläuft. Werden die geschriebenen bytes noch mal überprüft? Es kommt ja am Ende eine "Successful" Meldung. Aber dann sollte es funktionieren. Es wird ja auch ggf. "no target detected" angezeigt. Ich müsste mal probieren, ob sich das nur auf den Arduino am COM-Port, oder auch auf das BT-Modul am Arduino bezieht.
Jedenfalls habe ich sicherlich 10x die Firmware von Dir, die ja auch schon auf dem ersten Modul läuft, und außerdem die protonbridge aus dem Forum, geflasht. Aber es tut sich nichts.


Viele Grüße!

Henri

[DG0MG]

Aber ich habe noch mal ein wenig dazu gelesen. Um den eigentlich mit einem externen 8 MHZ Resonator ausgerüsteten Pro Mini auf 1 MHz runterzutakten, muss ich auf den internen Oszillator zurückgreifen. Der ist aber nicht sonderlich genau und driftet auch gerne mal. Und bei 1 MHz bekommt man z.B. für 9600b auch schon keine gute Übereinstimmung bezüglich des Timings hin. Das führt dann wohl dazu, dass 9600b bei 1 MHz nicht richtig läuft.

Äh, das verstehe ich jetzt nicht - 19200 soll besser gehen, als 9600?

So richtig verstanden habe ich auch noch nicht, wie der Programmierprozess abläuft. Werden die geschriebenen bytes noch mal überprüft? Es kommt ja am Ende eine "Successful" Meldung. Aber dann sollte es funktionieren. Es wird ja auch ggf. "no target detected" angezeigt. Ich müsste mal probieren, ob sich das nur auf den Arduino am COM-Port, oder auch auf das BT-Modul am Arduino bezieht. Jedenfalls habe ich sicherlich 10x die Firmware von Dir, die ja auch schon auf dem ersten Modul läuft, und außerdem die protonbridge aus dem Forum, geflasht. Aber es tut sich nichts.

So genau weiß ich das auch nicht. Wenn man die CCLoader.ino mal grob durchschaut, findet man da nichts von z.B. "VERIFY". Könnte ja aber auch in der Executable realisiert sein in der Form "Schreibe nn nachfolgende Daten an Stelle xx", "Lese nn Daten von Stelle xx" und danach der Vergleich. Damit fände man im CCLoader.ino wirlich nur Lese und Schreibbefehle. Das mag ich aber nicht debuggen zumals ja bei mir geht. Hast Du mal mit einem anderen Arduino anderen Typs probiert? Also z.B. mit einem nano oder so? Es muss ja nicht zwingend an den Modulen liegen und die größere Anzahl der Leute die sowas machen, scheint das Flashen unter Windows durchzuführen. Da spielt ja der USB2serial-Wandler auch noch mit rein.

Im Anhang die beiden Versionen mit 9600 Bd und 19200 Bd. Die erstere hab ich getestet (also nachher im Arduino-Code auch auf 9600 umgestellt), das geht.

[Henri]

Äh, das verstehe ich jetzt nicht - 19200 soll besser gehen, als 9600?

Ja, beide Kommunikationspartner brauchen ja den selben "Takt". Und der bestimmt sich aus der Taktung des Prozessors und ggf. einem clock_div.  Wenn beide Seiten nun 9600b sprechen wollen, kann die eine Seite vielleicht nur 6917b liefern, weil das der Prozessortakt so vorgibt.  Und die andere Seite spricht vielleicht nur 9513b. Irgendwann wird es dann kritisch, und dann werden Zeichen missverstanden.  Eine bestimmte Prozessortaktung kann nicht jede Baudrate gleich präzise liefern. Und 1 Mhz und 9600b beißen sich leider ziemlich.

Zu meinem AT-09: den habe ich mit exakt dem gleichen Arduino mit der noch aufgespielten Firmware unter Windows mit der selben CCloader.exe geflasht wie beim ersten Mal, wo es problemlos funktioniert hatte. Ich habe alle Drähte durchgemessen und sogar mal mit dem Oszi geschaut. Ich kann es mir wirklich nur so erklären, dass das Modul kaputt ist. Leider habe ich vor dem Flashen nicht probiert, ob es AT-Kommandos entgegennimmt.

Ein großes Dankeschön für die beiden Firmwares!!!

Viele Grüße,

Henri

[Henri]

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.

Wenn ich es richtig verstanden habe, ist es tatsächlich die einzige Möglichkeit, den Kalibrierfaktor zu überschreiben, wenn man alle Anzeigen kongruent haben möchte.

Der Kalibrierfaktor K wird in der App zur Berechnung herangezogen von

- CPM im SEARCH Modus:  CPM = DL * K / 0.6

- CPM im MEASURE Modus: CPM = ((D2-D1) * K * 10.000) / t[min]

- CPS im MEASURE Modus: CPS = ((D2-D1) * K * 10.000) / t[sek]

Das Problem ist die Berechnung der CPM im SEARCH Modus durch Heranziehung der DL. Denn wenn man auf dem Arduino die DL so zurechtbiegt, dass die App aus ihr und dem fixen K ein korrektes CPM berechnet, stimmt die angezeigte DL im SEARCH Modus nicht mehr - diese wird ja genauso angezeigt wie vom Arduino gesendet.

Hast Du das mal ausprobiert? Kann man den im BT-Modul gespeicherten K überschreiben? Wieso ist der überhaupt im BT hinterlegt, statt das BT-Modul einfach nur zum Durchschleifen der Daten zu verwenden?

[DG0MG]

Wieso ist der überhaupt im BT hinterlegt, statt das BT-Modul einfach nur zum Durchschleifen der Daten zu verwenden?

Naja, man muss sich mal die beiden Bluetooth-Stacks (im Smartphone und im CC2541) als Mittel zum Zweck vorstellen. Sie ermöglichen, dass auf die gleichen Variablen (eigentlich mittels UUID definierte Bytefolgen) von BEIDEN Seiten der Funkstrecke gleichermaßen zugegriffen werden kann. Wenn ich auf einer Seite etwas in einer Variable ÄNDERE, dann ist das quasi automatisch auch auf der anderen Seite geändert. Vielleicht ist auch ein großes altmodisches Postschließfachsystem eine geeignete Anschauungsmöglichkeit: Es gibt EIN Fach, von vorn kann der Postkunde die Klappe öffnen und rausnehmen oder reinlegen und von hinten kann dasselbe die Postchristel machen.

Die App braucht nun den Kalibrierfaktor, also liest sie die entsprechende UUID aus, und verwendet den Wert in der Rechnung. Im Atom Fast ist der Kalbrierfaktor im NVRAM oder Flash gespeichert, beim Einschalten wird den der Prozessor also erstmal auslesen und in die UUID packen. Damit ist K auch für die App verfügbar.

Damit nun beim Einschalten des CC2541 in der UUID wenigstens ein sinnvoller Wert (und nicht 0x00000 oder gar was zufälliges)  drinsteht, hat SypH3er bei der ProtonBridge den Programmcode halt mit dem Kalibrierwert des AF 7735 initialisiert. Er hätte auch 1234 nehmen können. Wenn die Anzeigeergebnisse aber plausibel sein sollen, muss da natürlich der "richtige" Wert hin. D.h. ich muss vom Arduino aus die Variable für den Kalibrierwert ändern - genauso, wie ich das auch mit der Variable für die Dosis, die Dosisleistung usw. mache.

Ungefähr so:

Code Auswählen Erweitern


#define CalFactor 1930.0                 // Zählrohr-Kalibrierungsfaktor in  counts / µR SBM-20:78, AF 7735:1700

void setup() {
}

void loop() {
    BluetoothPutDose ((float)(pulsestotal/CalFactor*0.00001));                         // Dosis in mSv
    BluetoothPutDoseRate ( 0.01 * (Ticks0+Ticks1+Ticks2+Ticks3) * 900 / CalFactor);    // Sende den Strahlungspegel in µSv/hr 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)
    BluetoothPutBattPercent (measureBattVoltage());
    BluetoothPutTemperature(23);
    BluetoothPutKalib (CalFactor);       // Sende den Kalibrierfaktor in counts/µR
  }
}

void BluetoothPutKalib (float 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
}


Ich habs jetzt im Loop und sende den Kalibrierfaktor jede Sekunde mit, aber wahrscheinlich kann man den Befehl auch ins setup() verschieben.

[Henri]

OK, jetzt habe ich es geschnallt!  Hatte gestern den ganzen Abend rumüberlegt, wie man mit dem vorgesetzten Kalibrierfaktor trotzdem auf realistische Werte kommen kann. Aber das macht es jetzt deutlich einfacher.

Mir ist bei meinen Modulen noch aufgefallen, dass der CC2541 Chip bei den beiden, die nicht funktionieren, gleich aussehen. Der, der funktioniert, hat eine andere Oberfläche und ist auch anders gelasert. Entweder stammt er aus einem anderen Werk von TI, oder da ist tatsächlich mal wieder was "gefälscht" worden 


EDIT:

Habe gerade bemerkt, dass in dem russischen Forum

https://translate.google.com/translate?hl=&sl=ru&tl=de&u=http%3A%2F%2Fforum.rhbz.org%2Ftopic.php%3Fforum%3D80%26topic%3D98

viele das gleiche Problem haben. Auch hier sehen die Chips unterschiedlich aus - die eine Sorte funktioniert, die andere nicht!

Hoffentlich habe ich jetzt nicht wieder Mist nachbestellt...

[Henri]

Sooo, ich habe gerade noch mal das AtomSwift Entwicklerhandbuch durch deepl gejagt. Jetzt kann man es auch ohne Russischkurs lesen :-)

[DG0MG]

Sooo, ich habe gerade noch mal das AtomSwift Entwicklerhandbuch durch deepl gejagt. Jetzt kann man es auch ohne Russischkurs lesen :-)

Das sieht wirklich gut aus! Ich habs immer mit Google Translate gelesen, das hat dummerweise die Tabellen entfernt ..

[Henri]

Ja, weiter unten sind zwar ein paar Formatierungen verloren gegangen, aber man kann schon gut was mit anfangen.


Ich hatte gestern Abend mal das Senden des Kalibrierfaktors und das Empfangen der Ton-Einstellungen von der App probiert und dabei am Ende auch Deinen unveränderten Beispielcode verwendet, den Du im russischen Forum gepostet hattest. Aber weder das eine noch das andere hat funktioniert - die CMP/CPS wurden zu hoch angezeigt wie vorher, und das Leuchtverhalten der onboard-LED konnte ich auch nicht steuern. Bin allerdings ziemlich sicher, dass ich die AT-09 Firmware von Dir aufgespielt habe, die schon entsprechend gefixt war. Hast Du vielleicht eine Idee, woran es liegen könnte? Als Kalibrierfaktor für das STS-6 hatte ich 442 Imp/µR genommen.

Toll wäre übrigens, wenn man von der App aus noch die akkumulierte Dosis zurücksetzen könnte. Aber ich habe in dem Entwicklerdokument den Parameter nicht finden können. Hatte ich da  Tomaten auf den Augen?

Viele Grüße!

Henri

[DG0MG]

Naja, Du musst vielleicht erstmal rausfinden, ob der CC2541 überhaupt mit Daten antwortet, wenn Du einen Lese-Befehl 0xB0 ("Lesen"), 0x51 ("Ticklänge") schickst. Am besten mit einem Oszi. Dann darf natürlich der Pegelwandler für die Verbindung zum PC nicht paralll am Arduino dran sein, eventuell ist dessen Pegel am RxD-Eingang "dicker". Auf dem Arduino nano ist deshalb ein 1k-Widerstand dazwischen, da muss ich aber dann zum Ändern des Programmes den CC2541 abtrennen.

Das Rückstellen der Dosis werden wir rausfinden.

[Henri]

Naja, Du musst vielleicht erstmal rausfinden, ob der CC2541 überhaupt mit Daten antwortet, wenn Du einen Lese-Befehl 0xB0 ("Lesen"), 0x51 ("Ticklänge") schickst. Am besten mit einem Oszi. Dann darf natürlich der Pegelwandler für die Verbindung zum PC nicht paralll am Arduino dran sein, eventuell ist dessen Pegel am RxD-Eingang "dicker". Auf dem Arduino nano ist deshalb ein 1k-Widerstand dazwischen, da muss ich aber dann zum Ändern des Programmes den CC2541 abtrennen.

Das Rückstellen der Dosis werden wir rausfinden.

Hmmm... ich war in meinem letzten Post etwas unpräzise, ich habe Deinen Code doch geändert. Weil ich nicht dauernd das BT-Modul an- und wieder abstöpseln wollte, bzw. dieses mittlerweile auch "fest" verlötet ist, habe ich SoftSerial genommen. Das funktioniert in die eine Richtung auch problemlos, selbst mit 115200b, auf einem 8 MHz Arduino. Aber vielleicht macht er dann beim "Empfangen" nicht mehr mit - der Prozessor ist bei SoftSerial ja geblockt, bis alles angekommen ist. Daran könnte es liegen.

Ich schaue am Wochenende mal, ob es mit HW Serial besser läuft, und bemühe auch mal das Oszi.

Übrigens ist mir gerade ein schöner großer Szintillator zugeflogen. Kann mir gut vorstellen, da einen "AtomRich" draus zu machen :-)

[DG0MG]

Hm, die Dosis zurückstellen.
Dazu musste ich nochmal die Geschichte anschauen, die ich in Antwort #56 (der "1/10-Schalter") schonmal auseinandergenommen habe, damals zwar nicht falsch, aber doch unvollständig. Die bessere Übersetzung des Atom-Service-BLE-Dokumentes lässt einen dann auch manche Sachen eher verstehen

Im Register 0x50 werden also von der App kein Status (z.B. über die Stellung eines Schalters) übermittelt, sondern stattdessen ein Befehl, dieses und jenes zu tun. Das ist nur EIN Byte. Da manche der "Befehle" Parameter erfordern, gibt es noch 3 Zwei-Byte-Parameter (zugänglich über 0x51, 0x52, 0x53).

Schauen wir uns an, was in den Registern so ankommt, wenn man diverse Schaltflächen in der App betätigt:



Wie man sieht, braucht man den Parameter 1 nicht oft, die anderen beiden überhaupt nicht.


- 0x01/0x01 schaltet Ticks ein
- 0x01/0x20 Beeps statt Ticks (der zweite Wert ist die Tonlänge in ms)
- 0x08      Ruhe
- 0xAA      Find the device (Spielt im Original wohl eine Melodie)
- 0xDE      Setzt die Dosis zurück.
- 0xFF/0xACCE Schaltet das Gerät aus.

Die ist dann übereinstimmend mit der Beschreibung im PDF auf den Seiten 15..17ff.

Ich hab das im Programm so gelöst: jede Sekunde schaue ich nach dem Command-Byte 0x50. Wenn das etwas anderes als 0 enthält, wird verzweigt, bei Bedarf zusätzlich noch der Parameter 1 geholt und eine Aktion ausgeführt. Wenn das getan ist, setze ich mit einem Schreibbefehl das Kommandobyte wieder auf Null, damit wird in den nächsten Schleifendurchläufen der Befehl nicht wiederholt ausgeführt. Da ich die Dosis aus der aufsummierten Gesamtimpulszahl errechne, setze ich beim Erkennen des Befehls "0xDE" diese auf Null. Zum Testen initialisiert man die am Programmanfang eben nicht mit Null sondern z.B. mit 100000000, da ist dann schonmal ein halbes Millisievert (oder mehr) auf der Uhr.

Code Auswählen Erweitern


unsigned int  tickdivider = 0;
unsigned int  ticklength = 0;
unsigned int  password = 0;

boolean       tickflag = false;
boolean       divideby10 = false;
unsigned long pulsestotal = 100000000;           // Gesamtzahl der eingegangenen Impulse   


void setup() {
}

void loop() {
  if (tickflag) {
    tickflag = false;
    tickdivider++;
    if ((!divideby10) || (divideby10 && (tickdivider>10))) {
      if (ticklength > 0) tone(PIN_BUZZER, 1900, ticklength);
      tickdivider = 0;
    } 
  }
  new_millis = millis();
  if (new_millis - old_millis >= 1000) { // immer nach 1000 ms führen wir folgendes aus:
    old_millis = new_millis;

    switch ( BluetoothGetCommand()) {
      case 0x00 :
      break;
      case 0x01 :                        // "Clicks" oder "Beeps"
        ticklength = BluetoothGetParam1 () ;
        divideby10 = false;
        BluetoothClearCommand ();
      break;
      case 0x08 :                       // "nosound"
        ticklength = 0;
        BluetoothClearCommand ();
      break;       
      case 0xAA :                       // "Find Device"
        FindDevice();
        BluetoothClearCommand ();
      break;
      case 0xDE :                       // Zurücksetzen der Dosis
        pulsestotal=0;
        BluetoothClearCommand ();
      break;
      case 0xE1 :                       // 1/10-Teiler-Schalter
        ticklength = BluetoothGetParam1 () ;
        if (ticklength>0) { divideby10 = true; } else { divideby10 = false; };
        BluetoothClearCommand ();
      break;
      case 0xFF :                       // Turn off device
        password =  BluetoothGetParam1 () ;
        BluetoothClearCommand ();
      break;
    } 
  }
}

byte BluetoothGetCommand () {            // holt einen Kommando der Gerätesteuerungscharakteristik und den ersten der 3 Parameter
  byte buf[4];
  Serial.write(0xB0);                    // LESEN!
  Serial.write(0x50);                    // 0x50 = Gerätesteuerungskommando-variable
  Serial.setTimeout(1500);                // Nach max. 1500 msec. sollten die Daten gekommen sein
  unsigned int rlen = Serial.readBytes(buf, 1);
  byte resultat = *((byte *) buf);       // https://forum.arduino.cc/index.php?topic=30322.0
  if (rlen >= 1) {return resultat;  } else return 0;
}

void BluetoothClearCommand () {               // Setzt die Gerätesteuerungskommando-variable (das Kommando) wieder auf 0)
  Serial.write(0xA0);                    // SCHREIBEN!
  Serial.write(0x50);                    // 0x50 = Gerätesteuerungskommando-variable
  Serial.write(0x00);                    // Auf 0 setzen!
}

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
  Serial.setTimeout(1500);                // Nach max. 1500 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;  } else return 0;
}

void FindDevice () {
  for (int i=0; i <= 5; i++){
    tone(PIN_BUZZER, 950, 200);
    delay(200);
    tone(PIN_BUZZER, 1900, 200);
    delay(200);
  }
}


[Henri]

Sooo...! Ich glaube, ich fahre besser damit, künftig systematischer vorzugehen. Deshalb habe ich meinem "AtomPoor" mit STS-6 sein BT-Modul geklaut und mir mit einem neuen Arduino eine Testumgebung zusammengelötet. Programmieradapter und BT-Modul sind steckbar, dh. ich verwende jetzt erst mal genau wie Du Hardware-Serial und 8 MHz/3.3V. Wenn alles läuft wie gewünscht, kann ich dann ja immer noch schauen, ob es mit SoftSerial und/oder 1 MHz zum Laufen zu bringen ist. Ich habe dem Arduino noch eine RGB-LED spendiert und kann nun also verschiedene Dinge gut visualisieren. Impulse zähle ich erst mal keine, sondern simuliere das nur. Dann kann man auch besser sehen, ob alles richtig umgerechnet wird.

Gerade habe ich es mit dem Sketch getestet, den Du ins russische Forum gestellt hattest, um die 2-way Kommunikation zu demonstrieren. Also, nun: läuft super bei mir!    Ich kann mit dem Sound-Auswahlmenü nun die RGB-LED am Arduino steuern

Viele Grüße!

Henri

[Henri]

Zum Ändern des Kalibrierfaktors:

Code Auswählen Erweitern


#define CalFactor 1930.0                 // Zählrohr-Kalibrierungsfaktor in  counts / µR SBM-20:78, AF 7735:1700

void setup() {
}

void loop() {
    BluetoothPutDose ((float)(pulsestotal/CalFactor*0.00001));                         // Dosis in mSv
    BluetoothPutDoseRate ( 0.01 * (Ticks0+Ticks1+Ticks2+Ticks3) * 900 / CalFactor);    // Sende den Strahlungspegel in µSv/hr 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)
    BluetoothPutBattPercent (measureBattVoltage());
    BluetoothPutTemperature(23);
    BluetoothPutKalib (CalFactor);       // Sende den Kalibrierfaktor in counts/µR
  }
}

void BluetoothPutKalib (float 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
}


Ich habs jetzt im Loop und sende den Kalibrierfaktor jede Sekunde mit, aber wahrscheinlich kann man den Befehl auch ins setup() verschieben.

Funktioniert das bei Dir? Ich kann machen was ich will, den Kalibrierfaktor ignoriert die App und zeigt bei den CPM "Hausnummern"... 


Und lästigerweise bekomme ich mit

Code Auswählen Erweitern


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)
}


auch keine CPS in den SEARCH-Mode der App... da steht immer 0,0.

Was geht, ist Übertragung der Dosisleistung, Dosis, Temperatur und Batterie-Prozente, sowie NoSound/Beep/Click. 

[DG0MG]

Also ich bin schon der Meinung, dass es funktioniert. Ich hab so 8-11 cps, daraus ergeben sich ~400-600 cpm und ~0,17 µSv/h, sowohl im SEARCH- wie auch im MEASURE-Modus.
Im Prinzip muss es ja schon funktionieren, wenn die Dosisleistung im MEASURE gleich der direkt übertragenen im SEARCH ist, denn dafür ist ja schon der Kalibrierfaktor nötig.

Machst Du das jetzt mit der 19200Bd-Variante?

Du könntest mal testweise irgendwo (z.B. am Anfang jeder Sekundenschleife) das Senden einer Reihe von "0x00" einbauen.

Im Code der ProtonBridge ist Nichts, was die Kommunikation synchronisiert, außer eben die Reaktion auf 0x0A und 0x0B. Wenn irgendwo mal ein Byte zuviel oder zuwenig gesendet wurde, kommen die Stelle, an der nach 0xA0/0xB0 ausgewertet wird und das wirklich gesendete 0xA0/0xB0-Byte nie mehr zusammen.


Einzig den Variablentyp hab ich später noch nach unsigned int geändert:

Code Auswählen Erweitern

void BluetoothPutCPS (unsigned int 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,2);                     // Serial.write(buf, len)
}

Ich hatte eigentlich bisher keine Praxis in C und überhaupt kein Grundlagenwissen dazu. Aber ich hab festgestellt, dass man natürlich nicht so einfach die Variablentypen durch die Gegend würfeln darf, wie vielleicht in anderen Programmiersprachen. Deshalb muss natürlich auch der Funktionsaufruf einen unsigned int-Typ besitzen.

Code Auswählen Erweitern

unsigned int  Ticks0 = 0;
unsigned int  Ticks1 = 0;
    BluetoothPutCPS (Ticks0+Ticks1);     // Sende die Anzahl der Impulse in 2 Sekunden


Die Addition zweier unsigned int-Werte dürfte den Variablentyp nicht ändern, aber eine Fließkomma-Operation sollte in dem Aufruf BluetoothPutCPS() natürlich nicht drinstehen.

Der Kalibrierfaktor ist vom Typ float, deshalb soll man eben schreiben: #define CalFactor 1930.0 und nicht einfach nur #define CalFactor 1930.