Android bluetooth read characteristic repeats

1

I have a read characteristic that creates five 32byte keys. I’m running connection manager log(i’ve tested with and without) to see when this characteristic is read. I see it running more than once when blinking up with Android devices.

I’m unsure on whats happening in the lower level of the gatt server if it is doing something different with a broadcast coming from android devices. But iPhones are having no issues.

Could be the library on my app that I am using, although I see no open issues related to this.

Also what is going on with this cm.log method including the bytes of “1565206910”?

Code:

{
                "uuid": BT.uuids.new_secret_getter_uuid,
                "read": function(conn) {
                    cm.log("Key Getter Function() Called.");
                    local bletmp = blob(160);
                    for(local i=0; i<5; i++) {
                        local thing = blob(32);
                        for(local i = 0; i<32; i++)
                           thing[i] = (math.rand() & 0xFF);
                        cm.log(thing);
                        bletmp.writeblob(thing);
                        table.keys[i] = thing;
                    }
                    return bletmp;
                }
            }

Logs:

[Device]|1565206910 - Key Getter Function() Called
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 75 fb 65 65 de 16 88 16 21 33 85 a1 6e 9c 5a 91 df f7 db 14 3d 12 5e cf 83 f4 06 29 f8 8e c2 3e
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 78 cf 96 27 ed 8c 88 fb bc d7 a2 10 14 91 41 11 f8 1d 2b 05 5e 5f 85 07 bf 84 43 27 ec 42 8c 98
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 05 df c2 37 0c cf 08 3e bd 5a f6 3e 03 72 90 c9 07 c1 0d 68 4e 89 0b 26 eb e4 48 b0 7e 32 2f 25
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 1a 83 00 1f 2f db 55 e9 fc 68 12 68 92 54 fa f5 03 82 e6 bb 3f 08 39 8b 81 79 47 66 cc d2 b8 87
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 63 f8 08 a4 63 4f 8c e4 ce 57 a0 cf 4c 96 cd ff b6 f8 c0 68 e4 a0 9f 95 1e 9c 1f 76 64 eb 9b 04
[Device]|1565206910 - Key Getter Function() Called.
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 b0 49 e6 7b c0 d7 1e c7 3b a9 9b 41 50 25 6d 3a b8 bd 56 4c 75 49 9e 4e e1 ed 5c a9 fe f8 58 d6
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 7c 88 90 af 4b 71 83 0a ef 62 a7 98 87 c5 15 06 0c c4 8e d3 d0 8c 0c 53 9f 13 95 da a2 1e f3 51
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 8f 28 65 72 1c 6d 33 21 6c 2a bb 73 e9 90 2a 1e 1a e7 0a d2 78 ae 61 cf a3 19 42 12 ff 48 f0 1f
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 f9 67 0d 49 17 d6 0c 1e 9b be 39 43 14 45 92 b6 93 86 69 e1 07 60 e6 b0 e5 5d a9 f2 f6 fd a8 77
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 74 73 24 95 96 9a 0b 55 84 fa 1f c9 5b 79 47 bb e0 b5 92 a7 82 f6 d2 4b 1b 0f 50 8c 54 89 62 53
[Device]|1565206910 - Key Getter Function() Called.
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 29 64 e3 0e 7d 2f 47 4c fc 2e 47 6e 3b cb dc 54 d0 39 ac d1 1f c1 a6 40 32 47 75 72 fd a9 2b 41
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 fa 3c 41 5d f1 89 6c 4b 74 6a 33 ec 45 8d 6f db 96 36 9e 22 6f 8a 2c ee 2c 2e 5d bf b6 5f 13 07
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 7d ea ea b0 c1 90 7a 21 6a 0f be 3d 05 bc 16 13 dc 89 b8 ff 5a 10 94 99 2a 44 43 62 ec e6 3f 3f
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 93 84 55 3d c3 29 dd f8 fe 78 e8 90 79 b4 7b d7 a8 16 c9 f5 e4 fd 69 8a 03 4e 14 53 67 74 92 b1
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 5c 74 06 1f 77 e7 92 d0 55 1a 65 73 a8 53 87 12 e8 78 7a 7a 47 a2 fe 81 b4 c6 49 17 e7 61 5b bf
[Device]|1565206910 - Key Getter Function() Called.
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 58 2a 9f c2 d5 ea 34 11 ee 99 82 f2 10 2f 5a a7 18 93 91 cc 86 80 97 88 cb 45 73 4b 35 aa 5c 55
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 49 e9 8e 0d bc 26 1d 28 2e ae d0 a4 65 b8 2a a5 c1 af 78 e6 84 df 89 fe 43 ca 17 db 85 cd ba 58
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 92 88 03 aa cd ee ea 09 db ec f3 bf b6 d0 2a 17 22 5c 0a 59 12 1b fd 9b 14 e8 88 53 02 41 2a 5e
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 d7 ff 09 ac 1d a3 9c 80 67 82 09 6f fb f0 47 65 16 b2 a6 61 18 2e 4e 83 c0 52 17 22 b0 10 74 51
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 0d 70 95 3e 1e bd cf 61 5c bc 52 87 6e 01 5a c6 d8 4a 30 1d 41 78 7d 16 0f 7b b8 77 42 63 97 90
[Device]|1565206910 - Key Getter Function() Called.
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 5c 5d 29 e7 d0 9d ca f5 84 9c 17 20 8b e3 ef db c2 f8 11 a8 5d b3 8c 5b 56 7d 69 2a 4b 9b 84 a3
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 94 22 20 d8 eb eb 99 27 02 4d 29 0f 68 88 4d fe e5 b2 f2 fa ac 70 a9 cc ab be 83 76 54 8a 2c 19
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 61 28 03 f4 a9 5c 17 e7 bb dd ce 64 36 a4 43 36 e4 4c 9c 80 61 07 09 28 cc 7f be 38 25 7f 84 4d
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 1d b2 47 38 e6 70 8c 39 09 32 69 0e 06 66 f7 c9 1e e1 b0 67 33 8d fc 0b f7 a1 63 63 cf 32 73 26
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 20 d7 81 be 1c a5 a3 79 e4 ca e4 a7 5d 49 d4 4a ed 79 dd 51 ce b8 d9 62 ce 33 c3 5d 53 fe 4f 41
[Device]|1565206910 - Key Getter Function() Called.
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 2d 06 af af 7c 03 97 53 f4 95 a6 42 41 6c 1f 2a 00 69 e6 07 35 10 cc 03 af 88 41 bc cc 71 85 41
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 cf 0b 8b e8 a6 57 f1 b5 9a 92 2e db e4 f5 85 cb a9 1c 86 20 37 dc b6 c3 d8 cd a4 c5 38 19 25 49
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 d4 99 cd cc 4e e5 14 0f 48 b6 15 c2 85 f1 78 6b c5 c4 cd 07 1c 42 e0 a2 30 ae 74 52 3f 8b 56 ef
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 d4 2c 89 e9 b3 71 76 97 b3 54 30 15 6e f2 25 f3 4e 38 4e 87 5e 60 58 2b 7c 60 14 f2 bc 6f 4f b9
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 a3 80 49 03 4f c2 49 b8 fa 38 5d a7 30 ce 89 57 59 45 b4 39 6c 96 0c 72 44 d7 6b 26 65 4b 11 c9
[Device]|1565206910 - Key Getter Function() Called.
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 50 2d 76 a5 9d d9 fb f5 a6 75 dd 29 92 da b0 61 d6 78 49 ef 3f 7c af bc 58 b4 a4 a0 85 06 c9 91
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 09 44 34 b9 f6 e3 29 ae b5 7d ae 08 6f cf e9 27 14 d2 bd d2 0d 7d 6b c3 1c 6b 9e 86 9d a9 40 e8
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 93 93 46 0c 31 e6 77 5e 70 e9 0d 9f 1c 2c 9b f1 6e cd 08 f1 a8 70 de c3 d9 e8 4e 56 f5 60 af 2a
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 dc 23 2f 70 d5 00 f7 62 11 67 07 cb 9c 52 0b a8 04 98 b6 03 92 ff c5 ba 62 87 2e 6c b0 65 2f c2
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 fc d7 0b e7 0b 91 58 b9 6a f6 3a c2 3c 5e c2 d7 c1 ae 28 45 bd b8 57 d4 6b f9 e4 a8 4b 83 ce ce
[Device]|1565206910 - Key Getter Function() Called.
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 37 fa 80 7a 6a f2 fc 46 d6 b1 b5 00 dd 27 39 00 62 04 1a 6b 13 ff 1a 61 d3 53 7c 63 0c a8 e8 b4
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 10 b1 8d 83 df b7 f4 46 82 d2 14 58 8e 0b e0 4f 46 63 47 0e 34 5d 6d a1 27 5d 82 6c 53 fa a7 c1
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 dc 32 f9 56 ff ec 3f 40 7b 34 78 0e ed 5e a4 69 c8 fd 64 c1 21 f1 7a bc 20 f7 a8 23 56 e5 41 83
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 bc 34 bd 2c 9b 1c b8 0e 79 1d fd 1d 1e 5b 69 71 09 35 25 44 c2 2d 46 2c ad ff 40 a2 40 49 a5 ed
[Device]|binary: 31 35 36 35 32 30 36 39 31 30 20 2d 20 ab 0b ad 5e 00 8c 10 cf f1 18 09 2b eb 68 74 39 2e 3f 18 81 50 77 e9 f0 ae 26 fc de 79 24 b1 70
2

