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

[Henri]

Ich hatte als Zählrate feste 10 cps vorgegeben und dann den Kalibrierfaktor auf 3.6 (also mit definierter Nachkommastelle) gesetzt. Damit wird Arduino-intern eine Dosisleistung von 10µSv/h errechnet und auch korrekt zur App gesendet und dort angezeigt. Wenn diese den Kalibrierfaktor korrekt empfangen hätte, müsste sie aus diesem und der Dosisleistung die Zählrate korrekt zurückrechnen, also auf 600 cpm kommen. Tatsächlich werden aber ~ 28888 CPM angezeigt. Im MEASURE Modus zählt der Impulszähler auch dementsprechend schnell hoch, also nicht mit 10er Inkrementen, sondern mit ca. 500ern.
Ändere ich im Arduino den Faktor, sende aber die gleiche Dosisleistung, müssten sich eigentlich die CPM ändern. Tun sie aber nicht, sie bleiben bei ~28888. Also wird der Kalibrierfaktor bei mir nicht ausgewertet.

Ich mache das noch mit der 115200 Variante, die aber ja schon Kommunikation in beide Richtungen ermöglicht.

Das mit den Variablendeklarationen ist aber ein guter Hinweis, das probiere ich nachher noch mal! Wenn etwas absolut inkompatibel ist, fängt es der Arduino Compiler ja ab, aber wenn nur ein logischer Fehler resultiert, halt nicht. Bei den CPS wundert mich, dass immer 0.0 angezeigt werden, egal was ich sende. Sowohl im SEARCH als auch im MEASURE Modus.

Und wenn ein einzelnes Byte verlorengeht, sollte danach dann ja gar nichts mehr gehen. Ich habe es tatsächlich immer mal wieder, dass der "Fortschrittskringel" angezeigt wird. Da ist dann wahrscheinlich ein einzelner 1-s-Wert mal ausgeblieben. Aber die Dosis und der Akkustand werden ja weiterhin übertragen, und die Daten werden ziemlich am Schluss gesendet, also muss davor ja eigentlich auch alles stimmen. Für den Akkustand verwende ich zur Zeit den internen ADC, das heißt ich habe echte Werte, die dauernd hin und her springen.
Im Moment sende ich den Kalibrierfaktor als letztes. Ich hatte gestern gar nicht geschaut, was passiert, wenn man ihn als erstes sendet. Das probiere ich nachher auch noch mal.

[Henri]

Ich habe noch mal mit den Datentypen gespielt. Überall uint genommen, auch für den Kalibrierfaktor. Außerdem habe ich das Senden des Kalibrierfaktors an verschiedenen Stellen im Datagramm probiert.

Ergebnis:

CPS im SEARCH Mode funktioniert nun und zeigt die korrekten 10 cps. Das lag am Datentyp! Ich benutze jetzt unsigned long dafür. Die nächste Reaktorkatastrophe kommt bestimmt

CPM zeigt weiterhin nur 28333. Meine 10 cps werden im Arduino zu 10µSV/h verrechnet (Kalibrierfaktor ist 36). Wenn man die 28333 CPM zurückrechnet auf die 10µSV/h, ergibt sich ein Kalibrierfaktor von 1700. Das ist der für den AtomFast.

Man kann das Problem natürlich umgehen, indem man den Faktor in der ProtonBridge entsprechend setzt. Aber ich fürchte, auf meiner alten WinXP Kiste bekomme ich die Entwicklungsumgebung nicht zum Laufen, und ansonsten benutze ich Windows halt nicht. Also, wenn es bei Dir funktioniert, wäre es schon sehr spannend, herauszufinden, wo die Unterschiede liegen.


Du hast das Problem, dass die Clicks vom AtomFast über USB-Audio an das Smartphone übertragen werden, nun mit einem Piezo direkt am Arduino gelöst, oder?

Ich probier jetzt mal, ob ich den Dosis-Reset zum Laufen bekomme

EDIT: läuft! 

[DG0MG]

Ich habe noch mal mit den Datentypen gespielt. Überall uint genommen, auch für den Kalibrierfaktor. Außerdem habe ich das Senden des Kalibrierfaktors an verschiedenen Stellen im Datagramm probiert.

