Hallo zusammen,
ich bin auf der Suche nach einem Bluetooth-Modul, BLE mit Ansteuerung
durch einen Host über UART. Das Modul soll als Master fungieren und mit
mehreren Slaves kommunizieren können. Das/die zu verwendende Profile
kenne ich leider noch nicht.
Ziel ist es, mit verschiedenen Geräten zu kommunizieren und Daten
auszutauschen. Nur Konfiguration, keine Streamingdaten.
Ich war fest der Annahme, dass jedes Bluetooth-Modul das Piconet
beherrscht, habe jetzt aber nach endloser Suche gerade mal das BT121 und
das CC2564MODA gefunden, in dem die Funktionalität Master + mehrere
Slaves auch im Datenblatt zu finden ist.
Stehe ich jetzt auf dem Schlauch oder ist es wirklich so, dass es kaum
BT-Module gibt, die das beherrschen?
Gruß Bernhard
> BLE
BLE aka Bluetooth Low Energy?
> Piconet
Piconet ist Blueooth Classic.
Was solles denn nun sein?
Bei BT Low Energy würde ich programmierbare Module empfehlen. Habe gute
Erfahrungen mit NRF52832 und NRF5840-basierten Modulen gemacht - wenn
man halbwegs solide C beherrscht.
Bei den fertig-Modulen hat man das Problem, dass man hinterher per UART
doch nur mit einer Gegenstelle vernünftig reden kann.
"Transparent UART" heisst eben auch das KEIN Protokoll benutzt wird. Das
bräuchte man aber um mehr als eine Gegenstelle überhaupt ansprechen zu
können.
> Das/die zu verwendende Profile kenne ich leider noch nicht.
BLE hat nichts mit normalen Bluetooth zu tun. Das ist auch logisch gut
und richtig so weil es sonst nicht LowEnergy sein koennte. Ist halt nur
bloed das man Kunden verwirrt weil man etwas komplett anderes auch
Bluetooth genannt hat.
Du wirst also erstmal viel dazulernen muessen. .-)
Olaf
Bernhard schrieb:> ich bin auf der Suche nach einem Bluetooth-Modul, BLE mit Ansteuerung> durch einen Host über UART. Das Modul soll als Master fungieren und mit> mehreren Slaves kommunizieren können. Das/die zu verwendende Profile> kenne ich leider noch nicht.
Du kannst z.B. jedes auf nrf52832 basierende breakout board nehmen,
darauf die nordic connectivity firmware spielen und dann mit
pc-ble-driver in C dagegen entwickeln.
Wenn Du noch verraten möchtest, woran Du dieses "BLE Modul" anschließen
möchtest, hätten wir ggf. auch noch passendere Tipps für Dich.
Wir haben ein tragbares Gerät im Medizinbereich und dass soll von
externen Geräten zyklisch Informationen bekommen. Das BT-Modul soll
Bindeglied zwischen diesen externen Geräten und dem Controller bei uns
sein.
Deswegen auch die Low-Energy-Variante und meine Frage, ob man mit
mehreren kommunizieren kann. Pairing findet nur mit uns bereits
bekannten Geräten statt.
C ist kein Problem. Mir schwebte eine Lösung vor, bei dem dieses
BT-Modul einfach über die UART angesteuert wird, damit Produktion und
Support bei uns einfacher wird.
Viel mehr weiß ich leider auch nicht, die Frage war "Schau mal, ob das
möglich ist"
Bernhard schrieb:> Wir haben ein tragbares Gerät im Medizinbereich und dass soll von> externen Geräten zyklisch Informationen bekommen. Das BT-Modul soll> Bindeglied zwischen diesen externen Geräten und dem Controller bei uns> sein.
Implementieren diese Geräte bereits spezifizierte Protokolle?
> Deswegen auch die Low-Energy-Variante und meine Frage, ob man mit> mehreren kommunizieren kann. Pairing findet nur mit uns bereits> bekannten Geräten statt.
Ja, das geht. Ein link layer master (oder GATT Client) kann mit mehreren
link layer slaves (oder GATT Servern) "gleichzeitig" kommunizieren.
> C ist kein Problem. Mir schwebte eine Lösung vor, bei dem dieses> BT-Modul einfach über die UART angesteuert wird, damit Produktion und> Support bei uns einfacher wird.
Du kannst einen nrf52 über UART anschließen und dann mit pc-ble-driver
diesen ansteuern. Wie der Name pc-ble-driver aber bereits andeutet, sagt
läuft diese Library nur auf PCs (Win, Mac, Linux). Wenn Deine "tragbares
Gerät im Medizinbereich", PC hardware hat, würde das gehen.
> Viel mehr weiß ich leider auch nicht, die Frage war "Schau mal, ob das> möglich ist"
Naja, von den Details hängt es dann schon ab, in welche Richtung eine
Lösung gehen würde. Möglich ist das auf jeden Fall.
> Implementieren diese Geräte bereits spezifizierte Protokolle?
Das weiß ich leider nicht. Der Kunde ist im Urlaub. Es soll nur eine
Recherche sein, ob es überhaupt geht
> Wenn Deine "tragbares Gerät im Medizinbereich", PC hardware hat, würde das
gehen.
Kein PC. Reine Firmware auf einem ARM-Controller
> Naja, von den Details hängt es dann schon ab, in welche Richtung eine Lösung
gehen würde. Möglich ist das auf jeden Fall.
Ich würde ein Königreich für mehr Informationen geben. Aber langsam sehe
ich Licht am Horizont und eine Richtung. Das ist ein erster Fortschritt.
Mehr kann mein Chef dann auch nicht wirklich erwarten
Bernhard schrieb:> Kein PC. Reine Firmware auf einem ARM-Controller
Dann könntet ihr ggf. sogar den ARM-Controller durch einen ersetzen, der
BLE kann...
> Mehr kann mein Chef dann auch nicht wirklich erwarten
Amen ;-)
Wenn ich höre "medizinischer Bereich" und "Bluetooth" und das auch noch
zusammen in einem Satz, dann rollen sich mir die Zehennägel hoch ...
"Oh, jetzt hab ich mit meinem Smartphone versehentlich die Dosierpumpe
verstellt" ...
Naja...
alopecosa schrieb:> Wenn ich höre "medizinischer Bereich" und "Bluetooth" und das auch> noch> zusammen in einem Satz, dann rollen sich mir die Zehennägel hoch ...>> "Oh, jetzt hab ich mit meinem Smartphone versehentlich die Dosierpumpe> verstellt" ...>> Naja...
Das ist völlig okay und absolut normal. Schließlich gibt es auch
Elemente, welche nicht sicherheitskritisch sind. Beispielsweise das
Auslesen von geloggten Daten, Fehlercodes, Monitoring-Items etc...
Arzt schrieb:> alopecosa schrieb:>> Wenn ich höre "medizinischer Bereich" und "Bluetooth" und das auch>> noch>> zusammen in einem Satz, dann rollen sich mir die Zehennägel hoch ...>>>> "Oh, jetzt hab ich mit meinem Smartphone versehentlich die Dosierpumpe>> verstellt" ...>>>> Naja...>> Das ist völlig okay und absolut normal. Schließlich gibt es auch> Elemente, welche nicht sicherheitskritisch sind. Beispielsweise das> Auslesen von geloggten Daten, Fehlercodes, Monitoring-Items etc...
Ich find ja das auslesen von geloggten Daten im Medizinbereich alles
andere als unkritisch.
Aber ich gehöre ja auch der Aluhut Fraktion an, die selbst funkende
Heizkörperthermostate böse findet..
naja...
alopecosa schrieb:> Ich find ja das auslesen von geloggten Daten im Medizinbereich alles> andere als unkritisch.>> Aber ich gehöre ja auch der Aluhut Fraktion an, die selbst funkende> Heizkörperthermostate böse findet
Ganz meine Meinung. Aber der Auftraggeber ist nun mal der, mit dem
längeren Hebel. Aber zur Beruhigung, es ist nicht lebenserhaltend, was
wir machen. Nur reines Monitoring ohne Patientenbezug in den Daten. Und
im Handbuch steht auf Seite 1000 im extrem Kleingedruckten, dass der
Arzt eh nicht alles glauben darf, was er sieht...
Also selbst kann ich das Modul RN4871 empfehlen ist leicht zu
programmieren (ASCII usw.)und unkompliziert. Selbstverständlich BLE 4.2.
Ist recht günstig und klein. Wen du aber eine anspruchsvolle anwendung
hast nimm doch ein Modul von Nordic das nRF52840 mit cortex M4 1MB flash
und natürlich Bluetooth 5.0 BLE.
Bernhard schrieb:> Hallo zusammen,>> Ich war fest der Annahme, dass jedes Bluetooth-Modul das Piconet> beherrscht
Piconet stammt aus dem Pleistozän des BT Standards. Die Module können
das meist auch allesamt, die Tragödie ist allerdings, dass die
aufgespielte SW auf dem Modul meist nur das primitivste SPP Example aus
dem Hersteller-Baukasten ist. Wenn man Piconet haben wollte, müsste man
das SDK des Herstellers kaufen und selber machen. Es scheitert meist an
Geld, Lernkurve, Manpower und NDAs. Kann man faktisch vergessen.
> Stehe ich jetzt auf dem Schlauch oder ist es wirklich so, dass es kaum> BT-Module gibt, die das beherrschen?>
Siehe mein Kommentar dazu in diesem Thread:
Beitrag "Günstige Bluetooth Module ohne Probleme?"
