Document D-Lab Powerbox

[blackspherefollower]

BLE Name: D-LAB ESTIM01

Service UUID: 955a180a-0fe2-f5aa-a094-84b8d4f3e8ad

Rx Characteristic UUID: 955a1500-0fe2-f5aa-a094-84b8d4f3e8ad (Handle: 12 0x0c)
Purpose: Battery?

public class d {
    public static int[] a(byte[] bArr) {
        if (bArr == null || bArr.length == 0) {
            return new int[]{0, 0};
        }
        String e2 = e(d(bArr));
        String substring = new String(e2).substring(5, 16);
        String str = new String(e2);
        return new int[]{Integer.parseInt(substring, 2), Integer.parseInt(str.substring(16), 2)};
    }

    public static int[] b(byte[] bArr) {
        if (bArr == null || bArr.length == 0) {
            return new int[]{0, 0};
        }
        String e2 = e(d(bArr));
        StringBuilder sb = new StringBuilder();
        sb.append("====== ");
        sb.append(e2);
        Log.e("yuyu", sb.toString());
        String substring = new String(e2).substring(2, 13);
        return new int[]{Integer.parseInt(new String(e2).substring(13), 2) / b.f360b, Integer.parseInt(substring, 2) / b.f360b};
    }

    public static int c(byte[] bArr) {
        if (bArr.length == 1) {
            return Integer.parseInt(a(bArr[0]), 2);
        }
        return -1;
    }

    // flip endian
    private static byte[] d(byte[] bArr) {
        byte b2 = bArr[0];
        bArr[0] = bArr[2];
        bArr[2] = b2;
        return bArr;
    }

    // byte to binary string
    private static String a(byte b2) {
        StringBuilder sb = new StringBuilder();
        sb.append("");
        sb.append((byte) ((b2 >> 7) & 1));
        sb.append((byte) ((b2 >> 6) & 1));
        sb.append((byte) ((b2 >> 5) & 1));
        sb.append((byte) ((b2 >> 4) & 1));
        sb.append((byte) ((b2 >> 3) & 1));
        sb.append((byte) ((b2 >> 2) & 1));
        sb.append((byte) ((b2 >> 1) & 1));
        sb.append((byte) ((b2 >> 0) & 1));
        return sb.toString();
    }

    // bytes to binary string
    private static String e(byte[] bArr) {
        String str = "";
        for (byte a2 : bArr) {
            StringBuilder sb = new StringBuilder();
            sb.append(str);
            sb.append(a(a2));
            str = sb.toString();
        }
        return str;
    }
}

public void a(byte[] bArr) {
                int c = d.c(bArr);
                StringBuilder sb = new StringBuilder();
                sb.append("electric = ");
                sb.append(c);
                Log.e("electric", sb.toString());
            }

Rx Characteristic UUID: 955a1501-0fe2-f5aa-a094-84b8d4f3e8ad (Handle: 15 0x0f)
Purpose: ?

Rx Characteristic UUID: 955a1502-0fe2-f5aa-a094-84b8d4f3e8ad (Handle: 17 0x11)
Purpose: BT MAC

Service UUID: 955a180b-0fe2-f5aa-a094-84b8d4f3e8ad

Rx Characteristic UUID: 955a1504-0fe2-f5aa-a094-84b8d4f3e8ad (Handle: 22 0x16)
Purpose: Read power levels? 3 bytes 0=b-power 1=a-power 2=unused?

Characteristic UUID: 955a1505-0fe2-f5aa-a094-84b8d4f3e8ad (Handle: 25 0x19)
Purpose: ?

Characteristic UUID: 955a1506-0fe2-f5aa-a094-84b8d4f3e8ad (Handle: 27 0x1b)
Purpose: ?

Characteristic UUID: 955a1507-0fe2-f5aa-a094-84b8d4f3e8ad (Handle: 29 0x1d)
Purpose: Gets divider?

        public void a(byte[] bArr) {
                int[] a2 = d.a(bArr);
                com.bjsm.dungeonlab.global.b.f359a = a2[0];
                com.bjsm.dungeonlab.global.b.f360b = a2[1];
                BlueToothService.this.e.postDelayed(new Runnable() {
                    public void run() {
                        BlueToothService.this.a(0, 0);
                    }
                }, 100);
            }

[rezreal]

@blackspherefollower thanks for helping out with the apk. I think I've made some progress, will have to verify my assumptions with a POC tomorrow:

public interface BLEConstants {

    String SERVICE = "955A180B-0FE2-F5AA-A094-84B8D4F3E8AD";