Die jeweiligen verschiedenen Datentypen sind ja im ATOMSERVICE-PDF angegeben, z.B. für den Kalibrierfaktor eben float. Halte ich für keine gute Idee, davon abzuweichen.

Man kann das Problem natürlich umgehen, indem man den Faktor in der ProtonBridge entsprechend setzt. Aber ich fürchte, auf meiner alten WinXP Kiste bekomme ich die Entwicklungsumgebung nicht zum Laufen, und ansonsten benutze ich Windows halt nicht. Also, wenn es bei Dir funktioniert, wäre es schon sehr spannend, herauszufinden, wo die Unterschiede liegen.

Also ich hab jetzt folgendes gemacht:

Code Auswählen Erweitern


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

//    BluetoothPutKalib (CalFactor);       // Sende den Kalibrierfaktor in counts/µR
    BluetoothPutKalib (75.0);       // 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
}

Also im Arduino-Programm rechne ich weiter mit den 1930, übermitteln tue ich aber etwas völlig anderes, nämlich 75.
Das führt jetzt dazu, dass ich im Measure-Modus 20 cpm und 0,3 cps angezeigt bekomme. Etwas erschrocken bin ich zuerst über die Tatsache, dass die Dosisleistungsanzeige im MEASURE trotzdem richtig ist. Aber das ist schon okay so: die Dosis wird ja weiterhin mit dem richtigen Kalibrierfaktor errechnet und übermittelt. Nur mein Gedanke, dass die Kalibrierfaktorsache hinhauen müsste, wenn SEARCH und MEASURE die ODL gleich anzeigen, ist falsch. Das ändert aber nichts daran, dass cpm und cps wie erwartet sinken, wenn man einen falschen (zu niedrigen) Kalibrierfaktor sendet.
Warum das nun aber bei Dir nicht geht?

Mach doch mal ein extrem minimalistisches Testprogramm, dass nur die fraglichen Werte übermittelt, sonst nix rundrum.

Du hast das Problem, dass die Clicks vom AtomFast über USB-Audio an das Smartphone übertragen werden, nun mit einem Piezo direkt am Arduino gelöst, oder?

Ja, so ist es ja auch am Atom Fast und das geht gar nicht anders. Dass die Klicks irgendwie übertragen würden, hatte ich ja nur aus verschiedenen Videos heraus gemutmaßt.

[Henri]

Also bei Dir funktioniert es. Das minimalistische Programm zum Testen hatte ich bereits gemacht, aber wie gesagt, bei mir geht es nicht, warum auch immer. Was den Datentyp betrifft, stimmt, da sollte man sich an die Dokumentation halten. Aber einen Versuch war es wert, da es ja keinen AtomFast gibt, für den ein so niedriger Kalibrierfaktor nötig wäre, dass man die Nachkommastellen braucht. Könnte ja auch ein Fehler in der Dokumentation sein. Aber wahrscheinlich braucht man "float" einfach für die nachfolgenden Berechnungen.

Vielleicht hattest Du in der ProtonBridge noch mal was geändert, nachdem Du hier die erste Version ins Forum gestellt hast, die in beide Richtungen kommunizieren kann? Sobald die neuen BT-Module da sind, flashe ich mal eins mit der Firmware, die Du vor kurzem für mich kompiliert hast.

Aber selbst wenn ich den Kalibrierfaktor nicht zum Laufen bekomme, wichtig ist ja vor allem die Dosisleistung im Search-Modus (funktioniert) und die CPS im Search-Modus (funktioniert auch). CPM nutze ich gewohnheitsmäßig eh nicht, und was den Measure Mode betrifft... kann ich auch erst mal ohne leben. Was den Rest betrifft, geht ja mittlerweile auch schon richtig viel.

Viele Grüße!

Henri

[DG0MG]

Wir werden das schon rausfinden. Dass ich in der ProtonBridge nochmal was geändert habe, nachdem die bidirektionale Kommunikation ging, ist mir eigentlich nicht bewusst. Aber trotzdem kann man das mal im Auge behalten.

Wenn Du ein Minimalprogramm gemacht hast, das NICHT funktioniert, dann poste doch mal das komplette *.ino - ich werde das dann einfach selbst probieren. Für den Fall, dass Dein Compiler anders reagiert, vllt. auch gleich das generierte hex oder bin, das findet man doch bestimmt irgendwo in den Temp-Dateien?

