Android - BlueTooth LE Advertise Broadcast Bytes empfangen

[OrtmannMedia]

Hallo,
ich habe eine Hardware, die sendet per BlueTooth LE (4.1) broadcasts im Advertise modus.
Also da können ja 25 Bytes als PayLoad gesendet werden.
Diese möchte ich nun mit meiner Android-App empfangen.
Mit BlueToothLE1.DiscoverDevices(15000); bekomme ich das Gerät auch schön gelistet,
und habe dann im event TForm1.BluetoothLE1EndDiscoverDevices auch das Device gelistet:
ADeviceList[i].DeviceName...

Jetzt möchte ich die Payload, also die Broadcast bytes haben.
Leider gibt die Help garnix her... aber z.B. habe ich gefunden
ADeviceList[i].AdvertisedData. ...
Das hört sich zumindest schon mal so an.

Wer kann mir helfen, wie kann ich die Bytes zu empfangen, bitte?
Viele Grüße, Jürgen

[Rollo62]

Hast du die Demos BleScanner und ExploreDevicesLE ausprobiert ?
Da kann man schon eine Menge Geräte mit analysieren.

Rollo

[OrtmannMedia]

Hi, oh, stimmt gibt's ja Samples. Probiere ich erst mal. Danke, Jürgen

[mensch72]

schaue dir die "AdvertisedData" BINÄR an, verlasse dich nicht auf die Erkennung&Aufteilung durch den BLE Stack&Delphi... suche dir also deine PayLoad-Daten und verifiziere sie selbst(z.B. durch eine eigene CRC), lass dir was zum Thema Simulationssicherheit durch Fremde einfallen! (BLE-Name+XYZ als "SALT" der CRC oder was auch immer, verwende nicht die MAC des BLE Gerätes, weil die bekommt deine App unter IOS leider NICHT heraus, weil Apple die nur für eigene Zwecke intern verarbeitet und den APPs nur einen HashID zur Geräteidentifikation anstatt der BLE-MAC herausgibt.

Verwende bitte mindestens IOS9.x oder Android 5.1 oder neuer... IOS8.x und Android 4.4.x und Android 5.0.x hatten das Problem, das sich erstens die PrimaryServiceID nicht sauber als AdvertiseFilter nutzen ließ und zweitens sich die AdvertiseDaten(PayLoad und Name) nicht aktualisiert haben, wenn die BLE MAC einmal erfasst wurde (CacheProblem im AndroidStack, da half nur gesteuertes BLE Disable,Wait,"DisabledCheck" und Enable... wenn "BLE-Disable nicht binnen 3sec möglich, Hinweis an Nutzer, doch bitte mal sein Gerät hart neu zu starten)

Da der AdvertisePayload im BLE "zeitlich" begrenzt ist, sollte man möglichst kurze Namen(bis 8Standard-ASCII-Zeichen und nur eine PrimaryServiceID im BLE Gerät konfigurueren und den Payload als "UserDefined" wenn man echt die Daten will(das verhindert das OS-Services den PayLoad "abfangen", wie sie es bei erkanntem "BeaconPayload" machen), wenn man lieber einen AutoWakeup+AutoStart seiner App möchte, dann sollte man seinen BLE-Advertise-Payload als "BeaconSimualtion" OS kompatibel senden... dann klappt wenn man es geschickt anstellt das sogar unter IOS(ist aber etwas tricky und nur rechtlicher Graubereich ohne echte Apple-MFI Lizenz;) )

Prüfe wenn IOS für dich wichtig bitte immer zuerst was unter IOS geht, denn es gilt grob gesagt: alles was unter IOS geht, klappt auch unter aktuellen Androids, umgedreht gilt das leider NICHT! Speziell bei NonStandard BLE Daten verhält sich Android gutmütig und gibt alles an seine APPs weiter. Bei IOS bekommt man nur das, was Apple einem freigibt und durchreicht. Seit Apple IOS Richtung SmartHome intern erweitert, ist aktuelles IOS gerade wieder verschärft wurden, da bereitet man intern eine weitere Lizenzstruktur im Advertise Payload für offizielle MFI kompatible BLE Geräte vor. (Nach "Connect" kann ja jeder machen was er will, aber gerade das "normale" Advertise als verbindungsloses BroadCast für eigene Daten(änderungen) zu nutzen... da arbeiten Apple und andere wie auch wir gerade ausgiebig daran:) )

[MyRealName]

Da will ich mal kurz ne Frage einwerfen, vielleicht wisst ihr das ja als BT Experten :)

