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

[Henri]

So, heute ist tatsächlich schon mein AT-09 angekommen! Habe mich natürlich gleich ans Basteln gemacht

Die protonbridge.bin habe ich unter Linux mit dem selbstkompilierten ccloader versucht aufzuspielen. Hat erst mal aber überhaupt nicht geklappt. Der USB-Port wird noch richtig erkannt, dann passiert nichts mehr und der loader hängt bei "Waiting for respond". Also alles 33x kontrolliert, Verbindungen durchgemessen und Foren geflöht. Als "Programmer" hatte ich zuerst einen 3.3V Pro Mini genommen. Allerdings liefert der zum Anschluss nötige FTDI-Adapter nur 50mA, was wohl zu wenig sein soll. Also einen Nano genommen mit Level Shiftern. Nichts. Dann wurde ich ungeduldig und habe einfach alles an 5V geklemmt, wie DG0MG. Nichts. Dann hatte ich in einem Forum gelesen, dass jemand mit einem Mega 2560 gute Erfolge hatte. Ich nicht. Habe dann den Vorgang noch 3, 4 Mal angestoßen, und da... hat er angefangen zu programmieren! Schön sauber alle 512 Blocks durch, am Ende: "Program successfully! File closed!"

Warum das zuerst nicht funktioniert hatte? Keine Ahnung!

Und dann der Test: das AT-09 wird von der App nicht gefunden. Tja.

Beim Power-up blitzt einmal ganz kurz die LED auf dem Modul auf, dann passiert nichts mehr. Bei der Original-Firmware hatte sie noch geblinkt, um zu signalisieren, dass das Modul bereit ist, sich zu paaren. Soll das auch bei der neuen Firmware so sein?

Tja, vielleicht mache ich mich morgen noch mal ans Werk.

Viele Grüße!

Henri

[DG0MG]

So, heute ist tatsächlich schon mein AT-09 angekommen! Habe mich natürlich gleich ans Basteln gemacht

Hattest Du auch bei MAKERSHOP bestellt?

Beim Power-up blitzt einmal ganz kurz die LED auf dem Modul auf, dann passiert nichts mehr. Bei der Original-Firmware hatte sie noch geblinkt, um zu signalisieren, dass das Modul bereit ist, sich zu paaren. Soll das auch bei der neuen Firmware so sein?

Ja, das veränderte Blinkverhalten der LED ist bei mir auch so. Die ist immer aus, nur beim einem Koppelversuch blitzt sie kurz auf.

[Henri]

Hattest Du auch bei MAKERSHOP bestellt?

Nee, dafür war ich zu geizig

Ich habe grade noch mal rumprobiert.
Interessanterweise habe ich rausgefunden, dass der Befehl zum Flashen so lange hängt, bis man statt der "0" am Ende des Aufrufs eine "1" eingibt. Das nächste Mal, wenn man dann erneut mit "0" aufruft, startet der Flashvorgang meist. Eigentlich stellt man mit "0" oder "1" nur zwischen Arduino Uno und Leonardo um...

Tja, ein erneutes Flashen brachte nichts. Also habe ich erst die Firmware des chinesischen Herstellers zurückgeflasht (aber das Modul meldet sich nicht). Danach die Original HT-10 Firmware, aber auch erfolglos.

Ich habe ja den Verdacht, dass der "Arduino Programmer" gar nicht kontrolliert, ob etwas korrekt geschrieben wurde. Wenn es einen Schreibfehler gab, gab es halt einen Fehler. Jedenfalls hatte die LED geblinkt, als ich das Modul neu bekommen hatte, und jetzt tut sie gar nichts, selbst wenn eine der "Original-Firmwares" wieder drauf ist.
Vielleicht geht der Programmiervorgang unter Linux einfach nicht verlässlich.

Und dann kam mir noch ein Verdacht: nach dem ersten Flashen hatte ich das Modul, ohne vorher zu testen, gleich an RX/TX des Arduino angeschlossen. Blöder Fehler, denn darüber wird der Arduino ja auch programmiert. Und dann versucht, einen neuen Sketch auf den Arduino aufzuspielen. Da ist dann also "Datensalat" auf dem seriellen Eingang des AT-09 gelandet, vielleicht hat sich dadurch ja was verkonfiguriert. Mich wundert nur, dass sich das durch Neuflashen der Firmware nicht beheben lässt.

Was mir auch noch aufgefallen ist: dass die auf dem AT-09 angegebenen 3.6V Mindestspannung kaum reichen dürften. Denn die müssen erst durch eine 1N4148 Diode und dann noch mal durch einen LDO-Regler. Bei 3.6V Eingangsspannung kommen weit unter 3V am Eingang des Submoduls an. Ich finde das ziemlich unpraktisch und überlege, ob ich mir noch noch ein AT-09 Modul ohne Trägerboard kommen lasse. Das ist nicht nur kompakter, sondern kann auch viel einfacher an einen 3.3V Arduino gekoppelt werden.