[Henri]

Wir werden das schon rausfinden. Dass ich in der ProtonBridge nochmal was geändert habe, nachdem die bidirektionale Kommunikation ging, ist mir eigentlich nicht bewusst. Aber trotzdem kann man das mal im Auge behalten.

Wenn Du ein Minimalprogramm gemacht hast, das NICHT funktioniert, dann poste doch mal das komplette *.ino - ich werde das dann einfach selbst probieren. Für den Fall, dass Dein Compiler anders reagiert, vllt. auch gleich das generierte hex oder bin, das findet man doch bestimmt irgendwo in den Temp-Dateien?

Pardon, hatte wenig Zeit die Woche über.

Den Mini-Sketch muss ich mir erst mal wieder zusammenbasteln, weil ich den immer mehr erweitert hatte. Sollte hoffentlich dieses Wochenenede was werden. Bin sehr gespannt, ob er dann bei Dir läuft...

Mit dem Binary solltest Du wenig anfangen können, da ich ja für 8 MHz Arduino Pro Mini kompiliere und Du einen 16 MHz Nano hast. Hmmm... das wäre noch ein Ansatzpunkt... wenn ich einfach auch mal auf 16 MHz gehe. 

Viele Grüße!

Henri

[Henri]

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...

Gestern sind meine nachbestellten 3 Module gekommen. Und alle 3 von der Sorte, die ich nicht zum Laufen gebracht bekommen habe 


Die muss ich jetzt erst mal testen, ob sie mit der Original-Firmware überhaupt funktionieren. Wenn nicht, wird reklamiert.

[spika1]

Hallo,

ich habe zwei "AT-09 komp. HM-10 Bluetooth 4.0 Board BLE Low Energy Modul CC2541) Module bei Makershop bestellt.
Beide Module wurden vor den Firmware Upgrade getestet und beide reagierten auf AT Befehle.
Das Flashen mit CCLOADER und der ProtonBridge Firmware funktionierte ohne Beanstandung.

Aber dann war Feierabend.
Das Handy (Hat mind. BT4.0) konnte das Modul nicht mehr finden was aber vor den Flashen der Fall war.
Dann versuchte ich die AT Firmware CC2541hm10v540.bin zu flashen was auch ohne Probleme funktionierte.
Aber hier auch kein Erfolg.
Einige male hin und her flashen mit verschiedenen Firmware Versionen brachten keinen Erfolg.
Aber als ich die beigelegte DEMO.bin Firmware die bei der CC2541hm10v540.bin Firmware dabei war,
konnte das Handy das Modul wieder finden.
Aber trotzdem beim neuerlichen flashen mit ProtonBridge oder CC2541hm10v540.bin tat das Modul nichts
und wurde vom Handy nicht mehr gefunden.
Außerdem hat das originale HM10 Modul zusätzlich einen Resonator das bei diesen Modul nicht
bestückt ist.

Meine Vermutung ist das das Modul ein Clone vom Clone ist, weil ursprünglich zeigte das Handy mit der originalen BT Firmware den BT Namen "BT05" an.
Also die momentane verkaufte Serie ist nicht zu gebrauchen.
Weil ich ja leidenschaftlicher Bastler bin und schon einige Komponenten und Bauteile aus China bestellt habe,
ist meine Erfahrung das die Qualität sehr schlecht ist.
RF-Schalter Chip die vor den Einbau Durchgang hatten, Transistoren mit schlechtere Specs und auch ST Mikrochips die sich nur sehr langsam oder gar nicht flashen liesen. Das Originale hingegen Blitzschnell.

Chips und Bauteile die verkauft werden sind oft Ausschüsse aus der laufenden Produktion die einfach billig weiter verkauft werden.
Ich vermute das der Chip auch Schrott ist leider.
Habe jetzt zwei andere BT Module wo anders gekauft mit der Hoffnung das es funktioniert.

Ich habe übrigens gesehen wenn man das BT Modul mit der 5V Pro mini Variante flasht, sollte man bei den Arduino PINS D4,D5 und D6 einen 1k Widerstand vorschalten, weil der Pegel sonst zu hoch ist.



Grüße, Florian

[Henri]

Hallo Florian,

