safety check #107
safety check #107
Conversation
Check on edrumulus startup, if the ADCs roughly detect the expected 1,65V from the voltage divider circuits. If not, abort and inform the user via serial console about the issue. The control port is skipped. This check may may detect: - incorrect analog circuits - broken microcontroller ADCs - pads drawing current - accidental shorts
|
That's a good idea to inform the Edrumulus user about a possible DC offset issue. I have decided to implement this a bit different from your solution. I'll do this check periodically when also the sampling rate check is performed. Then I can detect if, e.g., an input is short cut or during operation the front end has changed (a resistor has no contact after vibration). Also, I have the advantage that I know which input is the control input (which you do not know in the setup function). If the DC offset is too large, the board LED will flash quickly, indicating clearly that there is something wrong with Edrumulus (note that the board LED will now also flash if the sampling rate is too low which I have implemented some days ago). I decided not to abort the ADC read since even if the DC offset is large, it may be possible to operate Edrumulus almost normal and I do not want to disable Edrumulus completely at some undefined time (maybe during a song with your band...). This is my commit: 621f3a5 |
|
Sounds reasonable to me. One of the main points why I wanted to abort reading the ADC was in order to not break the hardware though. As you know it happened to me that the voltage divider was not connected to either 3V3 or GND (due to the "mind the gap" issue) resulting in the piezo with negative voltages to be directly connected to the ADC. That check would've detected it, but as long as the ADC continues reading, the microcontroller is likely to die anyway. Maybe some sort of global performance mode setting to always attempt to go on with the default being the more safe practice mode would help here. Or simply make the bounds themselves configurable. If not, I'll likely have to patch your lower bound for my setup as I still have at least one pad running at only slightly above 1V since it's still trying to draw more current than it can get. Also, I'd suggest to print the offending pins to serial out to help debug hardware issues. |
The question is if the ADC died or the multiplexer. Also, I guess it would have made no difference if the ADC was turned off or on. I assume that your Teensy would have been broken anyway. You have to start the ADC to detect that the DC offset is incorrect and during that time it would have died anyway, I assume.
My bound is set to accept a waste of 1 bit, i.e., half the available maximum dynamic. For a 12 bit ADC, the allowed range is from 1024 to 3072 which should be large enough for your use case.
The ESP32 cannot use MIDI and serial at the same time. |
|
On 10/31/23 09:39, Volker Fischer wrote:
> That check would've detected it, but as long as the ADC continues reading, the microcontroller is likely to die anyway.
The question is if the ADC died or the multiplexer.
Pretty sure it was the ADC as I received relatively reasonable, but slowly moving values rather than none at all.
Also, I guess it would have made no difference if the ADC was turned off or on. I assume that your Teensy would have been broken anyway. You have to start the ADC to detect that the DC offset is incorrect and during that time it would have died anyway, I assume.
And yes, I have to read from the ADC to detect the DC offset in the first place. However that takes 1ms or so. The negative voltages that caused my Teensy to break only occur when I hit one of the drums, which is very unlikely to happen during that check time: Usually I start my Teensy first and then need seconds to minutes before using my drum set. During that timeframe such checks can easily save my Teensy. Once I start playing it's too late for it.
> If not, I'll likely have to patch your lower bound for my setup as I still have at least one pad running at only slightly above 1V since it's still trying to draw more current than it can get.
My bound is set to accept a waste of 1 bit, i.e., half the available maximum dynamic. For a 12 bit ADC, the allowed range is from 1024 to 3072 which should be large enough for your use case.
OK, I'll test that.
> Also, I'd suggest to print the offending pins to serial out to help debug hardware issues.
The ESP32 cannot use MIDI and serial at the same time.
Ah yes, I forgot about that. It might make sense to then define some print function that does nothing on the ESP32, but uses Serial for the Teensy.
|
|
FYI, I just implemented a new feature on a Git side branch which will give you the information about the problematic pad (input) in the Edrumulus GUI:
It uses the normal MIDI transfer and therefore, it works for the Teensy as well as for the ESP32. |
|
That looks like a very good way to report errors. Maybe print them in red though? I look forward to see that in the main branch! :-) |
I think this is not necessary since the text is in capital letters and it is blinking: Bildschirmaufzeichnung.vom.03.11.2023.17.40.29.webm |
Nice! I agree. I however still think it would be safer to not read from the ADC on critical errors (i.e. wrong voltages). I'm also unsure about the "what happens if it's during a gig?" argument as both edrumulus refusing to work as well as the ADC breaking will eventually interrupt the gig. And the latter is not even fixable without new hardware. |
It's on main branch now.
As already written above in one of my posts, I'm not sure that it would have made any difference if the ADC was on or off. I assume that your Teensy would have died in any case caused by the incorrect voltage. |
Check on edrumulus startup, if the ADCs roughly detect the expected 1,65V from the voltage divider circuits. If not, abort and inform the user via serial console about the issue.
The control port is skipped.
This check may may detect: