jkominek / piano-conversion Goto Github PK
View Code? Open in Web Editor NEWHardware, and some firmware, for acoustic piano to MIDI controller conversion.
License: Other
Hardware, and some firmware, for acoustic piano to MIDI controller conversion.
License: Other
I produced a bunch of variations on the sensor board very quickly, to account for the changes in my mechanical plan. Improvements:
Additionally, I'd like to make a variation on some of them that uses the EAITRCA6 from Everlight. It's a similar, but much thinner sensor. Looks like it could be surface mounted, which would allow the sensor PCBs to rest flush against their support. That should eliminate flex when the hammer impacts.
Place to record necessary changes for rev 3 of the board:
Place to record necessary changes for rev 1 of the board:
Check:
According to this paper http://mtg.upf.edu/mosart/papers/p35.pdf and this other one https://www.researchgate.net/publication/7603558_Touch_and_temporal_behavior_of_grand_piano_actions and how it discussed in some details at
https://pianoclack.com/forum/d/289-scanning-speed-and-velocity-mapping-of-cybrid (and to less extent https://pianoclack.com/forum/d/243-diy-piano-sensors/33 ) it might be necessary to scan at 200kHz per channel.
I update the board revision number right before producing gerber files. So this will be the very last thing to do on the milestone.
Generate gerber files for the following, and attach to the release:
A sort of pie-in-the-sky idea, that isn't part of any milestone, or blocking anything:
A board, conforming to the overall I2C/Qwiic scheme, which presents itself like the I2C UART on the MIDI output board, basically taking a stream of MIDI data written to register 0x00. But instead of streaming that MIDI data elsewhere, it runs it through a simple synth, generating an analog signal, and feeding it to any of line outs, headphone amps, or power amps for real speakers.
I don't have any interest in trying to implement even a sample-based piano synth in hardware, let alone a fancier synth than that. But some simple 32 voice sine wave + some harmonics that responds to note on velocities, note off, and sustain pedal could maybe be useful? I'm imagining a situation where you've taken a unit to a tech for them to work on the regulation of the system after confirming that whatever your issue is, is present even when using this simple synth.
It would also serve as a reference for anyone who wanted to build a more advanced synth. For instance, it is possible to get a Raspberry Pi to act as an I2C slave device. So, you could make a board that brings in the Qwiic connection, has plugs for a Raspberry Pi compute module (both for it to mount, and so you can put a display/keyboard/mouse on it), takes the audio output from the module, runs it through amps. Then you could slap Pianoteq on the Pi module, and have a largely standalone system with "real" synthesis and "real" audio.
Most of the fixes necessary for Rev 1 have been made and are covered under the Board Revision Notes.
Would using these parts make the ADCboard to sensorboard cables easier to build?
Cable: https://www.digikey.com/en/products/detail/3m/HF100-40TP/3911407
Connector on the ADCboard side: https://www.amazon.com/dp/B00K2NTSJE/
Connector on the sensorboard side: regular jumper to be crimped, such as https://www.digikey.com/en/products/detail/harwin-inc/M20-1160046/3919438
This will cut in half the number of pins that need to be crimped (yay... but see below for even better) produce neatly organized cables (yay), and give some screening protection from noise by virtue of being twisted (yay).
I looked (not very hard) for single-row of stuff like https://www.amazon.com/dp/B0936Q6BDX/ which would eliminate the need of crimping.... or we can use two rows connectors rather than single row on the sensorboard too?
Now of course not everything will fit into the 4x arrangement (I'm planning to leave some of those sensors unconnected), so some cable-fu is still needed, but not as much as if we'd be wiring all 176 sensors (each with two cables, each with two ends) with a regular crimped connector. Am I missing something?
Note that if necessary the HF100-40TP cable can be ordered with custom lengths, as mentioned at https://multimedia.3m.com/mws/media/671953O/3mtm-twisted-pair-flat-cable-hf100-series-ts2344.pdf (not sure if the price remains affordable).
In this scenario, we could make the distance ADCboard-to-sensorboard fully twisted and have a custom section of non-twisted part for ease of separating into the various connectors for the 22 sensorboard (or more, in my case) ending into the same ADCboard
JLCPCB being one of the easier (and still reasonably priced) ways for the average person to get a board assembled, I'm trying to keep the parts used to things that are available via JLCPCB.
In the unlikely event anyone else tries to work on this, you'll probably need to ask me some questions about part choice/suitability. Some are left underspecified in the schematic, some might be too specific. I can either describe the relevant attributes for a given part ("needs long term stability and low input offset"), or review a few choices presented to me.
Putting ethernet on the main board is an unnecessary complication, which increases the board size/BOM/cost/etc. Many users probably won't even want it. It's certainly non-existent on every other digital piano, so it shouldn't have such a prominent place.
I decided I2C was a nice idea after I'd already started putting the ethernet onto the main board, and didn't reevaluate its suitability. Doing full TCP/IP over I2C would probably be a pain, but the main board doesn't need to. It can mostly just worry about MIDI and its own configuration.
So we'll move all networking off to another board, and pick up WiFi at the same time. The networking board will feature an ESP32 module, acting as an I2C slave to the main board. The ESP32 will bring along WiFi, and we'll add a SPI-based Microchip ENC28J60 to get 10Mbps ethernet. The only thing that will need to move across I2C is MIDI messages (and maybe some sysex for configuration/control, but that's minor). All of the TCP/IP and RTP MIDI stack stuff can be handled on the ESP32, where it won't bother the realtime stuff happening on the main board.
I'd like the ability to run the RTC on the main board, accurately. That'll let us track calendar time, so that we can properly time stamp files stored on the SD card.
Why do we want to time stamp files on the SD card? I'd like to be able to record everything played into MIDI files on the SD card, to duplicate the Pianoteq feature of remembering everything that's played. It's not a super high important feature, but it should be possible to at least squeeze the relevant stuff onto the PCB (with no downsides) even if it isn't populated.
See section 2.1.3 of AN4938. It looks like the STM32H743 can charge the battery a little bit? Do I need to put something in place to handle the possibility of a missing battery? Maybe a diode with a 1.5V drop from Vdd to Vbat? Or just some spot to solder a resistor between Vdd and Vbat?
So we need:
There are three bring up issues to check before the Rev 1 schematic can be finalized:
I update the board revision number right before producing gerber files. So this will be the very last thing to do on the milestone.
Generate gerber files for the following, and attach to the release:
We'll want the new TIA circuits for testing/writing analog processing code going forward.
All the desired fixes/changes have been made. I don't anticipate bringing these up, they're just cheap enough they're worth getting in case I need more adapters; no sense building the old design.
Place to record necessary changes for rev 2 of the board:
Most PCB manufacturers have a minimum size, which is much larger than even the larger sensorboards.
I guess making one PCB with scoring should solve this issue (and perhaps save some money, the way I've seen costs being calculated).
I don't see scored sensorboards in the repo though, so I am wondering if that's simply left as an exercise to the reader, or if there is any issue which my naive competence does not let me see.
Most of the fixes necessary for Rev 1 have been made and are covered under the Board Revision Notes.
All the centered sensorboards have the holes at a distance of 20.2mm
from each other, rather than exactly 20.0mm
as I was expecting for the extrusions you and I are utilizing.
This might be intentional or my own measurement error, and in any case not a big deal since smaller than mechanical tolerances, but since I saw it, I am reporting it anyway.
An inconsistency in the ADC kicad file:
As you can see the comment says "Monolithic switching regulator" but the part and its description is for a linear regulator.
Probably related (hence I am not opening a separate issue for that) is the text in https://github.com/jkominek/piano-conversion/wiki/Assembly-Notes which says
IF your firmware doesn't draw much current, you can use a linear 3.3V regulator, and save a couple of dollars per board. If you don't know what you're going to run on the board, stick with the suggested VR05S3V3
Not sure what you mean by "suggested", I initially thought that your board had a switching regulator VR05S3V3 which one could substitute with linear regulator, but instead it looks like it is now the other way round? If that is the case, does it mean that the regulator you selected should be able to provide enough current for a generic firmware, or that you measured the current for the firmware you posted and for that the linear regulator is adequate?
In any case, you might want to fix the kicad file and the wiki page
The HDLC code on the ADC board (which will need to be generalized for use on the main board as well), currently receives data over the UART using DMA. Character recognition on the HDLC frame byte is used to trigger a UART interrupt to process the received data. Works great.
But the board still uses the dumb method of sending data, with the CPU spinning while it waits. Even at 3Mbps the UART is very slow compared to the CPU (480MHz vs 300kB/s). We're burning 1600 CPU cycles for every byte, once the FIFO fills up.
Instead, we should maintain a circular buffer for DMA transmit. Note, we don't want to put the DMA transfer into actual circular mode. Rather, the send function should tack bytes onto the end of the buffer, and if no transfer is currently in progress start one. Then the DMA transfer complete interrupt handler should check to see if there are unsent bytes in the buffer, and if so, begin a new transfer.
(The code which writes into the outgoing buffer could also add in a bit of smarts, and send fewer HDLC frame bytes, depending on what it sees in the buffer already.)
That should free up quite a bit of CPU time, and work quite nicely even with the priority of the DMA transfer lowered, as the UART has its own FIFO to help smooth things over.
Subtasks:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.