EWI mouthpiece with breath and bite (lip pressure) sensors

P

progmars

Member
Hi all.

I've been looking at electric wind instruments, both professional and also do-it-yourself projects. The mouthpiece seems to be the most tricky part to get done right.

I have seen a few approaches for implementing breath sensors and bite sensors, and I'm not sure which one would be the most accurate / easy to implement using available parts, and also which one would work the best with Teensy to provide reasonable latency.

So, here are my choices and what I already have.

Breath sensing
-----------------------------------
I've seen people using mostly MPXV4006 and MPX5010 diff or gauge sensors, they seem to provide a pressure range that more accurately matches wind instruments. According to some studies, blowing pressures in wind instruments range between 1 and 12 kPa.

I have a MPXV7002 differential sensor -2.0 to 2.0 kPa and I haven't yet tested it. Wondering, if 2kPa might be too sensitive and get oversaturated by breath? But we should also consider that the tube will have a side path to have free breathing. So, only a part of the air stream will reach the sensor, in which case 2kPa might be sufficient. Not sure, will see when I get to testing it (Teensy still in my cart in the store).

I could not find MPXV4006 nor MPX5010 in my closest Distrelec store, and shipping from another store would cost more than the parts themselves.

Another option is to buy ABPDRRV060MGSA3 - Basic Board Mount Pressure Sensor 0 ... 60 mbar, Gauge, Digital/SPI, Gas/Liquid, DIP, Honeywell. 60mbar corresponds to 6kPa, which is closer to a real woodwind (but again - not considering the open side tube).

Not sure about SPI. Which option would provide lower delay on Teensy - analog output from the sensor or SPI?

Another novel approach that I saw in a Youtube video is to use a balloon rubber on a bottleneck and a reflective sensor CNY70. As you blow, the rubber gets closer to the sensor and it receives more of the reflected light. But I'm not sure if it's a better and more accurate solution than a pressure sensor. What do you think?



Bite (lip pressure) sensing
-----------------------------------
I have read an AKAI EWI tear-down article. They seem to be using some kind of capacitive sensing with two metallic plates getting pressed together when biting. I have looked at a similar DIY sensor article for Arduino, and it seems to be tricky to implement right - it needs very accurate resistor value tweaking and also depends on input pin specifics with internal pull resistors and maximal current. There might be a risk damaging my Teensy while experimenting with such a capacitor.

Also, I don't want to have a strong bite but more like lower lip pressure, like what I'm used to when playing my Clarineo.

I have seen an article where a person uses a reflective sensor (QRD1114) for the bite mechanism. I don't have QRD1114 available, but I have CNY70 - should work the same, I guess.

But I'm not sure how to implement it mechanically - unfortunately, there are no detailed examples. So, my idea is to buy some cheap sax mouthpieces from China and a few plastic reeds to experiment with.

Then I cut the part under the reed to make it more round at the front, so that the reed has wider amplitude to move when I press it with my lower lip. Then it all boils down to - how to translate the small vertical movement of the reed to something that the optical sensor can understand with enough accuracy?

Also, I'll have to seal the sensor part to protect it from moisture (the open tube will drain it all out at the end of the instrument, the same way as Akai / Roland does).

I might instead buy an Akai mouthpiece, but then I'd have to think of connecting that capacitive bite sensor to Teensy.

I hope it won't end up costing me more than buying and modding an Akai EWI-USB :D

Thanks for reading this lengthy "thinking aloud", and I hope somebody has something to say about this.

I'll especially appreciate ideas from people who have successfully created such mouthpieces and have been using them for some time.
 
You have a lot of very specific questions and I think you'll have to just try some things and see if they work. I can perhaps assist with a few points.

MPX5010 are less than £20 including shipping to UK on AliExpress. I don't know where you are but it's probably similar pricing.

In terms of latency, both SPI and reading an analogue value would cause imperceivable delays so don't worry about that.

I think this will cost you more than any already existing solution. Maybe not in money, but in time at least.

I have never heard of lip pressure sensing, and I don't know how the mechanics of it work (embouchure?) but maybe a flex sensor would work? I looked at a datasheet for the QRD1114 and I don't know how that would work (your lips would always be touching the sensor and even if they are tight on it, the reflections would still be the same?)

A lot of negativity and very few actual answers. Sorry about that, but maybe something I said can help you slightly.
 
Thanks for the reply.

