MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

Q: Does the Moon Modular 564 switch CV glitch free?
MUFF WIGGLER Forum Index -> 5U Format Modules Goto page 1, 2  Next [all]
Author Q: Does the Moon Modular 564 switch CV glitch free?
JohnLRice
It was mentioned by wiggler ranix in another thread that he gets CV glitches when switching with the Moon 564 but not with the DotCom Q962. I didn't want to derail the other thread with lots of "No It Doesn't!" and "Yes it Does!" back and forth hihi so I thought we could explore it in this thread? cool

This is the first I've heard of the 564 glitching with CV switching and have never encountered the issue myself and wiggler Squattamolie also mentioned the same. My first thought was that the 564 rainx has is just a defective unit or maybe there is some other issue isolated to his particular use and/or system? hmmm..... seriously, i just don't get it
ba1
Mine operates glitch free. How is he using it? I was doing something wrong at first and getting some frustrating results, but I can't remember what it was.
ranix
I spent some time characterizing the misbehavior tonight.

Here's the patch: q960 used as two voltage sources. Row 1 set to 1V, row 2 set to 6V. SHIFT signal generated by a square wave. 1V patched to CH1 on both switches, 6V patched to CH2, SHIFT patched to SHIFT, all through a mult. Shift time set at approx. 1 second 90% pulse width.

The Moon 564 is RED on the scope, the Q962 is YELLOW. See attached image for patch.




PROBLEM 1: the ON switch time for the Moon 564 is inconsistent when compared to the Q962. It is also consistently significantly slower to switch than the Q962. See attached images for timing jitter.




PROBLEM 2: the SHIFT input of the Moon 564 feeds switching noise back into the Q962. This noise disappears when the Moon 564 is disconnected. See attached image for example of noise fed back through Moon 564 SHIFT input



PROBLEM 3: the descent from 6V to 1V is slewed. See attached image for example of descending output voltage slew when switching



Conclusion: The Q962 is far superior to the Moon 564
JohnLRice
Thanks much for the detailed info, rainx! thumbs up I no longer have a Q962 and my 564 has been modified a bit, but at some point I'll see if I can duplicate your findings with what I have.
ranix
No problem dude. Some of those problems are real killers for a lot of applications, although I still make use of this module once in awhile for other things (logic switching, counting, dividing). My original intent was to use it for automatically switching in modulation sources at long time intervals, like 8/16/32 bars. It's still good for that, especially on pads or anything with an attack, but you have to watch out for how it chows down on the SWITCH signal, in my experience it will mess up anything that's connected to it unless you connect it via a buffer or buffered mult.
kindredlost
I have noticed similar timing and feedback problems when using a common trigger or gate to shift various sequencers and switches as well.

I have learned to isolate the common trigger/gate with a buffered multiple. Even then it is sometimes a challenge and I have to boost or attenuate the trigger/gate before sending to each shift input.

It's been so perplexing under certain patches that I've even tried to use a gate delay to affect a fix on some timings. Usually by then I give up and go a different route. It isn't much help when the patch is specific to a particular task you need to perform. I can understand the frustration firsthand. Usually there is more than one way to make that cat noise. lol

I've come to the conclusion this is all a part of the magic of having several vendors in a system. I try not to complain so much about the burden of having a large, mixed vendor 5U setup. razz

EDIT: Oh, BTW ranix... I have that same scope. It's a pretty decent and inexpensive tool. Very light weight and handy for quick troubleshooting. thumbs up
LesMoMo
JohnLRice wrote:
Thanks much for the detailed info, rainx! thumbs up I no longer have a Q962 and my 564 has been modified a bit, but at some point I'll see if I can duplicate your findings with what I have.

Guys, I can't argue that much on the "reaction speed" of the 564v2. Or the ability of the trigger outputs to drive "loads".
But I think that it is being worth to highlight that the 564 is a bi-directional switch. Hence the jacks are labelled accordingly. The (RA) Moog 962 is uni-directional and therefore can/does buffer the switched signal. I don't know how the Q962 is being constructed, though.
kindredlost
LesMoMo wrote:
... the 564 is a bi-directional switch... I don't know how the Q962 is being constructed, though.


