Making the assumption that the schematic was correct, I tried implementing it and I am cautiously optimistic. It seems to solve the issue and I haven't seen any bad effects yet. Will try to live with it for a while and see how it goes.

Thanks!

Yes, your before/after schematics look good to me.
And good to hear that it has an effect, too!

I just think it's pretty freaking amazing what a few resistors here and there can accomplish! Thank-you Mr.Ohm for laying down the Law!

Cheers

I'm running into some new problems with the initial bootup and connect of the module. I have been trying software fixes but they're not working, so it might not be a software fixable issue. I am not sure if it's related to the 2.5v voltage issues or not. But I'm now thinking of experimenting with putting one of those 3.3v linear regulators on my new replacement Betz board (in place of the 2.5v one at "U4" on the schematic).

My prior Betz board, I had done that, but only after I'd already fried the I2S inputs on the chip. And then when I tried to put 3.3v into the thing it got real hot.

Did you say that you'd already done the 3.3v regulator swap on your Betz board, and that yours did NOT run hot when you did that? If so, I'll try it on mine.

I'm also thinking of ditching the Betz board altogether and going for getting a bare WT32i and a bare FTDI chip for programming it. Looking at the Betz schematic, there's not much there than what I'm already implementing on my interface between it and the Arduino:

- The aforementioned linear regulator with two 0.1uf smoothing caps.
- The FTDI chip with 0.1uf caps on its reset pin and DTR pin, and two 47pf caps on the incoming data pins from the USB plug.
- An LED and a resistor to watch its LED0 pin.
- The C16 470uF cap on the BATT line that I'm not sure is needed (is it?).
- A few connections such as VREG_ENA to BATT, some grounds, and the connections to the FTDI chip.

Everything else I don't need: Most of it is analog input stuff that I won't be using. The few other connections which are needed, I'm already implementing via my interface board to the Arduino. Does that seem about right?

I have not done the regulator swap on my Betz board yet. But the reference devkit board uses 3.3V, and the datasheets are all fine about it.

The Betz board does some funky stuff to get their +5V USB input shifted down to 2.5V for powering the logic. It looks to me that there ought to be no issue changing the regulator for 3.3V, but if I were you I'd experiment more on the semi-fried board first, and maybe compare temperatures with the semi-fried devkit board you also have.

The PDF datasheet for the WT32i is required reading if you want to go for the bare module. It shows exactly what is needed.

Cheers

Sounds good.

If I am successful at powering it with 3v, do you think that we should need to change any of the voltage dividers?