Yes, I might end up spending the same amount as AKAI EWI USB (about 300 EUR), but even then I'll have much more moddable hardware. I'm already experimenting with a wireless solution using RF24 with Teensy LC and Arduino Nano, and it works rock solid now with under 1ms latency. Wireless EWIs cost much more than 300 EUR. I'll get much more bang-for-the-buck from a DIY device if only I get it finished.

I'm from Latvia, by the way. I'm a bit wary of buying relatively expensive electronic components from Aliexpress - too many fakes out there. Some of them are actually good fakes, but still. At the same time, I have some fake Nanos and RF24 from Aliexpress. I'm such a hypocrite :D

Regarding that lip pressure sensor - I've read that it can be done by mounting the sensor inside the mouthpiece and having some reflective part attached to the reed. As you press your lips and move the reed, it moves the opposite end of the reed closer / farther from the sensor. Unfortunately, I haven't found detailed mechanic drawings to see how it works. Normally, the reed has very little movement, and there should be some additional mechanism that translates it to larger amplitude for the sensor to pick up.

I recently found this guy:
https://youtube.com/playlist?list=PLCejzxWlLD_ybX0R1CpkwIb5D1jcsiq2-
His videos are a huge source of inspiration for me. So simple ways to design simple but creative MIDI instruments. I'll try to think of something along those lines when designing mine.
 
Re: the bite sensor, 10 years ago you could buy a cheap sample pack of Quantum Tunnelling Composite (QTC) rubber pads on a number of educational/science online stores. These were great because they could measure a very wide range of pressures.

Unfortunately they seem to have become one of these products where you have to "call the sales department". But pressure-sensitive rubber is still a thing: https://mindsetsonline.co.uk/shop/pressure-sensitive-conductive-rubber-pack-of-5/
I have no idea how it performs though, in comparison with QTC.
 
Yes, I was thinking of some kind of pressure sensors first, but had some doubts, seeing that EWIs usually avoid this solution. One reason to avoid it might be durability.

Another issue is sensitivity. I would have to press it with my lips - not sure if it would be able to detect such a soft pressure and maintain consistent output values depending on lip pressure. I could make it react to bites instead, but then durability becomes even more important.

I found a video comparing mouthpieces of Roland Aerophone and Akai EWIs. Here's the most important screenshot from the video:
chrome_2021-08-08_22-53-49.png

I'm leaning Roland's way - it seems easier and more reliable to implement it with an optical sensor. than with those metallic strips However, Roland has made it a bit complicated - the sensor is not inside the mouthpiece, but instead, it uses a lever that gets pressed by a pressure plate that touches your lower lip. I don't have confidence I could implement it that way; I'd better mount the sensor inside the mouthpiece. But then I would still need some way to transform the relatively small movements of the pressure plate into larger movements for the optical sensor to have enough range to work with. I highly doubt I would be able to extract about 127 values if I leave only a millimeter of movement for the optical sensor.

I have bought some ultracheap saxophone mouthpieces to experiment with. In the end, I might need to design my own and order a 3D print, but at least I'll have some starting point. So, the main question still remains - how to design the lower lip plate (I have some plastic reeds) so that the tiny movement is translated to the movement of a reflective piece (aluminum foil) above an optical sensor and have enough springiness to move it up/down smoothly.
 
I've had a play with similar things some years back - full disclosure, I never completed it, though I'm meaning to come back to it some time!

Reflective optos are a good way to sense small position changes, though you do need to get the mechanics and electronics right. I'd strongly suggest taking a leaf out of Roland (and Yamaha's) book, and put the sensor behind a flexible moisture barrier: part of the reason my project got mothballed was condensation problems. I used a 16-bit differential ADC (ADS1115) along with a 12-bit DAC (MCP4725), so I could offset the ADC to match the lip sensor signal, then turn the gain up on the ADC to get decent resolution - I was going for the full Monty pitch bend range of ±8191 counts... That was using a Hall sensor, but opto would do it just as well. That approach basically let me get the mechanics vaguely in the right ballpark, then do the rest in software. You get a non-linear response, but that's fixable in software too, given enough resolution to start with.

Cheers

Jonathan
 
Thanks, Jonathan, for the moisture warning. In that sense, a Hall sensor might work even better than an optical one because I can completely seal it.

I found a service manual of an Aerophone AE-10. From their photos, it seems, the bar that is pressed by the "reed" doesn't actually touch any mechanism on the other end. It's just hanging over the optical sensor that's tracking the reflected light. It is mounted on a pivot point that translates the small movements of the reed to large movements of the other end above the sensor. Nice.

