I never resolved the loading tray problem and my CD73 is sat in the cupboard waiting for some inspiration.
I've been using my other Akai, a CD55 but that's playing up now and looks like the laser is on it's way out. That's likely to be easier to fix than the CD73.
If I remember the CD93 used an optical sensor on part of the tray sensing circuit so maybe this is the way to go with a modification.
I've been using my other Akai, a CD55 but that's playing up now and looks like the laser is on it's way out. That's likely to be easier to fix than the CD73.
If I remember the CD93 used an optical sensor on part of the tray sensing circuit so maybe this is the way to go with a modification.
I've got my CD73 out of storage but as I watch the loading tray go through it's endless cycle of shaking back and forth and never working... I wish I hadn't bothered.
I previously spent countless hours going round in circles trying to fix this impossible fault and made absolutely no progress at all with it.
All that's left to do now is clout it with the largest hammer I can find and take it to the refuse centre.
I previously spent countless hours going round in circles trying to fix this impossible fault and made absolutely no progress at all with it.
All that's left to do now is clout it with the largest hammer I can find and take it to the refuse centre.
For anyone still reading this thread...
I have tried very hard to eliminate the loading tray fault but have made no progress at all.
In summary I have:
Replaced both tray loading belts
Cleaned and lubricated the loading mechanism
Cleaned and tested the four tray position leaf switches
Reflowed all solder joints on the digital PCB
Replaced all electrolytic capacitors on the digital board
Removed main microprocessor IC7 from its DIL socket and soldered it directly to the board
Replaced +5V voltage regulator IC12
Replaced bi-directional motor driver IC8
Added a schmitt trigger de-bounce circuit between the position switches and microprocessor inputs
Disconnected the internal power supplies and run power from external bench PSUs
Added filter capacitors to both clamp and loading motor terminals
Twisted and screened both clamp and loading motor leads
The only conclusion I've reached is the main microprocessor IC7 must be faulty. Since this is a custom Akai part and no longer available to buy, unfortunately this fault cannot be fixed.
I have tried very hard to eliminate the loading tray fault but have made no progress at all.
In summary I have:
Replaced both tray loading belts
Cleaned and lubricated the loading mechanism
Cleaned and tested the four tray position leaf switches
Reflowed all solder joints on the digital PCB
Replaced all electrolytic capacitors on the digital board
Removed main microprocessor IC7 from its DIL socket and soldered it directly to the board
Replaced +5V voltage regulator IC12
Replaced bi-directional motor driver IC8
Added a schmitt trigger de-bounce circuit between the position switches and microprocessor inputs
Disconnected the internal power supplies and run power from external bench PSUs
Added filter capacitors to both clamp and loading motor terminals
Twisted and screened both clamp and loading motor leads
The only conclusion I've reached is the main microprocessor IC7 must be faulty. Since this is a custom Akai part and no longer available to buy, unfortunately this fault cannot be fixed.
Last edited:
I understand your reasoning on the micro but having spent a lot of time on this fault with no improvement, its hard to reach any other conclusion. The fault isn't intermittent as the tray will never load cleanly and will only do so by cycling the power repeatedly until it moves to the next phase.
I've trawled the web for info on this fault and although it is quite common on this model I've yet to find anyone who has cured it. I translated some info on some Polish and German sites and they also point at the custom micro as the problem.
I've admitted defeat on it as I've run out of ideas what to try next. A recent search on eBay showed 2 faulty CD73s have recently sold for over £200, so maybe its time to offload it and let someone else have the headache instead?
I've trawled the web for info on this fault and although it is quite common on this model I've yet to find anyone who has cured it. I translated some info on some Polish and German sites and they also point at the custom micro as the problem.
I've admitted defeat on it as I've run out of ideas what to try next. A recent search on eBay showed 2 faulty CD73s have recently sold for over £200, so maybe its time to offload it and let someone else have the headache instead?
When you reach the point of having tried and looked at everything else then it is time to replace it, often on the basis to rule it out. I've been in that situation many times as a bench tech and and its a tough call to make, but once are happy everything else is OK then you have to try it.
Sometimes a product does have a known issue with a part that causes problems but its very rare on a uP and even more rare for it to be an intermittent issue... but it's not impossible.
Sometimes a product does have a known issue with a part that causes problems but its very rare on a uP and even more rare for it to be an intermittent issue... but it's not impossible.
I've ruled out the switches, PSU ripple, motor noise, faulty caps, dry solder joints and the motor driver chip. There isn't anything else on the list other than the micro, which I would happily replace if available. I would take it back to the place that repaired it for me before but they appear to have shut down.
Their repair tech told me to remove the micro's DIL socket if the problem came back as he claimed it was corrosion on that which caused the original failure. His final comment was, if that doesn't work, you'll need a new micro and its obsolete.
Their repair tech told me to remove the micro's DIL socket if the problem came back as he claimed it was corrosion on that which caused the original failure. His final comment was, if that doesn't work, you'll need a new micro and its obsolete.
Here's the video of the fault I uploaded to You Tube some time ago in the hope I might find a solution from there:
Akai CD73 defect - YouTube
Akai CD73 defect - YouTube
Its definitely not happy...
What happens if you manually simulate doing whatever the tray switch does, in other words operate the switch yourself before the tray gets to it.
Have you tried adding a series resistor to the tray motor to slow it down a bit and see if it makes any difference?
The limit switch is obviously triggering OK, the question is whether the issue is mechanical or not.
Also try getting the motor to run but without the belt fitted so it is unloaded and the tray doesn't operate. After a second or two you operate the limit switch manually and see if the motor drive does anything odd or not. The motor should just stop cleanly. That would eliminate any mechanical bounce. If the motor threw a wobbler doing that then I agree the uP should be swapped.
What happens if you manually simulate doing whatever the tray switch does, in other words operate the switch yourself before the tray gets to it.
Have you tried adding a series resistor to the tray motor to slow it down a bit and see if it makes any difference?
The limit switch is obviously triggering OK, the question is whether the issue is mechanical or not.
Also try getting the motor to run but without the belt fitted so it is unloaded and the tray doesn't operate. After a second or two you operate the limit switch manually and see if the motor drive does anything odd or not. The motor should just stop cleanly. That would eliminate any mechanical bounce. If the motor threw a wobbler doing that then I agree the uP should be swapped.
Manually operating the tray switch before the tray gets to it causes mayhem with the clamp mech as it starts that phase before the tray is fully closed, making it jump the gears. Taking one of the loading belts off allows me to open and close the tray manually and observe the motor rotation unloaded.
Pushing the tray in from fully open starts the loading motor in the correct direction of rotation for closing it. When the tray is pushed against the closed switch, the motor goes straight into reverse for about 5 seconds, which seems wrong to me. I would have expected the loading motor to stop dead at this point.
Without the belts on the loading motor the tray can be held closed and after the 5 seconds of the loading motor reversing, it stops and the clamp motor starts to operate. Once the tray is fully down, that too goes into the oscillating state, before unloading again.
Both the loading and clamp motors are briefly going into reverse at the point they should be stopping. I think this shows the micro is sending erroneous logic levels to the motor control chip.
Pushing the tray in from fully open starts the loading motor in the correct direction of rotation for closing it. When the tray is pushed against the closed switch, the motor goes straight into reverse for about 5 seconds, which seems wrong to me. I would have expected the loading motor to stop dead at this point.
Without the belts on the loading motor the tray can be held closed and after the 5 seconds of the loading motor reversing, it stops and the clamp motor starts to operate. Once the tray is fully down, that too goes into the oscillating state, before unloading again.
Both the loading and clamp motors are briefly going into reverse at the point they should be stopping. I think this shows the micro is sending erroneous logic levels to the motor control chip.
This thread is something else!
Normally a disc tray either works or it doesn't.
Am I correct in thinking this "tray operation fault" has been reported several times by several different people for this particular model? (Akai CD 93)
That would lead me towards some type of "design error" or oversight.
DC motors are capable of generating a wide range of transients and power supply glitches.
Has a capacitor of perhaps .1uF up to 10uF been applied in parallel with the DC motor? (Note: capacitor must be non-polarized).
I recall plenty of analog tape decks, both reel-reel and cassette, where the DC motors were always bypassed with parallel capacitors and sometimes there were also small inductors in series with the feed wires to the motors. Analog tape decks present plenty of unwanted electrical noise issues due to the mV level of the audio signal coming from the tape head. Therefore the circuit designers often did a very thorough job of suppressing the electrical noise from motors and other electromechanical components.
-EB
Normally a disc tray either works or it doesn't.
Every logical diagnostic and testing action appears to have been applied to this case without success.
Parts that commonly fail have been tested, cleaned, or replaced.
Yet the root cause of the fault hasn't been found yet.
Parts that commonly fail have been tested, cleaned, or replaced.
Yet the root cause of the fault hasn't been found yet.
Am I correct in thinking this "tray operation fault" has been reported several times by several different people for this particular model? (Akai CD 93)
That would lead me towards some type of "design error" or oversight.
DC motors are capable of generating a wide range of transients and power supply glitches.
Has a capacitor of perhaps .1uF up to 10uF been applied in parallel with the DC motor? (Note: capacitor must be non-polarized).
I recall plenty of analog tape decks, both reel-reel and cassette, where the DC motors were always bypassed with parallel capacitors and sometimes there were also small inductors in series with the feed wires to the motors. Analog tape decks present plenty of unwanted electrical noise issues due to the mV level of the audio signal coming from the tape head. Therefore the circuit designers often did a very thorough job of suppressing the electrical noise from motors and other electromechanical components.
-EB
I have seen reports of several other CD73s and 93s exhibiting this fault as well as units for sale on eBay with the same problem.
I fitted capacitors across both loading and clamp motor terminals and from each terminal to the metal body.
The tray position switches are directly fed to the micro, switching to 0V in the closed position and pulled to +5V by resistors. I tried adding schmitt triggers to each input to clean up the signals from the switches without success.
The brief reversal of the motor after closing seems to be the problem. This causes the closed switch to open just after closing and the micro throws it the other way again to close again. This cycle repeats, causing the oscillation.
The same thing happens with the clamp motor if it can be persuaded to move on in the loading process.
I fitted capacitors across both loading and clamp motor terminals and from each terminal to the metal body.
The tray position switches are directly fed to the micro, switching to 0V in the closed position and pulled to +5V by resistors. I tried adding schmitt triggers to each input to clean up the signals from the switches without success.
The brief reversal of the motor after closing seems to be the problem. This causes the closed switch to open just after closing and the micro throws it the other way again to close again. This cycle repeats, causing the oscillation.
The same thing happens with the clamp motor if it can be persuaded to move on in the loading process.
That sounds plausible and if so isn't really a faulty uP. I wonder if it something like the tray becoming more free over the years, maybe there was a thick grease used as mechanical damping that has essentially worn away.
It's definitely worth trying a few things like a resistor to the motor, maybe with a bipolar cap across the motor to slug it a little. You have to be creative. Try a series low voltage Zener. That would give full volts in one direction and limit the voltage in the other.
There are no signs of grease of any kind on the tray mech and it is already quite heavy to push back and forth.
I tried a 10R resistor in series with the loading motor but it slowed down too much and struggled to close the tray. A little push helped but it still went into oscillation when it closed.
Looking at the 3 logic lines from the micro to the motor driver on the scope, input 3 is flapping up and down wildly when it goes into oscillation. The other 2 inputs are stable.
The zener is a good idea but won't that prevent the tray opening when the motor actually needs to run in reverse to open the tray? I think the micro is supposed to send logic levels to brake the motor but is reversing it instead.
I'm now starting to think the only way to fix this is to cut a hole in the top cover and do away with the loading tray altogether. Just make it a top loader with a weight on the disc!
EDIT: In reality, I think the only way to fix this problem is take control of the motor driver away from the Akai micro and add some switches and logic circuits to control the motors separately. The original switches will simply report the tray/clamp state to the original micro so it can advance the program to play mode. I used to work with a software engineer that used PIC microcontrollers a lot and I'm sure he could have come up with a mod to fix this problem... long since lost touch and that is unfortunately beyond my skill set.
I tried a 10R resistor in series with the loading motor but it slowed down too much and struggled to close the tray. A little push helped but it still went into oscillation when it closed.
Looking at the 3 logic lines from the micro to the motor driver on the scope, input 3 is flapping up and down wildly when it goes into oscillation. The other 2 inputs are stable.
The zener is a good idea but won't that prevent the tray opening when the motor actually needs to run in reverse to open the tray? I think the micro is supposed to send logic levels to brake the motor but is reversing it instead.
I'm now starting to think the only way to fix this is to cut a hole in the top cover and do away with the loading tray altogether. Just make it a top loader with a weight on the disc!
EDIT: In reality, I think the only way to fix this problem is take control of the motor driver away from the Akai micro and add some switches and logic circuits to control the motors separately. The original switches will simply report the tray/clamp state to the original micro so it can advance the program to play mode. I used to work with a software engineer that used PIC microcontrollers a lot and I'm sure he could have come up with a mod to fix this problem... long since lost touch and that is unfortunately beyond my skill set.
Last edited:
Is it possible to adjust the position of the leaf switches so that they remain closed for a slightly longer duration?
It seems that a time delay is needed so that the MCU doesn't get a signal telling it that the end-of-travel switch reopened during the brief "back-up" where the drive motor reverses.
I think it was poor design to reverse the motor immediately after the end-of-travel switch closes. Why not just let the motor stop then?
Another thought would be to find a way to reduce the driving voltage applied to the motor so that it rotates more slowly. Perhaps apply a variable external power supply voltage to the motor driver circuit. Then the voltage can be adjusted up and down, causing the motor to run slower or faster. That might help identify whether getting the motor to run more slowly would fix these problems.
Another thought related to how fast the motor rotates:
Many older circuit designs applied "unregulated" power supply voltages to motors. The magnitude of these unregulated supply voltages is proportional to the AC mains voltage. In the USA, the typical AC mains voltage has crept up over the years, from 110V, to 115V, to 117V, to 120V, and (today) is can be as high as 123 to 125V. This issue comes up often for people who restore antique radios and other vintage tube (valve) electronics. Today's mains voltage is excessive for some of the older items.
To summarize, I think that "reversal" of the drive voltage to the motor is causing the problem here. I doubt it is possible to reduce the duration of the "reverse" drive signal which occurs when the end-of-travel switch closes. That is probably fixed by the firmware inside the MCU.
This leads back to the idea that "slowing down" the rotation of the motor might fix the problem. If the motor is rotating more slowly then the "reverse" signal won't move the tray far enough to open the end-of-travel switch.
-EB
The only way to adjust the leaf switches is to bend their contacts back and forth as there isn't any adjustment in the mounting point. Doing this just alters the point at which the tray starts banging back and forth.
I don't think the motors are supposed be thrown into reverse when the tray closes and when the clamp down operates - they should brake and stop. I think this is the fault with the micro and the cause of the oscillation.
The motor driver chip has a Vr pin which is used to set the motor drive voltage from the unregulated 12V supply. The data sheet shows it set with two resistors but Akai control this with another output from the micro to a transistor and zener. I previously tried setting this with resistors instead but it didn't make any difference to the problem.
I don't think the motors are supposed be thrown into reverse when the tray closes and when the clamp down operates - they should brake and stop. I think this is the fault with the micro and the cause of the oscillation.
The motor driver chip has a Vr pin which is used to set the motor drive voltage from the unregulated 12V supply. The data sheet shows it set with two resistors but Akai control this with another output from the micro to a transistor and zener. I previously tried setting this with resistors instead but it didn't make any difference to the problem.
I think I've tried everything I know to fix this including all the suggestions I've received via this discussion. The only thing left to replace, bearing in mind this unit is around 30 years old, is the loading and clamp motors themselves. I found they are still available to buy, so have ordered 2 as a final attempt to cure the problem.
After that, I think I will call it a day and put it on eBay for spares or repairs so someone else can try or just make use of parts such as the laser, which still works.
After that, I think I will call it a day and put it on eBay for spares or repairs so someone else can try or just make use of parts such as the laser, which still works.
Because the end-of-travel switches aren’t adjustable I think we should try to reduce the speed of the motor.
Here’s another thought I just had:
Put a resistor in series with the motor.
This will reduce the acceleration/deacceleration rate at the moment when the motor is turned on, turned off, or reversed.
I’d expect the series resistor value to be in the range of 10 ohms to 100 ohms. The goal is to slow the motor a bit and especially to decrease the tendency for the tray to reverse direction at the end of travel.
With the proper series resistor the tray should stop at the end without reversing.
-EB