we’re going to build this scanning into our own app for both iOS and Android, but as per @spencerergs comment, it would for a commercial product be needed to get guidance from eImp on where this difference comes from. Reason for going this route is the ease with which we can add BLE functionality in our already Imp enabled product. If that means extensive debugging of the Client side code for unexpected bahavioral difference between iOS and Android, the advantage is quickly gone…
==> would you guys be able to figure out where the difference in behaviour comes from and provide guidance as to what to do and don’t do ,
Starting to sound maybe a little like you have a hardware issue @spencergs - on the app it does work with, what’s the RSSI indicated for the advertisement? Do you have another imp004m board to try?
There shouldn’t be any issues with compatibility in that we’ve been using this on hundreds of imps and many different (mostly android, in fact) devices.
I’m actually using 3 imp004 simultaneously. I get about -45dBm on all with my phone right next to them.
That generally seems believable (though I see more like -30ish, it’ll vary fairly significantly).
How about if you enable wifi powersave mode with imp.setpowersave(true) - any improvement?
If I put my phone directly over the antenna, I can get as high as -27. To be clear, I can see all of the devices in all of the apps I’ve tried. It’s just connecting to them that’s the issue. I can connect with nRF Connect with -75dBm from the next room, but the other apps won’t connect at all, even when right next to the imp004m at -45.
Something strange is definitely happening, then. Do you see any connection requests logged?
We’ll try to replicate with a BT sniffer and see if anything looks wrong.
Hi, I run the code exactly on my imp004m, if I change the advert data to standard on the sample AND restart my android (galaxy S8), it does work on Lightblue Explorer.
local BTadvertisement = "\x02\x01\x01\x09\x09\x42\x6c\x75\x65\x66\x69\x73\x68\x05\x02\x0F\x18\x0A\x18\x00"; // change to
local BTadvertisement = "\x0e\x09\x69\x6d\x70\x20\x62\x6c\x75\x65\x74\x6f\x6f\x74\x68";
I know things about OS cache issue (hence need restart), but I don’t know why your advert packet not working on Android.
I have similar code working well on Android studio GATT sample app.
Also, if I use your advert data, but just change the UUID to incomplete 128bit: “\x02\x01\x06\x09\x09\x42\x6c\x75\x65\x66\x69\x73\x68\x05\x02\x0F\x18\x0A\x18\x00” and use 128 UUID on services and characteristics, and restart the android, it works as well.
Thank you @akmandala and @hugo for your efforts. When I use the ad data provided by @akmandala, it does work on LightBlue and the other apps I’ve tried.
However, correct me if I’m wrong, but where you modified my ad data, I believe you only changed the flag from x01 “LE General Discoverable Mode” to x06… “reserved for future use” in the CORE spec.
In fact, with no other changes to my code except the flag…it seems to work with any app. 
I tested with complete ad data as simple as “\x02\x01\x06” which works, but “\x02\x01\x01” does not work. Android did need to be restarted whenever I changed the ad data (clearing the app’s data/cache did not do the trick).
Heck, I can set the ad data to “\x00” and I can connect fine. Seems like it was just the flag causing the issue?
This is because I believe you’re misreading the spec
\x02\x01\x06 is flags 0x06 (2 byte packet, type 1, data 0x06)
\x09\x09Bluefish (9 byte packet, type 9, data is “Bluefish”)
\x05\x02x0F\x18\x0A\x18 (two services)
…but then you have a \x00 at the end. Not sure what that’s for? Did you just try removing the \x00?
I don’ think I’m misreading it? I know that \x06 is the flag…but what does it mean? It just says “reserved for future use” in the core spec.
I read somewhere that you could use \x00 as end of data, and it was just one of the things I tried to get it connectable. It didn’t seem to make a difference either way.
To test it, set your complete advertisement to “\x02\x01\x06” which works, but “\x02\x01\x01” does not work.
Termination with a null byte is not something I’ve seen in any example packets, though.
\x06 is \x02 (LE general discoverable mode) and \x04 (BR/EDR not supported).
We don’t support BR or EDR; possibly, the phone is trying to talk bluetooth classic to us if bit 2 isn’t set?
Oh okay I see what you were trying to say about the flags spec… 
Anyhow, whatever the reason…it seems to be working now with the \x06 flags so I’m happy.