FWIW, I noticed this with the Bluetooth BlinkUp sample code, which runs on iOS. The read characteristic that returns compatible WiFi networks seen by the imp is sometimes triggered twice.

// Define the getter characteristic that serves the list of nearby WLANs
chrx = {};
chrx.uuid <- _uuids.wifi_getter_uuid;
chrx.read <- function(conn) {
    // There's no http.jsonencode() on the device so stringify the key data
    // Networks are stored as "ssid[newline]open/secure[newline][newline]"
    // NOTE set _blinking to true so we don't asynchronously update the list
    //      of networks while also using it here
    server.log("Sending WLAN list to app");
    local ns = "";
    _blinking = true;
    for (local i = 0 ; i < _networks.len() ; i++) {
        local network = _networks[i];
        ns += (network["ssid"] + "\n");
        ns += ((network["open"] ? "unlocked" : "locked") + "\n\n");
    }
    _blinking = false;

    // Remove the final two newlines
    ns = ns.slice(0, ns.len() - 2);
    return ns;
}.bindenv(this);
service.chars.append(chrx);

I see Sending WLAN list to app appear twice in the log.

I put this down to iOS weirdness, but since it’s the same thing you’re seeing, I now wonder if this is an impOS BLE issue?

3

I can’t seem to find anyone else replicating this with the Bluetooth library on the App side.

Using the tool below (LightBlue) to read the characteristic i’m only getting one function call. So I can’t exactly say it’s an impOS BLE issue. I’ve patched my way around this by generating the keys upon boot up. Still worth investigating I believe…