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.

Messages - mario

Pages: [1] 2 3 ... 6
I have a box to fit the board in. My plan is to add a some stuff on the outside, like springs or a kalimba.
Sounds good!

A knob to dial in the channels directly would be my preferred mod.
I can add this to the next firmware version, it's a very simple modification.

Diodes: It sounds like I don't have green, then. On startup there is only red and blue flashing, then the switches to purple.
While I test every board before shipping, things may happen during transport or use - if this bothers you, feel free to ship it back and I'll fix it or replace for new board if it cannot be easily fixed.

I got the DIY set that came without the expansion board. Do you still sell those?
Well I did not officially release that board as it has a small error in it (one resistor needs to be soldered sideways, if you look closely at this picture maybe you will find it - it is marked "100k"). And I did not have time to revise this and order flawless PCBs. You can have one of these experimental boards if you want, maybe it will save you time - and also the question is if it can fit into the box you have and if the keypad is any good for your application at all.

At the moment it does as much as is shown in the demo - plays usual channels and where applicable, sends MIDI notes out. I also wrote a test binary for the touch keyboard to see if/how well it works (and it does reasonably well), but this is not yet integrated in the software - however it is a trivial thing to implement, I just did not have time to do it - but the idea is that notes from the keyboard will be added to the incoming MIDI data stream, and the rest of the software will handle it normally.

- Can the Glo receive or send clock in any way?
No, unless you program it in. It can have MIDI so it could send clock there. Or you mean some other hardware sync signal? That would be a nice programming exercise too :)

- The LED colors do not seem to work correctly for me. For binaural bests or isochronic tones, they do not shine amber, blue, green, turquoise. Usually it's either blue, red, or off. Is this a known issue?
So you never get any colour that consists of green element - maybe the LED is damaged? What do you see on power on? It should quickly cycle through all 3 colours.

- What's the best approach to attach a dial / knob, that lets the user select any of the 24 channels directly?
Like this? I used the I2C encoder, as you saw in this article but even a potentiometer could be used, when wired to some ADC capable input. The firmware does not support this (yet) simply because there was no interest in DIY beyond the "build your own enclosure" and "add charging circuit", you are the first one to ask about this :)

Hi! Thank you, happy you like it! :)

What kind of board (or breadboard) are you prototyping on? Not sure how useful for you is to see this as you may need to use different kind of caps, maybe not even SMD.

The caps are commonly placed on mic or line inputs to remove DC voltage and let only AC signal through, I made these experiments on the custom PCB - the last picture here shows the bottom side and the 220nF caps.

Firmware - well I have what is shown in the demo there, if I remember correctly it's a binary compiled to use line-in instead of mics and there was no control to switch it - haven't worked on it since however the code base is shared with Gecho where these options already exist - eventually I will enable them in Glo as well, where they make sense. That will probably happen later this year when I'll get a chance to move on with this model - because eventually I'd like to design a single-PCB pocket synth with touch keyboard like this board uses.

As for SD, you can use any slot you want - signals compatible with Glo board you have are as shown here, however this is not the most fortunate solution as it only works with 1-bit SPI mode, and is slower than what can be achieved with ESP32 if you use full 4-bit SDIO mode. It is good enough to load-store data - patches, configuration, samples to load to memory and play, even to build a mp3 player (ESP32 has enough power for that) but not to read/write wav files at a higher sampling rate.

Mic and line-out (if not wired differentially), yes, same AGND.

Hardware Questions / Re: Questions about adding line in to DIY Glo
« on: May 18, 2019, 12:23:55 PM »
Hi Pablo, yes the firmware will be open - it is based on other open source projects, so it could not even be any other way. I'll put it here next to the Gecho firmware, just need to clean up the code a bit. Thanks for the email, will reply soon! :)

Hardware Questions / Re: Questions about adding line in to DIY Glo
« on: May 13, 2019, 12:04:05 PM »
Happy to hear it arrived in a good shape and you are enjoying it! :) I've had it on for hours while working on the laptop too, mostly on decaying reverb, typing sounds very cool with it.

