Unoffical empeg BBS

Quick Links: Empeg FAQ | Software | RioCar.Org | Hijack | jEmplode | emphatic
Repairs: Repairs | Addons: Eutronix | Cases

Page 2 of 2 < 1 2
Topic Options
#369750 - 06/11/2017 22:36 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30784
Loc: Seattle, WA
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!
_________________________
Tony Fabris

Top
#369751 - 06/11/2017 23:09 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13628
Loc: Canada
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

Top
#369752 - 06/11/2017 23:11 Re: BlueGigaEmpeg [Re: tfabris]
mlord
carpal tunnel

Registered: 29/08/2000
Posts: 13628
Loc: Canada
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)?



Top
#369753 - 07/11/2017 02:26 Re: BlueGigaEmpeg [Re: mlord]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30784
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#369754 - 07/11/2017 05:54 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30784
Loc: Seattle, WA
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!
_________________________
Tony Fabris

Top
#369755 - 07/11/2017 08:29 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30784
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#369756 - 07/11/2017 13:42 Re: BlueGigaEmpeg [Re: mlord]
tanstaafl.
carpal tunnel

Registered: 08/07/1999
Posts: 5313
Loc: Ajijic, Mexico
Originally Posted By: tfabris
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.
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.
_________________________
"There Ain't No Such Thing As A Free Lunch"

Top
#369757 - 07/11/2017 16:19 Re: BlueGigaEmpeg [Re: tanstaafl.]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30784
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#369758 - 08/11/2017 04:33 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30784
Loc: Seattle, WA
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.

_________________________
Tony Fabris

Top
#369759 - 08/11/2017 04:40 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30784
Loc: Seattle, WA
Thank goodness I had the foresight to buy a couple of arduino mega boards. Backup board works perfectly with no changes.
_________________________
Tony Fabris

Top
#369760 - 08/11/2017 07:06 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30784
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#369761 - 08/11/2017 08:37 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30784
Loc: Seattle, WA
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.
_________________________
Tony Fabris

Top
#369764 - 10/11/2017 04:29 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30784
Loc: Seattle, WA
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. smile
_________________________
Tony Fabris

Top
#369768 - 11/11/2017 21:06 Re: BlueGigaEmpeg [Re: tfabris]
tfabris
carpal tunnel

Registered: 20/12/1999
Posts: 30784
Loc: Seattle, WA
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
_________________________
Tony Fabris

Top
Page 2 of 2 < 1 2