John's Organ MIDIfication project

MIDIfication
1

TK, all,

Everytime i get a problem solved, another one comes in.

Take  look at the attached block diagram.  The PC is now running linux puppy lucid (frugal), in a headless mode.  One power on/off switch starts everything  and the same switch turns it all off, thanks to linux puppy.

The pc is running jOrgan (linux) ver. 3.14, which provides the desktop GUI and  combination action.

jOrgan appears to function without problem when operating stops, couplers, pistons, set and cancel using the mouse and GUI. See (problem 2)

Problem 1:

When operating from the console mounted devices, pistons, stops, etc., jOrgan functions but with one problem.

if a gen piston is set with stops in all divisions, say 6 or 8 random stops,  followed by gc.,  then the Gen piston is depressed, the SAMS turn on as expected.  however,  when the gc is pressed to clear the stops, multiple things happen:

  1. The pre set stops turn off.

  2. other SAMS turn on and stay on,

  3. other SAMS flutter on and off.

  4. pressing the gc multiple times changes the state of some SAMS, on to off and  off to on  .

 

The same thing happens with division pistons, and the GC.

 

Doing the above procedure with the jorgan message monitor on clearly shows the preset SAMS turning off, and also shows other Sams

operating, i.e. on magnet turned on  then off after slight delay per SAMS extension.

 

Problem 2:

 

Doing a close check of the state of SAMS which should have been off, the cooling fan on the 30A - 12vdc PSU came on.  A close check revealed SAMS that were off, but hot, and when the TAB was moved, returned to the energized position, indicating that the SAMS extension had not turned the off mkagnet off.

using the jOrgan message monitor, and cycling the SAM with the mouse showed that in fact the SAMs off magnet was still energized.

Cycling the SAM using the mouse turned it off after a few cycles.  My first suspecions are; a week magnet, misadjusted mechanical stops on the SAM armature, or possibily low voltage due to excessive load on the 12vdc PSU.  However, it could be that problem 1 and problem 2 are related.

 

To complicate things, note on the block diagram that the sense contacts on the SAMS are matrixed (with diodes) using a KB pcb, tied to an LPC17, whereas the piston inputs come through DINS on the core8, and SAMS drivers are on DOUTS with ULN2803 drivers also on the core8. There are 2 KB pcbs, #1 encodes two keyboards, #2 the third keyboard, and SAMS sense contacts. The keyboard maticies are configured to exit through midiout 2 on the LPC router which outputs messages to  an Artisan Sound engine, along with activated/de activated messages for all SAMS, Pistons, couplers.

12vdc PSU Grounding was the subject of a thread some time ago as regards this setup.

 

At this point I am puzzled.  The system worked fine until recently.

 

Any suggestions, comments, questions, troubleshooting tests, etc are welcome.

[Organ block Diagram - Ground.bmp](< base_url >/applications/core/interface/file/attachment.php?id=11112)

2

I can’t help you on potential issues with jOrgan, Linux or your special hardware circuitry.

 

However, hopefully a hint which helps:

 

however,  when the gc is pressed to clear the stops, multiple things happen:

  1. The pre set stops turn off.

  2. other SAMS turn on and stay on,

  3. other SAMS flutter on and off.

  4. pressing the gc multiple times changes the state of some SAMS, on to off and  off to on  .

 

I don’t know what you mean with “gc”, but I guess that you want to say, that strange (uncontrollable) things happen when many outputs are changed at once, right?

 

Does this also happen if you remove parts of the hardware?

E.g. especially to 3) - do these SAMS also flutter if all other SAMS are disconnected?

 

And how long are the cables between the Core, DIN and DOUT modules?

They should be as short as possible!

 

Best Regards, Thorsten.

3

Hi John,

 

From an earlier PM message, you indicated that when you press the GC (General Cancel) button, that all the SAM’s are being told to turn off, even if they are currently off.  If this is the case, we might be able to use this for some of your debugging.  Something that worries me (from previous PM) is that with all of the SAM’s being told to turn OFF, you should only see OFF Midi messages coming from your SAM reed switches, but you are seeing some ON messages.  I think this is part of the problem but not sure.  Since the General Cancel button energizes the OFF magnets even if they are OFF, you might just remove your Matrix board from the mix by disconnecting it so the reed switches can’t send the spurious ON messages which are muddying the waters.  When I say remove, I mean totally remove the matrix board which is connected to the LPC core.  Doing this you should not see any Midi traffic due to the matrix board.  Now pressing the General Cancel button should still energize the OFF magnets.  If all of the SAM’s turn OFF and don’t flutter, then you know that the problem noise is not getting into your DOUT chain.  If they still flutter, check that there are no Midi messages from the non-existant matrix board.  There may still be a problem because the DIN serial chain wire is still running thru the DOUT cables.  With the LPC board running at 3.3 volts, that input will be much more sensitive to noise from the magnets.  

 

