Is it possible to use DX-Light LED strip? ( ambient light )

[ayhamo]

Hello,
i bought the following amibent light:
https://www.dx-light.com/product/products-9-14.html

but i'am unable to use it, any help would be appreciated :)
here is some logs from the program:

systemLocation: \.\COM6
description: USB Serial Device
manufacturer: Microsoft
productIdentifier: 0xfe0c
vendorIdentifier: 0x1a86

i tried already using adalight with 115200, but nothing happening

[awawa-dev]

Hi
Try to get a protocol documentation from the manufacturer ;-)

[ayhamo]

Hello, how I can do that please :), just email them?

Since iam not sure if they will hand such document

How was the process for skydimo?

And it might sound weird but opening the controller casing can help? Or I heard about de compiling their exe?

[awawa-dev]

Without programming documentation describing the protocol they use, nothing can be done, unless you do reverse engineering yourself. Emailing the manufacturer is a good idea. There is a risk that this is a product similar to thousands of other Chinese inventions released on the market without support and documentation, but I may be wrong in this case: we'll see. Therefore, in the case of HyperHDR, it is recommended to use proven solutions. Skydimo protocol was leaked by one of the user and I'm not sure how he got it in his hands.

[ayhamo]

Hello once again, i sent an email, but until otherwise, i been trying wireshark to sniff the usb pakets, would that be of any help?

[awawa-dev]

It might help if they use a very simple protocol like Skydimo. If they use some custom CRC variant, it might be a problem.

[ayhamo]

Hello once again,
i used wireshark to see usb packets during a mode for screen visualizer/ambient border lights ( the whole point of the the thing) , exported it as json which is attached in the next comment, and according to Google gemini ( can take lots of tokens):

Overall Communication Pattern

The data represents a series of USB communication events, likely captured using a tool like Wireshark with a USB sniffer (USBPcap, as indicated by frame.interface_name). The communication is between a "host" (likely your computer) and a USB device with the address "1.11.2". The communication is happening on USB bus ID 1.

The dominant pattern is a request/response sequence:

Host OUT Request (Bulk Transfer): The host sends a data packet to the device on endpoint 0x02 (OUT direction). These packets have a usb.data_len of 42 bytes and contain a usbcom.data.out_payload.

Device Acknowledgment (ACK): The device immediately responds with a short packet (27 bytes, usb.data_len of 0) on the same endpoint (0x02), but this time with the usb.irp_info.direction field set to 0x01, indicating an IN transfer. This is a standard USB acknowledgment, confirming the device received the data. The usb.time value in this packet represents time difference between the request and its response.

Key Fields to Focus On

For your simulator, these are the most critical fields to understand and potentially vary:

usb.src and usb.dst: These identify the source and destination of the USB transfer. In your case, the communication is consistently between "host" and "1.11.2".

usb.irp_id: This is the I/O Request Packet (IRP) ID. It's a unique identifier assigned by the operating system (likely Windows, given the USBPcap interface) to track the request. Notice that the same irp_id is used for a request/response pair. You'll need to manage these IDs in your simulator. There appears to be the same irp_id being used for every 8 packets before cycling.

usb.irp_info_tree.usb.irp_info.direction: This field is crucial. 0x00 signifies an OUT transfer (host to device), and 0x01 signifies an IN transfer (device to host).

usb.endpoint_address: This is the USB endpoint address. The communication is primarily on endpoint 0x02, which, based on the usb.endpoint_address.direction, is an OUT endpoint from the host's perspective.

usb.transfer_type: This field shows the type of usb transaction. Every usb transaction in the given file uses 0x03, which corresponds to an interupt.

usbcom.data.out_payload: This is the actual data payload being sent from the host to the device. This is the data you'll most likely want to vary in your simulator.

frame.time: shows the complete date-time of each frame, example: "Feb 22, 2025 18:22:25.118085000 W. Europe Standard Time"

frame.time_relative: shows how much time has passed for that frame, since the trace have started.

Payload Structure (usbcom.data.out_payload)

The usbcom.data.out_payload appears to have a consistent structure, suggesting a simple protocol. Let's break down an example:

53:43:00:2a:c0:80:01:55:55:54:08:09:54:55:54:11:12:54:55:54:1b:1c:55:55:54:25:26:54:55:54:2e:2f:54:55:54:36:37:54:54:55:3f:ad

53:43 (SC): This is likely a fixed header or magic number. It appears in every payload. It could signify the start of a message, a specific device command type, or a vendor-specific identifier.

00:2a: This might be a command ID or length field, it change frequently.

c0:80:01: changes in every package.

55: This byte appears to be a repeated seperator.

53:56, 08:09: These two bytes are incremented with each packet.

55:55:53 55:55:53: These sets of three hex values appear to be a repeating pattern, potentially acting as padding, separators, or another form of identifier.

Remaining Bytes: there are sets of 4 hex values, it is unclear what those

