Here's a 2.5V regulator that should work as a direct replacement on your board, for 73 cents (CDN$) each:
https://www.digikey.ca/product-detail/en...CBCT-ND/1979849

That one uses the same capacitors, and is good for up to 250mA of current draw. You could order a handful of those and replace the one on your board to see if it then comes back to life.

Or search Digikey for a very similar 3.3V version, using this as the search string there:

3.3V regulator SOT23-3

Then click on "PMIC - Voltage Regulators - Linear" as the category in the search results.

Yes. The {0} strings that we already capture and use, are the Bluetooth MAC addresses. The first three digit pairs should identify the manufacturer of the head unit.

So for the Harman head-unit in my Subaru, we would check for A0:56:B2, which is the vendor ID for Harman/Becker Automotive Systems GmbH.

Thank you so much, Mark!



Always OK. One of the nice things about posting on the BBS is that there's no obligation for anyone to answer immediately until/unless they want to. Of course there's no obligation to answer a tweet, an email, a text, or a phone call, either, but those each seem to carry increasing levels of urgency. I kind of see BBS posts as the bottom of that hierarchy.



I'll give it a try for that board and see if it solves the problem. Thanks so much for the information about which part to order.

I think that, long term, the resistors are a better idea because they don't involve desoldering a surface mount device on one of our components. I could also design the resistors into my final PCB for the external box design, which would make assembly of future units much easier.

Your plan for the resistors, are you thinking entirely inline, i.e:
Empeg SCK -> Resistor -> BlueGiga SCK
Or would it have to be two resistors in a voltage divider configuration?



Aha, that's the secret I didn't understand. So you think that too-high logic levels might fry the chip? If that's what fried it, replacing the voltage regulator on the chip might not fix anything, but it's worth a try since those items from Digikey are cheap.

Thank you!

Yeah. So we'll fix the logic levels with resistor voltage-divider circuits, and add a third resistor to each as a safety measure.

So.. I have something in mind like this, but need to build/test it first, and figure out the exact resistor values required.


EDIT: To clarify, I suspect something to do with the too-high logic voltages probably caused the failure. On your board, the 2.5V regulator appears to be dead as a result of Something Bad. And the I2S signals of the WT32i also seem to have died -- directly attributable to the high logic levels.

Cool!

How important are the exact values? I happen to have a large pile of 10k's and 100's here but not any of those particular values. I could parallelize or serialize to get the exact values but that starts to get annoying in terms of the number of resistors.

Either way I could definitely test this arrangement.

Is arrangement you've illustrated a directional thing? In other words, does it only work if the supplier is one spot and the receiver is in the other? Or could it also work in reverse?

I ask because I'm not sure who's who out of each of those three pins we're using.

The three I2S lines are all transmitted from the empeg and received at the WT32i. So each of those would need a circuit something like that to reduce the empeg's 3.3V signalling down to 2.5V or so.

So if I get this correct (unlikely with my current mental faculties, but..), the ratio we need is 2.5/3.3 == 0.75.

So the value of the rightmost resistor, divided by the sum of the left+right resistors, should be about 0.75. I would suggest choosing values that keep the total of left+right in the 5-15K range.

Get it?

The third resistor on the tap, is there as a safety, in case something goes cuckoo. It will ensure there can never be a dead short (aka. "zero ohms"), should the polarity of a GPIO pin accidentally be programmed incorrectly. I'm not sure what value to use, but 300 is a good start.

EDIT: Duh.. scrap that one entirely -- the first two resistors already provide oodles of current limiting. So just get rid of the 300ohm thought altogether.

Cool!

So with a 5k and a 10k in your illustration that gives us 2.2v output from a 3.3v input, according to an online vDiv calc I found. That should do well, right?

I could either buy some 5Ks or I could double up on 10ks in that spot.

I ordered a pack of 4.7k resistors which, combined with the 10k's I've got, would give 2.245v output which I am guessing should be good for signaling voltage.

One would hope so. Again, the necessary info is in the WT32i datasheet. It says (page 13) "VIL input logic level high" should be between 0.625xVDD and VDD+0.3, where VDD is the supply voltage, or 2.5V in this case.

