MBSIDx4, control surface frozen

Testing/Troubleshooting
1

I am sooo close, but some little gremlin has taken my prize away.

Last night I finally had the whole MBSIDx4 working with full control surface for the first time. I was exploring all the features for the first time; 303, WT, etc, and after making my first patch that I was happy with, I tried to save it in bank B of my 8 bank bankstick.

While trying to use the SAV submenu (which, btw, I have found no documentation on, maybe i’m not looking in the right place) I was stuck at trying to change the name of the patch from <empty> to something else. I didn’t know what to do so it was a few minutes of trial and error.

Eventually I gave up trying to name it, so I wanted to switch to another patch in Bank A and then go back to B002 <empty> and see if the new patch had actually been saved.

When I changed to Bank A, the internal default patch was enabled and no matter which patch I went to, nothing changed; it stayed the default patch and no patch-changing ‘click’ was occurring.

I thought at first, ‘oh no I’ve erased my whole bankstick trying to save this thing’ but then I thought this was probably unlikely since all the patchnames were still there. I powered-off and turned it back on and then none of my control surface worked. Not one button, although the standard LEDs that light up at startup were on. After a few restarts, trying with the bankstick plugged and unplugged, I figured nothing was going to change this way, so I tried re-uploading the MBSID app via sysex, thinking maybe my save attempt messed with the software.

When I got no changes from this, I tried re-updating the MIOS using the “update with old mios” sysex file included in the MIOS 1.9 release. Then reloaded the SID app and still, same behavior. Then I tried sending program change messages from my DX7 and discovered that all my patches are indeed still there: the one master SID that is enabled (since i cannot press the ‘link’ button) will ‘click’ and change to whichever patch I please; just not accessable from the control surface.

I checked my wiring and nothing has changed since last night, both DOUT and DIN are a-ok as far as I know, and it seems this problem is at a deeper level than DIN and DOUT because both the LEDs and buttons/encoders stopped working at the same moment.

Does anyone have an idea? a similar experience? Please help, I was literally recharging my camera to take a final picture of the thing when this happenned!

2

and it seems this problem is at a deeper level than DIN and DOUT because both the LEDs and buttons/encoders stopped working at the same moment.

Sounds strange …

But I would first check the hardware (what you did already) and then try to upload a test application to the Core connected to the control Interface.

A good tip is to start with the ain64_din128_dout128_v1_3.zip App to verify if all knobs/encoders/Leds are working. You won’t have to change the app. Just upload it via MIOS Studio.

If all controls are working you really have a strange problem. If not, take your multimeter and measure the connections from CORE to DIN/DOUT and the voltages on all ICs.

To me it sounds like a problem between the CORE and the DIN/DOUT connections.

greets

Doc

3

I’ve tried this today, both double checking my DIN/DOUT connections and running the app mentioned, and the response on the LCD reads like this:

Received an AIN

Event:    $$/$$$

where $ is an ever-quick-changing digit.

Pushing my buttons have absolutely no effect but when I spin my encoders REALLY fast, the first two digits of the readout tend to slow down a bit and hover at a certain number.

How does one customize the app so that it filters out AIN inputs? I thought maybe it’s receiving so many of AIN that the LCD isnt displaying the DINs.

is this AIN readout expected (I have nothing attached to J5 on the cores) or is this a sign of something else amiss?

EDIT:

I’ve now tried switching the master PIC to a different core and I get the same problem, so the actual core board being a problem is out.

I’ve also tried only having DIN or only having DOUT plugged in and the behavior is the same, i.e. either buttons and encoders do not change the information on the LCD (when only DIN is plugged) or the lights turn on to initial positions but do not move- like the matrix which usually flickers after boot (when only DOUT is plugged).

I’m reducing the possiblities of problems to quite a narrow margin now. Does anyone see somewhere that I am not looking?

4

is this AIN readout expected (I have nothing attached to J5 on the cores) or is this a sign of something else amiss?

I missed to told you that you have to ground all analog inputs (CORE J5, Pins A0-A7). Then you won’t get the ain messages. Sorry, my fault.  :-* :cry:

I’ve now tried switching the master PIC to a different core and I get the same problem

You mean, you can’t use buttons on any Core?

