Tascam M-___ Story...

  • Thread starter Thread starter sweetbeats
  • Start date Start date
...

I'm envious of your tenacity, thoroughness & technical ability!
That's an incredible board, too! Awesome! Beautiful!
:spank::eek:;)
 
Thanks, Dave. That means a lot. I appreciate it.

So it's happening...the more I work with the details of the controls on the board a weird thing happens...it becomes...smaller. Like when I look at it it's no longer a sea of controls but my mind breaks it down into blocks automatically...I see the input trim section, subgroups, eq aux pairs, monitor section and solo block. I *saw* that all before but as the sum of them become individually understood where each of their facets sit in the signal path my mind automatically breaks the sections down...like the visual noise of all the controls is cut out based on what I'm looking for or focusing on. Don't know if that makes sense, but it makes the entire device feel smaller. I'm not getting lost.

I/O Module #3 checks out!

There was a weird problem with the meter needle hovering at -10VU when the meter source was set to INPUT regardless of the input source selection (i.e. MIC, LINE 1 or LINE 2). The meter was still displaying signal but would never drop below -10VU and was a little erratic. The problem went away on it's own. Like any good skeptic I expect it to return but for now it's gone and I made note of it.

Overall there is VERY minimal noise from the pots in terms of the skritchies, and the switches are pretty quiet too. I'm pleased about this. There is always some to be expected for something of this vintage especially with disuse, but it's in as good or better shape than anything else I've touched from this era.

So I'm 25% done with the full function test of the I/O modules and so far I'm batting 1000. :D
 
Glad to read the testing thus far is going well with little to no issues!

I suppose should you run into any real ones, you'll more quickly be able to find and fix them due to your growing experience through all the work you've done on it. Hopefully, you didn't put any caps in backwards! :D

Cheers! :)
 
The Ghost of FM said:
Glad to read the testing thus far is going well with little to no issues!

I suppose should you run into any real ones, you'll more quickly be able to find and fix them due to your growing experience through all the work you've done on it. Hopefully, you didn't put any caps in backwards! :D

Cheers! :)
Click to expand...

Yeah, I used to be VERY intimidated by the complexity and the lack of documentation, but its helped the work I did on the Soundtracs MX32 console and the work I've done so far on the MCI JH-416 desk...learned a lot...and then yes with the recent blitzkrieg of recapping on the M-__ console, as I was recapping module after module I was studying too...what each of the components are there for...Lots more questions than answers simply because my knowledge-base isn't deep enough but at least I'm much more comfortable being able to hone in on an area if/when trouble arises.

Man I'm always waiting for a *POP* after I've recapped something...and I check not once, not twice, but three times to reduce the risk that I've put something in backwards.

I assume you are referring back to that cap that blew in one of the power supplies on the Ampex MM-1000? Boy oh BOY that was loud! And the sound room STILL has a hint of that fishy blown cap smell years later. *BANG!!* like a Glock 45.
 
Wow! What a story. What an amazing process you've been through. Makes me want to restore something... :)

Thanks!
 
Saddle said:
Wow! What a story. What an amazing process you've been through. Makes me want to restore something... :)

Thanks!
Click to expand...

Thanks for the comment. I appreciate it.

Word to the wise...if you DO go out and restore something, let it be something that's not the only one...and isn't too far gone. :D