So.. 0.625 * 2.5 = 1.56V is the minimum, and we should treat VDD (2.5V) as the best maximum. Anywhere in between could work, but the higher the voltage the better it ought to behave with faster changing signals like I2S. So I would guess that anything over 2V would be good enough.

The only question is, have we got the overall resistance values too high? Would 2.5K+5K be better?

Undoubtedly a real EE like Patrick could tell us, but I prefer to just fry try it!

I will try this when I get my next Betz board in.

In the meantime, updated the code at https://github.com/tfabris/BlueGigaEmpeg

Removed the "KillAllLogging" variable. It turns out that the existing statements in the code which say "if (Serial)" were sufficient for my goal. So simply unplug the USB cable from the arduino if you want to kill all logging.

Thanks. I expect to be idle on this for a few days now, and pick it up again after the Jolly Guy leaves.

Cool. I have a reliably-working system at the moment, albeit with analog audio instead of digital, and I'm just doing a lot of software touch ups. I'll keep reporting my changes here so you know what to expect when you get back to the project.

Speaking of which:
https://github.com/tfabris/BlueGigaEmpeg
- Moved explanatory text into README.txt file.
- Add behavioral flag reconnectIfBadRegistrationReceived
- Experimentally change the code which resets the bluetooth if a bad PDU registration is received to a hopefully-quicker version. (Edit: reverted, it didn't fix the issue.)
- Add behavioral flag performResetLinePhysical - Set to true if you want to use the reset line.
- Add behavioral flag digitalAudio - Set to True to use I2S audio, set to False to use analog audio.
- Add behavioral flag logLineByLine - Set to True to log a line at a time instead of a character at at time.
- Added time profiling to each output line in line-by-line logging mode. Each line is preceded by a delta, in milliseconds, from the prior output line.
- In the log output, label bluetooth module's output lines which are deliberately ignored by the DisplayAndSwallowResponses function.
- Increase RX buffer size requirement to 256 to help with the full-player-shuffle bug. Mostly helps.
- Refactor some of the string handling in the code to work around Arduino memory bugs that would occur when very long track titles came up.
- General bugfixes and refactoring.
- More cleanup of code comments and README.txt file.
- Mark Lord's required security mode, which is yes/no prompt mode, is now the default mode for the BlueGigaEmpeg, and the code automatically answers the yes/no prompt. It can even answer the prompt when outside the pairingmode process.

Update on the state of my Betz board.

I got the replacement 3.3v power IC in and replaced the one at position U4.

The chip worked and responded correctly to commands afterwards. It paired and maintained a steady connection. This was better than before.

However it had problems still:
- I2S input still did not work or produce audio. I didn't really expect it to, but I was hoping.
- The chip ran pretty hot.

So this isn't a good solution, and I should have a new Betz board soon. I will make sure that use the voltage divider circuit we discussed on the I2S inputs on the new Betz board so I don't fry it.

Do you have a more solid idea of how we could make the chip reset line work without frying it? Should it just be another voltage divider with two 10k resitors?

The datasheet for the WT32i (a great source of info) recommends using a diode when connecting to the RESET pin. So we should do use one there, AFTER the two resistor voltage divider that is also needed.

So.. yeah, the proper way is two resistors as usual, and the output from those to the WT32i then passes through a small diode to guarantee correct direction of current flow.

Cheers

So do you think it should be two identical resistors for a 50% voltage divider?

Any particular specs on the diode?

Yes, 50/50 for the two resistors if converting down from 5V to 2.5V. For the diode, any "small signal" diode will work. I have no specific recommendation -- myself, I'll just grab whatever I can find in my parts bins, or rob one from an old motherboard or whatever.

The kind that are commonly spec'd for use with Arduino relay controllers would be fine -- you might already have some of those.

Cheers

Thanks very much for the info about the voltage divider and the diode on the reset line.

I've included the instructions for that reset line and its accompanying voltage divider and diode in my README.txt. I haven't implemented it yet, but when I get the new Betz board in later this week, if it's needed on the new Betz board I will implement it then. If I don't seem to need it on the new Betz board (I didn't need it on the last one as long as I was powering it off the Pololu), then I will run things for a while without it. I'll make sure that the digital inputs are running stably and last a little while for me without the reset line, then I'll try implementing it and see if my chip blows again. If it runs stably with the new reset line configuration, I'll include it in my final PCB design.

By the way, if you look at my latest code, the Reset line code is now implemented as a separate function, but the code is temporarily disabled behind a boolean flag at the top of the code: "performResetLinePhysical". To use it yourself you'll need to flip that flag to true.

I have another question about my schematic that you might be able to help me with.

I'm using the attached schematic from this page for my MAX232 circuit. It's wired as follows:

MAX232 Pin 1 and 3 aka C1+/C1- - Bridge with a 2.2uf ceramic capacitor
MAX232 Pin 4 and 5 aka C2+/C2- - Bridge with a 2.2uf ceramic capacitor
MAX232 Pin 2 aka V+ - Connect to Pololu 5v via a 2.2uf ceramic capacitor
MAX232 Pin 6 aka V- - Connect to GND via a 2.2uf ceramic capacitor
MAX232 Pin 11 aka TTL-I1 - Connect to Arduino Mega Board 18 aka Tx1
MAX232 Pin 12 aka TTL-O1 - Connect to Arduino Mega Board 19 axa Rx1
MAX232 Pin 13 aka 232-I1 - Connect to RS-232 plug pin 3 aka Tx
MAX232 Pin 14 aka 232-O1 - Connect to RS-232 plug pin 2 axa Rx
MAX232 Pin 15 aka GND - Connect directly to GND
MAX232 Pin 16 aka VCC - Connect directly to Pololu 5v

I'm using 2.2uf capacitors for all of this because of a note in the datasheet. I'm using this MAX232 chip from Digikey, and when I look at the datasheet for the chip, I see the following note:



So that's why I'm using 2.2uf ceramic caps.

So far so good. My question is about the last capacitor "C5" in the attached schematic. It simply bridges 5v and Gnd with a capacitor. (I'm just using another 2.2uf ceramic capacitor there.) I'm wondering (a) why is this cap there in the schematic at all, and (b) if that is having an adverse affect on my board/circuit since it's bridging the 5v rail that everything else is running off of. Any ideas or recommendations related to that capacitor?

Thanks!

Without looking at the datasheet (lazy today), I'd say that 0.1uF cap is there for "decoupling" purposes. It is quite common to add such a capacitor between GND and Vcc (+5V) for each chip in a circuit, as close as possible to the GND/Vcc pins of the chip.

The purpose seems to be to smooth out any voltage fluctuations that might otherwise be caused by small instantaneous current draw as the chip switches internal states and whatnot.

https://learn.sparkfun.com/tutorials/capacitors/application-examples

So it's there just to keep the +5V supply "clean" and stable.

Cheers

Cool thanks!

So you're saying it's normal to put a voltage stabilization cap physically close to more than one component on the same board, even though they'd all be working off the same +/- rail, and that doesn't adversely affect the components?

Does the value of the cap there at that particular point matter much? I'm using a 2.2uf there at that point.

It's a relatively minor thing on the whole. It does need to be very close to the pins it is "protecting", so that it can react and smooth the voltage before minor spikes/dips reach the chip itself. Or emanate from the chip.

0.1uF is the most commonly used value that I remember. Bigger values don't stop shorter (more common) spikes.

But really, this will will all work even without it.

Cheers

I've got a pack of Radio Shack 1N914-type diodes. Would these work?

They are the same kind as listed here in this ad:
http://www.bakersfieldads.net/Bakersfiel...ckage-of-50.JSP
Photos from that page attached, not my photos but mine look just like that with the same specs.

Seems to be similar to, though not exactly identical to, this Digikey part:
https://www.digikey.com/product-detail/en/on-semiconductor/1N914/1N914FS-ND/978749

Also, I'm working on Rev 4 of my board design and including the reset line in the design.

I'm triple checking here, though I'm pretty sure I have all this correct already.

The thing you're connecting pin 51 on the Arduino to is the "RST" pin, pin 16 on the edge of the Betz board, which is immediately next to the 3v3 pin, pin 15 on the Betz board, correct?

And you put your "smd_2_pole_switch" on the Betz board in the Down/Right position, correct?

This is the schematic for that connection in my current design, is this correct?



All good?

Yes, that all sounds right.
But do note that I have not yet wired up the resistor/diode circuit for testing, so I don't know if it actuall works. It won't harm anything regardless.

Those diodes are fine.

Cheers!

Yep. My intention is to test it too, once I'm sure that everything works without it first.

Thanks so much!

Pro tip: When cutting the trace at JP4, be extra careful not to peel up the pads or to cut other nearby traces.

I accidentally peeled up the pad on the USB side of JP4 and this broke a trace coming off the side of that pad.

Turns out that the main connection between "+5v" and "CHG" goes through that trace to that pad. If you break that trace or pad, your board won't ever power up and you have to make a jumper wire between +5v and CHG.

My replacement Betz board seems to need the reset line (my first one didn't).

So I'm going to try to implement it. Can you explain more about your reasoning for your code for the pullup/pulldown code?

At startup, your code did:

pinMode(51, INPUT_PULLUP);

Then delayed for 300ms then did:

digitalWrite(51, LOW);
pinMode(51, OUTPUT);
digitalWrite(51, LOW);

Then delayed for another 50ms then did:

pinMode(51, INPUT);

My questions are:
Should the default state of pin 51 be "INPUT" most of the time?
Why the "INPUT_PULLUP" at first then?
And why the 300ms delay after the INPUT_PULLUP?

I think I see what you were getting at.

Instead of saying digitalWrite(51, HIGH) for a moment to trigger the reset, you instead did INPUT_PULLUP briefly instead to trigger the reset. The rest was just to put it back in the standard input state.

Now that I've got the voltage divider and diode circuit implemented, then I can trigger the reset with a short burst of digitalWrite(51, HIGH) and it should work. It does in my tests (the pullup didn't work any more with the voltage divider circuit).

I'm running into a different problem with this replacement Betz board that I can't figure out.

It mostly works, including its I2S digital inputs.

But sometimes the RX/TX serial communication with the arduino does not work.

When I power it straight from the UART with nothing else connected but the USB cable, it works. I can upgrade its firmware and type commands in putty and whatnot, and everything looks right.

But when I power it with 5v from the 5v pin, I get garbage on the serial port, everything it sends to the Arduino is mixed with random garbage characters. It can work for brief periods but then stops working again.

No chips are getting hot or anything.

If I plug in both the Arduino into one USB port and the Betz board into another USB port (with JP4 disconnected) then everything looks correct on the serial port. It's almost like it needs two 5v supplies to keep it going or something.

Except... that last thing also eventually stopped working.

Wondering what I've done wrong here. :-)

More information.

When powering the Betz board from its USB plug with JP4 connected and the UART powered (Arduino disconnected), I get working clean serial communications in Putty from that same USB plug. In this state, voltage on the 3v3 pin reads about 2.5 volts, and voltage on the 5v pin reads about 4.8 volts.

When connected to the Arduino, with JP4 disconnected and the UART unpowered, powering the Betz board and the Arduino both from my Pololu power supply which supplies 4.95-5.05 volts to the 5v pin, I get either nothing on the Arduino serial port from the Betz board, or expected text mixed with garbage characters on the serial port. Voltage on the 5v pin reads 4.95-5.05 volts, and voltage on the 3v3 pin reads 1.37 volts.

My TX pin from the Arduino to the Betz board is going through a 10k+10k 50% voltage divider. The RX pin coming from the Betz board to the Arduino is not.

The thing that seems to control whether I get "nothing" on the arduino serial port from the Betz board, or whether I get "something" on the arduino serial port from the Betz board, is the position of that SMD 2 pole switch.

When it is in the down/right position, I get nothing.
When it is in the up/left position, I get something.

When I get "something" it is either:
- The expected text mixed with garbage characters if I do NOT have power applied to the Betz board USB port via a USB cable.
- Fully perfect text if I DO have power applied to the Betx board USB port via a USB cable.

In the latter state, with the Betz USB port being supplied power via the USB cable the 3v3 pin reads about 2.5 volts.
In the former state, with the Betz USB port NOT being supplied power, the 3v3 pin reads different voltages depending on the position of the switch. Down/right: 2v or less, Up/left: 2.5v.