Android - BlueTooth LE Advertise Broadcast Bytes empfangen

[Rollo62]

Hallo mensch72,

ich benutze auch das Filtern im Devicenamen (aber andere Module).
Habe festgestellt das es bei Android/iOS gut funktioniert nach
mehreren verschiedenen Geräteklassen zu filtern.
So in der Art Prefix "xyz-...".
Zusätzlich ein Filtern der UUID mit dem AList Parameter.

Allerdings beim Entwicklen mit Delphi unter OSX scheint es eine Obergrenze von 3 UUID-Filtern zu geben.

Ist dir das auch aufgefallen, gibt es da eine Einstellung um das zu erhöhen ?

Rollo

[OrtmannMedia]

Hallo mensch72,
den SS habe ich noch nicht verwendet (ist wohl noch default). Hier mein dump:

BTA=001EC030B638
Name=BLUTEST
Connected=no
Bonded=001A7DDA7104,0
Server Service=80000000
Features=04000000
TxPower=4

Ah, danke, ja den Y brauche ich bevor ich die Daten wieder ändere.
Beim Start gings bei mir wohl 1x so, weil ich AutoAdvertise aus habe.

Ok, ja, ich würde wohl dann die Firmware mal updaten.
Soweit ich gesehen habe gibt's da ein Tool. Allerdings ist mein RN ja schon eingelötet,
muss mal sehen wie ich das da über meinen PIC rüberübertragen kann.

[mensch72]

Mit dem Updateprogramm von Microchip habe ich wie auch andere im INet schlechte Erfahrungen, Installiere und starte es, dann such dir dessen TempVerzeichnis wo es die Firmwarefiles ausgepackt zur Programmlaufzeit ablegt... sichere dir die Dateien und dann nimm ein Terminalprogramm ala TerraTerm, so steht es auch in der Doku zum USB-RN4020 Demoboard für Firmwareupdate.

Also: Wenn Modul schon eingelötet und du ja so ein Demoboard von Microchip mit USB Anschluss hat, dann würde ich dir raten, mit deinem PIC dein Modul nur OTA kompatible zu initialisieren (SR,???????? & SS,????????)... dann mit TeraTerm das USB-DemoBoard auch passend initialisiern (SR,???????? & SS,????????)

mit E connecten
mit ~,2 OTA Mode aktivieren
mit TerraTerm das UpdateFile(!!!BINÄR-ModeHäcken nicht vergessen!!!) per USB ans Demoboard schicken, das leitet es an dein verbundenes Modul weiter

Vorschlag: "probiere" es erst mit dem USB Demoboard selbst (kein "E connect" und "~,1" für DFU selbst Update)... dann hast du zuerst die aktuelle Firmware auf dem Demoboard

Morgen ist Montag, da kann ich dir im Büro die passenden SS & SR Einstellungen per PN senden (leider mehrfach schon mit großer Stückzahl "getestet").

[mensch72]

@Rollo62
Das hier diskutierte RN4020 BLE Modul kann schlicht nur einen PrivateService(128Bit-GUID) und hat wenn man will auch ein paar DefaultServices(16Bit-StdID).
Das RN4020 kann im Advertise nur einen sogenannen "PrimaryService" verbindungslos als "Broadcast-Info" gleich mit senden.
Wenn man es genau nimmt, ist das Modul leider nicht ganz sauber BLE konform, daher gibt es unter Android4.4 und alten IOS ein paar Sachen die unsicher gehen(wenn ich im Büro schon 2..3 Geräte finde wo eine PermanentScanApp nicht läuft, ist die Funktion unabhängig wer schuld einfach nicht benutzbar).

