[Device Request] DG-LAB Opossum #958

Activity

1. BytewaveMLP

   assigned

   qdot

   on Sep 26, 2026
2. BytewaveMLP

   added

   FeaturesNew things to add to the projectNew things to add to the project

   on Sep 26, 2026
3. qdot commented on Sep 26, 2026

   

   qdot

   on Sep 26, 2026

   Member

   More actions

   Sure, I don't see why not.

   @LF112 anything else we should know about the device? We could also possibly look at supporting the civet for our sensor system, though I'm not sure we have the correct descriptors for that yet.

   ❤️React with ❤️2Reacted by Eliot Partridge and Florian Rathe
4. BytewaveMLP commented on Oct 3, 2026

   

   BytewaveMLP

   on Oct 3, 2026

   Last edited by BytewaveMLP

   Author

   More actions

   So I don't feel super comfortable contributing it myself (I don't really know Rust), but I was messing around with prototyping a device protocol implementation/config entry with substantial help from Copilot, and I have a couple notes that might be worth sharing.

   1. The device seems to be affected by the coded PHY bug addressed in feat(winrtble): allow overriding Coded PHY support deviceplug/btleplug#493 - I was able to get the device announcements to appear on my Linux machine, but not on my Windows one until I switched to this fork and disabled coded PHY.

   2. It seems like you need to send B0 commands with new waveform data every ~100ms or the device doesn't vibrate at all. I'm not sure if there's functionality in buttplug currently for custom waveforms, so this could probably just use some static data, but worth noting. Sending B3 without waveform data is a noop.

   3. The 50 instruction seems a little buggy - the DG-Lab Android app will update both the power meter AND corner indicator colors, but 50 only updates the corner indicators. B2 seems like what the Android app is actually using - see below.

   4. The B2 command controls a lot more aspects of the display than updating the channel strength numbers. I don't know how useful these fields are since they're mostly related to controlling the display, and I don't think there's a great way to expose these details in the library itself (except maybe as LED features?), but I documented it here below mostly because of the above point.

      B2 command fields

      Command Layout

      Offset	Size	Meaning
      0	1	Command: 0xB2
      1–2	2	Product icon color
      3	1	Product icon
      4–5	2	Top-left indicator color
      6–7	2	Top-right indicator color
      8–9	2	Channel A power bar color
      10–11	2	Channel B power bar color
      12–13	2	Channel A label color
      14–15	2	Channel B label color
      16–17	2	Channel A intensity color
      18–19	2	Channel B intensity color
      20	1	Channel A label
      21	1	Channel B label
      22	1	Displayed channel A intensity, 0–200
      23	1	Displayed channel B intensity, 0–200

      Color fields use big-endian RGB565.

      Product Icons

      Value	Observed Icon
      00	Opossum
      01	Coyote 3.0
      02	Coyote 2.0(?)

      Warning: Out-of-bound writes caused the device to stop responding to commands until reset.

      Channel Labels

      Selector	Displayed Label
      0x00	Mode 1
      0x01	Mode 2
      0x02	Mode 3
      0x03	Mode 4
      0x04	Mode 5
      0x05	Mode 6
      0x06	Mode 7
      0x07	Mode 8
      0x08	Ch. A
      0x09	Ch. B

      Warning: Out-of-bound writes caused the device to stop responding to commands until reset.

      Display w/ labels

      

   I was able to get a working prototype of the protocol implementation put together, but don't want to dump that on you and not be able to back it up in code review. I can put it up in a fork if you'd like, though.

   I also didn't probe to see if there were any undocumented commands beyond the behaviour expressed in B2, since I think there's sufficient coverage for controlling the toy via Buttplug with the documented commands.