Welches BLE-Modul - für Auswertung einer Waage - würdet Ihr empfehlen, wenn am AVR die I2C-Pins frei sind? Software-UART statt I2C sollte dort auch gehen (8bit-Timer frei + 18.4MHz AVR). Google findet vor allem nRF51822. Ist das das, was man zur Zeit nimmt? Soweit ich es verstehe, ist das ein SoC, selber zu programmieren. Hört sich kompliziert an. Oder ist das nur eine Frage von "Jetzt spiele ich fertige BLE-Firmware vom Hersteller auf und fertig ist es"? Bei der Waage weiss ich noch nicht, welche ich nehmen werde. Zumindest bei einer habe ich aber das Protokoll: "Weight comes in on 0000EF81-0000-1000-8000-00805F9B34FB Like so: 0x07: length 0xff: manufacture data 0xef: service header byte1 0x81: service header byte2 0x__ weight val byte1 0x__ weight val byte2 0x__ weight val byte3 0x__ weight val byte4 usw." BLE sagt mir zur Zeit noch nichts. Wenn man kein Protokoll hat: Kann man die lange Zahl (UUID = Adresse?) herausfinden und dann versuchen, sich aus den Daten einen Reim zu machen - oder kann man solche Gerät nur ansprechen, wenn man das Protokoll vorliegen hat?
Frank schrieb: > "Weight comes in on 0000EF81-0000-1000-8000-00805F9B34FB Das ist die UUID. Du musst das Bluetooth Modul so konfigurieren, dass es die Daten von dieser UUID empfängt und an dein Programm weiter reicht. Unter Linux kann man die UUID's damit anzeigen: https://github.com/pcborenstein/bluezDoc/wiki/hcitool-and-gatttool-example > Bei der Waage weiss ich noch nicht, welche ich nehmen werde > Wenn man kein Protokoll hat ... > kann man solche Gerät nur ansprechen, wenn man das Protokoll vorliegen hat? Es wäre reine Glückssache. Ich würde nur Produkte kaufen, bei denen das Protokoll dokumentiert ist.
Google hat noch zu diesem BLE-Modul geführt: RN4871 on Microchip. Hat jemand eine Meinung dazu? UART-Befehlsinterface. Schätze das funktioniert so ähnlich wie das AT-Interface beim BTM222-Modul, das ich mal hatte. Hört sich einfacher als nRF51 an (?). Ein Problem damit wäre voraussichtlich, dass dessen Baudrate 115200 ist. Das werde ich mit Soft-UART nicht schaffen. Aber das lässt sich anscheinend umschalten (hoffentlich mit Speicherung in non-volatile-Memory).
> Google findet vor allem nRF51822. Ist das das, was man zur Zeit nimmt? Die Dinger sind gut eingefuehrt und dokumentiert. Werden aber wohl gerade duch moderneres ersetzt. Wenn du also basteln willst dann sind sie optimal. > Soweit ich es verstehe, ist das ein SoC, selber zu programmieren. Hört > sich kompliziert an. Haengt von der grauen Masse zwischen deinen Ohren ab. :-) Ich hab von 0(keine Ahnung von BLE) auf erfolgreiche Uebertragung mit eigenem Programm auf beiden Seiten etwa 40h gebraucht. > Oder ist das nur eine Frage von "Jetzt spiele ich > fertige BLE-Firmware vom Hersteller auf und fertig ist es"? Du musst eine Firmware vom Hersteller aufspielen und dann diese Libary in deinem eigenen Programm benutzen. Das nimmt dir schon 90% der ARbeit ab, aber die restlichen 10% sind auch noch Arbeit. > BLE sagt mir zur Zeit noch nichts. Wenn man kein Protokoll hat: Kann man Das sind die ersten 8h auf der Strasse zum Erfolg. :-D > oder kann man solche Gerät nur > ansprechen, wenn man das Protokoll vorliegen hat? Kann man nicht vorhersagen. Der Hersteller könnte es voll krass verschluesselt uebertragen und dann bist du erstmal chancenlos. Aber wahrscheinlich wird er nur ein paar Bytes und vielleicht eine Pruefsumme uebertragen und dann ist es mit etwas Phantasie kein Problem. Tip: Es gibt von Nordic ein Testprogramm fuer BLE das auf einem Androidhandy lauft. Wenn du die Grundlagen von BLE verstanden hast dann koenntest du mal probieren ob du damit sinnvolle Daten von deiner Waage auslesen kannst. Olaf
Frank schrieb: > .. oder kann man solche Gerät nur > ansprechen, wenn man das Protokoll vorliegen hat? BLE Gerät kann man fragen was sie können. Viele batteriebetriebene Gerät antworten dann z.B. das sie "0000180f-0000-1000-8000-00805f9b34fb" unterstützen..
> Du musst eine Firmware vom Hersteller aufspielen und dann diese Libary in deinem eigenen Programm benutzen. Das nimmt dir schon 90% der Arbeit ab, aber die restlichen 10% sind auch noch Arbeit. Danke für die Infos. Man spielt anscheinend erst ein "Soft Device" auf, das den Bluetooth-Stack bereitstellt, dann eigene Firmware. Es scheint keine fertige "AT-Firmware" vom Chiphersteller zu geben, aber von Drittherstellern gibt es Platinen mit diesem Chip und AT-Firmware, z.B. BlueFruit von https://www.adafruit.com/product/2479. Mit der Firmware wäre ich vermutlich da, wo das (etwa teurere) RN4871 on Microchip ab Werk ist: BLE-Modul mit Textbefehlen. Was ich jetzt noch gerne wissen würde: Wenn man die Beschreibung der Waage hat (übrigens Modell "skale 2" von http://skale.cc/en/buyIntl.html), womit eigentlich nur die UUID angegeben ist, kann man dann davon ausgehen, dass die AT-Firmware die Waage auch ansprechen kann - oder muss die AT-Firmware bestimmte "Services" unterstützen, so wie SPP bei klassischen Bluetooth-Modulen? Bei adafruit steht z.B. "The following commands allow you to interact with various GATT services present on Bluefruit LE modules when running in Command Mode" (https://learn.adafruit.com/introducing-the-adafruit-bluefruit-le-uart-friend/ble-services) Woher weiss ich, auf welchen Service ich bei der Modulauswahl achten sollte? Ich finde in der kurzen Protokollbeschreibung der Waage keinen Hinweis auf einen Service. Nur die UUID: BLE API SPECIFICATION for Skale I and II: Weight comes in on 0000EF81-0000-1000-8000-00805F9B34FB Like so: 0x07: length 0xff: manufacture data 0xef: service header byte1 0x81: service header byte2 0x__ weight val byte1 0x__ weight val byte2 0x__ weight val byte3 0x__ weight val byte4
Falls es jemanden interessiert, bei arrow bekommt man das Microchip RN4871-I/RM130 zur Zeit mit Gratis-Expressversand aus den USA (https://www.arrow.de/products/rn4871-irm128/microchip-technology) für 6,27€ https://www.arrow.de/products/rn4871-irm130/microchip-technology
Die UUID ist der Schlüssel zu dem GATT-Service, den Du im Code des Applikationsprozessors im Modul anlegen musst. Dnach kommen dann noch 8 Bytes, die die Informationen enthalten. Deinen AVR kannst Du Dir sonstwo hin drücken, der ist hier nur im Wege. Dein Code läuft komplett im Modul ab. Der Cortex M4 hat mehr als genug Resourcen dafür. Nordic ist ein beliebter Hersteller entsprechender Chips. Die beiden Alternativen wären TI (CC254x und CC264x, http://www.ti.com/wireless-connectivity/simplelink-solutions/bluetooth-low-energy/overview/overview.html ) und SiLabs ( https://www.silabs.com/products/wireless/bluetooth/bluetooth-low-energy-modules ). Letztendlich wirst Du es immer mit einem Cortex M3 oder M4 Applikationsprozessor zu tun haben. Schau Dir die Hersteller an, und starte vielleicht erstmal mit einem Hersteller-Evalboard. Da ist oft schon ein Debugger, zusätzliche Peripherie und eventuell auch Strommess-Hardware mit drauf (keine Ahnung, ob das für Dich relevant ist). Damit kannst Du dann in die Serie gehen. fchk
Aktuell ist die nRF52 Reihe von Nordic Semiconductor state of the art. Im allgemeinen sind Anwendungen basierend auf BLE aber (noch) nicht ganz so einfach umzusetzen. Die nRF52 Reihe löst die nRF51 sowie von TI der CC2650. Das sind alles SOC, haben also bereits eine MCU integriert. Wenns kein BLE sein muss, dann würde ich, der einfachheitshalber auf die HC-05/HC-06 setzen. Die können dann mit einem AVR über UART und AT commands gesteuert werden.
Frank K. schrieb: > Deinen AVR kannst Du Dir sonstwo hin drücken, der ist hier nur im Wege. > Dein Code läuft komplett im Modul ab. Der Cortex M4 hat mehr als genug > Resourcen dafür. Jein. Genug Ressourcen schon, aber wenn man z.B. einen Nordic mit softdevice nutzt, hat das softdevice immer die höchste Priorität und kann der Applikation (im wahrsten Sinne des Wortes) jederzeit dazwischen funken. Kommt halt ganz auf die Anwendung an, ob das okay ist.
FK schrieb: > Frank K. schrieb: >> Deinen AVR kannst Du Dir sonstwo hin drücken, der ist hier nur im Wege. >> Dein Code läuft komplett im Modul ab. Der Cortex M4 hat mehr als genug >> Resourcen dafür. > > Jein. Genug Ressourcen schon, aber wenn man z.B. einen Nordic mit > softdevice nutzt, hat das softdevice immer die höchste Priorität und > kann der Applikation (im wahrsten Sinne des Wortes) jederzeit dazwischen > funken. Kommt halt ganz auf die Anwendung an, ob das okay ist. Wenn das ein Problem sein sollte, wäre z.B. ein TI CC2642R geeigneter. Da läufen die zeitkritischen Sachen auf einem extra Cortex M0. Wie es bei SiLabs ist, weiß ich nicht. fchk
Ich würde hier mal noch u-blox reinwerfen. Sind Recht einfach zu konfigurierende BLE auf uart Wandler mit nRF52. Da muss man sich nicht mit dem Bluetooth Stack abmühen.
FK schrieb: > Frank K. schrieb: >> Deinen AVR kannst Du Dir sonstwo hin drücken, der ist hier nur im Wege. >> Dein Code läuft komplett im Modul ab. Der Cortex M4 hat mehr als genug >> Resourcen dafür. > > Jein. Genug Ressourcen schon, aber wenn man z.B. einen Nordic mit > softdevice nutzt, hat das softdevice immer die höchste Priorität und > kann der Applikation (im wahrsten Sinne des Wortes) jederzeit dazwischen > funken. Kommt halt ganz auf die Anwendung an, ob das okay ist. Die maximale zusätzliche Latenz wird von Nordic aber angegeben, z.B. für M4/S140: Open peripheral interrupt: Softdevice enabled: < 3 μs Softdevice disabled: < 1 μs Blocked or restricted peripheral interrupt: Softdevice enabled: N/A Softdevice disabled: < 2 μs (only forwarded when SoftDevice disabled) Application SVC interrupt: Softdevice enabled: < 2 μs Softdevice disabled: < 2 μs Wenn das für die eigene Applikation passt, ist ja alles OK.
nfet schrieb: > Ich würde hier mal noch u-blox reinwerfen. Sind Recht einfach zu > konfigurierende BLE auf uart Wandler mit nRF52. Da muss man sich nicht > mit dem Bluetooth Stack abmühen. u-blox hat viele Produkte. Was meinst Du genau?
Hi, ich möchte hier mal die Cypress Produkte ins Rennen werfen http://www.cypress.com/products/ez-ble-and-ez-bt-bluetooth-modules Zum einen hat Cypress vor 2(?) Jahren den Bereich Embedded BLE/WiFi von Broadcom übernommen, und mit den PSoC BLE auch eigene Produkte. Es gibt einiges an (fertigen) Beispielen und die Programierung (zumindest für die PSoCs mir bekannt) ist die einfache IDE, PSoC Creator. Ausserdem haben die PSoCs auch noch einiges an Peripherie bis hin zu eimem mini FPGA/PLD (nennt sich UDBs) auf dem Chip, was auch interessant sein könnte. Und jeder GPIO lässt sich auch als Kapazitssensor für Touch-Bedienung (z.B. Button, Slider, etc) verwenden. Alles in allem bekommst Du damit weit mehr als reines BLE. Die zertifizierten Module sind teils kleiner als 1cm². Grüße Mic Roller
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.