Mmmm.. I suppose one might have gotten the wrong pin -- the labeling on the board is really poor on that side. RST is the 7th pin.

.

That's a decent sign actually. Might just be a dead regulator, which isn't really a catastrophe here. Those are cheap and not too difficult to replace.

I still haven't figured out how this board should be wired, but they definitely took a few short-cuts. Mine behaves better now with the slider switch in the position furthest from the USB connector. The Arduino reset takes care of things nicely there.

Dangerous to have it in there charging, as we don't know yet where the fault is. If you can charge it some other way, and then power the board with just the battery, that could tell us something.

Can you explain more what your thinking was for the "INPUT" and "INPUT_PULLUP" modes on the reset line? I was doing some code refactoring, trying to put that code into a subroutine, and I tried different approaches to those. Perhaps I left it in the wrong mode for too long or something.

I was just trying to avoid having to have a pair of resistors similar to the serial pin. It is okay to drive LOW (ground) on the reset pin, but NOT okay to drive HIGH (+5V) on that pin.

Since the Arduino has an internal pull-up resistor available (INPUT_PULLUP), I used that instead of "HIGH". A pull-up is just a suitable resistor (eg. 50-100K-ohm) connected between the pin and +5V internally. It would still give +5V for a very weak current draw, but won't pass enough current to harm stuff.

When the pin is later programmed to plain "INPUT", it actually has a very very weak pull-down (to ground) resistance.

So the simple code I supplied just puts a high pulse onto the reset pin for a few hundred milliseconds, and then pulls the pin down to ground and leaves it there.

Safe so long as one never drives HIGH on that pin.

Cheers

And in order to drive it high, it would need to have been set to OUTPUT, right? Something I didn't do.

I may have left the pin in INPUT or INPUT_PULLUP for longer than 300ms. would either of those have hurt it?

In other news:

I tried powering the Betz board with about 3.2v coming out of the "3v" pin on the arduino and into the "3v3" pin on the Betz board, with the 5v pin disconnected from the Betz board. Didn't solve the problem and the board was dark.

If I power both the 5v and 3v3 pins on the Betz board it light up. Trying to see if it works normally now.

v523 was new today. That's the one.

I thought that the issues I was reporting were with V523. Though now I must retry because now I'm not sure any more.

In the meantime: Powering both 5v and 3v3 pins on the Betz board makes my chip work, but it gets warm. Warmer than I expect it to get, though not scalding. Warmer than I recall it getting before.

Do you think that's an issue?

The board would need to be somewhat rewired in order to operate it with straight 3.3V. Which is a shame, because the WT32i module itself would be quite happy with 3.3V.

But the way they've wired things doesn't adapt nicely to it. And for such a simple schematic, they've really gone out of their way to make it difficult to read! Especially the power wiring.

Actually, I don't think you can hurt much stuff with both 5V and 3.3V fed to the board. The voltage regulator might go up in smoke, but I think the rest is okay so long as the FTDI chip isn't powered up. And even it might be fine.

The VDD_IN pin of the WT32i connects directly to the "3.3V" pin, and that's perfectly safe to do. I'm just not understanding the VDD_CHG and VDD_BAT pins, and what should really be done with those. The datasheet gives a couple of suggestions, but my head hurts and I'm retiring for the night now.

Cheers

OK thanks for all your help!

More information:

Since the chip seemed to get warm when I connected 3.3v, I looked at the Betz schematic, and what the schematic says it expects on that pin is actually 2.5v despite the "3v3" on the pin name. I was wondering if 3 volts was a hair too much and what I should really be trying is 2.5 volts there.

So I thought, hey, I've got 5 volts here, I can just do another 50% voltage divider to get 2.5 volts. So a couple of 10k resistors and now I had what I thought should be 2.5 volts heading into that 3v3 pin.

But that's not what I measure there. With everything hooked up, I'm getting about 60-70mv on that pin if the switch is in the down/right position, and the LED blinks steadily and the unit won't wake up. And with the switch in the up/left position, I get a varying amount in the range of 100-170mv on that pin, and the LED is dark and the unit won't wake up.

Hmph.

Current state:

