Update

Hi crowd,

I’ve just assembled what was meant to be the final version of the Shruthi-1. Unfortunately, there’s a very worrying display bug that will need to be solved by a board revision. The problem was there on the v0.2 board and occurred once every couple of hours, but was still annoying (this was a kind of “monkeys and typewriter” thing). The fix I’ve attempted on this revision makes it worse. Until I find a software fix, this is going to add a further 3 weeks delay to the release.

(For those of you curious about the problem): there’s a line (pin 23 of the ATMega644p) which is used both for I2C communication with the eeprom and for writing to the LCD display. Since there’s no situation when I really need to use both at the same time - I disable the LCD refresh during load or save operations - I never thought this would be a problem.

In the rev 0.2, the two I2C pins were also used for LCD communication. The glitches were very occasional, once every few hours, and they only affected display (missing or glitchy char on display). With the change I made in the rev 0.3, only 1 line is shared, but for some reason I fail to understand, the problem is now worse! Not only I easily get glitchy display in load/save operations, but some of the load/save ops fail.

That’s very unfortunate, Oliver.
In the meantime, have you decided how you will distribute the Shruthi-1? Kit? Assembled? Bare boards? Full kit with case?

Kits for the main (digital board) and the “standard” filter ; bare boards or bare board + chips for the boards based on more exotic chips.

Case will come later, once I’ve recouped a bit of what I’ve invested in the development, and can afford failed Ponoko protos :slight_smile:

if we can help u…

sorry to hear that olivier! frustrating!

ha, i’ll probably just be finishing my shruti midi out bug by the time this rolls around…

Heh, me too - I hope to get my Shruti sorted in time for it to be rendered obsolete by this :slight_smile:

By “bare boards or bare board + chips”, do you mean that there won’t be an option to buy those boards in kit form from you (i.e. the board and all the components to go into them)? Will we just get a PCB (or a PCB and some chips) and have to source the rest of the parts ourselves for the nonstandard filter boards?

@Electrodruid: yes, that’s what I planned to do. It’s going to be a logistics nightmare if I do kits for every board. Also, I want to raise the barrier of entry a bit for the boards with rare chips, to avoid putting too much stress on the SSM/CEM chips stocks. And well, I’d really like to see other people getting into the “Shruthi-1 filter board business”, so it won’t help if I already do everything myself :slight_smile:

I’m going to stick with the same parts for most of the future work on analog boards - 1% metal resistors in the E12 series ; 4.7uF NP caps, poly/film caps in 1.0, 6.8, 22 and 33nF values ; 100nF and 100pF ceramic caps ; TL074s, LM13700s, SSM2164s ; 5k trimmers. With an army of that you could do any the boards that will follow :slight_smile:

On the positive side of things, the revised PCB layout makes the assembly 3mm flatter

Don’t worry about the delay Olivier - you’re already about 100x faster than most other developers in bringing new features/products!

… and we have many things to discover with actual shruti-1 I continue my live with it and each night i discover new sound and new possibilities It’s an amazing synth. And the mix with other synth like tb303, sammish sid and other big analog synth is perfect !
Really :slight_smile: !

Today I removed the LCD screen from the board and totally deactivated it from the code - thinking that the problem was due to the sharing of some port between the LCD and the I2C eeprom. Unfortunately, the data read glitches are still there, so there’s something faulty either with my assembly (possible), the layout/routing (?) or with my code. Will try to swap chips too. It’s very odd, because the very simple thing I did in the previous revision worked. I’m going to assemble a new board tonight or tomorrow to rule out the assembly error theory. In last resort, I’ll revert to the previous design, with only one minor adjustment, and will fix the occasional display glitches in software by forcing a full display refresh every second.

I think I’ve nailed it

I’ve been frantically browsing through the patch list trying to cause glitches. The problem seems to be fixed. Hooray! Had a theory about the problem, did the experiments to confirm. I’ll let the layout of this one marinate a bit in my head and assemble the “release candidate” of the filter board to see if it also needs corrections, and hopefully I’ll order the new boards by the end of the week.

Culprit: my two previous designs used the 644p internal pull-ups to pull the I2C lines, and it worked, but it was more a matter of accident/coincidence than a very sane thing. Final board now has real pull-ups, and I2C lines are not used for anything else (since the pull-up cannot be switched on/off). A drawback of the fix: I had left in the previous designs the second UART unconnected for hacking/future extension. I’m now using its RX pin as a GPIO (which was previously “shared” with the I2C lines). But there’s still a free TX to tickle smrl’s digital delay.

Any idea why the internal pullup would behave differently than ‘real’ pullups?

From the datasheet, the value of the internal pull-ups is around 35k. The maximum transmission speed varies in 1 / (pull-up value x line capacitance of the connection between the eeprom and ATMega). I haven’t found much info about trace and via capacitance, but I suspect that the capacitance of the the 6cm or so of traces on my layout + a via is enough to make it sensitive to the resistor value, and to make 35k only relevant to slow speeds. Actually, I could make the version without pull-up work more reliably (but not perfectly) by lowering the transmission speed to 2kHz. But this doesn’t meet my goal of “scrolling through patches/sequences should have as little effect on the playback as possible” (100 bytes of patch data x 2 transmission overhead x 8 / 2000) = 0.8s to load a patch ; which is almost 100 times the maximum duration an I/O operation can take without causing audio glitches (I have a larger buffer on the Shruthi).

I’ve soldered 3.3k pull-ups and problems disappeared instantly. Cut them back: glitches and crashes. Brought them back: fine.

I got a nice mix of fm/organ patch when the glitches occurred, though! So maybe I could sneak in a “randomly hybrid current patch with a preset” feature…

Love the open synthmaking process.

My eyes always glaze at some point, but I’m cheering by the end.
These threads are like short stories of trial and tribulation.

Looks great! Maybe put a more obvious pin1 indicator on the ISP header? Almost looks like that little white dash might become hidden…