like @everNoob, I’ve also had a go at getting a quote for PCBA service from JLCPCB. There are a few things to be done, but they are do-able. Before I order a run though, I’d like to finalize the design, and do one more prototype run for testing. For that I’d like to pose a couple of questions to those interested in a module like this:
MIDI - Does anyone see a strong use case for MIDI in? It opens up the possiblilty of parameterization beyond the front panel, but doesn’t fit well to the modular ethos of “do one thing and do it well” There would be space for two more CV inputs, or the two DAC outputs if I were to get rid of it…
OLED Display - I don’t like menu-diving, and swiss-army modules require mental gymnastics to operate (I’m looking at you Disting…). But the goal of this module, similar to the Patch, is not to fulfill a specific function, but to allow for experimentation (or for myself specifically, to better learn DSP). In this context a little bit of feedback can be invaluable, plus the .49" display fits so conveniently, I tend towards keeping it.
SD-Card slot - I think I might be able to fit an vertical SD card slot into the design. This opens up a pretty wide range of possibilities, but also smells a bit like feature creep.
Please feel free to give your opinions, I hope to get a new prototype fabricated by the end of the week.
MIDI - yes. MIDI changed music generation, why go back to the 70s ?
OLED - yes.
SD-card - not on the front panel. But would be nice to be able to reprogram the Daisy from the front panel. Problem is you need the reset and boot pins as well as the USB or UART pins, which gets complicated.
While I can appreciate the wish for bringing the USB port to the panel, this is just too complicated. Anyhow, I see the USB firmware upload mechanism for folks who aren’t developing, but flashing pre-compiled firmware, and probably not too often. Anyone who is actually developing firmware will want access to the debug pins.
Now the features are set, I’ll try and finalize a hardware design and order a final prototype soon.
Heya! First off, woah! What a cool project; looks great!
Looking at the TDM format as shown in the Datasheet, it looks like this would be totally possible. Depending on the Peripheral architecture of the teensy, it may not be trivial to port the driver, but SAI2 can be configured for 8 slots of 32 bits (256 bits total per frame) for each channel. The limitation being that it can be a maximum of 256 bits in a frame.
Setting up that configuration shouldn’t be too hard, and then it looks like either SPI or I2C can be used to control the codec.
This project is very exciting, that’s exactly what I was looking for or considering to make. The form factor (and being a kit) are much better than a Patch to me.
My current attempt was to get a Radio Music PCB + Panel kit just to use the front board on top of the Daisy Seed. It works well for the audio out (but only mono) and the knobs, but then things get more complicated about the switch (pulldown design, works but noisy) and the analog vs. digital 3V3 confusion, not even talking about the CV inputs…
About the bluemchen, ideally I’d love to be able to repurpose the audio IN into CV IN when needed (a jumper somewhere for the DC coupling?)
If/when anyone wants to share a PCB/BOM/SMT assembly batch I’m in for a few units
I was also hoping to make this possible, but it is not due to a design decision Electrosmith made with the seed. The codec they used has a digital high pass filter on the ADC side which cannot be disabled in software. I made mention of this a while back here:
I’m currently waiting on my second revision PCBs to be delivered. I hope to populate and test this revision in the coming weeks. If all goes well, I plan to offer a few DIY kits with parts and through-hole only soldering soon after. I’ll be updating this thread with my progress, so stay tuned if you’re interested.
On the DC coupling thing, perhaps the ability to re-route the audio IN signal conditioning to ADC of the Seed via jumpers would make some sense to offer more modulations for synth-ish applications (no need for extreme accuracy). But even without that the project is very appealing for sure.
Not sure I understand your suggestion - maybe a schematic. But anyway if people want to read DC signals with the audio ADC, one possibility is to set up a free running timer on a GPIO and drive a chopper transistor. Google for “chopper stabilised op-amp” from back in the days when a 741 was state of the art and you’ll find all the theory on this.
The +/-500mV (aka 1Vpp) is from a 10Vpp signal. The AK4556 clips at about 2.1Vpp, so this allows for about 6dB of headroom. That covers pretty much anything within the Eurorack rails, minus diode drop, etc. (about 20Vpp)
There are some interesting ideas here for getting DC and low frequency signals into the digital realm, but they seem (to me) to make compromises in order to get there.
This seems like a good idea for DC and low frequency signals, but would it not limit the upper bounds of the usable bandwidth to half of the chopper frequency? Additionally the chopper frequency would theoretically be limited to at most, half the codec sample rate, right? If I understand correctly, this means you’d need to disable the chopper in order to use the codec channel for audio purposes.
Indeed, this allows you to sample the signal at frequencies down to DC using the ADC of the STM32. In a space constrained design, this is interesting as it essentially allows for the re-purposing, or even simultaneous use of an input jack in software. But you’d also have an upper bound on the usable bandwidth unless you sampled the ADC of the STM32 at the same sample rate as the audio codec.
Both of these ideas though, require treating DC/low frequency signals different than higher frequency (lets say >10hz) signals in software. In the analog realm of modular synths, this distinction is not nearly as strict. I’d find it more intuitive to have access to codes at DC, low frequency, and high frequency inside of the AudioCallback at the audio sample rate. I think that would make for some creative modulation possibilities.
All of this is only really relevant when dealing with a “platform” type module like the Patch or the kxmx_bluemchen (or the Disting, o_C, etc.), where the hardware defines the constraints of the software you flash to it. Otherwise, you’d typically design for your goal function anyhow, turning these kinds of compromises into decisions.
Specifically to the kxmx_bluemchen, I’m not considering any of the above mentioned workarounds. If a future revision of the Seed supports reading DC/LF signals with the codec, that’s cool, otherwise it’s just another constraint to consider when writing the software you’d like to flash to it.
@recursinging : yes that’s a correct understanding of using a chopper. But as it’s software controlled, just stop the chopper if you want full bandwidth audio to pass through. I can’t think of any signal that is full audio bandwidth and needs a DC component - in fact DC is what you need to get rid of in most audio signals. Modulation frequencies tend to be less than a kHz or two at most, usually far lower.
I’d also not support changing the Daisy Seed as once you enable DC into audio ADCs you often get all sorts of biasing problems, which will cause more hassle than it solves for less experienced users. This is why the defaults on audio ADCs are usually HPF enabled.
Surely it requires DC or full audio bandwidth. For CV operation you obviously need DC, but the Daisy does have several ADC inputs which can sample at 16 bits/3.6Msps so no problems there.
For FM synthesis you could use the ADCs with some additional circuitry, but it is probably easier to use the audio input. But if the modulation signal has a DC offset then the carrier oscillator will be offset from the proper frequency and so the results will not be harmonically related. But if this is what you want then the same effect can be simulated by adding a DC input on an ADC (or a software constant) to the audio ADC.
In any case for normal operation we need to ensure the modulation and carrier are harmonically related, so they really should both be generated on the Daisy so they are using the same clock, otherwise the results are going to be a bit unpredictable.
To the left and right of the pilot tone you might notice the dozens of noisy little spikes, each one poking a little hole in my ego, and letting my motivation drip out the bottom.
I spent a few hours isolating things to track the problem down. I’ll spare you the gory details and just share my solution; I soldered a 24 gauge wire between the Seed AGND, DGND pins, and the Eurorack Power GND pins. This is what I got:
Notice the scale of the graph… Blissful silence (well almost).
OK, so I kinda sorta suspected this might bite me in the ass. In order to keep the back PCB at two layers, I had to route the GND (AGND & DGND) nets around the board using traces, as the routing is far too dense for any substantial contiguous copper areas. Sadly, it seems that workaround just won’t cut it for the Daisy.
I see two possible solutions to this problem:
Change the back PCB to a four layer design with proper GND planes.
Re-design the front PCB (which is much less dense) to have generous, contiguous GND copper areas, which should effectively do the same job as the jumper wire currently.
#2 is the most economical solution. Four layer boards cost about 5x as much a two layer boards, even if they are now cheap enough to not be considered a barrier of entry. Relying on the front PCB also means the back PCB can’t effectively be used without it, something nobody outside myself probably cares about.
In conclusion, it’s getting there, but I’ll need to do another revision to get this sorted out.