Wenn ich einen externen Kamera Auslöser habe, der sich ja beim Android Gerät als Keyboard anmeldet, und ich mochte den Knopfdruck in meiner App mitbekommen, dann kann ihc das OnKeyPress Event des Forms nehmen während die App im Vordergrund ist.

Wenn sie im Hintergrund ist, krieg ich das nicht mehr...
Gib es eine Chance, das Event zu bekommen ?

Danke :)

[OrtmannMedia]

Hallo mensch72, danke,
ja Android 5.1 mache ich als Voraussetzung. IOS wird nicht unterstützt werden.
Sender ist ein Microchip RN4020. Ich setze den in Broadcast mit ein paar bytes Payload
(z.B. Temperaturmess-Daten) und lasse ihn advertisen (mit no direct advertisement,
so dass ihn alle nicht-gebondeten Devices sehen müssten, wenn sie vorbeikommen).
Im 100ms Intervall, invinite.
Die Payload-Daten selbst enthalten auch noch ein paar Bytes extra für eine Id, damit ich ein bisschen weiss, obs auch meine Payload ist und zur Fehlererkennung usw.
Autowake/start der App brauche ich nicht. Die App wird vom Anwender gestartet und soll sich dann
auf klick auf die Suche machen und die Temperatur anzeigen. Sonst eigentlich nix.
Habe dem RN4020 schon einen (kurzen) DeviceName gegeben, und das Ding wird
nach DiscoverDevices auch schon gefunden und gelistet.
Nun eben noch, womit komme ich an die Payload? :)

[mensch72]

Ich behaupte, ich weiß hier zufällig mal sehr sehr gut Bescheid... "zufällig" setzen wir auch das RN4020 von Microchip von Anfang an ein, sogar in mittlerweile 5stelliger Stückzahl :)

Welche Softwareversion hast du auf dem RN4020?
(V1.20/V1.23 oder V1.33+ ... alles unter V1.20 ist Schrott, lässt sich aber per DFU/OTA updaten)

Hast du am RN4020 noch ein eigenes Programm(z.B. Microcontroler), oder willst du es per "Script" Standalone im Modul machen?
(Script unter V1.23 funktioniert nie wirklich gut, und wirklich drauf verlassen tun wir uns auch aktuell nicht, wir setzen immer einen eigenen Microcontroler zur Modulsteuerung und Powermanagement bei BattSystemen ein)

Wie konfigurierst du dein Modul?
(... sag mal deine "SS" & "SR" Werte)

Wenn es dir wirklich nur um ein paar Bytes(bis zu 5Bytes+1ByteCRC) eigenen Payload im Advertise geht, würde ich dir sogar als schnelle und 100% Android&IOS kompatiple Alternative empfehlen, nur den BLE Advertise Namen (SN oder S_ Komando) als 8Zeichen Base64 kodierte 6Bytes zu nutzen und eine 16ByteGUID als PrivateService zu definieren, womit du "deine Geräte" erkennen und vorfiltern kannst. Dann einfach bei allen 8Zeichen langen BLE Namen diese Base64 decodieren und die CRC der 5+1Bytes prüfen... so machen wir das nebenbei auch noch, weil das Verfahren 2 Vorteile hat: Die BLE Namen sind "unlesbar" was den Spieltrieb von Leuten mit BLE Scannern deutlich reduziert, das Verfahren bietet "zusätzliche" 40Bit Payload und funktoniert sogar mit allen Wald&Wiesen BLE-Modulen sowie ab Android 4.4 und IOS8.x :)

[OrtmannMedia]

Oh, wow, das ist allerdings ein sehr schöner Zufall!
Super :)

Ja, der wird über einen PIC32MX340 angesteuert.
Habe mal ausgelesen, mein Modul, in meinem Projekt,
antwortet mir mit Version "MCHP BTLE v1.23.5 8/7/2015".
Habe die von Microchip Direct Ende letzten Jahres bekommen.

(Ausserdem habe ich aber noch so ein Demo-Board von Microchip,
das man über USB am PC ausprobieren kann,
das hat noch das 1.20 drauf sehe ich grade.)

Ich habe mir das Setup lt. User Guide mal so ausgedacht:

SN,BLUETEST
SR,04000000
R,1
N,12345566
A