I wish I could buy some of these mechanical parts. I know the mouthpiece is available but it also would be great to have the neck parts and that sus bar. I looked on ebay for a broken EWI, but no luck; I guess these things are too rare and too expensive for people to sell them for parts.
 
I built my own EVI using ideas from the TeensyWI (hackaday). My solution for bite pressure is a rubber button from a Playstation controller and associated carbon tracks cut from the controller circuit. It turns out that under slight pressure, these form a great variable resistor. Attached to a piece of circuitboard material as a 'lip-pressed' spring, just under the mouthpiece, I get constantly variable output mapped to CC1 and control modulation, etc. Using it for over a year and it is always accurate, never neeeding adjustment and has always worked flawlessly.

pressure.jpg

To clarify, the button and it's tracks are housed in the little box. A hole through the 'spring' has a small plunger (a small plastic rod about the diameter of a toothpic, 3mm long) which pushes on the button ever so slightly under lip pressure.

Cheers, John
 
Last edited:
And.. for anyone interested, here is the whole thing. 5 octave range with touch sensors in the back of the unit. Joystick for pitchbend, etc. The whole thing built into a powerboard case.

TeensyWI.jpg

Happy to answer any questions :)
 
Thank you, John, for the great idea! I have an old half-broken game controller lying around, will try to see if its buttons can be used.

Looks like you have a solid device there. I'm still experimenting with software parts and looking for a simple case to avoid 3D printing while I'm not yet fully confident with my design. The powerboard idea is nice, too.
 
Let me know how you go with it! Takes a little experimenting to get the pressure range but I get smooth control (for example modulation wheel) through it's range with only about .5mm movement of the spring bar, depending how far along the levering point the 'switch' is mounted. It is very sensitive (in a good way).

The buttons you want are typicaly mounted on a silicone rubber base holding all the little black conductive contacts in place (I cut one of those out for use). It would have a rounded profile, like tiny half a rubber sphere, and be sitting on carbon coated tracks which are part of the controller board (so you have to cut that part of the circuit out). As the button is pressed, more of it comes into surface contact with the tracks because of its shape, hence the resistive effect with very small travel.

What I would really be interested in, is that I have been loooking for a way to get wireless midi. I'm hoping to fit it in the case if possible. I'd love to know more about any progress you have made there. Is it the TeensyWI you have there with USB midi out, or another design? Although I'm not really a programmer, I'm happy to share any code I have.

Oh, another idea for you.. the touch buttons.. they are the Anode caps pulled from alkaline AA cells. They have a nice center pin to solder the wires to :)

Cheers :)
 
Last edited:
... I may as well show the back of the thing :)

back.jpg

Edit: Some extra info... For the presure sensor I used an MPX2010 and built a differential amplifier from an LM358 and that works great. The original design calls for a MPX5010 but I could not find one locally.
 
Last edited:
I've done (i.e. got working but not really finished...) a wireless MIDI implementation for the Yamaha WX series of wind controllers, tested only on the WX-5. That used an Arduino Pro Micro + nRF24L01+ at each end, transmitting a continuous stream of structures giving the current status and change flags for every controller implemented by the WX. Seemed to work fairly well, but I never got round to making it properly resilient against stuck notes due to loss of comms. Of course, in that instance I was constrained by the fact that I only had MIDI data available to me. As your EWI is designed from the ground up, it'd possibly be better to read and transmit raw buttons and analogue sensor states, and move all your breath, bend and button processing to the receiver end. The nRF24L01 link latency is pretty good.

Various people do wireless MIDI converters, but you have to buy two lots so it gets quite expensive quite quickly!

Cheers

Jonathan
 
I, too, can vote for nRF24L01+.

It can be fiddly, especially if you happen to have fake modules (which I, most likely, have) and it is somewhat nitpicky about its powering and wiring, but with some software and hardware tricks you can get it working rock solid

Actually, wireless comm is the only thing I have completed for my EWI :D I just wanted to get it working reliably before I proceed. What I found is that sometimes you cannot rely on nRF24L01 built-in packet acknowledgment. It was lying to me about some packets being ack-ed by the receiver, while the receiver side actually never saw the packets! Most likely, it would work just fine in ideal powering conditions and with 100% real nRF24L01 modules, but I wanted to get it working with what I had.

So, I ended up disabling the nRF24L01 built-in ack&retransmit feature and using my own ack-ing code which essentially switches the transmitter to receiver mode and waits for some milliseconds (I use 5). If the ack does not come during the timeout, I retransmit the package. However, if sensor/button state has changed while waiting for an ack, then I send the updated state instead of the old packet.

