Sad News Alert

Imma try and limit the framerate today and see if that changes anything, then im gonna whack a big capacitor on the power rail and see if that does anything, but i doubt it.

Check it. I (kinda) got the timings thing sorted. It was timings too.

template<uint8_t DATA_PIN, EOrder RGB_ORDER = GRB>
class WS2812B_280us : public ClocklessController<DATA_PIN, NS(400), NS(1100), NS(750), RGB_ORDER, 0, false, 350>

Thats the fastled timings i changed to, i found a post on the github about WS2818 leds, https://github.com/FastLED/FastLED/issues/1407#issuecomment-2408505632
He posted a way to work out the timings based on the datasheet, so i used the timings from the ws2812c datasheet and got the values i used above.

this is the result.

Ignore the first LED, that was the start of the next animation. As you can see, its far from fully working, but its successfully addressing 700ish of the 875 leds, which is way more than before.

The only issue i have is, if i push the timings any higher the leds start glitching again.
The standalone controller only shows me 600 leds, so i have no way to verify if its an issue with timings still, or if its something related to the pcb.

Im 99% sure its timings, as when the animation reaches the glitched out leds, it still turns the leds off in the correct sequence, and the random brightness changes were similar to what we had earlier.

Im not really sure where to go from here to be honest. I could try limiting the framerate? but i dont know if that would actually make a difference. hmmm

ive been looking at the datasheets for the ws2812b and the ws2812c,

This is from the data transmission section:

WS2812B

WS2812C

If im reading that correct, the B variant can take a reset time greater than or equal to 50ms, but the C variant needs a reset pulse of greater than 280ms.

So if the reset time being used by fastled B variant is less than 280ms, it wouldn't work on the C variant? But if its more than 280ms, it should work on both the B and C variants?🤔

That would explain the scope readings, the blue waveform was the standalone controller, which had much larger gaps between data bursts. The yellow waveform was super close packets, so much so it looks like noise.

I had a look on the github for fastled, but i only saw one post about WS2812C and that was because someone mentioned the "WS2812Controller" template parameter.

I guess im gonna have to sit and look through the fastled source and see if i can see what timing its using for the B variant.

Take a guess which waveform is the standalone controller, and which is the esp32/fastled...

i could hook the standalone controller and the pico pi upto the scope... that might show something

Im looking on amazon, they have a wled based controller on there that uses a esp8266, but its 15, which is more than i would pay for a pack of 5 esp32's, so it kinda feels like a waste, BUT, it might help rule out if its a physical issue or a code issue... ugh😒

Im still thinking its timing related. When i turn all leds on using the pico pi, you can see the degradation the further you go along the string of leds, until you get to the last row, where only the first 5 or so leds turn on at all, the rest remain off.

If the timing was off by a few microseconds for each led, after a certain amount of leds, it will get so far out of sync, the leds would just be trying to show garbage data, and eventually nothing.

But i know literally nothing about the fastled library, and my c/c++ skills are lacking to say the least

Now im starting to wonder if its a logic level thing, but that doesnt make any sense to me.

So the leds are 5v logic level, that means they need, typically, more than 3.5v ish for the signal to be deemed a "high" level, BUT, there is some margin in that value, 99% of people would be able to run them using 3.3v logic level, which is what comes out of most microcontrollers.

The data signal from the microcontroller only needs to get to the first led. Each LED in the string essentially regenerates the data signal after removing its portion of the data, so the data from the first led to the second led is different than that data from the microcontroller to the first led.

In theory it shouldn't be an issue with the logic level, if it was, the first 140ish leds wouldn't function correctly. The fact they are functioning correctly indicates they are receiving the correct data, and passing it along without issue.

I just talked myself out of it being a logic level issue😂

So after a little bit of research, and a closer look at the "standalone" led controller, it seems most people recommend putting a low value resistor on the data line, i checked on the standalone and it does indeed have an inline resistor on the data output, so i dug out 3 resistors, 100ohm(same as the standalone), a 220ohm, and a 470ohm and it made no difference that i can see.

So its not a missing resistor on the data line.

Ok after i wrote that last post, the led-a-sketch was bugging me, it made no sense that the standalone controller works, but fastled doesn't, So i thought maybe i was misremembering, and the standalone controller didn't work on the led-a-sketch.

I just tested it again, this time hooked up to a beefy power supply, cause the standalone controller doesn't appear to let you adjust the brightness, so they are full bright, which not only makes my eyes hurt, also uses a shit-ton of current.

It works fine... Only 600 of the LEDs are being used, but i assume that's because the string of LEDs i received the controller with was 600 LEDs.

Thats proof that the pcb is functional as i expected it to.. right? So it HAS to be a timing issue, or some other issue not present in the standalone controller.

Here is a picture of the controller, its marked as HJHX001B, I think im gonna take the heatshrink tubing off of it and see what chip its using.

What a surprise, Its a chip with no markings at all. Fucking annoys me that they do that. Better than a blob chip tho i suppose.

I just checked, and the LEDs that the controller came with are WS2812B LEDs, which means the WS2812B LEDs are compatible with the C variants🤷‍♂️

I got a lot of research to do i suppose, but im not exactly counting on it being any use😒

