SSP shuts down in POD60 case when connecting QAM buff mult

Bug description (state clearly and simply): When connecting a SSP output to the input of a QAM buffered multiple in the same Eurorack enclosure, the SSP reboots or shuts down immediately when the two modules make electrical contact. SSP is unaffected if the QAM is in a separate Eurorack enclosure.

Steps to reproduce (use numbered list):

  1. Install SSP in a 4ms Pod60 case along with a Rides in the Storm QAM buffered multiple module.

  2. Power on the case.

  3. Extend a patch cable from the SSP’s output jack to the QAM input jack.

  4. SSP shuts down immediately.

Software version (blank if unknown): 13072022

Type (major or minor): Major (if your SSP shares a Pod60 case with a QAM buff mult)

that won’t be a software fault.its going to be an electrical “fault”.
given its not happening in a different case, Id suspect its something to do with ground.

obviously given the nature, id be very careful on how you test this… shorting to ground is not a good thing.

obviously, the question is which is at fault…
the easy thing to do, is to test the SSP with other modules in the same case.
if it doesn’t do it, then its not at fault.

note: its best to test the SSP with other modules.
it could well be the QAM will work with other modules, even with a fault.
e.g. it be unlikely to show up with an analog module.
the issue here… is that digital modules, will tend to reset on things like shorts, or undervolting.

so testing, if the SSP is fine with other modules, chances are its not where the fault lies.


my suspicion, and again, it can only be that is…
one of the modules has an issue with the jack socket… such that as you place a cable in , the tip touches the sleeve, and creates a short (this would not normally be an issue) - so the jack insertion is the issue.

note: im assuming you are plugging an OUT to IN, not out->out, or in->in … though this SHOULD be protected these days!

you could test this theory in two ways.
a) plug the cable in whilst powered OFF
I suspect you won’t have an issue, it’ll work fine - as its your not inserting a jack

b) test SSP
power off, have jack plugged into QAM, but not into SSP
power on, then plug into SSP.
if this restarts, id suspect then Id be concerned both the SSP side…
(try different sockets on SSP, same issue?)

c) test QAM
power off, have jack plugged into SSP, but not into QAM
power on, then plug into QAM.
so reverse of (b), if this causes an issue, it points more to the QAM.
again try different jacks.

i have a similar setup (with a synthorek MST07 buffered multi) so i can test this setup / problem too

btw: just a note to the above…

obviously normally, plugging in a jack to socket, or even having faulty patch cables would not normally cause an electrical fault - so ‘something is wrong’ if this happens, basically a short, which likely draws a ton of current and so undervolts the SSP, which is why we see the reset.

the other thing Id be tempted to test is…
if you find the SSP works with another module in your other case.
then try it also in the pod60 (even if you cannot mount it), as it may be worth testing that the Pod60 does not have a fault… as this is always possible. (even if it feels unlikely)
(obviously, you’ll need to use a module that SSP+ other module does not exceed supply current of Pod60)

similarly, Id assume you tried other patch cables, again. even a fault cable shouldn’t cause the issue, but always good to start eliminating contributing factors.

Thanks, Mark and wavejockey, for your replies. I will follow the test procedure and report on the results.

1 Like

Good luck. Hope you find your issue.

just be a bit careful given the nature of the issue.
eg damaging a 2k module due to a faulty buffered multi would be heartbreaking.
Not saying it’s gonna happen, or this is definitely the cause , but wise to keep things in perspective … curiosity killed the cat and all that !

Mark:

Below are the outcomes from the tests performed per your recommendations (italicized below). I’ve included the results (in bold) under each test section.

################
you could test this theory in two ways.
a) plug the cable in whilst powered OFF
I suspect you won’t have an issue, it’ll work fine - as its your not inserting a jack

a) RESULT: As anticipated, no issues.

################
b) test SSP
power off, have jack plugged into QAM, but not into SSP
power on, then plug into SSP.
if this restarts, id suspect then Id be concerned both the SSP side…
(try different sockets on SSP, same issue?)

b) RESULT: SSP crashed on plug insertion from QAM to all SSP IN and OUT sockets.

################
c) test QAM
power off, have jack plugged into SSP, but not into QAM
power on, then plug into QAM.
so reverse of (b), if this causes an issue, it points more to the QAM.
again try different jacks.

c1) RESULT: SSP crashed on plug insertion from SSP to QAM on all SSP IN and OUT sockets.

