@dedehai If I can get Govee to give me something what should I ask for? Just the data sheet that shows the control protocol of the SM8605G chip?
Also is there a way to connect to the output of the Govee controller and capture the control data coming out of it? I know for RS232 I can use a data viewer and connect to a device and capture its hex or ascii commands to figure out commands. Was not sure if the same thing existed for this.
The thing you need is called a :logic analizer. You can buy one that is good enough for thios project very cheaply and then you will be able to “see” just about any digital signal. I use an $8 “Saleae clone” with Saleae software you can download from their website. But there are open source equivalents. To play in this field a logic analyzer is not optional, and they are cheap and easy to use. Google “Saleae Clone” to get many hits. There is some controversy over the ethics but there are many options. Pulseview is open source. and supports these devices Supported hardware - sigrok
Some of the above hardware is available on Amazon for under $20 with overnight shipping, But $6 on Aliexpress.
Once you can see the bit pattern that works, afjusting the software is easy
like ChrisA sais, you need a logic analyzer and knowledge on how these protocols work in general, you can see that in any digital LED datasheet: its a train of short (0) and longer (1) pulses, I am sure there is good explanations of it online. Maybe the logic analyzer software even supports decoding, otherwise you need to painstakingly count the pulses, write down the byte values and analyze to figure it out.
govee will not give you the datasheet, these are given out under NDA.
I had an idea and it might work: use an ESP32 as a protocol decoder. Tested on ESP32 only (may or may not work on C3, S2, S3). It’s a simple Arduino sketch, I used espressif esp32 version 3.3.5
It ouputs this for a WS2812 on pure green on all LEDs:
Frame #48197 [50/50 bytes]: B1 00 00 B1 00 00 B1 00 00 B1 00 00 …
WS2812 are GRB, 8bit so green set, red and blue zero.
Sweet! I will have to give this a try and if that does not help look into the logic analyzer. I do not see anything on this SM8605G chip anywhere.
I purchased a logic analyzer and have installed logic 2. I am going to capture the yellow data wire coming right off the Govee controller and see what I get. First time doing this with LED stuff, I am used to decoding and working with RS232 for hex and ascii stuff to control things like projectors, displays and commercial AV equipment but this is a different world haha. When it comes to capture settings what should I use? We know that the SM16825 profile in wled controls this chip almost perfectly except for something with the red brightness not going to full unless you also have cool white slightly mixed in. How should I capture data so it could be compared to the sm16825 and see what’s different?
Any updates on this? I installed the custom firmware on my WLED controller but can’t seem to be able to tun on Custom bus start indices.
Unfortunately no. I need someone that can help and knows how to read led logic captures. I have been able to connect to the Govee controller and capture data. Are there any programmers with wled out there that would be willing to help with this project to get an led driver written for the prism LEDs?
not yet supported
Well looks like im returning my prisms. Converting them to WLED was the only reason i got them.
Yeah I have mine installed already, I do really love them and the way they look but not being able to convert to wled is a bummer. I saw at least two people on YouTube that did it, Chris Maher with will it wled did and it did not appear he had any issues with the red channel like I am having, I used all the same settings and even gled opto controller he did. I even got a wled controller that has a logic level shifter to see if that would help. I don’t know if Govee changed the chip or something from what others have used on YouTube with the prisms or if I just have something wrong. I got a logic capture device and did some captures from the Govee controller but I am not fluent in deciphering this type of stuff to figure out what’s different now than what people have used with the sm16825 driver. It’s so close to sm16825 but red brightness seems to be the only thing that’s off which makes no sense. With sm16825 I can run effects and control everything fine but red is half the brightness it should be so things don’t look right.
Curious if there was any further work being done on this. I am utilizing the Govee “Outdoor Spotlights 2” which appears to utilize the same control mechanism as the Prism. SM16825 provides control but certain colors (typically red) are dimmer than they should be.
I’ll add that if you change the LED protocol to WS281x and run up all channels to 255, the light will go full on (all colors). Then, flip the protocol back to SM16825 and a majority of the time you can get full output on each color. However, that doesn’t stick after a power-cycle and sometimes other colors maybe dimmed.
In experimenting, there seems to be a byte somewhere near the end of the first light array where a value will increase the overall output of the color channels. I’m working to hunt that down.
Edit - I’m seeing a consist path to full brightness. When under SM16825, set to ffffff. Flip to SK6812, lights will go super bright. Flip to ff0000 to just hit red (avoid over driving leds). Flip back to SM16825, the lights will be controllable at full power. At least until you power-cycle. Not a solution, but interesting nonetheless.
That is the exact same thing that happens with the Prism. I would love to help figure it out and am down too, I have a logic analyzer but am just not super fluent in all of this and the drivers.
Analyzed the GoVee controller. Here are the results…
672 bits per frame
42 × 16-bit words
Words 0–9 = Fixture 1
Words 10–19 = Fixture 2
Words 20–29 = Fixture 3
Words 30–39 = Fixture 4
Words 40–41 = frame footer / control data
Logic 0:
HIGH ≈ 0.225–0.250 µs
LOW ≈ 0.975–1.025 µs
Logic 1:
HIGH ≈ 0.800 µs
LOW ≈ 0.625 µs
There is also a distinctive longer LOW interval at the end of each 16-bit word ≈ 1.725–1.750 µs
Relative word within fixture:
+0 Red
+1 Green
+2 Blue
+3 unknown / unused
+4 unknown / unused
+5 White-related
+6 White-related
+7 White-related
+8 unknown / control
+9 unknown / control
There were observed max values the controller used for BLUE and the 3x WHITE channels. I’d assume these are important as not to overdrive the LEDs?!?!
// Fixture 1 - RED
Words[0] = 0xFFFF;
// Fixture 2 - GREEN
Words[11] = 0xFFFF;
// Fixture 3 - BLUE
Words[22] = 0x82EB;
// Fixture 4 - WHITE
Words[35] = 0x5A9F;
Words[36] = 0x5A9F;
Words[37] = 0x5A9F;
// Footer
Words[40] = 0xC631;
Words[41] = 0x8C1F;
Note the Footer values above. It’s unknown what those are, but they seem to be directly tied to the maximum brightness the fixture will output. If set to 0x0000, each color is dim. With the values above, each color goes to the brightness expected. Magic?
Now to figure out how to implement into WLED. Anyone??? dedehai?
Update - I have a dev build of wled running and it works great… full brightness. However, I’ve only tested out to four fixtures which the landscape lights I’m using are limited to (per the kit). I’m unable to confirm how the footer/config value impact strings more than four fixtures. How many fixtures are in the Prism string?
My test string has 5 fixtures, but I have a whole string left over that I didn’t use on my install that I could test with to see the impact
Okay. I’m going to do some regression testing with the dev build and then I can share that with you. The version built will limit the fixture count to 4 due to the footers. I’ll dm you with a link Sunday/Monday if you want to try it out.
interesing analysis. so it looks like it needs 10 16bit values per fixture or 2x5 channels. The footer
is a repeated pattern of 11000 (5x, might be per color channel tuning bits or jus a “end frame” pattern) it then ends with 0011111 which may be a 5bit encoded “global brightness” like it is done in other LED driver types.
the question is if the channels you marked as “unused” are truly unused and what exactly the “white related” values do. Also the footer needs to be decrypted, i.e. which bits have meaning and what they do
Thanks for the feedback.
I hadn’t caught the repetition in the footer… I think you’re right. I will experiment a little more with them and report back.
I played with the “unused” channels a little bit but didn’t see any visually noticeable changes. Thinking these lights may use the SM860x chip (no confirmation yet), I assumed the unused channels may be placeholders for the chips supporting more channels… I think I saw up to 9.
The 3x2B values for white all impact the intensity of white. I have not cracked open the lights as I’m using the four I have, but plan to break the seal soon to see if they are independent led arrays or what.
Sweet sounds good!