Supplying power to the external circuit from the tuner plug connection (through a 5v power supply of course) works fine. The amount of noise is unchanged, but I much prefer the idea of my assembly connecting to this existing connector instead of trying to manage additional power connectors, so I'm going to roll forward with that. Thanks!

Okay, I might pursue using the Tuner serial port for the BT module connection then. This way would leave the empeg's primary serial port available for the usual troubleshooting etc. without any conflicts or special handling needed.

The Tuner port is (I believe) 5V TTL logic, which will need to be voltage adapted for the 3.3V CMOS on the BT module. I expect just a couple of resistors will do the trick, but will find out when I do it here.

Cheers

So.. this noise. Is it drive related at all, or just present even with the drive "spun down" (can tell this by looking at the empeg display)?

Oh, and is the noise still there if you switch from the Pololu 5v adapter to your earlier 7805 regulator (with two capacitors)?

The noise is pretty faint so it's hard to be sure. It's at the level where you can't hear it unless the song has a really long faint fade-out.

The BlueGiga's ADC seems to have a "floor" or a "noise gate" where extremely quiet sounds don't get sent to the ADC at all and there's just digital silence. So for example, songs with long fade-ins or long fade-outs might have a very small bit of the quietest part of the fade cut off. The amount of noise I'm hearing is just barely on the edge of that noise gate's sensitivity level, so what I get is an intermittent thing where occasionally I hear a faint bit of noise floor appear for a second or so, then it drops below the sensitivity threshold of the noise gate then it fades out again. It's only audible if I turn up the volume on the head unit really loud. But my goal is to eliminate it completely so that even that's not a problem.

Side note: I've also looked through the commandset looing for a way to bring that noise gate's threshold setting down even further, so that it doesn't cut off even the quietest fadeouts. But I can't find any command to adjust the threshold of that noise gate. I'm already controlling the gain and the preamps and the mic bias voltage, and those are set correctly in my code, I can't find any other settings related to that.

I'm using an SSD so I can't tell if it's spinup/spindown related.

I haven't tried switching back to the 7805, I'm going to try switching forward to that isolated voltage converter instead, it comes in the mail tomorrow. If that doesn't solve the issue, I'll try comparing the three power supply types.

Another update to the source code here:
https://create.arduino.cc/editor/tfabris/4c5eea9a-1462-45d7-908d-81a5bb6b0d90/preview

This implements the proper responses to the head unit's queries for track metadata, in cases where it attempts to query for multiple pieces of metadata in the same query line.

I haven't gotten a chance to see if this fixes the problem with my roommate's Kenwood stereo yet. Crossing my fingers!

Hmph. The new code did not fix the problem.

It did allow the track number to be displayed on the Kenwood screen but again, only the first one. The Kenwood didn’t query for subsequent ones.

Rush, "Red Barchetta"?

Play the track on some other device to be sure the problem isn't in the track itself, and experiment with different tracks as well. I suspct you have already done those things, but that's the limit of my technical competence so is the only suggestion I can make.

tanstaafl.

Thanks for that suggestion. Unfortunately it’s not that simple. I’m using a large variety of tracks to test this, and I also have the ability to A/B with other playback systems and also with the pure digital versions via A2DP with my phone, so I’m certain I know the difference between noise floor extant in the track and noise added by external electronics.

OK weird.

I got the new isolated power supply and hooked it up and tried it out.

It seemed to work but it made a faint humming/whining noise during operation. Not noise in the audio chain, but I mean physical noise when I put me ear up next to it. I've heard power supplies that whine a bit before, so I thought maybe this was normal operation and kept trying it out.

The ground loop noise on the bluetooth/arduino/empeg assembly audio chain was even less than with previous power supplies. Not 100 percent gone, but definitely much much better. Prior versions of the noise were a combinaion of an electronic hum as well as a rushing-wind kind of static noise floor, but with the new power supply it was only the static noise floor, and that was pretty quiet.

Unfortunately I noticed that the bluetooth and arduino were a bit unstable, as if maybe it wasn't supplying the right voltage. Example of what I mean by "unstable" is that the bluetooth connection would drop occasionally, or the reset button that I implemented on the arduino would not function sometimes.

