Did SprintPCS forget to Spring Forward

"Bob Smith" <[email protected]> wrote in message
news[email protected]...
>

>
> Make that the Sixty One Faces of Eve ... in Drag ... <g>
>

NO, DAMMIT- three was enough!!!!!

---

› See More: Did SprintPCS forget to Spring Forward

Bob Smith wrote:

> Make that the Sixty One Faces of Eve ... in Drag ... <g>

And BAD drag....3 day beard, hairy back....

"JRW" <no_addy@no_.com> wrote in message
news:[email protected]...
> Bob Smith wrote:
>
> > Make that the Sixty One Faces of Eve ... in Drag ... <g>
>
> And BAD drag....3 day beard, hairy back....
>

I can handle that- sounds like my first wife.

In article <[email protected]>,
JRW <no_addy@no_.com> wrote:

> Bob Smith wrote:
>
> > Make that the Sixty One Faces of Eve ... in Drag ... <g>
>
> And BAD drag....3 day beard, hairy back....

Hows the mirror you guys are looking in?

Typical blind SprintPCS apologists. Don't like the message, attack the
messenger.

"Robert M." <[email protected]> wrote in message
news:[email protected]...
> In article <[email protected]>,
> JRW <no_addy@no_.com> wrote:
>
> > Bob Smith wrote:
> >
> > > Make that the Sixty One Faces of Eve ... in Drag ... <g>
> >
> > And BAD drag....3 day beard, hairy back....
>
> Hows the mirror you guys are looking in?
>
> Typical blind SprintPCS apologists. Don't like the message, attack the
> messenger.

When the messenger changes his ID 61 different times, when the messenger
LIES, when the messenger misquotes prior posts, when the messenger causes
false arguments, when the messenger purposely demunges other poster's email
addresses here to have them harvested by spambots and then doesn't answer
questions directed to the messenger ... In other words, when the messenger
is a verified troll, sure, why not ... ?

Bob

This message needs to be repeated just for anyone who missed it. "The
Messenger" refers to Phillipe/Robert M./Cell Merger.

Bob Smith wrote:
<<When the messenger changes his ID 61 different times, when the
messenger LIES, when the messenger misquotes prior posts, when the
messenger causes false arguments, when the messenger purposely demunges
other poster's email addresses here to have them harvested by spambots
and then doesn't answer questions directed to the messenger ... In other
words, when the messenger is a verified troll, sure, why not ... ?
Bob>>

"Robert M." <[email protected]> wrote in message
news:[email protected]...
<<Hows the mirror you guys are looking in?>>

It looks great because it doesn't show us your reflection... the
reflection of a sad, bitter, lonely man who lives for nothing but
causing arguements and trouble and hiding behind the unmoderated usenet
to do so.

[email protected] (Andrew Shepherd) wrote in message news:<[email protected]>...
> "Steve" <[email protected]> wrote in message news:<[email protected]>...
> > My Treo 600 in Chicago still shows it's 9am... when it should be 10am. Does
> > the Treo not set with the network?
>
> Precisely synchronized system time is imperative to the success of
> CDMA. And the clock on your handset derives its synchronization
> latently from the CDMA sync channel. After synchronization has been
> achieved, the clock runs asynchronously until another access of the
> sync channel resets the clock, which is why most CDMA handsets will
> continue to maintain time while AMPS roaming until power-cycled.
> However, for example, my handset clock w/o the benefit of periodic
> reads of the sync channel while AMPS roaming gains at least a minute
> or two per 24 hours.
>
> The compelling question then is: what prompts an access of the sync
> channel?

OK, I think you've succesfully overanalyzed the problem. It suspect it
boils down to crappy clock software.

1) there's sync'ed clock info, probably in UTC, that's the same for
every CDMA tower in the WORLD. this is "constantly" being sampled by
the phone and used, among other things, to prevent drift of the
display clock.

2) there's a time zone correction, specific to each site (sector?).
DST updates depend on this information being updated (by Sprint) and
resampled (by the phone). Some phones might only do it on power-up. Or
whenever the carrier is reacquired. Or when switching sites. Or on
call start/end. Or ... whenever! The point is that "getting it right"
is probably not a high priority for some handset manufacturers.
Encouraging people to power-cycle their handset 2x a year is probably
a good thing.

