Rockbox mail archiveSubject: Re: Getting rid of that damn noise.
Re: Getting rid of that damn noise.
From: Rob Ward <wards_at_paradise.net.nz>
Date: Sat, 29 Dec 2001 09:32:59 +1300
The LCD is probably being updated under interrupt.
So is it just inductive pickup via the clock line to the LCD running at say,
a 10ms interrupt (100Hz)? Mmmmm. Might be easiest to find by just writing
some simple code to toggle each line.
----- Original Message -----
From: "Andrew Jamieson" <ajamiesn_at_mira.net>
Sent: Friday, December 28, 2001 7:09 PM
Subject: Re: Getting rid of that damn noise.
> > The noise is always present and a constant volume, regardless of whether
> > vol is up or down. It's just very hard to hear when the vol is up.
> > Also, the noise is not a constant ripple - it exactly matches whatever
> > LCD is actually _doing_ (you can actually control the noise by changing
> > the LCD is doing), eg it's whether something is being changed or updated
> > onscreen. Thus I'm pretty sure that when the HDD reads and the screen
> > freezes, it's silent because the LCD stoped updating, not because of the
> > HDD. The HDD doesn't explain all the other links with the LCD.
> > I'm guessing that this rules out voltage inverters (they would be linked
> > power drain such as HDD, not to the LCD screen), and also seems to rule
> > the LCD's power supply, clock, etc, as these things would all produce a
> > constant hum or whine, which the noise isn't.
> > Turn the volume right down so you can hear the hum, then start browsing
> > menus. then go back to the level-meter screen. You'll see what I mean -
> > noise is directly tied to what is visibly changing on the LCD, not an
> > underlying constant.
> > Particularly with the level-meter, which updates constantly at a lowish
> > frequency (4hz?), the hum is replaces by a pulsing at that frequency and
> > remains constant with the updates until they freeze.
> > I don't see how these things can be explained by something outside the
> > system. No component (other than the CPU) has it's state affected by
> > actually displaying on the LCD, and you can control the noise by
> > what is on the LCD.
> > AFAICS, the buck stops at the LCD system.
> It sounds to me like it's the data for the sync serial used by the CPU to
> control the LCD. The LCD contrast / power is active at all times, so if
> noise can be stopped when the HD is accessed it is probably not this
> (although a switchmode power supply going into high freq. to power the HD
> would explain it, this would also change if the backlight came on (as the
> LEDs would draw more power, increasing the switching frequency) - anyone
> test this for us?). The data line would explain why the noise stops when
> the HD is active - the CPU stops upodating the LCD (and thus the clock -
> probably polls the HD and thus requires an exclusive state machine,
> therefore no LCD updates).
> If it is the LCD serial data, then the ultimate cause is a lack of proper
> power-supply de-coupling at the CPU. This is quite a common thing, as
> complete de-coupling is virtually impossible without seperate supplies
> even then sudden loading can ripple back through the primary supply to all
> sub-supplies ....). Possibly a simple test for this would be to 'update'
> the ASCII table in the code (I assume it must have one, as the LCD
> controller doco does not mention an embedded one) to contain all blanks.
> This is possible given our current level of knowledge. Errrr ...... just
> thinking about this for a moment, I'm not sure it will work - the CPU will
> probably still send the 'blank' information to the LCD (I doubt they parse
> the info for white space), and if the noise does disappear, it could still
> be the contrast switcher (which would have no work).
> *Sigh* Forget I mentioned it.
> Anyway. I think it's the data line.
> PS: Sorry I have been a bit slack with my schematics recently (Joachim is
> putting me to shame), but I actually found a job again! Bummer, huh? I
> will continue to update when I can.
Received on 2001-12-28