    /**
     * Subscribe to receive configuration.
     * read: 3 bytes: reverseByteOrder(skip(5) ~ uint(11).as("maxPower") ~ uint8.as("powerStep"))
     * The app initialises with maxPower:2000 and powerStep:7
     */
    String CONFIGURATION_CHARACTERISTIC = "955a1507-0fe2-f5aa-a094-84b8d4f3e8ad";

    /**

     * notify/read/write: 3 bytes: reverseByteOrder(zero(2) ~ uint(11).as("powerLevelA") ~ uint(11).as("powerLevelB")) 
     * Power levels must likely be a multiple of "powerStep" and between 0 and "maxPower" (as obtained through config attribute.)
     * The power dials on the device will step the power level and create a notify message (only when the channel is active (emitting a pattern)).
     * Using the dial will change the internal power level and send a notification with the corrected power level (a or b +/-7)
     * Exception: When the power level is below 70, a dial-down will jump move to the level 70 (seems to be an internal minimum)!
     * If you want to override(=disable) the power dial, simply write the old power level after receiving a notification
     */
    String POWER_CHARACTERISTIC = "955a1504-0fe2-f5aa-a094-84b8d4f3e8ad";

    /**
     * write: 3 bytes
     * p = reverseByteOrder(zero(4) ~ uint(5).as("az") ~ uint(10).as("ay") ~ uint(5).as("ax"))
     * Best guess: 
     * ax: number of pulses in the group 0 - 31 pulses (1khz). 0= 0ff, low feels spiky, high somewhat smoother
     * ay: Time between group of pulses (ms).
     * az: amplitude multiplier 0..1 (relative to the main power level)
     * This pattern has to be written every ~100 ms in order to keep the device emitting 
     * On some boxes, ax and ay are multiplied by 8 (see comments below).
     */
    String PATTERN_A_CHARACTERISTIC = "955a1506-0fe2-f5aa-a094-84b8d4f3e8ad";
    String PATTERN_B_CHARACTERISTIC = "955a1505-0fe2-f5aa-a094-84b8d4f3e8ad";

    /**
     * notify: 1 byte: uint8
     * Likely a percent value between 0..100, > 84 is considered "full-bars"
     */
    String BATTERY_SERVICE = "955a180a-0fe2-f5aa-a094-84b8d4f3e8ad";

    /**
     * notify/read: 1 byte: uint8
     * Likely a value between 0..00, > 84 is considered "full-bars"
     */
    String BATTERY_CHARACTERISTIC = "955a1500-0fe2-f5aa-a094-84b8d4f3e8ad";
}

[rezreal]

Working prototype (js):
https://github.com/rezreal/coyote
https://rezreal.github.io/coyote/web-bluetooth-example

[dsgamermike3]

I just looked at Ax, Ay, Az on a oscilloscope.

Ax: number of pulses in the group 0 - 31 pulses. Only seems to look at lower 5 bits. Pulses are at 1kHz.
Ay: Time between group of pulses. Value*8 = mS between pulses.
Az: Amplitude multipler. Not sure if exact but output level * (0-0x0A * 0.1)

[dereve-prog]

@dsgamermike3 In my case
Ax is the same (number of 1ms pulses in a group)
Ay is the delay between pulses but 1=1ms (no 8x multiplier, if different versions have different delay clocks it would be weird)
This is the duration of the pause only, so total period in ms = Ax + Ay
Az is an energy multiplier (on an open circuit it increases the pulse width instead of amplitude) I think 5-25 is pretty much the same pulse shape but different width. The edge values behave weirdly: around 2-3 are very short and just dissipates when load is attached, 25-31 is very full and doesn't change much, so it might saturate at 25ish.

The difference between Az and Intensity settings for the channel are that the intensity (0-2000) is the actual amplitude and it's more or less linear with the Volts, while Az is power in electrical sense (integral of the pulse) I think it mostly affects the time capacitors are discharged through the load (both in pre pulse and the pulse). So intensity settings should be adjusted based on electrode placement, while Az changes the feeling/contraction strength while limiting hotspotting.

[dsgamermike3]

That's interesting. It seems there may be some different firmware versions floating around. I did in-fact check mine again just to double check. My box is indeed Ay * 8 = mS between the groups of pulses. The first image shows Ay with a value of 1. There are ~8mS between the groups of pulses. 2nd image shows Ay with a value of 8. 8*8=64 which shows ~64mS on the scope capture.

I'd be curious to compare nRF connect dumps between different boxes to see if there are any differences. Below is what I have exported from my device. The sticker on the front of the device labels it as E-STIM POWERBOX 2.0. The BLE name is D-LAB ESTIM01.

[dereve-prog]

Sorry, I was busy with life for some time.