Lasse ich das N, .. weg,
dann kommt das Teil beim Scannen als BLUETEST auch gelistet.
Mit N, ist es unsichtbar.

Jedoch:
Inzwischen habe ich das Demo-Board mit
SR,80000000 (set to central)
R,1
F
J,1
aufgesetzt. Und es sausen die Broadcast-Daten daher.
Also scheint das Broadcasten schon zu klappen.

Jetzt müsste ich die bytes noch in Delphi reinbekommen.
Hier bin ich leider noch nicht so weit.

Ansonsten, ja stimmt, könnte man auch im DeviceNamen was so geschickt reintun.
Und PrivateService definieren u. filtern.
Hat ja sogar nennenswerte Vorteile wie Du schreibst.
Muss ich mal nachdenken.

Die Broadcast-Daten bekomme ich die überhaupt mit Delphi?
Wenn nicht, wäre eben die DeviceName Idee eine Lösung.

[mensch72]

der SS Wert wäre noch sehr wichtig!

oder mach mal ein "D" wie "Dump" und gibt mal die gesamte Rückgabe

[mensch72]

deine zwar gut gedachte Kombi aus

Y ...als "Disable(Auto)Adverise" fehlt, sonst kann man keine AdvertiseDaten setzen/ändern
N,12345566 ... klar das sollen deine Broadcast Daten sein
A ... EnableAdvertise

klappt so leider trozdem nicht, da der BroadCast(Beacon)-Mode des RN4020 vor Version 1.33 leider zu nix kompatibel ist!

Entweder du machst überall V1.23 drauf und nutzt den BLE Namen, oder mach das Update auf V1.33 und lies dir von Microchip die ReleaseInfo durch, das steht recht gut beschieben wie du echt binär mit Kennung deine Zusatzdaten für das normale Advertise definieren kannst. ("N" ist was für ala "BeaconMode"... wir verwenden es nicht, weil nicht kompatibel zum BLE-Standard.Scan unter Android&IOS)

[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

[mensch72]

Für BLE-"Mesh" hat auch Microchip für das RN4871 (bzw. teils auch nur für das Baugleiche BM71) eine PreRelease Firmware.

Microchip und seine Distributoren(wie z.B. FutureElectronics) geben auf Anfrage aber alles raus und verweisen auch auf Kunden, welche schon damit testen/arbeiten(wie z.B. wir;) ) Da wir historisch gewachsen nunmal alles mit PICs von Microchip machen, haben wir dadurch eben auch guten Kontakt zu den Leuten und bekommen beim BLE eigentlich auch per Updates das was wir "brauchen/wollen".

Z.B.: wir hatten als erste die Idee, ein BLE Modul könnte abwechsend sich mal als Beacon und mal als StandardBLE Devive per Advertise melden... da wir kein Interesse an Patentanmeldung und so was haben und auch keinen Patch eines StandardStacks(z.B. Nordic) machen wollten, wird das bald offiziell von Microchip in deren BLE-Modulen verfügbar sein. Eventuell kommt die Demosoftware bzw. ein Link dazu für Delphi&C++Builder sogar von uns:)

[Rollo62]

Das wäre ja super :-)
Ein Grund mehr zu Microchip zu wechseln.

Rollo

[OrtmannMedia]

Hallo mensch72,
leider habe ich beim Wechseln des rn4020 mein Board irgendwie zerstört.
Ich muss aus anderen Gründen sowieso ein re-design durchführen, d.h. die nächsten zwei Wochen, kann ich mal nur mit dem Demo-Board und Delphi experimentieren.

Da ich nun sowieso das PCB neu mache, sollte ich vielleicht gleich den RN4871 statt den 4020 drauf tun?
Hat der bei Dir soweit gut geklappt?
Bestimmte Firmware Revision, die ich gleich drauf tun sollte? ;)

Viele Grüße aus München

[mensch72]

ich würde aktuell beides vorsehen... braucht auch nicht viel (Zusatz)Platz:)

[Rollo62]

Ist das nicht ein bischen kritisch mit der Groundplane und evtl. freien Flächen
um die Antenne ?
Microchip gibt da Refernzdesigns an, ich meine immer mit genügend Luft drumrum.

oder hast du damit immer optimale Reichweite, weil die Module schon optimierte Groundplanes haben ?
(ich hatte tatsächlich schon ein integriertes Gerät gesehen was nur 5m weit kam, natürlich aus China, die haben das mitten auf eine größere Platine gesetzt).