Viele Grüße!

Henri

[Henri]

So, ich lasse mir jetzt noch mal zwei von den Modulen kommen, aber ohne das Basisboard mit dem Spannungsregler. Gibt es leider nur direkt aus China, wird also wieder ein Weilchen dauern.


Die App habe ich mir mittlerweile mal angeschaut und finde sie auch gar nicht schlecht, wenn man mal davon absieht, dass sie für sich das (nicht abschaltbare) Recht einfordert, nach Hause telefonieren zu dürfen. Ziemlich frech, weil der Atom Fast ja nur mit dieser App funktioniert. Dass die Kartenmappingfunktion nur mit den Google Play Services läuft und man auch noch ständig Netz benötigt, überzeugt mich aber nicht so sehr. Deshalb werde ich lieber mal ein bisschen mit qfield https://qfield.org/ rumspielen und schauen, ob man damit so was ähnliches hinbekommt. Das kann mit auf dem Gerät gespeicherten Karten umgehen.

Was mir auch nicht so gut gefällt: dass immer nur 2-Sekunden-Messwerte in der App dargestellt werden. Die Messstatistik ist also bei "normalen" Dosisleistungen ziemlich schlecht (im Demomodus bei 2-Sigma ca. +/- 50%...). Da die App aber bereits fertige Messwerte vom Gerät erwartet, kann man das bei einer Selbstbastellösung "faken" und in Wirklichkeit Daten aus einem gleitenden Mittelwert an die App schicken (der dann aber natürlich auch träger ist). Dann macht aber die Unterscheidung zwischen Such- und Präzisionsmesssfunktion wieder nicht so viel Sinn... Es wäre besser, wenn man in der App konfigurieren könnte, wie lange die Messintervalle sein sollen, oder noch besser, wie viel Messungenauigkeit man akzeptieren möchte. Na ja, kommt ja vielleicht noch 

[DG0MG]

Ich bin jetzt auch an ein Problem geraten.

Inzwischen hatte ich eine einfache Impulszählroutine mit Interrupt installiert, deren Zählwert alle halbe Sekunde ausgelesen und der eigentliche Messwert über solche 10 Messungen ermittelt wird. Dieser dann mit einem Kalibrierfaktor multipliziert und als Dosisleistung gesendet und in der App angezeigt.

Nächstes Ziel war die umgekehrte Datenrichtung.
Also irgendeine Information aus der App soll in den Arduino geschickt werden und dort etwas bewirken. Man kann in der App den Ticker des ATOM FAST auf "Aus", "Ticks" und "Beeps" einstellen. Das muss also der Weg aus dem Handy heraus in Richtung Arduino sein. Beim Studium des "ATOMSERVICE BLE"-Dokuments (oben verlinkt) findet man Variablen für die Tonhöhe des Beeps in Hz und die Länge in ms. Ich gehe also davon aus, dass die App diese Werte ändert. Der Arduino muss also aus dem AT-09-Modul eine Variable LESEN, bisher haben wir nur welche GESCHRIEBEN. Dazu soll man zuerst den Lesebefehl (0xB0), dann das zu lesende Register (hier "Parameter #1", 0x51) senden und das AT-09 soll dann mit dem Inhalt der Variable antworten (in diesem Fall 2 Byte). Ich hatte zuerst versucht, diesen empfangenen Wert als Phantasie-Dosisleistung wiederum zum Smartphone zurück zu schicken, dann hätte eine Veränderung des "Tick"-Schalters die Anzeige der zugehörigen Zahlenwerte als Dosisleistung verursacht - das hat aber nicht geklappt. Bis ich nach einiger Fehlersuche und Oszillografieren drauf kam, dass das AT-09 *NIEMALS* überhaupt irgendetwas per UART sendet. Der Pegel des TxD-Anschlusses bleibt unverändert "High". Das Problem ist erstmal, dass bisher noch niemand öffentlich bestätigt hat, dass das überhaupt geht. Der Beispielcode von Nikita71 SENDET auch nur Daten.

Die Frage ist nun:

• ist das AT-09-Modul, speziell der TxD-Anschluss, der direkt vom CC2541 kommt, defekt? (ist immer "High")
• ist mein Wunsch, die Daten der Variable 0x53 haben zu wollen nur "falsch formuliert", so dass die Protonbridge nicht reagiert?
• ist das ein Problem innerhalb der Software Protonbridge.bin?

Ich muss wohl auch einen neuen AT-09 flashen, um zumindest die erste Fehlerquelle auszuschließen.

[Henri]

