I kinda figured that after the fact! See what I mean, you know so much more about EE than me.

I am not likely to "manufacture" anything for this. My plan is just to get my own setup going (after Christmas), and share whatever it takes to do so.

The first rev will be the external BT dev board, connecting to the tuner connector on the empeg, most likely with I2S also hooked up through the tuner connector. The empeg CPU will do all of the control etc..

If I ever do a second rev, it will be to replace the large/expensive BT dev board with just the BT module instead, and that is tiny enough to be mounted inside the empeg (probably in a drive bay). I had been shying away from doing this, because of the difficulty (for me) of keeping clean audio paths. But with pure digital audio interconnects (I2S), that all becomes a non-factor. Thanks again, Tony!

Makes sense!

When your code uses the tuner internal serial port, it'll be accessing to the RX/TX lines internally on the empeg, correct? So you don't need those RX/TX pins to be connected externally on the tuner connector out the back of the sled, correct? So you could do like I did and disconnect those pins from the wiring header that connects them to the sled harness inside the empeg and then those can be used for running some of the I2S pins out the back of the tuner connector, like I did. Right?

If we use the same pinouts on the tuner connector, then both of our designs will be compatible. Would that work for you?

Here's the pinouts I'm using on the 8-pin molex tuner connector. Let me know if these work for you. Note that the colors listed are the externally visible wire colors on the tuner connector outside the player. The colors are different on the internal wiring header that connects to the motherboard.

1 - Pink - originally "tuner level", now disconnected from internal wiring header inside the empeg and soldered to a jumper wire which is solodered to I2S pin "IISD1" inside the empeg. This is pin 4 of the IIS header on the empeg motherboard, the 4th pin from the "notch" on the silkscreen outline. On my external board, this is connected to the SDIN pin of the BlueGiga module.

2 - Grey - tuner signal - left unchanged - No connection on my external board

3 - Blue - Power Ant - left unchanged - No connection on my external board

4 - Black - Empeg Ground - Connected to the ground on my external board, which is connected to several ground pins in various places on the BlueGiga board and the Arduino board. In particular it's connected to the GND pins on the I2S header on the BlueGiga board.

5 - Brown - originally TX, now disconnected from internal wiring header inside the empeg and soldered to a jumper wire which is soldered to I2S pin "IISW" inside the empeg. This is pin 2 of the IIS header on the empeg motherboard, the 2nd pin from the "notch" on the silkscreen outline. On my external board, this is connected to the WS pin of the BlueGiga module.

6 - Red - originally RX, now disconnected from internal wiring header inside the empeg and soldered to a jumper wire which is soldered to I2S pin "IISC" inside the empeg. This is pin 1 of the IIS header on the empeg motherboard, the pin next to the "notch" on the silkscreen outline. On my external board, this is connected to the SCK pin of the BlueGiga module.

7 - Purple - unused - left unchanged - no connection on my external board.

8 - Blue - 12v - Connected to my 12v input on my power supply regulator on my external board.


What do you think?

For the dev board, the TX/RX pins on the tuner connector will be needed. So let's leave those intact. Also, the empeg has 5V available internally, so if we feed that out the tuner connector, then there's no need for any extra voltage conversions.


So, referencing the above, pins 1,2,3,7 are all available for our use.
We should keep 4 (GND), 5(TX from tuner), and 5(RX to tuner).

There are enough leftover pins to use one of the remaining pins for +5V in addition to keeping +12V, and still have three pins for I2S (SCK,WS,SDIN).

So, how about you decide the final assignments within those constraints?
If for some reason we end up needing another pin, then we could put +5V in place of the +12V on pin 8.

OK, I'll change which pins I'm using. :-)

In the meantime I have another code update with some more bug fixes and minor behavioral changes. I'm trying to get the initial boot-up and connection procedures to behave as cleanly and quickly as possible.