Solltest du wirklich noch XE8 nutzen, dann ist der AdvertiseScan dort mehrfach geändert worden (XE7->XE8rtm->XE8updates).
Wir haben die XE8 BLE Sourcen damals per Hand bereinigt(und dies nicht an Emba per QC gemeldet). Im XE10rtm.. haben wir weiter mit "unseren" XE8 BLE Files gearbeitet, erst jetzt mit aktuellem Berlin (10.1u1) haben wir mal wieder einen OutOfTheBox Test mit den org. Emba-BLE-Sourcen gemacht und es geht soweit vergleichbar unserer XE8-Patchlösung.

Filtern ala "AABBCCDD-*".. das nutzen wir, haben es aber jetzt nicht mehr in die EMBA BLE Source eingepatcht, sondern machen es im Soucre der APP sauber selbst, weil die Geräte mittlerweile schnell genug sind die Eventcalls auch für 100 BLE Geräte im Scan sauber zu liefern. Wir nutzen von der 128Bit GUID des PrivateServices 32Bit als fixe Systemkennung und 96Bit als variablen Broadcast-Payload, das zusammen mit den 40Bit Base64 kodierten BLE Namen gibt 17Bytes "AdvertisePayload" welcher 100% Android&IOS kompatibel ist.
Wir sind für einen der großen Systemanbieter im Hotelbereich tätig, da muss Zimmerzutritt und Raumsteuerung mit JEDEM Gastgerät was irgendwie BLE kann funktionieren. (Rückwärts)Kompatibilität geht daher bei uns vor Funktion / neuestem Standard.

(unsere Erfolgsquote ganz ohne Whitelist/Blacklist liegt trotz/wegen RN4020 und Delphi-BLE-Handmade sehr hoch, auch gegen Mitbewerber mit eigentlich besseren Hardwaremöglichkeiten oder native Java/Xcode-APPs)

[OrtmannMedia]

Hallo,
oh, inzwischen habe ich das schon probiert. Das DemoBoard konnte ich updaten. Hat geklappt.
Bei meiner Schaltung habe ich im Pic uart1<->uart2 mit cts/rts flow alles aufgesetzt.
Konnte prinzipiell gut direkt kommunizieren mit dem RN4020 dann.
Aber - leider hat das Firmwareupdaten hier nicht geklappt, kam keine Antwort mehr und jetzt kommt
es nicht mehr hoch. Ich probier mal ein hartes reset. Ansonsten muss ich es wohl austauschen...
Ja, das wäre super, wenn Du mir die SS, SR settings noch sagen könntest. Dann mache ich das direkt mit
den Binärfiles.

[OrtmannMedia]

Ah, ich hatte falsch verstanden. Du meintest über das Demo-Board per BT-Verbindung mein RN updaten?

[mensch72]

ja "simples" OverTheAir RemoteUpdate von einem RN4020 per BLE auf das andere... das ist doch auch die zukünftige Standardvarianten, wenn du mal dein Zeug draußen beim Kunden "durch die Luft" aktualisieren willst/kannst

Aber gräm dich nicht, auch wir kalkulieren mit 1% "Schrott" wenn wir die RN4020 updaten. Microchip ist kulant und tauscht dir die (auch ausgelöteten) Module, die wissen, was sie (anfangs) für einen Müll ausgeliefert haben

[Rollo62]

Unter 10.1 Berlin, (aber erst Upd1 bis jetzt) hat das UUID-Filtern gut funktioniert bei den Mobilen.
Nur eben nicht unter OSX.
Das ist nicht so wichtig, weil es ja noch eine mobile App ist, aber es nervt beim Entwickeln.
Ich muss immer die Geräte die ich gerade nicht teste unter OSX per define wegschalten, und kann max. 3 Filter gleichzeitig machen.

Habe noch nicht zu tief danach gesucht, ich denke fast das könnte eine Beschränkung von OSX sein.
Habe bisher aber nichts dazu gefunden.

Wenn du RN4020 einsetzt, darüber hatte ich damals auch schon nachgedacht, es gibt allerdings mittlerweile eine Menge günstiger Module.
Ist das RN4020 noch zu empfehlen ?