The latency is great - about 1-2ms. However, it is important not to do anything heavy in the other side's loop(), or you'll end up increasing the latency! For example, I tried to display my packet stats on a small LCD, and it turned out to cause 50ms latency. I2C displays can be slow.

So, last week I did a stress-test sending packets between two nRF24L01 and counting losses and retransmits caused by lost acks. Half a million messages were sent, zero lost, ~100 retransmitted to get an ack. Seems reliable enough to me.

The sender side (EWI-wanna-be) is a Nano Mini Pro (3.3V edition) powered by two AA batteries with a tiny DC booster to 3.3 volts. The booster turned out to be one source of huge packet loss, but it started working great as soon as I added a 1000uF electrolytic capacitor.

The receiving side is Teensy LC connected to a PC.

I haven't yet started sending actual MIDI messages, just dummy random stress-test packets with sequence numbers to check for dropouts.

I intend to keep the EWI side as simple and dumb as possible, sending only button and sensor state. Teensy will do all the logic. I'm also thinking of adding a Bluetooth module to it, so that I can control Teensy parameters from an Android smartphone (iPhones don't do simple serial Bluetooth with third-party devices, blame Apple for their MFi requirements... You have to use BLE and fake serial communication).

If getting fancy, I might even use a small SBC computer with a software synth on it, and make Teensy do some powerful stuff, like playing automated harmonies (taking inspiration from KontinuumLab's Youtube channel).

I've heard people have tried Bluetooth wireless or even UDP network packets, but these usually have some protocol overhead and thus cause greater latency. So, nRF24L01 might be an optimal choice for low-latency, reliable (after dealing with all the quirks) and simple communication.

I'll share the fragments of my custom ack code, in case if someone wants to play with it.

The sender part:

Code: 
// in setup:


  radio.setRetries(0, 0); // delay, count
  // disable retry - will wait manually for ACKs
  // although should not care because sending as multicast
  radio.setAutoAck(false);

  // write to main, read on ACK
  radio.openWritingPipe(MAIN_PIPE_NAME);
  radio.openReadingPipe(1, ACK_PIPE_NAME);

...

// call this inside your loop() after sending a message

void waitAck() {

  unsigned long startTime = millis();

  radio.startListening();

  // assume success
  lastSendSuccess = true;

  byte payloadXorSum = xorChecksum(payload, sizeof(payload));
  byte sentPacketNum = payload[7];

  // wait for the ACK reply just a bit - as long as can afford
  while (!radio.available()) {

    if (millis() - startTime >= WAIT_FOR_ACK_MS) {
      lastSendSuccess = false;

      sprintf(buf, "Timed out while waiting for an ACK: %lu", millis() - startTime);
      Serial.println(buf);

      break;
      // give up
    }
  }

  // did we get anything before timeout?
  if (lastSendSuccess) {

    // now assume failed until we find the right ACK
    lastSendSuccess = false;

    // we might have more than one ACK - in case if some old ACKs arrived too late
    // so we read all the packets and analyze them to find the right ACK
    while (radio.available()) {
      radio.read(&ackPayload, sizeof(ackPayload));

      // ack packet has seqnum and xor checksum to ensure unique-ish packet ids
      // the remaining 6 bytes are garbage

      if (ackPayload[0] == sentPacketNum && ackPayload[1] == payloadXorSum) {
        lastSendSuccess = true;

        sprintf(buf, "ACK found in: %lu", millis() - startTime);
        Serial.println(buf);

      } else {

        // seems never happening - most likely, rf24 flushes out the received data when switching modes
       Serial.println(F("Received unexpected data for an ACK"));

       sprintf(buf, "Wrong ACK: %u %u %u %u %u %u %u %u", ackPayload[0], ackPayload[1],
        ackPayload[2], ackPayload[3], ackPayload[4], ackPayload[5], ackPayload[6], ackPayload[7]);
       Serial.println(buf);
      }
    }

    if (!lastSendSuccess) {
      Serial.println(F("No valid ACK received"));
    }
  }

  radio.stopListening();
}

The receiver part:

Code: 
// in setup: 
  radio.setRetries(0, 0); // delay, count
  // disable retry - will wait manually for ACKs
  // although should not care because sending as multicast
  radio.setAutoAck(false);

  // write to ACK, read on main
  radio.openWritingPipe(ACK_PIPE_NAME);
  radio.openReadingPipe(1, MAIN_PIPE_NAME);

...

// call this inside your loop() after receiving a message
void sendAck() {
  byte payloadXorSum = xorChecksum(payload, sizeof(payload));
  byte sentPacketNum = payload[7];

  ackPayload[0] = sentPacketNum;
  ackPayload[1] = payloadXorSum;

  radio.stopListening();

  radio.write(&ackPayload, sizeof(ackPayload), true); // true - to not wait for ACK

  radio.startListening();
}


Some other pieces of code for helper functions and variable definitions and includes:


Code: 
#include <SPI.h>
#include <nRF24L01.h>
#include <RF24.h>
#include <printf.h>

#define RADIO_CE_PIN 9
#define RADIO_CS_PIN 10

const byte PIPE_NAME[5] = {'a','a','a','a','1'};

RF24 radio(RADIO_CE_PIN, RADIO_CS_PIN);

// wrapping-around short sequence number 
// to detect missed packets on the receiver side
byte seqNum = 0;
byte lastAckTimeMs = 0;
bool lastSendResult = true;

// 6 bytes of some random data, 1 byte of last ACK time in ms (expected less than 255) and 1 byte with seqnum
byte payload[8];

// just for printing stuff
char buf[100];

byte xorChecksum(const byte* array, int size) {

  byte cs = 0;
  for (int i = 0; i < size; i++) {
    cs ^= array[i];
  }

  return cs;
}
 
Last edited:
Thank you both for all your input and ideas. Both the idea of sending the button presses and analogue sensor states to be processed at the receiver, and the code to use for the RF24.

Admittedly I had given little thought to the ‘off-instrument’ midi generation but it may be an appealing path to take. I’ll pick up a couple of RF24 boards to experiment as I have never used these before and as I said, I'm not really a programmer so it may be slow going :). In the meantime I'll also review some of the control options I would like to improve in my EVI. For example, I have a number of VSTs that have options for things like growl, flutter, and other dynamics which I currently can’t choose on the fly as I only have breath, bite and a joystick (currently for pitch bend and portamento).

I also want to continue to experiment with different techniques to measure lip pressure as well other controls. The pressure variable resistor is working very well, but options would be nice. The EWI approach with the two metal strips forming a variable capacitor, does work by just using one of the touch pins on the Teensy but the output is quite noisy… I may investigate that further as I think the NUevi uses it too and a simple solution if I can get it to work. Optical sensing appears mechanically delicate and possibly prone to misalignment, at least with what I could build. I think a viable option would be a Hall Effect sensor and magnet arrangement, but I am trying to understand why this has not been used in commercial units.. perhaps I am missing something, or maybe it’s just a matter of economy. Anyway, for now the resistive solution still works the best and is the easiest to implement!

Edit: Just saw the 'Smallest Ewi' video at KontinuumLab's channel on YouTube. Lots of work has gone in it and lots of great features I'd love to have. Having said that, I dislike the form-factor.. not my cup of tea at all. It would be nice to get the build details to make one to my liking though :)
 