https://create.arduino.cc/editor/tfabris/4c5eea9a-1462-45d7-908d-81a5bb6b0d90/preview

Once you guys get all the wrinkles worked out, I will definitely be doing this. I'm not in any hurry, but at some point in the next 18 months or so I'll be in the market for a vehicle and would love to have the empeg running again (right now we only have the one minivan and I've been warned not to fool around with the built-in DVD system). Until then, I'll be lurking and collecting parts and having them brought down to Mexico. I've just been waiting to purchase until Tony found a board that was actually viable.

I also travel quite a bit when in the US as I visit churches all over the country. It would be great to have an empeg that I could just carry into a rental car, plug into the lighter and connect via bluetooth (ie...the fully internal option above).

Cool. We'll have the kinks worked out soon and hopefully make it into a very simple kit. :-)

An example of a kink that I have to work out (well, a bug in the empeg player that I must work around) that I just discovered:


N
serial_notify_thread.cpp: 116:@@ N10
serial_notify_thread.cpp: 117:@@ F0xf8b0
serial_notify_thread.cpp: 118:@@ TAquafin
serial_notify_thread.cpp: 119:@@ ATony Levin
serial_notify_thread.cpp: 120:@@ GInstrumental Rock

N
serial_notify_thread.cpp: 116:@@ N11
serial_notify_thread.cpp: 117:@@ F0x10640
serial_notify_thread.cpp: 118:@@ TWhere the Streets Have No Name
serial_notify_thread.cpp: 119:@@ AU2
serial_notify_thread.@@ GRock

And now it's not reproducing consistently. It reproduced perfectly before (only on the U2 track and not any of the others) and now it's not reproducing and... GRRR.

Wait, no, now It's sometimes reproducing differently. Now I see it like this:

N
serial_notify_thread.cpp: 116:@@ N11
serial_notify_thread.cpp: 117:@@ F0x10640
serial_notify_thread.cpp: 118:@@ TWhere the Streets Have No Name
serial_notify_thread.cpp: 119:@@ AU2
serial_notify_thread.: 120:@@ GRock

Grr.

Now I'm starting to suspect my own code even though the examples above are straight character-in-character-out on the serial port.... More research is needed...

So, what I see there is that it sometimes drops the "cpp" part of the string? That part alone is easy enough to ignore and deal with.

Oh, okay.. second example dropped a few more chars. Really looks like it ought to be the receiver (Arduino) at fault, but I suppose it could be a buffer overrun on the empeg TX path too.

I do seem to recall having to fix the Arduino library here for one of my projects: it had WAY too small of a serial RX buffer for my needs. Increased the buffer size, and problems went away.

Ahh.. here's the file:

arduino-x.x.x/hardware/arduino/avr/cores/arduino/USBAPI.h

Look for "#define SERIAL_BUFFER_SIZE" and make it bigger.

Thanks for that tip about the serial buffer!

I was already sure it wasn't a serial buffer problem because my code handles single characters in and out in a fast loop, and my repro was only on that one U2 song going back and forth across it. But that tip is really useful and I will keep that in mind just in case I need it later.

I have traced it down to memory overwrite problems in the Arduino program's string handling which surrounds the processing of of track metadata. To make the bug go away, I can either skip the UTF-8 conversion step, or I can skip the logging that says "Artist changed to xxxx", either way the bug disappears. So it's some sort of bug related to the way those strings are handled. I'm going to poke at it some more and get the code updated to fix the bug.

Thanks!

It could well be (1) running too low on RAM, or (2) running out of stack space (too many nested calls, too many local variables).

Using String types instead of char * for strings results in lots of added memory usage and overhead. Arduinos don't have much to burn.

I spent this afternoon writing a script to convert (most of) the Arduino C++ sketch into plain POSIX C, in preparation for trying to run it on a Linux laptop or empeg. The idea is that I just re-run the script with minor mods whenever you update the sketch.

Still poking away at it, but perhaps 75% of the way there now. The variable numbers of arguments for things like .substring and the like are giving me the most grief.

Wow, that's kind of awesome and crazy.

There are updates to the sketch today but I'm still kind of in-process on parts of it.

Then today, the BlueGiga dev board flat out stopped working. It's like it's not getting any power or something any more. And I tried it bare with just its USB cable into the UART port which used to work, but now it doesn't. I don't see any burned out components on the thing. Some time perhaps tomorrow night I'll start looking for things like bad solder joints.

Indeed, I have had that happen before in Arduino sketches. But why it would hit that condition only on that U2 album is weird. I think there's a pointer bug in some of the String functions in their compiler, and it was only triggered because the Artist string was only two characters long. I'll look through and see if it happens for other bands on my empeg which have two-character artist names. I think there might be a few of those to try, or I could edit a tag on a test song.



Totally understood, but the reason I was trying to use the String type was precisely because I didn't trust myself not to create memory-overwrite bugs when using char*. Literally the thing that happened was specifically the thing I was trying to avoid. Is that Morissetian irony, or just plain irony?

When I get the bluetooth dev board working again, I will try to go with this (jury is still out until I actually implement it for sure though):





But since I'm still leaving 12v, ground, TX, and RX unchanged, that leaves only one wire left for that 5V run:


... And that one isn't connected to the wiring harness. There's no pin on the docking connector for it. And I can't hijack the existing 12v blue wire because that's the one that comes out the dock connector for the Amp Remote wire. So I think we're stuck with our own power supply.

By the way, I've done that sort of thing with the Roslyn library features, converting an entire company code base of Nunit 2.x and MSTest unit test cases into Nunit 3. It was painful but I did it!

I was wondering about stuff like that. Okay, so let's steal something else from the main docking connector?
The microphone, perhaps? Or one of the main serial port pins (since they're all on the back of the case as well as on the docking connector). DCD perhaps?

Nope, only RX and TX and Gnd are connected to the serial port plug, and it would be a bad idea to get rid of those, a worse idea than getting rid of the tuner module serial connector. There are some things you can only do on the player if you've got that main serial port available. I personally know that I wouldn't give it up on my player.

There are a couple other pins coming out of that part of the serial connector, but they're being used for Cell Phone mute and Headlight Dimmer Sense instead of things like DCD and such.

Oh hey. Cell phone mute might be good for that. I think I already talked about that wire earlier. Since we're doing a bluetooth project that connects to a head unit that will have cell phone mute inherent in the bluetooth connection, a physical wire is no longer needed for that.

So are you suggesting to get another male pin for the empty one on the Molex tuner plug, and wire the docking connector pin which USED to be the cellphone mute wire and then adding that to the tuner connector instead, and then make that the 5v supply? That seems like a lot of surgery to go to just so that we don't have to build a power supply into our design. I think it's better if we just bite the bullet, do the power supply, and simplify the connector down to just that one tuner plug and three wire modifications inside the empeg. That Pololu supply I got is working fine and is super easy to wire up.

Yeah, okay. Simple enough to just use the existing 12V for power.

I just find it a bit weird to be going through so many contortions to get voltages that already exist in fine form from the empeg.

The BT module REALLY wants 3.3V. But it doesn't have a suitable input on the dev board for that. So we feed it 5V, and it has an onboard power supply to make that into what it wants: 3.3V. The empeg has both of those available, but instead we're feeding it 12V. Just seems peculiar, though convenient.

But yeah, let's have just one voltage out for now, and the existing 12V is probably it.

I didn't realize that the tuner molex has only 7/8 pins populated -- I have replacement connectors for it here, so mine have all 8 pins. Perhaps I'll use the "spare" unpopulated pin for my own purposes..

Cheers

The problem isn't the missing pin on the molex connector, the problem is that there's no corresponding position coming out of the sled docking connector for that spot. So it's more than just "not populated", it's literally not available at all for connecting the inside of the player to the outside world. So you'll have to hijack a different wire from somewhere else on the docking connector for that purpose. The cell phone mute wire is a great candidate for that, I think, it just requires more complicated surgery.

Found another copy of the sled wiring diagram in the BBS history to help illustrate. It shows the cell phone mute wire as a light green wire that is connected to serial plug pin 1, and the headlight illumination sensing wire as a gray wire (actually white in reality) connected to serial plug pin 8.

Totally separate thing now...

I think my BlueGiga dev board started malfunctioning in terms of its internal power conversions circuits yesterday.

It stopped working entirely, and I got no output from its serial ports.

Tonight I measured the voltage on several of its pins, and I did this measuring both with it hooked into my assembly and getting its voltage from there, and also when it was disconnected from my assembly and getting its voltage directly from the serial port. For places where it was supposed to be getting 3 volts, such as "VDD_IO" it was only getting 1.5 volts. And for places where it was supposed to be getting 5 volts, such as "VDD_CHG" it was only getting 4.5 volts. All other voltage test points were similarly lower than expected.

I verified that my assembly was putting out exactly the expected voltages: 4.95-5.00v on the 5v pins.

However when I connect my assembly to the BlueGiga board, the voltage on those pins drops to 4.5v.

If I take the 3v pin from the Arduino and jumper it to the 3v pin on the BlueGiga board, then suddenly it all works again. I wasn't using that pin because I had previously been using the 5v input ("VBUS") pin on the BlueGiga board. Do you think I should change that so that I use the 3V pin coming out from the Arduino exclusively instead? Or maybe both Vbus (5v) and 3v simultaneously (since Arduino outputs both)?

I think the chip seems to work correctly whether I connect the 5V rail or the 3v rail either way. Can you tell if there's anything on that dev board that truly needs the 5 volts besides the battery charger (that we're not using)?

Hm. When I connect that 3V rail and the board is working again (regardless of whether I have the 5v rail connected, then this chip on the BlueGiga board gets quite hot.

This occurs without any of the I2S pins connected. All that's connected are jumper wires from the Ardunio on these pins:
- 5v (either connected or not)
- 3v
- Gnd
- RX
- TX

This worries me. What has gone wrong with my BlueGiga board I wonder?

And I wonder if that chip or any of its supporting circuitry is the problem and if I can disable it easily?

The chip getting hot, by the way, is the Texas Instruments AIC32I audio codec chip.

http://www.ti.com/lit/ds/slas479c/slas479c.pdf

When I connect up the board with just the 5v rail connected, the chip doesn't get hot, but also the BlueGiga doesn't work and I get no serial output from it.

Whereas if I connect up the board with the 3v rail connected, the BlueGiga works and I see serial output, but the AIC32I audio codec chip gets real hot and I'm afraid to leave it that way for any length of time.

This is with all I2s connections disconnected by the way. Just the power, ground, serial.

And even when I briefly supply the 3v rail to get the board working again and pair it up with a bluetooth device, I no longer get the I2S audio out any more.

I think that circuit is fried. I sure wish I knew whether it was something I did or if it was just a bad chip or something else bad on the dev board.

Mark, how tough do you think it would be to do the WT32i chip bare, without the dev board? How much supporting circuitry do you think we need for:
- Serial RX/TX
- Line in
- I2S in.

Even willing to drop the line in at this point, even though my whole idea was a fully external box so that folks don't have to mod the inside of their empeg.

I might try this one:
http://www.betztechnik.ca/store/p3/WT32i_breakout_board.html

Attached is a screen shot of the relevant portion of the schematic of the WT32i development board where they have that external codec plugged in. It's part of their zip file of the full design documents for the development board at this link: https://www.silabs.com/documents/login/reference-designs/DKWT32i-v2.2.zip

I wonder if I have blown one of the caps in that ladder that connects to its power inputs. I don't see anything visibly physically wrong, everything looks OK there.