The BT dump looks more or less the same. The differences are:
MAC is D5:1D:3B:xx:xx:xx (changed BT chip?).
The 955a1501 might be a firmware version in my case it's 0x02 0x10

[rezreal]

Here is the "official" documentation:
https://github.com/DG-LAB-OPENSOURCE/DG-LAB-OPENSOURCE

[TurkMcGill]

I don't know if anyone is still working on this but I am trying to adapt rezreal's code for a project I'm starting. I'm having some issues, however. I want to send a single pulse to the Coyote every time I press a button. This is working, but the intensity is very inconsistent. Setting the power to 1000 definitely creates a stronger pulse than setting it to 350, but when I set the power to a single value (like 500), and push the button 5 times the pulses all feel quite different.

I should note that I am not an engineer (electrical or computer), so there is stuff going on in rezlreal's code that I don't understand.

[ltx4jay]

I'm working on a ESP-32 controller for my Coyote. I have it working fine: I'm able to get power level updates when they are adjusted using the buttons, and I can generate waveforms that feel exactly like the ones generated by the app.

Note the following errors in the documentation:

• In the PWM_AB2 characteristics, A is in bits 21:11 and B is in bits 10:0
• The PWM_A34 characteristics is at UUID 0x1506
• The PWM_B34 characteristics is at UUID 0x1505

Or I could have a unit with outputs A and B swapped :-)

My problem is that the Coyote keeps disconnecting every 1-2 mins. I can automatically reconnect but that is obviously a pain (not to mention a security risk as another control app could sneak in in the meantime):

10:44:44.337 -> Connected to: e2:8b:7b:81:6e:a0
10:45:08.493 -> e2:8b:7b:81:6e:a0 Disconnected - Starting scan
10:45:10.498 -> Connected to: e2:8b:7b:81:6e:a0
10:46:46.202 -> e2:8b:7b:81:6e:a0 Disconnected - Starting scan
10:46:47.221 -> Connected to: e2:8b:7b:81:6e:a0
10:48:22.941 -> e2:8b:7b:81:6e:a0 Disconnected - Starting scan
10:48:23.373 -> Connected to: e2:8b:7b:81:6e:a0
10:49:59.232 -> e2:8b:7b:81:6e:a0 Disconnected - Starting scan
10:49:59.894 -> Connected to: e2:8b:7b:81:6e:a0
10:50:40.844 -> e2:8b:7b:81:6e:a0 Disconnected - Starting scan

I am sending a waveform update every 100ms as per spec.

Any ideas? Looks like I might have to go digging in the snoop trace file for a heartbeat between the app and device.

[TurkMcGill]

Hello, I'm still working on my Coyote project, but the code and hardware for this are a bit above my pay grade. I could use the help of an expert. Could anyone help me? I can pay. My javascript code is based on the documented code from the original developer, and Rezreal's example. For my project I only need to generate a single pulse (at different intensity levels) whenever someone hits a button. It works, but there are two small issues: 1. I can set the power to a static value (say, "500"), but the feel of the output varies quite a bit. This confuses me, because when the same code is updated every 100ms the pulses all feel the same, every time. 2. This may just be the Bluetooth, but I'm getting some timing inconsistencies. When users push a button I play a sound effect and send a single pulse. The sound and the pulse are not syncing up very well. Sometimes the pulse is a little early, sometimes it syncs well, other times it's a little late. Would appreciate some help or suggestions.

…

On Sun, Dec 18, 2022 at 12:16 PM ltx4jay ***@***.***> wrote: I'm working on a ESP-32 controller for my Coyote. I have it working fine: I'm able to get power level updates when they are adjusted using the buttons, and I can generate waveforms that feel exactly like the ones generated by the app. Note the following errors in the documentation: - In the PWM_AB2 characteristics, A is in bits 21:11 and B is in bits 10:0 - The PWM_A34 characteristics is at UUID 0x1506 - The PWM_B34 characteristics is at UUID 0x1505 Or I could have a unit with outputs A and B swapped :-) My problem is that the Coyote keeps disconnecting every 1-2 mins. I can automatically reconnect but that is obviously a pain (not to mention a security risk as another control app could sneak in in the meantime): 10:44:44.337 -> Connected to: e2:8b:7b:81:6e:a0 10:45:08.493 -> e2:8b:7b:81:6e:a0 Disconnected - Starting scan 10:45:10.498 -> Connected to: e2:8b:7b:81:6e:a0 10:46:46.202 -> e2:8b:7b:81:6e:a0 Disconnected - Starting scan 10:46:47.221 -> Connected to: e2:8b:7b:81:6e:a0 10:48:22.941 -> e2:8b:7b:81:6e:a0 Disconnected - Starting scan 10:48:23.373 -> Connected to: e2:8b:7b:81:6e:a0 10:49:59.232 -> e2:8b:7b:81:6e:a0 Disconnected - Starting scan 10:49:59.894 -> Connected to: e2:8b:7b:81:6e:a0 10:50:40.844 -> e2:8b:7b:81:6e:a0 Disconnected - Starting scan I am sending a waveform update every 100ms as per spec. Any ideas? Looks like I might have to go digging in the snoop trace file for a heartbeat between the app and device. — Reply to this email directly, view it on GitHub <#91 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF66VNVYFWNHHMR42ZI7HT3WN5PHZANCNFSM4MD7H2GA> . You are receiving this because you commented.Message ID: ***@***.***>

