Bouncing off of a satellite should accomplish that nicely.:-)
GEO orbit is at ~35,790km for a round trip of ~70,000km at 299,792,458 m/s ~= 0.25 sec.
Add that to your standard internet routing and you'll have your 750ms.
If the plane was close to the ground, yes, it would work - aside from the fact that the luggage compartment is basically a poor faraday cage. Once you get a few thousand feet in the air, however, signal strength drops dramatically due the the toroidial nature of cell antennas. In GA aircraft, I have never received a signal above 6000' AGL. Usually no more than ~2500'. Stick that same phone in a luggage compartment of a jetliner and you have very little time to activate your device.
Using an IP network has another advantage - it allows the "trigger" and the "device" to be separate components which can communicate via infrastructure provided by the airliner. Security screeners see a plethora of laptops pass through security and probably wouldn't think twice about them. It also allows the "trigger" to be almost completely software-based which will for sure pass undetected by screeners. (Will we have mandatory OS security scans in the future?) The actual "device" would just need the most basic of IP interfaces (ala Gumstix) to receive the "activate" signal once the software did all of the calculations for the attack. They could even be calculated/manually performed by someone on the ground.
I'm not saying that we shouldn't push forward with this, we just need to be aware of what attack vectors we're opening in the process.
Does anyone else see this as a security risk? If suddenly we have cell and internet access on planes, "all" someone has to do is get some nasty device (explosive, gas, greek fire, whatever) on the flight and activate it remotely via whatever method they choose. Our physical security on flights is improved, but far from effective (remember the student who got some razor blades or something on a plane a couple years back, not to mention the recent incident of luggage being flown even though the passenger was not aboard). Right now, nothing catastrophic has happened because there are a limited number of people willing to sacrifice their own life for . If we open things up so that you can take down an airplane just by smuggling something on it, I see this as a major problem. I'm not usually one to balk at new technology, but this seems like an invitation for disaster unless we first fix the physical security measures that plague the industry.
In addition to this, focus on learning how to learn. In a field with so many variables and very few constants, you have to continuously keep up with how the industry is changing shape.
IMO, Blizzard's programming schema/mantra/whatever has led to an unusual level of stability in their games compared to most others out there which in turn has led to their increased playability. Less frustration = more time spent playing. I remember playing Starcraft a ton more than say, Carmageddon, simply because the game didn't crash 1 of 5 times in networking mode.
Another aspect that has led to their success is the extensible format in their RTS games. I still play WC3 mods years after it was released because people keep making enjoyable, challenging maps for the engine. This level of customizability is rare, but very welcomed.
On the topic of WoW, well, they screwed some things up - but with that said, WoW is arguably the "best" (not intended as flamebait) MMO out there and helped to bring the genre out of nerds' basements/dorm rooms into the light of the "regular" world. Also, in Blizzard's defense, the game grew to levels they never imagined at launch and while one would hope that the code would be extensible enough to handle such an inrush, it obviously fell short.
Overall, I agree with another poster that summed it up by saying that Blizzard creates games that define genres - and not only create, but create well, with solid code backed by extensive balancing and testing.
There isn't any "burn-in" - at least not in the traditional sense. Over time, the pigment capsules degrade which leads to a reduced contrast ratio. Initial specs have contrast at 8:1 going down to 5:1 at the end of its life (after ~40,000 hours of "normal" use).
As far as residual image, yes this is an issue - although not a show-stopper. E-Ink currently has 6 waveforms for updating the image, each with a clearer image being presented at the cost of time and "flicker" during the transition. If you update a page of text to a blank (white) screen, you can still read the previous text as a faint residual remains. When covered with new text, however, this ghosting is not that significant of a issue.
I must say, having recently viewed the technology, it has a very promising future. We'll just have to wait and see how close that future is depending on how well the new Sony reader does...
I use this tool at work all the time - mostly for recovering files from problematic systems and for virus/adware scanning. It works great! That said, I tried putting BartPE on a USB key back about 6 months ago to no avail. It works great right up to the point that XP initializes your USB devices - then *POOF*, no more boot drive. The RAM drive is a clever workaround and I will have to give that a shot. If you're using Dell's, however, I wouldn't expect too much luck. The older Optiplex's don't support USB booting and the newest ones seem to not like the BartPE variant. I did have luck with the GX270 series, however. Just posting my experiences for others to learn from...
For my church projector setup, we're planning to use a Cat5 video extender to get a signal to a couple ceiling-mounted projectors. Obviously, the projector itself needs its own power, but the box that translates the cat5 signal back to DB15 needs its own brick as well. I've looked, and after looking, dreamed for a device that uses PoE for a video extender. Perfect application IMO.
The HP rating is peak, so that's what the motors give basically at stall. Under normal operation, each of them can output (consume) ~1/4 HP (187W) continuously without overheating. Then there's the fact that they only run ~70% efficient and the most significant loss (other than wind friction) of the friction drive instead of a belt/chain (probably the biggest thing I would do differently if I were to redesign).
So you are correct, the raw numbers are high. I'm just so used to using "max" numbers from designing BattleBots where it's all about maxing out everything but only to the point where it will still run for 3 minutes.:-)
(Using "max" numbers also makes it easier in sourching parts as in my experience most everything is rated at or near peak values.)
After getting into BattleBots years ago, I decided to reduce my commute to college (before I graduated) by building an electric scooter out of "spare" parts. It's not an e-bike from the standpoint that I didn't want to have to input any energy into the system myself (i.e. the motors had to do all the work). For cost and simplicity reasons, I chose to go with SLA (sealed lead acid) batteries and a couple of overvolted motors. With the proper timing, I achieved a flat speed of 16.5 MPH on two 1HP motors. With 64Ah (@12V) of Pb-acid chemistry onboard (this weighed a whopping 50 pounds), I had a maximum range (tested on all terrain including large hills) of just over 12 miles.
That's what I did and perhaps you can learn from what I would have done differently. First off, I would have used NiMh batteries. This would have cut the weight in more than half and also would have allowed me to customize the pack more both in shape and capacity (I only needed to go 9 miles in a day). The only downside to this was the charge time. SLA batteries are pretty indestructible and I could charge the full 64Ah in around an hour. With NiMh, you're talking about several hours or less if you don't mind compromising lifespan (with the right charger you could charge the same capacity in NiMh in the same time if you didn't mind getting only ~100 charges out of your packs). If I had the cash, I would probably use the high capacity, high discharge Li-Ion batteries from PowerStream (http://www.powerstream.com/LL.htm) as they would be incredibly light (~10 pounds for the same capacity).
As far as the motors went, I was fairly satisfied with the power output, but would have liked more. If you compare it to a car (~100HP for ~2000 pounds), you should have ~10-15HP available for the same performance. Now with electric motors, due to their differing torque curves (in comparison to internal combustion engines), you can achieve similar results from significantly less overall horsepower, but I still would have preferred having 3-6HP on my project.
Of course, if you go with high output motors, you need a speed controller capable of handling the current. And if you go with the Li-Ion batts, you need a fairly expensive charger.
I'm not exactly sure why they went to 1.0 either - although it has been much more stable than ever before (since 0.7). I guess they figured that it was good enough to "officially" release.
For those interested, here is the changelog from the sourceforge site:
version 1.0.0 (09/17/2004):
New Features:
* Drag-and-drop buddy support for the Invite dialog (Stu Tomlinson)
* Drag-and-drop buddy support for the Pounce dialog (Stu Tomlinson)
* View Chat log available from the interface (Daniel Atallah)
* Ability to receive offline messages in character encodings
other than ASCII (thanks to Nick Sukharev)
* File transfer status messages printed to conversation
windows (Dave West)
* Display file transfer messages when someone sends you a file
over AIM (Dave West)
* Handle MSN buddy lists more sanely (Felipe Contreras)
* Zephyr can use tzc to run from behind a firewall (Arun A Tharuvai)
Bug Fixes:
* Work around window manager stupidity with new dialog windows (Dave West)
* Compile with gtk 2.5.x (Gary Kramlich)
* Escape invalid characters in log names (Daniel Atallah)
* Fix for clicking add in an msn chat with 2 or more people in your buddy
list (Daniel Atallah)
Slashdot Mirror
Bouncing off of a satellite should accomplish that nicely. :-)
GEO orbit is at ~35,790km for a round trip of ~70,000km at 299,792,458 m/s ~= 0.25 sec.
Add that to your standard internet routing and you'll have your 750ms.
If the plane was close to the ground, yes, it would work - aside from the fact that the luggage compartment is basically a poor faraday cage. Once you get a few thousand feet in the air, however, signal strength drops dramatically due the the toroidial nature of cell antennas. In GA aircraft, I have never received a signal above 6000' AGL. Usually no more than ~2500'. Stick that same phone in a luggage compartment of a jetliner and you have very little time to activate your device.
Using an IP network has another advantage - it allows the "trigger" and the "device" to be separate components which can communicate via infrastructure provided by the airliner. Security screeners see a plethora of laptops pass through security and probably wouldn't think twice about them. It also allows the "trigger" to be almost completely software-based which will for sure pass undetected by screeners. (Will we have mandatory OS security scans in the future?) The actual "device" would just need the most basic of IP interfaces (ala Gumstix) to receive the "activate" signal once the software did all of the calculations for the attack. They could even be calculated/manually performed by someone on the ground.
I'm not saying that we shouldn't push forward with this, we just need to be aware of what attack vectors we're opening in the process.
Does anyone else see this as a security risk? If suddenly we have cell and internet access on planes, "all" someone has to do is get some nasty device (explosive, gas, greek fire, whatever) on the flight and activate it remotely via whatever method they choose. Our physical security on flights is improved, but far from effective (remember the student who got some razor blades or something on a plane a couple years back, not to mention the recent incident of luggage being flown even though the passenger was not aboard). Right now, nothing catastrophic has happened because there are a limited number of people willing to sacrifice their own life for . If we open things up so that you can take down an airplane just by smuggling something on it, I see this as a major problem. I'm not usually one to balk at new technology, but this seems like an invitation for disaster unless we first fix the physical security measures that plague the industry.
Actually, "black boxes" are mostly orange. :-)
http://travel.howstuffworks.com/black-box5.htm
Just replace the battery with a new one from a site like http://ifixit.com/.
In addition to this, focus on learning how to learn. In a field with so many variables and very few constants, you have to continuously keep up with how the industry is changing shape.
IMO, Blizzard's programming schema/mantra/whatever has led to an unusual level of stability in their games compared to most others out there which in turn has led to their increased playability. Less frustration = more time spent playing. I remember playing Starcraft a ton more than say, Carmageddon, simply because the game didn't crash 1 of 5 times in networking mode. Another aspect that has led to their success is the extensible format in their RTS games. I still play WC3 mods years after it was released because people keep making enjoyable, challenging maps for the engine. This level of customizability is rare, but very welcomed. On the topic of WoW, well, they screwed some things up - but with that said, WoW is arguably the "best" (not intended as flamebait) MMO out there and helped to bring the genre out of nerds' basements/dorm rooms into the light of the "regular" world. Also, in Blizzard's defense, the game grew to levels they never imagined at launch and while one would hope that the code would be extensible enough to handle such an inrush, it obviously fell short. Overall, I agree with another poster that summed it up by saying that Blizzard creates games that define genres - and not only create, but create well, with solid code backed by extensive balancing and testing.
There isn't any "burn-in" - at least not in the traditional sense. Over time, the pigment capsules degrade which leads to a reduced contrast ratio. Initial specs have contrast at 8:1 going down to 5:1 at the end of its life (after ~40,000 hours of "normal" use).
As far as residual image, yes this is an issue - although not a show-stopper. E-Ink currently has 6 waveforms for updating the image, each with a clearer image being presented at the cost of time and "flicker" during the transition. If you update a page of text to a blank (white) screen, you can still read the previous text as a faint residual remains. When covered with new text, however, this ghosting is not that significant of a issue.
I must say, having recently viewed the technology, it has a very promising future. We'll just have to wait and see how close that future is depending on how well the new Sony reader does...
I use this tool at work all the time - mostly for recovering files from problematic systems and for virus/adware scanning. It works great! That said, I tried putting BartPE on a USB key back about 6 months ago to no avail. It works great right up to the point that XP initializes your USB devices - then *POOF*, no more boot drive. The RAM drive is a clever workaround and I will have to give that a shot. If you're using Dell's, however, I wouldn't expect too much luck. The older Optiplex's don't support USB booting and the newest ones seem to not like the BartPE variant. I did have luck with the GX270 series, however. Just posting my experiences for others to learn from...
Haven't looked at specifics, but try http://www.anandtech.com/
My thoughts exactly - followed by the "that's a very interesting 'liitle Sister'" thought...
We use a server from http://www.idealstor.com./ Simple, big and relatively cheap (5TB ~ $5000).
For my church projector setup, we're planning to use a Cat5 video extender to get a signal to a couple ceiling-mounted projectors. Obviously, the projector itself needs its own power, but the box that translates the cat5 signal back to DB15 needs its own brick as well. I've looked, and after looking, dreamed for a device that uses PoE for a video extender. Perfect application IMO.
Also beneficial for those doing KVMoE.
The HP rating is peak, so that's what the motors give basically at stall. Under normal operation, each of them can output (consume) ~1/4 HP (187W) continuously without overheating. Then there's the fact that they only run ~70% efficient and the most significant loss (other than wind friction) of the friction drive instead of a belt/chain (probably the biggest thing I would do differently if I were to redesign).
:-)
So you are correct, the raw numbers are high. I'm just so used to using "max" numbers from designing BattleBots where it's all about maxing out everything but only to the point where it will still run for 3 minutes.
(Using "max" numbers also makes it easier in sourching parts as in my experience most everything is rated at or near peak values.)
You can read my post under yours for more info, but the short answer to your question is http://www.robotmarketplace.com/.
I would recommend the "EV Warrior" motor for price-performance or the "MagMotors" if budget isn't such an issue.
After getting into BattleBots years ago, I decided to reduce my commute to college (before I graduated) by building an electric scooter out of "spare" parts. It's not an e-bike from the standpoint that I didn't want to have to input any energy into the system myself (i.e. the motors had to do all the work). For cost and simplicity reasons, I chose to go with SLA (sealed lead acid) batteries and a couple of overvolted motors. With the proper timing, I achieved a flat speed of 16.5 MPH on two 1HP motors. With 64Ah (@12V) of Pb-acid chemistry onboard (this weighed a whopping 50 pounds), I had a maximum range (tested on all terrain including large hills) of just over 12 miles.
:-)
That's what I did and perhaps you can learn from what I would have done differently. First off, I would have used NiMh batteries. This would have cut the weight in more than half and also would have allowed me to customize the pack more both in shape and capacity (I only needed to go 9 miles in a day). The only downside to this was the charge time. SLA batteries are pretty indestructible and I could charge the full 64Ah in around an hour. With NiMh, you're talking about several hours or less if you don't mind compromising lifespan (with the right charger you could charge the same capacity in NiMh in the same time if you didn't mind getting only ~100 charges out of your packs). If I had the cash, I would probably use the high capacity, high discharge Li-Ion batteries from PowerStream (http://www.powerstream.com/LL.htm) as they would be incredibly light (~10 pounds for the same capacity).
As far as the motors went, I was fairly satisfied with the power output, but would have liked more. If you compare it to a car (~100HP for ~2000 pounds), you should have ~10-15HP available for the same performance. Now with electric motors, due to their differing torque curves (in comparison to internal combustion engines), you can achieve similar results from significantly less overall horsepower, but I still would have preferred having 3-6HP on my project.
Of course, if you go with high output motors, you need a speed controller capable of handling the current. And if you go with the Li-Ion batts, you need a fairly expensive charger.
You can take a look at some basic pics of my scooter at:
http://sloviper.com/hobbies/scooter/index.html
A good place for parts is:
http://www.robotmarketplace.com/
Cheap Ni-Mh batteries can be found at:
http://www.batteryspace.com/
I have used them in BattleBots before and they hold up decently, almost as well as the "expensive" ones from http://www.battlepack.com/
If you have any specific questions, feel free to contact me. I love discussing this sort of thing and have had tons of experience.
I'm not exactly sure why they went to 1.0 either - although it has been much more stable than ever before (since 0.7). I guess they figured that it was good enough to "officially" release.
For those interested, here is the changelog from the sourceforge site:
version 1.0.0 (09/17/2004):
New Features:
* Drag-and-drop buddy support for the Invite dialog (Stu Tomlinson)
* Drag-and-drop buddy support for the Pounce dialog (Stu Tomlinson)
* View Chat log available from the interface (Daniel Atallah)
* Ability to receive offline messages in character encodings
other than ASCII (thanks to Nick Sukharev)
* File transfer status messages printed to conversation
windows (Dave West)
* Display file transfer messages when someone sends you a file
over AIM (Dave West)
* Handle MSN buddy lists more sanely (Felipe Contreras)
* Zephyr can use tzc to run from behind a firewall (Arun A Tharuvai)
Bug Fixes:
* Work around window manager stupidity with new dialog windows (Dave West)
* Compile with gtk 2.5.x (Gary Kramlich)
* Escape invalid characters in log names (Daniel Atallah)
* Fix for clicking add in an msn chat with 2 or more people in your buddy
list (Daniel Atallah)