MB-6582 Need advice on troubleshooting audio buffer

[highrider]

One of my 6582 SIDs is not outputting the test tone. It's a working SID )) I have used it in other sockets. The voltages are fine. I'm confident the problem is in the audio buffer area because I managed to get a test tone going out to my headphones by bridging pin 8 of U1_SID3 with J3_SID3 out pin. I also managed to nearly deafen myself by doing that.

I'm not that skilled in electronics but from my point of view all the connections seem fine (if slightly messy). Can somebody suggest how to find where the signal breaks in that section? Also is there anyway of determining if the transistor in T1_SID3 is alive or not?

A continuity test wouldn't work here because this section is full of caps, right?

Thanks for reading!

Vlad

[Wilba]

It would probably be easiest to just replace the transistor and see if the problem is fixed, thus proving it was probably the transistor at fault. It's highly unlikely any of the other components are broken, as they're all resistors and capacitors which don't often fail from soldering too long, unlike transistors.

[highrider]

It would probably be easiest to just replace the transistor and see if the problem is fixed, thus proving it was probably the transistor at fault. It's highly unlikely any of the other components are broken, as they're all resistors and capacitors which don't often fail from soldering too long, unlike transistors.

Wilba, thanks for replying so soon! You helped me so much! It was a broken resistor leg that was the problem. I couldn't see it earlier because the resistor was in an upright position and the second leg was concealed from view. So as I was trying to perform a continuity test I accidentally pressed on it and it turned out wobbly. I put a new one in and moments later the SID sang a 1Khz tone. Now I have every output fully functional.

My final task is to determine whether I have broken PIC's 01 02 03. They all work fine with the test tone app. All have successfully uploaded MB sid app V35. The core modules work fine with my only fully operational 00 PIC , but the 01 02 03's play for a couple of seconds and then either hold the note or go completely mute. Voltage checks have passed.

All I could find by searching the forum is that people with similar problems had to buy new PICS , but I couldn't find a single confirmation that this resolved their issue usually the threads just stop after that.

It seems that I'm missing something and I don't want to just order more pics without being at least 90% sure that the PICS are actually broken.

One more thing. I haven't put the Pics in slave mode as I don't have the menu button yet. I have just uploaded MB sid to each pic while moving the jumper on J11 with each PIC in it's respective core. Should I try to upload the MB SID app from core 1 only?

(R80 in place, diodes positioned correctly)

Am I providing the right information?

Cheers!

Vlad

[Wilba]

It should not matter whether you upload directly to each PIC or via the "cloning" method, both will result in the same firmware on the PIC... perhaps uploading directly is better because in MIOS Studio you get feedback (i.e. CRC checks on each block). This is probably happening during "cloning" via the CAN bus too, but there's less confirmation that everything is OK.

I don't think your PICs are broken... if you really want to test things, you could use the changeid program to make another PIC ID=00 and try that in the first Core.

Holding the note/going mute: How exactly are you testing that the other PICs stop working?

i.e. what is your current setup, how do you make all four PICs/SID engines operate?

The problem could be related to the CAN bus (i.e. master PIC->slave PIC communication fails) OR maybe even MIDI In to the slaves stops working (so you get a stuck note because Note Off is never received, or mute because Note On is not received anymore).

It's also possible that the PICs stop working completely... you should try a patch that has some kind of modulation so when it "stays on", you can tell that the synth engine is still running. For a simple patch without modulation, the SID might still be playing the last note while the PIC has stopped and you wouldn't know. So you should try something like an arp sequence so you can hear it still "working" and know the PIC is still working (as opposed to stopped completely).

[highrider]

... if you really want to test things, you could use the changeid program to make another PIC ID=00 and try that in the first Core.

The problem could be related to the CAN bus (i.e. master PIC->slave PIC communication fails) OR maybe even MIDI In to the slaves stops working (so you get a stuck note because Note Off is never received, or mute because Note On is not received anymore).

I agree that the logical step is to change the ID of each problematic pic. Unfortunately I don't understand how to compile the hex file with provided code in the readme file's. I tried to read the wiki but I failed to make sense of it...so I'll have to pass on this one.

I need know if I can exclude bad soldering as a possible cause. If my master PIC 00 is working in each socket without a problem this means that all the MIDI comms are fine throughout the 4 cores, right? If understand correctly it's not different for the slave PICS i.e. if one PIC is receiving MIDI then the others should as well.

Holding the note/going mute: How exactly are you testing that the other PICs stop working?

i.e. what is your current setup, how do you make all four PICs/SID engines operate?

I have a fully loaded PCB (all IC's in their sockets) no resistors for LED's though. No LCD just the base. I have the SID rc35 app uploaded to pics 00 01 and 03. 02 has the test tone atm. Earlier when I had all pics with mb sid rc35 the behaviour of pics was the same (note on hold or mute after 2-3 seconds). I'm assuming that the pics stop working because they no longer respond to midi notes/cc's until I reboot.

you should try something like an arp sequence so you can hear it still "working" and know the PIC is still working (as opposed to stopped completely)

With an arp sequence going from my midi controller (akai mpk 49) the sound still stops after 2-3 seconds on pics 01 02 03.

I have checked the voltages on all the IC's and I'm getting 4.88V (sids 8.87).

I can still hear what I play through channel 1 output after the other stop. Pic 02 outputs the test tone even with 01 and 03 not working.

Btw Can I re-upload MIOS 1.9G to each pic to format the bank sticks and to exclude the possibility of wrong software uploads causing the problem? I just remembered that I have uploaded the vintage bank 4 times (with MB sid editor) to PIC 01 (by changing the bridge on J11). I haven't understood the manual correctly and thought that I have to upload the bank through each core to have the patches working on each core. I did this because previously the vintage bank was only available through pic 00 while other cores only had the lead sound.

Perhaps by uploading the bank 4 times to PIC 01 I have caused this problem. Actually the patch I hear after power on is not a lead sound at all, it's more of sequenced riff...

Can you confirm that it's alright re upload MIOS 1.9G so that I can start over?

Thanks !

Edited February 3, 2010 by highrider

[Wilba]

It's OK to upload MIOS 1.9g to all PICs.

When I said try testing with an arp sequence, I meant a patch which has its own arp sequence... or any patch that will vary the sound over time... so when you hold down a keyboard key and it gets stuck on, you know the PIC is still running because the sound is still varying (as opposed to the SID being stuck with it's oscillators at constant frequencies). However, since you don't have any control surface yet, it's hard for you to setup a good test across the multiple PICs.

The patch banks are uploaded to the 24LC512 ICs not the PIC, and are only connected to the master PIC when in the #1 slot, they won't be available when the PIC is elsewhere.

I don't think your PICs are broken... use the changeid program to swap PIC 00 with PIC 01... then try the new PIC 00 in the master slot.

You really should connect an LCD, this can show you if there's a problem with the CAN bus and also let you connect the LCD to any Core and check it's still receiving MIDI by sending LCD commands with MIOS Studio. Right now you're trying to debug with no LCD and no control surface, it's too hard... make things easier for yourself!