If doing it this way, then the process of "Update the chip firmware first, then cut the JP4 Jumper" will then also have to include "desolder the 470uF cap at C16 after updating the firmware". And save the cap if you ever want to do more firmware upgrades.

So my current setup of the Betz board is:

- JP4 cut after updating firmware.
- 470uF cap at C16 removed after updating firmware.
- IISC pad from Empeg goes to PCM_CLK on Betz+WT32i via a 4.7k/10k voltage divider.
- IISW pad from Empeg goes to PCM_SYNC on Betz+WT32i via a 4.7k/10k voltage divider.
- IISD1 pad from Empeg goes to PCM_IN on Betz+WT32i via a 4.7k/10k voltage divider.
- RX from controlling CPU goes to TX on Betz+WT32i.
- TX from controlling CPU goes to RX on Betz+WT32i via a 10k/10k voltage divider.
- 3.3v from controlling CPU goes to BATT on Betz+WT32i.
- 3.3v from controlling CPU goes to ENA on Betz+WT32i.
- 3.3v from controlling CPU goes to 3v3 aka VDD_IO on Betz+WT32i.
- 5v not connected on Betz board.
- Betz 2 pole slider switch set to the down/right/off position.

Also the code has been updated a bunch lately at https://github.com/tfabris/BlueGigaEmpeg - a bunch of bug fixes and optimizations.

Thanks for all of that.

I just noticed the photo you have in git, and have a suggestion for you: put a blob of hot-melt glue on top of the wires/chip where they leave the I2S pads on the empeg mobo. Otherwise the solder joints will eventually fail.

Cheers

Thanks so much! I will add that to both the real thing and to the instructions.

I just need to say this: Tony, you are doing a totally awesome and awe-inspiring job on this thing. I dunno who else will want it, but it looks like you are having a lot of fun with it and perhaps learning more than a few things too!

Way well done, Dude!

I didn't get to my empeg implementation over the holidays, and something rather more life important has come up in the interim which could distract me from it for some time yet. So for now, the Arduino way is the only way.

Cheers!

Hey, Mark, I have more EE type questions if you have a moment. You've been so helpful with this in the past despite saying you're not an EE, so I'm hoping you can give me some ideas about this one.

I was originally powering the arduino and the Betz board both with 5v from the pololu. 5v out from the pololu, goes to 5v on the Arduino, 5vin on the Betz board, and 5v input on the MAX232 chip.

But when I switched to 3.3v then I needed a 3.3v source of power. I found that when the arduino is getting its voltage from the 5v pin then it's not putting out 3v on its 3v3 pin. In order to make the Arduino put out 3v on that 3v3 pin, I needed to power it from the VIN pin or from the USB port.