[ltx4jay]

@TurkMcGill It's highly dependent on the platform you use. The more layers between you and the audio player and you and the BLE stack, the more (unpredictable) delays you'll experience.

For one thing: make sure you are using posted writes to the BlueTooth characteristic (i.e. don't wait for a response). In my case, it went from a 600ms delay and a loop() that could not keep up to nothing and a loop() that idles over 60,000 times before I have to send the next wave update.

I'll post my code to GitHub (but it is Arduino/C++ so won't help you) once it is in a stable state.

[ltx4jay]

Gone through the sniffer log and did not find any heartbeat. What I observed (some minor differences from the table above):

• Reads 0x0210 from attr 0x1501 (Firmware version?)
• Subscribes to attr 0x1504 (Power levels)
• Subscribes to attr 0x1500 (Battery level)
• Reads 0x64 from attr x1500 (Battery at 100%)
• Reads 0x07D007 from attr 0x1507 (Device configuration)
• Writes 0x000000 to attr 0x1504 (Power levels)
• Subscribes to attr 0x150B (? new from above)
• Receives (and accepts) new connection parameters (min 20ms, max 75ms, 0LL, 4s timeout)

After that, it's purely writing to attr 0x1506 to update the waveform. No ping back from 0x150B.

Turns out my problem was not accepting the requested connection parameters (the NimBLE client example I started with did not like them). After accepting whatever it send me, the connection is solid.

https://github.com/ltx4jay/Coyote-ESP32#warning-use-at-your-own-risk

[TurkMcGill]

@Itx4jay Your post is a bit Greek to me, I'm afraid. Here's a snippet of the code I am using... I'm writing the encoded pattern and power. Should I be doing this a different way? patternA.writeValue(encodePattern(ax, ay, az));

…

patternB.writeValue(encodePattern(bx, by, bz)); power.writeValue(encodePower(selectedPowerA, selectedPowerB)); On Sun, Dec 18, 2022 at 2:52 PM ltx4jay ***@***.***> wrote: @TurkMcGill <https://github.com/TurkMcGill> It's highly dependent on the platform you use. The more layers between you and the audio player and you and the BLE stack, the more (unpredictable) delays you'll experience. For one thing: make sure you are using posted writes to the BlueTooth characteristic (i.e. don't wait for a response). In my case, it went from a 600ms delay and a loop() that could not keep up to nothing and a loop() that idles over 60,000 times before I have to send the next wave update. — Reply to this email directly, view it on GitHub <#91 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF66VNROHC6OUE3VLRCZYZ3WN6BTFANCNFSM4MD7H2GA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ltx4jay]

@TurkMcGill Difficult to say without more context...

Only the patterns need to be updated every 100ms. Not the power level. So I would keep sending the patterns at 100ms intervals all the time, then only send the updated the power levels when a key is pressed then returning it to 0 after the desired amount of time.

[TurkMcGill]

@Itx4jay My patterns never change, so that's definitely good to know! Currently, I am not setting the power to 0 after a button is pressed. (I tried that at one point, but it didn't seem to do anything, but my code may have been wrong.) Again, my code works but I'm getting different intensity sensations even though I'm sending the exact same power settings every time. Would you be willing to look at my code and help me with my project? I can pay you!

…

On Mon, Dec 19, 2022 at 11:26 AM ltx4jay ***@***.***> wrote: @TurkMcGill <https://github.com/TurkMcGill> Difficult to say without more context... Only the patterns need to be updated every 100ms. Not the power level. So I would keep sending the patterns at 100ms intervals all the time, then only send the updated the power levels when a key is pressed then returning it to 0 after the desired amount of time. — Reply to this email directly, view it on GitHub <#91 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF66VNR5JR26ENHXLM65AEDWOCSF5ANCNFSM4MD7H2GA> . You are receiving this because you were mentioned.Message ID: ***@***.***>