Is it risky for me to try powering at 3v without changing any of the existing voltage divider configuration? (Am I risking the chip being fried, or merely risking that the inputs won't do anything with the existing voltage divider configuration?)

The existing voltage dividers should all be fine with 3.3V. And the pull-up you added for Arduino-RX is still harmless but also not required.

Ideally, those voltage dividers should all get adjusted from 10K/10K to 20K/10K. But the existing 10K/10K should continue to work.

No risk in leaving as 10K/10K as you say, other than that the inputs might be less reliable than they would be with 20K/10K. Really though, I expect everything to just work as it always did. The 3.3V empeg I2S would no longer need any resistors.

Cheers

Hey, Mark, can I please have some more EE help?

I'm confused about something on the WT32i datasheet.

I'm going by this document:
https://www.silabs.com/documents/login/data-sheets/WT32i-DataSheet.pdf

My current goal is to try powering the chip entirely from the already-regulated 3v line coming off the Arduino. I'll cut the CHG_ENA jumper on the Betz board and/or simply not supply any voltage to the Betz 5vin pin (both will accomplish the same thing based on the Betz schematic).

It looks like, if I'm going to power the chip with pure 3v and not use the BATT or CHG lines, then that is theoretically supposed to be supported on the WT32i datasheet since there's a sentence saying so.

It says in section 6, "The module can be powered from a single 3.3 V supply provided that VDD_CHG is floating." Great, that's what I'm planning to do: Supply it with a single 3v supply and completely disconnect VDD_CHG.

I think I might need to do this:

- 3v into VDD_IO, definitely.
- (some unspecified amount of voltage) into VREG_ENA? (Not sure the dox aren't clear.) Can that be the same 3v too?
- Not sure what to do with VDD_BAT - I think I should supply 3v to that one too?

I'm pretty sure I need all of the above because the serial communications are driven off of VDD_IO but the radio is driven off of VDD_BAT which powers an internal voltage regulator that gets activated by power on VREG_ENA. That's great, but there is nothing in the datasheet that indicates what voltage is expected to be applied to VREG_ENA and what its limits are.

However, there's this confusion. It has a warning which says:

"Figure 10 shows an example how to arrange power control when on/off button is not implemented. VREG_ENA pin must not be connected to VDD_IO because leakage from VDD_BAT to VDD_IO will prevent VREG_ENA to fall low enough to turn off the internal regulators."

But... Figure 10 is in fact illustrating an On/Off control. The sentence says "When on/off button is not implemented", but then Figure 10 has a part on the drawing that says "On/Off Control". That's opposite of what the above sentence says. True, it's in a different spot than on Figure 9 (Figure 9 shows a temporary pushbutton), but it's still an "on/off control" of some kind. In fact the title of Figure 10 is "Figure 10: Correct and wrong connection for the power on/off control". So the datasheet is contradicting itself and now I don't know what to do.

What I want to do is take the 3v pin from the Arduino and supply 3v to the WT32i from that pin. I don't think I should need to go through yet another voltage regulator to supply power to VREG_ENA. And looking at Figure 8 seems to indicate that there's a voltage regulator inside the chip, which is connected to the OUT of the battery charger. That makes sense that leakage from that would cause problems there in the ENA pin of that internal regulator. But the instructions are weird, they say "leakage from VDD_BAT to VDD_IO will prevent VREG_ENA to fall low enough to turn off the internal regulators" but that's the opposite of what I want: I want the internal regulator ON all the time so that the chip never turns off.

Is it simply that I need to supply 3v to all three of VDD_BAT, VREG_ENA, and VDD_IO, and since I'm powering it up 100 percent of the time, ignore that warning in the datasheet about not tying to tie VREG_ENA to VDD_IO?

Can you tell based on the data sheet, specifically, figures 8, 9, and 10?

Thanks!

I am not an EE. Just a firmware/Linux kernel guy.

What a confusing datasheet. It seems to assume that we always will want an on/off control of some kind. Here, we don't.

So I would just connnect the 3.3V power supply directly to VDD_BAT, VDD_IO, and to VREG_ENA. The datasheet specifically says "don't do that", but only because they assume we might want to use a switch to control on/off without unplugging it completely. We don't.

And yes, leave VDD_CHG floating (not connected to anything).

If you are hacking the Betz board for this, then also cut the connection from the 2.5V regulator (or remove it).

EDIT: And I'm not 100% sure that we need to connect anything to VDD_BAT. Try it without that first. Page 10: VDD_BAT is required.

Cheers

Thanks a million!



Closer than I am!




What if I just set the little switch on the Betz board to the down/right/off position? Then BATT is not connected to ON which means that the voltage regulator does not have any input voltage at all. Would that also suffice do you think?

(I'm trying to design a system whereby I can still update that chip with the UART built into the Betz board if needed. I don't expect there to be any new software updates, but I'm thinking I might experiment with adding an APTX_LL license to the the thing.)

Give it a go and see. The WT32i will be fine, but I had once had a similar situation with a board that had a "dangling regulator" on it, and the regulator got rather warm, sucking a LOT of current, somehow, for some reason. Dunno why.

So just check to see if the regulator gets warm or not.

Cheers

Working so far, no hot chips, either the WT32 or the linear voltage regulator. More testing...

Thank you!

Okay!

Here's what I've got so far:

- The scheme of 3.3v going to BATT, VDD_IO and VREG_ENA all tied together worked perfectly.

- To get the 3.3v I had to change the way I was powering the Arduino. Before: The Pololu supplies 5v to everything, including the 5V rail on the Arduino and the 5V rail on the Betz board. After: Pololu only supplies 5v to the "VIN" pin on the Arduino, and then the Arduino's voltage regulator puts out both 5V and 3V on its 5v and 3V pins. The 5v pin powers the MAX232 chip and the reset/pair button, the 3V pin powers the Betz board into its 3v3 pin.

- Simply not supplying any voltage to the 5v pin on the Betz board (having it disconnected) worked.

- Throwing the 2-pole switch to the down/right/off position worked, and it was not necessary to cut the connection to anything. No voltage to the linear regulator that way. (I haven't tried finding out what happens if I turn that switch to the On position).

- No hot chips!

- Digital I/O works.

- 2k Pullup resistors on the WT32i TX line are no longer needed, serial data is clean now without them.

- I'm still leaving the voltage divider in place on the RX line of the WT32i though. That is also working.

- Here's a fun one: The reset circuit with the diode and the voltage divider, and the corresponding reset line code, are no longer needed. The chip powers up and stays powered without needing the reset button.

- The red LED on the Betz board does not light up any more. I don't know if that's because the voltage going into it is only 3v now instead of 4v, or if it's because the LED0 pin on the chip no longer does its "stuff" in "pure 3v always on" mode. In any case, that LED is no longer important to indicate anything we need to know. The chip Just Works now and it's always powered as long as we apply power to it.

- All of the above, converting this thing to run on 3v, solved several intermittent problems I was having with its behavior and pairing. It's now working and pairing reliably.

I'll be updating my docs/code shortly with all this information. Right now the docs still have stuff about the reset line and the pullup resistor and such.

I have a few remaining issues in software and hardware design, feel free to browse https://github.com/tfabris/BlueGigaEmpeg/issues if you're curious. After I solve a few of those I'll do another round of PCB design.

So, no voltage divider is required on the I2S lines now either, as those are 3.3V logic already. You can leave them if you're (rightfully) paranoid though.

If you drop the switch to the other position, the LED should light up, and the reset button will also become functional again (though not needed for anything).

Dunno if that would bugger anything else though. It should be fine with VDD_CHG floating.

It is great to see it all back at 3.3V now, which is what the WT32i really wants for easy interfacing. I can power mine from the 3.3V output of the empeg (near the I2S pads).

Cheers

Awesome!

One caveat:

When I said that there was no problem with the linear voltage regulator at "U4" on the Betz board, with 5v left floating and 3.3v on the BATT line...

I'd already tried replacing that linear voltage regulator with another 2.5v one from Digikey since I a had a package of them from trying to fix the last Betz board. It happened to run at 2.6v instead of 2.5v and that actually solved some of my problems but not all of them. Then I said screw it and decided to go all the way to 3.3v.

In other words, my successful results are based on that U4 having been replaced with another model of theoretically the same specs.

So what I'm saying is, take my results with a slight grain of salt and check your own chips for heat before committing.

Separate question for you, Mark.

I have a backup Rio Car player (calling it "red" because it has a red lens) that I'm trying to use as a secondary testbed for testing the BlueGigaEmpeg. It has a very interesting problem that I'm not sure what's causing it, and I wonder if it's Hijack related or not.

Preconditions:

- Player is a Rio Car.
- Player software version installed is 2.00 Beta 13.
- Player has Hijack v524 installed.
- Hijack is configured for "Player Uses Serial Port" under "Serial Port Assignment".
- Player config.ini contains the following items:

- Player is connected to serial port and is working and looking correct in general.
- Player is not connected to BlueGigaEmpeg.
- I2S pads, on the inside of the player, are connected to the three tuner connector wires we agreed on (purple, gray and pink) based on my instructions in the BlueGigaEmpeg README.txt. Though these do not have to be connected to anything to get the repro of the problem.

Symptoms:

- Player boots normally and plays music correctly.
- Viewing the boot process on the serial port with PUTTY I see all of the empeg bootup messages clearly without any corruption. I see all the IDE test messages and I see "Hijack: intercepting config.ini" clearly.
- After seeing the message "Prolux 4 empeg car - 2.1434 Jul 24 2002", which indicates the player app has started, I stop seeing any messages/data being put out on the serial port. All the messages that I'm used to seeing with the @@ signs are not showing up at all. There is silence on the serial port.
- If I type commands into the serial such as "w" "c" "p" "n" etc., they work correctly. The player receives the commands and it does the correct thing (playing, pausing, etc.).
- I can type Q and get to the shell prompt and that works normally, all I/O works fine. I also see things like "Vcb: 0x4086d000" when I exit the shell and go back into the player.

I don't see this occur on my main Empeg Car unit. I get all the serial port messages on that unit.

Clearly I'm missing something about the way this player is configured. Something about how to make the serial port track data messages appear that I'm failing to do on this player that I did on the other player. Do you have any idea what that is?

Thanks!

Seems to have been caused by case sensitivity on one or more of those section headers. On a whim, changed it to:



Now things work!

Oh, good. But that is a rather old release on Red. Why not V2-Final ?

V2 final and V2 Beta 13 were nearly identical, but there were some minor regressions in V2 final that didn't exist in Beta 13. I've been running 2.0 Beta 13 for years. There was a specific regression that I encountered regularly that was in 2.0 final that wasn't in 2.0 Beta 13.

Problem is, I don't remember what it was now, it's been so many years. I seem to vaguely remember it was in the tuner section, which I don't need any more, so maybe I should run 2.0 final.

I use v3alphaXX on pretty much everything here. It has the better audio path, as you discovered last year.

I had a ton of problems with synchronization with Emplode when using V3 alpha (lots of broken databases), and since I didn't need FLAC I stuck with version 2.

Can you tell if the code in BlueGigaEmpeg is working well with version 3 alpha on your systems? Since it depends only on the messages which come out on the empeg serial port, if those messages are unchanged in V3 Alpha, then it should work fine.

The strings it triggers on at various points are:

Detecting that the empeg unit is starting up and hasn't launched the player yet:


Detecting the player has started:


Detecting a status message or track metadata message:


If those strings are unchanged in V3 alpha then in theory it should work fine.

Even after the 3.3v conversion, I'm running into some troubles when "cold booting" the module, literally.

It's mounted in the trunk and it gets cold in there. When it's cold the WT32i tends to shut down and/or reboot itself. I don't think it's the WT32i's fault, it might be QC issues with the Betz board. When I first got the board, it worked for a while and then one of the Vias stopped conducting current and I had to make a jumper. I'm wondering if that's happening for other connections now, being exacerbated by the cold.

I'm thinking of developing a board to which I solder my own bare WT32i and FTDI UART (for loading the latest firmware onto the chip). I was hoping to avoid SMD soldering but it looks like I might have to bite the bullet.

My question is: How do I solder a chip that doesn't have any pins? I mean look at this picture: https://media.digikey.com/Photos/Silicon%20Labs%20Photos/WT32I-A-AI61.JPG

There are some solder pads sticking out from the edges on the Betz board but it looks like they go tuck under the chip's "base board" and I can't actually reach the contact points, I can only heat up the pads and pray.

What's the correct procedure for soldering a chip like this with no visible pads?

Also, question about that big 470uf capacitor on the BATT line at C16 on the Betz board. If we're not using an actual battery, and instead supplying 3v directly to the chip, we don't need a big cap in that position at all, right?

Pre-prime the pads with solder, then add lots of flux and mount the WT32i. Heat up the carrier board's pads to firm up the attachment, and pray.

Or.. just don't do that. Difficult to get a high success rate.

Cheers

That all sounds overly complex to me. Why not simply look for the @@ strings, and nothing else?

Thanks for pointing me to that section of the datasheet!

Do you suppose that they mean "always have that cap" or "you only need the cap if you have VDD_CHG supplying some voltage"? It seems to be the latter, but I wonder what your more-experienced opinion is on this matter. I want to be able to design my PCB correctly, but also the most simply.





So, if there are no pins sticking out from under the edges of the bluetooth chip itself, then my PCB should be designed so that at least its blank pads stick out from under it, so that I can at least get an iron onto the pads?

This sounds really iffy because, what if, when I pre-prime all the pads with solder, I don't get them all to the same height (thickness of solder) and then some of them don't seat down fully. Then some of them never touch and there is not enough heat transferred to get the solder to bond. It seems like this chip was designed to be made entirely with full flow soldering, and screw us hobbyists.

Is there an alternative for hand soldering this type of chip? Maybe there is a such thing as a carrier socket for this kind of chip?





For the empeg player startup messages, I need to be able to know when the empeg is there and ready to accept commands. I also need to know when the player application has started so that I can pause the player so that it waits for the bluetooth to be connected before it starts playing the song. Otherwise it will be spooling out a song to nobody since there is no bluetooth listening. Once bluetooth connects then it will play the song. On my Honda, it takes longer for the car stereo to boot up and connect to the bluetooth than it takes for the empeg to boot up and start playing music. So if I don't do this then, each time I turn off the car and back on again, I lose something like 17 seconds' worth of whatever song was playing. It's worse if I'm turning on the car and listening to something other than the empeg, such as the car's CD player, the car's radio, or a passenger's cell phone bluetooth, then in that case the empeg would just spool out songs forever to nobody listening. So I need those player startup messages as cues to know if the empeg is booted up or not. There's still a small amount of bugfix needed in this area, but when it's all fixed it will work correctly.

For the @@ messages, I indeed just check for the @@ signs first. Then I do different processing depending on the symbol which follows the @@ signs, and if there is not a match, then that processing doesn't occur.


Thanks for your help!

I really don't know what they meant about the 470uF cap. So perhaps lay out the board with a place for one, and you can then populate or not depending on whatever?

For the pads, one alternative is to have "plated through-hole" pads, which can then be soldered from underneath. The PCATS memory upgrades used this technique. Requires a double-sided board, and plated holes also cost more.

Others here may have more ideas and knowledge about this. Anyone?

Oh the plated through hole idea is awesome if I could arrange for it from Pad2Pad. I will look up to see if that’s even possible with pads that close together.

Thanks!!

I have done some experiments and I *think* that the 3.3v direct-power scheme works best with that 470 cap removed completely.

Will run it this way for a while and see how it fares in the long term.