LoRa mitm ESP

Hallöle.

Interessante Aufgabenstellung: meine App fürs Bergbaumuseum soll einige Erweiterungen bekommen.
Zum Museum gehört auch ein Schaustollen...

Ich fänds nun ganz spannend, wenn auf dem Bildschirm auch die Temperatur im Stollen angezeigt würde.
Da ich, für andere Dinge, sowieso nen MQTT-Server im Hintergrund laufen lassen will, kam ich auf die Idee, hinten im Stollen nen "Wettersensor" aufzuhängen.
Nur, wie das Signal da raus kriegen? Ein Kabel ziehen verbietet sich, das sind ungefähr 200m, dann müsste es noch übern Hof...da kam mir doch die Idee, das mal mit LoRa zu versuchen.
Der Stollen ist nicht ganz gerade, aber 200m sollte man doch trotzdem überbrückt kriegen...

Hat jemand hier Erfahrung damit?
Könnte das klappen?
Was denkt ihr?

Ich hab keine Erfahrung damit aber mein erster Gedanke war, dass Du ja auf den 200m in der/den Kurve/n auch noch eine Messstation aufbauen könntest und diese leitet die Daten von der weit entfernten Station weiter? Also keine direkte Kommunikation zwischen den Endpunkten sondern über einen/mehrere Stationen in der Mitte.
Cooles Projekt!

Crypi

Die Idee hatte ich auch. Da wird aber die Stromversorgung schwierig, weil wir zwar 220V im Stollen haben (Licht usw.), aber keine Steckdosen, wo man einfach mal ein 5V-Netzteil anstecken kann.
Die würden, wegen der hohen Feuchtigkeit, auch nicht lange leben..
Das muss alles _richtig_ gut verbaut werden, wenns ne Weile halten soll.
Ne Lösung mit Akku gefällt mir nicht, den müsste _ich_ ab und zu laden (nie auf andere verlassen bei sowas), und ich würds auch öfter vergessen...
Ich denke aber, die 200m sollten machbar sein, weil der Stollen zwar nen Bogen macht, aber jetzt keine ständigen, scharfen Kurven.

Inzwischen sind hier zwei ESP34 mit anmontiertem LoRa-Chip, Oled-Displays und Antennen eingetroffen.
Mit denen werd ich mal ein wenig spielen...

Am Ende der 200m hast DU aber Strom oder wie machst Du das da?

Viel Erfolg!

Crypi

Wenn es klappt, kann ich da irgendwas abzweigen, ja.
Da sind LED-Spots, die müssen ja irgendwie versorgt werden.
Was genau wir da im Schaltkasten haben, hab ich noch nicht eruiert, die Dinger sind sehr gut verschraubt...

So- vorhin hab ich aus den beiden Dingern schnell mal zwei Funkgeräte gebastelt:

Anhang 35951

Auf dem da läuft ein Testprogramm, was mitgeliefert wurde.
Das sendet, nachdem es ein bisschen mit den verfügbaren WiFi-Netzen herumgespielt hat, einfach nur alle paar Sekunden eine Message per LoRa.
Auf dem zweiten hab ich das Programm schon eingekürzt.
Dank der Grösse der Dinger kann man sie prima rumtragen-also so ein Ding in die Hemdtasche, ne kleine Powerbank dran und dann nen Abendspaziergang gemacht.
Das Zweite war die ganze Zeit zu Hause- _im_ Haus, wohlgemerkt.
Das Testprogramm zeigt immer brav an, ob ein Paket gesendet werden konnte, und auch, was empfangen wurde.
Die grösste Entfernung zwischen beiden waren etwa 450m- da hatte ich allerdings auch Sicht auf mein Haus.
Auf 250-300m ging es auch ohne, nur nicht, wenn mehrere Gebäude dazwischen waren.
Man muss natürlich schon aufpassen, dass die Antennen so leidlich parallel zueinander sind...

Ich muss sagen: hätte ich nicht gedacht, bei so hoher Frequenz und lausigen 25mW. Ich glaub, ich nehme die Dinger morgen mal mit, und packe eins davon in den Stollen. Dank dem verbauten Display und der Möglichkeit, sie einfach mit ner Powerbank zu betreiben, sind die ja mal super zum Testen.