So I unplugged the new power supply and went back to the pololu power supply. And then I plugged in my USB debug cable into the Arudino to work on the programming side of things and... nothing. Nothing comes out on the debug cable.

What's interesting is that things go IN on the debug cable just fine. And the communication between the arduino and the bluetooth board are fine. I know this because of the behaviors I have programmed into my code. I can press the reset button and my blue LED connected to the arduino lights up and it erases the bluetooth pairing on the bluetooth chip, exactly as it is supposed to. I can do all the actions that I normally can do and they all work. I just don't see their output logs on my arduino serial debug monitor any more.

I can SEND commands to the bluetooth module by typing them into the arduino debug console and they get there, they arrive and do the correct thing. For instance if I type BOOT 0 into the arudino debug console then the bluetooth chip correctly reboots (it disconnects form whatever it was paired with and then reconnects after a moment). So SENDING text to the Arduino works.

But I don't see any serial ooutput coming BACK from the arudino. And I know that my program outputs stuff back (regardless of echo on or echo off), it's got specific logging commands that my program has said to put there, and those commands are in there pretty constantly from power-on. For instance, I can press my reset button and my blue LED lights up to indicate it's in paring mode, and I know at that moment I'm echoing a bunch of messages to the arduino debug serial port, but I'm not seeing them on the console.

I tried reloading a program onto the arduino, it times out because it can't get a serial signal back saying that it is receiving the code.

I tried fully unplugging the arduino from the entire assembly and connecting it solely to the computer just from the USB cable. Same thing.

I tried plugging it into an entirely different computer and different operating system (going from Mac to Windows), which entailed installing the arudino development software and device drivers from scratch on the new computer, same thing.

It's not a baud rate thing, because (a) the program sets the baud rate and I know the program is working, and (b) I tried different baud rates on the monitor anyway. Same thing.

Wow this is weird. I don't see how the new power supply could have done this to the arduino but I suppose it could? I don't know. Why would it fry only one direction of the arduino serial port while the rest of the thing works perfectly for everything else? Weird.

Thank goodness I had the foresight to buy a couple of arduino mega boards. Backup board works perfectly with no changes.

Another update to the source code.
https://create.arduino.cc/editor/tfabris/4c5eea9a-1462-45d7-908d-81a5bb6b0d90/preview

This makes it so that the same set of notification commands is always sent to the bluetooth chip every time a track changes or the playback status changes. This was an attempt to fix the bug with the Kenwood headunit where it only ever got the first track title on its screen and never got subsequent ones.

It didn't fix that bug, but it fixed another previously-unmentioned bug where I had a bluetooth headset which wasn't successfully pausing/unpausing when I pressed its pause button. Something about the change in the last set of code fixed that bug, and now the headset correctly pauses and unpauses.

Aha.

Updated example code that fixes the Kenwood bug:
https://create.arduino.cc/editor/tfabris/4c5eea9a-1462-45d7-908d-81a5bb6b0d90/preview

Here's what was going on with the Kenwood bug (from my code comments in the update above):

// Final fix for the "Kenwood Bug". Description of the Kenwood Bug:
// The AVRCP NFY CHANGED commands work on factory car stereo in
// Honda Accord 2017 model no matter what the transaction label is.
// This led me to believe that the transaction label was only important
// when performing an immediate response to a state query (i.e., when
// sending an "AVRCP NFY INTERIM" response), and that if I was the one
// who was indicating the state change (i.e., when I was sending an
// "AVRCP NFY CHANGED" statement to tell the host that something had
// changed), that the transaction label was arbitrary and that I was
// the person choosing the transaction label at that time. This was
// fine for the Honda stereo: When those commands are issued to the
// bluetooth chip, then the car stereo head unit immediately reacts
// by re-querying for more new track metadata from the bluetooth chip.
//
// However, when using those commands on a Kenwood bluetooth-equipped
// car stereo, then nothing happens when the messages are sent up
// with arbitrary transaction labels. The Kenwood stops sending new
// queries for track information and just "sits there" blindly
// playing the audio stream without getting any new track data.
//
// It turns out that the transaction labels aren't arbitrary if
// you received a "REGISTER_NOTIFICATION" message for the
// "PLAYBACK_STATUS_CHANGED" or the "TRACK_CHANGED" messages.
// Yes, you need to immediately respond with an "INTERIM"
// notification, but then if you send a "CHANGED" notification
// yourself later, then the transaction label still has to match.
// The Kenwood stopped querying for new track data because the
// transaction labels didn't match when I sent it "CHANGED"
// notifications. The fix is to match the transaction labels
// by storing them in a global variable.

