Recent Posts

Pages: [1] 2 3 ... 10
PreenFM2 / Re: PreenFM2 SMD version
« Last post by matrix12x on Today at 01:18:47 AM »
I'm really excited by the progress.
PreenFM2 / Re: PreenFM2 SMD version
« Last post by Xavier on January 21, 2018, 02:25:26 PM »

Impressive soldering skills !!!  :o
Nice pictures....
PreenFM2 / Re: PreenFM2 SMD version
« Last post by alien_brain on January 21, 2018, 02:11:46 PM »
golly thanks for that i guess.  btw white oleds are just as bright.  im not a technical guy but my tech has white oleds in his yamaha fm synths like tx802 and tx81z that are just as bright as any other color i have seen anywhere.  so...  nows your chance to be vain i guess.  whats wrong with white oleds?  it would certainly make a statement.  what a pity that you dont care.  oh well,  i guess the only thing your design has that i want is 4 outputs.  but even then im not sure that means very much unless you cant afford a second synth...
PreenFM2 / Re: PreenFM2 SMD version
« Last post by zelea2 on January 21, 2018, 09:39:01 AM »
hey do you think you could find out why the white oleds are not shining as bright when swapped in and do the necessary changes?

OLEDs are a vanity thing, I'm just interested in functionality. Yellow ones are always much brighter than the white ones - it's a construction feature. All the ones I'm building use plain green-yellowinsh LED backlight. The difference is the price 5$ compared to 35$. The screen can be swapped with ease anyways.
PreenFM2 / Re: PreenFM2 SMD version
« Last post by alien_brain on January 20, 2018, 07:27:08 PM »
all pretty exciting!  hey do you think you could find out why the white oleds are not shining as bright when swapped in and do the necessary changes?  im very excited to use one of these when you have them ready.
PreenFM2 / Re: PreenFM2 SMD version
« Last post by zelea2 on January 20, 2018, 05:18:53 AM »
More problems fixed:

I've solved the digital volume and now it works beautifully with a logarithmic scale. I was sending the potentiometer bytes in the wrong order.

One of the audio channels was bearly audible. I've traced that to 2 mislabeled references of 2 caps. I've switched those and everything is fine.

I'm thinking of redesigning the headphones amplifier for a further revision. Separate 78L05 supply, MC33204 OpAmps (couldn't use LM324 because it's not rait-to rail) for mixing the 4 channels and provide proper separation and LM4880 as 200mW/channel amplifier. I've already done the simulation.

I haven't tested MIDI yet but I don't expect any surprises there.

I'm still struggling with the encoders. I can't get rid of that extra step in the wrong direction when they are turned fast. If I mask the inputs longer than 15ms then I'm missing steps, shorter and I have the jump backwards. The question is do I have some particularly noisy encoders or are my algorithms bad? Right now I'm triggering on the falling edge of one input, masking further interrupts with times and I'm examining the state of the second input for the last 15ms. How is your experience with the encoders on the current design? The switches on the other hand are perfectly debounced.
PreenFM2 / Re: PreenFM2 SMD version
« Last post by zelea2 on January 19, 2018, 06:46:38 PM »
I can confirm that there is no noise at all on the jack outputs; I'll make some scope captures during the weekend.

The headphones amplifier needs a redesign. The idea of mixing 2 channels and then amplifying it almost 100 times with no proper dedicated supply is bad. Probably the best way is to choose only 2 channels instead of 4 and reduce the voltage gain considerably. Other option is to use a cheap LM324 to mix them and then use another phones amplifier IC and use a dedicated power rail for it.

For the current boards the headphones schematic is compromised and I'll have to desolder that part of the circuit.
PreenFM2 / Re: PreenFM2 SMD version
« Last post by zelea2 on January 19, 2018, 07:56:38 AM »
After another 10 hours of coding I want to report some good progress:

I've got the inter processor communication working. This was tricky because the F4 is the SPI master and the F1 raises an interrupt wire when any of the switches or encoders change state. For the F4 this transfer is transparent, everything is done by the DMA at both ends and after the 32bit transfer it can process the new input whenever it likes. There are also some commands which change parameters like the max volume and interrogation commands like the firmware version. So the F1 must start a DMA receive but if a key/encoder is pressed it must abort the current DMA (because the first word is already loaded in the SPI register) and start a new one with the new info. This allows the information exchange in just one 32bit transfer.

My encoders can send +/- 7 steps but regardless of how fast I turn them the max was +/- 2 steps. Also the detection algorithm for the encoders should be improved (now I'm basing this on just one sample) because I get the occasional step in the opposite direction.

Also my note generation works. I get sine waves on all outputs but I have a horrible super-imposed noise in my headphone amplifier. I have to admit that I haven't put a scope yet on my boards and my only detection method was a pair of headphones. I can also hear the microcontroller running in my headphones so this is bad. I hope that the only culprit is the headphones amp which was a bit of an afterthought. This is powered by the general 5V line and connected to the digital ground (instead of the analog ground as the rest of the audio path) while it has a 39db gain! I might have to scrap this and use only the jack outputs.

The wave generation is using 48KHz sample rate on all 4 channels and all transfers are DMA. I get a half way transfer interrupt and I'm filling the other half of the buffer based on a precomputed sine wave table and the desired frequency.

What's not working is the digital volume (haven't investigated why), haven't checked the purity of the sine waves with a scope and I get a very rare hangup of the surface processor so there's still a bug in there. Another bug is also lurking in my F4 code which manifest itself only when I'm compiling as a release, the debug version works fine. So programming still required.

All in all I'm very pleased so far because all the audio chains are working at least up the output of the DACs and the processor spends most of the time sleeping in the main loop.
PreenFM2 / Re: new matrix destination
« Last post by lokki on January 19, 2018, 12:54:22 AM »
haha perfect! yes for once i did look in the docs and not in the synth, since i was not home...
PreenFM2 / Re: new matrix destination
« Last post by Xavier on January 18, 2018, 10:00:35 PM »
You have RelC that modifies all "carrier" envelope releases and RelM that modify all "modulator" envelope releases.

I know i have to update the doc  ::)
Pages: [1] 2 3 ... 10