A Couple of (Stupid) Questions

[angiamusic]

Hello!

First of all, thank you so much for this project! It's always lovely to see more and more Mutable designs being adapted to THT, especially for amateurs in SDIY like myself.

I had a couple of questions if you didn't mind:

1. Is this project actually complete and ready to get PCBs made, or is it still WIP? I ask because I haven't been able to come across this elsewhere and only stumbled upon it through the "eurorack" topic on Git.

2. Will the Printable Instruments Frames panel work with this, along with any other Frames panel, or does this require it's own panel design?

3. Is there an official BOM? I was able to gather one from the kicad files, but I would like to know if you have an official one in case there are amendments that I missed.

Thank you for your work, and I look forward to this as my next project!

Aditya

[30350n]

Hey!

Sure, I'll try to answer them as good as I can:

1. This project is basically complete, I already ordered a first batch and assembled it. There were some minor issues which I fixed (see https://github.com/30350n/tht-frames/commit/59306a8ae20bcc9e90746306323c4285c5344e31, https://github.com/30350n/tht-frames/commit/50d177925b66d5548b39c43762f530c301673435, https://github.com/30350n/tht-frames/commit/25838d59e854389ca7136ca0f5d0b7b73fe9cf8d).

2. This should fit any standard Frames panel, including the printable-instruments ones of course. (I'm using those myself, ordered them in the same batch and they fit perfectly).

3. I haven't found time to put together a proper bom, you should be able to generate one in KiCad though. Parts should be fairly standard/have standard packages, the most important thing is that you get a STM32F103CBT6 with 128kB of RAM.

If you actually build this, make sure to share your experiences! And if you run into any issues along the way, just ask me here or via discord (Bobbe#8552).

Thanks a lot for checking out the project!

[30350n]

Two more things I forgot:

• This requires slightly modified firmware, because it's using a different dac. I also haven't had the time to upload that here, but I'll probably do that in the next week or so.
• Contrary to an original Frames, this variant requires a 5V power rail.

[angiamusic]

Thank you for your reply! I am getting PCBs manufactured currently, after having built the THT Braids I'm really looking forward to starting this build. :)

Hope to see the modified firmware soon too.

[30350n]

Just added a software patch, aswell as some more information to the README and a release containing a pre-compiled .hex file. ^^

[pierstu]

Hello, i'm about to send the pcbs to fab too! Thanks for this project. I'm having an error when trying to compile Parasite for Frames tht

• patched the .patch file to eurorack-modules (which applied to frames/drivers/dac.cc and dac.h)
• copied these files to frames-parasite/drivers
• bootoader compiled successfully
• tried to compile the Parasite firmware make -f frames-parasite hex

build/frames-parasite/startup_stm32f10x_md.o: In functionLoopFillZerobss': (.text.Reset_Handler+0x2e): undefined reference to main' collect2: error: ld returned 1 exit status make: *** [build/frames-parasite/frames-parasite.elf] Error 1 vagrant@vagrant-ubuntu-trusty-64:/vagrant/eurorack-modules$

Win 10 last week update, vbox 6.1.16, vagrant 2.2.14 Anyone could guess better than me whats going on?

Thanks for this great project @30350n, hope we'll have more and more of these Mutable tht ports

[30350n]

Hey! Thanks for checking out the project. I actually didn't knew a parasites firmware for frames existed, but I just tried to replicated your issue and well ... this has been quite a bumpy road... ^^

Two questions:

• How did you add the parasites firmware exactly?
• Where does the frames-parasite makefile come from?

Regardless, this is what I just did to get it working:

1. setup the mutable-dev-environment normally, with the default eurorack repository
2. add the parasites repository as a remote and checkout it's master branch (this might require you to create a second, local "parasites-master" branch)
3. go into the stmlib folder/submodule and checkout the master branch of the original repository (this was necessary for me, because it otherwise tried to call the compiler from /usr/local/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-g++ instead of /usr/local/arm/bin/arm-none-eabi-g++ (this could probably also be fixed by properly installing that version of the toolchain, but I didn't bother))
4. apply the tht-frames.patch from this repository and build the code via make -f frames/makefile hex

Note: I actually use make -f frames/makefile upload, without a connected programmer (because that generates the frames_bootloader_combo.hex) and then flash it manually via the STM32CubeProgrammer utility on Windows.

[30350n]

Here's the hex file btw, if you don't want to mess with building it yourself. ^^

[pierstu]

Thank you! I downloaded the Parasite zip from github, renamed the frames folder to frames-parasite and pasted it into the eurorack folder. I often rename the target dirs in the makefiles to get a corresponding output in the build folder, so it's more clear. Thanks for the build anyway !

[30350n]

Ah okay, maybe the renaming somehow messed up the linking process. ¯_(ツ)_/¯

[ijnekenamay]

Hello! It appears that the specified microcontroller (robotdyn) is currently out of stock. It seems that 128kb blue pill is a kind of mutant and hard to find in the market. Is there any store where I can easily get it now?

[30350n]

Yeah, 128kb blue pills have pretty much become complete unobtainium in the last year and a half or so. Normal 64k ones are still available and i've heard of people being lucky and getting 128k variants when buying 64k variants, but it's a gamble. I'm not really sure where I'd get one at this point in time either, sorry :/

[Genmaizen]

Hi Bobbe, I´m TL1A from Kristian´s Discord server. I built your THT-Frames yesterday. The PCBs look very nice and it was easy to solder all the parts (sourced most of them from TME.eu). I used an AS2164 (electric druid) instead of the V2164.

Unfortunately, the Frame animation acts erratic. I try to explain it in the following using the walkthrough example from Emilie:

• Frame 1: After first power-up (or reset) the FRAME knob is white and the keyframe indication LED is off. Pressed the ADD button. Set the first attenuator knob to maximum level, and second to its minimum level. The FRAME knob is illuminated in red and that the keyframe indicator is also lit.
• Frame 2: Rotated the FRAME knob to its medium position (12 o'clock). Pressed the ADD button. Set the first knob to its minimum level, and second to its maximum level. This second keyframe looks orange.
• Frame 3: Rotated the FRAME knob to its final position (5 o'clock). Pressed the ADD button to create the last keyframe in the animation. Set 1st and 2nd knob to medium levels. This third keyframe is given a yellow colour.

The above three steps behave normally. But now when moving the Frames knob back and forth there is no animation like programmed. The LEDs 1 and 2 lights somehow get dimmer, but do not go out when they should and eventually light up fully and stay like that. The VCO sound (saw and square) moves in loudness like indicated by the LED 1 and 2 indicators. The keyframe indicators and the FRAME knobs behave like that:

• Frame 1: The keyframe indicator lights steady and the FRAME knob flickers
• Frame 2: The keyframe indicator as well as the FRAME knob flickers
• Frame 3: Both indicator lights are steadily on.

It get´s even stranger when I move the Attenuator knobs. Then the LED 1 and 2 also begin to flicker and the saw and square wave sound changes to a high pitched noise. This behaviour changes a bit when moving several times through the Frames. Also, when powering up without reset or after the second powerup the flickering already starts after setting the first Frame. I also noticed that different STM32 act differently - more or less flickering, distortion or eratic behaviour. To sum up, in principle the Frame animation acts erratic.

Troubleshooting:

• Inspected all soldering with magnifying glass and multimeter for shorts. Looks ok.

• The resistors and caps are correctly placed. I measured them in order to match the values as precise as I could (UNI-T UT61E multimeter).

• A reset with the DEL button (5 sec) does not help with the problem. It is reproducible in that the animation acts erratic.

• Change of STM32 did not help. All STM32F103C8T6 are 128 kb and verified to work with Beaks and Braids.

• Used two different ST-Links V2 with either STM32CubeProgrammer or STM32 Utility.

• Kristian mentioned differences in GND and 3.3V layout of the STM32. I have ...B8, B9, 5V, GND, 3.3

• It is interesting to see that the code on the STM32 changes after it was installed in the Frames (I compared the installed code with the hex file). But initially of cause the code is identical with the hex file. I compared the code with STM32 Utility. Seems to be normal behaviour?

• I removed all ICs except for the three TL072s. The problem is still there (flickering lights…). I suppose this should mean that the problem is not due to the ICs (except for TL072s).

• When removing also the TL072s the lights on the Attenuator knobs go out (except for the first).

• I replaced the TL072s (TME.eu) with TL072s from two other sources (AliExpress and LCSC). This did not help. But I had the impression it somehow improves the flickering a bit at first, but not longterm. They did not get hot.

• All pins from the TL072 socket holders on the PCB are connected well to the chips (multimeter test).

• When leaving frame programming untouched, the analog attenuation and mixing works well

Well, that is about it. Sorry for the long read. I am out of ideas what to test further… But yeah that´s the DIY way 😊 Do you or anybody have ideas? Thanks very much!

[Genmaizen]

Calibration (holding DEL button when powering up) does not solve the issue. I also loaded the parasites firmware on the module just for testing the calibration because for this firmware the above calibration method is explicitly described. Also this did not solve the issue. On Modwiggler I read that some people have similar problems, although with the original MI Frames: https://www.modwiggler.com/forum/viewtopic.php?p=3820306&hilit=frames+calibration#p3820306

[Genmaizen]

I used an LM4040BIZ-10NOPB for the 10 V reference. At the offset pins I measure 5.742 and 11.228 Volts. At the LM4040BIZ itself I measure 11.542 Volts. Is that a clue?

[30350n]

The flickering sounds like a power issue or issue with the mcu, as these are directly driven by it (via PWM probably).

I also noticed that different STM32 act differently - more or less flickering, distortion or eratic behaviour.

This also makes me think it's just a defective/out of spec bluepill module, I'd probably try replacing that.

I used an LM4040BIZ-10NOPB for the 10 V reference. At the offset pins I measure 5.742 and 11.228 Volts. At the LM4040BIZ itself I measure 11.542 Volts. Is that a clue?

That's definitely not right and either sounds like your LM4040 is defective, not soldered properly or just really out of spec. The B variant should have a +-0.2% tolerance, so pin 1 should be off by 20mV at most. Where did you get it from? That being said, It isn't directly connected to the mcu, so it shouldn't have any effect on the flickering issue.

[Genmaizen]

Thanks very much for your comments!

I bought the LM4040 at tme.eu. I tried to somehow measure another one out of this batch, but it is not easy to build up the test circuit for that because one needs a load on the LM4040... I also was a bit confused concerning the pin description in the schematic. 1 is cathode and 2 is anode. 1 and 2 should mean Pin 1 and Pin 2 of the LM4040? However in the LM4040BIZ-10NOPB documentation Pin 1 is anode and Pin 2 is cathode. Is this something?

[30350n]

Hah! Yeah okay, the LM4040 is on me, seems like I swapped the pins and never even noticed ... Welllll, I should probably fix that at some point 😅 .

[Genmaizen]

Wohoooo, I contributed 😉

Anyhow, do I understand it correctly that this is just a schematic designation issue and not a PCB problem. So I don´t have to cross the legs of the LM4040 on the PCB? That means, the silkscreen shows the correct orientation of the LM4040.

[30350n]

No, it is a PCB problem, but it shouldn't matter much. If you want the offset to work correctly, you should solder it like this.

[Genmaizen]

Cool, thanks! I can confirm that after soldering the LM4040 like shown above, the offset is correct. 👍