I tried it out connecting the Betz board to both 5v and 3.3v supplies at the same time.

Chip sorta worked. It connected and exchanged data with my bluetooth headset. I could issue pause/play commands from the bluetooth headset (the only thing the headset will do).

However there was no sound. On a hunch, I hooked up some RCA plugs to the analog input pins on the Betz board and switched the line in the code to route the audio to internal instead of I2S. I got sound. Switched it back to I2S, no sound.

Also the chip keeps reporting that it's receiving random "AVRCP PAUSE" and "AVRCP PLAY" commands even though I'm not issuing them from the headset.

So I think I'm back to the state I was with the BlueGiga dev board: Fried I2S input and no idea why.

Is there a chance that we are missing some kind of buffer circuit or even simply a voltage decrease between the empeg's I2S outputs and the chip's I2S inputs?

[SLEEPWALK]
I'll have a look at that (I2S) later. But I don't think there's a problem with it.

For the RST pin, the WT32i datasheet suggests a diode rather than a straight wire. This implies that the pin might also be an output from WT32i in addition to being an input.

I'll investigate that later too, but for now best to leave the RST disconnected until I've had another look on the weekend. Or if you have a general purpose small signal diode, use it. The WT32i datasheet has a diagram somewhere with the polarity.
[/SLEEPWALK]

Yeah. Welcome to Ohm's Law.
If you measure the voltage at the midpoint there with nothing else connected to the midpoint, it will read exactly half of the input voltage. But only because the voltmeter has a high impedance (resistance here), and doesn't suck more than a microamp or two.

A voltage divider (two resistors) works only for a tiny current draw. Because of Ohm's Law, a tiny current draw will still yield close to the desired output voltage. But draw more current (like.. powering a bluetooth chip with it) and E=IR says that the resulting voltage drop through the resistor will be high, leaving nearly nothing left.

Or something like that. The only way to make a resistor ladder work here is to use SMALL resistors, so that they can conduct more current with minimal voltage drop. BUT "more current" means more waste (heat) in the resistors, and that's not great either so don't do it.

My sleep-impaired brain says there is a simpler (meaning, more correct) way to explain it:

The WT32i board is also a "resistor", or at least so from the point of view of its power supply. So that resistor, or "internal resistance", needs to be included in the calculation for the resistor ladder you are building. Except the WT32i is a variable resistor, having different internal resistance depending upon what it is doing at any given point.

This makes it nigh impossible to power with a resistor ladder, unless the resistors you choose for the ladder are significantly lower than the internal resistance of the WT43i, so that its resistance doesn't throw off the ladder's value too much.

