Ambika SMR-4 Voicecard Assembly Troubleshooting

Hello all!

I recently attempted to build an Ambika, and I was able to confirm that my motherboard build passed the power rail tests in the “Testing” section listed here: http://mutable-instruments.net/ambika/build/mobo

However, only two out of the six SMR-4 voice cards seem to be working on my build; 4 of the voice cards do not light up a DATA LED when stacked into the motherboard. I’ve tried all the possible permutations of voice cards and motherboard slots, and I can confirm that the two functional voice cards work in all the slots, but none of the other four; it appears as though that the problem is on the voicecards themselves.

I’ve confirmed that the diode (D1) and the four transistors (Q1-Q4) are in good condition on each card by using the method described here:
http://www.electronics-radio.com/articles/test-methods/meters/multimeter-diode-transistor-test.php

I’ve also traced through the Scematic of the Ambika SMR-4 and I can confirm that all the ICs appear to be getting power from the power line on the header pins, so it’s curious to me as to why the DATA LEDs would not be lighting up on these boards. For what it’s worth, the DATA LEDs also appear to be soldered in as expected.

I’ve resoldered the IC sockets, but I’m still not seeing any progress.

Is there anyway I can get feedback from the Ambika itself about what sound cards are available? How would I go about testing if the ATMEGAs on the SMR-4s are in good shape? Does anyone else have any pointers as to how I can further test out the voice cards? In general, I’m pretty stumped as to what to debug next.

Any help would be greatly appreciated!

One thing worth trying is the firmware update procedure on the voicecards.

After attempting the voicecard firmware update process listed here: http://mutable-instruments.net/forum/discussion/3078/ambika-voice-card-issue-narrowed-it-down-to-the-main-cpu-but-why/p1

It appears that I still get a ‘?’ on the device I’m attempting to update the firmware on. After multiple attempts, it still looks like the non-functional voice card is not getting the firmware update (or the Ambika motherboard thinks it is not connected).

Any other pointers for further debugging?

(Also, I appreciate the swift response! Thank you :))

Is the A/B jumper correctly set?

Yes, I can confirm that the non-functioning card has both of the jumpers bridging the A pin (I’m placing the non-functioning card directly into the motherboard slots; there are not other cards on top of it).

Then it may be time to post some pictures of the non-functioning card (both sides) …

Cristal and the two caps, or the arduino headers. Have you test if 5V -8 and 8 volt are there ?
Normally the Atmel must give a Signal , in spite of you use only the ATMEL and the DAC. You can remove all other IC’s. If there is no signal , than it can be that the ATMEL had no firmware , or the cristal don’t oscillate or simply the 5 Volt rail had no power. Or a short.
I had here a similar problem with one voicecard . This was the ATMEL socket.
BTW, do you use the same cristals and the same caps 18 pF for all voicecards and the MOBO ??
For example , MOUSER and Farnell uses cristals with 18…22pF, Reichelt cristals need 33pF.

Greets

Andre’

@tubeohm: I can confirm that I get +8V, +5V, and -8v to the Headers on the non-functioning board when it’s placed on the motherboard.

I can also confirm that the following ICs have the following voltages:
Atmega 328p: +5v
MC4822: +5v
TL074CN: -8v and +8v
LM13700N (1): +8v and -8v
LM13700N (2): +8v and -8v
LM13700N (3): +8v and -8v
TL072CP: -8v

After checking continuity on every connection on the board, it looks like there’s no cold joints, either :frowning:

Yes, I used 22pf Caps for the crystal. The instructions lead me to believe that those were OK instead of 18pf capacitors.

Is there any way to check the integrity of the Crystal while it’s onboard? What are the chances it could’ve got damanged in transit or during assembly?

@eelco: I’ll clean the boards up tomorrow and get some pictures online.

Another update!

After poking around a bit more on the circuit board, I can confirm that the MCP4822 DAC has some different voltage readings on the non-functional boards vs. the ones that work.

After reading up on the Data sheet (http://www.mouser.com/ds/2/268/21953a-8929.pdf), it looks like the SDI pin (PIN #4) is reading 100mV+ - 300mV+ on the broken boards and 5V+ on the functional boards.

It should also be noted that I’m getting the same 100mV+ - 300mV+ Reading on Pin 3 on the AtMega328p (PCINT17/TXD).

Could anyone tell me what I can look at next for debugging? I’m a little bit lost since it looks like these pins are only connected to each other through a single trace on the PCB. Could there be some other component that’s not soldering on correctly that would be contributing this issue? What would be causing Pin 3 on the ATMega328p to be writing at a lower Voltage than expected?

It’s probably a consequence of the processor not starting at all.

If you want you can send me the 328p chips and I’ll test them / reprogram them if necessary. Unless you’re outside of the EU in which case the round-trip would take too much time…

@pinchenettes: Thanks for the offer, but I’m in Seattle, WA, USA, the time to ship back and forth would just take too long. I’m confident that I could re-program the chips myself if necessary! Do you have a reccomended procedure for programming the atmega328ps ? I’ve seen a few articles online describing how to program these chips using arduinos, but I wasn’t sure if there was an additional step for this build.

Update:

I swapped out the Atmega328P of one of the working machines and placed it in one of the non-functioning boards. It worked. I’m a little more confident that it’s now an issue of the atmega328p not being programmed correctly.

I ordered a few extra Atmega328ps, and I’ll update this thread when I have more progress.

In the meantime, does anyone have a preferred way of programming the atmega328p?

AVR ISP mkII is the preferred way.

It’s been a while, but I wanted to update this thread saying that the problem was solved.

It should be mentioned that when I originally purchased the parts for my Ambika build, I had coordinated with a friend and we bought 6 SMR4 cards and 1 4P card each. So when the shipment arrived, we got all of the microcontrollers for these voice cards in very similar looking packaging. The only difference between the Atmega328ps was a small number on the IC above the serial number (1425 for the SMR4 boards, and 1440 for the 4P boards, respectively).

I had accidentally placed the 328ps intended for the 4P on the SMR4 cards by mistake. It was a complete goof on my part.

Thanks everyone for your help. Consider this one solved!

The problem was due to something else - all voicecards run the same code, and all chips are programmed with identical firmware.

So what was the issue ? I’m having the same problem.