I used to recover electronics from saltwater and freshwater intrusion, as well as from toilet water, various chemicals both solid and liquid, mould and others for a living.
Remove the device from its housing to the degree you find possible and soak it in 99% isopropyl alcohol (NOT rubbing alcohol, which is typically only 70% isopropyl - you want 99% pure). Swirl it around after a couple/few hours, repeat until it appears clean. Remove from the alcohol and allow to dry thoroughly - you can also use a brush to displace any crud during or after the soak. Give it at least a day or two to dry, then reassemble and test. CRITICAL NOTES:
1. 99% isopropyl alcohol is beyond flammable, it's explosive! No smoking, open flame, or anything capable of causing ignition in the room you use.
2. That alcohol evaporates extremely quickly at room temperature - ventilate the room well if you wish to live.
3. Any visible rust or corrosion evident after the above is an indicator that the device will likely not survive, or at least survive for long. Best action in that case is do NOT apply power, buy a new one.
I understand how you can use software to replace some of the active circuitry, but how are you going to change the size and shape of an antenna via software?
You don't necessarily need to change the size, you need to change the resonant frequency and impedance. This is currently done with 'automatic' antenna tuning circuits using varicaps and other components/switching circuitry that varies the resonant frequency by varying bias voltages.
You don't understand how it works. Using 4 overlapping channels, 1, 4, 8 and 11 is just as good as 1, 6, 11.
That's wrong for "11 Mb/Sec", which is the commonly-advertised maximum (and default, usually) rate, although the RF (OSI layer 1, transport) 'overhead' reduces that to 6-7 Mbps of "meat" in 802.11b. 1, 6 and 11 are the 3 unblocking channels.
A technical explanation in this forum would likely be unproductive, since a discussion of chipping (CCP) and modulation schemes would probably be meaningless to most folks here (imho?). Reply if you disagree;).
A throwaway line I've been using for years is "if I entered college now to learn my field, I'd be in college for the rest of my life trying desperately to catch up to what has been developed just since I entered college!"
As others have posted, an engineering course is only intended to teach(/force) you to learn how to learn - the bleeding edge is not a static objective.
In my neighbourhood, local service has high costs to the telco in line, concentrator, and other infrastructure maintenance. Someone suggested that it's a "sunk" cost - not so!
Traditionally around here (B.C. Canada) monopoly long-distance tolls used to subsidize the cost to maintain those millions of miles of local copper (counting each pair's mileage separately) and infrastructure. The government-regulated local loop charges were allowed to increase to compensate for losses of l/d revenues to the competition when the monopoly was opened up around 20 years ago.
> and I assure you that the next new battery technology will NOT be serendipitous, rather it will be the result of years of (frustrating) research building on discoveries dating all the way back to wet towels and copper discs.
Thank you for your illuminating post - I'm aware of some of the challenges in battery design, and the huge expenses incurred in battery R&D, and tried to impart that concept to the reader in my simple way.
I'm only a user of stored ergs - your "note from the trenches" of battery design made my point with eloquence!
...has swallowed large amounts of R&D money since batteries were first invented/discovered. Yes, improvements are most often incremental, and differing technologies offer different qualities (Li-On maintains voltage 'til almost complete discharge; GNB (now Exide) Absolite batteries work down to at least -60 C. with a normal 20-year service life), NiMH avoids NiCd's memory effect, but stop working at 0 C./32 F.).
Demand for tiny, high-capacity stored power sources has never been greater than today, and the R&D budgets are ever rising, but forecasting when the next serendiptuous discovery of a new technology will occur is not easy...
IBM invented plug and play, and OS/2 had it, 'til Microsoft "invented" a method different enough to break IBM's and make theirs the de facto standard.
> limited registry,
IMHO this is a GOOD thing;)
> limited games support
...understandable in a business sense (although OS/2's solitaire had a Cheat key, and a sense of humour if you used it too much) - IBM's never put out a dedicated game machine (PSII, Xbox, et al) of which I'm aware either.
> less APIs,
How many stable APIs did Win95 have? Are you familiar with all the Workplace APIs? (since Workplace is the descendant of OS/2)
> it's not a moving target and its API very closely resembles Win16 / Win32.
A non-moving target would be a bad thing why, again?;) The API resemblance to Win16/32 is irrelevant.
Look for the REN ("Ringer Equivalence Number") on the phones - the sum of all the phones' RENs should add up to less than the REN of the VoIP box, else the current the phones will need to ring could blow the ring generator in the VoIP box.
I can't imagine that's the case. With a 700ms delay each way
I said ~520 ms round trip, which means both ways, aka ~260 ms each way. You'd be surprised how close that is to normal human "think time" for those who think before they verbally react.
You may be interested to know that sub 80 ms response is a bit faster than "normal" PSTN (Public Switched Telephone Network) latency for an interstate call within the USA.
Do you have details? Sat. networks I've seen have about a ~250ms latency each way, not the 10-100ms wired connections tend to have.
Yes, ~250 ms each way is close (depending on one's exact distance from the bird, and ignoring the propagation latency through the equipment at each end). It's a lot easier for humans to accomodate a ~520 ms roundtrip: that's not an unusual latency for a normal human reaction to the words heard - it doesn't start getting annoying or noticeable until it's 700-800 ms or higher, imho.
With all due respect, don't say that to the thousands of people who have used our satellite network technology over the years for voice and video. That includes Provincial Governments that do medical imaging (remote medicine), as well as videoconferencing on our satellite network.
I've been engineering at a VoIP-over-satellite telephone network for about 6 years now. Using old circuit-switched telephone technology over a DAMA satellite system is usually very poor to unusable (the telcos use/used SCPC links to move PSTN traffic).
Using VoIP over sat. links works for clear, toll quality service, with round-trip delay in the order of 520 - 550 mSec... that's about half a second after you finish asking "OK?" that you hear the other end answer with their "OK" (not counting "think time", aka "human latency"). There's lots of carriers whose technology does poorly for the application, but our in-house technology provides good results as above.
WiMAX is an up-and-coming technology that can be utilized on both licensed and unlicensed spectrum. The interoperability specs haven't been finalized yet, but manufacturers are working as hard as possible to incorporate current rapid advances in RF technologies (that, collectively, will get 'snapshotted' for the 802.16 WiMAX spec) to provide competitive advantages in their current product lines. The operating frequency has nothing to do with "WiMAX" technology itself
> a CN tower transmitter could service most of Ontario
Well, a hundred mile radius, perhaps, line-of-sight (Toronto folks forget Ontario stretches for another 1200 miles north of their region, never mind east-west), but using what immense piece of spectrum? A million customers (conservatively) wanting high-speed downlink and settling for dialup backhaul would still require much more bandwidth than is available in any RF span ("band"), even with QAM64 or better.
> ANd what about satellite internet, how come its still 2x the price of DSL or cable when theres so many rural citizens who'd otherwise have bought it.
It's so costly because (a) a system that transmits to the satellite costs 10 times what a simple mass-produced TVRO TV receiving system does; (b) once the user has to share the cost of their transmitter bandwidth, they quickly realize just how many $million/year the TV broadcasters pay for upstream bandwidth (the satellite owner has to replace that $300 million bird every 10-15 years, monitor and steer it 24/7, and also make a profit) - and the TV broadcasters even get their bandwidth 'wholesale', being the high-volume, long-term customers of the satellite operators that they are...
Also, aligning a transmitting antenna is much more involved than aiming a TVRO dish by tone - it takes an experienced tech practiced in an advanced technology, usually working via telephone with the satellite operator to properly commission an earth station, so the installation costs money too.
[Offtopic; responding to personal "button-push" - mod at will!]
Lots of misconceptions in the replies, so here's some hard facts (btw, I've been operating a VoIP telephone network over GEO satellites since 1999):
1. Roundtrip latency (ping gnd to bird to gnd, plus reply gnd to bird to gnd) runs around 520 mSec for an SCPC (Single Channel Per Carrier) satellite link with sat-optimized TCP/IP stack. Toll-quality voice is easy with Cisco gear and our trade-secret methodology.
2. You almost certainly are using a DAMA (Demand-Assigned Multiple Access) link for Internet feed via satellite. This is a demand-based TDMA-like link, whereby sometimes your packet goes out "immediately", and some other times has to wait for the next (or next...) slot to be made available. Ping times could run 600-700 mSec best-case, but can vary to 1200 - 2400 mSec between one ping and the next. This is alright for Internet access, but sucks for VoIP.
(DAMA allows far more users per satellite bandwidth, and bandwidth costs are the biggest ongoing expense of using a satellite link. For non-time-sensitive applications like web browsing it's a no-brainer choice).
3. Having said that, it'd be worth a try if you already have the sat. link in place, but I very much doubt that you'd find it acceptable on a DAMA system.
4. My location at ~49N x ~122W is ~38,694 Km from the PanAmSat G4R satellite at 99W degrees above the equator. Take speed of light over twice that distance (up + down), allow for modulation and demodulation latencies (10-40 mSec), and you'll approach the end-to-end sat. latency. Round trip times on our network are around 520 mSec, which is a small delay that phone users quickly get used to.
Having seen the wide range of speculation and misinformation in this thread, but having no wish to get involved in US politics, I'll be vague on details... but after a number of years of designing and operating a wide variety of commercial earth stations, I'm here to tell you that jamming others' services is simple and easy to do, given a certain amount of infrastructure.
The "remarkable" ability of the military to accomplish their objective years ahead of plan sounds like the all-too-frequent result of a plan dreamed up in isolation by marketers, board members, and managers working with no real technical input, once they finally present their vision to an engineer.
Translate the commercial job functions listed above into their military/gov't equivalents, adding "spooks" to taste.
I've been deploying VoIP since 1999 - if packets arrive in a QOS-optimized order at the router, that single router won't impact the QOS downstream if the downstream path isn't heavily loaded (and the QOS bits aren't stripped or ignored by that router)
Selsius was a joint venture of telco folks (who knew that market) and data folks that succeeded by doing well develping customer-driven solutions. When Cisco bought them, their technology became the property of data folks with no real telco exposure... in early days, Cisco reps mocked the need for fax support "since everybody uses email these days" - it was a battle every step of the way to teach them to accept the customers' long-established expectations for telephony services (it's not "new tech", data folks, just ultra-standardized "old tech" done a new way).
Cisco still stumbles often with ease-of-use for telephony features (although, to be fair, it may now more likely be the clients' data people who misunderstand telephony expectations, from what I've read on this thread), where a company like Avaya (descended from AT&T/Bell Labs' decades of PBX development) does the user-friendly features very well in their VoIP offerings, albeit with a reluctance to price their offerings appropriately for a competitive market, rather than for the old PBX-and-larger top tier that they've "owned" for decades...
Actually Cisco bought Selsius in 1999 to get a foothold in VoIP - we were using Selsius gear before their buyout to provide toll-quality voice/fax telephone service over satellite to remote Arctic locations (and you think YOU've got high bandwidth costs?;).
We had also selected Aironet as best-of-breed for wireless last-mile network connectivity at those remote sites when Cisco bought Aironet Corp. in 2000 to get a foothold in wireless TCP/IF (WiFi) - strike two from the 800-lb. gorilla!
A paranoid might think they were freeloading off our qualification processes to direct them to the best stuff for the markets they decided to enter, but it was just an unfortunate, coincidental 1-2 punch...
Slashdot Mirror
I used to recover electronics from saltwater and freshwater intrusion, as well as from toilet water, various chemicals both solid and liquid, mould and others for a living. Remove the device from its housing to the degree you find possible and soak it in 99% isopropyl alcohol (NOT rubbing alcohol, which is typically only 70% isopropyl - you want 99% pure). Swirl it around after a couple/few hours, repeat until it appears clean. Remove from the alcohol and allow to dry thoroughly - you can also use a brush to displace any crud during or after the soak. Give it at least a day or two to dry, then reassemble and test. CRITICAL NOTES: 1. 99% isopropyl alcohol is beyond flammable, it's explosive! No smoking, open flame, or anything capable of causing ignition in the room you use. 2. That alcohol evaporates extremely quickly at room temperature - ventilate the room well if you wish to live. 3. Any visible rust or corrosion evident after the above is an indicator that the device will likely not survive, or at least survive for long. Best action in that case is do NOT apply power, buy a new one.
You don't necessarily need to change the size, you need to change the resonant frequency and impedance. This is currently done with 'automatic' antenna tuning circuits using varicaps and other components/switching circuitry that varies the resonant frequency by varying bias voltages.
That's wrong for "11 Mb/Sec", which is the commonly-advertised maximum (and default, usually) rate, although the RF (OSI layer 1, transport) 'overhead' reduces that to 6-7 Mbps of "meat" in 802.11b. 1, 6 and 11 are the 3 unblocking channels.
A technical explanation in this forum would likely be unproductive, since a discussion of chipping (CCP) and modulation schemes would probably be meaningless to most folks here (imho?). Reply if you disagree ;).
Mod that UP! (n/t)
As others have posted, an engineering course is only intended to teach(/force) you to learn how to learn - the bleeding edge is not a static objective.
Traditionally around here (B.C. Canada) monopoly long-distance tolls used to subsidize the cost to maintain those millions of miles of local copper (counting each pair's mileage separately) and infrastructure. The government-regulated local loop charges were allowed to increase to compensate for losses of l/d revenues to the competition when the monopoly was opened up around 20 years ago.
Thank you for your illuminating post - I'm aware of some of the challenges in battery design, and the huge expenses incurred in battery R&D, and tried to impart that concept to the reader in my simple way.
I'm only a user of stored ergs - your "note from the trenches" of battery design made my point with eloquence!
Demand for tiny, high-capacity stored power sources has never been greater than today, and the R&D budgets are ever rising, but forecasting when the next serendiptuous discovery of a new technology will occur is not easy...
The logo may also be Atmel (they do lots of microwave SMDs) - ink deposition is often unclear when marking such tiny housings...
Mitsubishi
IBM invented plug and play, and OS/2 had it, 'til Microsoft "invented" a method different enough to break IBM's and make theirs the de facto standard.
> limited registry,
IMHO this is a GOOD thing ;)
> limited games support
> less APIs,
How many stable APIs did Win95 have? Are you familiar with all the Workplace APIs? (since Workplace is the descendant of OS/2)
> it's not a moving target and its API very closely resembles Win16 / Win32.
A non-moving target would be a bad thing why, again? ;) The API resemblance to Win16/32 is irrelevant.
Look for the REN ("Ringer Equivalence Number") on the phones - the sum of all the phones' RENs should add up to less than the REN of the VoIP box, else the current the phones will need to ring could blow the ring generator in the VoIP box.
I said ~520 ms round trip, which means both ways, aka ~260 ms each way. You'd be surprised how close that is to normal human "think time" for those who think before they verbally react.
You may be interested to know that sub 80 ms response is a bit faster than "normal" PSTN (Public Switched Telephone Network) latency for an interstate call within the USA.
Yes, ~250 ms each way is close (depending on one's exact distance from the bird, and ignoring the propagation latency through the equipment at each end). It's a lot easier for humans to accomodate a ~520 ms roundtrip: that's not an unusual latency for a normal human reaction to the words heard - it doesn't start getting annoying or noticeable until it's 700-800 ms or higher, imho.
With all due respect, don't say that to the thousands of people who have used our satellite network technology over the years for voice and video. That includes Provincial Governments that do medical imaging (remote medicine), as well as videoconferencing on our satellite network.
Using VoIP over sat. links works for clear, toll quality service, with round-trip delay in the order of 520 - 550 mSec ... that's about half a second after you finish asking "OK?" that you hear the other end answer with their "OK" (not counting "think time", aka "human latency"). There's lots of carriers whose technology does poorly for the application, but our in-house technology provides good results as above.
Well, a hundred mile radius, perhaps, line-of-sight (Toronto folks forget Ontario stretches for another 1200 miles north of their region, never mind east-west), but using what immense piece of spectrum? A million customers (conservatively) wanting high-speed downlink and settling for dialup backhaul would still require much more bandwidth than is available in any RF span ("band"), even with QAM64 or better.
It's so costly because (a) a system that transmits to the satellite costs 10 times what a simple mass-produced TVRO TV receiving system does; (b) once the user has to share the cost of their transmitter bandwidth, they quickly realize just how many $million/year the TV broadcasters pay for upstream bandwidth (the satellite owner has to replace that $300 million bird every 10-15 years, monitor and steer it 24/7, and also make a profit) - and the TV broadcasters even get their bandwidth 'wholesale', being the high-volume, long-term customers of the satellite operators that they are...
Also, aligning a transmitting antenna is much more involved than aiming a TVRO dish by tone - it takes an experienced tech practiced in an advanced technology, usually working via telephone with the satellite operator to properly commission an earth station, so the installation costs money too.
[Offtopic; responding to personal "button-push" - mod at will!]
'Was going to disagree with some mod's "troll" rating, but it's +1 Insightful now. I'd likely mod even higher, had I the points. Nice piece.
1. Roundtrip latency (ping gnd to bird to gnd, plus reply gnd to bird to gnd) runs around 520 mSec for an SCPC (Single Channel Per Carrier) satellite link with sat-optimized TCP/IP stack. Toll-quality voice is easy with Cisco gear and our trade-secret methodology.
2. You almost certainly are using a DAMA (Demand-Assigned Multiple Access) link for Internet feed via satellite. This is a demand-based TDMA-like link, whereby sometimes your packet goes out "immediately", and some other times has to wait for the next (or next...) slot to be made available. Ping times could run 600-700 mSec best-case, but can vary to 1200 - 2400 mSec between one ping and the next. This is alright for Internet access, but sucks for VoIP.
(DAMA allows far more users per satellite bandwidth, and bandwidth costs are the biggest ongoing expense of using a satellite link. For non-time-sensitive applications like web browsing it's a no-brainer choice).
3. Having said that, it'd be worth a try if you already have the sat. link in place, but I very much doubt that you'd find it acceptable on a DAMA system.
4. My location at ~49N x ~122W is ~38,694 Km from the PanAmSat G4R satellite at 99W degrees above the equator. Take speed of light over twice that distance (up + down), allow for modulation and demodulation latencies (10-40 mSec), and you'll approach the end-to-end sat. latency. Round trip times on our network are around 520 mSec, which is a small delay that phone users quickly get used to.
The "remarkable" ability of the military to accomplish their objective years ahead of plan sounds like the all-too-frequent result of a plan dreamed up in isolation by marketers, board members, and managers working with no real technical input, once they finally present their vision to an engineer.
Translate the commercial job functions listed above into their military/gov't equivalents, adding "spooks" to taste.
I've been deploying VoIP since 1999 - if packets arrive in a QOS-optimized order at the router, that single router won't impact the QOS downstream if the downstream path isn't heavily loaded (and the QOS bits aren't stripped or ignored by that router)
Cisco still stumbles often with ease-of-use for telephony features (although, to be fair, it may now more likely be the clients' data people who misunderstand telephony expectations, from what I've read on this thread), where a company like Avaya (descended from AT&T/Bell Labs' decades of PBX development) does the user-friendly features very well in their VoIP offerings, albeit with a reluctance to price their offerings appropriately for a competitive market, rather than for the old PBX-and-larger top tier that they've "owned" for decades...
We had also selected Aironet as best-of-breed for wireless last-mile network connectivity at those remote sites when Cisco bought Aironet Corp. in 2000 to get a foothold in wireless TCP/IF (WiFi) - strike two from the 800-lb. gorilla!
A paranoid might think they were freeloading off our qualification processes to direct them to the best stuff for the markets they decided to enter, but it was just an unfortunate, coincidental 1-2 punch...