Found the problem. It was apparently a short to the drive sled. I had insulated the sled from the board with some heat shrink tubing, but apparently it wasn't enough. After ripping the board from the sled and putting it beside the Rio, I immediately got perfect output.

For those wondering about volume control and EQ, they are both fully functional through the dig. output. One minor drawback is that there is no beeping with button presses. I will get to work on a SMT version soon.

Thanks for everyone's help making this project a reality.

Stu

Congratulations! Another successful empeg hack..

Congratulations!
Put me down for one of those...

Anybody know what can be done about stray capacitance on the MCK input of the CS8405A. I am now attributing the intermittent output of the board to the 11.2896 MHz input from the Empeg. It seems to get loaded down with capacitance while the S/PDIF board is installed inside the Empeg. It will not work reliably inside the Empeg. If I grip the wire (the insulated portion) carrying the 11.2896 MHz signal it basically kills the output of the board. There are no shorts. Right now I am using one conductor of a 3M color coded ribbon cable about 6 inches long. I tried some shielded audio interconnect cable, but it wouldn't work at all with this cable. Do I need low capacitance shielded cable? Perhaps twisted pair? Throw me some suggestions here.

Stu

Sorry to ask such question :

what is the utility of your hack ?

Where are you picking the signal up?

It sounds like your picking it up from part of the osc drive circuitry where any capacitance will have a major impact on the osc. I haven’t seen a schematic for the empeg so I can't really comment and you obviously have electronics experience or you would not have gotten so far. So I guess you know to take the signal from a driver or fan-out gate.

If this is not the problem you may just be loading or deforming the signal too much. At 11Mhz you want to keep the lead as short as possible and personally I would not shield it. It's not like your trying to pass CE or FCC.....

Try moving the pickup to the other end of the 11.2896MHz xtal - one end is driven by the 7705 (XTAL out) the opposite end is an input on the 7705 and probably doesn't have the power to drive your board.

Hugo

Some people would like to use their Empegs with external DACs, either at home or in the car. Digital audio transmission, especially optical, is more immune to noise than analog. Also, depending on the quality of the external DAC, you can improve the quality of the sound by virtue of higher quality equipment. If all signal sources are input through a single DAC, the output level will also be more closely matched across signal sources.

Hope I'm not explaining the obvious,

Stu

So we could plug the sound output to a Digital Qualizer ?

Right now the lead is connected to the side of the xtal closest to the front of the Empeg. Before I go unsoldering things, is that the side going to the input on the 7705 (the week side)?

Thanks,

Stu

Hmmm, haven't got one of those . I hope it works better than those CD demagnetizers.

Stu

Hugo, is there any way to get the beeps to function through the dig. output? Right now they don't.

Stu

I'm not sure why they don't, to be honest. It's probably a DSP setup issue. Currently, you're *not* getting eq if you are in 4x5 EQ mode; you're only getting it on 2x10 mode.

You could try these (empeg_mixer.c):

2x10 band eq mode - write Y_OutSwi = 0xa49 (currently 0xa7c)
4x5 band eq mode - write Y_OutSwi = 0xa50 (currently 0xa85) - this *may* disable the onboard DAC though.

Hugo

I switched the lead to the other side of the xtal and shortened the length to about 3.75 inches from 6 inches, but I still get dropouts. Not really any improvement from switching sides, that I can tell. I guess the only thing left is to add a buffer/line driver chip. I've got a 74HCT541 I'm going to try. It's just not going to be easy to add on to the existing board.

Stu

A couple of inverters should be fine; 74lvx04 or similar. These are only 14 pin, so are likely to be less hassle to mount than a '541 - mount it "dead bug" (ie, glued upside-down to the pcb) then wire it this way, it's the neatest way...

Hugo

It's "accepted electronic best practice", no less .

At the risk of sounding really ignorant, why would I want to invert the signal? As you probably know, the 74HCT541 is a noninverting buffer. Any reason this wouldn't work, ignoring physical dimensions? It seems to have worked in others' applications and it's all I I've got on hand.

Stu

Hi.

I guess Hugo meant the "couple of inverters" literally: Inverting twice results in a "buffered" input signal.
But a single inverter is sometimes handy, too. Depending on the amount of delay the inverter and/or other components introduce to the clock and data signals, it can be useful to use the inverted clock on ICs at the end of the chain: If the data signal get's shifted by more than 1/2 of a clock cycle, inverting the clock cycle can help to get in sync (well soft of) again.
Shouldn't be an issue on a 11MHz signal and todays ICs though. So I really guess that Hugo was talking about inverting the clock twice.