Something that you might also look into is the Matrix board input resistors.  I don’t remember if there are pull-up or pull-down but you might check if they are 10k ohm.  If they are, you might want to reduce them so the induced current spikes will not be as bad.  And I hope that these matrix reed switch wires are not bundled with your magnet wires.  

 

Pete 

 

PS - I don’t think this information should be part of the MIDIO128 V3 thread.  It should have a separate topic all its own.

4

Yes, a separate topic makes sense for all conversations which belong to John’s project, so that it’s easier for interested readers (who want to build something similar) to follow.

 

Any proposal for the subject?

 

Best Regards, Thorsten.

5

Kpete, TK,

I put the post in this topic, since midio128 ver.3 is the basis of system operation. What catagory would you prefer, troubleshooting, midification?

TK, the “GC” is the general Cancel, and for all practical purposes is just another contact input to the DIN chain.  More specifically, the “GC” causes jorgan to send out off messages to all DOUT pins.

per the message monitor in jOrgan, it is doing that, however, some  on messages are also going out which shouldn’t be.

pete - the resistors on the matrix boards are 10K.

As for loose wiring i must admit my guilt.  in most cases the DOUT wiring to SAMS and matrix  wiring from SAMS contacts is separated, but still in close proximity, 2-3".  Strangely, the random situation is recent,  has not been that way until recently.  At Christmas time, i had to dis-assemble everything which was in a setup mode, i.e. pc,  soundengine etc., although all midibox devices and wiring remained unchanged.  during that time, i moved the PC so as to get linux puppy lucid loaded and setup to run jOrgan.

You troubleshooting test sounds good to me and could be most helpful.  i’ll  do it and get back to you.

TK,  MIOS Studio would be a great tool, but is asking for glibc2.15 before it will load.  Evidently puppy lucid uses an earlier release.  See thread in the MIOS Studio topics. Sure would be nice to be able to use it with linux puppy lucid 5.2.8!

DIN cables that extend from  the SAMS KB pcb (LPC17) to the SAMS are approx 5 feet long for the longest, 18" or so for the shortest..  the SAMS are mounted on a theatre organ style, horseshoe shaped bolster with a 2’ +/- arc. DOUT wiring that extends from the DOUTs to the SAMS parallels the DIN wiring.  There are 64 SAMS in all, bounted side by side around the horseshoe.  There is no way to shorten the wiring.

Thanks for the comments and suggestions.

Johnc

ps;  the block diagram I attached needs updating, I’ll post a better one.

6

I separated the topic. If you don’t like the subject, just let me know how we should call it :wink:

 

Best Regards, Thorsten.

7

TK,

the new topic name is fine!

Still a bummer not being able to use MIOS Studio.  i don’t fully understand why puppy lucid is not compatible, but it does run the organ, so I shouldn’t complain.

In implementing kPetes test, I did find a problem that may be the culprit.  one of two things has happened: some of the wiring in the matrix that monitors the SAMS sense contacts is messed up, or some of the diodes in the matrix are bad.  Need some more digging to isolate the problem. 

I mentioned a power supply issue on another topic and was hoping for some comments.  Many of my DIN and DOUT pcbs are early SMASHTV boards, designed before the  additional 100uf caps were added on the 5v pins on the chips.  This was for noise suppression, i suspect, and have concern that this could be some of my problem.  In addition, the 12vdc PSU for the SAMS has a common ground with the 5vdc supply for the core 8 and jindirectly the dc supply on the LPC17. Any comments would be appreciated.

johnc

8

 kPetes test, I did find a problem that may be the culprit.  one of two things has happened: some of the wiring in the matrix that monitors the SAMS sense contacts is messed up, or some of the diodes in the matrix are bad.  Need some more digging to isolate the problem.

Go ahead and debug your matrix wiring but I suspect your matrix hardware and wires are picking up the currents when the magnets are turned On or Off.  If the matrix performs fine without activating the SAM magnets, then I would consider changing the input resistor values from 10k ohm down to something like 470 ohm.  This will reduce the likelihood that the spicks will not be coupled into any of the open reeds. 

 

My direction would be to investigate the SAM output first by disconnecting the Matrix switches and proving that this side is working without problems.  You may have problems in both Matrix sensing and the Dout shift register chain to the SAM magnets.

 

Go ahead and add the 100nf (they are not uf.) but these are for small spikes.  Your spikes are 1A per SAM and without measuring, I believe the current could decay in over 1-2us or more.

 

And something that I am also wondering is do you know if ALL of the SAM’s are the same type.  Meaning were they bought as “Common -” or “Common +” SAM’s. 

9

kPete,

