sci.electronics.repair - 9 new messages in 3 topics - digest

sci.electronics.repair
http://groups.google.com/group/sci.electronics.repair?hl=en

sci.electronics.repair@googlegroups.com

Today's topics:

* HP Laserjet 1012 - 1 messages, 1 author
http://groups.google.com/group/sci.electronics.repair/t/a05ab2facc590cfe?hl=en
* Basic questions about telecommunications - 7 messages, 3 authors
http://groups.google.com/group/sci.electronics.repair/t/86ac7da2cbac660c?hl=en
* Where to find (affordable) Oven Set Control G.E. - 1 messages, 1 author
http://groups.google.com/group/sci.electronics.repair/t/1cb36c021a0afb59?hl=en

==============================================================================
TOPIC: HP Laserjet 1012
http://groups.google.com/group/sci.electronics.repair/t/a05ab2facc590cfe?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 31 2010 8:59 pm
From: "Ron D."


Anything blue is meant to be replaced. The paper pickup rollers are
the first suspect. I don't know that printer, but the release
mechanism for most rollers is difficult if you havn't seen how to
release them. Usually that roller wears asymetricly causing the paper
to feed at a slight angle or the paper fails to pick-up.

SOMETIMES you can turn the paper upside down and the printer won't jam
because the curl of the paper is different, but it usually means it
won't last long.

==============================================================================
TOPIC: Basic questions about telecommunications
http://groups.google.com/group/sci.electronics.repair/t/86ac7da2cbac660c?hl=en
==============================================================================

== 1 of 7 ==
Date: Fri, Dec 31 2010 9:25 pm
From: David Nebenzahl


On 12/31/2010 8:39 PM John Tserkezis spake thus:

> David Nebenzahl wrote:
>
>> Here:
>> http://s786.photobucket.com/albums/yy147/bonezphoto/?action=view&current=Linespeeds.gif
>
>> Time divisions are ~3 seconds. This transfer (downloading a picture)
>> bounced between 3.0 and 4.4 K (which I ass-ume means kilobytes?).
>
>> On longer transfers the pattern (sawtooth "wave") becomes very regular.
>
> OK, you're talking about 9 seconds or so between each drop and rise,
> that's not a protocol issue, it's way too long. It might be a
> re-negotiation timing, or something your ISP is doing.

No. Maybe I wasn't clear: the time between the time divisions (vertical
lines) is about 3 seconds, so it's about a second between each drop
and rise. The display updates about once a second. (3 samples/time div.)


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.


== 2 of 7 ==
Date: Fri, Dec 31 2010 9:41 pm
From: John Tserkezis


David Nebenzahl wrote:

> No. Maybe I wasn't clear: the time between the time divisions (vertical
> lines) is about 3 seconds, so it's about a second between each drop and
> rise. The display updates about once a second. (3 samples/time div.)

That makes even less sense. If you meant 0.3 Seconds per horizontal
division, that would equate to one second (or thereabouts) per each rise
or trough, allowing that I counted about three divisions for each.
So it appears you've left out a decimal point.

For one second, that might be a bit quick for a re-negotiation, but I
still don't buy the protocol packetising that's doing it.

Have you tried using another graphing logger? It *might* be that it
takes a snapshot, rather than a real average over the timing period.
--
I am free of all prejudice. I hate everyone equally.


== 3 of 7 ==
Date: Fri, Dec 31 2010 10:01 pm
From: David Nebenzahl


On 12/31/2010 9:41 PM John Tserkezis spake thus:

> David Nebenzahl wrote:
>
>> No. Maybe I wasn't clear: the time between the time divisions (vertical
>> lines) is about 3 seconds, so it's about a second between each drop and
>> rise. The display updates about once a second. (3 samples/time div.)
>
> That makes even less sense. If you meant 0.3 Seconds per horizontal
> division, that would equate to one second (or thereabouts) per each rise
> or trough, allowing that I counted about three divisions for each.
> So it appears you've left out a decimal point.

No. You're just not getting what I'm trying to describe.

It's really simple. The display updates once a second. Each vertical
division--the space between two vertical green lines--is 3 seconds. So
there are 3 1-second samples between each pair of vertical lines. The
smallest feature in the display (i.e., the resolution) is 1 second. Does
that make sense?

> Have you tried using another graphing logger? It *might* be that it
> takes a snapshot, rather than a real average over the timing period.

I don't *have* another graphing logger. This is the one that comes with
the firewall.

Here's another snapshot:
http://s786.photobucket.com/albums/yy147/bonezphoto/?action=view&current=Linespeed44-59.gif

