I'm not aware of any type of motor that simply locks up when no power is applied. However, there are multiple scenarios which could cause the wheel to lock, or at least to become so difficult to turn that it drags rather than freewheels.
1. Bearing failure. Considering the atmosphere on Mars, cold and dusty, this is a distinct possibility. However, if this were the case, the motor should be drawing a lot of current, and the motor is reported to be drawing none. Perhaps there's a failsafe circuit that shuts the motor off if it draws excess current, though.
2. Gears. If the motor is geared down by a significant amount before driving the wheel, it would require more force to turn the wheel manually. If there was a worm gear in the drive train, it would not be possible to turn the wheel manually, since worm gears only work one way.
3. Short circuit. If you short-circuit the terminals of most motors, they become more difficult to turn by hand. The reason for this is that in this situation, the motor is effectively a generator attempting to provide power into a short circuit. A short circuit can sink a lot of energy, and generators are more difficult to turn the more energy they are asked to supply. Again this would mean that the motor should be drawing a great deal of current, but there may be a failsafe circuit which shuts it off.
4. Internal Jam. Certain types of permanent magnet motors have the armature surrounded by a relatively brittle permanent magnet stator. Mechanical shocks to the motor can cause pieces of the stator to break off and become wedged between the stator and the rotor, causing the motor to jam. This is most common in cheap motors that are used in toys and cassette recorders. I should hope that the rovers use something of higher quality!
OK, I'll keep that in mind. If I should want to lock a recording in a safe for 500 years, I'll use an LP. On the other hand, if I actually want to listen to it here and now, I'll go for the CD.:D
I noticed the chart ends at the "Plateau of Productivity" but that isn't where all technology ends. Just look at things such as phonographs (you can barely find them anymore).
Quite correct. The last stage is generally obsolescence, and in this stage the mention of the technology imparts an air of quaintness.
It's funny you should mention phonographs, though, because it illustrates another phase, after obsolescence, that some technologies go through. I call it the 'retro-elitist revival'. In this stage, the technology gets a small but vocal contingent of proponents who loudly proclaim that the obsolete technology is superior to the newer technology which replaced it.
At this stage, the old technology is not available anymore, so a niche industry springs up to supply this newfound demand -- at exorbitant prices. Since few can afford or justify these prices, you now have an exclusive group that exists seemingly outside of reality, smugly assured of its own superiority, regardless of what objective tests may reveal.
Vinyl records, and the contraptions used to play them, have achieved this status in recent years. A similar retro-elitist revival happened to vacuum tube audio equipment in the late 70's/early 80's and continues to this day.
Of course. There's simply no right or wrong way to do these things. If you end up with a working project at the end, or even if you don't, if you've learned a thing or two, and had some fun doing it, that's what counts more than anything else.
However, I find that it's easier to remove components from circuit boards by taking a heat gun (ie. the kind you use for removing paint) and using it to melt the solder. Yes, on high heat, most heat guns get hot enough to melt solder. Just direct the gun at the back of the circuit board while gently prying or tapping at the component you're trying to remove from the front.
Just be sure to do this in a _very_ well ventilated area (ie. outside) because if you leave the heat gun in one place too long, which you probably will sooner or later, you'll burn the board, which produces some of the most evil smelling smoke you've ever had the misfortune of smelling.
Also, I find that dead motherboards aren't particularly fertile grounds for component salvaging. Once, I got a whole skid full of old scientific instruments at a government surplus auction for $10. The load of components I salvaged from this was quite unreal!
Pinfo is a godsend for people who just can't get the hang of the GNU info viewer. I concur that GNU info has one of the worst user interfaces ever conceived. Pinfo uses Lynx-like navigation and is a snap to get the hang of.
As for reinventing the wheel, Info has been around at least as long as HTML, and possibly longer. (The first entry in the TeXinfo changelog dates back to 1988). Info is also a lot more conducive to producing printed copies of the documentation than HTML is.
As most of us all ready know NOTHING IS FREE! Ok go ahead and say Open Source is free, no it is not. I know that my time is worth a lot more that $.00/h.
As opposed to closed source software, which is only free if neither your time nor your money has value.
"Real Time" simply means that the system will respond within a specified time. It does not necessarily mean that the kernel can be pre-empted, nor does the fact that the kernel can be pre-empted necessarily mean that an operating system is realtime.
No, a square wave is a square wave is a square wave. Sine waves operate on entirely different principles. A true sine wave is the result of a trigeometry identity - sine. They are not an "infinite number of sine waves" rolled into one. All you've done here is a nice graphing trick - just like a good way of representing pi is 22/7.
Try this: Take a 22kHz square wave, and run it through a low-pass filter with a cutoff frequency that's slightly higher -- say, 25kHz. Look at the output on an oscilloscope.
What will you see?
You'll see a somewhat distorted sine wave, that's what you'll see.
If a square wave is in fact made up of a bunch of sine waves, it is easy to explain why this happens. The filter has allowed the fundamental frequency to pass, and has attenuated the higher harmonics. The distortion results from the fact that the filter is not perfect, and will allow some of the first few harmonics to pass.
On the other hand, if indeed a squarewave is something entirely different, how do you explain this result?
In other words, you have just denied a theorem which underlies much of modern signal processing and communications. You better have damn good proof of your position!
You are confusing bits/second with sampling rate. To capture and reproduce a sine wave, you need only sample at double the highest frequency. ie, to capture 22khz or lower, you sample at 44khz. This is the Nyquist Criteria, which I believe may have been mentioned earlier in this thread. The formula is somewhat complex to write out here, so please visit these guys for the formula
No, he's right. If you want to get a reasonably accurate digital representation of a squarewave, you need to sample at a higher rate. Why? In order to capture the higher harmonics present in a squarewave, that's why. If you sample at a high enough rate, you will capture several higher harmonics, which will combine in order to approximate a square wave.
Oh, but you don't seem to accept Fourier's theorem. Well, never mind then.
You seem to be falling victim to the Mozilla Memory Escalation Misunderstanding. That is, under Linux, when a program has multiple threads, you _do not_ add up the memory usage of all the threads to get the total memory usage! The total memory usage is simply the memory usage of _one_ of the threads.
Granted, some graphical process meters complicate things by automatically adding up all of the threads. Try using the textmode top to see what it is really using.
Actually, there has been systematic discrimination against ghosts in computer games since the early days. The ghosts were none too happy about being cast as the villians in Pac-man, for example.
But things are starting to look up. Programs specifically targetted at ghosts are starting to appear -- first came Ghostscript, and now there's Ethereal.
1. If my bank had some of its embedded systems accessible from the internet, I'd be looking for a new bank. And a cracker would have a lot more difficulty breaking into such a system if he couldn't get at it from the internet.
Don't forget that most "Linux" security issues are not with the kernel itself, but with other programs which run on it. There would be no reason for these programs to be running on an embedded system. If they are, that's bad design, and it's not the fault of the operating system. You can make any OS insecure if you try.
Not to mention that the number of situations where military/bank grade security is important is going to be relatively small.
2. Chances are that PCI is used because of an industry standard called PC/104 -- basically a PCI bus with a different connector used in embedded systems. Using a different bus would prevent the design from leveraging the existing PC/104 peripherals. It's ironic that you mentioned MCA -- IBM has apparently learned it's lesson there.
3. WinCE? Stop it, you're killing me.:P
QNX? Well, yes, it has advantages over Linux in some situations, most notably where hard realtime constraints are required. But that isn't the case in most circumstances. Considering that the price of QNX could best be described as "obscene", you aren't going to use it unless you absolutely need it.
Even then, there are other alternatives available for HRT programming, like RTLinux and eCos.
Well, it was once thought that the Leakeys merely discovered the origins of life in Africa. But, the shocking truth is that they were the cause of it! There was an accident with a contraceptive and a time machine, you see...
IIRC, ECL logic has problems with high power consumption. So it's not at all clear that ECL is an improvement rather than a differing tradeoff.
It's interesting to note, though, that CMOS had almost exactly the opposite problem when it first came out -- it was slow, but had extremely low power consumption. It also was dreadfully static-sensitive. But, CMOS itself managed to displace the older NMOS technology in the early 80's, so these things can happen.
Slashdot Mirror
I'm not aware of any type of motor that simply locks up when no power is applied. However, there are multiple scenarios which could cause the wheel to lock, or at least to become so difficult to turn that it drags rather than freewheels.
1. Bearing failure. Considering the atmosphere on Mars, cold and dusty, this is a distinct possibility. However, if this were the case, the motor should be drawing a lot of current, and the motor is reported to be drawing none. Perhaps there's a failsafe circuit that shuts the motor off if it draws excess current, though.
2. Gears. If the motor is geared down by a significant amount before driving the wheel, it would require more force to turn the wheel manually. If there was a worm gear in the drive train, it would not be possible to turn the wheel manually, since worm gears only work one way.
3. Short circuit. If you short-circuit the terminals of most motors, they become more difficult to turn by hand. The reason for this is that in this situation, the motor is effectively a generator attempting to provide power into a short circuit. A short circuit can sink a lot of energy, and generators are more difficult to turn the more energy they are asked to supply. Again this would mean that the motor should be drawing a great deal of current, but there may be a failsafe circuit which shuts it off.
4. Internal Jam. Certain types of permanent magnet motors have the armature surrounded by a relatively brittle permanent magnet stator. Mechanical shocks to the motor can cause pieces of the stator to break off and become wedged between the stator and the rotor, causing the motor to jam. This is most common in cheap motors that are used in toys and cassette recorders. I should hope that the rovers use something of higher quality!
Is English VSO when you're asking a question? Yes, I do believe that it is.
On an unrelated note, I wonder if Soviet Russian was an OVS language...
I wonder how well those LCD credit cards would survive being put through one of those old "chunk-chunk" credit card machines?
Granted, I haven't seen one in years, but I'm sure there are still a few kicking around out in the sticks somewhere.
From TFA:
The picoPSU-120 is currently available for $49.99.
I suppose if you lived in a country where the unit of currency was worth approximately $0.25 US...
You realize that Einstein's formative years were long before WW1, right?
OK, I'll keep that in mind. If I should want to lock a recording in a safe for 500 years, I'll use an LP. On the other hand, if I actually want to listen to it here and now, I'll go for the CD. :D
I noticed the chart ends at the "Plateau of Productivity" but that isn't where all technology ends. Just look at things such as phonographs (you can barely find them anymore).
Quite correct. The last stage is generally obsolescence, and in this stage the mention of the technology imparts an air of quaintness.
It's funny you should mention phonographs, though, because it illustrates another phase, after obsolescence, that some technologies go through. I call it the 'retro-elitist revival'. In this stage, the technology gets a small but vocal contingent of proponents who loudly proclaim that the obsolete technology is superior to the newer technology which replaced it.
At this stage, the old technology is not available anymore, so a niche industry springs up to supply this newfound demand -- at exorbitant prices. Since few can afford or justify these prices, you now have an exclusive group that exists seemingly outside of reality, smugly assured of its own superiority, regardless of what objective tests may reveal.
Vinyl records, and the contraptions used to play them, have achieved this status in recent years. A similar retro-elitist revival happened to vacuum tube audio equipment in the late 70's/early 80's and continues to this day.
Of course. There's simply no right or wrong way to do these things. If you end up with a working project at the end, or even if you don't, if you've learned a thing or two, and had some fun doing it, that's what counts more than anything else.
However, I find that it's easier to remove components from circuit boards by taking a heat gun (ie. the kind you use for removing paint) and using it to melt the solder. Yes, on high heat, most heat guns get hot enough to melt solder. Just direct the gun at the back of the circuit board while gently prying or tapping at the component you're trying to remove from the front.
Just be sure to do this in a _very_ well ventilated area (ie. outside) because if you leave the heat gun in one place too long, which you probably will sooner or later, you'll burn the board, which produces some of the most evil smelling smoke you've ever had the misfortune of smelling.
Also, I find that dead motherboards aren't particularly fertile grounds for component salvaging. Once, I got a whole skid full of old scientific instruments at a government surplus auction for $10. The load of components I salvaged from this was quite unreal!
Pinfo is a godsend for people who just can't get the hang of the GNU info viewer. I concur that GNU info has one of the worst user interfaces ever conceived. Pinfo uses Lynx-like navigation and is a snap to get the hang of.
As for reinventing the wheel, Info has been around at least as long as HTML, and possibly longer. (The first entry in the TeXinfo changelog dates back to 1988). Info is also a lot more conducive to producing printed copies of the documentation than HTML is.
As most of us all ready know NOTHING IS FREE! Ok go ahead and say Open Source is free, no it is not. I know that my time is worth a lot more that $.00/h.
As opposed to closed source software, which is only free if neither your time nor your money has value.
"Real Time" simply means that the system will respond within a specified time. It does not necessarily mean that the kernel can be pre-empted, nor does the fact that the kernel can be pre-empted necessarily mean that an operating system is realtime.
No, a square wave is a square wave is a square wave. Sine waves operate on entirely different principles. A true sine wave is the result of a trigeometry identity - sine. They are not an "infinite number of sine waves" rolled into one. All you've done here is a nice graphing trick - just like a good way of representing pi is 22/7.
Try this: Take a 22kHz square wave, and run it through a low-pass filter with a cutoff frequency that's slightly higher -- say, 25kHz. Look at the output on an oscilloscope.
What will you see?
You'll see a somewhat distorted sine wave, that's what you'll see.
If a square wave is in fact made up of a bunch of sine waves, it is easy to explain why this happens. The filter has allowed the fundamental frequency to pass, and has attenuated the higher harmonics. The distortion results from the fact that the filter is not perfect, and will allow some of the first few harmonics to pass.
On the other hand, if indeed a squarewave is something entirely different, how do you explain this result?
In other words, you have just denied a theorem which underlies much of modern signal processing and communications. You better have damn good proof of your position!
You are confusing bits/second with sampling rate. To capture and reproduce a sine wave, you need only sample at double the highest frequency. ie, to capture 22khz or lower, you sample at 44khz. This is the Nyquist Criteria, which I believe may have been mentioned earlier in this thread. The formula is somewhat complex to write out here, so please visit these guys for the formula
No, he's right. If you want to get a reasonably accurate digital representation of a squarewave, you need to sample at a higher rate. Why? In order to capture the higher harmonics present in a squarewave, that's why. If you sample at a high enough rate, you will capture several higher harmonics, which will combine in order to approximate a square wave.
Oh, but you don't seem to accept Fourier's theorem. Well, never mind then.
No. XMMS doesn't use 37 meg.
You seem to be falling victim to the Mozilla Memory Escalation Misunderstanding. That is, under Linux, when a program has multiple threads, you _do not_ add up the memory usage of all the threads to get the total memory usage! The total memory usage is simply the memory usage of _one_ of the threads.
Granted, some graphical process meters complicate things by automatically adding up all of the threads. Try using the textmode top to see what it is really using.
Just imagine everyone else in their underwear.
:)
Tried that once. Problem was, there was a bunch of hot chicks in the first few rows. Ended up giving myself a woody.
Mind you, that might not be such a big problem for the type of crowd Taco is likely to attract.
* Stability
Needs work, I will say.
* Bookmarks manager
Mozilla has one.
* Working preferences dialog
Works for me, even if it's one of the slowest parts of the UI.
...Now try running the textmode top. Press shift-M.
What you'll see is 6 separate threads each with a memory usage of 25-30meg.
Here's the important part: Each of those threads is using the _same_ 25-30meg chunk of memory. gtop adds them up, and it shouldn't.
Still, I would have to say that 25-30meg is still too big, but it is much more reasonable, and mozilla is, after all, still prerelease software.
Well, you learn something new every day.
Actually, there has been systematic discrimination against ghosts in computer games since the early days. The ghosts were none too happy about being cast as the villians in Pac-man, for example.
But things are starting to look up. Programs specifically targetted at ghosts are starting to appear -- first came Ghostscript, and now there's Ethereal.
Flexibility.
Maybe you think that it's a bad thing that a browser should have such flexibility.
However, it gives me a woody.
1. If my bank had some of its embedded systems accessible from the internet, I'd be looking for a new bank. And a cracker would have a lot more difficulty breaking into such a system if he couldn't get at it from the internet.
:P
Don't forget that most "Linux" security issues are not with the kernel itself, but with other programs which run on it. There would be no reason for these programs to be running on an embedded system. If they are, that's bad design, and it's not the fault of the operating system. You can make any OS insecure if you try.
Not to mention that the number of situations where military/bank grade security is important is going to be relatively small.
2. Chances are that PCI is used because of an industry standard called PC/104 -- basically a PCI bus with a different connector used in embedded systems. Using a different bus would prevent the design from leveraging the existing PC/104 peripherals. It's ironic that you mentioned MCA -- IBM has apparently learned it's lesson there.
3. WinCE? Stop it, you're killing me.
QNX? Well, yes, it has advantages over Linux in some situations, most notably where hard realtime constraints are required. But that isn't the case in most circumstances. Considering that the price of QNX could best be described as "obscene", you aren't going to use it unless you absolutely need it.
Even then, there are other alternatives available for HRT programming, like RTLinux and eCos.
So in short, I think you're wrong.
Not particularly useful for those who don't use x86 processors, though.
Well, it was once thought that the Leakeys merely discovered the origins of life in Africa. But, the shocking truth is that they were the cause of it! There was an accident with a contraceptive and a time machine, you see...
Leakies indeed...
I suspect they were being facetious. One dimentional Tetris, while possible, wouldn't be much of a game. :)
IIRC, ECL logic has problems with high power consumption. So it's not at all clear that ECL is an improvement rather than a differing tradeoff.
It's interesting to note, though, that CMOS had almost exactly the opposite problem when it first came out -- it was slow, but had extremely low power consumption. It also was dreadfully static-sensitive. But, CMOS itself managed to displace the older NMOS technology in the early 80's, so these things can happen.
This might be a good time to mention LeoCAD, a similar program which has a Linux version.