So I’ve heard rumors (but nothing very specific) that Data3 was producing flickers on V3 proffieboards. I did some testing, and got a lot of flickering from Data3. However, when I checked my config, I noticed that I had #define ENABLE_SPDIF_OUTPUT in it, and when I removed that it seems to work just fine. (SPDIF output would come out on Data3 on a V3 proffieboard.)
Since I don’t have much specifics to go on, I have no idea if that is the same problem that others are encountering or not, but I thought I’d put it out there in case it helps somebody.
It’s not only on data 3.
I’m waiting on another V3 to be able to show you.
The problem appear when using multiple data. Me I was only able to get 5 data total without flickering out of 7. Also moving datas can make the problem appear on a total random one that was working.
Here’s a paste of the info I already put on another thread about this :
I have experience the same issue with strips flickering.
I needed 7 data. Data 3 and free 3 had strange behaviours with flickering at the base.
Changing the order of the blades in the bladeconfig section of the config, changed the problem from one data to another.
At the end, the only thing after trying to debug this that work, was to combine 4 data together to drop to 5 data. Moving a data to another pad works and not. sometimes it moves the problem.
I ended up using data 2,4,5,6,7. Data 1 and 3 doing flickering even tho it started with 3 and 7.
I had many pms about this from others and was resolved by moving the data.
I am no coder at all but seems like a conflict of clocking or something induced in the data line perharps.
For some reason I wasn’t able to find that thread when I went looking for it…
In order for me to fix a problem like this, I have to be able to replicate it. Most of the time, that comes down to having the config file that causes the problem.
Do you still have the config file that caused your problems?
Sadly I don’t. It was a saber for a customer and had to make it work before shipping it.
I’m waiting on another board. I will install all data lines with strips and see if it recreates the bug. I will update this thread when I do with a video and the config so that we can resolve this issue.
But I think anyone who would use the 7 datas on the V3 will encounter this problem.
So you know, I used OS 7.7, Reverting to 6.7 did not solve it. #define ENABLE_SPDIF_OUTPUT was also not used in the define section.
The problem was seen on all kind of addressable led media (flexible strips, KR blade strip, connectors, etc…)
Awesome… well not cool but at least you see a problem. It’s a start.
Without a v3 board I can’t be really useful at the moment. But let me know if I can be any help at all.
Thank you very much. Your help is always appreciated.
Well, I would request that in the future you come here and report problems.
Getting help in DMs is great and all, but there is zero chance of me knowing about it and fixing it.
Well, I think I have this figured out.
WS2811 pins come in two classes: proxy and direct-drive.
data1/2/3 are direct drive pins, which means that there is a direct connection between the timer that drives it, and the pin.
All the rest of the pins use a more complicated scheme where the timer drives three DMA channels, and the DMA channels write to the GPIO register that drives the pin. I call this proxy mode.
Apparently something weird happens when switching from proxy mode to direct drive mode, and it sometimes causes glitches. The OS iterates over all the pins backwards, so Data4 is processed in proxy mode, and then it switches to direct mode to drive Data3.
I have a fix that I’m testing right now. The most important part is an extra call to stm32l4_dma_enable() which ends up preventing an extra call to DoDoneCB. I also found a potential problem where kick() could end up calling show() from inside show() under some circumstances. With these fixes in place, the leds seem to be rock steady.
The fix is now on github master, please try it and let me know if:
a) it works
b) it fixes glitches
Wow that’s awesome. I will test this out the best I can as soon as I get a v3 in hand.
Thanks again for checking this out. I will inform you of the result as soon as I can.
So I had Russel Mitchem test the new master since he was having issue with this on his crossguard.
He reported to me that the new master fixed the flickering for him (was on data2 for him)
So it seems that you fix worked.
I will test further when I have mine in hand but for now it seems all good.
Porting it is easy, but testing is hard.
Changing the clock speed can affect every part of the system, so it’s hard to know if the fix is safe. (And 7.x is the stable branch, so only safe changes are backported.) If people want this fix sooner rather than later, I need people who use the code from github master for a at least a few days, then come back and tell me that it works fine
My experience from the 7.x testing is that this is not likely to happen, in which case the clock speed fix will have to wait until 8.x
Maybe if someone experienced could write up a detailed list of what exactly to test, what to look for, what potential issues might come up, it could lower the bar for entry. I know a huge number of people here will be less confident about even being able to contribute due to worrying about not doing things correctly.
If it’s a matter of throwing the beta on a hilt and leaving it for a while, then seeing what battery level is, then doing x/y/z then leaving it then checking battery, people will more likely get involved.
The reality is that for most of users, the idea of testing is intimidating and saying “test these things” to someone that has never done it is scary.
Maybe create a download of 7.9 with the low power code as well?
Well the first thing to do if you want to help with testing is to say that you want to help with testing, so good job for doing the first step.
There are a couple of different types of testing:
feature testing
stability testing
bug verification testing
Feature testing is when you enable a feature to see if it works.
Stability testing means just using it and make sure there are no problems.
Bug verification testing is when you verify that a problem has been solved by a fix. (Which you can’t do unless you have the bug in the first place.)
For the clock speed fix, what would be needed is mostly stability testing. I already tested the feature, I just want make sure it doesn’t break anything else. The only tricky part about stability testing is that a million people testing basically the same thing doesn’t really help much. It’s much more important that the configurations are as diverse as possible.
Okay, I’m getting flickering like what has been reporting, but i’ve moved my data from Data1, to Free2, and to Data2…so I’m thinking it has to either be my blade array, or perhaps something more hardware related. In other words, maybe my chassis connector, or the in/outs on my crystal chamber single accent pcbs (my main blade is daisy chained thru the crystal chamber, thru a shotk v3 emitter pcb in subblades, and subblades with stride. But the flickering is happening all up and down that path (on the crystal accents, the emitter pcb, and in the actual blade itself).
I started with Data1 in OS7.8. Then tried Free2 as it was close by after having cinched down my chassis build. When I moved to Free2 using “blade6Pin” caused my chassis accents to not work, and made the entire chassis/saber not work. In other words, I’d hear the boot sound, but could not turn the saber on or off, and none of my other accents worked. I had no idea what was up, but I was making some other config changes to the Top Section. So, I reverted those back to my working version. After being befuddled by that. I didn’t re-solder my wires, I just changed my config back to data1 and everything but the main subblade array line worked.
So then I moved my data line to Data2 (using 3 and 4 for the chassis accents LEDs). Same exact flickering all up the subblade line. So, tried flashing back to OS6.9. Same issues.
I’m fairly certain it’s not a hardware issue, because I tested the main subblade line with the default config that was flashed to the proffie v3 how it came from The Saber Armory, but before I had my config ready. I think it’s my blade array, or something like that.
Did you try reading the thread above?
It says that there is a potential fix specifically for this issue on github master.
Have you tried the github master version of ProffieOS?
Must be. I used the above, and while it solved the flickering issue on all the the subblades on the main blade line, I’m getting an artifact of the last few pixels of the main blade somewhat mimicking one the accent LEDs. It’s mirroring an accent from that subblade line. Not sure how/where to post the video clips. I’ll edit with an unlisted youtube clip
note: the emitter PCB subblades (inner and outer) are covered the 1" main blade, but the tip lights seem to mirror the inner accents. This is Preset 1 from the previously pasted config.