Notice how regular the pattern is here (in this case, it's bouncing
between 4.4 and 4.9 K/sec). The same flat tops of the waves (minus a few
bobbles here and there). I've seen such a display that was absolutely
perfectly uniform across the entire display on a long download. (This
was downloading a PDF; line connection speed was 49.2, the highest
possible speed with my setup).


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.


== 4 of 7 ==
Date: Fri, Dec 31 2010 10:54 pm
From: John Tserkezis


David Nebenzahl wrote:

> It's really simple. The display updates once a second. Each vertical
> division--the space between two vertical green lines--is 3 seconds. So
> there are 3 1-second samples between each pair of vertical lines. The
> smallest feature in the display (i.e., the resolution) is 1 second. Does
> that make sense?

You're describing two different timings.

If it's three seconds per horizontal division, and as per the image, I
saw (about) two to three divisions per peak or trough, (not counting the
steady bit on the right, that equates to six to nine seconds per peak or
trough. That's how it's counted.

> Here's another snapshot:
> http://s786.photobucket.com/albums/yy147/bonezphoto/?action=view&current=Linespeed44-59.gif

> Notice how regular the pattern is here (in this case, it's bouncing
> between 4.4 and 4.9 K/sec). The same flat tops of the waves (minus a few
> bobbles here and there). I've seen such a display that was absolutely
> perfectly uniform across the entire display on a long download. (This
> was downloading a PDF; line connection speed was 49.2, the highest
> possible speed with my setup).

You're talking about the little variations? I get wider variations
that that myself. I just did a test here, and I'm getting quite
significant variations over the download. But, I'm on cable, and I
don't have an active landline modem connection to test otherwise.

In any case, now I officially don't know. Sorry for wasting our time. :-)

As far as speculation goes, one could guess that the internet IP
packets might have something to do with that. Everything gets to your
place in packets. If a few packets get there late, they're still
ordered correctly, but just a little late.

There would be significant (depending on your needs) "jitter" in that
on average, you may have quite constant speeds, but from second to
second, not. You basically don't have any control over the intermediate
data handlers from the site you visit to your destination.
It's actually a bad thing when you're using it for live voice/video
communication (Skype etc), because that type of communications *needs* a
constant supply of data, but the buffering works well enough that you
don't notice too much.


In effect, you're insulated from the effects of Real Life (TM).
--
Follow-ups to alt.nobody.really.cares


== 5 of 7 ==
Date: Fri, Dec 31 2010 11:10 pm
From: David Nebenzahl


On 12/31/2010 10:54 PM John Tserkezis spake thus:

> David Nebenzahl wrote:
>
>> It's really simple. The display updates once a second. Each vertical
>> division--the space between two vertical green lines--is 3 seconds. So
>> there are 3 1-second samples between each pair of vertical lines. The
>> smallest feature in the display (i.e., the resolution) is 1 second. Does
>> that make sense?
>
> You're describing two different timings.
>
> If it's three seconds per horizontal division, and as per the image, I
> saw (about) two to three divisions per peak or trough, (not counting the
> steady bit on the right, that equates to six to nine seconds per peak or
> trough. That's how it's counted.
>
>> Here's another snapshot:
>> http://s786.photobucket.com/albums/yy147/bonezphoto/?action=view&current=Linespeed44-59.gif
>
>> Notice how regular the pattern is here (in this case, it's bouncing
>> between 4.4 and 4.9 K/sec). The same flat tops of the waves (minus a few
>> bobbles here and there). I've seen such a display that was absolutely
>> perfectly uniform across the entire display on a long download. (This
>> was downloading a PDF; line connection speed was 49.2, the highest
>> possible speed with my setup).
>
> You're talking about the little variations?

Phew. Finally; yes, that's what I'm talking about, the "little"
fluctuations (between ~4K and ~5K in that second snapshot). They
intrigue me because they're ubiquitous (they happen all the time) and
they're sometimes so regular; it seems like a pattern that must have
something to do with the underlying transfer mechanism. If it's indeed
jitter, it's damned regular jitter.

Since at this point we both seem to be going on pure speculation, I'll
just thank you for your participation so far.


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.


== 6 of 7 ==
Date: Sat, Jan 1 2011 12:11 am
From: Jeff Liebermann


On Fri, 31 Dec 2010 23:10:51 -0800, David Nebenzahl
<nobody@but.us.chickens> wrote:

>On 12/31/2010 10:54 PM John Tserkezis spake thus:
>
>> David Nebenzahl wrote:
>>> http://s786.photobucket.com/albums/yy147/bonezphoto/?action=view&current=Linespeed44-59.gif

>Phew. Finally; yes, that's what I'm talking about, the "little"
>fluctuations (between ~4K and ~5K in that second snapshot).

Methinks you're looking at the effects of roundoff error. There are
not enough packets used for the download test, so the graph is
rounding off the result to the nearest convenient significant figure.
A running average, with larger time slices, would yield a much
smoother and more realistic curve.

--
Jeff Liebermann jeffl@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558


== 7 of 7 ==
Date: Sat, Jan 1 2011 12:17 am
From: David Nebenzahl


On 1/1/2011 12:11 AM Jeff Liebermann spake thus:

> On Fri, 31 Dec 2010 23:10:51 -0800, David Nebenzahl
> <nobody@but.us.chickens> wrote:
>
>> On 12/31/2010 10:54 PM John Tserkezis spake thus:
>>
>>> David Nebenzahl wrote:
>>>
>>>> http://s786.photobucket.com/albums/yy147/bonezphoto/?action=view&current=Linespeed44-59.gif
>
>> Phew. Finally; yes, that's what I'm talking about, the "little"
>> fluctuations (between ~4K and ~5K in that second snapshot).
>
> Methinks you're looking at the effects of roundoff error. There are
> not enough packets used for the download test, so the graph is
> rounding off the result to the nearest convenient significant figure.
> A running average, with larger time slices, would yield a much
> smoother and more realistic curve.

But as I watch the display during a download, I can see the rate *very
regularly* alternating between two definite speeds (like 4.4 and 5.9 K).
As you can see, the pattern is visible, at least according to this
display. Doesn't that tell us something about how the transfer is taking
place? Or is this just a regularly repeating roundoff error?

In fact, I can tell when the transfer rate is faster or slower, based on
the display: it'll bounce between the same two speeds--that never
changes--but the "flats" on the upper part of the line will be longer,
meaning it's spending more time at the faster speed. The difference is
actually noticeable, in the time it takes to render web pages and such.


--
Comment on quaint Usenet customs, from Usenet:

To me, the *plonk...* reminds me of the old man at the public hearing
who stands to make his point, then removes his hearing aid as a sign
that he is not going to hear any rebuttals.

==============================================================================
TOPIC: Where to find (affordable) Oven Set Control G.E.
http://groups.google.com/group/sci.electronics.repair/t/1cb36c021a0afb59?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Dec 31 2010 9:59 pm
From: "Wild_Bill"


If the electric oven control is a single rotating knob type that controls
on/off, bake, etc, then it probably doesn't use any electronics or circuit
board for temperature control.. considering the type of control and the year
it was manufactured.

If you have separate controls for temperature, and another for bake, broil,
clean, then this selector switch should also be tested.

By referring to the electrical diagram that most appliances have attached to
them, you may also see some failsafe/safety limit switches which should be
tested.

The simplest of searches will reveal numerous results for testing, adjusting
and replacing electric oven temperature controllers.

http://www.fixitclub.com/Major_Appliances/Electric_Oven.shtml?page=3

As the info in the above link points out, inspecting all of the connection
terminals is important.
Corroded, loose, heavily oxidized or badly discolored terminals should be
replaced, or at least brightened to achieve very good connections for
testing purposes, then replaced with new high temperature terminals only.

In my limited experience with electric oven (or other heating appliance)
controls, they're not intended to be serviced/cleaned or repaired.. they're
often assembled with rivets, not just screws.

--
Cheers,
WB
.............


"Vacillator" <user132384@aol.com> wrote in message
news:70e1182b-8c98-4b45-857b-a4b92a622fa9@s5g2000yqm.googlegroups.com...
> Hi,
>
> It looks like my oven set control, on my 1986 vintage GE
> oven, is acting up. It sometimes works (turns on the oven element)
> and sometimes doesn't. Last time it worked for a while, then shut
> off, that is, the heat went down, until I rotated it through all the
> settings, and back to "bake", when it started working again.
>
> I guess the connections are getting old and worn. Is there some
> way to just clean it ? I notice there are websites selling the
> control, but for huge sums, equaling 2 days pay of a guy making $9 an
> hour, minus taxes.
>
> The average price seems to be about $115, for this one electronic
> part. Yikes.
>
> Is there a more affordable way to obtain the part? Is it possible
> to just clean the part, and reuse it ?
>
>
> The part number is WB22X5122, in a GE oven circa 1986.
>
> GE website has it as "unavailable".
>
> Yes, I know I got a lot of years out of it, but $116 is a lot for one
> electronic switch.
>
>
> Thanks

==============================================================================

You received this message because you are subscribed to the Google Groups "sci.electronics.repair"
group.

To post to this group, visit http://groups.google.com/group/sci.electronics.repair?hl=en

To unsubscribe from this group, send email to sci.electronics.repair+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/sci.electronics.repair/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

No Response to "sci.electronics.repair - 9 new messages in 3 topics - digest"

Post a Comment