Super Sixteen build support thread

[jonnyjupiter]

Bad luck. I've had too many of those existential moments post midnight, so now always stop at 11:30pm at the latest.
It's that tricky balance between finding a bit of free time long enough and the excitement of the new build.
About to test a build that went right up to the 11:30pm curfew last night. Hopefully won't have to bring my cocoa further forward.

[extralifedisco]

I've got a weird issue with my build. When I power it up, the 16 small leds light up dimly, but I can see what I'm selecting. The two bigger leds don't seem to light up at all. I'm pretty sure I got the orientation correct on the big ones. I can't see any obvious shorts. Any advice as to where to check first?

Edit: I'm looking at my board and the schematic and I've probably got a cold solder on pin 8 of U1 (or something...)

Edit2: It's not pin 8 of U1. Guess it's time to take some pictures...

Edit3: From the build guide: "Double-check that the LEDs are installed in the ​correct orientation​, with the short legs in the square holes on the PCB"
Fuck.

Edit 4: I've had my 15 minutes of existential despair over it. Serves me right for getting stressed over politics and then deciding to finish the build at 3am and pushing on til dawn. And then I had to wait all day for my kids to go to bed before I had the mental energy to puzzle it out. I'll pick up a proper desoldering gun and make it right next month. Still a very nice build, very solid. Cheers.

Ah, that sounds familiar! I've definitely bricked some boards trying to rush the last few parts. In fact I've even done the exact same thing on the my earlier prototype boards! I've actually compiled a version of the firmware that flips the polarity of the shift registers and allows the LED matrix to run with the LEDs installed in reverse. If you have an ICSP programmer of some kind you can just hook it up to the module and re-program the atmega chip to use that firmware.
https://github.com/matthewcieplak/super ... verted.hex

If you have avrdude installed (comes with the arduino software), here's a shell command to upload the firmware - you'll want to change "firmware.hex" to "firmware-inverted.hex" and you may need to use a different serial port or programmer mode (COM4 or COM5 instead of COM3 maybe, depends on your programmer. I use the pololu avr v3 which emulates the atmel stk500):
https://github.com/matthewcieplak/super ... /upload.sh

For the gate and glide LEDs, you'll have to physically flip them as they're connected to the ground plane and can't be flipped in software.

As far as desoldering, I haven't got an electric desoldering gun but it is on my list! For small parts like LEDs you can usually just grab the led from one side and then wiggle it out one leg at a time while heating one pin, or heat up both terminals with a wide iron tip. Of course you still have to get the leds back in and seated at the right height so a manual (spring-powered) solder sucker is also handy along with some solder wick to clean out the vias.

EDIT: actually now that I think of it the inverted firmware may also flip the display register so it can use a common anode unit - if you have display issues with it or the LEDs don't start working let me know and I'll recompile a build for you.

[FrJK]

Hi,
I have built a through hole version based on the PCB/panel kit from your kickstarter project. All is well, except on the 7 digit display the 1 is much brighter than all the other numbers. Is that normal?
Thanks, Frank.

[extralifedisco]

Hi,
I have built a through hole version based on the PCB/panel kit from your kickstarter project. All is well, except on the 7 digit display the 1 is much brighter than all the other numbers. Is that normal?
Thanks, Frank.

Hi Frank,
Yes, I notice this on my boards as well. It's odd, but I guess it's a feature of either the shift register design or the common anode topology. I'm not really sure how to solve it besides using an expensive Maxim dedicated display chip or a bunch of discrete transistor logic. Either way it is totally normal for the builds!

[FrJK]

Hi Frank,
Yes, I notice this on my boards as well. It's odd, but I guess it's a feature of either the shift register design or the common anode topology. I'm not really sure how to solve it besides using an expensive Maxim dedicated display chip or a bunch of discrete transistor logic. Either way it is totally normal for the builds!

Thanks a lot for clarification.
Frank.

[sd_falter]

