Amazing, right what I’ve been looking for. Working with the MPU6050 (GY-521) myself. But having trouble reading the data. Any chance you could share this object as a guide?
Hi, sure! Let me find the test patch I’ve been using for this. I am using I2C3 though (not accessible via pins), long story - so the object code will have to be rewritten a bit to use the standard I2C (PB8, PB9). I’ll have a look at that, it’s not too much of a change (in theory, once you know what to look for)
That’s great, thanks!! Okay, interesting! Looking forward to play around with it!
i2c1_gyroscope.axp (9.2 KB)
Here’s my patch converted to use of the standard I2C on Ksoloti Core, via PB8 (SCL) and PB9 (SDA), Patcher version 1.0.12.
As I mentioned earlier the LSM6DS3 gyro I was playing with is located on a prototype Core, and I don’t have an external breakout which I could test this conversion with. I may well have messed up some details around the I2C transfer commands, YMMV.
Also obviously you’ll have to redo the register mapping and setup procedure for the MPU-6050, which includes:
- change I2CADDR define
- change register map defines
- change check for expected WHO_AM_I number during init (should also be something like 0x67 or 0x68 for the 6050?) (Or just comment the check out)
- setup Accel & Gyro on, conversion rate, full scale rate etc.
- pull Accel & Gyro values from the respective registers (lower & upper byte sorting might be the same as my example, or inverted?)
-power-down procedure in xxx_end() function, if any - anything I forgot
And for reference only, here is the original patch which uses onboard I2C (I2C3) and will definitely not compile with the default firmware.
onboard_gyroscope.axp (8.6 KB)
Hey there! I’ve been working with your patch for the LSM6DS3 (I bought one). Thanks so much for posting the .axp in the Thread! I don’t know enough of it, but I’m working with an engineering friend. The I2C1-version does not pass the WHO_AM_I-check unfortunately. It does read something I think but we cannot check what, because we don’t know how to serial print or log. For debugging we’re just using LED blinking ;). So we wondered if there would be a better way to get it to check values etc.?
Hi, yes there is LogTextMessage() which you can pass C-style formatted stuff, check out some examples in the libraries to get a feeling for the syntax:
In v1.0.12 LogTextmessage() is stable but calling it very frequently, e.g. once every k-cycle or with a lot of text, might cause the Patcher to lose connection after some time. But the occasional one-time update messages are fine!
In v1.1.0 LogTextMessage() has been graciously reworked by AndyCap and it is virtually bulletproof. I use it a lot to print k-rate values to the console then paste those in dedicated software (cough, Excel) for analysis.
Looking at the i2c1 patch I transcribed with a fresh pair of eyes, I noticed I made at least one mistake - forgot something in the init code.
i2c1_gyroscope_2025-05-25.axp (9.9 KB)
If still nothing, what exact model LSM6DS3 do you have? Check the datasheet to find out its WHO_AM_I number, or skip the check entirely. The registers should be about the same for all LSM6DS3xxx if I am not mistaken.
Let me know how this goes!
Tysm! It works!!! We had to change 2 minor but critical things. 1. We had to change the I2C address from 0x6A to 0x6B. 2. The formula for the WHO_AM_I register was changed to
if ((who & 0x6C) != 0x68) {
etc. (so with brackets added) > otherwise Bitwise and Boolean function got confused.
LSM6DS3.axp (2.4 KB)
Thanks for all the help! Will keep you posted on the project 
1 Like
Thanks for sharing your fix!
Update: the problem with such off-the-shelf capacitive sensor packages is the high latency. They are designed for high reliability, for example in household appliances and such, not speed.
It seems touch detection latency on the CY8CMBR3116 in particular is at least 60 ms, usually over 100 ms, and that is with all noise filters and debouncing turned off, not taking the I2C scan rate in the Ksoloti object into account. Too slow for anything musical IMHO!
If anyone has a suggestion for a faster sensor please let me know! (I’ve seen dedicated small MCUs with capacitive touch features, like the MPS430 series maybe?)
The Bela trill stuff uses a CY8C20XX6A
They have a couple of ms latency I think.
CY8C20336A looks like a good candidate. Or CY8C4014 - newer, in stock, and costs less than 6 USD a piece?
If I were to put them on the Core by default, I am not sure if I’d be able, and can be bothered, to program all of them.
I’ve been thinking of adding a dedicated battery charging circuit instead of an I2C toy, if free space allows it. This seems like the most useful solution at the moment.
- Gyroscope would be too rarely used, and functionality can be added easily as a breakout board
- Capacitive sensor IC does not perform well enough, scan rate and latency are too slow for use in music
A battery charger, if it is possible, would be an easy way to create a portable Ksoloti by simply hooking up a Li battery.
Anyone out there with some experience on this?
On-board “toys”?
Think again.
-
Some are useful for only a fraction of users. Yet all other buyers will have to pay for the extra chip(s) without needing it. MIDI, on the other hand, is not an extra for an audio system. It can be assumed to be expected by every user: Axoloti had it.
-
For the actual user-facing part of the peripheral, the PCB may be the worst of all places. A microphone, for example, cannot be decoupled from vibrations. Or the capacitive sensors you have in mind, they should not need long connection cables, because these have a capacity too and could pick up interfering electrical noise. And so on… Apart from these potential functional problems, it can severely restrict the possibilities for enclosures.
-
If you dedicate any port line to a specific peripheral, you can never revise your decision without breaking some users’ patches.
So - I love to see cool peripherals, but, please: On an optional daughterboard.
Not sure if troll or “expert”?
Read again.
End price would not increase
Ksoloti has it
Yes, yes, I know about the MIDI functionality, it served only as an (counter)example for a right decision. And I2C2, I know, too, but it may be considered more useful for something else in the future, which you might regret to have blocked. Concerning “troll”, 
I’m happy to be contacted by you by direct message, to tell you about my background.