@Mooly
The more this investigation goes on, the less inclined I am to think the main micro is the culprit here, despite other forum users claiming so. As you correctly pointed out this problem was originally cured by the repair shop I went to around ten years ago, which would support the problem being something else.
I also got it working for a while by removing the micro from the DIL socket and soldering direct to the PCB. The fault returned again and is no longer intermittent.
@electricboyo
I'm about to take a look at MCU pins 34 and 35 and will try grounding them as well.
I'll also get the scope on the Vr pin of the motor driver and pin 43 of the MCU with the belts on and the tray oscillating as well as manually operating the tray with a belt removed.
The more this investigation goes on, the less inclined I am to think the main micro is the culprit here, despite other forum users claiming so. As you correctly pointed out this problem was originally cured by the repair shop I went to around ten years ago, which would support the problem being something else.
I also got it working for a while by removing the micro from the DIL socket and soldering direct to the PCB. The fault returned again and is no longer intermittent.
@electricboyo
I'm about to take a look at MCU pins 34 and 35 and will try grounding them as well.
I'll also get the scope on the Vr pin of the motor driver and pin 43 of the MCU with the belts on and the tray oscillating as well as manually operating the tray with a belt removed.
MCU pins 34 and 35 stay at 0V throughout the loading/clamping/oscillation phase of the tray. I linked them both to 0V directly as suggested but his made no difference to the loading oscillation problem.
Looking at pin 43 of the MCU shows 5V while the tray is loading and/or oscillating. It drops to 0V when the clamping motor takes over and stays at 0V thoughout the clamping phase and once that has finished and the disc spins up.
The Vr pin of the motor controller is 5.4V during the loading phase and 12.1V during the clamping phase, which shows TR5 is switching and D19 is doing its job.
Both motors are marked RF-510T which are 12V rated. It looks like the tray loading one is running at reduced voltage while the clamping one is operating at full supply.
Looking at pin 43 of the MCU shows 5V while the tray is loading and/or oscillating. It drops to 0V when the clamping motor takes over and stays at 0V thoughout the clamping phase and once that has finished and the disc spins up.
The Vr pin of the motor controller is 5.4V during the loading phase and 12.1V during the clamping phase, which shows TR5 is switching and D19 is doing its job.
Both motors are marked RF-510T which are 12V rated. It looks like the tray loading one is running at reduced voltage while the clamping one is operating at full supply.
Last edited:
I've also found the tray will oscillate at the end of opening but only if the loading phase is interrupted and reversed. If it opens normally from the fully closed position, it is clean.
Video here:
Akai CD73 defect 2 - YouTube
Video here:
Akai CD73 defect 2 - YouTube
Its definitely not happy.
I might be tempted to go around all the uP pins with the scope when it does that chattering. Everything apart from the switch inputs and the motor drive outputs should be 'steady'. By that I mean supplies and grounds and so on. See if anything is showing as superimposed onto something else, or a ground that is showing a voltage change as the chattering goes on.
You could also try disconnecting the motor and fitting say a 100 ohm in its place as a load. Scope across the motor (or to the motor if the scope would cause a ground short) and push the tray in manually and see if the oscillation on the motor drive still happens.
I might be tempted to go around all the uP pins with the scope when it does that chattering. Everything apart from the switch inputs and the motor drive outputs should be 'steady'. By that I mean supplies and grounds and so on. See if anything is showing as superimposed onto something else, or a ground that is showing a voltage change as the chattering goes on.
You could also try disconnecting the motor and fitting say a 100 ohm in its place as a load. Scope across the motor (or to the motor if the scope would cause a ground short) and push the tray in manually and see if the oscillation on the motor drive still happens.
I've never encountered anything like it before, that's for sure!
I will take a good look round the micro to see if anything looks amiss or is 'in time' with the oscillation.
From memory, I tried a resistive load (as you previously suggested) while looking at suppressing any motor noise. The oscillation doesn't happen with a resistive load but I think I've proven that is only happening because the motor is going into reverse when it should stop. If the tray is moved by hand with the belt removed it doesn't happen either.
I will take a good look round the micro to see if anything looks amiss or is 'in time' with the oscillation.
From memory, I tried a resistive load (as you previously suggested) while looking at suppressing any motor noise. The oscillation doesn't happen with a resistive load but I think I've proven that is only happening because the motor is going into reverse when it should stop. If the tray is moved by hand with the belt removed it doesn't happen either.
For all that it is a weird fault I still can't help wondering if it is mechanical in nature and is something like the tray not being mechanically damped enough (to loose and free to move).
What happens if you 'follow' the tray in with your hand while applying a small pressure to the front to add a bit of resistance when it tries to reverse at the end?
What happens if you 'follow' the tray in with your hand while applying a small pressure to the front to add a bit of resistance when it tries to reverse at the end?
The tray is quite heavy to push in and out even without the belt in place. If you follow it in it requires quite some pressure to hold in against the motor, which makes the belt slip. After the loading motor stops, it goes to the clamping phase. That is a motor driving the geared mech, which is even heavier. As that oscillates as well, I don't think it's mechanical. The problem seems to be caused by the motors reversing rather than stopping.
Because the oscillation can happen at either “tray closed” or “tray open” causes me to wonder if the “rope drive” system for moving the tray is too “springy?”
What happens if the tray drive belt is removed and then the tray is moved entirely by hand?
It would be interesting to see a video.
-EB
Does the clamper always get into oscillation or only sometimes?
You said the clamper motor normally gets 12V.
You could try temporarily grounding the collector of transistor TR5.
This will reduce the drive voltage to the clamper motor, slowing it.
While this may not eliminate the oscillation it might change the frequency of oscillation.
Another test:
Remove belt from tray drive.
If you press open/close button to get the tray motor to run without moving the tray, does it keep running indefinitely in one direction or does it periodically reverse?
While the tray motor is running (without belt) what happens when you push the tray all the way in (closing the “tray closed switch)?
Also observe what happens if you manually pull tray all the way out while the motor is running without a belt?
These tests will tell help understand how the MCU firmware is set up.
-EB
On rare occasions a digital IC chip (such as an MCU) may develop an internal intermittent connection which affects only one pin. The usual state is an intermittent open circuit.
If the intermittent pin is an output then it is helpful to confirm that its output voltage is always close to 0 or close to Vcc (5V in this case). Rising and trailing edges should have sub-usec rise and fall times. But if the output voltage is noisy or floating, or stuck at either 0 or 5V, then this is the bad pin.
If the intermittent pin is an input then it may intermittently fail to respond to the expected input signal. Or the system may respond at random times to a “phantom” input signal.
These intermittent connections between the silicon die and the pins are sometimes responsive to rapid temperature changes. Heating the IC package with a hot air gun followed by rapidly cooling it with an upside-down can of air-duster may temporarily “fix” the intermittent pin. But this is only a temporary “fix.” The original fault will return, sooner or later.
If heating/cooling the MCU temporarily fixes the tray oscillation, this would be confirmation that the MCU itself is actually faulty.
It would be informative to try this heating/cooling test on the MCU.
-EB
For testing the tray drive with the belt removed so that you can move the tray by hand, I would try this:
Disconnect the tray motor and then connect the wires that normally feed power to the motor to this test jig:
A 1k ohm resistor in series with 2 LEDs. The LEDs are wired in parallel, one red LED, one green LED.
These 2 parallel LEDs are wired anode/cathode and cathode/anode so that you will see either red or green depending on the direction of rotation (polarity) of the motor driving signal.
This will make observation of the motor drive signal polarity and any back-and-forth oscillation easily visible.
During this test you will always “operate” the tray with your hand.
I’m suspicious of “springiness” in that “rope” drive system for the disc tray.
-EB
I was suspicious of the spring loaded cable drive on the tray but this is quite tight. Even if it was causing the tray oscillation, it doesn't explain the clamper oscillation.
With the outer belt removed the loading motor inner pulley and belt can be easily observed without using the two led test jig. The oscillation does not occur when the tray is pushed in by hand as the reversal of the motor does not cause the tray closed switch to reopen without the belt attached.
The clamper does always oscillate and in both directions. I will try grounding TR5 collector to see what effect it has on the clamping phase.
I have a temperature controlled heat gun and a can of freezer spray somewhere so I can apply hot and cold conditions to the MCU to see if it cures the problem.
With the outer belt removed the loading motor inner pulley and belt can be easily observed without using the two led test jig. The oscillation does not occur when the tray is pushed in by hand as the reversal of the motor does not cause the tray closed switch to reopen without the belt attached.
The clamper does always oscillate and in both directions. I will try grounding TR5 collector to see what effect it has on the clamping phase.
I have a temperature controlled heat gun and a can of freezer spray somewhere so I can apply hot and cold conditions to the MCU to see if it cures the problem.
Last edited:
Grounding TR5 collector slows the clamping mech down but it does still oscillate, albeit slightly slower.
I tried the opposite and grounded the base to give the loading motor full voltage. That makes the tray whizz in and out really fast and oscillate more visciously but that's all.
I found my can of freezer spray so tried heating the MCU first with my heat gun and then after it cooled back down, tried using freezer spray. Neither hot nor cold had any effect on the problem while the tray was cycled.
########
Another test:
Remove belt from tray drive.
If you press open/close button to get the tray motor to run without moving the tray, does it keep running indefinitely in one direction or does it periodically reverse?
With the tray open the motor runs in the direction for closing when the button is pressed and then stops. This looks correct to me.
While the tray motor is running (without belt) what happens when you push the tray all the way in (closing the “tray closed switch)?
If the tray is closed by hand without the belt, the motor runs one direction (closing) and then the other (opening) once the closed switch operates. This looks wrong to me.
The motor runs in the opening direction for around 5 seconds and then stops and the clamper engages. The oscillation doesn't occur unless the belt is fitted.
Also observe what happens if you manually pull tray all the way out while the motor is running without a belt?
Manually pulling the tray out while the motor is running without a belt - the motor stops as soon as it hits the tray open switch. This looks correct to me.
I tried the opposite and grounded the base to give the loading motor full voltage. That makes the tray whizz in and out really fast and oscillate more visciously but that's all.
I found my can of freezer spray so tried heating the MCU first with my heat gun and then after it cooled back down, tried using freezer spray. Neither hot nor cold had any effect on the problem while the tray was cycled.
########
Another test:
Remove belt from tray drive.
If you press open/close button to get the tray motor to run without moving the tray, does it keep running indefinitely in one direction or does it periodically reverse?
With the tray open the motor runs in the direction for closing when the button is pressed and then stops. This looks correct to me.
While the tray motor is running (without belt) what happens when you push the tray all the way in (closing the “tray closed switch)?
If the tray is closed by hand without the belt, the motor runs one direction (closing) and then the other (opening) once the closed switch operates. This looks wrong to me.
The motor runs in the opening direction for around 5 seconds and then stops and the clamper engages. The oscillation doesn't occur unless the belt is fitted.
Also observe what happens if you manually pull tray all the way out while the motor is running without a belt?
Manually pulling the tray out while the motor is running without a belt - the motor stops as soon as it hits the tray open switch. This looks correct to me.
I've looked again at the three MCU logic inputs to the motor controller with the scope.
With the belt on, the controller is simply following the instructions it receives from the micro:
While loading (tray closed), M1 is high, M2 is low and M3 is oscillating.
When clamping (mech down), M1 is low, M2 is high and M3 is oscillating.
If the fault is in fact the MCU then maybe the only way to fix this problem is take control of these 3 lines away from it and install a separate logic circuit with switches to control the loading and clamping?
The original leaf switches can stay in place to provide signals for the MCU so it knows the tray status and when to start the disc.
Other than that I'm out of ideas on this one...
I have two new motors on the way but I think this is just clutching straws.
With the belt on, the controller is simply following the instructions it receives from the micro:
While loading (tray closed), M1 is high, M2 is low and M3 is oscillating.
When clamping (mech down), M1 is low, M2 is high and M3 is oscillating.
If the fault is in fact the MCU then maybe the only way to fix this problem is take control of these 3 lines away from it and install a separate logic circuit with switches to control the loading and clamping?
The original leaf switches can stay in place to provide signals for the MCU so it knows the tray status and when to start the disc.
Other than that I'm out of ideas on this one...
I have two new motors on the way but I think this is just clutching straws.
These observations cause me to suspect the MCU is looking for “tray closed” signals from the (non-existent) LED/photodetector tray sensor system which is used only in the CD-93 model.
Are you certain MCU pin 57 is at 5V at all times?
Pin 57 is the “model identification” pin:
Logic level 1 (5V) for model CD-73 (leaf switches for tray)
Logic level 0 (0V) for model CD-93 (LED/photosensor for tray)
A useful test is to temporarily ground pin 57 to observe whether or not this causes any change in behavior.
According to the CD-73 detail schematic, pin 57 is pulled high by a 47k ohm resistor located inside the resistor module 1B3. But because schematics are occasionally incorrect it will be useful to test both states of pin 57 (logic level high or logic level low) in order to learn whether either mode will fix the oscillation fault.
Another useful test will be to apply signals to pins 34 and 35.
These are the pins which detect signals from the LED/photodetector sensor used in the CD-94 model. The goal is to learn whether or not the MCU responds to these pins.
I suggest temporarily attaching pullup resistors to pins 34 and 35 for testing. Pullup resistor value can be anything from 1k to 47k ohms. Then test these 2 pins with all 4 possible states (00, 01, 10, 11).
If the MCU is actually in the proper “CD-74 mode” then it should totally ignore these two pins 34 and 35.
-EB
Are you certain MCU pin 57 is at 5V at all times?
Pin 57 is the “model identification” pin:
Logic level 1 (5V) for model CD-73 (leaf switches for tray)
Logic level 0 (0V) for model CD-93 (LED/photosensor for tray)
A useful test is to temporarily ground pin 57 to observe whether or not this causes any change in behavior.
According to the CD-73 detail schematic, pin 57 is pulled high by a 47k ohm resistor located inside the resistor module 1B3. But because schematics are occasionally incorrect it will be useful to test both states of pin 57 (logic level high or logic level low) in order to learn whether either mode will fix the oscillation fault.
Another useful test will be to apply signals to pins 34 and 35.
These are the pins which detect signals from the LED/photodetector sensor used in the CD-94 model. The goal is to learn whether or not the MCU responds to these pins.
I suggest temporarily attaching pullup resistors to pins 34 and 35 for testing. Pullup resistor value can be anything from 1k to 47k ohms. Then test these 2 pins with all 4 possible states (00, 01, 10, 11).
If the MCU is actually in the proper “CD-74 mode” then it should totally ignore these two pins 34 and 35.
-EB
For how many seconds does the motor run after pressing open/close button with the tray remaining in the fully open position?
(Don’t touch the tray for this test. Just let it stay in the fully open position)
Repeat this test by manually moving the tray in part way while the motor is still running. What happens?
Repeat this test by waiting for the motor to stop before moving the tray part way in by hand. What happens?
This appears to be the “fault” state where the motor will oscillate the tray when the belt is installed.
Does the clamper oscillate or does it operate normally at this time?
(After the 5 seconds of tray motor rotation in opening direction)
Please confirm:
The machine usually behaves when opening the tray.
The oscillation occurs when the tray hits the “closed” switch and then it oscillates.
-EB
Connecting pin 57 to ground definitely has an effect. The tray closes fast, the same as when Vr is set to run at full voltage. It closes without oscillation but the motor continues to run in the close direction. It eventually gives up and opens the tray at full speed, again without oscillation.
I tried pulling pins 33 and 34 high and low in all four combinations but the only effect it had was to slow the tray down in one direction or the other. With pin 57 pulled low I was unable to advance the drive to the clamping phase.
I'll try the other tests suggested in your latest messages tomorrow.
I tried pulling pins 33 and 34 high and low in all four combinations but the only effect it had was to slow the tray down in one direction or the other. With pin 57 pulled low I was unable to advance the drive to the clamping phase.
I'll try the other tests suggested in your latest messages tomorrow.
I’m gonna go out on a limb and state that pin 57 should remain pulled up (logic level high) for the CD-73 model.
Do pins 34 or 35 have any effect at all while pin 57 is pulled up?
My opinion is that the MCU should totally ignore pins 34 and 35 while pin 57 is pulled up.
This project would become vastly easier if we had a functional CD-73 to compare with.
I just had this really odd thought about the “tray closed” switch:
Is there any possibility that the portion of the tray which operates this switch is supposed to close the switch for just a very short duration, and then continue moving slightly farther, which allows the switch to reopen just before the tray hits a mechanical backstop?
I recommend taking a super-close look at the mechanical arrangement which operates the “tray closed” switch.
With the belt removed this concept could be simulated by manually pushing the tray in until the switch closes but then immediately pull it back out just far enough to reopen the switch.
My hunch is that maybe the MCU needs to see an input signal from the “tray closed” switch that goes 1-0-1 rather than 1-0.
-EB