@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)