Tuesday 19 July 2016

Debugging the analog data bus of a Roland JX3P

I've been having problems with my JX3P (modified with a Kiwi 3P kit) recently. Had been working very well for months and months, but everything went extremely quiet one day. Kiwitechnics have been super helpful and suggested that it didn't sound like an MCU problem, and gave me a couple of debugging tips. They are awesome.

Last weekend I finally had a few hours to investigate, so I opened her up!




Everything sounded extremely quiet with the occasional very loud noise. The moment it went loud was not completely random... It seemed to coincide with more than 3 key presses, although not consistently (sometimes I could press 6 keys and nothing would happen... At other times, it causes the loud noise).

First off, I checked the volume levels of the patches. Strangely, they had all become extremely low. I'm not sure why, but my guess would be a knock. In the course of this analysis, I realised there was a weak connection inside one of my MIDI cables - this could be related :)

So I increased the level of the active patch, and sure enough I could hear the notes again. However, a problem remains (otherwise I wouldn't have bothered with this post). The same reproduction steps I described above now make everything *even louder* despite the VCA levels for the active patch being set to maximum!!

A few knowns at this stage:

  1. The problem is related to multiple (more than 3) keys being pressed at once (although the pattern isn't obvious)
  2. It seems to be unrelated to specific voices (as each voice chip works fine in isolation)
  3. The resultant level goes beyond what it should be capable of (max VCA level on any given patch)

So I started looking a the multiplexers used in the JX3P... the "4051" chip:


 

The 4051 is a clever little chip. It can be used to multiplex (bring together) or de-multiplex (split apart) 8 individual signals. The signal active on pin 3 (the input or output signal pin... depending on whether we are demultiplexing or multiplexing, respectively) is determined by the bit pattern on pins 9, 10 and 11. Whether it is multiplexing or demultiplexing is controlled by the signal on pin 6.

This chip is used to set the different analog outputs that control the various blocks in the analog signal path of the JX3P. Including the VCAs for each voice chip (which control the amplitute of the notes...)



If you look at the different blocks above (DCO 1 CV, DCO 2 CV, VCA CV, VCF CV), you can see that they are all controlled by signals coming from 4051 multiplexers which are demultiplexing under the control of the MCU. Their different output values set to the voltage on the thicker black line above (the data line of the analog bus).

This leads us to TP-10! An interesting "Test Point" which sits on the analog bus' data line. As a note for electronics engineers generally, these test points are simply incredible for making sure everything is working correctly... If only all boards I worked with had them :)





Once the test point was hooked up, I attached the ground reference to the closest GND test point... A bit of a stretch!




I then set the scope to trigger on edges and set the scaling to reasonable levels. Here is a video of the problem being reproduced, with the scope trace of TP-10 (the analog data bus line) also shown:




I love this analog bus :) It is so much fun. The different multiplexers are being selected in turn for demultiplexing of the signals from the MCU. It's not a digital bus, so all the voltage level ranges are different for different values (they go from the MCU through an 8/12 bit D/A converter).

As you can see, the levels controlling the VCA CV appear to be entirely incorrect when this problem occurs. With the reproduction steps i'm following, the output on pin 3 leaps up beyond the max level for every utilised bit combination on pins 9, 10 and 11 whenever lots of keys are held down.

The service manual includes a helpful block diagram:


I think the problem must lie with either the MCU or the D/A converter. The demultiplexer can be ruled out of the equation, as the test point i'm looking at is directly on the analog bus data line, and the problem occurs there before the signal even passes through the 4051 chips.

I've already tried re-flashing the firmware, so I think the next step is to replace the MCU and see if that helps. It is socketed due to my Kiwi 3P upgrade, so this should be very straightforward!

I found this little debugging exercise so much fun, I felt compelled to share it :) 

All hail useful service manuals and test points :D


UPDATE 23/8/2017:

MCU replacement has done the trick :)




hooray!

2 comments:

  1. Hi Matt, I'm currently working on my Kiwi3P which also has issues with background intermittent low frequency noise when the filter resonance is increased. You mention replacing MCU are you referring there to the KIWI CPU?

    ReplyDelete
  2. Yes, it's the Kiwi3P!

    I have some on-going issues with low frequency noise, caused by the chorus clock. If I switch the chorus to auto, I get it... have to turn it off or set it to manual. Asked Murray about it, but no one else seems to have the problem, so I assume it's something I've done wrong :)

    Might be worth you experimenting with modifying the chorus setting when you experience the noise...

    ReplyDelete