As far as the noise goes, I think I'm going to attempt to make a first pass at a PCB and see if all I really need to eliminate the noise is to simply get things more solid with better ground traces and everything, instead of jerry rigged on a breadboard.

Now that the software and my breadboard prototype are working well, I've just ordered a PCB from Pad2Pad. Should have a video of the assembled version of that in the next 10 days or so.

I have done another update of the code. Some code cleanup and comment cleanup. Removed a few dead things in the code.
https://create.arduino.cc/editor/tfabris/4c5eea9a-1462-45d7-908d-81a5bb6b0d90/preview

Current status:

- I have a working car installation, with the breadboard prototype and the attached empeg velcroed to the floor of my trunk, Eutronix remote display extender is installed and working in the sunglasses holder in the ceiling up front. Works well and sound is good.

- I have a PCB on the way from Pad2Pad that should allow me to turn the prototype into a single nice little box that I can mount better and well protected in the trunk, while still allowing me to pull out the player and dock it to load tunes indoors.

- There is a bug in the software, such that high-ascii characters are displayed as an inverted question mark on the car stereo screen. So Béla Fleck and Blue Öyster Cult look funny, for example. Will work on fixing that soon.

Questions for Mark Lord and Stu:

Stu's digital interface does I2S, and its instructions seem to show some simple I2S connection pads on the empeg motherboard. There are some I2S pins on the BlueGiga development board, and there are instructions in the BlueGiga docs which say how to route the audio from the I2S pins (you have to issue a particular couple of commands to the BlueGiga chip).

Question 1:
Is it as simple as a couple of wires to connect the I2S on the empeg motherboard to the I2S pins on the BlueGiga board? Or is some buffer circuitry needed or what?

Question 2:
If I am getting my audio from I2s instead of from the audio out jacks, what features will be lost if any? Or will these all work as expected even through I2S?
- Left right time alignment?
- EQ?
- Bass/treble boost?
- Auto volume adjust?
- Volume control from front panel?

The I2S pads come more or less directly from the empeg's DSP chip, so that would be AFTER pretty much everything has been done to the audio. I haven't tried it yet, but all of the adjustments should "just work" through I2S.

However.. it is not entirely clear to me whether the I2S outputs use 5V or 3.3V. The datasheet for the DSP seems to indicate 3.3V, but I'd like to see it on an Oscilloscope just to confirm. Stu would already know this too, so if he chimes in..

EDIT: The schematic indicates 3V on the IIS header, so it should be good.

That's important, because 5V could fry the BT module. So you really want 3.3V logic there. Easy to convert 5V to 3.3V with a 10Kohm and 20Kohm resistor ladder, if it is needed.

Cheers

So should we try it with just some wires? Do we know what the pinouts are for that header? Stu's instructions also have a connection to a timing crystal, would that be needed as well?

I don't know what Stu needed the connection from the side of that crystal for.
No schematic of Stu's device here, so you'll have to ask him what that was all about.

But here is the layout of the I2S (aka. IIS) header inside the Mk2a, along with the nearby 3V power source.

Stu appears to be using IISC, IISW, and IISD1 from the header.
Ground is also available there, so no need to go hunting elsewhere for it.
Those are the same pins we'll want to connect to header J12 on the BT dev board (SCK, WS, SDIN, GND).

Wow that looks really straightforward. Thanks! Maybe I'll get a chance to try it later this week or this weekend. If you try it first, let me know!

According to the docs, you have to issue these commands to get the dev board to route from the I2S connector:

SET CONTROL AUDIO INTERNAL I2S EVENT 32
SET CONTROL EXTCODEC PRE 30 18 0200918000008A1037000100008000000FF07C7C787C7C78 30 04 25C01400 30 0a 28C00000000000008000 30 03 330F00 30 05 3F00800F00 30 04 6500A200
RESET