Mit unseren Lösungen kommen wir realistsich durch z.B. eine Wand ca. 15m weit,
mal mehr mal weniger.
Im Freifeld habe ich noch nicht wirklich gemessen.
Auf der letzen Electronika hat mir ein Microchip/Atmel-Ingenieur auch versichert das man mit BLE und aktuellen Phones nicht viel mehr erwarten kann, Maximum vielleicht 30m


Rollo

[mensch72]

Nebenbei: Für uns ist zuviel Reichweite sowieso ehr störend!

Im Standard(Türöffnung oder Zimmersteuerung) wollen wir nur 1..5m, daher haben alle Physiker Recht, das was wir da "designen" ist HF technischer Mist, aber es funktioniert für unsere Anforderungen ausreichend gut:)

Kommt also auf die Anwendung an. Aber wenn ich diese Pads so am Platinenrand anordne und ringsum mich an die Vorgaben zu Freiflächen und Groundplane halte, sollte die OPTIONALE 180° Bestückung HF technisch fast völlig unschädlich sein. Es geht ja nicht darum beide Module "überlappend" zu bestücken;)

Und ja, auch wir setzen das mit vorliebe "mitten" in eine Platine, welche z.B. im Standard hinter einer 55x55mm Blende eines "Lichtschalters" oder "IT-Steckdose" sitzt.

[Rollo62]

Dann sind wir wohl beide noch in der glücklichen Lage das uns die Performance nicht so interessiert, denn unsere Geräte werden auch "am Mann" getragen,
also ist eine Reichweite nicht so relevant.

Ich denke aber das Thema wird früher oder später hochkommen.

Es kommen jetzt schon die Anfragen mehrere Geräte zu verbinden, wo auch mehrere Personen im Team arbeiten.
Dann würden sich mehrere BLE an einem Phone anmelden, oder eben ein Mesh bilden,
denn da kann die Reichweite schon kritisch sein.
Wie das unter Fmx geht da bin ich noch auf der Suche, allerdings nur nebenbei.

Könnte mir vorstellen das die Beacon-Technologie etwas dafür hergibt, aber die verbinden die sich ja gar nicht wirklich.
Ein Gedanke war das wir unsere Daten wirklich nur als Beacon-Payload absenden, es sind auch nur ein paar Byte Messdaten.
Auf die Art könnte man einfach mehrere "Beacons" suchen und hat gleich alle Daten ohne viel Verbindungsaufwand mitgeliefert.
Da es dann doch nicht so einfach ist könnte ein gemischter Beacon/Ble Betrieb sehr sinnvoll sein.

Rollo

[mensch72]

Im März auf der "embedded 2017" werde ich mich in Nürnberg mal wieder auf den aktuellen Stand der Kombo-Software für alternierendes Beacon+Standard Advertise sowie die Pre/Beta Version der BLE Mesh Funktionalität bei Microchip machen.
Microchip hat da einen "neuen" FAE nun fest im eigenen Haus, den ich schon lange als Distri-FAE kenne... mit dem werde ich mal einen Kaffee in einer ruhigen Ecke trinken:)

Wir sind mit unseren Ansätzen zwar schon recht gut, aber im Bereich UARToverBLE(also BytePerByte Streaming) schafft Microchip mit eigenen APPs und Modulen so bis 4KB/sec, also etwas Netto um die 38400Baud... das schaffen wir mit eigenen APPs (noch)nicht... für Firmwareupdates würden wir sowas aber gerne auch mit dem Speed nutzen... nur da fehlt uns da mal ein SampleSource für IOS/JAVA/FMX... Microchip kann das zwar dokumentiert von Modul auf Modul, tut sich aber schwer sowas als Source für ein MobileOS zu veröffentlichen.

Wer das was hat darf sich gerne melden, wir haben dafür was zum "QuickConnect" binnen Millisekunden... ohne die Zeit für DiscoverServices:)

[OrtmannMedia]

Da habe ich was ähnliches auch schon bei mir und zwar für alternativ RN1810 und RN4020 :)
Klappt sogar, dabei die Sperrflächen nicht zu verletzen.
Ansonsten, ich muss mich nun leider wg. Re-design mal ettliche Tage hier ausklinken. Hoffe kann dann
wieder mit meiner Frage hier weitermachen. Bis bald, und Danke bisher!

[Rollo62]

Zitat:

