Hallo, ich möchte eine Reihe von Feuchtigkeitemessern in meinem Garten verteilen und die Messdaten periodisch per Funk an eine Empfangstation übertragen. Ich hatte mir dazu das RN4870 BLE Modul von Microchip ausgesucht, weil es schön klein ist,wenig Energie verbraucht und mich direkt mit einem (Linux/WIndows)-PC kommunizieren lässt. So war die Hoffnung. Zu meiner Enttäuschung scheint es keine Möglichkeit zu geben, auf einem Windows PC einen virtuellen COM port zu erhalten, um über das Modul per BLE mit dem uC dahinter zu kommunizieren. Also: PC-BLE-UART-uC. Auch mit Linux scheint es nicht zu gehen. Kann mir jemand ein kompaktes, energiesparendes, günstiges Funkmodul nennen, das auf meine Anwendung passen könnte?
> Zu meiner Enttäuschung scheint es keine Möglichkeit zu geben, auf einem
Es gibt keine virtuellen Comport fuer BLE. Sowas gab es nur bei normalen
Bluetooth. BLE ist etwas komplett anderes.
Olaf
Olaf schrieb: > Es gibt keine virtuellen Comport fuer BLE. Jain. Man muss ihn eben selbst bauen, die RN4870 unterstützen das auch. Vor einiger Zeit habe ich in der Firma mal eine kleine App für Android geschrieben, die mit diesen Modulen kommunizieren kann. Findet man auch im Netz Infos zu. Ist aber schon etwas Gefrickel. Es gibt auch BLE Terminalprogramme für den PC / Apps fürs Handy. Damit habe ich allerdings keine Erfolge gehabt. Hmmmm ... Du möchtest unbedingt an den PC connecten!? Eine App reicht Dir nicht? Gruß Jobst
> Jain. Man muss ihn eben selbst bauen,
Ja selbst bauen kann man immer alles. Silabs hat da z.B auch was.
Ist dann aber nicht kompatibel sondern hardwarespezifisch.
Und ich meine Nordic hat auch was eigenes.
Olaf
Tobias S. schrieb: > Kann mir jemand ein kompaktes, energiesparendes, günstiges Funkmodul > nennen, das auf meine Anwendung passen könnte? Du könntest aber auch einfach die GATT API verwenden (und nicht die UART API): https://learn.microsoft.com/en-us/windows/uwp/devices-sensors/gatt-client
Tobias S. schrieb: > Kann mir jemand ein kompaktes, energiesparendes, günstiges Funkmodul > nennen, das auf meine Anwendung passen könnte? Energiesparend beißt sich mit Zuverlässigkeit = Reichweite. Günstig meist ebenfalls. Etwas tiefer in die Brieftasche gegriffen kann ich Dir XBee-Funkmodule empfehlen. Sehr komfortables Arbeiten mit denen. Com-Port am PC inklusive.
> Du möchtest unbedingt an den PC connecten!?
ja, das ist wichtig. Da meine Haussteuerung auf Linux-Servern läuft,
müssen die Daten am Ende in einem PC-System landen.
Natürlich könnte man eine Empfangstation auf uC-Basis und serieller
Schnittstelle auf PC-Seite machen, aber diesen Aufwand würde ich gerne
vermeiden.
Olaf schrieb: >> Zu meiner Enttäuschung scheint es keine Möglichkeit zu geben, auf einem > > Es gibt keine virtuellen Comport fuer BLE. Sowas gab es nur bei normalen > Bluetooth. BLE ist etwas komplett anderes. Ja, das ist mir dann auch aufgefallen. Sehr schade. Deshalb suche ich ja eine Alternative.
> Ja, das ist mir dann auch aufgefallen. Sehr schade. Deshalb suche ich ja > eine Alternative. Dann nimm z.B die hier: Beitrag "JDY-40 ein neuer Geniestreich aus China?" Da musst du eigentlich garnicht denken, die funktionieren einfach so. Oder du lernst halt mal 2-3Tage wie BLE funktioniert und verzichtest auf eine virtuelle Schnittstelle. Alle anderen Leute koennen ja mit BLE auch Daten uebertragen. Der Vorteil von BLE ist in der Hauptsache das es in dein Handy drin ist. Da kannst du einfach in 1-2Tagen ein huebsches Programm zusammenschustern das auf Handy, Linux und Windows laeuft. (falls du Qt/C++ kannst) Olaf
Ich sehe das als Softwareproblem auf den PC (Linux und Windows). Man braucht Software die mit BLE/GATT zusammenspielen. Und in 2 bis 3 Tagen ist das höchstens für Hochbegabte zu schaffen. Ich habe mich mal mit Linux in einer älteren Betriebssystemversion und Bluez ein paar Tage rumgeärgert. Und das waren JDY-Module. Ob die JDY-40 kann ich jetzt nicht genau sagen. Die Charakteristiken habe ich bekommen, aber danach wäre es in Softwareentwicklung abgeglitten. Wie vorher schon gesagt, ich habe noch keine Terminalemulation gefunden, die die seriellen Charakteristiken verarbeitet. Nur eine Pythonimplementation aus einen GIT, die ich mir auf meinen Hauptrechner nicht installieren wollte.
Sie den nachfolgende Beitrag. Serielle Verbindung bis zu den Charakteristiken hat funktioniert. Danach müßten die Charakteristiken im PC verarbeitet werden. Beitrag "Re: Lidl-Multimeter PDM-300-C2 Analyse und Erweiterungen"
> Und in 2 bis 3 Tagen ist das höchstens für Hochbegabte zu schaffen. Ich hab vorausgesetzt das man mit Qt/C++ umgehen kann. Die Basisklassen fuer BLE werden dir dann mitgeliefert. Beispiele die du einfach uebersetzt und dein Modul damit finden kannst gibt es auch. Daher ist das nicht so die Schwierigkeit. Wenn man irgendein anderes Framework nutzt dann wird das da vermutlich nicht viel anders sein und irgendwas sollte man ja schon programmieren koennen wenn man sowas bauen will. Und ja, wenn du richtig tief in BLE eintauchen willst dann ist das schwieriger und dauert eher 2-3Wochen, aber auf der Seite des Mikrocontrollers musst du das ja sowieso. > Wie vorher schon gesagt, ich habe noch keine Terminalemulation gefunden, > die die seriellen Charakteristiken verarbeitet. Das kann es bei BLE nicht geben weil das einfach nicht vorgesehen ist. Das einzige was es geben kann ist Geraete die eine Firmware haben welche sowas fuer dich umsetzen, aber dann halt Herstellerspezifisch. Olaf
olaf schrieb: > Und ja, wenn du richtig tief in BLE eintauchen willst dann ist das > schwieriger und dauert eher 2-3Wochen, aber auf der Seite des > Mikrocontrollers musst du das ja sowieso. Das ist doch irre. Welches Ingenieurs-Genie denkt sich solchen Wahnsinn aus? Nur weil man ein paar poplige Bytes übertragen will?
> Das ist doch irre. Welches Ingenieurs-Genie denkt sich > solchen Wahnsinn aus? Naja, es ist fuer das dahinterstehende Konzept schon gut und sinnvoll. Dafuer hast du dann standardisierte Services: https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit UUID Numbers Document.pdf Aber ja, ein bisschen ueberdreht/abgehoben ist es sicherlich auch. Vermutlich gerade in dem bemuehen Standards zu setzen mit denen man alles abdecken kann. > Nur weil man ein paar poplige Bytes übertragen will? Niemand interessiert sich vermutlich so besonders dafuer was du willst. :-) Es ist aber auch so das der Hintergedanke bei BLE war moeglichst stromsparend zu sein. Da passt ein serieller Stream unbekannten Inhalts schlecht in das Blockorientierte Konzept. Wer das nicht will kann ja normales Bluetooth nehmen und zahlt den Preis des hoeheren Stromverbrauchs. Das ist halt das andere Konzept. Ohne Arme keine Kekse. Olaf
olaf schrieb: > Dann nimm z.B die hier: > > Beitrag "JDY-40 ein neuer Geniestreich aus China?" > Danke für den konstruktiven Vorschlag. Damit kann ich leben, wenn das auch mit dem one-to-many Modus funktioniert. Dann muss die Zentrale eben über RS232 an den Rechner angeschlossen werden. Und ich muss mir noch ein Protokoll ausdenken, wie ich die periodisch aus dem Schlaf aufwecke und Kollisionen erkenne.
olaf schrieb: > aber auf der Seite des > Mikrocontrollers musst du das ja sowieso. Wie schon von mir gesagt, wird sowas vom RN4780 unterstützt. Entwickeln muss man vor allem auf der anderen Seite. Man kann auch 2 der Module koppeln und hat dann eine UART zu UART Verbindung. Wie, steht im Datenblatt. Aber man kann eben auch nur 2 Module koppeln. > Das einzige was es geben kann ist Geraete die eine Firmware haben welche > sowas fuer dich umsetzen, aber dann halt Herstellerspezifisch. Richtig, mit anderen Modulen arbeitet das auch nicht zusammen. Gruß Jobst
Die sauberste Lösung wäre, auf den RN4780 gleich die Feuchtemessung zu implementieren und als Charakteristik über BLE anzubieten. ;-) Vom Konzept her sind das alles Mikrocontroller, die BLE über Bibliotheken anbieten.
noreply@noreply.com schrieb: > Die sauberste Lösung wäre, auf den RN4780 gleich die Feuchtemessung zu > implementieren und als Charakteristik über BLE anzubieten. ;-) Das stimmt auch. Ist aber auch nicht nur Arbeit, sondern kann auch gut scheitern, sich durch die Charakteristika-Schlüssel etc durchzufinden und zu konfigurieren im Modul. Die andere Seite ist auch nicht ohne: wie verarbeite ich die übertragenen Daten in Linux so, um sie in mein Node-red zu bekommen. Schön wäre es für mich gewesen, den UART des Moduls zu bedienen und auf der anderen Seite kommen Zeichen aus dem seriellen Device /dev/serial raus. Ich werde mich mal belesen, ob ich mir das zutraue und parallel habe ich die China-Dinger bestellt. Da ist die Herausforderung ja eher die Kollisionserkennung bei mehreren Teilnehmern. Viele Grüße, Tobias
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.