Just finished an install today and booting up is slower than I’m used to. I’ve done a comparison video with one of my own sabers (the top one) versus the one I built today.
Done the usual - different SD card etc. Saber works perfectly apart from that.
I built an identical one earlier this week - same wiring and config - and boot time for that one was normal (fast). But I’ve already sent that one out so can’t compare it in a video.
As I say, no biggie, but I’m just curious to know if there’s a reason for it, or if it’s indicative of some imminent failure further down the line. Or am I over-thinking stuff? (Very likely! LOL!).
As long as there’s no actual issue - and it’s just the way things are - then all good, but thought I’d check just in case. 
Does it boot faster after running through all the presets once?
Any difference in SAVE_STATE or similar defines?
I know what you mean about running through the presets after a new upload (i.e. the first few preset changes on a saber are usually laggy while the Proffie writes all the new temp files) but I’ve scrolled right through all the presets forwards and backwards but it makes no difference to the boot time.
And yes, I use SAVE_STATE, but it’s no different in this build than any other as I use it in all my installs.
sd test in serial monitor. You might have a bad sd card.
I always run sdtest whenever I programme the board (unless I’ve had to disable diagnostics to save space). The numbers were good with both cards I tried.
Do you have a bunch of extra files (in subdirectories) in any of your font directories?
Oh, and since these two sabers are identical:
What happens if you switch the SD cards around?
The font layout is the same as I always do, following your recommendations a while back. The screenshot shows how I lay it out. I have three folders with fonts in them, no more than 14 fonts per folder, and all filenames are eight characters or fewer. I’ve been using this layout for a while now and it’s worked very well. I even title the font folders so the premium paid-for fonts get loaded up first when I drag and drop the whole lot from computer to SD card.
The two in the video are quite different config and wiring-wise. (Indeed the top one is a 1.5 board). The identical one was earlier this week, and it booted normally, but I sent it out before I finished this one. But I did try another SD card in this one, but it made no difference. Tried sdtest on both cards I tried too, but the numbers were ok.
How about an sdtest all ?
I’m guessing that tests all the fonts and not just the active one?
I’ll give it a go, but I imagine it will take quite a while.
Will report back…
It tests every single file on the SD card.
Including tracks, proffieOS copies, config files, etc. etc.
1 Like
Ok this was the result - not a million miles from the normal sdtest result:
20:14:30.319 -> Time to open files: Average time: 4131.97 us
20:14:30.319 ->
20:14:30.319 -> :
20:14:30.319 -> :
20:14:30.319 -> :
20:14:30.319 -> :
20:14:30.319 -> :
20:14:30.319 -> :
20:14:30.319 -> :
20:14:30.319 -> :
20:14:30.319 -> . ... .:.. ... . :
20:14:30.319 -> . ...... ...........:.....::::......:::::....::::::::::::::::.::::::::.....:......:
20:14:30.319 -> x100us 1 2 3 4 5
20:14:30.319 -> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
20:14:30.319 -> Time to read blocks: Average speed: 982.23 kb/s, 11.14 simultaneous audio streams.
20:14:30.319 ->
20:14:30.319 -> :
20:14:30.319 -> :
20:14:30.319 -> ::
20:14:30.319 -> ::
20:14:30.356 -> ::
20:14:30.356 -> ::
20:14:30.356 -> ::
20:14:30.356 -> ::
20:14:30.356 -> :::
20:14:30.356 -> .:::................
20:14:30.356 -> x100us 1 2 3 4 5
20:14:30.356 -> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
Not spectacular results, but it doesn’t seem like something that should cause a noticeable slowdown either.
I agree. Though I’m not sure where that leaves us.
Normal operation isn’t laggy at all, and the saber works fine. It’s just the boot that takes a while.
I tried it on different fonts and such like, in case the boot effect in the first font was corrupted, but it’s the same whatever I do.
I guess as long as it all works, then I’ll just send it out.
If you’re interested in digging deeper, I could add some code to ProffieOS that takes timestamps during startup and prints them out later. This could possibly give us some clues as to what is causing the slowness.
It’s possible the slowness happens somewhere before the processor even starts though, in which case such code would not help at all.
Just PM’d you, Prof, but I don’t want to put you to a load of trouble for what seems to be a pretty rare phenomenon. If we start to get more people observing it, then of course, I’m happy to help any way I can.
*** UPDATE ***
I fixed it! 
It turned out to be flux residue around the Bluetooth capacitor between the 3.3 volt and ground pads. I’d cleaned it with isopropyl when I made the joint, so there was nothing visible there, and there was no short or anything like that as test meter showed a solid 3.3 volts between those pads when powered. But I went over it again very carefully with more ispropyl and a wooden cocktail stick, making sure to get right in between those resistors alongside those pads, and lo and behold, problem solved.
That’s the second time I’ve had flux residue cause weirdnesses, even though I clean each joint as I make it with ispopropyl and a cotton bud. Looks like it’s time I bought a new pot of flux.
Thanks again for everyone’s thoughts on it though. Appreciated as always.
1 Like
Flux capacitor time dilation - cool.
1 Like