Nachtrag: da das ein Werks-Test-Programm war, war gar nicht die maximal mögliche (erlaubte->25mW) Sendeleistung eingestellt.
Die war nämlich im Programm gar nicht definiert, da wird dann irgendeine Voreinstellung benutzt...
Auf die Schnelle hab ich dazu im Datenblatt nix gefunden, aber eben hab ich die mal laut Anleitung eingestellt, und hab zwischen beiden noch ne deutlich höhere Feldstärke:
vorher ~ -65dB
jetzt ~ -45dB

Damit gehts noch mal besser.
Nachher Testlauf im Stollen...

So.
Das gestern war ein Fehlversuch. Es lag aber nicht an der Funk-Reichweite...
Aus irgendeinem Grund blieben die Dinger (mal das eine, mal das andere) immer wieder nach kurzer Zeit stehen...
Da es in der Konsole keinerlei Ausgaben dazu gab, kann ich das Problem auch nicht wirklich eingrenzen...
Ich hab aber einige Änderungen in der Software vorgenommen, und immerhin erreicht, dass sie definitiv länger am Stück laufen (letzte Nacht mehr als 1000 Messages erfolgreich übertragen).

Heute muss ich sowieso wieder in den Stollen, da probiere ichs noch mal.
Wenn ich dann sicher weiss, dass die Funkübertragung klappt, schreib ich alles neu, diese Beispielprograme sind ziemlicher Murks.

So.
Erneuter Test heute: die Reichweite ist grundsätzlich kein Problem.
Ne recht scharfe Kurve im Stollen- schon.
Da die Stollen recht schmal sind, kommt das Mini-Funkgerät nich um die Ecke...
Allerdings komme ich sowohl von draussen bis um die Kurve (gradeso, einige Meter weiter ist dann aber Schluss), als auch von innen.
Eine Möglichkeit wärs jetzt, an der Kurve ein weiteres Modul als Repeater einzusetzen- glücklicherweise gibts da sogar ne Steckdose, wäre also machbar.
Aber ich experimentiere erst noch ein bisschen..zwar bin ich jetzt bei der maximal erlaubten Sendeleistung, aber noch nicht beim vollen Spreading- wenn ich das auf 12 setze, laufen die Dinger merkwürdigerweise nicht mehr, die hängen sich nach wenigen Paketen auf.

Aktuell bin ich von den voreingestellten 7 auf 10 rauf, das bringt hier im Labor ne deutliche Verbesserung des RSSI- von ungefähr 62 auf etwa 55.
Auch schon was...

Spannend!
Bin gespannt wie Du das mit der Kurve löst!

Crypi

..ich auch.

Inzwischen hab ich rausgefunden, dass die Heltec-Teile, die ich hier hab, wohl so ziemlich die reichweitenstärksten sind, die man kriegen kann.
Wenn es als damit nicht klappt, klappt es (ohne Repeater) _gar nicht_.
Repeater wäre Plan B, auch, weil die Dinger inzwischen hierzulande das Doppelte von dem kosten, was sie wohl vor zwei Jahren noch kamen, und ich keine Ansage hab, was es denn "kosten darf".

Da ich nun aber zwei Tage frei hab, hoffe ich, mal ein bisschen mit denen spielen zu können, vor allem die Instabilität aus dem Test-Programm muss raus.
Während einer der beiden auch schonmal mehr als 2000 Nachrichten am Stück schafft, hängt sich der zweite gewöhnlich irgendwo zwischen der 100. und der 200. auf- interessanterweise aber _nur_ das LoRa.
Der ESP läuft munter weiter. Das weiss ich daher, weil an dem Kandidaten schon ein BME280 hängt, und der trotzdem weiter Daten in die Konsole schreibt...
Je höher ich das Spreading setze, umso schneller gehts mit dem aufhängen. Daher vermute ich das Problem in der Software.

Ich werd also alles mal neu schreiben, und mal schauen, was dann passiert.
Und es auch im Freien mal testen....das Ganze ist viel zu spannend, um nicht mal rauszufinden, welche Entfernungen man unter guten Bedingungen wirklich überbrücken kann.
Die Rede ist da von durchaus 10km...das _will ich genauer wissen_.

Sodele.
Inzwischen haben beide ne neue Firmware drauf.
Der Sender ist momentan _nur_ Sender, der Empfänger _nur_ Empfänger.
Die Kommunikation ist erstmal nur Unidirektional..das ändere ich vermutlich später, weil ich es eleganter fänd, wenn der Empfänger wenigstens ne Quittung schickt, dass er das Paket bekommen hat (nen "ok" oder so reicht da ja schon).

