Schaltung mit SBM-20 Zählrohr

[DG0MG]

Ich glaub die Spule hat garkeinen Kern. Oder woran sehe ich das? Ist diese hier:

Dochdoch, 15 Millihenry als Luftspule wären ja ungleich größer vielleicht 1 oder 2 Meter im Durchmesser.
Der kleine Kern sieht wie eine Garnspule aus: oben und unten eine Scheibe, auf den Zylinder dazwischen ist dann der Draht gewickelt. Der wird extrem dünn sein, sonst würden nicht 28 Ohm Gleichstromwiderstand entstehen.

[DO1MUE]

So, nach einem halben Jahr Arbeit bin ich nun bei einer Art finalem Design angekommen. Sieht nun nicht mehr ganz so erbärmlich dilettantisch aus wie noch am Anfang  .

Was ganz interessant ist: der Tausch von 1N4007 zu UF4007 (siehe dieser Beitrag) erhöhte die Spannung schlagartig von ca. 390V auf ca. 470V, bei ansonsten gleichen Parametern und Bauteilwerten.

Somit wäre es das wohl an der Stelle. Danke nochmal an Alle die mir gute Tipps gegeben haben  .

[NuclearPhoenix]

Ja sehr schön. Damit wäre das Problem an der Spannungsversorgung ja gelöst

Rein aus interesse: Was hast du denn jetzt noch an der Platine geändert, dass es besser funktioniert im Gegensatz zur letzten Version?

[DO1MUE]

Hallo NuclearPhoenix. Danke für dein Interesse.

Hab mehrere Sachen geändert, manche Maßnahmen haben wohl mehr, manche weniger Einfluss:
- PullUp-Widerstand für den "Zählkreis" mit BC337 ist jetzt intern
- Leitungen sind so kurz wie möglich gehalten und nicht mehr tw. konfus über die ganze Platine geführt
- gibt zwar noch eine Massefläche auf der Rückseite, Isolationsabstände sind nun aber nochmals vergrößert

Klar ich brauch noch ein paar Langzeittests um die Tauglichkeit abzuschätzen.

Generell ist das LCD relativ empfindlich, das steigt gelegentlich mal aus (bei meinem alten Design andauernd, jetzt nur noch sehr sporadisch). Kommen dann nur noch wirre Zeichen. Ich hab keine Idee ob das irgendwie ein EMV-Problem am I2C ist/war, oder ob das eher was mit einer unstabilen Versorgung zu tun hat (+5V von USB).

Falls jemand was weiß, ist dieses Teil:
https://cdn-reichelt.de/documents/datenblatt/A300/SBC-LCD16X2_DB.pdf

[NuclearPhoenix]

Generell ist das LCD relativ empfindlich, das steigt gelegentlich mal aus (bei meinem alten Design andauernd, jetzt nur noch sehr sporadisch). Kommen dann nur noch wirre Zeichen. Ich hab keine Idee ob das irgendwie ein EMV-Problem am I2C ist/war, oder ob das eher was mit einer unstabilen Versorgung zu tun hat (+5V von USB).

Hast du auch Pull-Up Widerstände an den beiden SCA und SCL Pins? Die braucht man nämlich für I2C. Ansonsten klingt das ehrlich gesagt eher nach einem Software-Problem. Vorausgesetzt natürlich die Versorgungsspannung ist halbwegs OK, aber das kann man ja prüfen.

[DO1MUE]

Hm. Eigentlich ist das Alles nur copy&paste aus den Pico Beispielen, mit minimalen Anpassungen:

https://github.com/raspberrypi/pico-examples/tree/master/i2c/lcd_1602_i2c

GP4 SDA, GP5 SCL. Meine Vermutungen ist da kommt irgendein EMV-"Dreck" über den I2C. Lässt sich nur mit einem harten Reset beheben (Aus-/Einschalten).

Aber schlecht reproduzierbar diese Aussetzer.

[NuclearPhoenix]

Hm, verstehe. Vielleicht kannst du trotzdem mal versuchen von SCL und SDA jeweils einen 10k Widerstand auf VCC (3V3) zu hängen. Möglicherweise hilft das doch noch etwas.

[DO1MUE]

Also ich hab das Ding gestern mal den ganzen Tag laufen lassen (auch draußen in der feuchten Kälte), und konnte keinen Fehler mehr reproduzieren. Was wohl ein Indikator dafür ist dass der Prototyp jetzt ein akzeptables Design hat. 

