Using this software - the journey

[oatybiscuit]

Rather than continuing to post 'issues' I am continuing my I intend to use this myself! as a discussion with an update on progress so far.

Hardware is on hold while I gather the necessary components, and I aim to build the controller with solenoids as a test first. Once all is proven I can consider how to go about modifying pipework etc and installing in the organ.

Using an M5stack Core S3.

A nice unit, and I have managed to get it loaded and connected with the Uiflow tool. I am experimenting with various extension modules - rotation sensors, pressure sensors, and a midi synth unit. It helps to use the Uiflow with blocky to easily find the 'code' for the extra units and the internal display screen, but I find it less satisfactory for programming than directly with python code. I have added Thonny to my PC and found this a great tool - easy to connect to the S3, easy to navigate the flash, and easy to use the REPL to test code directly.

I have managed to write simple code using the M5 libraries to access rotation, pressure sensors and to write to the screen. I have taken the umidiparser code (see different repository) and written a very simple program to load the necessary modules, initialise the synth unit, add the SD card, read a fixed midi file, and then play the midi file sending the midi note on commands to the synth unit. It works!

The hope is that I can somehow use this CoreS3 for front-end display / control, and to add rotation and pressure, and also possibly use the synth for drums etc or an additional pipe register. It would be interesting to have a small amp-speaker to add sub-octave 'helpers' to the base and accompaniment notes.

Using this for the main organ program itself may not be possible without wiping the Uiflow from firmware, and timing may mean that it is just not possible for example to continually read a pressure sensor to provide a gauge meter. My thought is to consider using one esp32 S3 for the main program, and the M5Stack Core S3 unit for monitoring / control with a connection between them.

Using other S3 boards

I bought an adafruit Metro ESP32-S3, which works nicely and I have been able to write micropython to the flash using Thonny, however the adafruit board is intended for circuitpython, and I have struggled with getting this to work. I added all the organ data and software files manually, but found running the code caused a string of issues. I assume the existing UM loader is getting in the way.

So off to yet another S3 board, this time Unexpected Maker ProS3. Staring from scratch I have added Python to my PC (tip - make sure you tick the 'add to PATH' option otherwise nothing works). I have used Thonny to add micropython to the board, and I have run mpremote in Python from my PC command window and executed the install commands. (note, the software install takes quite a long time and nothing much visually happens for a while).

The software is up and running

The organ software works nicely. I have just had to edit the main.py to change the initial NeoPixel pin number for this board. The WiFi works and the board is now configured to connect to my home network, and typing 'organ.local' in a browser finds the organ pages. I have added just the one midi file (to flash) and I am still using the default 20 key config, but it all "works", and I have even found that I can see and play the midi file on the PC!

Next job is to get a breadboard, the MCP23017 expanders, solenoid drivers (I have a 32 channel PNP driver board on order) and wire all this up with real solenoids.

• I need to modify the settings and configuration to use the 26 note option, with MCP23017. I have two expander boards, and plan to chain them on the same I2C bus but with different addresses. I am currently assuming this will be OK since the current config uses two different pairs of pins for two separate I2C busses.
• I need to find a few more midi files to work with
• I am looking at battery-packs, and have found a 12/9/5 volt unit. This is normally 12 volts, which I would use to drive the 12v solenoids which appear to work down to 6 or 7 volts, so an exact 12v is not essential, and I can drive the ESP32 S3 from the regulated 5 volts. The question remains as to if/how I can set up the battery monitoring, if any form of special connection is required?

Once the 'system' is proven I can test the solenoid values that I have, and if they work in the organ, it will be a case of building a new wind chest for the valves and installing everything.

Questions to ponder

I appreciate that, when a midi file is playing, there is a lot going on and the code has been written to minimise other activities so as not to stop the music. I would like to be able to add wind pressure monitoring, rotation speed monitoring, current tune name display and stop/start controls etc using the M5Stack CoreS3 display. Since the midi tune-player part is just one section of the code with the rest mostly devoted to running the webserver, would it be possible to separate the two, having the tune-player etc on one esp32-S3, and the webserver and any extra code I would like to add on another esp32-S3? I understand that esp32 can communicate between one to another using ESP-NOW. Since these boards are really very cheap, a multi-board system would take the pressure off the midi player and allow extra features on the 'display' end of the system.

[bixb922]

Wow, that's quite impressive!

Using an M5stack Core S3.

Ohh, I have looked at those with envy several times already :-)

Unexpected Maker ProS3

That seems to be a good quality board, I have read good comments about them in the MicroPython forum.

I have used Thonny to add micropython to the board,