Die Verbindung steht inzwischen seit gestern Abend ununterbrochen- da sind jetzt mehr als 6000 Pakete ausgeliefert worden.
Momentan sende ich alle 5 Sekunden- das ist später natürlich viel zu viel, aber zum Testen...
Da am Sender schon ein BME280 hängt, der Luftdruck, Luftfeuchte und Temperatur liefert, setzt sich ein Datenpaket aus einer Sender-ID und den drei Messwerten zusammen.
Gesteuert wird das Sende-und Mess-Intervall non-blocking, also ohne delay().

Der Empfänger kann schon mehr: er dröselt den Datenstring wieder auf, und hängt in meinem Wlan. Mit ein paar weiteren Codezeilen könnte er die Daten jetzt auf meinen MQTT-Server schicken, aber vermutlich werd ich versuchen, die auf nen Webserver zu packen später.
Von da aus kann man die immernoch auf nen MQTT -Server packen, wenn nötig.
Zur Kontrolle geben beide Funkgeräte einiges auf den Displays aus.
Sender:
Name
Temperatur
Luftfeuchte
Luftdruck

Anzahl gesendeter Pakete

Empfänger:
Länge des zuletzt empfangenen Datenpakets in Byte,
Name des Senders, von dem die kommen,
Temperatur (aus dem Datenpaket),
Luftfeuchte und Luftdruck aus dem Datenpaket
RSSI-Wert.

Ausserdem blinkt eine LED beim Sender, wenn er ein Paket abgeschickt hat, kurz auf, und beim Empfänger dann, wenn er eins bekommen hat. So kann ich mit dem Empfänger in der Hand herumlaufen und nachgucken, ob was ankommt, ohne jedes Mal die winzige Schrift aufm Display entziffern zu müssen...


Dennoch: wenn ich das Spreading auf 12 rauf nehme (Maximum) hängt der Sender sich wieder auf.
Aktuell bin ich bei 10, das läuft.
Ich muss mir mal das Datenblatt von diesem LoRa-Chip angucken, mein Verdacht ist, dass der eigenmächtig blockiert, wenn man zu oft sendet (bei voller Leistung darf man nur 1% der Zeit...). Höheres spreading bedeutet zwar auch höhere Reichweite, aber eben auch ne längere Sendezeit.
Dann liesse sich das mit längeren Intervallen ja beheben.


Grade drucke ich mitm Resin-Drucker mal ein Gehäuse für eins der Daten-Walkie-Talkies, damit ich ein paar Feldtests machen kann. Geht ohne zwar auch, aber wenn man zwei solche Drucker rumstehen hat...

Welche Erfahrungen hast Du mit dem BME280 gemacht?
Ich nutze einen BMP280 und hab festgestellt, dass der Temperatursensor sich nur bedingt dazu eignet um die Umgebungstemperatur zu messen, die Temperatur steigt über die Zeit. Vermutlich heizt der Sensor sich selbst auf.
Nach meinem Verständnis wird er zur Kalibrierung der anderen Messwerte verwendet und hat nur eine begrenzte Aussagekraft über die tatsächliche Umgebungstemperatur.
Ist das beim BME280 anders?

Crypi

Es kommt, wie bei jedem Thermometer, drauf an, wie man es verbaut. Ich kauf ja den Sensor nicht einzeln, sondern immer diese kleinen Breakout-Boards.
Die versuche ich, dann so anzuordnen, dass sie frei umströmt werden können, also z.B. die Platine hochkant und seitlich oder unter allem anderen anzuordnen, damit die erwärmte Luft nach oben weg kann.
Und natürlich Belüftungsöffnungen im Gehäuse...sensibel auf sowas ist eigentlich jeder Temperaturfühler.
Das funktioniert prima.
Ein wirkliches Problem ist, dass die Sensoren sich relativ schnell (im Freien, drinnen nicht, da hab ich welche seit Jahren wartungsfrei laufen) mit Feuchtigkeit sättigen. Zwar kann man sie wieder trocknen, aber danach geht das immer schneller.
Ich will mal versuchen, einen mit Goretex einzupacken, mal sehn, ob das hilft...

