Driving percussions

[xpa]

Hi All,

Is there a facility in MIOS for driving a DOUT output pin with a fixed length pulse? This would be useful in driving a solenoid-based percussion instrument where the solenoid is not rated for continuous duty. I am looking at a glockenspeil on my Rodgers organ that uses thirty-volt solenoids. They would melt with anything longer than a 500ms pulse. I need to rebuild it so that it is driven by a midi signal.

I need to drive the output high for a fixed time period when the core receives a note-on message with velocity > 0. Any other message would be ignored.

There is the hardware option of using a 555 on each output, but that would be messy. The pulse period would also not be easily changeable if I guessed wrong on the pulse length. A variable pulse width would also be useful to change the 'volume' of the instrument.

Suggestions?

Thanks,

George

[jimhenry]

I don't know if MIOS has a facility for a pulse output but I'd be uneasy using it even if it did. Anything MIOS provides will be software driven. That means if anything happens to stop the processor, the pulse could be stuck on.

You are going to need some sort of buffer to step up the output to the 30V required by the Rodgers solenoid (and probably step up the current too). I don't know how to do it but I'd want to use a hardware circuit that delivered a 30V pulse of adequate current based on receiving a 5V logic level rising edge.

[xpa]

Hi,

There is nothing inherently wrong with using software any more than using a hardware solution. 555s, transistors, capacitors can fail, so can code. The  coils could be protected by fuses.

As far as the current and voltage requirements, the ULN2803 can handle 50V at 1/2 amp. The ULN2823 can handle 95V at 1/2 amp. The data sheet says, and from personal experience I know that the outputs can be used in parallel to increase the current capability. The interface to the hardware is simple if the pulse comes from software. The hardware solution would be a fabrication nightmare.

[lylehaze]

I find the hardware / software discussion very interesting..

Yes, either CAN fail, but they don't have the same failure modes at all.

Once code is "stable" it can be tested thoroughly, and it's behavior should be

as predictable as that testing was thorough. As long as the definition of "code"

is the complete package, MIOS, application, and settings, and the testing includes

all variations of MIDI input, valid and invalid.

I'd LOVE to say that tested code never fails,  but I have had bit errors in the

program storage of PIC chips.. Does that count as software error or hardware error?

But the code will always be subject to the hardware it is running on. No matter how

well the code is written, a power failure, loose connection, or blown fuse can always

bring the software down. A great mind in a frail body will soon perish.

Getting back to the discussion at hand, I suggest the following considerations:

A stuck output may burn a solenoid,  but it will not put life or limb in peril, so there is

no need for "extraordinary" safety measures. Another reason to avoid explicit hardware

timers for each output are that they would complicate the option of letting note velocity

control pulse duration.

I think a reasonable protection level could be reached with slow-blow fuses, either

at the power supply or maybe for each separate solenoid if you want overkill.

Another option could be polyfuses, as they are self resetting. This has the advantage

of reducing service visits, but can give a bad reputation for intermittent reliability

if nobody fixes the root cause of the overcurrent problem.

As technology becomes more accessible, better ways become available if we want

take it that far. A simple current monitor reading back to an analog input would allow

the PIC to monitor current usage while operating, and then establish a "baseline" of

current consumption while it operates. Now we can be smart enough to know when

one (or all) the outputs are drawing more current than they used to.

It sounds "over the top", but it's neither difficult nor expensive to do. Just a good

challenge to teach our machines to do self-diagnosis. Any abnormal readings could

be transmitted by SysEx messages that describe the variance.

Finally, from a failure analysis perspective it's important to consider, a bad solenoid

can destroy the driver transistor, and a shorted driver transistor can overheat and destroy

a solenoid. I'm not the only tech here who has a background in pinball machine repair.

Fun to think about, I hope I didn't get too far off-topic.

Have Fun,

LyleHaze

[xpa]

You have some excellent points Lyle.

I have considered polyfuses, even as replacements for the one-shot circuit, but time to reset would have to be considered. As protection alone, they would be fine.

The Artisan MicroMidi system has the ability to perform the one-shot function as well as re-it. I'm using that system in two pipe organs that I maintain. This, however, is for my own electronic instruments where experimentation is most of the fun.

I am looking at the source code for the MIOS output functions and I am tempted to try some rewrites to get the functionality that I am looking for. The problem is that I am not a very proficient code writer. This post was to make sure that I am not re-inventing the wheel, or pulse output.

George

[lylehaze]

I had not considered using polyfuses as the pulse circuit. I would guess that they are not durable enough for that many blow/repair cycles. But extra points for thinking outside the box!

I would suggest that IF you try this with MIOS, that you write this application to work through MIOS, and you avoid rewriting any part of MIOS itself. This offers you: The ability to work in a higher level language like C instead of ASM, and it makes it possible to easily port your app to newer MIOS versions later.

Let MIOS provide the well tested framework, and you just add the application specific stuff you need:

Incoming NOTE ON will turn on an output, and the velocity is stored somewhere..

periodic timer decrements the stored velocity by some preset amount..

when the velocity is decremented to zero or less, the output is turned off.

That's a simple framework to start with anyway.

since the max velocity is 127, you can juggle the decrement value and the timer interval to determine the maximum allowable ON period.

Later refinements might include ignoring additional NOTE ONs of any note that is already ON, and ignoring new NOTE ON messages until a note has been OFF for some preset "release time"

MIOS handles all the startup, bootloading, MIDI management, and lots of ugly stuff for you, all you need to do is add the "fun stuff" described above.

Have Fun,

LyleHaze