"Robert M." <[email protected]> wrote in message
news:[email protected]...
> In article <[email protected]>,
> JRW <no_addy@no_.com> wrote:
>
> > Bob Smith wrote:
> >
> > > Make that the Sixty One Faces of Eve ... in Drag ... <g>
> >
> > And BAD drag....3 day beard, hairy back....
>
> Hows the mirror you guys are looking in?
>
> Typical blind SprintPCS apologists. Don't like the message, attack the
> messenger.

Not attacking anyone- might be having a little fun in pointing out the
absurdness of your idiotic thoughts, and if you condsider the posts in this
thread an insult.....oh well.

[email protected] (Andrew S) wrote in message news:<[email protected]>...
>
> OK, I think you've succesfully overanalyzed the problem. It suspect it
> boils down to crappy clock software.

W/ all due respect, I do not think that I over analyzed the problem.
This newsgroup has become largely a shouting gallery for
misinformation, double-speak, & slander. Heaven forbid that someone
should disseminate some concrete technical truth around here. You
probably meant no offense, but I often feel ignored or
underappreciated around here when I altruistically attempt to assist &
educate on the inner-workings of CDMA technology or wireless
regulatory issues.

> 1) there's sync'ed clock info, probably in UTC, that's the same for
> every CDMA tower in the WORLD. this is "constantly" being sampled by
> the phone and used, among other things, to prevent drift of the
> display clock.

No, chip synchronization is not required for "every CDMA tower in the
WORLD," only those for which soft-handoff capability is desired. The
absolute time itself is not important, only the relative time, such
that the mobile & the network are in sync over proper timing-offsets
in the pseudo-noise (PN) short & long codes. However, most CDMA BTSs
- regardless of network - do receive their time-references via the
same source: GPS.

> 2) there's a time zone correction, specific to each site (sector?).
> DST updates depend on this information being updated (by Sprint) and
> resampled (by the phone). Some phones might only do it on power-up. Or
> whenever the carrier is reacquired. Or when switching sites. Or on
> call start/end. Or ... whenever! The point is that "getting it right"
> is probably not a high priority for some handset manufacturers.
> Encouraging people to power-cycle their handset 2x a year is probably
> a good thing.

"Getting it right" would entail that handset manufacturers implement
some sort of intelligence into the embedded clocks. At 2am on a
Sunday morning every April & October, Windows seeks my permission to
automatically update my PC clock according to initiation or expiration
of Daylight Savings Time. The same could be and probably will be done
as modern handsets adopt more PC-like operating systems. Similarly,
handsets could be programmed to automatically cycle through a sync
channel read at 2am on the relevant Sundays in April & October,
particularly as the relatively limited lifespan of most handsets would
necessitate only a five-year calendar. Or, most drastically, handsets
could be programmed to "hiccup" through a sync channel read every
specified period of time - perhaps once every two or three hours - in
order to maintain more precise clock synchronization w/ system time,
though each "hiccup" could cause a handset to miss a simultaneous
message on the paging channel, resulting in a call defaulting to
voicemail or an SMS being delivered late.

Andrew
--
Andrew Shepherd
[email protected]
[email protected]
http://www.ku.edu/home/cinema/

In article <[email protected]>,
[email protected] (Andrew Shepherd) wrote:

> "Getting it right" would entail that handset manufacturers implement
> some sort of intelligence into the embedded clocks. At 2am on a
> Sunday morning every April & October, Windows seeks my permission to
> automatically update my PC clock according to initiation or expiration
> of Daylight Savings Time. The same could be and probably will be done
> as modern handsets adopt more PC-like operating systems.

Most PCs do it automatically; and if you have a "dual-boot" PC, say with
Windows XP, and Windows 98; it'll get done twice, and then you're off by
an hour.

Good explanation. Thanks. ;-)

Scotty