wir haben dafür was zum "QuickConnect" binnen Millisekunden... ohne die Zeit für DiscoverServices

Da melde ich mich doch gerne, was gibt es denn da von dir :-)

Ich schlage mich seitdem ich BLE mache mit den Fmx Ble.Routinen rum, die öfters
mal Haken und das GUI einfrieren lassen.
Alle Versuche das in Threads zu packen etc. haben nur mittelprächtig funktioniert.
Bin zwar ganz zufrieden im Moment, aber das "Gelbe" ist es noch nicht.
Habe es jetzt aber auch schon dreimal komplett neu aufgebaut, seit XE8.
Ich brauche zwar keine "Millisekunden", aber wenn es dadurch auch stabiler werden kann ist es allemal ein Vorteil.

Hast du die ganzen BLE-Routinen für IOS/MacOS/Android nativ da reingeklöppelt ?

Rollo

[Rollo62]

Hallo Jürgen,

sorry das wir etwas von deinem Thema abweichen, ich gelobe Besserung.
Dachte du wartest noch auf dein neues Board zum Testen.
Ich hoffe damit kriegst du es dann gelöst.

Dein PCB sieht ja ganz gut aus, so wie die Antennenflächen übereinanderliegen sollte es
gut funktionieren.

Rollo

[OrtmannMedia]

Hallo Rollo, mensch72,
ja das passt schon, mich interessiert das Rand-Thema auch sehr :) Ja, muss noch auf das neue PCB warten.
Aber ich habe ja noch das DemoBoard. Zumindest das was ich eigentlich wissen wollte könnte ich damit auch
ausprobieren.
Hättet Ihr für mich so ein Mini-Setup für den RN4020, mit dem ich so einen Service starte?
Im Moment ist das Problem, dass ich eigentlich zwei Unbekannte habe, 1. ein nützliches Setup für den RN4020,
2. eben Delphi-Code mit dem ich das dann sehen kann.
Also vielleicht sowas mit
128BitGUID PrivateService advertisen. Egal welche payload nur
damit ich was habe womit ich dann Delphi-seitig weiterkomme,
das dann zu sehen.
Dann denke ich komme ich schon mal weiter.
Wie ich lese, war es wohl unter XE8 Problematisch,
und unter Berlin dann gut. Ist noch spannend jetzt für mich,
ob Seattle auch schon Ok war...

[mensch72]

Hast ne PN bezgl der "Setups" :)

[OrtmannMedia]

Hallo,
bekomme DiscoverServices nicht vernünftig zum Laufen.

Habe mein Board nun endlich wieder bereit. Mit RN4871 allerdings.
Und habe nun auch selbst geschafft diesen mit
1. Alternate Beacon (einige Bytes payload im Major/Minor part) oder
2. Private Service mit Characteristic read/write u. 128bit UUID aufzusetzen.
(der beacon läuft dann bei mir nicht gleichzeitig).
3. Device Info Service aufsetzen.
Und mache jetzt mit Tokyo rum.
Beacon kann ich mit Delphi Android app auch empfangen u. auswerten.

Den private Service kann ich mit einem zweiten RN4871 problemlos
connecten u. bonden und Daten bidirectional austauschen. Auch mit notification.

Leider - mit der Delphi App (Android 6.0.1) klappt das speziell das Listen der Services nur gelegentlich.
Und zwar habe ich eine BluetoothLE compo.
Starte DiscoverDevices. Alle meine RN4871 werden immer aufgelistet.

Mit einem Device starte ich dann DiscoverServices.
Und das klappt nur ca. jedes 10. mal dass die Services aufgezeigt werden.
Meist wird keiner gefunden. (Wenn doch, dann bekomme ich auch alle Characteristics problemlos aufgelistet).
Komisch auch, wenn ich DiscoverServices gleich nochmal starte, dann kommt
OnDiscoverServicesEnd sehr schnell/sofort. Scheint garnicht nochmal zu suchen.
Nimmt wohl was aus nem cache?

Klappt das Auflisten der Services bei Euch mit dem RN4020 oder 4871?
Was müsste ich ggf. beachten?

Wann muss ich eigentlich connecten?
Sollte ich schon bevor DiscoverServices, vielleicht? Oder erst wenn ich die Chars lesen will?

Viele Grüße, Jürgen

[Rollo62]

Hallo Jürgen,