Yes that's correct, the line input should be wired to MIC2 and AGND. But there should be 100nF-470nF caps in series with L/R lines (with larger capacity, lower frequencies get transferred - I usually add 220nF only, sounds great with them). The datasheet with more details about the codec is here if you need to check something.

In the current firmware there is no automatic detection or option for this yet, but there will be a parameter in config file to switch to the third and fourth option - line-in and both mics & line-in mixed, by pressing (+) and (-) together, the same way as you can now switch mics on and off. And perhaps add an option to make this a persistent setting that is remembered during power off.

By the way there is a new article about expansion board, planned to have it in the shop but there is a small error in it that requires rework, the 100k resistor needs to be mounted sideways. Until I get to fix it and order more, there are a few available - feel free to email me if you are interested in one. It expands Line-in and out, and also MIDI both ways through the 3.5mm Jack. Here it is shown in action, it's the previous version that did not yet have LEDs and used different keypad driver that did not work well.

Hardware Questions / Re: Duration of Lipo batteries
« on: May 07, 2019, 07:04:44 PM »
Hi and welcome :) The board takes cca 50mA from 3.6-3.8V, and Li-Po generally keeps useful voltage down to 80-85% discharge, so you can expect to get playing time of [capacity in mAh * 0.8 / 50] which would be around 20 hours for 1200mAh. I haven't yet got to test full discharge curve with Li-Po, only with 2xAAA, so this is only a guesstimate.

Yes the PCB is smaller, 53x25mm, keypad adds a bit, it's 55x28mm and 10.5mm vertically (without buttons).
Actually, it's all here:

The charging circuit is set to max charging current of 500mA to not overload common USB ports, and cut-off is 4.20V which is compatible with Li-Po or Li-Ion chemistry. You can expect charging times in ballpark of [battery capacity / 500] so e.g. 2 and half hours for 1200mAh cell.

For safety reasons, it's perhaps better to have a smaller capacity cell in. When choosing Li-Po, make sure you get one with internal protective circuit (overdischarge and overcurrent). It is very important also to protect the battery itself as Glo board contains voltage booster that will happily continue draining nearly discharged Li-Po (<2.5V) which is likely to damage it.

So, perhaps 1200mAh isn't too much of an overkill, but it really does not make sense to put in any larger... unless you are also adding some external circuitry (more sensors, controls, lights...) for minimal setup, even 250mAh might be fine for daily use.

Yes the STM32 Flash Loader is a bit finicky when it comes to timing, or maybe it's the internal state of MCU, but it eventually works. For example it does not leave enough time for global erase by default, you need to change the timeout to about 10 seconds, or just ignore the warnings and flash it without erasing next time.

Thanks for sharing your observations - happy to hear you figured it out! :D

Great stuff! Hope you like the new functions! More to come, I will fix the app soon 8)

Hi! Sorry to hear it doesn't "just work" as intended  ???

If RDY is blinking, and app claims to not be able to connect, it might be the same issue as discussed here?

The problem is that auto-detect feature is pretty basic and may confuse other COM port for Gecho's port. Can you try to run the app without Gecho attached, that would prove this is the problem.

Otherwise, feel free to share a short video, that's usually very helpful.

I will update the app soon so it has better auto-detect and allows to choosing the correct COM port manually.

Thank you for looking further into it, it's really helpful. Just checked the source code and originally it was looking specifically for "USB-Serial" type of COM ports but later it was changed to just go over all ports, I vaguely remember this was changed as on some systems the virtual COM port was showing under a different random name and therefore wasn't detected. It looks for all "active" ports, whatever that means - I guess the problem is that a hardware type port is always active no matter if something is plugged into it.

The "auto-detect" might still work as intended, just needs to check if there is a meaningful reply from the device... but will add a manual override anyway, it's easy enough. Meanwhile, hope you will be more lucky with the manual update process! :)

