Transporter Not Playing

[circlotron]

Yesterday my Transporter quit playing. It powers up and connects to the server. When I select a song and hit play, the display indicates Now Playing but the progress bar on the player does not advance. The VU meters don't move either. The web UI works normally. I'm running 7.9.1 firmware (and have for months).

Searching the forums I found and tried a few suggestions:

Xilinx reset
Factory Reset

Neither helped.

I've opened the unit up and have started to make some measurements. The first thing I checked was the 5V switcher after seeing failures on the forum. I've looked at the output with an oscilloscope. The output is 5V and clean.

The power relay is behaving strangely. The +5V and +/-15V come up initially but then turn off (the 5V and +/-15V LEDs go off). I found that by changing the "Power Off AUDIO" setting in the Audio menu of the Player tab from "Audio always on" to "Power down audio when off" the the power supplies stay on. The player still doesn't work but I can make measurements.

The supply testpoint measurements are 5V (4.99V), 15V (15.00V) and -15V (-14.78V).

The 11MHz and 24MHz oscillators are running but MCLK testpoint is stuck high.

[circlotron]

Update

Still haven't got the Transporter playing. I've traced out several circuits and identified a some of the components which may help someone else on a future repair. All the parts mentioned below have been replaced without any effect on the original issue.

I've found a couple of things in the original design that could use improvement.

1) The relay drive transistors Q12 and Q13 don't fully turn on (I was seeing a drop from collector to emitter a bit over 1V). This results in a bit less than 4V to the 5V relay coils. This may shorten the life of the relays. The original transistors are NXP BC850C which are only rated for 100mA, the nominal relay current is 106mA at 5V. I replaced Q12 and Q13 with ON NSS30101 Low Vce(sat) transistors rated at 2A (drop in replacement), their collector to emitter drop is now 30mV.

2) The 24.576MHz oscillator (U22 and Y2) and the 11.2896MHz oscillator (U18 and Y1) overdrive their crystals (this can cause the crystal to start on the wrong frequency and exceeds the manufacturers Drive Level spec). U18 and U22 are TI SN74LVC1GX04 Crystal Oscillator Drivers. The output of U22 pin Y was only about 2V and waveforms on Y2 looked wrong (the waveform on the crystal pin connected to X2 was square). I measured the Y2 crystal current at 10mA (with a Tektronix CT6 current probe) which gives a drive level of about 3mW. (I'm guessing a bit here but similar crystals typically have a maximum drive level of 1mW and a maximum resistance of 30 Ohms.) The TI datasheet calls for a 1k resistor between the X2 pin and the crystal to limit the drive power that is not present in the original design. Adding the 1k resistor reduced the crystal current to about 4mA and reduced the crystal power to near 0.5mW. The crystal waveforms are now sinusiodal and the output on pin Y has increased to 2.5V.

Other Information

The discrete voltage regulators (+5V, +/-15V) appear to be very similar to the Jung Super Regulator published in The Audio Amateur 4/2000 with a few different part selections. The Op-Amp is different, the voltage reference appears to be a five pin TL431.

U26 is an Analog to Digital converter used to monitor the line voltage, TI ADC101S021. It is protected by a dual series diode D19. I wasn't able to find the diode part number but a BAS70-04 should work well here.

I've replaced my 5V switching supply with a Mean Well MPM-15-5. It's rated at 5V and 3A. The input and output connections are solder pins.

[circlotron]

The Transporter initially powers up the +5V, +15V and -15V supplies. After obtaining an IP address it turns the supplies off. I suspect that it is detecting some type of fault and disabling the analog supplies. Am I correct in thinking that all the embedded firmware is closed source? If I had an idea what the possible faults were, that might be helpful in diagnosing the failure.

[bpa]

I think you are getting no visibility from other forum users by initially posting an LMS or Transporter problem in the DIY subforum which is usually visited by users who are building their own hardware from scratch.

From your first post - this "feels" to me to be a LMS softwrae issue and not a Transporter hardware problem. I don't remember any part of the LMS -player protocol which tells LMS that audio hardware is not working and so don't try to play.

All the IP3K based older players (Transporter, Sb3, SB2, Boom, Receiver) have closed source - even if it was open you wouldn't be able to rebuild the firmware as SDK for IP3K processor was v. expensive

I'd suggest first, try the Transporter connected to mysqueezebox.com (and not your local LMS) to see if you can play internet radio.
I don't know Transport specific features but are there any option under Firmeware menu "Factory Test" ?

If you don't like that route, I suggest re-post first post in the General Discussion forum where other Transporter users will see the post.

[circlotron]

mysqueezbox.com isn't working either. The power supplies are still not turning on. Thanks for the suggestion about posting in General Discussion. I'll try that next.

[DrJazzer]

Hey everybody,
My Transporter shows exactly the same behavior for about two days now. I've tried resetting it and changing to a different LMS version - no success.

Any ideas are sincerely appreciated!

Best,
DrJazzer

[Fizbin]

If you don't mind me asking, how old are your Transporters?

[edwin2006]

Just bought one. I'm convinced that this problem will be solved. So much knowledge on this forum. Perhaps Joe can chime in?

[edwin2006]

Just curious, is it connected via wifi or ethernet? Can't this be just a network connect problem?

[bpa]

Just curious, is it connected via wifi or ethernet? Can't this be just a network connect problem?

No because in one of the two instances, the trace of slimproto communication shows the network connection is working but player is telling LMS do not send any more data and player is not decoding the data in its buffer presumably because firmware has detected something wrong in the DAC or output hardware