damit kämpfe ich auch schon seit Wochen.
Es lief anfangs Alles super, aber ich habe mittlerwiele 12 ganz verschiedene Geräte unter einen Hut gebracht und sehe das es ziemliche Unterschiede im Verhalten gibt.

Insbesondere habe ich ein lokales Problem, es funktioniert in der Entwicklung ganz gut, gehe ich aber raus zum Kunden fliegen die Connections raus, oder er findet keine Connection.
Die Services auch manchmal ja, manchmal nein.

Ich habe mir extra ein paar Tests geschrieben, und ich vermute stark das es auch Funk-Störungen bei bestimmten WLan Konfigurationen gibt.
Ich kann mit der gleichen Konfiguration verbinden und den ganzen Tag verbunden bleben, bin ich
aber in anderer Umgebung dann fliegt die Verbindung alle 5 Sekunden raus.

Beides unter And/iOS dasselbe.
Nach etas Recherche gab es auch Hinweise dazu das soetwas mal unter Android 4.4.3 als Kinderkrankheit gab, aber ich denke das wird es nicht mehr sein.

Das Service-UUID Filtern funktioniert bei mir auch nicht gut, deshalb muss ich manuell filtern.
Weil die Steuerung vom Phone kommt liefert die bei Advertisen mal 7 mal 5 mal keins zurück, und das scheint normal zu sein.
Ausserdem ist das Verbinden und Verviceabfragen mal in 300ms, mal in 3 Sek., mal 6 Sek. mal gar nicht möglich.

Ich gehe mittlerweile davon aus das es nicht so wie zu Anfang war:
einmal verbunden, immer verbunden,
sondern das man BLE Verbindungen immer als etwas Temporäres ansehen muss.
Ich baue im Moment die Library um, so das ich notfalls schnell wiederverbinde in der Hoffnung das es schnell genug geht.

Ausserdem schenit es mit Threading Problemen zusammenzuhängen, denn die Fehler fangen an sobalb man an die Services geht, das Advertising ist noch OK.
Die Umstellung auf Rx10.2 hat ja das Threading komplett auf den Kopf gestellt, und ich Teste im Moment noch und versuche das Beste rauszuholen.
Auf iOS 10 habe ich mich noch nicht getraut upzudaten, denn im Moment geht es zumindest wieder einigermassen.

Ich habe auch so ein bischen das Gefühl das es mal geht und mal nicht.
Komme ich Abends gar nicht mehr klar und nichts wird sauber verbunden, dann kann es am nächsten Morgen schon wieder perfekt weiterlaufen.
Ganz so als würde sich das Phone irgendwelche Stati merken.

Edit:
Auch die Verbindung mit den Notify Characteristics läuft nicht immer sauber, und es muss wiederverbunden werden.

Ein DiscoverTimeout habe ich von 3500ms bis zu 15000ms probiert, das scheint aber relativ egal zu sein.

Es ist schon sehr nervig, und wenn ich andere Lösungen teste dann sehe ich das es auch zuverlässiger geht.
Sollte da evtl. doch etwas mit dem Delphi BT Stack nicht in Ordnung sein ?

Ich mache es in der Reihenfolge:
- DiscoverDevices
- DiscoverServices (ich denke vor dem DiscoverServices wird es automatisch connected)
- DiscoverChars
- ReadRemoteRSSI als final Test das jetzt Alles stabil ist.

Rollo

[OrtmannMedia]

Hallo Rollo,
danke für die Info.
Dann ist die instabile Verbindung nicht nur bei mir.
Das hilft mir schon mal. :)
Hatte gedacht, ich mache alles falsch, weil Mensch vor einigen Seiten ja geschrieben
hat, dass das mit den Services bei ihm out-of-the-box funktioniert. Das dürfte dann wohl
so nicht ganz exakt der Fall sein.

Und wie ich Dich verstehe, ists bei anderen BT Modulen auch nicht besser.
Dann bleibe ich wohl bei dem RN4871.
Welches hast Du eigentlich?

Dann werde ich mal auch so Loops verschachteln, die nach Bedarf mehrmals scannen und re-connecten usw.
Dürfte wohl eine etwas hackelige Kommunikation werden dann.
Aber ich muss eigentlich eh nur hauptsächlich so Config Daten übertragen/lesen, also recht wenig.
Guid werde ich auch manuell filtern.
Werde auch noch experimentieren mit Standort.
Also, ich fürchte ansich ists wieder ein Delphi Problem.