Well folks here's just a quick update: I tested I/O module #4 and it also is 100%. That weird issue with the meter hovering with module #3 did indeed return, and there's a "fffffft" that happens with fader actuation above "0" on the fader scale. To make matters worse at one point it was happening with almost ALL the modules. Then just #3, #4 and #11. I moved the offending modules to different slots and the problem followed the modules. I tried swapping just the fader with a non-offending module and the problem stayed with the offending module. I checked for proper grounding, but that checked out good. The wiring to the card edge finger on one of the modules where the signal output to the meter bridge goes looked janky so I addressed that but no change. There were some weird noises happening (a high frequency modulating noise) so I thought maybe the problem was actually tied to the master module so I pulled that and the hovering meter problem was still there. When I put the master module back in there was a host of "sputnik" sounds in the headphone circuit and popping noises (which has been an intermittent issue for awhile). Pressing on the control surface (which applies pressure to the connection to the motherboard) affected the noises so I figured it was time to clean the card edge connector on the motherboard and tweak the contacts for better connection and that took care of all those weird noises but not the hovering meter problem. #4 seems to have resolved at least so far. Now when I turn it on this morning #3 is behaving properly. I think just for good measure I'm going to pull all the I/O modules and clean and tweak the contacts on the motherboard. I don't expect this will resolve the issue, but I think its good preventative work anyway. I don't want to be chasing multiple issues and I think its best to take those out of the equation. The "fffft" range on the fader on the I/O module really makes the meters jump on the stereo buss. There's no hum or anything, it *seems* to just be a meter issue but I don't really know that for sure. There could be something there beyond my hearing range and I may hook up my meter and set it to frequency count and see if there's something there. Anyway, just trying to at least get the problem to behave *consistently*, and then my next steps are to look closely at the offending module(s) again and see if something doesn't look right...a fine-tooth-comb look...and then disconnect the jacks and see if that helps, and if not then its time to start swapping individual module boards with a non-offending module and see if I can get the problem to move. Then at least I'll have it narrowed down.

Its frustrating. It was pretty discouraging at first but I'm over that. Problems that don't behave consistently are frustrating.
 
When you recapped the cards, are any of the new caps perhaps touching onto metal on other cards via the top of the new cap, perhaps creating a unwanted loop point which shows only with elevated levels, thus explaining the "ffffffft" sound?

Cheers! :)
 
Good idea. That's exactly the kind of thing I'm going to be looking for when I do my "fine-tooth-comb" inspection. And it might also explain the intermittent presentation of the issue as things might change just slightly enough with insertion of the module and/or environmental conditions.
 
Inspected, tweakered and cleaned all the card edge connector contacts on the motherboard; a significant task as there are 602 of them. I then tipped the frame up and closely inspected each solder joint under good bi-directional lighting and a 10x magnification jewelers loupe...re-flowed anything even hinting at looking suspicious. That's over 700 solder joints.

Now time to re-load the frame and find that module #s 3 and 11 still have the hovering meter and high range fffffft-ey fader problem. :D

I'm being a realist. This recent effort was really just an attempt at taking the module/motherboard interface out of the equation, but I'm not expecting it to fix the problem. I just know with stray noise issues related to the master module being abated with contact tweakering and cleaning, I'd be dumb not to pause and execute that process globally.
 
It's in there...the problem is *somewhere* in there...

image.webp


As I suspected, my work cleaning contacts and checking/re-flowing solder joints didn't make a difference, though module #3 is consistently no longer misbehaving. It's just module #11.

I swapped out everything else card-wise one at a time with a non-misbehaving module and the problem never went away, so it comes down to the core card of the module...the one with the harness hard-wired to it, and the card-edge contacts...and all the logic. It also has the aux and monitor buss amps. Anyway, I was hoping it wouldn't be this card because it is the most complex. So...don't know what to do now.

So I'm going to start looking over it closely.

Bah.

Humbug.
 
Well...nothing looks out of place. I've tested everything I know how to test. Basically looking for a miracle answer to drop from the sky at this point. It's weird that almost all of the channels were doing at at one point, then just three, then just two, and now just the one. I'm really pretty certain it is a problem in the module.

My fear is that it is a bad transistor or opamp...and that starts to get over my head in terms diagnosing, so then I just start shot gunning in new parts and that's not really a good way to do it.

Gonna give it a rest tonight.

I *did* find another mouse turd though. Been a good long while since I found on of 'em in the M-__. Thought I'd found them all.

Yay.

Sweetbeats 1, mouse excrement 0.
 
So I figured out the issue with module #11, or at least found a work-around...

If the console is powered up with the EQ section bypassed (via the BYPASS switch on the control surface), the channel is extra noisy...that's what is elevating the meter. Just sounds like a really high noise floor coming off that module. As soon as I enable the EQ section there's a nice *pop* in the headphones and the noise floor is like the other modules even when bypassing the EQ section again.

So this is definitely an issue to be aware of because it is NOT just isolated to the meter...it is an issue in the audio path.