Hmmm also aus dem Bauch raus würde ich ja die protonbridge.bin im Verdacht haben. Quelltext gibt es nicht? Die Software ist eh noch nicht ganz fertig, und ich vermute, dass die bidirektionale Kommunikation gar nicht auf dem Schirm hatten. Die Bridge ist ja da, um die App mit einem beliebigen Detektor zu betreiben, der kein Atom* ist, also gibt es detektorseitig normalerweise nichts, was man konfigurieren sollen müsste.  Praktisch wäre es natürlich trotzdem

[DG0MG]

Dochdoch, "Syph3r" beschreibt das ja, sowohl das Lesen wie auch das Schreiben von Variablen von der Arduino-Seite.

[Henri]

Ach OK? Dann bin ich ja mal gespannt, ob es nicht doch am Modul liegt. Vielleicht sind die ja doch nicht so 5V tolerant...

Frag doch mal freundlich an, ob Du vielleicht den Quelltext bekommen kannst. Das macht das Debuggen viel einfacher.

[DG0MG]

Nach einigem Überlegen hab ich erstmal an anderer Stelle weiterprobiert. Wir haben ja festgestellt, dass es definitiv "nicht optimal" ist, einen 3,3V-Chip mit 5V-Signalen aus einem Arduino zu beaufschlagen. Wenn man aber rumliest, dann machen das ziemlich viele Leute so und die Quote der dadurch defekten ICs scheint also relativ gering zu sein.
Hier https://forum.arduino.cc/index.php?topic=393655.msg4552963#msg4552963 schlägt einer vor, wenigstens 3 1k-Widerstände in die Programmierleitungen einzufügen, um die internen Schottky-Dioden an den Pins des CC2541 zu schützen.

Gut.
Ich hatte also folgenden Stand: Signale vom Arduino in das AT-09 hinein funktionierten, aber vom AT-09 kam nie ein serielles Byte zum Arduino. Es hätte also sein können, der TxD-Anschluss des CC2541 ist defekt. Um das zu überprüfen, gabs ne Rolle rückwärts: Es sollte erstmal wieder die HM-10-Software in das Modul, damit man mit ihm per Textkommandos reden kann, sofern das überhaupt noch geht.
Ich habe diese Firmware genommen: http://www.hangar42.nl/wp-content/uploads/2017/10/CC2541hm10v540.bin_.zip
Die lässt sich auch wieder mit der CCLoader.exe flashen und danach sieht man am langsamen Blinken der LED, dass sich das Modul jetzt anders verhält. Eine Kommunikation mit dem PC hab ich erstmal ebenfalls nicht hinbekommen - es kam auf das Senden von "AT" nie ein "OK" zurück. Sah also tatsächlich so aus, als ob keine Daten mehr rauskommen.
Aber erstnochmal den ganzen Thread https://forum.arduino.cc/index.php?topic=393655.0 gelesen. Tatsächlich jammern dort auch ein Haufen Leute, dass zwar das Firmwareupgrade geklappt hätte, danach aber die AT-Befehle nicht mehr gingen. Da bin ich also nicht allein.

Diverse Lösungsansätze dafür sind:

• Arduino-IDE Seriellen Monitor mit 9600Bd und KEIN ZEILENENDE verwenden
• ENABLE-Anschluss dauerhaft oder während des Einschaltens auf High setzen
• Das Modul darf nicht mit einem anderen Gerät gekoppelt sein (BT am Smarphone aus!)
  
• nicht "at" sondern wirklich "AT" senden!

Letzteres konnte ich verifizieren: Nach einigem rumprobieren hab ich irgendwann mal wieder ein "OK" vom Modul bekommen, auf "AT" reagiert es, auf "at" nicht. Man muss auch alles anzweifeln: Die Eigenheiten, die das Modul namens AT-09 (=Clone) direkt nach dem Kauf hat, sind nach dem Flashen der originalen HM-10-Firmware anders!

Aber damit war bewiesen, dass das Modul nicht defekt ist.

Ich muss also dochmal den Protonbridge-Autor fragen.

[Henri]

Ach, das ist ja super!

Ja, den Thread zur "Original-Firmware" hatte ich auch gelesen und nach meinen erfolglosen Versuchen  zwei Firmwares wieder zurückgeflasht: einmal die vom chinesischen Lieferanten, und dann noch mal die "Original" HM-10 Firmware. AT-Kommandos hatte ich allerdings gar nicht probiert, sondern nur geschaut, ob die Module ein Bluetooth Signal aussenden - das sollten sie ja eigentlich tun, selbst wenn sie nirgendwo angeschlossen sind. Da kam bei mir aber nichts. Ich glaube, die LED wollte auch nicht mehr blinken.