c2) RESULT: Attached a different QAM to the power bus along with the SSP. The SSP crashed in the same fashion as before.

Looks like the QAM is suspect. I’ll contact Rides in the Storm to see if they have any insight into this issue. :frowning_face:

################
d) the other thing Id be tempted to test is…
if you find the SSP works with another module in your other case.
then try it also in the pod60 (even if you cannot mount it), as it may be worth testing that the Pod60 does not have a fault… as this is always possible. (even if it feels unlikely)
(obviously, you’ll need to use a module that SSP+ other module does not exceed supply current of Pod60)

d1) RESULT: Removed SSP and QAM from Pod60. Removed power bus from Pod60 case and reattached SSP and QAM on exposed power bus. Applied power to the bus and tested SSP to QAM connection. Same failure as above.

d2) RESULT: Attached an Erica Synths Cursible module in place of QAM in the “exposed” setup. Applied power to SSP and the Cursible. No issue with connection to other module. Also tried a vpme.se Euclidean Circles module. Again, no issue with connecting to the SSP.

NOTE: Detected strong ozone odor from SSP when removed from the Pod60 case. The odor was especially strong around the SSP’s jack farm. Is this normal?

################
e) similarly, Id assume you tried other patch cables, again. even a fault cable shouldn’t cause the issue, but always good to start eliminating contributing factors.

e) RESULT: Same outcome with different cables.

Thanks for your help, Mark. I’ll see what Rides in the Storm has to say.

1 Like

well, as frustrating as it is… better to find the issue with the ‘cheaper’ module…

whilst Id not expect it… I cannot say, I sniff my SSP often :wink:

Im not an electrical engineer, but I think ozone is caused by an electrical spark… see this
so yeah, thats not ‘normal’.
(though thinking about it… I kind of remember this with some old electronic gear Ive had in the past)

usually Id say look at the SSP pcb, but not sure if you see something on the front, or the backside, and the front means removing the front panel … so probably not worth the effort.
(besides, it won’t really determine if its cause or effect)

I think, I’d only get concerned, if you notice the SSP has this all the time with other modules as well,
if its only with the QAM, then its not a totally surprising result of the short.

apart from that, Id test all the SSP io ports (not with QAM!) , just to check they are still all ok, Im sure they are… but it’ll make you feel better !

again, I re-iterate, my first step is now you have a fair idea of the issue, Id stop testing and using the QAM with the SSP - just in case it can cause damage.


as for ‘rides in the storm’, hopefully they know what the issue is… and can sort you out.

but, I’ll be frank here, be prepared for them to say ‘it works fine for everything else. we’ve had no other issues reported ’ - unfortunately, thats a not uncommon response in eurorack.
don’t’ get me wrong, this is not their fault…
eurorack is a bit ‘cowboy’ at times, and the standards are not exactly ‘strict’ , so incompatibles are not that uncommon.
(if this is the case, hopefully they can just issue a refund, and you can find something that works for you!)

Mark,

I didn’t see any irregularities with the SSP’s PCB back or sides, but it does generate a bit of heat in the Pod60 enclosure. I exiled the QAM from the Pod60 box containing the SSP; it will find a new life elsewhere. Thanks for your support and advice. I will keep my nose peeled for any precursors to flame, but I don’t expect any.

BR,
John

1 Like

Im guessing yours is actually a pod64x , as the ssp is 60hp, and you have some space for another module…

Ive got the pod64x , and I put 2hp gap at each end, and this helps airflow, and keeps the SSP pretty cool, as I didn’t like it when my SSP was in my main case, and used to get very warm!

that said, Bert had the SSPs in a Pod60s at Superbooth last year,
running all day, and they were absolutely fine.

(have to say they did look very cool in the sleek pod60… but Im happy to have the extra ventilation on mine!)

yeah, im sure your SSP is fine…as I said, Id personally test each jack, but only for my own piece of mind…frankly, if they had been damaged, you’d have noticed by now.

You’re not gonna believe this, I just had another buff mult (2hp, this time) short out when connecting to the SSP – and they are in two separate enclosures with separate power supplies! As soon as I plug an SSP IN or OUT into the 2hp buff mult, the entire enclosure containing the 2hp mult shuts down. Even if I put another buff mult (Doepfer A180-3, which seems to be unaffected by all this) in between the SSP and the 2hp buff multi, connecting a cable between the Doepfer and the 2hp shorts out the 2hp rack and reboots the SSP. WTF!!! I’m tearing the system apart and starting from scratch. I cannot believe this.