The Q962 is bi-directional too.
bwhittington
I haven't noticed any anomalies in the 564's I've used, which are two presently and one that I sold. I probably haven't ever shifted two switches simultaneously as in the patch you set up to notice your main complaint, though.

But you also seem to be describing what I suspect would amount to an audible pitch fluctuations and switch noise just using them independently? I've never noticed anything like that. What is the time scale on the scope shots? Wondering what those images represent exactly. Perhaps I haven't heard what you experiencing because it is lost in the attack phase of an EG on a typical patch?
Ranxerox
Yeah, I haven't noticed this particular anomaly with my M564 either. My other modules (Q960, envelopes) do get momentarily weirded out when I connect it in a patch however? Some digital voodoo going on with that one.
ranix
bwhittington wrote:
I haven't noticed any anomalies in the 564's I've used, which are two presently and one that I sold. I probably haven't ever shifted two switches simultaneously as in the patch you set up to notice your main complaint, though.

But you also seem to be describing what I suspect would amount to an audible pitch fluctuations and switch noise just using them independently? I've never noticed anything like that. What is the time scale on the scope shots? Wondering what those images represent exactly. Perhaps I haven't heard what you experiencing because it is lost in the attack phase of an EG on a typical patch?


well the first two scope shots are 500µs time scale and the second two are 100µs

for how many hundreds of µs is our pitch CV allowed to look like this? lol Dead Banana



This doesn't render the module useless but unless you're using it in very specific ways it does indeed create noise on pretty much every output when switched.

I'd be interested to scope out some other switches to see if switching noise is normal for modules like this, maybe the Dotcom version is just special in its noise-free audio switching ability

It's also possible my Moon switch is defective of course, I only have the one
JohnLRice
OK, FWIW here's some of my haphazard and unscientific testing. Yellow is the output of the 564 switching between about 0.8v and 4.5v and teal is the clock source. My 564 had been modified to have on-board passive attenuators that feed varying amounts of the +5v rail to the the In/Out jack's switch terminals. The power supply is a Power-One switching supply. The lamps for the stage indicators were replaced with LEDs. Most of the testing was done with the pulse output of a Corsynth C102 LFO.

Running at typical speeds I'd normally use (low and medium ranges of the C102) the voltage switching of my 564 looked to be on time and sharp.