"Andrew Shepherd" <[email protected]> wrote in message
news:[email protected]...
> "Steve" <[email protected]> wrote in message
news:<[email protected]>...
> > My Treo 600 in Chicago still shows it's 9am... when it should be 10am.
Does
> > the Treo not set with the network?
>
> Precisely synchronized system time is imperative to the success of
> CDMA. And the clock on your handset derives its synchronization
> latently from the CDMA sync channel. After synchronization has been
> achieved, the clock runs asynchronously until another access of the
> sync channel resets the clock, which is why most CDMA handsets will
> continue to maintain time while AMPS roaming until power-cycled.
> However, for example, my handset clock w/o the benefit of periodic
> reads of the sync channel while AMPS roaming gains at least a minute
> or two per 24 hours.
>
> The compelling question then is: what prompts an access of the sync
> channel?
>
> Several user-side or network-side actions can prompt an access or
> re-access of the sync channel. First of all, powering-on or
> power-cycling the handset will always initiate a read of the sync
> channel to establish synchronization w/ the network system time. On
> the other hand, routine registration - timer-based, distance-based, or
> zone-based - and even a static handset quietly completes at least
> several timer-based registrations per day - should not require a
> re-read of the sync channel, though this might vary by handset
> manufacturer. Originating or receiving a voice call, SMS,
> circuit-switched data connection, or packet-switched data connection
> will also not prompt access of the sync channel. However, termination
> of that transmission - even one as brief as that of an SMS over the
> paging channel - will always once again prompt a re-sync w/ system
> time via an access of the sync channel, which will also reset the
> clock.
>
> Therefore, on the biannual nights when Daylight Savings Time begins or
> ends, unless your handset receives a call or an SMS after 2am, your
> handset clock will continue to operate non-sync and you will awaken to
> find the incorrect time until one of the above events prompts a
> re-access of the CDMA sync channel.
>
> Andrew
> --
> Andrew Shepherd
> [email protected]
> [email protected]
> http://www.ku.edu/home/cinema/

[email protected] (Andrew Shepherd) wrote in message news:<[email protected]>...

> W/ all due respect, I do not think that I over analyzed the problem.
> This newsgroup has become largely a shouting gallery for
> misinformation, double-speak, & slander.

<sigh> agreed

> Heaven forbid that someone
> should disseminate some concrete technical truth around here. You
> probably meant no offense, but I often feel ignored or
> underappreciated around here when I altruistically attempt to assist &
> educate on the inner-workings of CDMA technology or wireless
> regulatory issues.

Oh, I think the info you provided is great. A bit tough to parse,
perhaps, but that's more the reader's (my) fault. However, the next
time I'm looking for technical CDMA info, I'll be mining your posts!

> "Getting it right" would entail that handset manufacturers implement
> some sort of intelligence into the embedded clocks. At 2am on a
> Sunday morning every April & October, Windows seeks my permission to
> automatically update my PC clock according to initiation or expiration
> of Daylight Savings Time. The same could be and probably will be done
> as modern handsets adopt more PC-like operating systems. Similarly,
> handsets could be programmed to automatically cycle through a sync
> channel read at 2am on the relevant Sundays in April & October,
> particularly as the relatively limited lifespan of most handsets would
> necessitate only a five-year calendar. Or, most drastically, handsets
> could be programmed to "hiccup" through a sync channel read every
> specified period of time - perhaps once every two or three hours - in
> order to maintain more precise clock synchronization w/ system time,
> though each "hiccup" could cause a handset to miss a simultaneous
> message on the paging channel, resulting in a call defaulting to
> voicemail or an SMS being delivered late.

I don't mean to imply that it's rocket science. The Apr/Oct rule is a
bit US-centric. DST changes are surprisingly location-dependent, and
cellphones tend to be, well, mobile. Your "more drastic" solution is
definitely more generic.

Andrew S <[email protected]> wrote:
> [email protected] (Andrew Shepherd) wrote in message news:<[email protected]>...
>
>> W/ all due respect, I do not think that I over analyzed the problem.
>> This newsgroup has become largely a shouting gallery for
>> misinformation, double-speak, & slander.
>
> <sigh> agreed

Largely due to the efforts of maybe two or three people... there are plenty of
others here who are willing to actually discuss technical stuff.

--
JustThe.net Internet & New Media Services, Apple Valley, CA PGP: 0xE3AE35ED
Steven J. Sobol, Geek In Charge / 888.480.4NET (4638) / [email protected]
Domain Names, $9.95/yr, 24x7 service: http://DomainNames.JustThe.net/
"someone once called me a sofa, but i didn't feel compelled to rush out and buy
slip covers." -adam brower * Hiroshima '45, Chernobyl '86, Windows 98/2000/2003

In article <[email protected]>,=20
[email protected] says...
> Typical blind SprintPCS apologists. Don't like the message, attack the=20
> messenger.
>=20

Typical dishonest antagonist. Have his dishonesty refuted, change=20
the topic.

--=20
R=D8=DF
O/Siris
I work for Sprint PCS
I *don't* speak for them