ChromaTalk Archives: April 2020
- Keyboard scanner (12 messages)
Keyboard scanner
Luca Sasdelli [21010226] · Fri Apr 3 11:32:35 EDT 2020
Hi all,
here I've got a very damaged Chroma: it arrived nearly two years ago, in very bad conditions (i.e. distributed on several shopper bags etc).
After a very long restore work, this morning finally I had it performing autotune without errors and with great sound.
Then I've left it powered on for a while, and I was doing other tasks on another bench, so nothing has disturbed it in any way.
After one and a half hour, suddenly all Chroma voices started, so promptly I've reset it via SetSplit[50]: it did the reset sequence as expected, but after that no keyboard is detected anymore.
At present it does properly autotune, but it doesn't recognize any keystroke.
SetSplit[37] shows no DVB select with any key press.
Replaced Z31 with no changes. Even right stack switch ICs have been replaced.
The keyboard scanning circuitry appears as follows:
- Z31-9 PSEN operates > 500kHz
- Z31-11 ALE as previous one
- Z31 data bus seems to work
- Z31-8 RD stuck high
- Z31-6 INT stuck high
- K MASK (Z29-2) properly cycles during autotune, then high
- Z34 inputs seems to work
- Z35 inputs seems okay, outputs all stuck low (Z35-9 high, so no store)
- Power +12v and +5v on switch stack boards Ok.
Any hint?
Thanks!
Luca
Paul DeRocco [21030230] · Fri Apr 3 17:46:10 EDT 2020
Is it possible that the scanner EPROM has faded? You could try reprogramming it. Just because you see activity on its data bus doesn't mean it's reading and executing the actual program.
Luca Sasdelli [21010226] · Sat Apr 4 04:10:12 EDT 2020
Thank you Paul for your hint,
anyway, I've compared the EPROM reading with the binary file, and they match.
CC+ firmware is okay as well.
Next step will be to replace all KSC logic ☹
Ciao
Luca
Paul DeRocco [21030230] · Sun Apr 5 03:25:10 EDT 2020
From: Luca Sasdelli
anyway, I've compared the EPROM reading with the binary file, and they match.
CC+ firmware is okay as well.
Next step will be to replace all KSC logic ☹
That should be the last step. I would try to figure it out with a scope before replacing everything. Poking around with a probe is easier than desoldering and soldering. Are you seeing the expected pattern of bank numbers being sent to the keyboard? If so, are you seeing the data coming back respond to key presses?
Luca Sasdelli [21010226] · Wed Apr 8 05:45:41 EDT 2020
Ciao Paul,
I totally agree with you, but the matter is now the time, therefore I should choose the fastest way; I'm aware that this would leave the cause unresolved, thus impairing future similar fault findings.
To cut times more, I've temporarily swapped the whole I/O board with another one, and the issue is vanished. Then I'll deeply check on the original I/O.
Cheers
Luca
Luca Sasdelli [21010226] · Fri Apr 10 16:22:39 EDT 2020
Hi all,
just to close the issue: the I/O board is now fixed, after replacing all keyboard scanner logic, except the CPU and EPROM (Z32, Z33, Z34, Z35, Z36, Z37 and Z49). Surely not that clever, neither useful for similar fault finding, but effective because of my time needs.
Another question: all DVBs have been tested with my simulator and they work very well: all connectors, C13 and C14 are new, but some of them fail autotune after half an hour from power-up or so. In detail: at power-up all ok, and the same by hitting AUTO TUNE on panel; after some time, AUTO TUNE fails on some boards (three of them) and reset won't cure it. A power cycle restores instead.
It seems that this isn't a thermal issue, but something related to component charge or something like it.
Cheers
Luca
David Clarke [21030085++] · Fri Apr 10 17:56:36 EDT 2020
… but some of them fail autotune after half an hour from power-up or so. In detail: at power-up all ok, and the same by hitting AUTO TUNE on panel; after some time, AUTO TUNE fails on some boards (three of them) and reset won't cure it. A power cycle restores instead...
The assumption is that it has been confirmed (by swapping board locations, and keeping track of which ones 'fail' over time) that the issue follows the voice cards (vs. the channel motherboard).
Assuming so - a great tool to have is a small interface device to convert from the Chroma's DB-25 interface port to a standard serial interface you can connect to you computer. There's no 'off-the- shelf' unit to do this - but a small PIC or similar controller could be used to do the conversion.
Having one of these will let you use a standard serial terminal program to issue 'Chroma Port' commands to the Chroma: Interface Manual: Command Descriptions
With this you can actually 'peek' inside the Chroma's memory while it is running. More specifically, for this sort of an issue, you can directly view the stored RDAC and MDAC values for the oscillator and filter tunings on a channel-by-channel basis. You can see how close to the margin limits they are to start with and (with multiple tuning attempts over time) what direction they're drifting towards.
Different revisions of voice cards have had different component values installed for some of the scaling resistors - and in combination with the other parts/tolerances on the board can tend to shift the 'nominal' starting part for tuning to be more towards one side or another. Seeing how they're skewed to start with would suggest whether changes in that area might make sense.
By seeing how the signals are shifting over time, you can also get a sense if it is drifting too far, too fast (e.g., compensation issues, component issues, etc.)
[Note - this approach would work with all Chromas - and does not rely on having a CC+.]
This sort of data can be used in addition to the general information regarding which 'functional blocks' of the cards are failing tuning (as can be retrieved by using the voice-card debug capabilities of the CC+ and alphanumeric display): CPU Plus User's Guide: Set Split 40 Display Autotune Failure Information
Luca Sasdelli [21010226] · Tue Apr 21 16:49:44 EDT 2020
Hi David,
I should admit that this tuning matter is still quite hard to me.
The situation is: two DVBs are fine just after power-up, even with warm instrument; after some tenths of minutes, an autotune would fail only with those two boards, irrespectively to their position on CMB. Reset (either SetSplit[50] or /RESET) won’t cure it.
A power cycle resets the state, and autotuning has success. All other DVBs are ok.
SetSplit[40] shows error code E0 upon fail, VCO A both boards.
With only one of the mentioned DVBs, I’ve replaced by steps all VCO semiconductors, but no changes. The S&H DC behavior is equal between A and B; I’ve also replaced all fast S&H capacitors, and VCO capacitors, without any improvement.
Another impression: by setting the duty cycle to 50% with the scope, results in a totally absent sawtooth harmonic, as if the square comparator were working outside its defined range. In practice: 50% square is obtained with the trimmer, but with sawtooth there is no region where the pitch doubles, as it normally happens during tune by ear.
In your excellent Tuning document on Chroma site, you wrote that the VCOs are set with a 144Hz and a 9,2kHz, but I can’t find any voltage reference to them. What I mean, I’d like to know the voltage range that CPU does allow to try to obtain those frequencies, before aborting, so that I’d try to check with my DVB tester if the VCOs, at those frequencies, does fall within the adjustable area of the CPU or not.
Or if you know any way to simulate the CPU calculation, to be done via a CV to the board, it would be highly useful for this issue.
Thanks again
Luca
David Clarke [21030085++] · Wed Apr 22 07:59:34 EDT 2020
SetSplit[40] shows error code E0 upon fail, VCO A both boards...
Luca - if it has not already been done, then prior to issuing SetSplit[40] an attempt should be made to tune with SetSplit[31].
(If this is not done, then SetSplit[40] will only show the 'first' error encountered for the voice card - not all errors.)
SetSplit[31] will allow all errors to be captured.
If the E0 error (Oscillator scale factor high end measurement) is the main one still seen, then the implication is that the request to produce the 'high' frequency has made it so that the period actually can't be properly measured.
SetSplit[31] will also leave all 'failing' boards enabled so that you can still 'play' them. In this case, the 'tuning' used is center-scale/nominal tuning. This is convenient as if you play the failing voices you can get a sense (especially in the failing case) as to how they sound (e.g., are the higher notes abnormally too high or perhaps too low - or might it be that the notes have now taken on a portamento (such that nominally the frequency may be OK - but just not OK for the instant the auto-tune is otherwise looking at the frequency).
...the VCOs are set with a 144Hz and a 9,2kHz, but I can’t find any voltage reference to them. What I mean, I’d like to know the voltage range that CPU does allow to try to obtain those frequencies...
It is important to note that there isn't a 'fixed' voltage-to-frequency assignment.
Instead different voice cards will have slightly different volt/oct responses, and will also have different absolute offsets for frequency. That's exactly how/why the CPU will use a different DAC/reference DAC setting (on a voice-by-voice basis) - so as to adapt the actual voltage to match the voice card (e.g., to use the calibration/adjustment factors found during the auto-tune to otherwise normalize the 16 different voices).
Additionally, it is not so much about what voltage _range_ the CPU will try. Instead - it is a matter of how the analog electronics responds to 'fixed' voltages produced.
Specifically - the Chroma will generate a DAC voltage output for that it believes should be a note (e.g., nominally 144Hz). It then puts out another voltage for what it hopes will be 6 octaves away. It then attempts to measure the time periods associated with these two voltages.
So - for a 5V analog rail of 5.05v, and for a center scale RDAC value - the reference voltage into the main DAC would be about 4.6877v. That means each DAC 'bit' would represent about 1.14mV. As the tuning adjustment is in terms of 32nds of a semitone, an octave would be represented by 32 x 12 = 384 DAC values - or about 384 x 1.14mV = 0.437v/octave.
So - the main DAC would output voltage X (to request the 'low' frequency' - then output voltage X-(6x0.437) to request the 'high' frequency.
There's no 'absolute' frequency that the oscillators should produce in response to these two voltages (as the auto-tune produces a correction factor to offset to the actual 'desired' frequencies) - but in order for auto-tune to 'work', the resulting frequencies have to be able to be measured using the internal timer. If the resulting frequency is too high (or too low) to be measured by the timer/counter - then the 'tune' will fail.
Nominally the 'low frequency' DAC voltage will be about 3.38V and the 'high frequency' will be about 0.771 - but the frequencies these voltages produce are allowed to vary widely and still be OK (e.g., it might end up as 122 and 7.8k - and that's OK).
Luca Sasdelli [21010226] · Wed Apr 22 09:07:03 EDT 2020
Thank you again, David. I'll look at it more deeply later.
Scott Rodriguez [21030079] · Wed Apr 22 08:08:26 EDT 2020
Luca:
If you have any of the original RCA 4558 op amps on your cards, I'd replace them without a thought. I've had nothing but problems with these, nealy all of them failing sporadically and when they do, can cause all kinds of different issues. Best thing I did to eliminate recurring problems was to install all new 4558 amps everywhere on all the cards.
Luca Sasdelli [21010226] · Wed Apr 22 09:12:08 EDT 2020
Hi Scott,
the 4558/1458 is a quite noisy OA, and I usually replace them with TL072 when needed. Indeed I didn't replace such as many 4558s, but I'll keep useful your suggestion.
Cheers
Luca