Interposer howto?

[oliv3r]

Hey all,

I am building a PCB that will sit inbetween an existing devices interface. The device in question is the Vappeby Gen3 Bluetooth speaker from Ikea. The UI seems to be straight forward, a couple of inputs on the MCU, with the appropiate pull-ups/downs, and 2 LED's, sitting on a ribbon cabled PCB.

I haven't traced out the specifics perfectly (working with fotos), but I was a bit too eager in my schematic I suppose. I am putting an ESP dev board in between the ribbon cable. So for the out-side of my PCB, e.g. the LED outputs, the button inputs, I don't have to do much/anything, as all the inputs etc are being taken care of. But I now wonder, between the two MCU's, is there anything needed? Both are 3v3, so no level shifting is needed, but some 22Ohms in-line? Pull-ups/downs? Or are the internal's MCU pull up/downs enough? What about when I configure the pin as an output, and let (i have no idea what the actual value is) drive the pin with 20mA? Won't that be too much for the receiver? Obviously I don't have a spec sheet, but ballparking things propably helps a bunch here.

[jwet]

Hacking at its best.  I did something like this with cheap MP-3 players controlled by a uP for them to play bird sounds on demand for a consulting project with Ornithologists here at the university.  I did a half dozen of iterations of these with different uP's and MP-3 players and it was never as simple as I hoped.

Things are sometimes simple but never as simple as you hope...  A few things worth considering before you commit to a PCB.

Look at how things are powered.  I tied the grounds of the two systems together but left the hacked devices power alone in most cases- two AA batteries.  My system ran on 4 AA's.  It would have been nice to have one set of batteries.  The device had a boost converter, that was tied in to things.  I also had to use a DPST to turn things on and off. This also creates issues if one system is powered and the other is not.  Resistors in lines (1k in my case IIRC)  could help here so logic pins don't try to drive the speaker power through ESD diodes, etc.  You may want to verify that no current flows in those circuits.  If you get into this dual power scheme, sample the Vcc of the remote devices with a voltage divider to tell how its doing, low battery etc.

Some of the MP-3 devices actually multiplexed the buttons even though there were only a half dozen- it saved them a port pin or two but made the interface much harder.  On these devices I picked up both sides of the button inputs and used 4066, quad analog switches.  This made the my system pretty agnostic to what was going on in the gadget and in the extreme, I could get away with not even having the grounds tied together.  I've seen some gadgets that interface the buttons through an analog to digital converter with the buttons shorting out segments on a resistor string to give a voltage that was interpreted by the uP- one wire.  Analog switches would even work here and don't care about common mode voltages, etc- just open and closed.  The other gotcha here was to get the timing write, enough so the muxing would pick it up but no so long that it would double count it.  The big hammer here would be opto-isolators, I never had to resort to these but they can solve gnarly level shift problems.

In one system I would get audio interference in the audio when I connected the grounds together,  I connected them with an inductor so they were tied together at DC but couldn't pick up much AC interference.  Your "switch" lines will have whatever the ESP32 Vcc has on it.  This was probably due to the headphone output on the MP-3 player not being circuit ground but some kind of floating bridge tied load ground.  Watch these things- might not apply.

Another source of head scratching is auto power off and auto wake up.  Think through how the two systems will know what the other is doing.  It may be possible to see what the state is on the other system by making your digital output an input temporarily and probing for a pull up resistor being high, etc.

Another gotcha can be injecting clicks and pops on transitions.  Resistors in line can help  here.  You might want to measure with a DMM set to current, how much sink and source current it takes to close buttons and use a bit more.  Injecting too much current might create clicks.

Good luck- hopefully it will just work!

[I wanted a rude username]

This might be an obvious question, but ... you have built a prototype of it on a breadboard first, right? Using an ESP32 breakout board, FFC breakouts to connect the ribbon cable(s), etc.? You're not just going to have a PCB manufactured before even making sure your assumptions about e.g. pinouts are correct?

[oliv3r]

> This might be an obvious question, but ... you have built a prototype of it on a breadboard first, right? Using an ESP32 breakout board, FFC breakouts to connect the ribbon cable(s), etc.? You're not just going to have a PCB manufactured before even making sure your assumptions about e.g. pinouts are correct?

Well ... so I know for certain the pinouts are correct, as it's printed right on the silk-screen

However, You are right in saying I have not bread-boarded it. I know I should ... But I'm doing 4 other PCB orders so I was just gonna skimp this one in there.

One very correct point I overlooked, but I also realize can't be an issue anyway, is power supply. The 3v3 that is available, might be turned off in standby, but that's actually not true, as the buttons will work regardless.

I did consider if the 3v3 is powerful enough to source enough for the ESP32. Might need to add additional power pins and steal power from a different port. I saw USB power test points, so there's at least 5V as well.

Here's my current schematic and I'll probably add another power connector in case the 3v3 is to puny.