I disconnected the kb matrix card that encodes the pedal and the SAMS contacts, and nothing changed.  After some thought and checking i remembered that the way the SAMS extension in jOrgan works, after the note on message is sent out, if the SAMs armature moves, the sense contact closes.  The SAMS extension looks for the closure, then sends out the off message.  it also times out for 500 ms and sends out a second off message.  So even if the sense contact is not working, the SAM will be turned off..  however, going through all of the SAMS, at least 1/3 were being turned off by the second timed note off, and the sense contact is not closing. This was confirmed by just toggleing the physical tab on the console.  A close look at the matrix and circling the positions based on the hex note #,  one full row is not working, and the other positions are random.  i suspect a wire is loose for the row, but the random could be wire, or diode.

I even found one case where both of the magnet off messages were not reaching the SAM, so it stays energized. need to look seriousluy at that one, so i don’t burn up the SAM.

More later.

Pete, you are knowledgeable about jOrgan,  Are you using a linux distro on the pc?

johnc

10

kPete,

I disconnected the kb matrix card that encodes the pedal and the SAMS contacts, and nothing changed.  After some thought and checking i remembered that the way the SAMS extension in jOrgan works, after the note on message is sent out, if the SAMs armature moves, the sense contact closes.  The SAMS extension looks for the closure, then sends out the off message.  it also times out for 500 ms and sends out a second off message.  So even if the sense contact is not working, the SAM will be turned off..  however, going through all of the SAMS, at least 1/3 were being turned off by the second timed note off, and the sense contact is not closing. This was confirmed by just toggleing the physical tab on the console.  A close look at the matrix and circling the positions based on the hex note #,  one full row is not working, and the other positions are random.  i suspect a wire is loose for the row, but the random could be wire, or diode.

I even found one case where both of the magnet off messages were not reaching the SAM, so it stays energized. need to look seriousluy at that one, so i don’t burn up the SAM.

More later.

Pete, you are knowledgeable about jOrgan,  Are you using a linux distro on the pc?

johnc

John

 

For what it is worth, I had a similar problem - SAMs fluttering, all SAMs on the backrail not functioning, and some SAMs always energized. Your statement “one full row is not working, and the other positions are random.  i suspect a wire is loose for the row, but the random could be wire, or diode.”  I found a bad (intermittant) common connection between the stoprail SAMs and backrail SAMs. This condition would also damage the 74HC165N on the DIN board corresponding to the first SAM on the backrail every time a backrail SAM was activated (I changed a lot of I.C.s). I discovered this by careful visual inspection. I am using jOrgan under Windows XP, 3 MidiBox Core 8’s, and latest DIN and DOUT boards.

 

Al

11

Hi John,

I haven’t done anything with jOrgan at all.  There are only so many ways these combination actions work and your responses is what I am keying off of for my responses. 

 

You indicated that nothing changed when you removed the Matrix board that senses the reed switches for the SAM’s.  I have to assume that the SAM’s are still fluttering On and Off.  Is this true?

 

If it is true, do you still see On and Off messages from the LPC core for the non-existent Matrix board?

 

It sounds like the combination action will work the SAM’s even though the reed data is not being sent to jOrgan.  This is good.  This way you can make sure the magnets aren’t interfering with the serial data going to the Dout shift registers.  You might also look for conditions where the 2 coils of a SAM are being energized at the same time.  This can also happen if noise is getting into the Dout SR chain.  And I sure hope that after the second cycle of the 1/2 second period that all of the magnets are turned OFF.  The magnets can get real hot if they are left on for a long period of time.

 

Pete

12

Kpete, Aeoline8,

Found what i feel initiated the problem, The DOUT chip on KB matrix #4 (Sams contacts) is in fact bad, and failed while I was doing tests.  the chip fused to the socket which will require some major repair.  Al i will check to see if damage was also done to the DIN chip on that KB.  you were correct on the wire issue, found two bad solder joints.

FYI take a look at the revised block diagram below.

I’ll update the post after repair.

Thanks Guys1

johnc

post-3665-0-10266000-1390922929.jpg
post-3665-0-10266000-1390922929.jpg1200×600 56.8 KB

13

Update:

the socket and both chips are replaced for matrix#4 on KB pcb#2.  Evidently that was not the problem.

Same issues as before, with a new twist.

  1. Activating the stops on the desktop cycles the stop on and off both visually on the desktop and the physical stop tab as well for stops on the ACC,  solo and pedal. cycling stops on the great not only activates stops on the great, but stops in other divisions as well, much like pressing a piston.

  2. The GC physical piston still does the same thing with fluttering, activated stops, and activated then deactivated stops. pressing the GC again repeats the same action.

3.  some Off magnets(on the great) are still  not being de-energized , although in the off position. it appears that the SAMS extension in jOrgan is not sending out the final off message.