Same result though: do NOT attempt this. it will likely draw too much current and fry the resistors (literally: smoke). Eg, if you used two 100ohm resistors, then even with nothing connected to their midpoint that circuit will draw (5V / 200ohms) = (0.0925amps, or 25 milliamps. The heat generated would be (5V * 0.025amps) = 1/8watt. Which is just enough to fry the typical small 1/8W resistors used with Arduinos and such.

Get some sleep, Mark!

I've just wired back up the original BlueGiga dev board, this time with analog audio instead of I2S and it's working well. My original BlueGiga dev board also has no working I2S either.

I have a choice in powering this system, and I've tried both and both work, and I'm wondering what your opinion of this is:

Option 1:
- Pololu voltage regulator's 5v output goes into VIN on the Arduino which goes into the Arduino voltage regulator.
- Everything else (5V input on BlueGiga board, Max232) are powered off the 5v rail coming off of the Arduino.

Option 2:
- VIN on Arduino is not used.
- Pololu voltage regulator powers everything and connects to everything's 5v rail, including Arduino's 5V rail, Max232, BlueGiga board's 5v input, everything.

Both have worked but I don't know which is correct.

Mark, I hope you got some sleep. I hope I get a chance to also.

Thanks again for all your help with everything. You've been awesome.



Now that I've got things working with the old BlueGiga dev board again I had a chance to retest V523. (Well I stayed up past 2am to get the assembly working again and I decided to stay up a little extra to test things too.)

Here's the current issues I'm seeing with V523:

- When the player is paused, the Z (source) and D (duration) data do not come out the serial port for the current track, they come out the serial port for the next track. Repro steps: Pause player. Press Next Track. Z and D do not come out at first. Press Next Track again. Z and D come out now, but they are not for that track, they are for the previous track. On the car stereo screen, the Album title is shown that is the album title from the previously-played track while all the other track metadata is for the current track.

- When the player wakes from sleep or the player has recovered from a low voltage event, this is a fresh reboot of the Arduino and the Bluetooth chip. This can also happen when you are listening to the stereo in Accessory mode and then you start your car, causing the voltage to drop briefly. When this happens, the deduplication feature does not allow the player application to repeat its track data to the serial port (usually it does repeat it in these situations). This results in "Unknown track on Empeg Car" on the car stereo screen quite frequently. This did not occur with V522, there was always the correct track on the screen after any sorts of power events on the empeg player. Repro steps: With the player connected and playing, sleep and then wake the player from its front panel. The bluetooth will disconnect and reconnect, and when it reconnects, it will say "Unknown track on Empeg Car".

- The deduplication feature prevents me from being able to key off of any single particular piece of serial port data or even any particular sequence of serial port data (since, when paused, there are no time sequence ("#") lines coming out) to decide when I have a full track data set and can flag the host stereo that new data is available. This results in my code having to flag the host stereo for every line of new track data. For each new track this can be up to 5-7 repeated "TRACK_CHANGED" notifications instead of just one. For a single track change, or maybe two or three, this is OK, but pressing "next-next-next-next-next" on the player front panel in quick succession is enough to overload the host stereo and make it stop getting new track data altogether. This is only necessary in V523; in V522 with single notifications then the host stereo eventually caught up and multiple track changes didn't seem to confuse it.

I think the last two mean that we should go back to non-deduplicated (but keeping all your other improvements) and I'll fix the full-player-shuffle issue in a different way in the code. I think that trying to fix those last two issues would be just too complicated for Hijack and out of its scope. What do you think?

Thanks again!

By the way, I have just now updated the BlueGigaEmpeg code on GitHub to be the version that works with V523. It's possible that some of the track desynchronization issues you had yesterday were due to the fact that I hadn't uploaded a version of the code that was compatible with the deduplicated Hijack version.

It also contains your Pin 51 reset line code, though it is disabled at the moment (commented out and/or with a return statement preceding it, depending on where in the code you're looking).

If you want to re-enable the reset line, look in the code for all occurrences of the variable "ResetLinePin" and make the necessary changes near those points.

Also the version up on GitHub is configured for analog input instead of I2S input at the moment, change the corresponding line if you want to switch it to I2S.

Hijack v524 is now available.

-- gets rid of de-duplication of serial notification lines.

Thank you! Grabbing it and installing it now.

Thank you so much for helping so much with this project. I don't think I could do this without your help.

I have tested V524 and all the issues that I reported before are fixed.

Thank you!!!

Current code up at https://github.com/tfabris/BlueGigaEmpeg is written to work correctly with V524.

Changes you might need to make to get the code working for you after you download it:

- The reset line pin 51 code is disabled or commented out, search for "resetLinePin" in the code to locate all the places. I will make a note to fix this tonight, so that it's a single flag variable instead of having to fish through the code.

- The code is currently set to use analog audio instead of I2S. Search for "SET CONTROL AUDIO" to fix this if you need it fixed. I will also make a note to turn this into a flag variable.

- My code still uses a different security method than what you succeeded with. I will make a note to see if I can set it that way for my devices too, then we can both use the same security method.


I'm really interested in hearing how you are doing with this, now that you've got successful connectivity.

I have a set of PCBs on their way from Pad2Pad which should make assembling one of these devices pretty easy. I could send you one if you like! I also ordered a couple more Betz boards in case I fry more boards.

Thanks so much!

We should be able to just key off of the Manufacturer ID from the head-unit's MAC address, and then auto-select the appropriate security method based on that. The same type of identification could then be used for any other system-specific tweaks that might arise.

I believe the "3 0" method is the best, and should remain the default.

Cheers!

I am not doing much with it just yet. My goal with the Arduino setup was to get the pairing working with a setup as close as possible to yours.
Now that this is happening, I am going to capture some more traces, help identify/fix any glaring issues, and then work on an empeg-only implementation for my setup.

Things are more than a bit "complicated" here just now, so it could be a while before I get back onto it again, though I do hope to try with your latest code drop ASAP.


Thanks for offering the PCBs. I'm not sure I would make much use of one though, as I will be moving the Betz board inside the empeg sometime in the next couple of months. [EDIT]For now I have just hot-melt glued both the Arduino and the WT32i to the top of the empeg. [/EDIT]

Ah yes, we do have to stop boards from dying so quickly there.
One suggestion I have (untested yet) is to just stuff resistors inline with each of the I2S connections. This will limit current draw in the event of a wiring or logic mistake, hopefully preventing things from frying quite as easily. Not sure of the value to use: usually people seem to employ resistors in the 100-300ohm range for that kind of thing, but perhaps even 1-Kohm would work.

To figure it out exactly, I can look up the current draw by the WT32i for those pins, and apply Ohm's Law to that along with 3.3V, and choose a resistor value that doesn't drop the voltage below a logic "1" threshold.

Or maybe there's a better way? One could go extreme and use opto-isolators to completely protect the WT32i. Or perhaps just simple diodes to guarantee correct flow direction?

Cheers

I'm sorry to hear that things are complicated in your life. I hope that when they simplify, they do so in a positive way.

Your idea about using resistors to prevent I2S from hurting the BlueGiga module sounds useful. I'm not entirely convinced that the I2S voltage is the root cause there, but since I2S has definitely gone nonfunctional on two chips for me so far, it's certainly the right place to start looking.

Thanks so much!

Feel free to subscribe to updates at https://github.com/tfabris/BlueGigaEmpeg to get notified when I make code changes or update the bug list.

Mmm.. I originally thought the WT32i was powered at 3.3V on the Betz board, but since we now know it is only 2.5V, this could be part of the problem.

3.3V is quite a bit more than 2.5V, and might need downconverting (resistor pairs again). It might even be simpler to just swap out the regulator on the Betz board for a proper 3.3V one. You could do that to repair your dead one as well.

So you mean like, not necessarily figure all of the manufacturer's best schemes ourselves, but rather, default to the original scheme but add special cases to a table which changes the security scheme for each new special case we discover?

As long as it's not a catch-22 (as long as we don't need to be paired already to read the MFR ID), then that sounds do-able. I'll make a note to try that.

You mean this puppy dog, right? He's the little transistor next to the 5v pin on the Betz board right?

Willing to try it. Do you have a Digikey part number to recommend? Would the caps need to be replaced too? It would be a pain to have to replace it on every board (I have this idea of making this a kit) but if it's necessary to keep the I2S from failing then we should do it for sure.

Can you clarify your thinking as to why making the chip's voltage higher would increase its reliability? I'd think that, if the I2S lines are coming in with too much current to begin with, then increasing the overall current into the chip would just make things worse. This might be a place where I can learn more EE knowledge from you about that particular situation.

Later, much, if that's okay. I'll have to look one up, and check the datasheet for the capacitors. But the onboard ones are probably just fine regardless. The tricky bit is to find an LDO (Low Drop Out) 3.3V regulator in that "package" size (SOT-23-3 ?). For sure they exist.

No, we can achieve the same effect with a bunch of resistors on all of the interconnect lines. But for your semi-dead board, this would be a simpler fix.


The idea is to keep the signals coming from the Arduino "in spec" for the WT32i. Referring to the "Absolute Maximum Ratings" I posted earlier, the acceptable logic levels on inputs to the WT32i must be no higher at any time than the supply voltage plus 0.3V.

So with a 2.5V supply voltage, we have to limit the serial RX and the I2S lines all to less than 2.8V. If we ran the board with a 3.3V supply, then the I2S lines would meet the spec without anything extra required.

But of course, at 3.3V, the WT32i ends up running 32% warmer than at 2.5V. Tradeoff. The resistors are probably the way to go, but wiring up so many of them starts getting messy too.

Cheers