der Verdacht mit dem "Clone vom Clone" oder der Ausschussware kam mir auch schon. Man bekommt irgend was, das ja in der Regel auch funktioniert, aber man weiß halt nicht, was man da bekommen hat. Vielleicht läuft es nur mit genau der Original-Firmware, weil Teile des Flash nicht in Ordnung sind, und wenn man mehr vom Speicher nutzen möchte, kommt es zu Fehlern. Vielleicht werden vom Clone auch nicht alle Funktionen, die die Bridge benötigt, unterstützt. Am Ende war es nur noch frustrierend, weil alles sehr viel Zeit gekostet hat und nichts bei rumgekommen ist. Ein Modul habe ich ja nach einigem Hin und Her geflasht bekommen, aber bräuchte eigentlich eine modifizierte Firmware drauf, traue mich aber nicht, da noch mal beizugehen. Bei den übrigen Modulen habe ich nur Totalschaden fabriziert. Ich habe noch zwei übrig, die lasse ich unverändert, falls ich mal simple Datenübertragung über BT machen möchte. Mit verlässlicher Hardware und einem zuverlässigen Flashprozess hätte das sicher mehr Spaß gebracht, und das Projekt ist ja eigentlich auch eine geniale Sache. Aber wenn es sich nicht ohne weiteres reproduzieren lässt - im russischsprachigen Forum hatten ja auch viele andere Leute Probleme.

Na ja, und dann kam auch noch der RadiaCode-101 - und damit kann jede Selbstbastellösung eh nicht mithalten.

Jedenfalls wünsche ich Dir viel Erfolg und gutes Gelingen!

Henri

[DG0MG]

Das Handy (Hat mind. BT4.0) konnte das Modul nicht mehr finden was aber vor den Flashen der Fall war.

Möglicherweise hast Du alles richtig gemacht und gehst nur von falschen Annahmen aus.
Nach dem Flashen musst Du die ATOM-Fast-App installieren und MIT DIESER nach Geräten suchen!
Da sollte dann ein ATOM FAST erscheinen, mit dem Du dich verbinden kannst.

[spika1]

Hallo,

ich habe es jetzt geschafft mit den neu bestellten BT Modulen mit den Programm CCLOADER die Firmware
ProtonBridge.bin zu flashen.
Bin dabei auf manche Dinge Aufmerksam geworden:
Mir scheint das flashen gelingt nur gut wenn vorher die CC2541hm10v540.bin Firmware darauf ist.
Nicht mit jeden Adruino gelang mir das flashen.
Die Firmware wurde ohne Fehler zwar auf das BT Modul geflasht aber das Modul funktionierte nicht.
Das Handy konnte das BT Modul nicht finden.

Erst mit meinen Arduino MEGA2560 R3 funktionierte es.
Das BT Modul wurde immer mit 5V versorgt.

Die jetzigen neuen BT Module melden sich vor den flashen  mit den Namen JDY08.
Und diese Module hatten ein anderes Pinning!
Die RX/TX Leitungen funktionierten nicht, weil diese PINS von der Trägerplatine mit
andere PINS mit den CC2541 Chip verbunden waren!

Für die Kommunikation zwischen BT Modul und Arduino benutzte ich den letzten Sketch im russischen Forum.
Konnte die Zeile mit den Umrechnungsfaktor für den Search und Measure Modus herausfinden.
Im Measure Modus wird sogar die CPM und CPS richtig angezeigt!
Im Suchmodus wird zwar der Messwert richtig angezeigt aber dafür sind die cpm falsch und cps geht gar nicht ,immer null.

Hat von euch einen kompletten Sketch (kein Ausschnitt davon) mit dem alles funktioniert bzw einfach den
Kalabrier Faktor verändern kann?
Möchte es momentan für eine SI22G oder SBM20 verwenden.

Für den Testaufbau benutze ich eine SBM20, JDY08 BT Modul, Arduino Pro mini 8Mhz 3.3V und Theremino Hochspannungsmodul.


Grüße, Florian

[Henri]

Hallo Florian,

toll, dass Du Erfolg hattest!

Ich habe mich immer gefragt, ob der ccloader überhaupt ein Feedback vom BT-Modul bekommt, dass korrekt geflasht wurde. Also am Ende z.B. mal eine Checksum prüft. Oder ob er einfach blödes bitbanging macht, unabhängig davon, ob ihm überhaupt jemand zuhört. Ich habe den Verdacht, dass letzteres der Fall ist. Er bekommt ja mit, ob es ein target gibt, aber das ist glaube ich das einzige, was er prüft.