In the meantime, I'm having a devil of a time trying to find out how to get high-ASCII characters to appear on the car stereo screen. I can't find the bluetooth specification information for how to handle non-ASCII characters in the strings sent up in the AVRCP metadata.

Hm, I misread those commands in the docs. The "EXTCODEC" command is for setting up an external TI codec included on the dev board. I think that perhaps you might only need the first command to use the empeg I2S:

SET CONTROL AUDIO INTERNAL I2S EVENT 32

And mayyyybe a "RESET" after that. Might be that simple.

Also the number might not be 32. The docs say "...configures I2S to use 32 bits per sample to suit the clocking requirements of the TI codec" so I don't know if the empeg needs that or if it needs 16 in that slot or what.

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

This one contains the following changes:

- Another pass through the code comments.

- Adds an aggressive reconnection retry so that once you've paired up with your car stereo, then after that, each time you start your car, the empeg tends to be the device that connects to the car stereo first, rather than playing tunes from the phone in your pocket. On my car now, when I start it, it connects the music to the empeg and the phone/voice to my cell phone. Nice.

- Fixes the issue with High ASCII characters in track titles by converting high ASCII to UTF-8 before sending it up the bluetooth link. Works well, now my Blue Öyster Cult and Béla Fleck tracks look correct.

Last night, my friend Fishy used his expensive high tech mill machine to clean up the edge cuts on the sunglasses holder where I mount the remote display. I'm really pleased with the way it's looking so far. I should also hopefully receive my PCB from Pad2Pad and I should be able to solder up a much better attachment box without having to use the breadboard. If I get that all working I'll post another demo video with everything in place.

Regarding the I2S connection on the Empeg motherboard - Would you expect that the GND for that is the same as the GND for 12V on the tuner connector?

I'm thinking of hijacking more wires on the tuner connector to run I2S out the back of the sled (disconnecting all existing tuner connector wires from the empeg motherboard except for the 12v power and ground).

Should be the same GND.. justasec while I dig out an ohm-meter..

Yup, same GND. Also same as the metal enclosure (chassis).

Holy shit it works. THANK YOU!

Since the IIS header on the empeg motherboard is not labeled, I'm going by your earlier post regarding the pinouts of the IIS header, and the photo of the connected wires from Stu's digital interface installation instructions.

Yellow wire in Stu's instructions: Assumed to be PL8 - Pin 1 - IISC
Orange wire in Stu's instructions: Assumed to be PL8 - Pin 2 - IISW
Not connected in Stu's instructions: Assumed to be PL8 - Pin 4 - GND - (I have added a blue wire here).
Red wire in Stu's instructions: Assumed to be PL8 - Pin 4 - IISD1
Not connected in Stu's instructions: Assumed to be PL8 - Pin 5 - IISD2

I am connecting (based on the assumptions above and your earlier post):

Yellow wire connected to BlueGiga board SCK pin.
Orange wire connected to BlueGiga board WS pin.
Blue wire connected to BlueGiga board GND pin.
Red wire connected to BlueGiga board SDIN pin.

Note: Don't usually need that blue wire except when I've got everything split out on the workbench and the empeg and the bluetooth module are getting their power and ground from two different places.

The final version of the secret command you have to issue to the BlueGiga module to make it work turns out to be:



And at some point in my setup code, the device eventually gets this command:
RESET

The format of the command, according the iWrap 6 command reference, is:

SET CONTROL AUDIO - The preamble for the command
INTERNAL I2S_SLAVE - The input and output audio routing. It doesn't seem to matter what I set the first one to, as long as the second one is set to "I2S_SLAVE" because that's the one we're using in A2DP "Source" mode. The other one is unused by our configuration.
EVENT - To receive audio routing events.
KEEPALIVE - Prevents DSP from powering down between A2DP streams. Removes possible clicks and pops from the beginning of the analog audio stream. Might decrease also A2DP latency. Increases power consumption when not streaming audio.
16 - Unused since we are in slave mode, it specifies the number of bits per sample when using I2S master mode. Can be 16/20/24/32 (default 24). I'm stuffing a 16 in here just for something to put in there.