Thonny seems to be simple and useful. I use VSCode to edit/lint the code and mpremote and old fashioned make files to update the microprocessor. Another nice development environment seems to be Viper IDE https://viper-ide.org

(note, the software install takes quite a long time and nothing much visually happens for a while).

Oh yes, during that time the software is uploaded via the USB connector.

Rest of the topics: I'll comment that later. Believe it or not: I have to go leave now to play the crank organ at at a Christmas concert :-)

[bixb922]

Re: Questions to ponder

The question remains as to if/how I can set up the battery monitoring, if any form of special connection is required?

What type of battery pack is that, and what type of monitoring are you thinking to do? Batteries are quite difficult to monitor externally. For example, measuring the battery voltage does not lead to good results, since the voltage depends on the current load and discharge curves do not help much there. A power monitor such as the INA220 may be the best option, since you can measure the consumed power directly and then add that over time and compare with nominal battery capacity. But that is somewhat equivalent with what the software currently does indirectly: the software adds up the operating time and the time solenoids are on and correlates that (with a linear multivariable regression) with the user input when the battery is empty to estimate a discharge curve.

wind pressure monitoring, rotation speed monitoring, current tune name display and stop/start controls

That sounds great! I made some tests with the BMP280 sensor and it seems very adequate for the job. It connects to I2C, so if you put the MCP23017 inside the windchest, you can put this on the same bus (https://www.tapatalk.com/groups/buskerorgan/viewtopic.php?p=7391#p7391).

Rotation speed: do you mean crank rotation speed? There is a capability in the software to measure crank rotation speed both with a simple encoder or with a quadrature encoder. The crank can either only start the tune, or can be set to influence playback speed. To sense rotation, it uses the PCNT hardware on the ESP32-S3 chip, so this has very little overhead. I have had many, many headaches with the crank sensor (mostly problems I introduced myself) and have a writeup pending with the conclusions... At this point I have pending to test a quadrature encoder as crank rotation sensor, which I like a lot, but I managed to connect 12V to the microcontroller input and fry it, and haven't had the courage and time to try again so far (and I needed to order a replacement ESP32-S3 board).

As for tune information display, that's quite interesting!

Since these boards are really very cheap, a multi-board system would take the pressure off the midi player and allow extra features on the 'display' end of the system.

I never thought about separating the code in two, so this will need some coding and design. I can certainly assist there. On the other hand, the "optimization" while playing back music allows to do tasks while the music plays, but you have to be a bit careful. The main issue is responsiveness, i.e. no task should "hog" the CPU for a long time, since that will mean a delay in the notes that are playing. A small delay, such as 10 to 30 milliseconds, is barely noticeable, since the MIDI player catches up with the tempo if that happens. So if a task needs little CPU time once in a while, it can perfectly run while the music is playing. For example, what I'm currently doing while music is playing:

• Read the crank sensor 5 times a second and calculates the playback speed
• Read the touch button 10 times a second to determine an action
• Flash leds
• Respond to web client requests. The requests ship data back to the client in JSON format. Serving such a request will take, say, 5 or 10 millisec at most. For example, every 2 seconds or so, the browser client requests the progress, and there is no noticeable interference. However, if you navigate, for example, to the diag.html page while playing music, notes will pile up and then play at once, and the music resumes normally, as an example of the hearable effect of CPU hogs.
• And many other tasks, I think there may be about 20 tasks running

Internally, this multitasking is not done with threads but with a mechanism called asyncio in Python. You can create a task with asyncio.create_task() and use the await statement to yield control to the next task or to put the current task task to "sleep" for some specified time.

If a longer computation is needed, exceeding, say, 30 milliseconds, then this software provides a RequestSlice call:

async with RequestSlice("my sensor", 200):
    do something that could need the CPU for up to 200 milliseconds

What this will do is to put the enclosed statements to wait until there is a 200 millisecond (or whatever time you specify) pause or long notes in the music. Music has lots and lots of pauses or long notes! That way, long tasks go absolutely unnoticed because they are scheduled when the music allows it. For example, MicroPython's garbage collection, which used to need up to 150 milliseconds, is handled this way and never interfered with the music.

The only drawback of RequestSlice() is that the start time for a task to be scheduled is a bit variable. Well, with the ESP32 family, having exactly scheduled tasks (for example every second +- 1 millisecond) is not feasible anyhow, and I don't think this is a restriction at all, especially if the tasks relate to human interaction, where 0.1 to 0.5 second delays are unnoticed or quite acceptable. There are always workarounds for this restriction, I think.

And, for me, the other drawback was that I had to learn about asyncio, but there is a good tutorial here: https://github.com/peterhinch/micropython-async

So as a first go, I would take the easier way and launch a task using asyncio.create_task() at startup time, and make the task with a while True loop, await some time and do the needed stuff there using RequestSlice() for CPU hogs. poweroff.py is a example that is not very complex and perhaps easier to follow.

Of the enhancements you mention, the display is probably the most CPU consuming one. It would be interesting to measure the display update time. I would guess update time is quite fast, probably much less than 200 milliseconds.

I think this route is less work than splitting the software in two. The music player is currently not stressed at all, the response can be monitored installing a asyncioprofiler (aioprof) in the microcontroller, which is already recognized by the software.

But I think this could be the best option: when using a second microcontroller for example for a display and buttons, there are already many JSON webservices coded such as /get_progress and the tune information (tunelib.json) with information about the current tune being played, and that can be called safely at any with a http client such as aiohttp to extract the information. All buttons of the user interface such as "Next" or "Da capo" or "Shuffle" are also available as JSON web services, and can be called externally from any client. That's a natural interface of the software, and wouldn't even need to touch the current software, since user interface is done with Javascript in the browser via these same web services. The software will work correctly with two clients (browser and a second ESP32-S3).

To communicate two ESP32-S3, ESPNOW seems to be the way to go, although to use the available web services you would need TCP/IP over WiFi (i.e. the builtin network module) plus aiohttp or requestsas client, not ESPNOW. Update: On a second thought, this might be the easiest option to integrate another microcontroller.

Please let me know if this is useful.

[oatybiscuit]

This is all very helpful thank you. It provides much food for thought. This is very much an evolving project, and as always applying a bit of thinking and testing of ideas up front helps greatly.

I like the concept of using a basic EPS32-S3 just to run the software (as is) close to the solenoid windchest, and to have a second ESP32-S3 up on top to provide (extra) 'monitoring and control'. The M5Stack CoreS3 appears ideal, since it has a touch-screen, SD Card, power options and a small battery, and plenty of easy to use ports.

Splitting software into parts is never easy, and the overhead of adding in inter-code communication and duplicated global variables and modules is likely to outweigh the benefits. I would prefer to keep your code as it stands, but add in 'extra' features on a second ESP32. I have no experience with asynchronous coding, so this will take me time to get to grips with how it works before I can consider making changes. To add 'extra work' to the existing code, such as monitoring pressure, I think that I first need to list out your 20 or so tasks, and see if anything on the list can be turned off, moved to another board, modified for different or less use, and what room there is for adding in other bits. I need to go away and study asyncio and your code!

If I was starting from scratch (which I am not) having got your umidiparser to work with a synth unit, I could see the benefit of just having one ESP board to run a basic 'midi player' from a given file. However, as this still requires a file to play and all the solenoid support, as well as monitoring, garbage collection and so on, a better 'cleave point' is more likely to be with the webserver, which naturally separates the working operation part from the less used and end-user interaction for just monitoring and control.

Battery - I am looking at a possible unit with 12, 9 and 5 volt supply. The 12v is nominal and unregulated, but perfect for 12v solenoids. The 5v is perfect for the electronics, and the 9v could run the solenoids or the M5 CoreS3. The battery unit has a simple 'press and count the leds' monitor, but nothing to easily integrate with. I had not looked that closely at your code, but good to know that it does the hard work of estimating use based on solenoid use-time. I have just received a set of 12v solenoid valves that I want to use for testing. Assuming they are suitable, the solenoid pulls in at around 7-8v (so could run on 9v) and apparently consumes just 100mA at 12v, so at 9000 mAh capacity the battery will almost certainly last longer than my arm. Perhaps battery monitoring is just not required!

Tachometer - my experimentation has been with a rotary encoder unit for the M5 CoreS3. This uses the I2C bus and has a pulse encoder chip built in, hence it keeps count as it is rotated and the running count can be read or reset back to zero. I was going to look at cannibalizing this and trying to add it to the drive wheel between crank and roll drum, then using the M5Stack to read at intervals. With a known interval of time, and the difference between the current and last reading, I should get 'rotations' per minute. This could run entirely separately on the second board, and perhaps offer RPM directly back to the main board via ESPNOW. Since the unit keeps its own count (at 30 increments per revolution) at the end of playing a roll, the count would be a 'total figure' of how much cranking was required for that particular piece, with modifications to your code for resetting the counter to zero before starting to play a new file. Much room for experimentation.

Pressure - again experimenting with the M5 stack BPS unit has proven the possibility of adding this easily to the M5 unit. These sensors (BPM280 and others) are indeed very sensitive, and this would be the easier bit of coding to do. I am unsure this would add any real benefit, since on my organ the reservoir is most often full and exhausting, however it might be interesting to record the crank rotation, reservoir pressure, and open pipes (solenoids) to model organ windage. Perhaps when I have nothing better to do!

Tune Display - from a basic point of view, just having the name of the tune on the M5 CoreS3 display on the top of the organ would be useful. This could come from the main board (again perhaps using ESPNOW) as the tune starts. From there I could consider having a bigger display on the organ front. Everything is moving to e-paper, but these units seem to require frequent refreshing on a weekly basis or they 'die'. LED display would use more power, but could be just turned on for 20 seconds at the start of the tune, and all of this could be managed by the second board.

Lots to think about. I need to go away and look more closely at your code. Now I have a working ESP32-S3, some solenoids, and a couple of MCP23017 boards. Just waiting for a 32 channel driver board to arrive, and then it will be time to wire it all together and change the config to the 26 note Universal. When I have solenoids 'playing' a tune, I can begin to think about other things!

Thanks again for your detailed information.

[bixb922]

The M5Stack CoreS3 appears ideal, since it has a touch-screen, SD Card, power options and a small battery, and plenty of easy to use ports.

It's a nice board! Fortunately there are several good quality providers for ESP32-S3 boards, that's good for us!

a better 'cleave point' is more likely to be with the webserver,

I agree. All functions are exposed as web services, so adding a second user interface should be quite feasible. (edit) For example, to implement a crank rotation sensor in a second microcontroller, there is a /set_velocity_relative web service. I did not document these web services, I never thought somebody might use those :-) but please post your questions here and I'll be happy to find some way to implement that.