Still strange.

Please try the mentioned app (with grounded J5) and let me know if your knobs work then.

greets

Doc

5

dayam. ok i’ve finished my two day journey into installing osx tiger (i only did it so i can run mios studio!) and now that i have my 'puter up and running again, i’ll give that a shot Doc.

Also I’m going to try sending specific sysex messages with mios studio to see if this changes which LEDS are lit up.

6

Two things would be interesting for me:

how does the CS behave, when no BankStick is connected?

Which BankStick (EEPROM types) are you using exactly, and are there different Chip-Select configurations (Pin #1/#2/#3), so that each BankStick has an individual address?

2: Do you see a “*” marker left to the patch number in the SAV menu? This identifies, that no BankStick has found for the selected bank.

Changing Pattern Names: CFG->Nam

Best Regards, Thorsten.

7

TK, the CS behaves the same whether a bankstick is plugged in or not. Right now I have the bankstick unplugged as I try to do all my debugging, but even in those 3 hours when everything was working, was getting it to work fine with or without the bankstick.

the only difference is I get the startup “ping ping ping” when the banksticks are plugged, and now that the CS isnt responding, when I use a midi signal to change the patch, then turn off, then unplug the bankstick, turn back on, then turn off, and plug the bankstick again, the patch is still at what I last set it.

I am using 3 of the 512kb banksticks, arranged on a vector board in accord with the instructions on the bankstick page, so that the addresses are A=0, 1, and 2.

8

Ok, in this case I’m sure it’s an interconnection problem as already assumed by doc.

You should try the srio_interconnection_test_v1 to check the control lines to the DIN/DOUT modules. The test procedure is described in main.asm

Best Regards, Thorsten.

9

Thanks a lot TK, a whole lot.

I’ll explain everything for the benefit of any future OSX and/or MBSID person that has similar problems.

I had tried the srio_interconnection_test_v1 test before, or rather attempted to try it, the other day but was frustrated with it not responding to my dx7’s modulation wheel, and was unable to figure out how to change the code to accept input from another CC#. This, of course, is my problem; but I wieghed the options and decided that my chosen path was less time-consuming. [perhaps it wasnt  >:(]

So, I thought I should be able to find the problem myself by painstakingly testing the continuity of every wire from DOUT to LED and DIN to button/encoder, and by going over the DOUT and DIN pcbs and doing the same to make sure circuits were isolated.

However tonight I discovered many things: now that I can run MIOS Studio on my computer (after a 3 day hiatus to do the OS upgrade) I discovered that my DX7’s modulation wheel jumps from 0 to 6 instead of passing through 1 and 2, which are needed for the srio_… test. Then I discovered that the virtual keyboard within MIOS Studio jumps from 0 to 5!

So my solution (and maybe there is a better way but this is what I thought of) was to run Midipipe, an OSX app, and patch it like this:

MIOS Studio -> Midipipe Input1 -> Control Split [set modulation wheel to _Scale_ all input to values 0-3] -> Firewire Midi Out [my midi interface to the mbsid].

Then I used the MIOS Studio virtual keyboard to send the modwheel signals correctly, and was able to eventually discover that that was indeed a short on the PCB of the DIN, and that this short only occurred when the DIN boards were set in place underneath my control surface.

Why only then? well after a lot of poking, it was no less than 3 of the uF caps that were intermittently touching parts of the backs of DIN PCBs, but would ‘spring’ back up to not touching (and thus not causing an observable short) when I would scrutinize the PCB in my hands with a magnifying glass.

My temporary solution is gaffer tape an a hand adjustment of the offending caps. Soon I’m going to make the support for all of my DIN/DOUT boards better, which is a shame because I can barely fit everying into my C16 shell as it is.

??? I would like to confirm one thing however, even though my system seems to be working fine now:

The “D0” of Core J8 and DOUT J1 referred to in the main.asm of srio_interconnection_test_v1 was a little confusing to me, until I eliminated the possibilities and realized it referred to the “SO” on the J8 and J1 in the pdf documentation I’ve downloaded. IS this correct?

thanks again

 

10

Yes, thats correct, I will change this in the main.asm

Great that you sorted it out!

Best Regards, Thorsten.