Second post here, last visit was super helpful so I’m back for more! As the topic title says, idle hum occasionally (but regularly) and seemingly randomly stops playing out of my speaker regardless of which sound font is active. This occurred both before and after getting into Fett263’s prop file and blade styles, and can always be fixed by just retracting the saber, waiting 2-3 seconds, then igniting it again. I’ve even seen it occur a couple times just sitting the saber on a stool while it’s on and not spinning, hitting, or moving it at all! Not even sure where to begin here, but I will mention as I did in the last thread I was involved in that I have been using a MacBook for coding, compiling, and uploading. Also worth mentioning that idle hum does seem to stop playing faster if I’m spinning or swinging the saber a bunch (which also occasionally leads to swing/spin sounds dropping some samples). Fett263’s edit mode also seems to accelerate the idle hum dropout. If anyone has any idea how to tackle this, or if I can provide more info, please let me know, thanks!
Hook up to Serial Monitor under Tools in Arduino and see if you can get the output when this happens. Then copy the output around when the sound drops and post the text here.
Hey! For whatever reason whenever I use the Serial Port, audio playback dies, and the saber works only well enough to test colors, ignition time etc. Might be because for some reason MacOS mounts the SD card automatically when Arduino connects to the Proffieboard. I’ll try to get the saber working normally when connected to the serial port, then I’ll check the serial output and post results here. Thanks!
@NoSloppy I have backed up and reformatted the SD Card many times, yes. No dice. I deleted some hidden files that MacOS added as well and it didn’t change anything, either.
MacOS is not any issue working with Proffieboards.
It seems you have uploaded with Arduino menu Tools>USB Type set to include Mass Storage option. That is why the SD card is mounting to the computer as a drive.
IF you can use a stnd-alone SD Card reader, change the option to Serial Only to avoid interruptions, and risk of corruption due to not properly electing the volume before disconnecting USB or uploading to the board.
Playing GreyPal/hum/hum01.wav
Failed to read 12 bytes.
Audio underflows: 384
Audio underflows: 202
Audio underflows: 71
Leaving the saber retracted for the normal amount of time I do to fix the issue results in
Unmounting SD Card.
Amplifier off.
Also @NoSloppy THANK YOU for catching that mass storage option I clicked, brainlessly selected that on setup and just toggled it to Serial only. Whenever the SD card unmounted as above, it would mount to my laptop instead because of my USB setting.
I’m gonna try formatting the SD card again and re-flashing everything. I’m betting the SD card got corrupted because of all the improper ejections. I will also note that even with the standalone SD card reader, I tend to have issues normally ejecting the card.
How so? I mean, you have to be patient, sometimes it takes a good 30 seconds maybe.
Add it to your Privacy tab in Spotlight settings so it doesn’t try to index it everytime it mounts.
System Settings > Siri & Spotlight > scroll to bottom and click Spotlight Privacy…
Drag your mounted SD Card icon to the list. Close the settings to save.
Ok @NoSloppy I formatted the SD carefully, put all the files back on, and followed your instructions from our previous conversation:
The Spotlight privacy list fixed the ejection issue and setting Arduino’s USB setting to just ‘serial’ also helped. However, even after all of this, idle hum still dies the same as described above. Really weird, wondering if I permanently damaged the SD somehow.
Not to say it may be the SD needs reformatting here but I noticed your config has the define to disable diagnostic commands. Go in and comment that line out by putting two // in front of the line and flash the board to the updated config allowing diagnostic commands. Then pull everything off the SD and use SD Formatter. When you put your font folders back in only put those in. Anything outside of the font folder that’s a temp file the board created is not needed. Once done put the SD back and try the saber out a bit. Then go back and try using Serial Monitor.
With the disable diagnostic command line disabled you’ll get a more accurate read.
@A_Rogue_Child hey! That disable is actually commented out already. I double-checked the pastebin too to make sure, but I’ve known about the diagnostic commands disable for a bit now. Gimme a holler if ya see anything else in my config… there’s a lot lol.
“failed to read 12 bytes” could be caused by a lot of things, but all of them would indicate that there is something wrong, either with the file, or with the SD card.
One way this could happen would be to copy a font to the SD card, then ejecting the SD card before it’s done. This would either cause the file to be truncated, or it would cause the file to contain corrupt blocks. Corrupt blocks seems to be the more likely cause in this case since you’re also getting all those audio underflows.
Now, it could be that some part of the SD card is simply bad, and formatting the card and putting the files back means that you’re just hitting the same problem again. SD cards have their own internal bad-block tracking though, so it really shouldn’t happen, but sometimes it does anyways…
True. Add a Mac into the mix and you’re better off doing any editing in a desktop folder and then once you’ve cleaned the SD simply copying and pasting the font folders etc all in at once do less of a chance of this happening.
I feel this is giving MacOS a negative stigma.
There’s nothing different in handling the files except for the invisible resource files added on copy, which typically are never a problem, and for some reason if they are, are easily removed from the SD.
And honestly, I don’t understand any of this really, and I think it’s just going to confuse people.
The only variant of the standard process of formatting and copying files back to the card would be removing the invisible resource files afterwards.
Having diagnostic commands enabled doesn’t give you
" a more accurate read" in any way.
The average user is not going to have invisible files showing, so after formatting, copying over files to the SD is still going to create invisible resource files. Not copying “Anything outside of the font folder that’s a temp file” is irrelevant.
When I first got set up for the Proffie ecosystem I got a pretty cheap standalone card reader. It worked fine at first, but quite a few times I had to unplug and plug the thing back in for the SD card to appear on my desktop. That combined with my original USB settings in Arduino (Serial + WebUSB + Mass Storage) and the SD card getting ejected improperly over and over again whenever I’d flash the Proffieboard may have caused some irreparable damage to the SD card. As @profezzorn and @NoSloppy put it, after formatting, the bad sectors SHOULD be mapped out and avoided, but I know there is nothing wrong with my .wav files, so all signs point to the SD card.
I’m thinking best course of action is, therefore, just getting a better card reader and a new SD card, which I will be very careful to always eject properly. What do you folks think? Any solid, reliable card readers any of you recommend?
For reference, here is the reader I’ve been using.
The one I use is older and not available anymore, but it’s a Sabrent and always works perfectly . I would use a trusted brand.
This looks like the current version which also has USB-c so that’s nice.