Perhaps battery monitoring is just not required!

I did all the support for calculating the battery usage, but then found out that at less than 300 grams per battery it's easier to carry a second battery pack around :-) and changing it when required. But it's nice to have a better indicator than just four leds.

however it might be interesting to record the crank rotation, reservoir pressure, and open pipes (solenoids) to model organ windage

Yes, I want to do that sometime also! There are some excel sheets out there to calculate the theoretical wind usage based on pipe measurements, but measuring the real thing is always interesting and sometimes surprising!

Tachometer
That should work. That rotary encoder seems to be a quadrature encoder (i.e. counts positive in one direction and negative in the other). Class TachoDriver in tachometer.py uses the Encoder class which in turn uses the low level driver at pcnt.py. It should be feasible to replace the Encoder class used there with an Encoder class that reads the rotary encoder's count via I2C. It's perfectly ok to use MicroPythons SoftI2C to do the I2C management. IDK if M5Stack provides some MicroPython example or some module.

With a known interval of time, and the difference between the current and last reading, I should get 'rotations' per minute

That's what tachometer.py does currently. Probably a good part of that code can be reused.

Everything is moving to e-paper

Oh yes, that's one of my dreams in the future, to have a e-paper display for the current tune title/genre/author/year/info. I find the flickering refresh and refresh time (sometimes 10 seconds or so) of many units annoying, but good, fast and non-flickering e-paper displays exist (but can be quite expensive). There are even some bendable e-paper displays out there :-)

