Do I replace the CC style with just that? I get an error:
““Compilation error: no matching function for call to ‘StyleNormalPtr<Red, Blue>()’””
Ops, try this:
StyleNormalPtr<Red, Blue, 300, 800>(),
Ok so I just flashed it and now it boots to blank (no light) until I turn it on then turns white until after I turn it off, after a couple seconds goes back to blank.
That sounds like the pixels are getting power, but no data.
Not sure why that would be though.
I guess it must be, an install issue?
It’s weird though, because it used to work, right?
From your picture, there doesn’t seem to be that many different ways that the data signal can go. I don’t know if that means that somehting happened to the connection, or if the configuration is still wrong somehow.
If you have a multimeter, you can set it to AC mode to detect data (1 probe on GND, other on a point you want to check.) Then you can follow the cable around and see how far the data goes.
If you can measure data at the board, but not at the CC, then it’s something wrong with the wiring. If there is no data, it’s either a short, or something wrong with the configuration. If data goes all the way to the CC, but it’s still not working, then either the CC is broken, or we’re sending the wrong data somehow. (Like, maybe it’s a dotstar pixel?)
Yeah, when I first got it the CC would change colors per preset correctly
So, it looks like I do get a reading on all CC data points when the saber is activated. Also Looking at it know I see there is 2 Neo pixels like for a blade (upper and lower), and the lower pixel doesn’t turn on at all.
Also the pixels are getting a reading from the board when its on. I had one probe from data to the pixels gnd and they were receiving data
If you change the blade lengths from 1 to 2, does the second pixel turn on?
WS281XBladePtr<2, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin4> >(),
You can try it one blade or the other independently.
I added a pixel to both CC blades and unfortunately no luck.
Would this missing define for activating the OLED screen make any difference?
#define ENABLE_SSD1306
No luck unfortunately
Not to ask the obvious again since @Sabersense already has, but you are removing the temporary save folders, the .ini and .tmp files the board creates to the SD before retrying right? The only thing you should have on your SD card after any flash is the sound font folders. Nothing temporary. Just missing this step would explain why nothing is changing. If the board sees a temp file from an old config the new stuff won’t show.
Pull all your font pack sound folders aside making clean copies and anything else vital. Take all the old stuff on the SD, dump it, use SD Reformatter, then reinstall the font folders and then retest.
If that’s not it are you certain the config flash is working and shows 100% completed?
That is only true if #define KEEP_SAVEFILES_WHEN_PROGRAMMING is used in the config. But @lil_hubby doesn’t have that. However @A_Rogue_Child might be on to something. Are you @lil_hubby sure you are uploading the correct config. To make sure, you can test it like this:
- delete the “S” from you first StylePtr, and save. (this should create a compile error)
- try to compile, if it compiles, you are not editing the correct config
- check the spelling of your config file in Arduino:
/*-----------------------------------------------------------------*\
| You can have multiple configuration files, and specify which one |
| to use here by removing the two slashes at the beginning. |
| **NOTE** Only ONE line should be left uncommented at a time! |
| Add the slashes to any that you are not using. |
\*-----------------------------------------------------------------*/
#define CONFIG_FILE "config/YOUR_CONFIG_FILE_NAME_HERE.h"
Make sure “YOUR_CONFIG_FILE_NAME_HERE.h” matches your config name exactly.
Fwiw, while this is true in theory, it’s often not the case.
I’ve see a lot of cases where stale save files are the issue even without that define.
Fredrik would maybe know why, but from experience, I can attest it’s fiddly sometimes.
1 Like
That used to be the case, but if you see that now, that’s weird.
AFAIK, the only way this can happen now is if you have savefiles without timestamps in them.
The only way to have savefiles without timestamps is if you’re using a very old ProffieOS. (5.x or older I think.)
If you see some other case where this happens, please start a thread about it so we can figure it out and squash it.
1 Like
With that new knowledge, I’m sure it’s all the Chinese sabers that are still on 5. I’ve not really kept track but more often than not whenever someone has any kind of problem at all it’s with a Chinese saber, so it’s probable that all the instances I’ve seen of that issue have been with Chinese sabers on old software.
That would explain it.
1 Like
@olivierflying747-8 see @ryryog25’s replies. That right there is why I brought the thought up. I see one or two situations a month with “drop-ship” sabers that are on old OS and the user simply didn’t remove the tmp and ini folders. Clean the SD card up, upgrade to newer OS and it works. Since both are things I’ve not seen the OP mention having done it’s entirely possible. 
Next time you suggest this, please provide background on why it may be required, otherwise it’s just another cargo cult.
1 Like