So I switched it so that I was powering it from VIN and then all other 5v stuff is being powered from the Arduino's 5v pin as output. But that wasn't enough, for example the 5v pin was now not supplying enough voltage for my MAX232 to fire up (it needs 5 volts and now the Arduino wasn't supplying enouugh).

So I split the difference and powered the Arduino from VIN with 5v from the Pololu and also powered the MAX232 with 5v from the same pin of the Pololu. That works most of the time except when things are cold (literally cold in the car and the BlueGigaEmpeg assembly is cold). After things warm up it all works. But I need it to work when cold too.

the Arduino always works no matter what I do the problem is getting that 3v to the Betz board from the same power supply. When things work badly the Betz board reboots itself a lot. I think it's because of too little voltage from the 3v3 pin on the Arduino.

So I'm wondering if what I need to do is figure out how to supply that 3v3 myself instead of depending on the Arduino's voltage regulator to be good at the job of putting out 3 volts.

I don't want to put in a whole other power supply but I'm wondering if you have any ideas about other ways to supply those 3 volts. For instance, would another voltage divider work there, or should you only do a voltage divider for signaling and not for a power supply?

To complicate matters, I want a system which is compatible with debugging the arduino via its USB port, plugging the USB cable into the Arduino while the whole assembly is also plugged into the empeg (pololu powered by the 12v from the tuner connector).

Looking for ideas.

A resistor based voltage divider won't work, because of Ohm's Law again. Eg. if we used even 200/100 ohms for it, Mr.Ohm says Voltage must equal Resistance * Current(I), or V=IR.

So 3.3V/200ohms = max current of 0.165A (16.5 milliamps). At first glance, that might even be enough current, but sadly the WT32i also has (internal) resistance that must get factored in.

The result being, that to use a resistor voltage divider for this means really small resistors, and therefore high current and very HOT resistors. As in, melting, unless you get special ones.

So, a resistor divider won't work here -- it's really only useful for tiny current draws (Ohm's Law again).

The simplest solution is to just feed 5V into the USB connector of the Arduino. That's how I've been powering it in the car: USB cable from the USB ports in the car to the Arduino board. In your case, it would be 12V to your PSU, and then a chopped-up USB cable to transfer 5V from there to the USB connector on the Arduino.

Note that with I2S digital audio, you no longer need a separate/special PSU to get nice audio.

That's an interesting idea, I'm going to experiment with that. Thanks!

I wouldn't necessarily need a chopped up USB cable, I could just jumper to one of USB pins since they seem to be through-hole on the Arduino board.

Would this scheme still allow me to hook up both the pololu and the USB cable to the computer at the same time while debugging?

Another idea that has occurred to me is that, when I was going into VIN on the Arduino, maybe I'm just not supplying the Arduino with enough "baseline" power to drive everything from its voltage regulators. I think that pin is supposed to accept 7v-12v and I'm simply doing badly by only supplying it with 5v. Maybe I should switch to a 7v power supply to the Arduino's VIN and see if that fixes everything.

Mmm.. interesting thought. Would need the schematic for the Arduino board to know if Vin is any different from 5V on the USB connector.

Note that you can supply 12V to Vin if you want. The regulator on the Arduino board will get warmer as a consequence. I think we covered this earlier in the thread though.

Ah, yes. Just looked at the Mega schematic, and Vin does feed INTO the 5V regulator. Which means the 5V regulator won't be outputting 5V (it has a minimum drop of perhaps 1.5V, resulting in about 3.5V output, which then reduces the output of the 3.3V regulator as well.. not good).

Vin needs to be at least 6.5V, or probably at least 7V.
Using the USB connector bypasses that, allowing a 5V feed.
This method has the advantage of also being compatible with out-of-car usage.

Cool, thanks so much for that excellent information!

I've got a temporary jumper from the 5v output pin of the Pololu to the 5v pin of the USB connector. It works and seems to do what is expected, though I haven't tried it when things are cold yet, this is all on the test bench. With it powered by the Pololu like that, can I still safely hook up a USB cable to the computer simultaneously? Sometimes I have to debug while things are powered.

I think that long-term, if the Arduino Mega board is going to be my 3.3v source, then I need a 7v power supply instead of a 5v power supply. So I could swap out the Pololu from a 5v one to a 7v one, I'll bet they'll have one with the same pinouts, I could look.

Would another option be to get a small linear regulator that takes 5v in from the existing pololu and puts out 3.3v, much similar to the one on the Betz board that takes 5v and turns it into 2.5v?

Okay the change to the power supply didn't fix the "cold boot" problem.

I futzed with it a bit and I was able to repro the problem on the test bench after chilling the assembly. And the thing that fixed it was...

Futzing with the I2S pins. (Specifically, gently touching the I2S pins with my finger.)

So I think that the I2S voltage dividers is the culprit. Removing those.

You're sure the empeg I2S runs at 3.3v and you're sure I won't fry another chip by running these things without a voltage divider?

Gonna try it... Crossing fingers....

Hm. With the voltage dividers removed, it ran for about 30 seconds quite nicely and then the audio started to crackle. I yanked power at that point.

Hm.

Okay, I tried going the other way with the voltage dividers.

Instead of the prior 4.7k/10k which would have resulted in 2.25v from a 3.3v input, I tried 10k/10k which results in 1.65v from a 3.3v input.

This seems to be working now on the test bench, without the crackling. Next, to test a true cold boot. First, chill then put on the test bench, then, put in the car overnight and see how it does in the morning.

Crossing fingers!

It passed the chill test with the 10k/10k resistors and the original power scheme (Pololu powers VIN). We'll see how it does in the morning after it's spent the night in the trunk in the cold.

Passed the test in the morning!

The 10k+10k voltage dividers on the I2S lines solved my cold start problems.


Current working setup of the Betz board is:

- JP4 cut after updating firmware.
- 470uF cap at C16 removed after updating firmware.
- IISC pad from Empeg goes to PCM_CLK on Betz+WT32i via a 10k/10k voltage divider.
- IISW pad from Empeg goes to PCM_SYNC on Betz+WT32i via a 10k/10k voltage divider.
- IISD1 pad from Empeg goes to PCM_IN on Betz+WT32i via a 10k/10k voltage divider.
- RX from controlling CPU goes to TX on Betz+WT32i.
- TX from controlling CPU goes to RX on Betz+WT32i via a 10k/10k voltage divider.
- 3.3v from controlling CPU goes to BATT on Betz+WT32i.
- 3.3v from controlling CPU goes to ENA on Betz+WT32i.
- 3.3v from controlling CPU goes to 3v3 aka VDD_IO on Betz+WT32i.
- 5v not connected on Betz board.
- Betz 2 pole slider switch set to the down/right/off position.

In my case I’m getting the 3.3v from the Arduino by powering it with 5v on Vin, and it’s workimg even though there should be 7v on the Arduino Vin.

Thanks so much for all the help and advice!

State of the project:

I have one minor software issue to iron out that I should have fixed by tonight some time.

Hardware wise, I’m ready to create a final PCB design which is based on the idea of piggybacking onto the Betz board. However that might not be feasible for reselling because I’m not sure Peter Betz can supply any more of these boards or not. I might need to create a board where I’m soldering the wt32i onto it myself.

Then I 3D print a nice enclosure and I’m done and ready to sell kits.

I don't think so -- the two PSUs (Pololu and the computer) will fight each other and Bad Things(tm) will happen!


Just use 5V through the USB connector. It is simpler for probably everyone, since most cars have more 5V sources than 12V sources these days, and those that don't can be updated with a simple plug-in dual 5V thingie.


You already have this. It is on the Arduino board.

I suppose you must be thinking about the boot/trunk area here, where you'll likely be tapping into some existing 12V wires? In which case, yeah, you can use the 5V Pololu PSU you have, but I would still wire it to a USB cable and then plug that into the Arduino's USB port.

This method is also the safest way to go, as it guarantees one can never have two power sources fighting (burning) each other at the same time.

Okay, most humble apologies are in order.
After failing to discern the I2S output voltages from either the schematic or the datasheet, it finally dawned on me that I have the means to actually measure them. Quite accurately.

I am seeing around +6V on those lines. Which is pretty amazing given that they come directly from the empeg's DSP chip, which is mostly a 3.3V part. But it does have 5V power as well, and the 5V must be a bit closer to 6V I guess.

So.. dividing it in half (10K/10K) is absolutely the correct thing to do here. And my misinterpretation of the output is undoubtedly what fried your first two boards. My bad.

My preference is always to measure when possible, rather than theorize. But measuring voltage of a rapidly changing digital output is difficult. Unless one has an oscilloscope. Just didn't think of using the darned thing. Until now.

Or at least your first Betz board. The original devkit board maybe only partially, as it has (had) that onboard I2S chip that was fighting for control of the same pins.

No need to apologize. Without your help I wouldn't have even had the courage to try the I2S pads at all, let alone knowing how to set up a voltage divider to make them work in the first place. This whole thing has been a great chance to learn new stuff that excites me. The stuff I've learned in this process, and your specific bits of advice along the way, is what made me cautious about the I2S lines at the end there, and to try different voltages for them to see if that would solve problems. That's why my last test with the lines connected straight was done with my hand on the power connector ready to yank it out at the first sign of trouble. That's what saved that most recent Betz board from being a third victim.

It's really good to know now, for sure, that it was the I2S voltage that fried the prior chips, and also that it was the source of some other problems I was having with the unit. With that all solved I've got much more confidence to move forward. And of course, it's going to help you quite a bit in your version of the project. Thanks for for putting it on the scope and getting a solid confirmation.




Alas, I cannot, because...



I need that USB port for debugging with the computer simultaneously while the unit is powered from its normal power source. A few different situations require this, not the least of which is having the empeg and the BlueGigaEmpeg both mounted in the trunk while I futz with debugging pairing/bootup/serial problems in the driver's seat. (I have a long USB cable run up from the trunk.)

However right now, with the 5v Pololu driving the Arduino VIN, everything is working fine, so I'm good with what I've got. It's awesome.

But.. the laptop will be powering the board over USB during debugging.. so why not?

And if you do stick with power separate from USB, then there's a small chance of frying a laptop over the USB cable..

I figured you might ask that.

Because some of the things I'm testing and debugging are timing sensitive and are based on tweaking code behaviors that occur when the empeg power is initially applied. Under normal runtime (without the USB cable) the BGE module gets its power at EXACTLY the same time as the empeg does, and I need to test and adjust behaviors at those times. In fact, some of the code changes that I just checked in a few minutes ago are related to that very situation. In real life, I don't have the time to go trundling back to the trunk to plug and unplug that goddamn molex connector each time I want to test that.

Also, since the power is carried on the same molex connector as the I2S audio, if I had to do my debugging with it unplugged, then I wouldn't be able to debug any of the audio behaviors. Not to mention that questions like "am I frying my chip" are a lot harder to answer. The fact that I was listening to the audio when testing the changes to the I2S voltage dividers is what saved that last chip. Without the capability to connect I2S+Power and USB at the same time, I might have fried the chip, since I was trying to monitor bootup messages at the same time.


There is one interesting trick I have to do, which is that if the Arduino is already powered by the empeg over that molex connector, and then after that I plug in the USB cable, the computer doesn't detect the USB-serial device. This happens with either Macs or PCs. So I have to do an interesting little dance if I want to debug startup timing. I have to plug in the USB cable first, let the computer detect the USB port, then press the button that launches the Arduino Serial Monitor. The act of launching the serial monitor resets the Arduino chip which in turn resets the BlueGiga chip (via a software reset command). If I press that serial monitor at the same time that I apply power to the empeg, then the timing of the empeg bootup in relation to the BGE assembly bootup is very close to the same as the timing of applying all power to everything at once. It's a bit of a silly dance, but necessary for some of the stuff I've had to debug.



Thanks for that warning, that's worth being concerned about.

However, as log as I'm powering it from VIN on the Arduino, I haven't had a problem with it, at least not yet so far. Not sure if that's just because I've been lucky or if it's because the Arduino circuitry is cleverly designed for precisely this kind of situation. The fact that the computer doesn't detect the USB-serial port unless I plug it in first makes me wonder if it's because of the latter.

Thanks!

PS: New code is available at GitHub. Implements the feature where there is a global variable that keeps track of whether or not the Bluetooth is connected and streaming. Also, since the 3.3v design doesn't require the resetline pin 51 trick, I've removed that code too. If it turns out that we need that code again, we can pull it from the code history in GitHub.

Here, do me a tiny favour: Power the empeg from Vin, and measure with a voltmeter the voltage at one of the +5V pins on the Arduino.

Then, plug in a laptop over USB (with Vin still connected), and measure it again.

Thanks

3.9V on my setup. Not quite enough for reliable operation of the Arduino, which wants 4.75V to 5.25V. Interestingly, this was enough for the Arduino's onboard 3.3V PSU to output a full 3.3V.


Here, the measured voltage went up to 4.8V. Then, I connected an inline current measuring device on the Vin line. Current draw was about 0.06A, until I connected the "laptop" USB in parallel, at which point current draw doubled to 0.12A. Which means it is very likely back-feeding some current to the laptop (not good).

This was expected, as one can measure voltage as "present" at the USB connector with Vin connected and nothing else. So it definitely is going to try and harm any PC that gets plugged in.

Note: I did not actually risk a laptop, but rather used a USB power dongle instead.

Arduino Mega reference design schematic is here:
https://www.arduino.cc/en/uploads/Main/arduino-mega2560-schematic.pdf
The boards we have may or may not match this schematic.

Mark, thanks so much for this important information. I'm so glad we're getting to the bottom of all my design issues.



About the same for me: 3.86 volts when the empeg is powered off the car's voltage.

Thing is, this works great for me. The Arduino has been very stable in all my tests. But you're right, it would make better sense if I could figure out how to do this properly.




Mine went up to 5.06v.




Is it possible that a laptop might be different from a USB charger? For example would a laptop have protection against reverse current?




I am using this one: https://www.amazon.com/dp/B01H4ZLZLQ/ in case it's relevant.


So here's the question, then. If I need to rethink the power scheme again, how can I do it so that it meets my needs? Specifically:
- Normally powered from the tuner connector, in the trunk, connected to the empeg that is also in the trunk.
- Can leave a USB cable plugged into it in the trunk which I can reach from the front seat and plug into a laptop for debugging from the driver's seat, with no need to unplug/replug anything in the trunk.
- Design needs to be something I can fashion into an easy kit without having to heavily mod the Arduino. So ideally any weird stuff would ideally go into my own PCB sandwich/shield board.

Right now what I've got is working for the above. Though you have shown me evidence that I merely got lucky with that, and I'm running a risk. So what to do?

My first thought is to power the Arduino into its 5v pin from the 5v power supply and then do something like an additional linear regulator to get the 3.3v. But that would just run the reverse-voltage-up-the-USB risk worse (it worked when I tried it before though).

There is an interesting circuit in the original BlueGiga dev board design which allows it to get power from the USB or from VCC correctly, and automatically switch. I don't understand it though, and I'm not sure how to implement such a thing on my board and whether it would even help in this situation.

Any other ideas?

Thanks again for all your help.

Peter got back to me and he's going to produce another small run of boards and so I should be good there.

Any lurkers in this thread want to chime in and say "I'd want a kit of this when it's ready" so that I have an idea of quantity?

LOL, Pad2Pad just sent me an email with details of how to do Plated Through Hole. They must be lurking in this thread. :-)

I don't need it at the moment since Peter Betz said he was going to make another production run of his boards, but it's a great thing to keep in mind.