Last edited:
Found some of the buttons I still was keeping as spares. They are actually labelled as "R" for resistor.. I had forgotten about that!

buttons.jpg
 
Last edited:
Interesting. I'm wondering if there is something special about PS controller buttons, and other generic game controllers might have worse quality buttons that do not work as reliable variable resistors.

Regarding the optical sensor - it might depend on calibration a lot. Initial zero position calibration can be done every time when your software boots.
Roland's Aerophone has different calibration profiles, and one of them works for both pitch up / pitch down. Essentially, by default, the reed is slightly pushed down, and when you put your lips around the mouthpiece it goes up a bit. So, you can get both up/down directions as on a real saxophone by relaxing/squeezing the reed and depending on how you calibrate your zero. But I've heard that some people 3d-printed their own reeds and experimented with calibration a lot to get the best out of their aerophone. Also, I've heard Roland has somehow improved it in their latest Aerophone Pro models, but I haven't yet seen any teardowns or service manuals for those.

I'm too wondering which one would be more reliable - an optical sensor or a Hall sensor to achieve high accuracy in a small movement range.

It's difficult to think of any reliable sensor that can translate the tiny reed movements directly into a usable range of electric signals. Maybe it would be worth trying a piece of Velostat-like material? KontinuumLab has a video with some experiments, but I'm not sure how reliable and accurate it would be if squeezed under a reed, considering that we need an accurate zero to avoid off-pitch notes etc.

I guess, Roland came to the same conclusion and that's why they are using the lever for increasing mechanical amplitude. Akai, on the other hand, completely ditched the idea of sax-style reed and created their own "biteable" mouthpiece that has enough mechanical movement.
 