Jedenfalls, ist es nicht normal, dass DiscoverServices bei jedem zweiten Versuch
sofort zurückkommt ohne gescannt zu haben.
Ist das bei Dir auch der Fall, und loopst einfach so lange drüber, bis es klappt?

Viele Grüße

[Rollo62]

Hallo Jürgen,

ja ich mache DiscoverServices solange bis ich etwas gefunden habe, in einer Zeitgesteuerten Schleife alle 5 Sec..
Hier gehr auch nur jedes 2te Mal, meistens aber auch beim ersten Mal.
Hängt halt irgendwie davon ab was das Phone dir gerade zurückschickt.
Woran das genau liegt kann ich nicht sagen, aber iPHone und Android tun sich hier nichts.

Vielleicht liegt es ja auch einfach am BLE Standard, wo die Geräte mit mehr oder weniger großen Zyklen
sich synchronisieren müssen.
Ist klar das 20ms Advertising besser/schneller läuft als 400ms.

Alles das ist akzeptabel, was aber enorm nervt ist das Verlieren verbundener Geräte, das habe ich teilweise auch.
Ich habe so gewisse Orte wo das Verbinden extrem schlecht funktioniert.
Bei mir im Büro (auch 2-3 Wifi Netzwerke, >= 7 aktive WiFi Geräte, bis zu 12 BLE Geräte verschiedener Kategorie und Hersteller), da klappt Alles perfekt.

Sobald ich zum Kunden damit fahre funktioniert die Verbindung nicht zuverlässig.
Das ist sehr blöd, weil wenn ich den Grund wüsste was passiert könnte ich das debuggen,
aber so ist es ein Try and Error.

Ich benutze hier TI Module und Cypress Pioneer Kit zum Basteln, aber die Geräte die ich
einbaue kommen aus China und enthalten mehr oder weniger unbekannte Module.
Oft aber nicht immer von den üblichen Herstellern TI, Nordic, aber mir ist jetzt auch ein exotischer Dialog Semiconductor untergekommen.
Ich vermute mal die Lösungen aus China basieren meistens auf den Referenzdesigns der Hersteller, die kopieren halt erstmal, deshalb funktioniert es auch meistens erwartungsgemäß.
Ich benutze aber bisher keine GATT Services, weil zu Speziell.
Sondern nur notifications mit WriteNoResponse als quasi RS232 Ersatz-Schnittstelle, das funktioniert ganz gut.

Die Probleme mit FMX liegen bei mir
- in der nicht so stabilen Auswertung
- in der anscheinend blockierenden Service/Char Auslesung (konnte in der Vergangenheit 1-2 Sek. MainUI hängen lassen)
(das ist durch 10.2 womöglich besser wg. geändertem Thread System, das checke ich gerade)
- in der nicht stabilen Verbindung (so habe ich das noch bei keinem Testsystem gefunden, und auch andere Analyser scheinen sicherer zu arbeiten)
- entweder das sind das Alles FMX Probleme, oder auch Android/iOS Entwickler müssten dieselben Schwierigkeiten haben


Rollo

[OrtmannMedia]

Hallo Rollo,
auch danke für diese Info.
Inzwischen habe ich das recht brauchbar hinbekommen.
Nach recht langen Versuchen, dann auch ähnliche Sequenz wie von Dir.
Ja, scheint das DiscoverServices macht nen connect, wenn erforderlich.
Allerdings verhält sich DiscoverServices (bei mir) unterschiedlich stabil,
jenachdem wieviel Chars ich eingerichtet habe. Habe nun nach langen Versuchsreichen
beschlossen, immer Connect konkret zu verwensen, und dann erst nach Erfolg DiscoverServices.