Stu's instructions say something about how the audio volume on the empeg might need to be set to one notch down from 0db to keep the audio from clipping. I'm going to experiment with that.

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

Includes:

- Optional IIS/Analog input based on commenting/uncommenting the global variables to set up IIS or analog audio routing.

- Some additional work done on attempting better "initial connection" experience and play/pause behavior at start of the car.

- Some other tweaks, I forget them all at this point. :-)

Next goal: modifying the wires on the tuner connector to carry the IIS signals instead of the tuner signals.

Awwww... that's nothing. I once wrote a program in Q-Basic that allowed me to select which Wadfile to play in DOOM. Be impressed!

tanstaafl.

Totally awesome, Dude!!

I am SO gonna go for I2S here in my setup too!

Excellent!!!

Note that the little "bent corner" on the silkscreen (paint) on the empeg motherboard indicates "pin 1".

I think you should really go for using the Tuner's serial port too, instead of the primary empeg serial port. Just two pins on the tuner connector (RX,TX), plus (exising GND).

The RX (to tuner/BT-module) pin requires a resistor ladder to step down the voltage from 5V to 3V logic. the TX (from tuner/BT to empeg) can connect without modification.

The resistor ladder on RX should consist of a setup like this:


Connect the RX (BT module) to the (+)point in between the 10K/20K resistors. No MAX rs232 chip required.

The two resistors function as a voltage divider, converting the 5V RX output from the empeg into (20/(10+20) * 5.0V == 3.3V) suitable voltage to not fry the BT-module.

EDIT: Oh, I keep forgetting you have the Arduino in-between right now..

-ml

Thanks! Maybe someday I will indeed try to do it sans Arduino and get it working fully internal to the player. But now that I have it working as an external box with all the features I want, I'm going to refine this for now and finalize the current design. In the meantime I'll give you any support you need for doing the internal version yourself.

Here's my thinking at the moment...

If anyone besides you or me ever wants one of these for themselves, then they can have three different ways of doing it:

1. Fully external box which requires no player modifications, uses analog audio plugs. Requires an Arduino and one of the WT32i dev kit boards.

2. External box like 1 above, which can also work with digital I2S connection, but you have to be willing to open up the empeg and solder to the I2S pads and hijack some wires out the back of the docking connector (I'm currently using three of the tuner module wires successfully for this).

3. Fully internal to the player, using the tuner serial lines for command/control of the bluetooth and the I2S pins for the audio, but requires additional connections and soldering internal to the player, and takes up a drive bay slot for the assembly.

I currently have a working implementation for either/both Way 1 and Way 2, and I'm designing my second revision of the printed circuit board already. Once I get that second PCB made and tested, I could be set up for manufacturing these things as complete modules, or selling them as kits. The second revision of the PCB will allow the module to be used in either Way 1 or Way 2.

For way 3, I think that you should totally run with that. You know so much more about programming for the Empeg and you know so much more about EE than I do, I think you'll be totally successful at that. Your version would be smaller, simpler, and MUCH cheaper to manufacture.

I'm pretty excited about this. I know the software is going to need a lot of tweaking though, so there will still be updates to the example code. If anyone else wants one of these, I'll bet that it won't pair up perfectly with their stereo and will need additional code tweaks. Each time I try this thing on a different bluetooth device, I discover some other little thing that doesn't work and I have to update the code again.

Still, having a lot of fun (and stress) with this project. I've been through so many twists and turns with the circuitry, most of which I haven't mentioned on here. Last couple of days it was weird thing with the serial connection failing on the PCB from Pad2Pad which turned out to be just traces grounding out when they weren't supposed to be, and I had to jumper around some shit. Next design from Pad2Pad will have bigger clearance around the traces than their recommended settings. Live and learn.

I'm super grateful for you and for the other folks on this BBS for the suggestions and the help. The initial idea for doing this was from two people: FieroSTI for having made a bluetooth input board for the empeg (the opposite thing of what I'm doing now), and Elperepat for pointing out the original BC127 breakout board at Sparkfun.com. From there it just snowballed. You all have been super helpful with all sorts of great suggestions related to the bluetooth stuff and for the electrical circuits. It's just been amazing. Thanks all!