I managed to see some switching delay and ramping/slewing by running the clock at about 500Hz which isn't something I'd normally do (that's almost an octave above middle C! eek! ) You can also see the edges of the clock pulse are looking a little 'soft' too. (maybe because I was at the upper frequency limit of the LFO?)


I switched to my test bench function generator for the clock in thins image.
ranix
JohnLRice wrote:
The lamps for the stage indicators were replaced with LEDs.


Very interesting! I will remove the lamps from my switch and test again!

You do clearly seem not to have the slew issue I seem to, but it looks like it does lag behind the switch pulse for you as well.
JohnLRice
ranix wrote:
JohnLRice wrote:
The lamps for the stage indicators were replaced with LEDs.


Very interesting! I will remove the lamps from my switch and test again!

You do clearly seem not to have the slew issue I seem to, but it looks like it does lag behind the switch pulse for you as well.
I was wondering if might be the lamps might be part of the problem hmmm..... since they take a bit of juice and are relatively slow to get to full brightness?

Also, that is the power situations with your cases? Do you have one big power supply in the bottom case that the upper smaller cases are powered from or does each cabinet have it's own power, etc?
ranix
I've got the big Dotcom QPS3 in this case but the problem does follow it to my much smaller Moon case that only has a Postman, a noise source, and a fixed filter bank in it and is powered by its own wall wart supply.
JohnLRice
ranix wrote:
I've got the big Dotcom QPS3 in this case but the problem does follow it to my much smaller Moon case that only has a Postman, a noise source, and a fixed filter bank in it and is powered by its own wall wart supply.
Ahh, OK. If you would have said that you have separate power supplies in each case my next question would have been "do you have the zero volt rails of all the power supplies tied together?" since not doing so can be the source of issues. Since you are running most everything off of one power supply never mind! cool
EATyourGUITAR
Probably driving the lamps and the switch IC directly from the output of the clock divider IC. That initial rush of current probably sags the logic rise time. That would explain everything. The solution is to delete the lamps or buffer them with a high input impedance lamp driver. The less optimal solution would be a sensitive Schmidt trigger to get the rising edge of the control logic as early as possible before the lamps + switch IC have full voltage on the control line. So basically you buffer the lamps that are too much of a load or you buffer the switch IC that has too much threshold to trigger logic high at the input on time. If there is a programmable microcontroller for no good reason (this a common theme with moon) then you will have additional unnecessary delay. I don't know what's inside but if it is birectional then I can tell you it is using a DG4** switch IC that can NOT be buffered because it is pretty much impossible if it is to remain bidirectional. The only uncertainty is everything else.
ranix
I did some more testing, and it wasn't the lamps! Which is nice, because I like the lamps.

I think the behavior of the switch is dependent on the load. This is what it looks like when I connect the output of the Moon switch to a Q109 oscillator's 1V/oct input:


And this is what it looks like when I disconnect the Q109 (remove the load):


edit: eh did more testing don't know what's going on

that falloff is always there no matter what I do. Mine's gotta be broken. These images are taken at like 1hz
JohnLRice
I tested again, comparing with an oscillator (Moon 501D) connected and disconnected this time and I didn't notice any difference.

I ran my tests with the clock at 1Hz this time, be low are a rise and fall screen shot plus attached is a short audio file. I'm not hearing or seeing any problems with mine, maybe yours needs to be sent in for repair, rainx? hmmm.....



Thalassa
John just one thing, the scope in the last ranix pictures have an horizontal scale of 100us , and you set yours at 50ms. He had a delay of 250us that will be impossible to see at a 50ms scale. You should repeat the last test at 1Hz and put your scope at 100us . In the picture that you use the C102 at 500Hz you said that you get some delay and if you look to you horizontal scale the scope was set at 50us. Maybe the behavior is normal for the module.

I don't have any of the modules discussed here, so I have a question, is it really noticeable a 250us delay switching a sequence row?
JohnLRice
Thalassa wrote:
John just one thing, the scope in the last ranix pictures have an horizontal scale of 100us , and you set yours at 50ms. He had a delay of 250us that will be impossible to see at a 50ms scale. You should repeat the last test at 1Hz and put your scope at 100us . In the picture that you use the C102 at 500Hz you said that you get some delay and if you look to you horizontal scale the scope was set at 50us. Maybe the behavior is normal for the module.

I don't have any of the modules discussed here, so I have a question, is it really noticeable a 250us delay switching a sequence row?
Thanks, I'll redo the test. (I'm very much a green nooblet when it comes to using o'scopes! oops )
ranix
Thalassa wrote:
I don't have any of the modules discussed here, so I have a question, is it really noticeable a 250us delay switching a sequence row?


From what we found so far, the most likely explanation for the noise I was hearing was that the SWITCH input was feeding noise back into a gate signal that I was also using for something else.
Thalassa
JohnLRice wrote:
(I'm very much a green nooblet when it comes to using o'scopes! oops )


It's the good thing about this forum , we all learn new things everyday smile


Ranix check if there are some leds that are turned on in any module when the switch happens. In that case disconnect the module from the patch and check if the noise is gone.
JohnLRice
Thalassa wrote:
JohnLRice wrote:
(I'm very much a green nooblet when it comes to using o'scopes! oops )


It's the good thing about this forum , we all learn new things everyday smile.
Indeed! thumbs up Hug

OK, for your viewing pleasure a plethora of pictures:









Thalassa
Nice!!!! applause applause

So your module has only 16us seconds delay while ranix one has 250us hmmm..... It seems that there is something not normal with his module.
MUFF WIGGLER Forum Index -> 5U Format Modules Goto page 1, 2  Next [all]
Page 1 of 2
Powered by phpBB © phpBB Group