Just finished a build. Did the tests, all good. Plug it in..... and nothing. No Display lights, no button, lights,... Nothing.

I went through the entire 2 boards and reflowed all joints, and verified polarity.

Parts were bought using the Mouser cart that was provided.

Oh no! Well there's a long list of things to check I suppose, but number one is to check all your IC orientations (pin 1 should match the dot on the PCB. I can see from your photos that the shift register 74HC595 near the display module is installed backwards, so pop that out and reverse it. I expect the chip will survive but if you get LEDs and buttons working but no display, then it could be toast (they're cheap though).

If flipping that doesn't fix it, use a multimeter to check voltages on IC pins. You want to find 5V on pin 7 of the CPU (atmega328p), and pin 1 of the DAC (mcp4822). On the control board, you want to see +5V on pin 9 of the MCP23S17 and pin 16 (corner) of the 74HC595s. You also want to see 3.3v on the memory chip, but that fault wouldn't cause a failure to boot.

I'm encountering a similar issue in that i've completed the build and nothing boots or lights up at all when powered.
I've checked IC orientation and that seems fine, checking all the voltages you've listed above and they are good too (5v on CPU & DAC, 5v on MCP23S17 and the 74HC595s, seeing 3.3v on pin 8 of the memory SMT chip too).

Note i've also done the continuity tests for shorts as described in the build guide but nothing appears to be of fault there either.

Not sure what else I can troubleshoot here so looking for pointers. what happens if you boot these with an unflashed atmega? im using the one i got with my kickstarter but maybe thats the issue and i just need to reflash?

[sd_falter]

Photos of my build. in retrospect i probably should have used sockets.

has to be the one time i tempt fate in a build by slacking off on socketed ics is also the first build in a long tome to go awry argh.

also due to some wackness with digikey, i didnt get the full set of resistors from my bom, so used some 1k, 10ks i had lying around. wouldnt think that would break the build but who knows?

[sd_falter]