Mit den RX/TX pins: das ist interessant!! Kannst Du da vielleicht Fotos zu hochladen, welche Pins man statt dessen nehmen soll? Mich würde interessieren, wie Deine Module genau aussehen und welche Pins Du dann genutzt hast.

Schade, kurz bevor Du Dich hier gemeldet hast, habe ich meinen "Atom Poor" ausgeschlachtet. Hätte ich mal noch ein paar Wochen gewartet...

Viele Grüße!

Henri


PS: ich glaube mich aber zu erinnern, dass ich sogar nach Datenblatt des Chips vom Chip-Pin bis zur Pfostenleiste durchgemessen hatte damals. Also ist der Chip ein anderer, als sein Aufdruck angibt??

[DG0MG]

Hat von euch einen kompletten Sketch (kein Ausschnitt davon) mit dem alles funktioniert bzw einfach den
Kalabrier Faktor verändern kann?

Hier mein letzter Stand, der aber auch nicht perfekt ist (AtomPoor.ZIP). Aber jede weitere Arbeit daran wurde dann durch die Verfügbarkeit des RadiaCode-101 ad absurdum geführt - wo alles das, was man hier mit mehreren Krücken macht, einfach schon perfekt funktioniert. Dazu kommt die etwas - nuja - eigenartige Arithmetik in der App, die man leider so nehmen muss, wie sie ist und nicht ändern kann. Meine Motivation war ausschließlich das Nutzen der Mappingfunktion.

Einen Vorteil hat die Atom-Fast-App ggü. dem RadiaCode: Die Systemanforderungen sind niedriger. Mein BastelAndroid, auf dem die AtomFast-App läuft, geht mit der RC-App nicht.

Ich benutzte einen Arduino nano, also werden vmtl. ein paar Anpassungen (Pins?) nötig sein.
Mein Messsensor waren 6 SBM-19 (Beta-Sonde POLON SGB-3P), die natürlich eine erheblich höhere Impulsrate liefern, als ein einzelnes SBM-20. Für gute Ortsauflösung muss die Messzeit kurz sein. Ich messe nur 1 Sekunde lang und ermittele dann über die letzten 4 Sekunden den Messwert.

[spika1]

Hallo Henri,

Danke! 

Ich habe mich immer gefragt, ob der ccloader überhaupt ein Feedback vom BT-Modul bekommt, dass korrekt geflasht wurde. Also am Ende z.B. mal eine Checksum prüft. Oder ob er einfach blödes bitbanging macht, unabhängig davon, ob ihm überhaupt jemand zuhört. Ich habe den Verdacht, dass letzteres der Fall ist. Er bekommt ja mit, ob es ein target gibt, aber das ist glaube ich das einzige, was er prüft.

Mit den RX/TX pins: das ist interessant!! Kannst Du da vielleicht Fotos zu hochladen, welche Pins man statt dessen nehmen soll? Mich würde interessieren, wie Deine Module genau aussehen und welche Pins Du dann genutzt hast.

ich glaube auch das CCLOADER nicht überprüft ob der Chip erfolgreich geflasht wurde.

Wegen der RX/TX Leitung:
Also wie gesagt die original RX/TX Anschlüsse haben bei mir nicht funktioniert wegen anderes pinning.
Auf den Foto unten siehst du einen gelben und grünen Draht.
Gelb= TX zu (RX Arduino)
Grün= RX zu (TX Arduino)

Dann funktioniert das Modul.

Ich habe das letze BT Modul ohne Trägerplatine und zwei mit Trägerplatine gekauft.



Grüße, Florian

[Henri]

Hallo Florian,

Danke für die Fotos!

Ich hatte meine Module ohne Trägerplatine gekauft. Die sahen zwar etwas anders aus als bei Dir (länger), haben allerdings den selben Chip verbaut, den ich nicht programmiert bekommen habe. Der eine Chip, den ich programmieren konnte, sah ein wenig anders aus. Vielleicht schaue ich mir das doch noch mal an... wäre ja nicht das erste Mal, dass ein Datenblatt falsch ist.

Viele Grüße!

Henri