This is true, but not the cap I'm thinking of. You are correct in that the consumer models are artificically capped at around 100mph, BUT there is also an altitude cap on all civvie units that prevents them working above some height (which I can't recall right now.)
I was working with some motorola GPS DSP chipsets/firmware a while back and there was some info on this stuff.
See, the majority of GPS chipsets and firmware (and off the shelf units) don't work so hot above certain altitudes and speeds. (as I recall anyway) Reason: Uncle Sam doesn't like people using GPS for ICBM guidance.
Now the RUSSIAN system (called GLONASS) would be a better bet. Only catch is that it isn't quite as accurate as GPS.
However if you are just trying to hit a county it would probably do just fine...
The FIRST sensible comment I have read so far in any/. article involving qt!! Congrats man! Of course maybe I'm just happy to see that someone else out there knows the "right way to do it".:-)
Go out and find (I would bet you could get some example off the net) an aviation sectional chart. You would be amazed at all of the areas marked off as restricted or off limit airspace. (Controlled airspace of all types, military training areas, missile ranges, etc.) Yes there are violations of these areas, and yes there probably would be some violations of uwave transmission beams... but not very many! Any violation would probably be by private pilots.
(Private pilots in general are pretty good at following the rules. In my exerience anyway. Mostly because the rules tend to make sense. However after spending some time with a few in Yuba county CA, I no longer believe that all of them even try to follow the rules. Or even get a license. Glad I don't live out there...)
Any incident with a IFR (read as: commercial traffic) aircraft running into a beam would be even more unlikely. Commercial pilots (the ones I've met anyway) are unbelievably paranoid about running into things. These are people who think of inter-aircraft clearance distances in terms of miles! They are very aware of where they are and where they are going. Soooo... in order to have a commercial flight wander into a beam you would probably have to have both a ground controller and the pilot mess up. And all of the computers involved on both sides get messed up too (or ignored). Not very likely.
The other worry you expressed about uwave interferance is not an issue. We would be talking about a direct beam here. The scatter would probably be quite small, and the restricted airspace around the beam would most likely be large enough to avoid that problem entirely.
So in conclusion to the aircraft issue... this is nothing new. Controlled access airspace has been around a long time.
As far as birds go... they are on their own...
I have a feeling that powersats would hurt far fewer birds than wind generators though.
I think it could be fun trying to design orbits to avoid running any other sattelite with a lower orbit through the beam though...
In any case it would be good to work all of this stuff out now, with solar power. This paves the way for moving nuke plants (and hopefully fusion plants someday) off the surface and into orbit.
I would be interested in seeing the pre 2.0 kernels stuck in there too... (not interested enough to dust my TOWER of old cds and start compiling though:-)
I heard from some people who were using 1.2.something in an embedded project that it's context switch times were quite a bit better than the latest.
Anyone out there know how the older kernels stack up?
Hey Taco, when we gonna get a slash port?
on
SQL Over FreeNet
·
· Score: 4
This would bet THE ideal thing to port slashdot to. Store the comments on freenet, and leave the metadata like mod points and such at a centrally controlled site. No more being forced to pull a comment due to lawyers babbling, and no more problems with old content that people still want going away, etc. etc.
Last I checked, fuel cells produced quite a bit of heat. (near boiling point of water as I recall... ?) I wonder how they are going to manage that in this type of an application.
Maybe. I have seen a lot of problems like this that look really simple on the surface (and make you ask "How the hell did they ship that??") that are actually much more complex.
Who says a reset is going to always drive the outputs of the system to a known state?
I mean, when you do an airborne reset a flight control system you wouldn't expect it to go and initialize all of it's interfaces to a known state, would you? (incedentally that's the kind of thing that tends to cause these type of problems...)
A reset drives the processors into a known state, but not necesarily the inter-subsystem interfaces.
Anyway, it's probably worthless to speculate further... it's just that that these things are almost always more complex than they seem. It annoys me a little that article descriptions says something like "Rather than resetting the computer, the software changed the pitch of the rotors". Makes it sound like the system never reset, just hard some code that said:
if Buttons.Reset = true then
Rotor_Pitch.Set(23.0);
end if;
and never reset at all. or something.
You have to remember that most modern aircraft are aerodynamically unstable. This is done to gain manuverability. They are not capable of flying without computer control. The pilot isn't really "flying" the aircraft anymore, he's just telling it where to go.
I think you may be missing a key issue here.
Everyone is assuming that this was an actual bug. (i.e. a requirement not implemented correctly, or a coding error, or even a design error.)
Don't forget to track back to the next level. It's very possible (and no, I don't KNOW, I'm just guessing...) that this could have been a requirements problem.
When the requirements were written for the control software, maybe nobody thought to specify what data should be output on that interface in this case. Therefore, there was no test case to cover it, and therefore the software got shipped out the door as "Bug Free" as the creators thouhgt possible.
Failure mode analysis on complex systems is HARD...
My experience with realtime embedded control systems has been that (with ada anyway) they don't usually die that way. In fact as I type this I'm trying to recall the last time the system I'm currently coding on went off in the weeds, and I can't. In this case, it most likely didn't go out of bounds either.
In my experience, most deeply embedded systems, like flight controls, rarely use pointers. They rarely use any "exotic" language features. They rarely (read as never) use anything that is allocated in a dynamic manner.
When things like this happen (reset problems) usually you end up with a situation where your box gets reset, and you output a default values on all of your interfaces, but these default values may not apply for all situations.
Rather than blaming the coders for these issues and calling them bugs, blame at the systems engineers for not covering the situation when they wrote the requirements. Not that it's easy to do this.
Failure mode analysis in a system as complex as the V-22 is a job I would not want...
The belly in on the YF-22 (NOTE the 'Y'.. That was a demval aircraft NOT a real F-22) was due to pilot error!!
The FLCS people KNEW there was a problem in the software. (Actually it was a problem with the control laws, not the implementation of the software, hence not a bug.) There was an Aircraft Operational Limitation that specified "Thou shalt not go into afterburner with thrust vectoring enabled."
The test pilot did it anyway on takeoff (probably an accident, pushed throttle forward too far). The system went into oscillation, and the pilot went in belly first for safety reasons.
Ugly (but not unexpected) failure mode ...
on
Seven League Boots
·
· Score: 1
From http://www.powerskip.de/function.html :
First, there is a risk of breakage of the spring of about 5% after 100 hours use. This percentage rises when the equipment is used longer. This data result from an evaluation of the current sold PowerSkips and can change with higher experience. In consequence, it has to be stated that the spring is a life limited part. With the current technology it is not possible to design and manufacture this part for a guaranteed durable use. Exchange-Parts can be orderd.
This kind of failure could be really really hard on your knees. Imagine comming down from 2 meters or so and having only one spring fail. Ouch. Then imagine have both fail. I'm not sure which would be more painful (and/or knee wrenching).
Failure probability of 0.05 after 100 hours is really quite high.
Need some kind of Hobbs meter to log the number of hours and just replace your springs every 90 or so no matter what.:-)
Mach=another layer before the hardware.. so if something heads south in the kernal (as you know it) it would mean that it's father (to speak) would just restart it.. or at least fail gracfully. OS's that use a mach design would be..
The WHOLE POINT of a microkernel based architechure is to have this layer. It's another thing that can break, yes, BUT unlike the rest of the 'kernel' it is small, and it has very very limited goals in life. (things like schedule tasks, map memory, provide some ipc primitives, etc....) Small means debugable. Small means TESTABLE. Like formal qualification tests. Regression test suites. You can beat the hell out of a microkernel. Then you have known stable base to build your OS services from.
Look at QNX as a real example. (not to say it's perfect, however, it works quite well. You can pull hardware drivers in and out on the fly.)
If you set up some kind of "web of trust" type thing (ala PGP/GPG) you could do this. If the ID was mandated, you just cut a huge portion of freedom from everyone on the network.
If you aren't familiar with the concept, read this.
This is a classic case of the trade-off between freedom and responsibility. You can have a "free" global data network where anyone can transmit anything to anybody else, OR you can have a global data network where geographically limited governments try to prevent certain types of data from being transmitted. There is no middle ground here. You can't ask for both at the same time.
The only real solution to the spam problem is via network user agreements and technology.
I hate to respond to this so late in the thread, since it's likely that no one will ever read this... however I think all of the posts I have read so far have missed a point here.
The cancelation of the X-33 and X-34 doesn't mean the projects were a failure! The amount of data and experience gained on these two project is very large. Hard to measure even.
Remember these are X planes. They are experimental. The goal in these programs is not necesarily to produce a production ready space/aircraft (that's what the next phase called EMD is for.) These were essentially research programs. People throught that the technology and processes to develop this type of spaceplane (in the X-33s case) existed and were solid, but they were not entirely correct. If you recall they had gotten to the point where the original fuel tank design had to be scrapped, they were now carryin fuel in what was originally the cargo space and hauling payloads in external pods, etc. It was turning into a kludge. (IMHO anyway.)
Canceling this program now is good because it means that someone higher up in the management food chain recognizes that continuing at this point would cost more than starting over. They realize that some of their base assumptions for the project are wrong, and think that now they know enough to rethink it and do it right. This must have been a hard decision to make, but I think it was the right one.
In summary, don't think of this as the end of the effort to produce this type of spacecraft, just a slight dip in the slope of the learning curve. (Errr... or so I hope.:-)
Sigh. Must now return to doing "real" work. The horror.
The atari (as I recall) is powered by an 8088. The memory management/bank swapping model used on the 1750A makes intel's segment-offset look like a WONDERFUL DREAM.
As you fill up your ROM on the 1750 (I'm assuming that your ARE running in expanded mode, with mode that 64k words of ROM) like past 70% or so, cramming all of your code in get HARD. It's not quite as bad as some of the other bank swap memory setups out there, but by modern standards it's an evil way to address 1 megaword of ROM.
sorry, thus endith my rant...:-) It's been a long day fighting that damn chip!
The write it then erase it thing IS a pain in the arse. But it's the same in a live class... only you can interrupt at that point. Some of the best distance classes I have been in have distributed all of the course notes in powerpoint. You can then print the notes ahead of the actual lecture and scribble right on then as the prof is talking. Works great.
Slashdot Mirror
If you don't issue any warning and come down on anybody who "infringes" like a ton of bricks, the number of repeat offenders is likely to be low.
I don't necessarily AGREE that this is anykind of infringement, but I can see how that might be their strategy.
Hah! I learn something new every day in spite of my best efforts ...
That's truly funny!
This is true, but not the cap I'm thinking of. You are correct in that the consumer models are artificically capped at around 100mph, BUT there is also an altitude cap on all civvie units that prevents them working above some height (which I can't recall right now.)
I was working with some motorola GPS DSP chipsets/firmware a while back and there was some info on this stuff.
See, the majority of GPS chipsets and firmware (and off the shelf units) don't work so hot above certain altitudes and speeds. (as I recall anyway) Reason: Uncle Sam doesn't like people using GPS for ICBM guidance.
Now the RUSSIAN system (called GLONASS) would be a better bet. Only catch is that it isn't quite as accurate as GPS.
However if you are just trying to hit a county it would probably do just fine...
The FIRST sensible comment I have read so far in any /. article involving qt!! Congrats man! Of course maybe I'm just happy to see that someone else out there knows the "right way to do it". :-)
The aircraft thing isn't actually a big deal.
... but not very many! Any violation would probably be by private pilots.
...)
... in order to have a commercial flight wander into a beam you would probably have to have both a ground controller and the pilot mess up. And all of the computers involved on both sides get messed up too (or ignored). Not very likely.
... this is nothing new. Controlled access airspace has been around a long time.
... they are on their own ...
...
....
Go out and find (I would bet you could get some example off the net) an aviation sectional chart. You would be amazed at all of the areas marked off as restricted or off limit airspace. (Controlled airspace of all types, military training areas, missile ranges, etc.) Yes there are violations of these areas, and yes there probably would be some violations of uwave transmission beams
(Private pilots in general are pretty good at following the rules. In my exerience anyway. Mostly because the rules tend to make sense. However after spending some time with a few in Yuba county CA, I no longer believe that all of them even try to follow the rules. Or even get a license. Glad I don't live out there
Any incident with a IFR (read as: commercial traffic) aircraft running into a beam would be even more unlikely. Commercial pilots (the ones I've met anyway) are unbelievably paranoid about running into things. These are people who think of inter-aircraft clearance distances in terms of miles! They are very aware of where they are and where they are going. Soooo
The other worry you expressed about uwave interferance is not an issue. We would be talking about a direct beam here. The scatter would probably be quite small, and the restricted airspace around the beam would most likely be large enough to avoid that problem entirely.
So in conclusion to the aircraft issue
As far as birds go
I have a feeling that powersats would hurt far fewer birds than wind generators though.
I think it could be fun trying to design orbits to avoid running any other sattelite with a lower orbit through the beam though
In any case it would be good to work all of this stuff out now, with solar power. This paves the way for moving nuke plants (and hopefully fusion plants someday) off the surface and into orbit.
wow, this is getting quite long
OUT
Or the pilot pulls a 9g turn and has to tense muscles to stop from blacking out. The software would have to be pretty damn smart.
I would be interested in seeing the pre 2.0 kernels stuck in there too ... (not interested enough to dust my TOWER of old cds and start compiling though :-)
I heard from some people who were using 1.2.something in an embedded project that it's context switch times were quite a bit better than the latest.
Anyone out there know how the older kernels stack up?
This would bet THE ideal thing to port slashdot to. Store the comments on freenet, and leave the metadata like mod points and such at a centrally controlled site. No more being forced to pull a comment due to lawyers babbling, and no more problems with old content that people still want going away, etc. etc.
a thought anyway.
Last I checked, fuel cells produced quite a bit of heat. (near boiling point of water as I recall ... ?) I wonder how they are going to manage that in this type of an application.
Maybe. I have seen a lot of problems like this that look really simple on the surface (and make you ask "How the hell did they ship that??") that are actually much more complex.
...)
... it's just that that these things are almost always more complex than they seem. It annoys me a little that article descriptions says something like "Rather than resetting the computer, the software changed the pitch of the rotors". Makes it sound like the system never reset, just hard some code that said:
Who says a reset is going to always drive the outputs of the system to a known state?
I mean, when you do an airborne reset a flight control system you wouldn't expect it to go and initialize all of it's interfaces to a known state, would you? (incedentally that's the kind of thing that tends to cause these type of problems
A reset drives the processors into a known state, but not necesarily the inter-subsystem interfaces.
Anyway, it's probably worthless to speculate further
if Buttons.Reset = true then
Rotor_Pitch.Set(23.0);
end if;
and never reset at all. or something.
You have to remember that most modern aircraft are aerodynamically unstable. This is done to gain manuverability. They are not capable of flying without computer control. The pilot isn't really "flying" the aircraft anymore, he's just telling it where to go.
I think you may be missing a key issue here.
...) that this could have been a requirements problem.
...
Everyone is assuming that this was an actual bug. (i.e. a requirement not implemented correctly, or a coding error, or even a design error.)
Don't forget to track back to the next level. It's very possible (and no, I don't KNOW, I'm just guessing
When the requirements were written for the control software, maybe nobody thought to specify what data should be output on that interface in this case. Therefore, there was no test case to cover it, and therefore the software got shipped out the door as "Bug Free" as the creators thouhgt possible.
Failure mode analysis on complex systems is HARD
My experience with realtime embedded control systems has been that (with ada anyway) they don't usually die that way. In fact as I type this I'm trying to recall the last time the system I'm currently coding on went off in the weeds, and I can't. In this case, it most likely didn't go out of bounds either.
...
In my experience, most deeply embedded systems, like flight controls, rarely use pointers. They rarely use any "exotic" language features. They rarely (read as never) use anything that is allocated in a dynamic manner.
When things like this happen (reset problems) usually you end up with a situation where your box gets reset, and you output a default values on all of your interfaces, but these default values may not apply for all situations.
Rather than blaming the coders for these issues and calling them bugs, blame at the systems engineers for not covering the situation when they wrote the requirements. Not that it's easy to do this.
Failure mode analysis in a system as complex as the V-22 is a job I would not want
The belly in on the YF-22 (NOTE the 'Y' .. That was a demval aircraft NOT a real F-22) was due to pilot error!!
The FLCS people KNEW there was a problem in the software. (Actually it was a problem with the control laws, not the implementation of the software, hence not a bug.) There was an Aircraft Operational Limitation that specified "Thou shalt not go into afterburner with thrust vectoring enabled."
The test pilot did it anyway on takeoff (probably an accident, pushed throttle forward too far). The system went into oscillation, and the pilot went in belly first for safety reasons.
Anyway, thus endeth my rant.
I have had really good luck with CiteSeer.
YMMV.
http://citeseer.nj.nec.com/
From http://www.powerskip.de/function.html :
First, there is a risk of breakage of the spring of about 5% after 100 hours use. This percentage rises when the equipment is used longer. This data result from an evaluation of the current sold PowerSkips and can change with higher experience. In consequence, it has to be stated that the spring is a life limited part. With the current technology it is not possible to design and manufacture this part for a guaranteed durable use. Exchange-Parts can be orderd.
This kind of failure could be really really hard on your knees. Imagine comming down from 2 meters or so and having only one spring fail. Ouch. Then imagine have both fail. I'm not sure which would be more painful (and/or knee wrenching).
Failure probability of 0.05 after 100 hours is really quite high.
Need some kind of Hobbs meter to log the number of hours and just replace your springs every 90 or so no matter what. :-)
The WHOLE POINT of a microkernel based architechure is to have this layer. It's another thing that can break, yes, BUT unlike the rest of the 'kernel' it is small, and it has very very limited goals in life. (things like schedule tasks, map memory, provide some ipc primitives, etc....) Small means debugable. Small means TESTABLE. Like formal qualification tests. Regression test suites. You can beat the hell out of a microkernel. Then you have known stable base to build your OS services from.
Look at QNX as a real example. (not to say it's perfect, however, it works quite well. You can pull hardware drivers in and out on the fly.)
Enough of this. I need to do some work here
If you aren't familiar with the concept, read this.
The only real solution to the spam problem is via network user agreements and technology.
So what we need, then, is a slashdot like frontend for freenet?
I hate to respond to this so late in the thread, since it's likely that no one will ever read this ... however I think all of the posts I have read so far have missed a point here.
... or so I hope. :-)
The cancelation of the X-33 and X-34 doesn't mean the projects were a failure! The amount of data and experience gained on these two project is very large. Hard to measure even.
Remember these are X planes. They are experimental. The goal in these programs is not necesarily to produce a production ready space/aircraft (that's what the next phase called EMD is for.) These were essentially research programs. People throught that the technology and processes to develop this type of spaceplane (in the X-33s case) existed and were solid, but they were not entirely correct. If you recall they had gotten to the point where the original fuel tank design had to be scrapped, they were now carryin fuel in what was originally the cargo space and hauling payloads in external pods, etc. It was turning into a kludge. (IMHO anyway.)
Canceling this program now is good because it means that someone higher up in the management food chain recognizes that continuing at this point would cost more than starting over. They realize that some of their base assumptions for the project are wrong, and think that now they know enough to rethink it and do it right. This must have been a hard decision to make, but I think it was the right one.
In summary, don't think of this as the end of the effort to produce this type of spacecraft, just a slight dip in the slope of the learning curve. (Errr
Sigh. Must now return to doing "real" work. The horror.
As you fill up your ROM on the 1750 (I'm assuming that your ARE running in expanded mode, with mode that 64k words of ROM) like past 70% or so, cramming all of your code in get HARD. It's not quite as bad as some of the other bank swap memory setups out there, but by modern standards it's an evil way to address 1 megaword of ROM.
sorry, thus endith my rant ... :-) It's been a long day fighting that damn chip!
And just where would you keep em ... ? Not a bad book.
dv