cu,
sven

Yeah; you could use a single gate solution like an '08 with the inputs tied, but as 04s are so useful people do tend to have them kicking about a bit (ok, I do at least).

A 541 being an octal buffer (as I remember) is a bigger, more unweildy chip to deal with.

Hugo

Yes the 541 is on octal buffer. I made a little perfboard circuit for the chip that floats (physically) above the main S/PDIF board. I now get uninterupted output as long as I don't put any pressure on the perfboard. If I try
to adjust the position of the board while in operation, I sometimes momentarily lose the output. Of course this could be from anything. Perhaps with a proper ground plane things will behave better. This board has started to get very ugly (see attachment). I guess I will just have to bite the bullet and build a prototype SMT board with the buffer on board.

Stu

I wouldn't mind if you don't get the beeps working, I've had several car stereos and the first thing I always do is switch the beeps off, personally I don't know what usefull purpose it serves (but I'm sure someone will tell me ).

but I'm sure someone will tell me

You think so?

The beeps are useful in knowing that your remote presses were received by the player. With beeps on, I can pretty much type in searches using my steering wheel remote without looking at the display. Not having to look at the display has a nice side effect in that you can keep your eyes on the road, which is a good practice, or at least that's what they tell me.

Unfortunately their implementation in the player app is kinda inconsistent. Hijack doesn't use them either.

Yeah, I'd really like to get the beeps back too. My Rio seems rather reluctant to take commands from the remote sometimes. It would be good to get confirmation that it was accepting my commands. I really don't know how to go about exploring the reasons behind the missing beeps and don't have a clue about what Hugo mentioned below:

In reply to:

---

You could try these (empeg_mixer.c):

2x10 band eq mode - write Y_OutSwi = 0xa49 (currently 0xa7c)
4x5 band eq mode - write Y_OutSwi = 0xa50 (currently 0xa85) - this *may* disable the onboard DAC though.

---

Once I get the boards on the market, perhaps someone else can tackle this issue.

Stu

In reply to:

---

The beeps are useful in knowing that your remote presses were received by the player.

---

That reminds me - at the moment, there are two settings, home and car. IWBNI I could have beeps for the remote but not panel or stalk (as I get tactile feedback from those). Heading over to wishlist...

I've done the changes Hugo mentioned and compiled a new kernel with Hijack v269 and v2.00b11 for a mk2. It's here. It is totally untested though as I obviously don't have the SPDIF board

- Trevor

Great, I'll give it a try! I've not delved into Hijack as of yet. So do I need I Hijack v269 and v2.00b11 to run this kernel or just v2.00b11?

Stu

Just upload the kernel I linked with Tony's logo editor kernel flasher and that should be it. So long as you've got a Mk2 and v2.00b11 installed you're set.

All of the Hijack changes are inside the kernel so that all there is to do. It's v269 instead of v270 because somebody else mentioned there was a bug in v270

- Trevor

I did the upgrade and it beeps through the digital out now! There are no major adverse effects as far as I can tell. The volume control works as does the EQ (at least in 2 x 10 mode). Analog out still functions with beeps too. Only problem may be that scrolling through options hangs sometimes, but maybe that is a problem with 2.0 b11? Good work guys (Hugo and Trevor)!!! If I come across any other bugs I will post them.

Stu

I have uncovered a rather irritating bug caused either by the kernel mod. The Rio refuses to play the entire contents of the hard drive. When I select the arrow in the playlist section and hit the bottom button, the player begins playing from the playlist to the immediate right of the arrow, not the entire contents of the player as it had in the past. So right now, if I want beeps I am limited to playing individual playlists. Any ideas? I am almost positve the problem lies in the kernel mod, because after experiencing this problem I went back and reinstalled 2.0b11 to get back the original kernel, and the problem (and the beeps ) disappeared. Anyone can try the kernel Trevor posted even if you don't have an S/PDIF board, and it would be great if someone else could duplicate the bug.

Stu

Just uploaded Trevors kernel, and if I press the Down button three times I get the entire content (minus those playlist tagged as 'Ignore as child') of the player.

Are you sure you didn't turn off Shuffle? If off, the player starts playing the nearest playlist (but still queues up all the content...) In the Now & Next screen, what's the total song count? That of the single playlist or the entire player? Hmmm, then again, the Shuffle setting shouldn't be affected by a kernel change...

/Michael