I dont really know what to do... I have no motivation for anything, I want to play a game, i want to work on the waltzer, or the led-a-sketch, and all my other projects, but i just have no motivation to actually DO it 😔

Like yesterday, i was working on the led-a-sketch, but the leds keep glitching out and i have no idea why, the 5v supply is solid (and not noisy), the data lines are short, ive tried 2 different micro controllers incase its a timing issue, but it still just starts glitching out.

I know there is a limit to the number of leds you can actually address, but according to evidence ive found online and in the datasheet, the limit is usually beyond 1000+, im using 875, and i get the glitching after the first 140ish leds. I dont know why, the standalone controller that came with some led strips i have worked without issue, so im 99% sure its not the soldering / pcb, If it was, the standalone controller would have shown issues too.

The other thing that makes me think its a timing issue is that if i run the leds and force 400Khz speed using fastled, they kinda work...

One of the tests i was running in my code was just showing a single row, in red, and looping through each row. The way i could see if there was any issues and have a good idea of where the issue starts.

What was happening with that test when using 800Khz, the first 140 leds would work fine and slowly start to get worse after that. But when running at 400Khz, it would show the first row, then turn all leds on to orange, then show the second row, then turn all the leds orange, rinse and repeat. That wasn't what should have happened, it should have just showed each row sequentially, i dont know why it was showing all leds orange between each row, but each row worked as i expected (except the orange obviously), which kinda tells me its a timing issue, but the ws2812 leds dont support running at 400Khz, only 800+.

It could be that, despite what the datasheet says, the ws2812c leds arnt timing compatible with the ws2812/b leds. But im sure i would have seen something about that somewhere. When searching for anything relating to ws2812c, my own fucking website (not this one) shows up on the first page of google results, so there must really be nothing out there about the C variants of the LEDS.

kinda wanna work on the waltzer again, this led-a-sketch is being a bitch😒

i wonder if people realize that if the stopkillinggames.com petition reaches its goal, fuck all will actually be done. It will go though the motions, but they wont actually implement a law that makes devs / publishers sunset games in a way that benefits players. At most it will have a 10 minute discussion by a bunch of geriatric fools who know nothing outside of there little bubble and then never mentioned again💀

🥵

its to hot for soldering 😭

A year or so ago, i was intoxicated and decided i wanted to make an Etch-A-Sketch, but with LEDs, I got kinda far into the project, then gave up on it like most projects. So I have decided to attempt to finish it.

At the moment, im currently in the "where the fuck was i, and what the fuck was i thinking" stage of returning to a project.

I wanted the LED-A-Sketch (ingenious name, i know😂) to look like a normal etch (i refuse to type its full name again), but with leds instead of whatever they used in etches.

I dont have an etch, and i dont intend on buying one, so ive had to take an educated guess as to the dimensions of a real etch but i think ive got kinda close.

I was looking to use an off the shelf led matrix, but they dont seem to be produced in a size that would work with the original etch dimensions, i did think about LED strips, but they wasn't really suitable for what i had planned. So i decided to just do my own PCB, ive made hundreds of PCBs over the years so its not exactly new to me, and the pcb itself is fairly simple tbh.

The PCB consists of 875 WS2812C-2427 LEDs in a 25x35 grid.
The LEDs will be driven by a PicoPi, It has 2 18650 batteries, 2 Knobs for movement & the potential to add some other things, like an accelerometer (would be cool for shaking to clear the screen).

There is loads of other things i want to implement, but need to get the basic code done first. Some of those things include the aforementioned accelerometer, a "snake" game mode, maybe a sand mode so you can roll the screen and have "sand" flow around, and some other things i haven't thought of yet 😂

Anyway, here is some pics of how it currently looks.

Its too hot to be working on the waltzer, i cant print anything, its to hot to concentrate on designing anything, and im pissed off at multiple things, so the waltzer, for now, will go untouched for an unknown amount of time.

If your wondering why i didn't post yesterday, i spent most of the day building the waltzer and seeing LOADS of things i want to adjust, but would be way to much work to adjust, and by work, i mean reprinting everything.

So i almost just gave in completely and put it on the "future project to finish" pile along with 1000 other things.

Depending how this new connector works, it might still make it to that pile.

Here are some random pictures of its current state.

And no, im not happy with the walkways 😒

I have redesigned the connection between the post and the upper cross beam.
It was originally just kinda sat ontop of the pin sticking out the post, but it would just fall off, then i added a little closed gap to try and friction fit the crossbeam to the pin, but that didn't stop it from pulling away from the post, so i have now designed this.

This really is pushing the limits of fdm printing

The little connector piece should probably be glued to the pin, but might not be necessary.
The crossbeam pushes onto that connecter piece. The result should be a connection that doesn't move away from the post, and doesn't slide off the pin like the previous design.

Ive been testing some prints of the paybox window frames.

Here is both, one is printed at 45 degrees, the other flat, Both using slim tree supports.

These are straight off the bed, they need a little cleaning.

Im conflicted, looking at them in person, i would say the right side non 45degree print looks better, but looking at these photos, the 45degree looks better 🤷‍♂️😭

This one has a better surface i would say, yeah it not shiney, but its smoother.

I dunno, i think there are both perfectly acceptable, But printing flat does print faster.

I dunno what the fuck is wrong with me, i really need to start just printing one object and checking it before printing them all 😒