#ble name
main trail
Ok thanks,
Do you know where it gets the circuitpy#### ?
I would think I could adjust it there
near beacon
It should work without having to recompile CircuitPython. What is the host that is receiving the old name?
main trail
The Bluefruit Connect app and my App
<ProvideServicesAdvertisement services=<BoundServiceList: UUID('6e400001-b5a3-f393-e0a9-e50e24dcca9e')> complete_name=Mikes_LP flags=<AdvertisingFlags general_discovery le_only > >
Device Disconnected```That is from a print(advertisment)
With the old command ble.name = "Mikes_LP" it works but randomly reverts back until you connect to it then it changes. The issue is I want to use this so the user an enter their LP name in the app and it will only talk to the one it's meant to.
near beacon
The Bluefruit Connect app and my App
app on iOS or Android?
main trail
iOS
near beacon
In addition to forgetting the device, turn Bluetooth off and then back on again
main trail
One sec
near beacon
iOS (and Android) cache a lot of Bluetooth data, and it's some work to get them to forget things
main trail
yes
near beacon
ok, I will try to check this later this afternoon, after a bunch of meetings. In general, setting the name and forgetting everything should work.
main trail
No worries, thanks for all your help
near beacon
i did try this, but it was more than year ago
near beacon
@main trail iOS is being very stubborn about remembering old names. I even power cycled my iPhone, and it is still using an old name. Android is much better about updating the name. ble.name (where ble is BLERadio() sets the default device name, which is used in advertising when an advertising name is not set. Android sticks to this name a bit, but it's easy to make it forget the name.
There is no change you can make to CircuitPython to fix this behavior. iOS just has to get around to forgetting the name.
I was testing with iOS 15, and a recent version of Android on a Samsung tablet
main trail
Ok
I will work something out 🙂
Can I ask another question not related to the name. or should I post in the main thread?
near beacon
it's fine to ask here if BLE related (sorry for the delay - I had a phone call)
@main trail ^^
main trail
You mean you don't do free support full time 😉
Do you know how the packets are formed? When checking with the adafruit app I can't really make any sense of the raw packet sometimes it's clearly RGB but others it's way shorter and still gets the color right... but for me trying to write a different app I can't make sense of it
some samples
b'!C\xff\x00(t'
Color is: (255, 0, 40)
It's an Int
(255, 0, 40)
b'!C3\x1e\xffK'
Color is: (51, 30, 255)
It's an Int
(51, 30, 255)
b'!C\x00\xff\x1c\x80'
Color is: (0, 255, 28)
It's an Int
(0, 255, 28)
b'!C\xff\xa8w}'
Color is: (255, 168, 119)
It's an Int
(255, 168, 119)```the packet is binary. There are three bytes for RGB. So \xff\x00( are binary bytes for 255, 0 and 40. At the end of the packet is a one-byte checksum, t in this case. Don't be misled by `\xff: that is an escape code for a single byte with hex value ff
main trail
Is there a way to dump the raw binary from the packet?
near beacon
>>> >>> [hex(x) for x in b'!C\xff\x00(t']
['0x21', '0x43', '0xff', '0x0', '0x28', '0x74']
the packet is a bytes or bytestring, but the characters that look like ASCII are printed as characters. The above shows how to force a hex representation for the bytes
you can see the 0xff in there that you see in the bytes
same for 0x0 and \x00
t = 0x74, etc
main trail
ok so on the swift side trying to form the packet, I need to cast the hex as data
near beacon
no, it just reads raw bytes from the sender
main trail
So my challenge now is to form the packet correctly in swift.