I have no automatic calibration on the pressure sensor as it is effectively off when pressure is not applied so there is really no need. I spent a lot of time initially trying to find a solution for my own use but admittedly it is a bit left of center. The reason I would have liked an alternative is that it would be nice to use a sensor which did not rely on mechanical electrical contact, but perhaps it is just a whim. I am waiting for some non-latching hall effect sensors, I think they would work with a lever system similar to the Roland to get the full range. I had given thought to a commercial unit but each have their drawbacks. The EWI USB has no real advantage over my DIY unit, the Solo is ridiculously large, the others are too expensive (and also very bulky). I'd like to have in built sounds for practice but apparently they are not so good anyway. Aerophones have more buttons than I need (I do not play sax) and while they look nice, the click-clack of the buttons would irritate me. I actually like the AE-01 in shape but it is more of a toy.. and those buttons again. I think I am just hard to please :)
 
Last edited:
I'm in the same boat. My main motivation is that it seems unreasonable to pay such a high price for a device that doesn't 100% satisfy me and still overpaying for features I don't need. I'd better invest more in quality software synths. In my opinion, a simple wireless EWI shouldn't cost more than a MIDI keyboard. However, the market dictates the rules - MIDI keyboards and synths are much more demanded, thus they get produced in large quantities, which makes the production cheaper. EWIs are kinda too exotic to be budget-friendly (and to release multiple models for every taste and need).

I just wish there were more EWI-friendly softsynths for Linux, so that I could run them on a small & powerful single-board computer to be fully portable. But for occasional jamming and play-along, a small laptop should also be fine.
 
Last edited:
Yamaha do use a Hall sensor for the reed sensor on their WX controllers. The service manuals are findable on the web... I’d considered adding an accelerometer / gyro for extra controller channels, but never got round to it. Reflective optos can be good for small motion detection, but do need a bit of setup to get working and are quite likely to drift over time.

Cheers

Jonathan
 
Thanks Jonathan, I don't know how I missed that! The service manual only has a reference to a HL101 hall sensor but no details on how it is implemented. I cannot find reference to this device, which is probably defunct by now, but that gives me great confidence that a sensor with linear output will work.

Can you shine any light on the reed, magnet and hall sensor placement on your own WX? That is, is the reed connected to any sort of visible linkage to the magnet perhaps? I have another Teensy 3.2 coming in the mail so that I can run some tests without disassembling what I have in my EVI.

As for synths, progmars, I have a muso friend who has given me the opportunity to have a play with quite a few. My absolute hands-down favourite, in terms of sound quality, suitability and ease of use with a wind controller and features is 'Diva'. It is available for linux as well I believe. For real instruments sounds, the SWAM woodwinds and brass instruments are fantastic with some really realistic dynamics. These are the ones I suggest are worth some research on Google.

I wish there were better Android options though (I don't have an iPhone). For portability I sometimes clip my old mobile phone to the back of my EVI, plug it in with a OTG cable and run Caustic on it. The PCM Synth is not bad and some fairly good sounds can be found online. Good for some portable practice and probably no worse than the built in sounds in some commercial wind instruments!
 
Last edited:
I remembered I had ordered a bunch of 49E Hall sensors from AliExpress a long time ago, will try to find them in my components box. Not sure, if they will be sensitive enough, but I've seen some suggestions to use them in parallel to essentially double the output. Also, some datasheets claim they can be powered from 3V.

Wondering if they will work ok without any opamp? And in general, what would be the recommended opamps (for use with sensors) that work from a 3.3V single rail?
I'm a programmer and feel very incompetent regarding electronics/mechanical design. I can solder and apply some logic thinking, but I'm still new to interpreting datasheets.

Just looked in WX service manual - it has the same approach as Roland, with a lever (sensor bar in their diagrams) pushing against the reed. I wish there was a printable working 3D model for the neck part with the lever mounting and holes. I have 3D design skills but I'm not sure if I'll manage to design it correctly, and shipping 3D printed parts in my country costs more than printing them :D

Ok, enough rambling from me, it's time to get to my breadboard and try actually doing something with those sensors.
 
Need to experiment if an amp is needed, but the LM358 will work to 3V and the dual design gives you two to work with. I am using one half for the pressure sensor and the second half could be used for the Hall sensor if needed. Simple to implement, requiring only a couple of resistors. Lots on info and circuits online :)
 
You must log in or register to reply here.
Back
Top