I mean it would be trivial to do actual morse code:
Sd card not found: … -… / -.-. .- .-. -… / -. — - / …-. — …- -. -…
The advantage of musical beeps is that you may be able to tell which error code it is without having the score handy if you can sing the error code to the beeps. Also, they sound better.
I don’t expect everybody to be able to actually read musical scores though. Here is how they actually sound:
SD card not found:
Battery Low: (You can also use a wav file for this one.)
Error in the blade array:
Error in the font directory:
Font directory not found:
Aliens are here:
That last one is what you hear if you use the “beep” command in the serial monitor. The five notes are the same ones that are played in “close encounters of the 3rd kind”.
I didn’t mean actual morse code. More like a beep sequence, no different than a robot vacuum’s error code reporting, or a status light on almost any device.
If we assign each error a number, then just have that number of beeps, and repeat 3 times to allow for confirmation.
Error 1 = SD Card Not Found = 1beep, pause, 1beep, pause, 1beep.
Error 2 = Error in Font Directory = 2beeps, pause, 2beeps, pause, 2beeps.
and so on.
I think it’s cute to have them sound musical, but I’m pretty sure I know a good handful of tone deaf people who would have no idea about which passage is which, but would be fine just counting the number of beeps.
Here’s what the musical beeps sound like coming from a Proffieboard:
You’d have to be tone deaf AND rhythmically challenged, because none of the error beeps have the same groupings of notes. Unfortunately “error in the blade array” has the same number of notes as “font directory not found” due to having the same number of syllables. Otherwise counting number of notes would work too.
And nobody is so tone deaf that they can’t figure out the right one by comparing to a wav file.
(Unless they are actually deaf, in which case none of this matters.)
It’s one of the reasons I moved the error messages into it’s own file; that way we can add other ways to signal errors, such as an OLED display, or the LED on the V3 board.
As for the pod page, I was thinking “what is it beeping”.
If people have things they want to get into ProffieOS 7.x, time is starting to run out. I’m hoping to move 7.x into alpha testing this weekend, which means that the bar for new features in 7.x will go up.
I would still like the option to enable Blade ID polling on “reasonable” circumstances, like preset change and/or blade retract. I think I know how to do it, but keeping a local set just for this tiny feature that can be quite useful, would greatly simplify things for those without Blade Detect pin.
Ok, I have checked in a completely untested new define called BLADE_ID_SCAN_MILLIS. if you set that to 1000, it will re-do blade ID once per second. If the blade ID comes out the same as before, it will do nothing. If it comes out different, it will do FindBladeAgain(), which will basically initialize the saber from scratch and load the right settings for the new id().
It will only work with neopixel blades, and it probably requires SHARED_POWER_PINS to work. Assuming it works at all, because I haven’t tested it yet.
Would it also require #define ENABLE_POWER_FOR_ID PowerPINS<bladePowerPin2, bladePowerPin3>
and #define BLADE_ID_CLASS SnapshotBladeID<bladeIdentifyPin>
as well?
Sorry if I misunderstand, but I gess it needs ENABLE_POWER_FOR_ID and some form of BLADE_ID_CLASS. But SHARED_POWER_PINS I understood where only needed if you had another NPXL data line connected to the same power.
ENABLE_POWER_FOR_ID is generally always needed for blade ID to work.
The BLADE_ID_CLASS depends how your blade ID is configured and if you have any external pullup resistors or bridged pins or not. If you don’t have any of that, the default will do. (hopefully)
The reason SHARED_POWER_PINS is needed is because ENABLE_POWER_FOR_ID will try to enable and disable the power for those pins, and without SHARED_POWER_PINS, the blade will actually loose power when the blade ID runs. The blade ID is sort of acting like another blade which is using the same power pins here.
What does the serial monitor say?
(Is it crashing, or is it just measuring a different ID and therefore resetting?)
Obviously it’s not meant to work that way, the question is why.
OK, If I don’t enable #define SHARED_POWER_PINS, Blade_ID just doesn’t works. I’m getting off readings from the blades, even though I put a 22k resistor between Data1 and 3.3V, but I’m assuming that’s the ECO PCB that’s mirroring the NPXL and might leech some resistance. I’m copying the serial readout in a minute.