So.
Zu weiteren Testläufen im Stollen bin ich noch nicht gekommen, weil mich ne Seuche erwischt hatte, aber ich hab die Software der beiden Geräte noch etwas verfeinert.
Inzwischen quittiert der Empfänger auch- er sendet momentan ein 'ok' zurück.

Der Sender erwartet nach seiner Ansage, die er momentan alle 10s macht, diese Quittung- wenn sie nicht kommt, versucht er alle 2 Sekunden, erneut zu senden. So wie die Quittung dann doch kommt, schaltet er wieder auf die 10-Sekunden-Intervalle um.
Das Ganze läuft nun seit zwei Tagen hier im Probebetrieb störungsfrei und man könnte es noch verfeinern, indem bei gutem Empfang das Spreading zurückgenommen wird.
Da das weitere Massnahmen erfordert (beide Geräte müssen sich dann absprechen) hab ich das erstmal nicht implementiert.

Ausserdem hab ich mal drei weitere dieser Dinger bestellt, damit ich, wenn die im Stollen laufen, noch was zum spielen hab.
Bei rund 10mA Stromaufnahme im Tiefschlaf (zumindest theoretisch können die Dinger durch ein Funksignal aufgeweckt werden, das muss ich noch genauer rauskriegen, wie) könnte es klappen, dass ich mir nen Repeater auf einem unserer Berge aufstelle, der mit Solarzellen und Akku läuft.
Damit, und mit nem Zugangspunkt hier im Haus (die Reichweite sollte möglich sein, Luftlinie ist das kaum mehr als 1km zum Geisingberg) könnte ich nen TTN-Zugangspunkt bauen, der richtig viel abdeckt.
Mal gucken...Packet Radio war früher schon spannend, hehe.

Inzwischen hab ich ein wenig weiter mit den Dingern gespielt..., es gab kleinere Fortschritte, aber auch kleinere Rückschläge.
Im Stollen waren die Dinger allerdings noch nicht wieder, da hatte ich keine Zeit für.
Im Heltec-Forum kann man wesentlich mehr Infos zu den Teilen finden, als in der Doku stehen, beispielsweise scheint es so zu sein, dass der Tiefschlaf-Modus nur dann wirklich gut funktioniert, wenn man die Dinger über nen Akku (der an der vorhandenen Akku-Buchse angesteckt ist) betreibt.
Das Teil ist für 1s-Akkus (LiPo oder LiIo) ausgelegt.
Da ich noch keinen passenden Stecker hab (sind nen paar bestellt) kann ich _das_ noch nicht austesten, aber in den nächsten Tagen mache ich das mal.
Im Tiefschlaf wird dann von einem Stromverbrauch von 5µA gesprochen- hochinteressant!
Damit müsste es eigentlich möglich sein, schon mit ner kleineren Solarzelle, und nem Akku, ein völlig autonomes Gerätchen zu basteln.
Man könnte sich dann nen Repeater (hier im Gebirge braucht man sowas halt schon oft) bauen, der völlig autonom läuft.
Wenn man den USB-Port zur Stromversorgung benutzt, bringt der Tiefschlaf allerdings wenig: Das Teil lief dann, versorgt mit ner kleinen Powerbank (2500mAh, sowas) etwas länger als nen Tag, wobei ich aber zu Testzwecken alle 10 Sekunden sende.
Auch hier könnte man noch einiges sparen, indem man z.B. das Display gar nicht erst aktiviert, oder die LED ausbaut oder so, aber ich warte mal ab, was mit der Akku--Vesorgung rauskommt.
Die V2, die ich hier habe, hat nämlich angeblich ein komplettes Akku-Management integriert: man kann den dann über USB aufladen, und auch die Spannung wird überwacht (Tiefentlade-Schutz).
Es scheint sogar ne Möglichkeit zu geben, die Spannung des Akkus auszulesen...

Den Tiefschlaf hab ich trotzdem schon ein stückweit ausprobiert: selbst das Display und das LoRa-Modul werden abgeschalten- prima.

