Open mearsy opened 2 years ago
See https://adamcatley.com/AirTag.html#advertising-data for the format of the AirTag's advertising data. Six bytes of the key are encoded in the device's Bluetooth address. So it's not enough to broadcast these data, you have to be able to change the device's Bluetooth address too. In OpenHaystack's code that's happening here.
See https://adamcatley.com/AirTag.html#advertising-data for the format of the AirTag's advertising data. Six bytes of the key are encoded in the device's Bluetooth address. So it's not enough to broadcast these data, you have to be able to change the device's Bluetooth address too. In OpenHaystack's code that's happening here.
Thanks,
I realised that after I'd posted when I looked at the microbit code and also Adams blog.
So if I understand right, the key is 28 bytes. the first 6 of which are used to form the devices bluetooth address. Then the broadcast is in the format
1e ff 4c 00 12 19 00 decddb9f38fefcae083795be15d7f458c77a4b7d36 3 <ββApple Tagββ> <ββββ- Last 22 bytes of public keyββββββ-><Append 1st 2 bits of public key(127 in decimal>
I think I'm going to give up with these minews for the moment. Anyone suggest a decent coin cell based tag which I can program with an stlink v2 then deploy straight out of the open haystack app with no issues.
@mearsy
Anyone suggest a decent coin cell based tag which I can program with an stlink v2 then deploy straight out of the open haystack app
I'm working on st17h66 (cortex m0) based tags like those: https://www.aliexpress.com/item/33035468217.html Still WIP but does that tick your boxes? I could use an extra pair of hands on these. EDIT: it's a bit of a gamble if you get st17h66 or st17h26 based tags, but I'm working on them both (although the latter you can't program with your stlink v2)
I'm working on st17h66 (cortex m0) based tags like those: https://www.aliexpress.com/item/33035468217.html Still WIP but does that tick your boxes? I could use an extra pair of hands on these. EDIT: it's a bit of a gamble if you get st17h66 or st17h26 based tags, but I'm working on them both (although the latter you can't program with your stlink v2)
@biemster How's it going? Do you have any success?
I have successfully reflash st17h66 tag (this one: https://www.aliexpress.com/item/1005003357986346.html) and it works with openhaystack osx app. For flash I use FTDI FT232RL board. For firmware - modified a bit sample Keil uVision project from lenze SDK.
The main disadvantages are:
1) The only sample projects I could find for st17h66 is for Keil uVision (v5), and this is not GNU toolchain and for this compiler you'll need a license. 2) It is all Windows only.
This IDE have some option to compile project using GNU Toolchain, but simply switch to GNU toolchain produces a tons of errors, and I am, unfortunately, not so sufficient in C or ARM development to transfer whole project to GNU Arm Embedded Toolchain.
The good news is, lenze uploaded many samples with the SDK, documentation also there, including the flash tool and many useful info.
If someone with more advanced knowledge of Keil toolchain can transfer basic uVision project to GNU toolchain, this could be very helpful.
The bad news is, flash tool is for Windows only, but I assume flash process can be reversed, or may be it is described somewhere in the documentation, but I could not find it so far (most of the documentation is in Chinese).
At the moment I have only one st17h66 tag and it successfully working with the custom firmware and visible on the map. I've ordered more tags and will clean the project code (for now only PoC there, bare minimum to make tag appears on the map).
@biemster, please get in touch if I could help you somehow.
I have successfully reflash st17h66 tag
Wow that is awesome work @vadimkozhin ! I did not manage yet to reprogram my st17h66, not with the uart method with the Lenze tool, and not with the SWS interface or the SWD interface, so I'm really excited that you actually managed! At first I also tried to compile with GCC, but I got stuck at the linking step. (But this should be doable if you actually have a working setup, which we do now, so let's give it another try!) I'll PM you @vadimkozhin as not to take this issue off topic.
Hello,
I have been given a mine iBeacon E8. It runs on an NRF52. The current firmware allows for the concept of slots, whereby it will round robin and advertise different formats in different slots. It would be nice to do some testing with these beacons whereby they will continue to broadcast their current iBeacon in slot 1, but I could use slot 3 to piggyback on openhaystack.
As a proof of concept I was hoping to be able to generate a key in Openhaystack, copy and paste that into via the Beaconset+ app and simply advertise it using the Minew E8.
The minew E8 supports the following Frame Types for broadcast: UID (Instance ID of 12 NamespaceID of 20) URL (Useless as it mandates the HTTP:(s)// iBeacon (Minor, Major UUID 8 chars-4 chars-4 chars-4 chars-12 chars)
My question is, is there a way I can take the output from the copy advertisement key (base 64) and format it to fit in the iBeacon field.
The Minew is expecting a UUID format like:
466C6F4B-6948-6561-6C74-680154616701
My sample Base64 from Openhaystack as a byte array is:
0x7f, 0xad, 0x88, 0x77, 0xe, 0xcf, 0xde, 0xcd, 0xd, 0xb9, 0xf3, 0x8f, 0xef, 0xca, 0xe0, 0x83, 0x79, 0x5b, 0xe1, 0x5d, 0x7f, 0x45, 0x8c, 0x77, 0xa, 0x4b, 0x7d, 0x36
So formatted it would be
0x7f, 0xad, 0x88, 0x77, 0xe, 0xcf, 0xde, 0xcd (8) 0xd, 0xb9, 0xf3, 0x8f (4) 0xef, 0xca, 0xe0 0x83 (4) 0x79, 0x5b, 0xe1, 0x5d (4) 0x7f, 0x45, 0x8c, 0x77, 0xa, 0x4b, 0x7d, 0x36 (12)
Ok, but still too long to fit into the UUID format. So I took the base 64 advertisement key of f62Idw7P3s0NufOP78rgg3lb4V1/RYx3Ckt9Ng== and ran it through https://base64.guru/converter/decode/hex to give me a UUID equivalent in hex...
f62Idw7P3s0NufOP78rgg3lb4V1/RYx3Ckt9Ng==
becomes:
7fad88770ecfdecd0db9f38fefcae083795be15d7f458c770a4b7d36 (56 characters)
I suspect the problem is I am trying to fit a quart into a pint pot. i.e the UUID iBeacon format the Minew expects is shorter than the custom format apple broadcast for their AirTags.
Any pointers or ideas would be gratefully recieved.