This is very suspicious indeed :) In the video it all looks good. The App definitely should complain when you don't have Gecho plugged in, I just tested it in my computer with v0.61b freshly downloaded from the website.

Any chance you have something else plugged in that might use the same driver? I would not think you are leaving your Arduino permanently connected but some other random device that uses USB-serial. If you look into control panel, you should see it (as shown in the first picture here). That would explain it, Gecho app finds first thing that looks familiar and tries to communicate with it.

It would be interesting to know if it was that. I should make it smarter and let it go over all active ports if more found, until a valid response is received.

The manual update utility will work fine as you can tell it to use the other virtual COM port.

And yes the commands for s/n and version were added later (by the way not too useful right now but you can check what applies to your firmware by looking at legacy manual version, links are at the bottom, i guess this one is for you:

Hi! If your serial number is above 27 then it's a final production board and should work with the app. And if the app opens without warnings, that means the board was detected.

The USB LED is driven independently (by PC drivers) and is not necessary blinking later even though communication happens. This also proves that you have correct drivers and privileges.

It sounds like an abnormal behaviour, any chance you could record a short video and share via PM or email? I don't think you are doing anything wrong, once you get the app running and RDY blinking, the update usually just works. Would be good to see how exactly the board and app behaves, chance is I may notice something that indicates a hardware problem.

There is a simple enough way how to flash the binary manually even if existing firmware is corrupted and therefore not talking to the app (if that's the case). You could download the binary here and then use this tool.

Hi Michal,

Happy you resolved the problem quickly!

Yes the trick is that while powering via USB, ON/OFF switch doesn't really power off anything but it is still important for selecting the "boot mode" (internal FLASH vs. serial port). And this setting is read either at power on or reset... therefore the app asks you to reset it while powered off - which sounds like a weird requirement indeed.

Enjoy the new functions :)


A little post-processing surely goes a long way. For example the way granular works, it doesn't have enough CPU power for more sophisticated tricks, joining grains neatly by ramping volumes up and down at boundaries. It just stitches chunks of waveforms together, resulting in steep jumps in signal level - audible as a kind of "cracking".

Or Low-pass IIR filters (pretty much all melodic channels unless you hold SET after keying in, which will switch to High-pass), they tend to leave residual white noise - you can remove it safely with additional low-pass above any useful signal. Software implementation is usually a lot more effective than what can be done in hardware - again, CPU can do at most 4th order IIR (with 24 db/octave roloff). Mixing 16 filtered voices together (8 per stereo channel) multiplies this residual noise again.

Ah and the delay can be switched off completely if needed, I'm sure you know that.

Looking forward to your samples - to be honest I can't very well imagine what you are trying to achieve as I lack experience working with DAWs - assumed there is enough tools in software world to do most of what a small HW synth can, and do it better - however the hardware surely allows for some interesting "happy accidents" :)

Welcome to the forum! :)

Interesting question. Do you mean as soon as you start the channel (presumably first of the granulars, #411) there is already some interference? That should not happen, even at the highest volume settings you should only hear silence.

Once you enable sampling using S2, unless you knock on it, there should not be anything apart faint and monotonous background (inherent semiconductor noise). Is that what you hear?

I don't think a soundproof room would help here, if you hear any artifacts they are either from clipping the samples - does it change with S3/S4?

If it's environmental, a repetitive sound of certain frequency (buzzing, humming), it often happens that with repeating the same sample over and over, if in sync with echo delay timing, it gets amplified. Sometimes you even won't notice it was there in the room all the time :)

The mics are sensitive enough to easily hear whisper or even breathing... but the signal processing (in this channel) is quite lo-fi, a trade-off between polyphony and precision.

Feel free to upload an example, or send me via email, so we can rule out a hardware issue (although all units have been fully tested of course, it's worth checking). Also try to reset everything (#43214321) to make sure it's not some cranked internal mixing volumes / clipping problem.

Pages: [1] 2 3 ... 6