DiscoverDevices selbst klappt sehr rasch.
Connect dagegen eben nur gelegentlich, das hab ich in eine Loop gepackt.
Muss man halt leider warten bis es verbindet.
Leider gibt Connect immer True zurück, auch wenn es nicht geklappt hat.
Ich verwende dann bei jedem Versuch IsConnected (statt die RSSI abzufragen), um zu
sehen ob die Verbinung tatsächlich geklappt hat. Das funktioniert zuverlässig.
Auch in meinem RN4871 Modul kommt dann gleichzeitig das Connect,
sobald es geklappt hat.
Ich habe 1 Private Service mit 2 Private Characteristics eingerichtet,
diese kann ich dann problemlos abfragen. Ich filtere die Suche dabei
"manuell" nach 128bit UUID.
Jedoch gibt es Probleme, wenn ich z.B. 4 oder mehr Characteristics einrichte.
Bei 4 klappt es gelegentlich nicht, und die Sucher dauert deutlich länger, bei 6 garnicht mehr.
Bei 2 jedoch immer, bisher absolut zuverlässig, und auch ohne merkliche Suchzeit.
Also mache ich nur mit 2 Chars, mit je 20 Octets Daten.
Das passt eh gut. Eine nehme ich zum Senden an das RN4871, das andere
habe ich als Notification eingerichtet und darüber sendet das RN an meine App.
Somit habe ich bidirektionale Schnittstelle. Ist ja fast wie eine RS232/UART jetzt bei mir.
Wenn was nicht mehr klappt (connection verloren, IsConnect false),
gehe ich zurück, dann fängt es wieder an zu connecten usw.
und holt das nach, was nicht erledigt wurde.
Das gibt dann zwar eine Pause, aber irgendwann werden die Daten dann übertragen.
Und dann halt noch ein Timeout (zähler) insgesamt, wenn es halt wirklich nicht mehr geht.
Somit, denke ich ists zumindest ne Komplett-Lösung.
Nun muss ich mich noch mit Threads und so beschäftigen, damit das auch
nicht nur "so" bei mir zuhause klappt, sondern wirklich zuverlässig. Da werde ich sicher
noch andere Fragen posten hier... Aber so prinzipiell habe ich es hinbekommen.
Vielen Dank

[Rollo62]

Hallo Jürgen,

bringt das Connect bevor DiscoverServices denn etwas ?
Es hört sich so an als wäre es auch so unzuverlässig wie das zweite.

Ich glaube jedenfalls das die unterschiedlichen Stabilitäten wohl im Wesentlichen von den AdvertiseZyklen abhängen, das würde ja Sinn machem.
Also Teile die mit 20ms feuern sind schnell erkannt, die mit 400ms soso, die mir 2000ms da kann man sich auf eine 2te oder 3te Runde einstellen.

Ich würde deshalb in der heissen Phase versuchen oft zu feuern, und ein intelligentes Device kann die Rate dann runternehmen wenn keine Connection kommt.

Ich habe übrigens ein guter Tool für Android gefunden Bluetooth LE Analyser von Bertrand Martel, das ein bischen die Advertisingzyklen darstellen kann.
Gibts in Playstore und auch in Github.
Vielleicht hilft es dir ja auch beim Debuggen.

Rollo

[OrtmannMedia]

Hallo Rollo,
Connect vor DiscoverServices ist letztlich nicht zuverlässiger als direkt DiscoverServices.
Nur konnte ich so unterscheiden, ob ein Erfolg vom Connect oder vom DiscoverServices abhing.
Mit Connect im Loop, und dann erst DiscoverServices dauert es nicht länger und würde ich daher empfehlen.
DiscoverServices geht dann, wenn man connected hat sehr schnell. (jedenfalls bei 1 Service, 2 Chars).
Ja, ohne das messtechnisch zu wissen, habe ich auch genau das gefühl, dass es eine Timing-Sache
von den Advertice Bursts vom Modul ist.
Da es jetzt zumindest mit loops auch wenigstens prinzipiell geht, habe ich bei meinem Projekt nicht mehr so viel Stress. Da eine schnelle Verbindung bei meinem Projekt schön wäre, aber nicht wichtig.
Aber ich möchte mich auch noch später mit den Timing Settings vom RN4871 beschäftigen, vielleicht kann ich
da was einstellen. Ich glaube da ist was.
Bei hunderten von Versuchen habe ich bei Connect alles zwischen beim 1. und beim 15. mal gehabt.
Meist ist es so bei 3 ... 6. mal erledigt. Jede Runde dauert 3.5 Sekunden...
Noch eine interessante Beobachtung - wenn es mal connected war und ich disconnecte, oder
gehe so weit weg, bis es disconnected und connecte dann wieder innerhalb kurzer Zeit, vielleicht 5 Sekunden,
dann connectet es fast immer sofort. Da ist ein Unterschied.
Auch, wenn ich die App dann schnell beende und wieder starte, dann schnell connecte,
dann connectet es meist sofort.
Also irgendwas ist da noch, was das ausmacht...? Zu dem Effekt habe ich noch keine Idee.
Viele Grüße
Jürgen