Normalerweise favorisiere ich ja ohnehin OLEDs. Aber da sind selbst die winzigen Displays doppelt so teuer verglichen mit den Standard-LCDs. Wobei das LCD aufgrund der permanent angeschalteten Hintergrundbeleuchtung wiederum schlecht ist was den Verbrauch von Batteriestrom betrifft.

Die Regelung läuft ein wenig aus dem Ruder wenn ich die Anode auf der Unterseite gezielt mit Wasser besprühe. Das fängt sich allerdings schnell wieder bzw. verursacht nur kurz Fehlfunktionen. Den Prototypen müsste man mal den ganzen Tag eingeschaltet in eine Klimakammer bei feuchter Wärme legen, wäre interessant was da passiert.

Hier mal noch alle Erkenntnisse in einem kurzen Video zusammengefasst, falls es wen es interessiert.

[DO1MUE]

Hm, verstehe. Vielleicht kannst du trotzdem mal versuchen von SCL und SDA jeweils einen 10k Widerstand auf VCC (3V3) zu hängen. Möglicherweise hilft das doch noch etwas.

Hattest du schon einmal Auffälligkeiten bei deinen Platinen bei Verwendung der internen PullUps für den I2C?

Bin grad mit einem anderen Projekt beschäftigt, und offenbar sind die internen PullUps (lt. Doku 50k-80k) für den I2C generell ungeeignet (da zu groß).

Greife ich auf externe PullUps im Bereich 5k zurück scheint das die Probleme mit dem I2C aus der Welt zu schaffen. Kann auch der Fall für das Display mit den sporadischen Ausfällen sein.

Moin, wegen dem "Pfeifen" der Spule:
Versuche doch mal das Teil in Gießharz einzugießen.

Auch das hab ich mittlerweile mal ausprobiert. PU500 Polyurethan Gießharz. PCB sieht jetzt nicht mehr schön aus, aber Spule ist einigermaßen "umkapselt". Leider ist das Piepen kaum leiser. Macht aber nichts, da ich ja jetzt mit Diode UF4007 auch >10 kHz gehen kann.

[NuclearPhoenix]

Hattest du schon einmal Auffälligkeiten bei deinen Platinen bei Verwendung der internen PullUps für den I2C?

Bin grad mit einem anderen Projekt beschäftigt, und offenbar sind die internen PullUps (lt. Doku 50k-80k) für den I2C generell ungeeignet (da zu groß).

Greife ich auf externe PullUps im Bereich 5k zurück scheint das die Probleme mit dem I2C aus der Welt zu schaffen. Kann auch der Fall für das Display mit den sporadischen Ausfällen sein.

Bei Platinen speziell nicht, aber generell hatte ich das schon ein paar mal, dass es zu instabil läuft ohne Pull-Up Widerstände. Ich verwende immer 10k und dann hat sich das erledigt.

[DO1MUE]

Hier noch mal ein neuerer Stand meines GZ, mit ein paar Verbesserungen.

Will aber nicht nur ein Video posten sondern habe auch ein, zwei Fragen.

Ich messe mit dem Multimeter 30 mA Stromaufnahme. Das scheint mir ein wenig verschwenderisch - selbst wenn ich das Display abklemme sind es immer noch etwa 25 mA. Auch die PWM (GP3) scheint keinen Einfluss zu haben; mit 1 kHz selber Verbrauch wie mit 10 kHz (klar, Multimetermessung ist ungenau aber grob kann man es schon einschätzen).

Irgendeinen Ratschlag wie man den Stromverbrauch senken könnte? Ich hätte es evtl. mit einem 4V Spannungsregler statt dem 5V und kleinerer Batterie versucht; im Prinzip benötigt der ganze Aufbau ja nur 3.3V. Die HV würde mit der Maßnahme etwas geringer werden aber das kann man sicher über Frequenz und TG wieder anpassen.

Dann gibt es was komplett Neues - IoT Fähigkeit via BLE (Bluetooth Low Energy). Was mich ziemlich überrascht hat: kaum ein Bastler scheint BLE zu nutzen, womit ich mich entsprechend hart tue Codebeispiele und Projekte zu finden. Auch professionelle Geräte scheinen eher nicht über Bluetooth zu verfügen (nur die sehr teuren?). Warum das so ist kann ich mir nicht so wirklich erklären, ist ja eigentlich äußerst komfortabel wenn man mal verstanden hat wie man es benutzt bzw. implementiert.