Just another follow up. It looks like the SSP is broken. Most of the input channels no longer work, and now the 2nd encoder stopped working (at least on the Global menu). I sent a contact email to Percussa to inquire about an RMA. Too bad; I had high hopes for this unit.

isn’t the SSP supposed to be protected against reverse polarity?

i am now weary trying this out for myself, since i could fry my SSP

(although any buffered multi should work (and benefit) with any module, including the SSP)

CULPRIT FOUND!

See if you can guess what’s different about this cable.

Only cost me an SSP! :stuck_out_tongue:

2 Likes

oh, really sorry to hear that @jsillari !
this is every eurorack owners nightmare :frowning:

cable - ouch, red stripe is wrong way around…
so guess, you put this in wrong way around at one end…
Im guessing the key’d end meant it was correct on the bus board, and incorrect on the module end, not using keyed connection. ( * )

was this on the mult? rather than the SSP?
I ask, as the SSP is supplied with a ‘special’ cable, which you are required to use ( ** )
also, Im assuming the multi? as the SSP wouldn’t even boot with reverse polarity. (MCU won’t run off -12v !)

arghhh…


( * ) though never trust keyed connectors…
you can actually put them in the wrong way around, with surprisingly little force… I did this once, but luckily spotted whilst ‘double checking’, before power-on… its made me super careful of plugging in modules.

( ** ) the SSP cable is not a ribbon cable, it uses thicker gauge wire, this is used due to the higher current use, and helps reduce ‘noise’.


yes… according to manual.

I used the supplied harness with the SSP because of its high current draw. The bad cable’s origin is not clear; it may have been from one of the mults, but definitely NOT from the SSP. Both ends of this cable are keyed; however, the power bus end is truly deceptive. You’ll note that the red stripe is oriented correctly, but the wire harness is attached to the wrong end of the terminal. The red stripe should be on the bottom-most contact of the terminal (-12V), not on pin 10 (see Dieter’s Eurorack power terminal pinout diagram below). Because it’s keyed correctly, users could easily be fooled because the red stripe points towards the correct end of the terminal block, but on the wrong pin!

doepfer_power_terminal_pinout

I’ve been in touch with Bert regarding a repair, so I’m waiting to hear from him.

LESSON SUMMARY: Inspect everything carefully, and trust no one. :face_with_symbols_over_mouth:

yeah, I could see the issue…

Ive actually had a (supplied) ribbon cable that was done the same. ( * )
when I noticed, I immediately threw it away… but for sure, it would be easy to miss… or be unaware of.
in fact, the key’d socket on the bus board was what ‘gave it away’ for me, as I noticed the red didn’t line up with the -12v marked on the bus board.

but key’d sockets are not that common on modules, and as above, they do give a bit of a ‘false sense of security’…

but hey, given the circumstances, im sure you don’t want to be discussing this theory…as its a painful experience !


( * ) unfortunately this is not rare…
the reason is… small manufactures often will diy ribbon cables.
as its very cheap, and very quick and simple to do.
you just cut ribbon, insert ends, and use a vice like tool too crimp on the two connectors… litterally 2 mins and costs virtually nothing compared to buy cables in, having to stock them etc etc.

but, its easy to either cross wire it , by putting on one connector ‘upside down’, or having red line on wrong pins by having ribbon upside down.
(former is worst, but both are confusing and can lead to mistakes by user)

of course, you notice if you are just making one… but if your making a batch it’d be easy to miss.

1 Like

worth pointing out with eurorack power cables - that if the headers are keyed properly on both ends… the red strip could be on the other side and it wouldn’t matter - as it’s just generic IDC ribbon cable.

But - more often then not - if one side is correct and the otherside is keyed the wrong way. Then voltages are going to the wrong pins and … Pooof!

Unfortunately there are some modules that didn’t follow key spec - and if you accidentally used a different cable when moving a module around things could get blue smokey.

It’s stuff like that this that really shines a light on how crap eurorack power is, generally.

1 Like

UPDATE:

Good news. Bert generously supplied a fistful of diodes to my instrument electronics repair-person which he used to replace all the ones in the input and output section. In addition, a couple of the 5532 dual op-amps had to be replaced; et voilà, a fully functioning SSP has returned to the roost. So be careful out there when connecting patch cables to the SSP from other modules.

Great to read that you’re up-and-running again!