Da ich inzwischen von den Dingern fünf Stück hier habe (zwei bis drei sind für den Stollen reserviert, ich will da aber versuchen, mit zweien auszukommen), hab ich mir auch mal zwei Gehäuse gedruckt, eins sieht hübsch wie ein Walkie-Talkie aus (dort kann man auch noch nen Akku mit einbauen), das andere sieht denen, die Heltec auch anbietet, recht ähnlich.
Da passt sogar ein BME280 mit rein, allerdings sind die Daten _hier_ nicht wirklich zu gebrauchen, durch die Nähe zum Board heizt sich das Thermometer tatsächlich deutlich auf.
Aber zum Testen reicht das trotzdem, man kann "echte" Daten senden..

Nachher werd ich mal wieder ein bisschen draussen herumspazieren, und Reichweite testen. Das Empfänger-Walkie-Talkie gibt mir auch den RSSI-Wert aufs Display.

Zitat:

---

.. Im Tiefschlaf wird dann von einem Stromverbrauch von 5µA gesprochen- hochinteressant ..

---

Das glaube ich gern. Ich hatte an meinen ESP8266-Platinen (D1 Mini) 45 µA gemessen . . und die haben ja nen Spannungswandler dran . . . Was die richtig kleinen ESPdinger benötigen weiß ich aber (noch) nicht.

So.
Laut Google Maps hab ich heute 1.7km überbrückt.
Nicht ganz direkte Sichtverbindung (einige, wenige Bäume waren dazwischen, ausserdem war der Sender _im_ Haus), aber fast.
RSSI hatte ich da -120, das geht noch.
Da kommt _jedes_ Paket an.
Auf dem Weg dahin war der schlechteste Wert -132, und neulich beim Testen hatte ich teilweise um die -145, ehe die Verbindung weg war.

Ich bin mir sicher: für die oft zitierten 10km braucht man bessere Antennen.
Die mitgelieferten sind simple Drahtspiralen, hübsch in nem Plastikgehäuse versteckt- Wunder kann man da nicht erwarten.
Trotzdem: nicht schlecht für 25mW Sendeleistung.

Anhang 35952

Inzwischen hab ich passende Stecker bekommen, und mal nen Akku eingelötet.
Da ich ihn da hatte (und er so schön mit ins Gehäuse passt) ist es ein 1s1p mit 600mAh geworden.
Das ist nicht brachial viel (ein 1000er würde sicher auch passen, hab ich aber grade nichts rumliegen), wird aber für Tests erstmal reichen.

Damit ist mein kleines Datenfunkgerät (das vom Bild oben, da hängt es noch an ner Powerbank) jetzt schonmal autonom (zumindest für eine gewisse Zeit) unterwegs.
Und: man kann tatsächlich mit Bordmitteln die Akku-Spannung auslesen, ein Beispiel gibts in der Arduino-IDE.
Allerdings stimmt in dem Beispiel ein Multiplikator nicht, den musste ich anpassen.
Ich hatte nur 3.3V anstatt den tatsächlichen 3.95V, die der Akku gerade hat.
Und: er lässt sich per USB -auch im laufenden Betrieb- laden!
Die kleinen Dinger werden mir immer sympatischer...