next task is to remove the DIN and DOUT chips and trace all wires in the matrix for the SAMS on  the Great. 

More later.

johnc

14

John

 

Sometimes jOrgan gets “confused” by such problems, even if the disposition is not saved. Look through your disposition carefully for incorrect or missing references. Also try finding a saved disposition that worked before the problems occurred. (I know this is not a MIDIbox topic but it may be a non-MIDIbox software issue.)

 

Al

15

Remove the Matrix board from the entire system and debug the Dout system first.

 

Pete

16

The 500ms timeout seems about 10x too long as I’m using 50ms pulses successfully, though on higher voltage SAMs.  If anything is slowing down the MIDI communications then it’s possible that you are bouncing the SAMs sufficiently that they actually do switch back on for a moment and cause the fluttering.  I realize the 500ms timeout is there as a safety precaution and shouldn’t be coming into play of course.

 

Also, the inputs from the SAMs need to be as well debounced as you would do for keys.  I assume that’s the case.  Sorry, I’m not totally up to speed on your hardware but am offering some advice based on similar projects.  I like Pete’s last advice as well having recently fought with a couple of “spooky” matrix issues myself.

17

You are absolutely right.  50ms is more than enough to change the SAM state.  The 500ms time comes in because I asked for the SAM reed switch logic to be disconnected so they won’t send the changes of the SAM’s to jOrgan anymore.  John indicated that there was a 500ms safe guard in jOrgan that would turn off a SAM magnet that might have been left ON.  Wanted to use this to make sure the Dout chain was stable before worrying about the Matrix Din chain.  And still haven’t heard anything about if he might be using - common SAM’s on the + common Dout boards.  If this is the case, he could be having issues with magnetic cross talk between the SAM’s.

 

Pete 

18

wow, guys, lots of suggestions, all appreciated.

 

  1. No to the +/- Sams question. negayive common SAMS with - common psus.

  2. The matrix chain is working after a thorough check of all solder joints, and replacement of several chips, as well as new connectors.

i had some wired spare pisrtons on te keyboard so i reprogrammed jOrgan to use a different piston as the GC and it works fine while the old one still does the same as previously.  i will go thru the wiring from Pistons to matrix for some glitch.

  1. All the DOUT chains are working, having done some upgrade to the PSU wiring to the DOUT boards.  Also replaced one SAM that was not working at all.

 

last issue to deal with involves the DOUT chain and SAMS on the great. After a GC, clearing all stops,  2 or 3 are remaining energized on the great, even though the tabs are off.  They heat up quickly. i am in the process of replacing the 595 and the uln driver chips on the DOUT, so hopefully that may solve the problem.  I also need to see if the disposition is corrupted.

 

i have not tried using a shorter pulse time for the SAMS.  It should be long enough to allow the feedback from the SAMS contact the receipt of which causes the SAMS extension in jOrgan to send out the off signal.  Strangely, The disposition has 4 sams extensions, one per division, and the other stops on the great work fine.

 

Johnc

19

Al, kPete, TK,

just an Update!

After re-arranging some wiring associated with the KB matrix cards, in particular the KB encoding the  SAMS contacts, the problem with the GC and pistons has gone away.  Evidently, the KB wiring must be kept short and care taken to isolate DIN wiring from DOUT wiring.  That is difficult to do on a Theatre organ horseshoe stop Bolster as the SAMS are distributed all the way around.

Still one problem still exists and that involves, SAMS not receiving the final tab off message.  Everything works well on the  “on” side, but on the SAM off cycle, the final tab off message does not come thru everytime and the off magnet stays energized.  This happens on only one division, and just a few stops, and does not happen every time.  I  suspect hardware is the cause and will go through wiring, chip contact in the sockets, etc.

Johnc

20

Kpete,

you have some posts dealing with the recorder/player on midio128 V3, and seem to be up on the player.

Is there some special setup as regards the router in the LPC-17 and midio128 v3/

As you may recall, i am usng 2 KB modules  with 4, 8x8 matices for 3 KB’s, &  SAM contacts, and an additional line with one core9 and DINS for pedal and pistons. The organ operates without a computer attached on the front end, no jOrgan, miditzer, etc.  using the router, all midi out messages  go out on “out2”  to an artisan soundengine.

each of the matrices specify midiout on out2; the midiout on the core 8 connects to “in1” on the LPC.

I have tried the midi rec/ player which appears to record, but there is no playback.

Is there a setup to select the source router port for recording  and the destination router port for playback.

Lastly,  will the recorder capture everything, stop changes, pistons etc.?

Organ is fully functional.  see attached diagram

Thanks,

Johnc

post-3665-0-92990900-1416525118.jpg
post-3665-0-92990900-1416525118.jpg1200×1553 58.3 KB