then telling it that it's color data for usb controller, here is what it said about it:

Revised Payload Analysis

Given that the data represents screen colors, we can make some educated guesses about the payload structure. The key is to look for patterns that change across different packets, as those are likely to represent the color data itself. A typical microcontroller-based LED controller would likely expect data in a format like:

Header: A command or identifier (we've already identified 53:43:00:2a).

Pixel Data: The bulk of the payload, likely representing RGB (Red, Green, Blue) values for one or more pixels. Common formats include:

RGB (24-bit): One byte (0-255) for each color component (R, G, B). So, three bytes per pixel.

RGB565 (16-bit): 5 bits for red, 6 bits for green, 5 bits for blue. Two bytes per pixel. Less common, but possible.

Indexed Color: A smaller number of bytes representing indices into a color palette. Less likely for dynamic screen content.

Checksum/Footer: (Possibly) A byte or two at the end for error checking. CRC (Cyclic Redundancy Check) is a common choice.

Let's analyze a few of your payloads again:

53:43:00:2a:c0:80:01:55:55:54:08:09:54:55:54:11:12:54:55:54:1b:1c:55:55:54:25:26:54:55:54:2e:2f:54:55:54:36:37:54:54:55:3f:ad
53:43:00:2a:c1:80:01:55:54:54:08:09:54:55:54:11:12:54:55:54:1b:1c:54:55:54:25:26:55:54:55:2e:2f:54:55:54:36:37:55:54:55:3f:ad
53:43:00:2a:c2:80:01:55:55:54:08:09:54:55:54:11:12:54:55:54:1b:1c:54:55:54:25:26:54:55:54:2e:2f:55:54:55:36:37:55:54:55:3f:af
53:43:00:2a:c3:80:01:55:54:54:08:09:54:55:54:11:12:54:55:54:1b:1c:54:55:54:25:26:54:55:54:2e:2f:54:55:54:36:37:55:54:55:3f:af
Observations and refined interpretation:

53:43:00:2a: Confirmed as a fixed header.

c0, c1, c2, c3: Increment by 1, there are no repeated values, so it seems it is the start of the packet ID or a time value.

80 : Allways the same.

01: Allways the same.

55: Repeats after every 3 values

08:09, 11:12, 1b:1c, etc.: These pairs could be 16-bit color values (RGB565), or they might represent some other kind of data pair, we can try to represent them as 2 byte values in little-endian order. They increment, but the increment isn't always by one. It jumps. This could relate to the screen region being updated. If only a small portion of the screen changes (e.g., a mouse cursor moving), the controller might only need updates for those specific pixels.

Last byte: Could be checksum, looks like a counter that loops from 0x00 to 0xff and then go back to 0x00.

Likely Protocol (Hypothesis)

Based on these observations, a plausible (but still unconfirmed) protocol structure is:

[HEADER] [COUNTER] [DATA] [PADDING/SEPARATOR] [CHECKSUM]

HEADER: 53:43:00:2a (4 bytes)

COUNTER: 3 bytes.

SEPARATOR/PADDING: 55 (1 bytes)

DATA: A series of 2-byte values (RGB565 or coordinates/data pairs),

SEPARATOR/PADDING: Repeated 55:54 (2 bytes)

CHECKSUM: last byte of the packe.

i hope that is enough to do some work on it, if you have any comment please do tell me :)
edit: if this does help, then i can basiclly try capture more if needed

[ayhamo]

all packets.json
The packets file

[awawa-dev]

Hi
Unfortunately Im currently out of coding for at least next few weeks. anyway I don't have such a set to conduct tests. I suggest that you test the new protocol by modifying the one from skydimo (

HyperHDR/sources/led-drivers/serial/DriverSerialSkydimo.cpp

Line 47 in f96eafb

int DriverSerialSkydimo::write(const std::vector<ColorRgb>& ledValues)

and

HyperHDR/sources/led-drivers/serial/DriverSerialSkydimo.cpp

Line 31 in f96eafb

void DriverSerialSkydimo::CreateHeader()

) and if it brings success then we will move it to a separate driver.

DATA: A series of 2-byte values (RGB565 or coordinates/data pairs),

BTW choosing 16bits per LED would be very, very unusual choice. Make sure its correct testing pure red/green/blue colors at the LED ouput.

[ayhamo]

Hello,
i have already got visual studio setup,
would you mind telling me how i can compile it locally ( as in test the changes in the code) without building it yet,
what are the libraries i need installed, a small explained steps would be amazing on on that process and how i can test it easily (since i did not use hyperHDR before) and something like how i can test single color (Green) via code or application

that would help me get an idea to start!

[awawa-dev]

Hi
The manual is in the wiki: https://github.com/awawa-dev/HyperHDR/wiki/Compiling-HyperHDR#windows

for Wndows use newer QT eg. 6.5.3