I'm not really sure what would be causing this to happen, and its easy enough to just actuate the BYPASS function in the EQ section when the board is powered up and be good to go, but because it was happening with other modules I assume it may become more of an issue over time. SO...before I put module #11 all back together and move on I'm just doing some tracing out of what is upstream and downstream of the BYPASS switch in the EQ section and sure enough it goes to/comes from the primary card in the module. Maybe a lazy transistor? Or maybe one of those hex-inverter switching ICs is getting long in the tooth? Its just like a good jigsaw puzzle. Once I can physically figure out the path the signal takes through that BYPASS switch it may lead to a specific component I can shotgun OR it may highlight a bad solder joint or some such thing that I haven't realized yet because I didn't have the focus of the specific signal path.

Another helpful observation is that the channel MUTE function (the master kill switch for the module) *does* kill the noise, so I at least have another reference point from which to trace if need be.

I will be tapping into the M-500 schematics just for signal flow reference sort of as a litmus test for what I'm gathering understanding-wise from the physical observations of the M-__ signal path.

At least the hunt has narrowed and there is a work-around.
 
Long day today. It's just me at the apartment...no pets or anything. Left the M-__ turned on all day today for testing purposes to ascertain the nature of the "hovering meter" issue on module #11. Anyway, it's nothing the same as being greeted by a live being, but there is a certain warmth in the glow of 14 VU meters...my welcoming committee this eve:

image.webp
 
Still working on the hovering meter issue on module 11. I've done a number of things both on my own initiative as well as under advisement by my tech friend. No luck yet. It's not getting me down and I'm not sure it's going to be resolved. Just glad I've got a work-around. It would be nice to get it fixed though and I'm far from giving up.

The troubleshooting has really helped my to become more familiar with a number of things within the module circuitry so that's good.

I'm at the point where I'm having to draw up schematical excerpts of pertinent sections of the module (i.e. the EQ bypass circuit and the amp stages just upstream and downstream of the bypass switch).

image.webp

image.webp


I did go ahead and do the function testing on module 11, and there were a couple issues but I think I fixed them.

Another unrelated thing that I'm thinking about doing is to resolve an issue that's bugged me all along...the LED color selections. Some mutes are red, some are green. Green means go. Red means stop. All mutes should be red. Solo functions typically seem to be red from this era of Tascam mixer, but staying with the green means go red means stop ideology the solo indicators shouldn't be red. Anyway, I need more red LEDs than I have on the modules...but I DO have some red LEDs in a certain M-512...
 
Yellow or blue might be a more intuitive color choice for a solo path LED.

Cheers! :)
 
Yeah I was thinking of buying some additional LEDs in different colors...but I'd end up spending $30-40 just to do that. Think I'm sticking with red and green.
 
Too bad there isn't a color filter boot that could be placed over the LED to alter the color! :)

Oh well

Cheers! :)
 
Well this might all seem like a silly waste of time, this LED swapping, but quite honestly I am really liking the new scheme. It makes a lot more sense to me. Channels 1~4 on the left are the original scheme, while channels 5~8 to the right are the updated scheme:

image.webp


I expect it ain't gonna make a whole lotta sense to y'all looking at the pic...it's just a lotta red and green everywhere...but in the new scheme all the mute functions are red, and if you include the BYPASS function in the EQ section (which is a pseudo "mute" function), that makes 7 altogether. I find myself scanning to check and see what is muted and frankly the red is a whole lot more visible, and now it's consistent: red is mute. Before all the mute functions were green...green means "go". Mute means "stop". And formerly the red indicated functions were a mix of "on" type functions (phantom power, EQ to monitor enable, remote enable, solo on...). Somehow the new scheme just makes more sense to my eyes and brain.

Something to putter at while I await further diagnostic testing instructions for the problem with module #11.
 
Ah hahhhhhhhh...

Something is indeed oscillating...

image.webp


I'm probing the input of the channel fader. Now to start tracing upstream until I find where the oscillating stops...a little bit of a challenge since the signal path is fairly complex, but I'll just take it one step at a time. Once I find where it stops, then the next step will be to figure out what is failing at the component from where the oscillation is being generated.
 
You must log in or register to reply here.
Back
Top