Ich hatte mich zwischenzeitlich auch mal mit Cypress PROC beschäftigt.
Bei asiatischen Modulen liegen wir aber mittlerweile unter 3USD, das Problem sind dann
immer die Zertifizierungen.


Rollo

[mensch72]

Da wir Anfang 2015 ein Modul suchten, was sich an unsere Batteriegeräte mit 8Bit Microcontroler einfach (seriell) zur Nachrüstung anschließen läßt, blieb damals nicht viel Auswahl übrig. Bei 330msec Advertise braucht das RN4020 bei deaktiviertem SW_WAKEUP-PIN nur 10..20uA (integriert über 3x Pulse pro Sekunde). Das ist ein echt guter Wert, weil die eigene CPU im DeepSleep bleibt bis "Connected" als ganz viele H->L Flanken vom Modul bei Verbindung gesendet wird und selbst ein lahmer 8Bit-Pic davon wach wird!

Microchip hat "gelernt" und hat nun mit dem RN4871 einen super Nachfolger für das RN4020 heraus gebracht. Ist kleiner und noch flexibler in der Funktion, und ganz wichtig: auch wieder echt Standalone und für Batt Geräte geeignet sowie noch technologisch einfach zu löten (nur Pads ringsum, kein BGA von unten)

Chinamodule kenne ich auch, bringen nix wenn man keine Garantie auf Langzeitverfügbarkeit hat.

Wenn man genug Manpower für eine volle eigene BLE Zertifizierung(Stack incl. OverTheAir-Updates) hat, dann kann man auch nur "Chips" kaufen und "das bissel Analogkram" ringsum selbst auf eine Platine bringen, ich habe mich wegen Aufwand und mangels eigener Messtechnik dagegen entschieden.
Wenn hätte ich den "Nordic" genommen... die beste Kombi aus BLE-Coprozessor und freiprogramierbarem ARM in einem kleinem Minichip.

CypressPSOC kenne ich auch, wer viel Analogkram braucht könnte darüber nachdenken, ich mag das PSOC Konzept nicht. Mir reicht schon unser PIC Zeug das zu nix kompatibel ist. Wenn dann würde ich was wie Nordic zukunftssicheres auf ARM Basis nehmen, da gibt es Software und Leute die sich auskennen wie Sand am Meer.

Bei den bezahlbaren BLE Modulen, also bei so ~5USD/1000Stk steht das RN4871 mit seiner Funktion, seiner Handelbarkeit und seiner wie bei Microchip üblichen Langzeitverfügbarkeit incl. Support für mich weiter ganz oben. Das Ding ist so klein, das wir es um 180° gedreht bei neuen Platinendesigns einfach im Antennenbereich des RN4020 als Bestückungsalternative mit vorsehen, weil wir wohl StepByStep darauf umstellen werden.

[Rollo62]

Module auch China sind auch nur Nachbauten der drei Verdächtigen: TI, Nordic, Cypress.
Nur eben günstiger, und auch teilweise mit Zertifikaten.
Wir haben nicht immer Einfluss drauf was in die Produkte eingesetzt wird, deshalb
bin ich froh wenn es denn funktioniert.

Cypress hatte ich deswegen gesehen weil die auch als Erste ein BT Mesh gezeigt hatten,
noch bevor der Standard fertig war.
Das wäre für mich hochinteressant, quasi ein Zigbee auf BLE, mit Phones Laufen zu haben.
Ich bin auch kein Freund von PSOC, aber man hat für ein einfaches BT Modul kaum was damit zu tun, und die IDE ist sehr gut dokumentiert.
Das abgespeckte PROC hat auch kaum Analogfunktion, und ist deswegen etwas günstiger.
Wir brauchen eigetlich nur ein Gateway RS232 zu BLE, dafür ist das einfachste Modul i.d.R. auch gut genug.
Wenn Microchip mittlerweile so günstig liegt ist es auch kein Grund nach etwas anderem zu suchen, das neuere Microchip-Teil muss ich mir dann nochmal ansehen.

Rollo