Nebenbei: die Board-LED (im Tiefschlaf wohl einer der grössten Stromfresser überhaupt, da die immer leuchtet, wenn an USB Spannung anliegt) ist im Akkubetrieb aus.
Schön wäre es ja wenn die als Ladeanzeige fungieren würde (ähnlich den kleinen Ladeplatinchen, die es für einzellige LiPo's an jeder Ecke gibt), aber das glaub ich wiederum nicht...vielleicht kann man da aber über die zweite LED was selber basteln, die lässt sich ja per Software steuern.

Nachtrag: die LED _fungiert als Ladeanzeige_. Die geht aus, wenn der Akku voll geladen ist.
Es wird immer besser...

Jetzt werd ich mal die Spannungsanzeige in das Empfangs-Programm einpflegen, und dann mal rausfinden, ob man die Dinger tatsächlich über LoRa aufwecken kann (angeblich funktioniert das, aber da bin ich skeptisch, da im Tiefschlaf der LoRa-Chip ja abgeschalten sein müsste).

Nebenbei steht nun an, das Gehäuse für das Ding noch mal leicht zu überarbeiten (der Displayrahmen muss um 2mm versetzt werden, und so paar andere Kleinigkeiten, wie üblich bei heruntergeladenem Zeugs), und bei der Gelegenheit auch nen Aus-Schalter zu integrieren.

Neue Erkenntnis: es gibt offenbar keine wirkliche Akku-Überwachung bei den Heltec-Boards: vorhin ist mir das Ding in nen Brownout gelaufen...kurz danach hat es sich dann doch noch selber abgeschalten.
Das war bei ungefähr 2.6V- für eine LiPo-Zelle zu wenig!

Da ich das aber nun weiss, ist es nicht schwer, das Ding beim Unterschreiten einer Mindest-Spannung wenigstens in den Tiefschlaf zu schicken.
Aus dem werd ich ihn dann jede Minute mal aufwachen lassen, die Spannung überprüfen, und falls die wieder ausreichend hoch ist, kann er weiter arbeiten. Ne andere Methode, ihn z.B. beim Nachladen wieder wach zu kriegen, fällt mir gerade nich ein..

Macht echt Spass, mit den Dingern zu spielen, wirklich...
In den letzten Tagen (ausnahmsweise hatte ich mal frei) hab ich an meinem Walkie-Talkie weiter herumprogrammiert.
Inzwischen versucht es, bekannte, offene Wlans zu finden (oder benutzt zu Hause meines, für das weiss es das PW auch), später will ich das so weit aufbohren, dass es selbständig offene Wlan entdecken und nutzen kann (momentan wird da einfach ne hinterlegte Liste abgearbeitet). Dazu fehlen mir noch ein paar Erkenntnisse, aber grundsätzlich geht das mit den ESP.
Wenn es ne Wlan-Verbindung hat, wird von nem Zeitserver die Uhrzeit geholt (das ist nur ne Spielerei im Moment, um auszugeben, dass wir Internet haben, kann man aber auch gut für Daten-Logging z.B. gebrauchen), wenn nicht, wird die Uhrzeit intern berechnet aus der Laufzeit seit dem Start.
Das, welches Wlan gerade genutzt wird (falls eines...), die Spannung des eingebauten Akkus und die Anzahl, seit Start empfangener Lora-Pakete werden auf ner eigenen Bildschirmseite angezeigt.
Trifft ein LoRa-Paket ein, wird die Anzeige umgeschalten, und ausgegeben, was eben empfangen wurde.

Damit das alles vernünftig funkioniert (es gibt keine ernsthaften delay() mehr im Code) läuft im Hintergrund ein Timer, der die interne Uhrzeit berechnet, und von Zeit zu Zeit weitere Aufgaben auslöst.
Beispielsweise wird alle 15 s auf den Info-Bildschirm umgeschalten, oder jede Minute der Akku überprüft.

Demnächst gibt es zwei neue, hoffentlich deutlich bessere Antennen (samt Kabel, da sind wieder mal Weibchen an den Anschlüssen verbaut, zum heulen ist das), dann kann ich mal wieder in den Stollen mit einem der Dinger.

Das Handgerät hat inzwischen noch mal ein neues, etwas ordentlicher gedrucktes Gehäuse bekommen, und nun auch nen Ausschalter.
Das Teil werd ich nämlich so behalten, wie es ist, und nur bei Bedarf einfach andere Software aufspielen. Als Testpilot ist das Ding super, da es in jede Hosentasche passt und dank dem eingebauten Akku kein weiteres Zubehör braucht.
Vielleicht bau ich da noch nen kleinen Buzzer ein, dann kann man auch, während das Ding in der Tasche steckt, mitbekommen, wenn Daten eintreffen oder so...

Anhang 35953

Anhang 35954

Sodele.
Heute konnte ich die zwei Dinger mal wieder im Stollen testen: zumindest von etwa 100m unter Tage nach draussen funktioniert es nun, mit den längeren Antennen.
Es kommt nicht jedes Paket an, aber mehr als 50%. Da die Temperatur im Stollen keiner soo genau braucht, reicht das!
Schön ist vor allem, dass ich jetzt auch _ins_ Museums-Gebäude komme. Da kann ich die Daten aus dem Stollen nämlich prima via Wlan ins Internet weiter reichen...

Die nächste Aufgabe hierzu wird es nun sein, ein Gehäuse zu bauen, was uneingeschränkt wetterfest ist, im Stollen ausreichend robust montiert werden kann und dem Sensor einwandfreie Bedingungen bietet.
Letzteres war beim Test heute nicht der Fall, da ich alles in nem Mini-Gehäuse hatte, wo der Sensor viel zu nahe an der Hauptplatine war (das macht gleich mal 2 Grad Unterschied aus).
Aber: der Plan sollte funktionieren...

Also kommst Du ohne Relaisstation aus?

Crypi

Ja, wenn ich davon ausgehe, dass die Wetterbedingungen in der Mitte des Stollens annähernd dieselben, wie ganz hinten sind.
Die 200m, die der _wirklich_ lang ist, schaff ich so nicht, wegen der Kurve.
Aber letzten Endes ist das ja auch keine Doktorarbeit, sondern soll lediglich ne Info für die Besucher sein, da kommts auf ein halbes Grad auch nicht an.

Denkst Du denn, dass es möglich wäre die Strecke mit einer Relaisstation zu überbrücken?

Crypi

Definitiv.
Hatte ich ja ausprobiert: wenn ich eins der Teile in die Kurve hänge, kann ich es sowohl von hinten (also Ende des Stollens) als auch von vorne, vom Mundloch aus erreichen.
Wenn man das jetzt als Repeater konfigurieren würde (was nicht schwer ist, das muss ja nur empfangene Daten kurz speichern und dann wieder aussenden), ginge das.
Ich will das nur nicht, weil ich dann zweimal Stromversorgung im Stollen bräuchte.

Wär der Stollen gerade, würde es wahrscheinlich auch deutlich weiter funktionieren...im Freien war ich ja schon bei ungefähr 1.7km.

Spasseshalber werd ich die Tage mal meine PMR-Geräte mitnehmen, und mal schauen, wie _das_ eigentlich unter diesen Bedingungen geht...

so.
Heute war ich mal wieder zu Fuss unterwegs, und da der Sender, der später in den Stollen soll, softwareseitig fertig ist, hatte ich das Daten-Handy mal wieder dabei.
Dabei hab ich wieder mehr als 1km Luftlinie überbrückt (schlechtester RSSI-Wert war -140), dieses Mal aber _ohne_ Sichtverbindung. Da waren immer _mehrere_ Baumgruppen (Wäldchen zu sagen, wäre übertrieben, aber schon jeweils so 20-30m breite Baumstreifen) dazwischen.
Teilweise auch anderes....
Nicht schlecht für das bisschen Sendeleistung...
In die Richtung war ich schon mal unterwegs- da hat es nicht geklappt. Die neuen Antennen sind also, vor allem auf Entfernung, doch noch mal deutlich besser.
Im Nahbereich taugen sie allerdings weniger als die kleinen...

Wir forschen mal wieder ein bisschen....:

Ich fänd es ja schön, wenn das "Daten-Handfunkgerät" auch _irgendwie_ bedienbar wäre.
Man könnte da manuell zwischen verschiedenen Anzeigen umschalten, irgendwelche Funktionen zu- oder abschalten....eine Menge Sachen eben.
Nun unterstützen ja die ESP-32 auch ne Touch-Sensor-Funktion..im Grunde reichts, wenn man die entsprechenden Pins berührt...
Leider sind etliche dieser Pins bereits mit irgendwelchem anderen Gedöns belegt.
Bei den wenigen, die frei sind, klappt es _nicht_, (vermutlich, weil ich an den ADC-Einstellungen so einiges umbiegen musste, um die Spannung des Akkus auslesen zu können, so ganz versteh ich selber noch nicht, was da genau abgeht).

Aber: der "Prg-Button", den die Boards ja haben, hängt auch an so nem Touch-Pin- und damit funktioniert es!
Da der im normalen Programmablauf sowieso nix bewirkt (angeblich soll man den drücken, um Programme flashen zu können, ich hab dazu nie einen der Buttons drücken müssen), kann man ihn tatsächlich ohne Probleme für die eigene Kreativität nutzen.
Einfach auslesen wie nen Touch-Pin, liefert er nen sauberen boolschen Wert...wenn man nicht drückt, ein HIGH, drücke man ihn, fällt er auf LOW.
Das ist ja schonmal was...
Da der Button in meinem Gerät sowieso von aussen zugänglich ist, brauch ich mir da nicht mal irgendeinen Kontakt nach draussen legen.
Sehr praktisch.

Jetzt muss ich mal in mich gehen, und überlegen, was man mit _einem_ Button so alles anfangen könnte.

Zitat:

---

Wir forschen mal wieder ein bisschen... und überlegen, was man mit _einem_ Button so alles anfangen könnte.

---

Da fallen Dir sicher ein paar gute (und vielleicht dazu manche dürftigen) Lösungen ein. Bei meinem Pacer (Takt-/Zeitgeber für Fitness) habe ich die Simpellösung: lang, kurz, gaaanz kurz+lang, gaaanz kurz+kurz: das geht "grad-noch". UND natürlich auch mehrfach-Ticks, z.B. beim hoch-/runtertickern. Beim Servotester gibts die erweiterte Funktion Druck-bei-Sekunden-LED-an und Druck-bei-Sekunden-LED-aus, beides manchmal erweitert mit kurz/lang/mehrfach.

Interessant hier mitzulesen . . .

Ja, in Verbindung mit nem Display und nem Timer (der da ja sowieso im Hintergrund tickt...er zählt ja z.B. die Uhrzeit weiter, wenn kein Wlan und damit kein NTP verfügbar ist) kann man mit so nem Button etliches anstellen.
Ne frei ansprechbare LED wäre auch noch da...alles das haben diese kleinen Funkgeräte ja an Bord.

Im Grunde kann man damit schon ne ganze Menüstruktur aufbauen.
Die Frage ist eher: wofür könnte man das halbwegs sinnvoll einsetzen...
Aber ich bin sicher, da fällt mir was zu ein...

Im Übrigen: wieso ich Spreading 12 (was zwar die niedrigste Datenrate, aber dafür die höchste Reichweite bringen würde) nicht nutzen kann (da hängt sich der LoRa-Chip nach kurzer Zeit auf) ist inzwischen geklärt: da ist ein Bug in der Heltec-Bibliothek.
Leider hab ich keine Infos zu, was da genau los ist, sonst könnte man's womöglich reparieren.
Mittelfristig kann ich aber auf ne andere Bibliothek ausweichen, wo auch das klappt.
Da ich dazu aber dann alles umschreiben muss (das sind inzwischen ein paar hundert Zeilen Code in nem halben Dutzend Dateien), weil die Heltec-Library auch das Display handelt usw., hab ich das nicht besonders eilig.

So.
Gehen wir mal das nächste Problem an: was mach ich mit den Daten, die aus dem Stollen kommen?
Klar, auf dem Raspi, der da sowieso ausserdem (praktischerweise im selben Wlan) läuft, könnte man nen Mosquitto-Broker aufsetzen.
Das wäre einfach, hat aber den Nachteil, dass da andere Anwendungen nicht so ohne weiteres drauf zugreifen können.
Ich hätte es aber gerne eleganter, beispielsweise kann ich mir vorstellen, dass auch die Webseite vom Museum die Daten später anzeigt. Es wäre also sinnvoller, die auf nen richtigen Webserver zu packen, von wo aus beliebig drauf zugegriffen werden kann. Der Raspi kann sie sich da ja auch holen...

Aktuell handelt es sich lediglich um 31 Byte pro Telegramm, also nix weltbewegendes (die werden später maximal alle Viertelstunde gesendet, das ist mehr als ausreichend).
Hier bräuchte ich etwas Hilfe: welches wäre der einfachste Weg?
Ich hab von dem Web-Gedöns nur sehr rudimentäre Kenntnisse- aber nen eigenen Webserver bei bplaced, der auch FTP hat..
Wie geh ich am einfachsten vor?

Kannst Du die Daten nicht auf dem Rpi in einer Datenbank ablegen?
Auf dem könnte ja auch ein Webserver laufen über den Du die Daten im Browser anzeigen lassen könntest oder auch an einen anderen Dienst liefern könntest, per http request oder sonstwie geartete API.

Oder hab ich dich falsch verstanden?

Crypi

Ich möchte nicht, dass dieser Pi von aussen zugänglich ist.

Das ist der, für den ich gerade die App schreibe, siehe hier.
Genau diese App soll auch die Daten aus den Stollen anzeigen (daher wärs denkbar, auf dem Pi nen MQTT laufen zu lassen), was aber dann nur im lokalen Netz funktionieren würde.
Fürs erste kann ich damit leben, aber ich fänds schick, wenn z.B. die Tourist-Info (nicht im gleichen Netzwerk) oder eben auch die Webseite vom Museum die Daten ausgeben könnte.
Dazu dürfen die aber eben nicht nur lokal verfügbar sein.