Update -- Turns out my atmega from the kickstarter delivery was not flashed :(

I spent a number of hours reading up on using arduinos as isp programmers and with the help of this tool:
https://github.com/nickgammon/arduino_sketches -- in particular the Atmega_Board_Detector I was able to determine the contents of the bootloader and flash memory were null.

Anyway, using this https://app.box.com/s/ol1z8jjnrpy6wly4w61imt7wcbxk3fcg as a guide I was able to get my Arduino Uno to operate as an icsp programmer and upload the firmware from the github.

It boots up now nicely and leds working, encoder is being read to the screen so it looks like that was ultimately the culprit. Will have to actually test and calibrate but for another time.

edit: had a run thru with the sequencer, everything works! still need to calibrate but worth it, this things fun as hell.

[extralifedisco]

Update -- Turns out my atmega from the kickstarter delivery was not flashed :(

...

It boots up now nicely and leds working, encoder is being read to the screen so it looks like that was ultimately the culprit. Will have to actually test and calibrate but for another time.

edit: had a run thru with the sequencer, everything works! still need to calibrate but worth it, this things fun as hell.

Oh wow, sorry about that! Massive oversight on my part there. Very nice work debugging the issue and figuring out a fix and implementing it in record time!!

If it's any consolation, I believe you are the first person to get to access the new firmware version 1.1 , which is what's up on github right now (firmware.hex). Included are several new generative sequencing mutations (check the last 3 mutation modes - tu1, tu2, tu3) as well as sequence chaining/song mode, and some little quality-of-life improvements. I will be doing an update video about it next week but you can find the updated manual which explains the new features here:
http://extralifeinstruments.com/docs/su ... manual.pdf

I think quite a few folks will be gearing up to do the same re-flashing process you did so they can update!

[sd_falter]

Update -- Turns out my atmega from the kickstarter delivery was not flashed :(

...

It boots up now nicely and leds working, encoder is being read to the screen so it looks like that was ultimately the culprit. Will have to actually test and calibrate but for another time.

edit: had a run thru with the sequencer, everything works! still need to calibrate but worth it, this things fun as hell.

Oh wow, sorry about that! Massive oversight on my part there. Very nice work debugging the issue and figuring out a fix and implementing it in record time!!

If it's any consolation, I believe you are the first person to get to access the new firmware version 1.1 , which is what's up on github right now (firmware.hex). Included are several new generative sequencing mutations (check the last 3 mutation modes - tu1, tu2, tu3) as well as sequence chaining/song mode, and some little quality-of-life improvements. I will be doing an update video about it next week but you can find the updated manual which explains the new features here:
http://extralifeinstruments.com/docs/su ... manual.pdf

I think quite a few folks will be gearing up to do the same re-flashing process you did so they can update!

Nw, I understand how these things happen as I imagine you were probably trying to get a whole pile of kits out the door in no time.

Good to know I managed to get the latest firmware out of it! I did notice the tu1-3 mutation modes but didn't have a go at them. Will check out later. This thing is quickly becoming one of my fave modules so kudos for designing it!

[Kerplunk]

Interesting! I haven't used an MPC-X so can't really offer much insight on how that works by default. When I am testing it I generally use it with a mutable instruments module tester or an erica synths MIDI-CV interface. What I do is set up a single MIDI note in my DAW to as a trigger out on beat 1 and then send that to the reset input through the midi-cv. The Super Sixteen will read the reset input first and the clock input second, so if they go trigger simultaneously, it should start in sync. The pulse length generally doesn't matter as the input is latched.

Hey Extralife!

I hope all is groovy!

So, I got rid of my MPC, and have replaced with Ableton + Expert Sleepers FH2.

I'm unfortunately still having the same problem. I have a 1/16 clock going to the Clock input and a 1/1 clock going to the Reset input but instead of it being synced, there is a double on the first beat. Which is throwing the timing out.

I have sent 2 clocks as gates directly to envelopes, driving one oscillator per , and have not had any issue with timing

This is a video of what I'm getting

The Kick is coming from Ableton, which is triggering the FH2. The FH2 is sending the 2 clocks to both Clock and Reset inputs.

It seems to work fine, if I only send a clock to the Rest input or Just send a clock to the Clock input, but not both...

Any advise would be appreciated...


thanks

Ben

[synthcube]

Hello all, now that we have these in the shop, we can say what an amazing little project--- fills a void in eurorack DIY and really a well-done kit, documentation and support!

[extralifedisco]

Hey Extralife!


I'm unfortunately still having the same problem. I have a 1/16 clock going to the Clock input and a 1/1 clock going to the Reset input but instead of it being synced, there is a double on the first beat. Which is throwing the timing out.

I have sent 2 clocks as gates directly to envelopes, driving one oscillator per , and have not had any issue with timing

This is a video of what I'm getting

The Kick is coming from Ableton, which is triggering the FH2. The FH2 is sending the 2 clocks to both Clock and Reset inputs.

It seems to work fine, if I only send a clock to the Rest input or Just send a clock to the Clock input, but not both...

Any advise would be appreciated...

Ah, what a pain! I just fired up ableton to try to repro this and I'm able to see exactly what you're getting. It seems like the pulse length does matter and it needs to be in a very small range (shorter than the clock pulse but not by too much) in order to work. This is clearly a firmware bug I should patch - I will try to sneak that into the 1.1 release this weekend!

The workaround I suggest (which does work consistently at least) is to have a midi note in ableton *just before* the end of the bar so that it goes out and resets the clock after step 16 but before step 1. You can also put a super-short trigger on beat 1 so that the sequencer starts in time on the first play-through, but this as mentioned is inconsistent. However if you set the clip loop brace to omit that first note every subsequent loop will be accurate. See attached image:

I'm really not sure what happened in the code as I'm fairly sure I tested this exact use case several times without incident, but clearly I overlooked something. The reset input should really only care about the rising edge of the signal but somewhere it's checking the state of the input and misinterpreting the signal. I'll update you when the firmware is amended.

[izash]

Hi Matthew,
Thank you for the email reply.
I checked the soldering joints and even replaced the memory chip with a new one.
Unfortunately the Super16 still crashes when turning the data knob.
I'm attaching photos and a short video.
Thanks!
Izhar

Super 16 Crash Video

[extralifedisco]

Hi Matthew,
Thank you for the email reply.
I checked the soldering joints and even replaced the memory chip with a new one.
Unfortunately the Super16 still crashes when turning the data knob.
I'm attaching photos and a short video.
Thanks!
Izhar
Super 16 Crash Video

Hi Izhar,
Overall the soldering looks pretty good. I would clean up a few of those joints and align the SMD IC to the pads a bit more, but I wouldn't immediately suspect a bad connection to cause that issue. I've annotated the top side of your CPU board with a few notes - the 7805 could use some reflow on the top and R118 seems like it might not be connected, but that probably wouldn't solve the crash.

The important test is going to be to look for 3.3v supply, for which you'll need a multimeter. Before that however you can simply turn the module on and touch the 3.3v regulator (U102) to see if it's overheating. If it is, you have a short from 3.3v to ground, which could be a soldering issue or a bad capacitor.

With the module plugged in and powered, if you probe the VCC and GND pins on the W25Q80DV chip (pins 4 and 8, marked on the photo), you should find 3.3v. With the module unplugged, you can also use continuity test for shorts between any adjacent pins on that IC. Pins 7 and 8 should be connected (as indicated on photo) but the others should be separate.


If soldering is not the issue, it may be time to hunt for faulty components. I've circled the components that are the most likely culprits.
1. The 2n7000 transistors are MOSFETs, which are susceptible to ESD (static shock) damage. If you work in a carpeted room, and/or the air is very dry, or other ESD hazard conditions exist in your workspace, it may be worth replacing these.

2. Electrolytic capacitors - It looks like you are using an import capacitor brand I'm not familiar with. Eletrolytics, depending on their age they could cause a short on the 3.3v line or other noise issues. The module *should* operate fine without c108 or c102, so you could remove them temporarily to test. I can't tell if C102 is oriented correctly from the angle of your photo, so double check that.

3. The LP2950-3.3v voltage regulator. These are pretty robust devices, but make sure it's outputting 3.3v.

Let me know if you find anything interesting!



EDIT: Also, looking at the back of the CPU board I do see some flux residue and debris near the 2N7000 transistors. May not fix anything but it's probably worth cleaning the board with some alcohol and a toothbrush just in case!

[izash]

Thank you Matthew.
The first thing I notice is that the memory chip is getting 3.0V. Is this a problem?

[izash]

Ok. I replaced the 3v version of the 2950 regulator with a l78l33 (the only 3.3v regulator I have in stock).
The mem chip is now getting 3.3V, but the problem persists.
I’ll check your other suggestions now.

[izash]

Hi Matthew,
I did all the tests you suggested, changed the mosfets and checked all voltages, but couldn't find the problem.
I found the schematic on Github and started checking all connections to and from the memory chip.
I discovered that there was no connection between pin 17 of the ATMEGA (MOSI out) and the junction of Q102-R107.
Pin 17 does reach pin 4 of the J101 header but not Q102-R107.
I made a jumper between pin 4 of J101 and Q102-R107.
It worked! the MEM problem is now gone.

I connected the Super16 to my Eurorack system to test it.
Everything works except Pitch!
Super 16 outputs a constant voltage from the Pitch output.

What do you think is wrong?

Thanks again,
Izhar

[extralifedisco]

Hi Matthew,
I did all the tests you suggested, changed the mosfets and checked all voltages, but couldn't find the problem.
I found the schematic on Github and started checking all connections to and from the memory chip.
I discovered that there was no connection between pin 17 of the ATMEGA (MOSI out) and the junction of Q102-R107.
Pin 17 does reach pin 4 of the J101 header but not Q102-R107.
I made a jumper between pin 4 of J101 and Q102-R107.
It worked! the MEM problem is now gone.

I connected the Super16 to my Eurorack system to test it.
Everything works except Pitch!
Super 16 outputs a constant voltage from the Pitch output.

What do you think is wrong?

Thanks again,
Izhar

Tremendous! Nice debugging. Perhaps what looked like flux residue in the previous photo is actually a damaged trace near that transistor. The trace is on the bottom of the PCB so it should be easy to find the break.

For the pitch output, what's the constant output voltage? Does the secondary CV output give any control voltage?

I would start by probing the DAC output directly and see if you get any kind of varying voltage there while a sequence is playing with varying notes. That's pin 8 of the MCP4822 (use the voltage regulator tab as ground). Ideally you'd use an oscilloscope but a multimeter works to see if it's flat or changing at least. If you have varying voltage there, you can test the output of the opamp (pin 1) and the joints at the header connector (lower side of R113/R115). If the data is unchanging, test the integrity of the serial data lines from the DAC to the Atmega chip (pins 2,3,4 on MCP4822).

From there it's a straight shot to the output jack, but it is worth checking the solder joint on the control board header connector as well, it's easy to miss a pin on those and they're in a tight space so hard to notice at first.

[izash]

Hi Matthew,
I checked everything as far as I can, and the connections seem fine.
The 4822 outputs CV on pin 6 which goes all the way to the CV output on the front panel.
There’s no pitch CV output on pin 8.
Could it be a bad chip? Any suggestion?
Thanks
Izhar

[Kerplunk]

Hey Extralife!


I'm unfortunately still having the same problem. I have a 1/16 clock going to the Clock input and a 1/1 clock going to the Reset input but instead of it being synced, there is a double on the first beat. Which is throwing the timing out.

I have sent 2 clocks as gates directly to envelopes, driving one oscillator per , and have not had any issue with timing


The Kick is coming from Ableton, which is triggering the FH2. The FH2 is sending the 2 clocks to both Clock and Reset inputs.

It seems to work fine, if I only send a clock to the Rest input or Just send a clock to the Clock input, but not both...

Any advise would be appreciated...

Ah, what a pain! I just fired up ableton to try to repro this and I'm able to see exactly what you're getting. It seems like the pulse length does matter and it needs to be in a very small range (shorter than the clock pulse but not by too much) in order to work. This is clearly a firmware bug I should patch - I will try to sneak that into the 1.1 release this weekend!

The workaround I suggest (which does work consistently at least) is to have a midi note in ableton *just before* the end of the bar so that it goes out and resets the clock after step 16 but before step 1. You can also put a super-short trigger on beat 1 so that the sequencer starts in time on the first play-through, but this as mentioned is inconsistent. However if you set the clip loop brace to omit that first note every subsequent loop will be accurate. See attached image:

reset clock.jpg

I'm really not sure what happened in the code as I'm fairly sure I tested this exact use case several times without incident, but clearly I overlooked something. The reset input should really only care about the rising edge of the signal but somewhere it's checking the state of the input and misinterpreting the signal. I'll update you when the firmware is amended.

AHA! that makes sense. That's what I was doing with my MPC but thought it was that... Anyhow, I'm glad there will be a solution for it. Now I need to workout how to update the firmware...

Cheers dude

[extralifedisco]

Hi Matthew,
I checked everything as far as I can, and the connections seem fine.
The 4822 outputs CV on pin 6 which goes all the way to the CV output on the front panel.
There’s no pitch CV output on pin 8.
Could it be a bad chip? Any suggestion?
Thanks
Izhar

He Izhar,
Sorry for the delay, just caught your post. That's a pretty unusual edge case! For *one* output to fail on a 2-channel DAC is pretty strange. It could be a bad IC, but the op-amp protects it from stray connections on the front panel. The trace is straightforward and looks fine. I can think of three possibilities:

1. Improperly seated IC / bent pin / bad socket
Remove and re-seat both the DAC and the op-amp. (MCP4822 and TL072). If you were testing on the solder side, test for the signals on the chip side from the legs themselves.

2. Blown op amp shorted to ground.
It could be that the signal *is* there on the DAC but the op-amp is fried and it shorts the signal to 0v. Remove the op-amp and test for the signal on the DAC pin 8 (it will not harm the circuit to run without the IC).

3. Software error/ bad calibration values
If there is some kind of firmware glitch, perhaps it's always sending 0v out as the signal. One explanation would be corrupted EEPROM calibration values. Try entering calibration mode (shift+14) and push the various step buttons to see if you get any different voltage. Maybe it went through an x-ray machine somewhere in customs?

4. Bad IC MCP4822
Could be an ESD damage or a manufacturing defect. The rule in electronics is it's *never* a bad IC except the one time it actually is. Easy enough to replace and find out, but requires another IC of course.

[izash]

Hi Matthew,
I tried the first 3 suggestions, but the problem isn’t there.
I’m going to get a new MCP4822, but it’s probably going to take some time to get here.
If you have another troubleshooting idea, please let me know.
Thanks!
Izhar

He Izhar,
Sorry for the delay, just caught your post. That's a pretty unusual edge case! For *one* output to fail on a 2-channel DAC is pretty strange. It could be a bad IC, but the op-amp protects it from stray connections on the front panel. The trace is straightforward and looks fine. I can think of three possibilities:

1. Improperly seated IC / bent pin / bad socket
Remove and re-seat both the DAC and the op-amp. (MCP4822 and TL072). If you were testing on the solder side, test for the signals on the chip side from the legs themselves.

2. Blown op amp shorted to ground.
It could be that the signal *is* there on the DAC but the op-amp is fried and it shorts the signal to 0v. Remove the op-amp and test for the signal on the DAC pin 8 (it will not harm the circuit to run without the IC).

3. Software error/ bad calibration values
If there is some kind of firmware glitch, perhaps it's always sending 0v out as the signal. One explanation would be corrupted EEPROM calibration values. Try entering calibration mode (shift+14) and push the various step buttons to see if you get any different voltage. Maybe it went through an x-ray machine somewhere in customs?

4. Bad IC MCP4822
Could be an ESD damage or a manufacturing defect. The rule in electronics is it's *never* a bad IC except the one time it actually is. Easy enough to replace and find out, but requires another IC of course.

[izash]

Hi Matthew,
Do you think I should re-install the firmware?
If so, what is the procedure?
Thanks,
Izhar




3. Software error/ bad calibration values
If there is some kind of firmware glitch, perhaps it's always sending 0v out as the signal. One explanation would be corrupted EEPROM calibration values. Try entering calibration mode (shift+14) and push the various step buttons to see if you get any different voltage. Maybe it went through an x-ray machine somewhere in customs?

[extralifedisco]

Hi Matthew,
Do you think I should re-install the firmware?
If so, what is the procedure?
Thanks,
Izhar

Hi Izhar,
I think that's unlikely to fix the issue. Bad EEPROM data would only affect the calibration data and thus the pitch output scaling, but bad flash/nvram data would likely cause a fatal error and result in a non-operable sequencer rather than just a single output glitch. I think the fault is more likely in the DAC or nearby board logic than in the microcontroller.

That said, you may want to flash the firmware anyway as I have just uploaded firmware v 1.1a, which introduces some new features and fixes. You can find the hex file on github, and you will need a USB AVR programmer and the Arduino IDE (or just avrdude CLI) to install it. I will have a video up soon on how to do this procedure, I'm still editing it together now, but if you are set to go, you can find the appropriate avrdude commands here.