Vielleicht habt ihr ja eine Idee.

Grüße und schönes Wochenende.

[DL3HRT]

Irgendeinen Ratschlag wie man den Stromverbrauch senken könnte?

Auf jeden Fall solltest du den 7805 gegen einen Regler mit geringer Ruhestromaufnahme ersetzen. Der 7805 braucht alleine ca. 5 mA ... 6 mA. Der LP2950 beispielsweise hat eine Ruhestromaufnahme von ca. 100 µA und kostet bei Reichelt (Best.-Nr: LP 2950 ACZ5,0) 60 Cent.

Noch besser wäre es natürlich, wenn du einen Schaltregler einsetzt. Bei Speisung aus einem 9 V Block werden in deiner Schaltung 4 V * 0,03 A = 0,12 W in Wärme umgesetzt.

Der Rest ist Softwaresache:
- Taktfrequenz des Controllers reduzieren
- Sleep-Modus verwenden

Ich habe in einem Versuchsaufbau mit einem Arduino Nano mit angeschlossenem Nokia 5110 Display bei Speisung aus einer 1,5V AA-Batterie mit nachgeschaltetem Stepup-Wandler eine mittlere Stromaufnahme von deutlich weniger als 2 mA aus der 1,5 V Batterie (normale Hintergrundstrahlung und Displaybeleuchtung aus).

Das Nokia-Display hat eine Stromaufnahme von 250 µA und der Controller ist die meiste Zeit im Schlafmodus.

Was mich ziemlich überrascht hat: kaum ein Bastler scheint BLE zu nutzen, womit ich mich entsprechend hart tue Codebeispiele und Projekte zu finden.

Das möchte ich so nicht stehen lassen. Alleine schon die Beispiele in der Arduino-IDE decken die meisten Anwendungsfälle ab und sind gut geeignet, sich in BLE einzuarbeiten.

[DO1MUE]

Danke für die Infos zu den Spannungsreglern, das war mir so nicht wirklich bewusst.

Das möchte ich so nicht stehen lassen. Alleine schon die Beispiele in der Arduino-IDE decken die meisten Anwendungsfälle ab und sind gut geeignet, sich in BLE einzuarbeiten.

Puh, ja das mag schon sein. Arduino hab ich nie benutzt.

Eine Menge Theorie und generische Beispiele gibt es tatsächlich, praktische Projekte im Bastler Umfeld sind ganz offensichtlich rar gesät. Vielleicht hat auch einfach niemand das Bedürfnis seine Erkenntnisse zu teilen  .

Vielleicht liegt es auch am Baustein den ich nutze - RN4870. Wohl nicht sehr verbreitet, zumindest auf YT gibt es kaum was dazu. Was merkwürdig ist, vielmehr wie ein bisschen ASCII Kommandos auf UART ist es ja eigentlich nicht.

[DL3HRT]

RN4870. Wohl nicht sehr verbreitet, zumindest auf YT gibt es kaum was dazu. Was merkwürdig ist, vielmehr wie ein bisschen ASCII Kommandos auf UART ist es ja eigentlich nicht.

Solltest du mit dem letzten Satz BLE meinen, so liegst du komplett falsch. Außer dem Frequenzbereich hat es mit dem herkömmlichen Bluetooth so gut wie gar nichts gemein.

[DO1MUE]

Nein, ich meine eigentlich die Konfiguration des RN4870 selbst. Also z. B. UUIDs für Private Characteristics definieren, Firmware auslesen, etc. Soweit bin ich schon. Das ist ziemlich einfach sogar.

Womit ich mich noch etwas schwer tue ist eine Menge Sensordaten hin- und herzuschicken. Dazu ist meine SW noch nicht in der Lage. Da wäre es wohl hilfreich Code von anderen Projekten als Beispiel vor sich zu haben.

Für mich die einzig wirklich brauchbare Info-Quelle ist jener 5 Jahre alter Blogbeitrag.

http://www.martyncurrey.com/arduino-with-rn48701/#more-7328

Interessant wird es im Text eigentlich erst weiter unten, wo er via Transparent UART Services (zu erkennen an der charakteristischen UUID, der Autor erwähnt das so nicht explizit) willkürliche Daten austauscht.