1
preenfm2 and preenfm3 / Re: LCD display connector
« on: February 03, 2018, 06:05:35 PM »
Can someone please post a sideways picture of their PreenFM2? Like the one I've posted above.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
preenfm2 and preenfm3 / Re: LCD display connector
« on: February 02, 2018, 09:03:57 PM »Have a look at the bom and at the LCD case in the github folder :
https://github.com/Ixox/preenfm2/tree/master/hardware/case
It's still not very clear but I can see your spacers are 8mm while my screen sits now at 10mm.
Switching the socket to Augat type will probably give me that smaller gap.
This also means that my buttons caps are too low (probaby need to glue another one on top) AND the encoder knobs are too tall - need to get the ones from your BOM or use my router to remove some plastic from the current ones.
For the cases I think I'll use the green 6600 acrylic because it's a dark green and still has about 27% transparency.
3
preenfm2 and preenfm3 / Re: priority bits
« on: February 02, 2018, 08:49:23 PM »
Setting the sub-priority in the above context can be considered a (harmless) bug. It's at least confusing when you read the code so I think it's worth placing a zero or remove the lines initializing the sub-priority.
4
preenfm2 and preenfm3 / LCD display connector
« on: February 02, 2018, 04:10:54 AM »
I was looking into building some cases for my PreenFM2s and I don't know how to solve the problem of the LCD display height. Now I have a normal ".1 header male and female and that's quite high. Even if I replace it with the Augat type (see picture) I'll only be able to lower it about 1mm and it needs to be flush with the buttons and that's 8-9mm lower. The only option I see is to solder the LCD header permanently to the main board.
I could raise the buttons (by using a different cap or by gluing 2 caps above each other but I can't raise them too much because they are limited by the encoder knobs.
How did you solved this problem. Are your LCDs much thinner than mine?
I could raise the buttons (by using a different cap or by gluing 2 caps above each other but I can't raise them too much because they are limited by the encoder knobs.
How did you solved this problem. Are your LCDs much thinner than mine?
5
preenfm2 and preenfm3 / priority bits
« on: February 01, 2018, 01:39:26 AM »
In the git code I've noticed that __NVIC_PRIO_BITS is not defined so it stays at its default value of 4
This means 4 bits for the PreemptionPriority and none for the SubPriority
Then in various places in the code both ChannelPreemptionPriority and ChannelSubPriority are
initialized with non zero values. Obviously the ChannelSubPriority has no effect and stays at zero.
One only needs sub-priority when several interrupts with the same preemption are pending then the
sub-priority decides which one is served first.
This means 4 bits for the PreemptionPriority and none for the SubPriority
Then in various places in the code both ChannelPreemptionPriority and ChannelSubPriority are
initialized with non zero values. Obviously the ChannelSubPriority has no effect and stays at zero.
One only needs sub-priority when several interrupts with the same preemption are pending then the
sub-priority decides which one is served first.
6
preenfm2 and preenfm3 / Re: PreenFM2 encoders
« on: January 30, 2018, 07:59:20 AM »It's at least 6 or so by my really crude testing.Thanks for your testing. I've got that too now, between 6-8 steps per second without skipping. Turned out I just had to be more aggressive with my timing. 8ms high followed by 8ms low is considered a step and works fine.
7
preenfm2 and preenfm3 / Re: PreenFM2 encoders
« on: January 26, 2018, 02:00:34 AM »
No one? This wasn't a difficult question though. Just let me know how fast can you turn your encoders while still registering steps.
8
preenfm2 and preenfm3 / Re: PreenFM2 SMD version
« on: January 26, 2018, 01:57:48 AM »
I have updated my project's page with real oscilloscope captures from the DAC and the line output if anyone is interested.
I've also redesigned the headphones amplifier for an eventual future version.
The PCM5102 performs very well and with its dynamic range of 112dB it has effectively 19 bits of precision (so I'm sending 24bits in 32bit frames per channel). If we compare this with the MCP4922 we can already see a big improvement. The 12 bits of the MCP4922 have a typical cumulative nonlinear error of +/-2LSb but this can go up to +/-12LSb. Then there is an abrupt nonlinearity when the 2 DACs are connected together; even with the 1% tolerance for the 1.8K resistor, 1% is equivalent with another resistor of 180K injecting current into the node, and that's almost as the entire contribution of the second DAC via the 155K resistor.
I've also redesigned the headphones amplifier for an eventual future version.
The PCM5102 performs very well and with its dynamic range of 112dB it has effectively 19 bits of precision (so I'm sending 24bits in 32bit frames per channel). If we compare this with the MCP4922 we can already see a big improvement. The 12 bits of the MCP4922 have a typical cumulative nonlinear error of +/-2LSb but this can go up to +/-12LSb. Then there is an abrupt nonlinearity when the 2 DACs are connected together; even with the 1% tolerance for the 1.8K resistor, 1% is equivalent with another resistor of 180K injecting current into the node, and that's almost as the entire contribution of the second DAC via the 155K resistor.
9
preenfm2 and preenfm3 / PreenFM2 encoders
« on: January 23, 2018, 08:22:56 AM »
Since I don't have a PreenFM2, I don't know what to expect as behaviour for the rotary encoders. Can someone please let me know how responsive they are?
The best I've obtained on my PreenFM2 version is about 4 steps per second with reliable detection and no back-skips. I've improved my detection as much as I could and the software is supposed to catch up to 25 steps per second but I don't think these encoders can handle that kind of speed (at least the ones that I have).
Is 4 steps per second acceptable or are your encoders better?
The best I've obtained on my PreenFM2 version is about 4 steps per second with reliable detection and no back-skips. I've improved my detection as much as I could and the software is supposed to catch up to 25 steps per second but I don't think these encoders can handle that kind of speed (at least the ones that I have).
Is 4 steps per second acceptable or are your encoders better?
10
preenfm2 and preenfm3 / Re: PreenFM2 SMD version
« 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.
11
preenfm2 and preenfm3 / Re: PreenFM2 SMD version
« 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.
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.
12
preenfm2 and preenfm3 / Re: PreenFM2 SMD version
« 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.
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.
13
preenfm2 and preenfm3 / Re: PreenFM2 SMD version
« 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.
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.
14
preenfm2 and preenfm3 / VolcaFM as development platform for PreenFM
« on: January 16, 2018, 08:48:33 AM »
I am in the process of adding note velocity on my VolcaFM and while I was reversing the schematics I couldn't stop noticing similarities with a PreenFM2.
MIDI Keys Velocity for Korg VolcaFM
Both devices use an ARM Cortex-M4 so the PreenFM2 firmware could be ported (in theory) to a VolcaFM. Of course the original code will be lost
forever. The Volca uses a companion processor to read the touch keys and the protocol could be quickly reversed by hooking a logic analyzer on the SPI connector. The Volca doesn't have a nice screen, only a 9x7-segment display and neither it has the USB connectivity or pen drive interface. Instead is has a stereo 24-bit DAC.
What do you think; is it worth the effort to port this firmware to a Volca?
The Volca's firmware can be updated via an audio file played from the computer. I'll have a look in the future to see if that can be reversed so we could save the original firmware. Or maybe they've forgotten to fuse protect their Spansion FM4 processor.
MIDI Keys Velocity for Korg VolcaFM
Both devices use an ARM Cortex-M4 so the PreenFM2 firmware could be ported (in theory) to a VolcaFM. Of course the original code will be lost
forever. The Volca uses a companion processor to read the touch keys and the protocol could be quickly reversed by hooking a logic analyzer on the SPI connector. The Volca doesn't have a nice screen, only a 9x7-segment display and neither it has the USB connectivity or pen drive interface. Instead is has a stereo 24-bit DAC.
What do you think; is it worth the effort to port this firmware to a Volca?
The Volca's firmware can be updated via an audio file played from the computer. I'll have a look in the future to see if that can be reversed so we could save the original firmware. Or maybe they've forgotten to fuse protect their Spansion FM4 processor.
15
preenfm2 and preenfm3 / Re: PreenFM2 SMD version
« on: January 16, 2018, 08:31:59 AM »
I haven't done any more testing but I've taken some pictures of the soldered boards. A few things I've noticed: the buttons caps that I have are way too low (they dont reach the screen base). Only one DIN connector fits comfortably at the back; a second will have to have its pins trimmed to fit in the back. but I have 2 more so I think I'll put all the DIN5 connectors on the sides.
The boards are still covered in flux; I haven't cleaned them yet.
The boards are still covered in flux; I haven't cleaned them yet.