[oatybiscuit]

Proof of concept - first stage - completed successfully.

ESP32 S3 (Dev Kit equivalent) with breakout board. Updated Micro Python to access 16Mb flash. (separately tested adding SD card and finally got that to work too). All code added and working.

Battery pack (12v and 5v). Two MCP23017 breakout boards (one I2C line, two different addresses). PCL signal controller (32 channel) with 3.3v input signal to control 12v relays. Valve relays (7 wired in for testing).

Playing a basic Midi file.

VID_20250105_122812158.mp4

[bixb922]

I like that!! Neat setup, looks way better than my breadboards!!! I am very happy that you could make the whole setup work!

[oatybiscuit]

I am very happy that it was, relatively speaking, remarkably easy to build a working Midi organ with so little effort. Your software is comprehensive and easy to use.
The electronics are really very basic, but I have decided to go with 'industrial' units. This costs more, but the large 'signal controller' comes in a frame that will be easy to mount, and easy enough to add mounting boards for all the other parts. All parts should be replaceable, all parts have power led, so easy to see what is on, and the signal controller provides full isolation and an indicator led (great for testing).

I am planning on adding a synth unit to provide additional support for bass pipes, drum sounds, and perhaps an additional reed/trumpet rank. I have a couple of SAM2695 units (and amp / speakers). I just need a Midi feed for this, which could come from the organ software, and that would then mean I can fully test with sound before I start on the physical stuff. Next step is to break into the pipework somewhere, put in one of the solenoid valves, and check to see if it actually works and lets enough air to the puffs.

Slow and steady progress.