Ich habe den Verdacht,
- dass es einen nicht-flüchtigen Konfigurationsspeicher gibt, der selbst durch das Aufspielen einer neuen Firmware erhalten bleibt
- oder dass der Programmer unter Linux Fehler produziert und deshalb keinen fehlerfreien Flash-Vorgang machen kann.

Die Frage ist: wie macht man einen kompletten "Factory Reset"?

Sobald meine Module da sind, werde ich noch mal eines flashen und dann sehr vorsichtig sein, wass ich über die AT-Schnittstelle sende. Geht es dann immer noch nicht, muss wohl irgendwo ein Windows-PC her...

[DG0MG]

Probiere mal die von mir verlinkte (alte) HM-10-Software V 5.40.  Ich hab auch einige andere Varianten probiert, die gingen alle nicht los - ich hab das an einer nur glimmenden roten LED festgemacht. Auch mehrmals hin und her geflasht und probiert, das blieb so: eine 6.09 und eine 7.09 ging nicht, obwohl ich der Meinung bin, dass die auch gehen müsste.

Welche Version "vom chinesischen Lieferanten" hast Du verwendet (Link)?
Die AT-09 Software habe ich nicht gefunden.

[Henri]

Welche Version "vom chinesischen Lieferanten" hast Du verwendet (Link)?

Ich hatte befürchtet, dass Du das fragen würdest 

Am Ende war ich so frustriert, dass ich einfach nur 1000 Sachen aus den Foren ausprobiert habe. Die Software habe ich mir runtergeladen, aber leider keinen Link gesetzt. Ich weiß nicht mal mehr, ob das noch die hmsoft.bin ist, die ich auf dem Rechner gespeichert habe, oder ob das CC2541hm10v540.bin ist, die ich auch noch hier rumliegen habe.

Vielleicht war es dieser Thread hier: https://forum.arduino.cc/index.php?topic=393655.0

Die Firmware des Herstellers würde sich hiernach dort herunterladen lassen:  http://www.jnhuamao.cn/download_rom_en.asp?id=66#


Ich probier mal, ob ich mein Modul mit Deiner Version wieder zum Blinken bringen kann 

[Henri]

Probiere mal die von mir verlinkte (alte) HM-10-Software V 5.40.  Ich hab auch einige andere Varianten probiert, die gingen alle nicht los - ich hab das an einer nur glimmenden roten LED festgemacht. Auch mehrmals hin und her geflasht und probiert, das blieb so: eine 6.09 und eine 7.09 ging nicht, obwohl ich der Meinung bin, dass die auch gehen müsste.

Hmmm jetzt war ich so neugierig, dass ich gleich mal die von Dir verlinkte Software aufgespielt habe. Aber leider... ich habe weniger Glück als Du. Bei mir blinkt leider gar nichts 

Aber immerhin habe ich jetzt eine Lösung gefunden zu meinem Problem, dass der Programmiervorgang erst beim 30. Versuch starten will. Das Problem war wohl die RESET-Leitung am Arduino:

https://forum.arduino.cc/index.php?topic=393655.msg2937926#msg2937926

Zwischen RESET und GND einen 10µF Elko anschliessen, dann startet das Programmieren gleich.

Die Firmware funktioniert danach allerdings immer noch nicht 

[DG0MG]

Okay, das ist schade, aber einen Versuch wert gewesen.

Die Firmware des Herstellers würde sich hiernach dort herunterladen lassen:  http://www.jnhuamao.cn/download_rom_en.asp?id=66#

Hm, ja, das sind die Firmwaren des Original-HM-10 Herstellers. Die sollen sich wohl nicht oder nicht so einfach oder nicht alle verwenden lassen, weil sie auf einen bereits im HM10-Modul befindlichen Bootloader aufsetzen und diesen deshalb selber nicht enthalten. Will man aber ein AT-09 zu einem HM-10 machen, braucht man eine Firmware, die den Bootloader enthält.

Ich dachte, Du hättest vielleicht die Software gefunden, die in den AT-09 Modulen, die wir haben (die Clones), drin ist.

[DG0MG]

Hmmm also aus dem Bauch raus würde ich ja die protonbridge.bin im Verdacht haben. Quelltext gibt es nicht? Die Software ist eh noch nicht ganz fertig, und ich vermute, dass die bidirektionale Kommunikation gar nicht auf dem Schirm hatten. Die Bridge ist ja da, um

Meine vorsichtige Frage im rhbz.org-Forum lautete zwar anders, aber Syph3r hat dankenswerterweise gleich mit den Sourcen und der kompletten 8051-Entwicklungsumgebung (Windows) geantwortet. Siehe http://forum.rhbz.org/topic.php?forum=80&topic=98&postid=1615233986#

Ich hab das installiert und kann jetzt die Sourcen übersetzen - hab aber eigentlich keine Ahnung davon