Yeah, but the fun is making the microstrip and cavity filters. Nothing quite beats the fun of building your own spectrum analyser. Not to mention the challenge of building a stable multi octave VCO on your own.
Did some political science major come up with this or something? This is nothing new.
It's been a well known weakness of any defence system. The moment you run out of bullets/interceptor missiles/... you're done for. Another tactic is simply overloading it with targets. You can only fire interceptors at a certain rate. If you exceed that rate for long enough you'll get through. Again not a very complicated tactic that's fairly easy to execute given sufficient time to build a large quantity of dumb missiles.
No, you look at Perl in the wrong way! The camel is good at what it's designed for. It won't do it neatly but it'll get the job done. Need to hack two incompatible systems together quickly? Perl is there for you. Need low level access from a scripting language? Perl fills the gap. And in terms of performance the old camel still gives a lot of new "optimized" languages a run for their money. It's also one of the most flexible languages out there. Name a few other scripting languages that are used on such a wide range of systems? You'll encounter Perl on the small embedded systems and on large clusters. It simply adapts to the task at hand. It's sort of like Fortran and Ada in that, many people are against it but those who are familiar with it know what it's capable off aren't going to drop it cause it looks ugly to the younger programmers.
In case you're wondering Fortran is the best data crunching language out there and Ada is in a league of its own when it comes to reliability. Idealism doesn't have a place in engineering, you use the right tool for the job and stop whining about how easy it is to use or master.
I disagree. Don't neglect the 8 bit goodness. An army of 8 bit microcontrollers working together can do some pretty funny things. Nothing quite beats the old fashioned 8051 in being well documented either. And it comes in loads of flavours. I'll agree on the stay away from Arduino, just too expensive for what you get. The TI dev boards are fun, very easy to use as well. The software is a bit iffy but not too bad. Never worked with Propellers so can't really say much about those.
Another interesting option is getting one of those NXP ARM dev boards. Or even better, get a large FPGA dev board and use a soft core. Side bonus is if you need heavy data crunching you can synthesize dedicated hardware for it. Most of the common simple microcontrollers have FOSS models available. Then when you wish to build something final you can just switch to the actual MCU.
Many of these printers also have some built in speaker to play stupid sounds and warnings. Imagine the fun you could have if you somehow managed to upload the voice of HAL saying "I'm afraid I can't let you do that Dave!". Bonus points if you make it say that when the printer runs out of paper.
Yeah, 18 months is pretty young for a phone. My last smartphone lasted over 2 years and if I don't do anything insane on it it'll still do an entire day on the original battery. That's HTC quality for ya!
I never had trouble opening the phone to replace a battery. Practice makes perfect!
And the batteries I can actually keep in my vest, backpack,... . No need to make my phone itself bulky!
The suggestion to use a power case has very much to do with phone cases. I bought my current phone cause it's very slim and doesn't come with a huge screen. As a nice side bonus you can replace the battery!
I disagree, replacing a battery in a tablet: soldering 3 wires at most and some screws.
Hacking a typewriter to act as printer: Figure out the internal workings, make a controller for it, make serial interface logic.
My latest "hack" was hooking up a network analyser to a tablet so I could control it while I was near the actual setup. Though I use quotes cause it's not exactly difficult to hook up a run off the mill Bluetooth PHY, a microcontroller and GPIB interface. All without using a single Arduino or RaspberryPi! Then again, considering what I see these days as hacks I wonder what the world has come to...
No, the added "convenience" you see is what I see as a limitation. I can have as many extra batteries as necessary while I don't need to fiddle with cases.
Heh, I sometimes do use a rowing machine or treadmill when the weather outside is horrible. Like with the ice right now I wouldn't make it 1 km outside without breaking a leg. So what did I do? Put the treadmill in front of the TV, hook up laptop, and watch a movie. Can't really contemplate the universe in your own living room when your cat is trying to attack the treadmill you're on. At least I've found it difficult.
Then again, when I do go running alone I do listen to music, but that's mainly to keep a rhythm for interval training. Otherwise I found this great entertainment form called asking a friend if she feels like going along! Though I guess we're too old fashioned.
Cause I don't like encasing my phone. Just use a screen protector to ensure your keys don't destroy the screen if they accidentally end up in the same pocket. No reason to spend another 50 euro on a damned case if you can buy 5 batteries for that price!
Ah yes, but satellite is quite different from WiFi in so many ways. Satellites use very directional spot beams in a frequency band that's not used for anything else. Combined with the fact that the spectrum allocated for satellites is very strictly regulated compared to the ISM band. A second factor is that the 2.4 GHz and 5 GHz bands are very crowded compared to that. Atmospheric interference isn't that much of a problem with WiFi obviously (especially with the lower frequencies). But the interference from other devices is. Another problem one can't forget is the that the up-link and down-link use different frequency bands that are quite a distance away from each other. So no cross-interference from the transmitter to the receiver like you have when you work in the 2.4 GHz band. And a few other differences. It's not cause you manage to use a certain type of modulation for a certain wireless application that it can be used for all the others. Modulation makes or breaks most wireless protocols. Hence why I fear they might have been a bit overly ambitious with this one.
Well, that depends on how smart the MIMO algorithm is I'd say. I've seen a few very efficient implementations that do seem to be able to select fairly good paths. I'm more worried about the necessary SNR.
Yes, but 256-QAM is very noise sensitive. Works fine on a coax cable, works fine on short copper lines. But wireless is a different story. Especially considering how crowded the 2.4 GHz band is these days. I'm not saying it's impossible, I just wonder how cost efficient these devices will be considering the SNR you'll have to achieve to keep the error rate down. At some point it might not be worth it.
I usually get 3-4 MB/s, have had more than a few peaks of 5 MB/s. Which isn't all that weird considering 54 Mbps. And that's through laminate, not exactly the best material for WiFi. Important side note is that I live in the middle of nowhere and the 2.4 GHz band is almost empty except for my neighbours routers which aren't too close either. If you're in an environment with a lot of noise like an apartment building it's worth the additional expense to get the 5GHz equipment.
You have easy and just plain impossible without cooperation.
It's one thing to mess with a closed source operating system and hide something in millions of lines of code (even though I doubt Microsoft put in flaws intentionally). A hardware design on the other hand is very strictly designed, especially when it comes to complicated high speed logic like a processor or PHY. Any addition of logic will be noticeable. I just find it funny you assume you can do this automatically. We have trouble writing software that differentiates between several things as it is. A bus we can sometimes detect based on it being defined as a vector structure in HDL. Clocks are easy enough. But beyond that it gets tricky, especially if you wish to hijack I/O. You'd have to figure out a way to get to the bond pad without it being noticeable.
And assuming you avoid messing with it at the design level and somehow hijack it when it's on the way to the foundry. It's another thing to mess with a stack of masks that need to be made on special machines that are fairly rare and take ages to do their work. The mask set costs a few million euros. If somebody is caught messing with those... Nobody is going to be very happy about it.
Well yes, but you have levels of complication in that. I'd hardly call the 6809 a RISC architecture. Complicated asynchronous logic becomes rather unreliable if you keep demanding faster speeds from it.
Testing software will capture such things easily if you're looking for it, if that isn't a distinguishing sequence then nothing is. And adding it in at the transistor level netlist would also be noticed easily. We don't really trust synthesis software so we often run programs that do reverse operations on it to extract parasitic effects and errors from the generated layout. If your RTL description doesn't match it'll throw a bucket load of errors at you. Design verification tools don't like such things... Combine it with hardware testing and you notice it's hard to slip in things unnoticed.
Thing is, we have been avoiding microcode. It's slow, RISC makes for faster designs that are easier to design and optimize. You can make a simple hardware fsm that gets the job done. Uses less area as well. We don't quite care anymore about assembly programmers I guess. This leads to ugly but fast instructions. RISC also makes pipelining damn easy, the gain of that outweighs your coding efficiency increase by an astronomical margin. And in the end the compilers don't seem to mind much if they use good optimization techniques. Programmers and compilers tend to be several years behind on the hardware though, a large performance increase is to be gained by closing that gap!
Slashdot Mirror
Yeah, but the fun is making the microstrip and cavity filters. Nothing quite beats the fun of building your own spectrum analyser. Not to mention the challenge of building a stable multi octave VCO on your own.
Did some political science major come up with this or something? This is nothing new.
It's been a well known weakness of any defence system. The moment you run out of bullets/interceptor missiles/... you're done for. Another tactic is simply overloading it with targets. You can only fire interceptors at a certain rate. If you exceed that rate for long enough you'll get through. Again not a very complicated tactic that's fairly easy to execute given sufficient time to build a large quantity of dumb missiles.
Neither of those are in the front pockets of my pants :p
No, you look at Perl in the wrong way! The camel is good at what it's designed for. It won't do it neatly but it'll get the job done. Need to hack two incompatible systems together quickly? Perl is there for you. Need low level access from a scripting language? Perl fills the gap. And in terms of performance the old camel still gives a lot of new "optimized" languages a run for their money. It's also one of the most flexible languages out there. Name a few other scripting languages that are used on such a wide range of systems? You'll encounter Perl on the small embedded systems and on large clusters. It simply adapts to the task at hand. It's sort of like Fortran and Ada in that, many people are against it but those who are familiar with it know what it's capable off aren't going to drop it cause it looks ugly to the younger programmers.
In case you're wondering Fortran is the best data crunching language out there and Ada is in a league of its own when it comes to reliability. Idealism doesn't have a place in engineering, you use the right tool for the job and stop whining about how easy it is to use or master.
I disagree. Don't neglect the 8 bit goodness. An army of 8 bit microcontrollers working together can do some pretty funny things. Nothing quite beats the old fashioned 8051 in being well documented either. And it comes in loads of flavours. I'll agree on the stay away from Arduino, just too expensive for what you get. The TI dev boards are fun, very easy to use as well. The software is a bit iffy but not too bad. Never worked with Propellers so can't really say much about those.
Another interesting option is getting one of those NXP ARM dev boards. Or even better, get a large FPGA dev board and use a soft core. Side bonus is if you need heavy data crunching you can synthesize dedicated hardware for it. Most of the common simple microcontrollers have FOSS models available. Then when you wish to build something final you can just switch to the actual MCU.
Many of these printers also have some built in speaker to play stupid sounds and warnings. Imagine the fun you could have if you somehow managed to upload the voice of HAL saying "I'm afraid I can't let you do that Dave!". Bonus points if you make it say that when the printer runs out of paper.
Yeah, 18 months is pretty young for a phone. My last smartphone lasted over 2 years and if I don't do anything insane on it it'll still do an entire day on the original battery. That's HTC quality for ya!
I never had trouble opening the phone to replace a battery. Practice makes perfect! ... . No need to make my phone itself bulky!
And the batteries I can actually keep in my vest, backpack,
I just waited for the Galaxy SIII Mini to come out. Reasonable size (not a half tablet), good feature set, big app memory and not too expensive.
More than enough Android phone options with replaceable battery.
The suggestion to use a power case has very much to do with phone cases. I bought my current phone cause it's very slim and doesn't come with a huge screen. As a nice side bonus you can replace the battery!
Believe it or not, some of us don't buy a phone if it doesn't have a replaceable battery. Hence we don't buy Apple products.
I disagree, replacing a battery in a tablet: soldering 3 wires at most and some screws.
Hacking a typewriter to act as printer: Figure out the internal workings, make a controller for it, make serial interface logic.
My latest "hack" was hooking up a network analyser to a tablet so I could control it while I was near the actual setup. Though I use quotes cause it's not exactly difficult to hook up a run off the mill Bluetooth PHY, a microcontroller and GPIB interface. All without using a single Arduino or RaspberryPi! Then again, considering what I see these days as hacks I wonder what the world has come to...
No, the added "convenience" you see is what I see as a limitation. I can have as many extra batteries as necessary while I don't need to fiddle with cases.
Heh, I sometimes do use a rowing machine or treadmill when the weather outside is horrible. Like with the ice right now I wouldn't make it 1 km outside without breaking a leg. So what did I do? Put the treadmill in front of the TV, hook up laptop, and watch a movie. Can't really contemplate the universe in your own living room when your cat is trying to attack the treadmill you're on. At least I've found it difficult.
Then again, when I do go running alone I do listen to music, but that's mainly to keep a rhythm for interval training. Otherwise I found this great entertainment form called asking a friend if she feels like going along! Though I guess we're too old fashioned.
Cause I don't like encasing my phone. Just use a screen protector to ensure your keys don't destroy the screen if they accidentally end up in the same pocket. No reason to spend another 50 euro on a damned case if you can buy 5 batteries for that price!
Ah yes, but satellite is quite different from WiFi in so many ways. Satellites use very directional spot beams in a frequency band that's not used for anything else. Combined with the fact that the spectrum allocated for satellites is very strictly regulated compared to the ISM band. A second factor is that the 2.4 GHz and 5 GHz bands are very crowded compared to that. Atmospheric interference isn't that much of a problem with WiFi obviously (especially with the lower frequencies). But the interference from other devices is. Another problem one can't forget is the that the up-link and down-link use different frequency bands that are quite a distance away from each other. So no cross-interference from the transmitter to the receiver like you have when you work in the 2.4 GHz band. And a few other differences. It's not cause you manage to use a certain type of modulation for a certain wireless application that it can be used for all the others. Modulation makes or breaks most wireless protocols. Hence why I fear they might have been a bit overly ambitious with this one.
Well, that depends on how smart the MIMO algorithm is I'd say. I've seen a few very efficient implementations that do seem to be able to select fairly good paths. I'm more worried about the necessary SNR.
Yes, but 256-QAM is very noise sensitive. Works fine on a coax cable, works fine on short copper lines. But wireless is a different story. Especially considering how crowded the 2.4 GHz band is these days. I'm not saying it's impossible, I just wonder how cost efficient these devices will be considering the SNR you'll have to achieve to keep the error rate down. At some point it might not be worth it.
I usually get 3-4 MB/s, have had more than a few peaks of 5 MB/s. Which isn't all that weird considering 54 Mbps. And that's through laminate, not exactly the best material for WiFi. Important side note is that I live in the middle of nowhere and the 2.4 GHz band is almost empty except for my neighbours routers which aren't too close either. If you're in an environment with a lot of noise like an apartment building it's worth the additional expense to get the 5GHz equipment.
256-QAM modulation for wireless data transfer, sure...
What's the intended range in realistic situations, 5cm?
You have easy and just plain impossible without cooperation.
It's one thing to mess with a closed source operating system and hide something in millions of lines of code (even though I doubt Microsoft put in flaws intentionally). A hardware design on the other hand is very strictly designed, especially when it comes to complicated high speed logic like a processor or PHY. Any addition of logic will be noticeable. I just find it funny you assume you can do this automatically. We have trouble writing software that differentiates between several things as it is. A bus we can sometimes detect based on it being defined as a vector structure in HDL. Clocks are easy enough. But beyond that it gets tricky, especially if you wish to hijack I/O. You'd have to figure out a way to get to the bond pad without it being noticeable.
And assuming you avoid messing with it at the design level and somehow hijack it when it's on the way to the foundry. It's another thing to mess with a stack of masks that need to be made on special machines that are fairly rare and take ages to do their work. The mask set costs a few million euros. If somebody is caught messing with those... Nobody is going to be very happy about it.
Well yes, but you have levels of complication in that. I'd hardly call the 6809 a RISC architecture. Complicated asynchronous logic becomes rather unreliable if you keep demanding faster speeds from it.
Testing software will capture such things easily if you're looking for it, if that isn't a distinguishing sequence then nothing is. And adding it in at the transistor level netlist would also be noticed easily. We don't really trust synthesis software so we often run programs that do reverse operations on it to extract parasitic effects and errors from the generated layout. If your RTL description doesn't match it'll throw a bucket load of errors at you. Design verification tools don't like such things... Combine it with hardware testing and you notice it's hard to slip in things unnoticed.
Thing is, we have been avoiding microcode. It's slow, RISC makes for faster designs that are easier to design and optimize. You can make a simple hardware fsm that gets the job done. Uses less area as well. We don't quite care anymore about assembly programmers I guess. This leads to ugly but fast instructions. RISC also makes pipelining damn easy, the gain of that outweighs your coding efficiency increase by an astronomical margin. And in the end the compilers don't seem to mind much if they use good optimization techniques. Programmers and compilers tend to be several years behind on the hardware though, a large performance increase is to be gained by closing that gap!