Kind of... I've been reading about them, and have a full dev kit sitting next to me on my desk, but I haven't had the time to actually crack it open and try it out yet. Maybe next weekend... I have been meaning to build that DAC...
Seriously guys, cool site. FPGAs are dynamically reconfigurable logic circuitry that can emulate almost any other hardware, AT THE HARDWARE LEVEL. Tell it with software how to connect the transistors up, and that's what it does. OpenCores.org focuses on creating CPUs for FPGAs (verilogic being one of the two big manufacturers of FPGAs) that will run standard instruction sets, such as ARM or Intel (mostly focusing on embedded applications, because an FPGA emulating a core is SLOW... they can get up to about 50 MHz clock speed, but not much more)
First off, most commodity imaging hardware does not have specified shutter rates, so anything that's timing dependant may be a problem. On the other hand, at the slightly more money than commodity but still less than lab equipment point, are industrial CCDs... usually they can be had for sub $500, and have a lot more options and better specs.
Assuming that you are going with a commodity imaging device, calibration is going to be important. Do it yourself with test patterns. Also, try to work in greyscale if possible. Many CCDs, when in color mode, have some built in color / light level compensation that will kill all your chromatic accuracy.
I'd just like to second that, and throw all my karma to the wind by going completely offtopic at the same time.
Wil, if I was a cool kid, I would definitely save you a seat. Post more often on slashdot! I've been reading your old comments, nothing I saw that I didn't think belonged here.
Oh, and good luck with the comedy. If I'm ever in the area, I'll be sure to check out one of your shows.
Well, then I hope they have lots of money to spend. 8TB of storage is not cheap, no way around that. For the amount you'll be spending to store that much data indefinitely (call indefinitely 3 years), you could probably develop holographic memory and use that instead.
See my previous post here on the subject. Basically, what you'll be looking at for this will be a large, robot-run facility that can archive that much daily. An 8 TB tape drive (and tapes) isn't that expensive, but the machinery to keep the tape drive fed is. Plus, I'd suggest making 4 tapes for every one. IIRC, tapes fail an average of 68% of the time... but of course that was 2 years ago, so the industry may have gotten a little better by now. And the failure rate is more related to storage time and handling conditions than brand of tape or drive.
Okay, mod me as redundant, but I'd like to know what the possible real world application is...
First off, there are commercial solutions that tape 10:1 onto VHS tape... maybe you could take one of these a step further (custom ASIC dev) and do 100:1 for grayscale.
Now, assuming analog is not the way to go (sounds like you want to stay digital), first you'd probably want to do motion detection. Only capture the stream from a camera that is reading changes. Depending on the application, that can cut your storage space down significantly, especially in off-peak hours.
Second, I'd probably rethink 30 fps. 15 fps is nearly as good, and takes half the storage space. ATM cameras can range from 5 fps to 1/5 fps... and give good enough results in most circumstances.
That combination should take you down to between 1 TB and 100 GB per day (maybe less depending on usage)... which is definitely more manageable. At that point, an HSM is the answer... look at any of the other excellent posts regarding this.
I worked at one point for a major US corporation with similar needs, and they have a data backup center... it's basically a huge warehouse with tape drives, robots to change tapes and cart them around the warehouse, and tons of archive space for the said tapes. Perhaps this would be a good solution for you? As I recall, they spent about $5 MM for the hardware, and about the same for the actual installation (which is terrorist resistant, etc.)
Yeah, but Tell-Me-Thrice has relevance even if two bits out of three always agree... it basically makes the assumption that if any of the bits don't agree, then something has gone wrong, and the minute chance that two of your processors are wrong and one is right is enough of a risk to a critical application (e.g. guiding a couple billion dollars worth of hardware around the solar system such that it gets where its going) that its best to just consult a known-good bit source (ground computer) in that case...
As one of the replies pointed out, this is clearly not the case.
What you're describing is known as Tell Me Thrice bitwise redundancy. Three-way bitwise redundancy relies on three processors, any time a bit doesn't match, it has a best of two rule. Tell Me Thrice consults a seperate computer, usually on a slower link but in a secure, controlled environment, in that case.
I don't think Tell Me Thrice has ever actually been implemented, though. If anyone has done it, it would be NASA... any idea what program it might have been?
I'm just disappointed they didn't release the shuttle sync stuff... the shuttle runs two computers, the ground runs another... and they have software that keeps in sync, down to the system clock. I've even heard rumor that it runs on commodity (radiation-hardened) 386 CPUs.
That would be some cool software to get my hands on...
Okay, this guy's got the problem of how to get the internet into his village. He laments that the nearest access point is in the city, a day's walk away, and that he can't afford a satellite phone...
How far is a day's walk? Is it farther than an 802.11b? With tuned antennas? I mean, an 802.11b access point could be the answer... big upfront cost, but no ongoing cost. And he's already bought 15 monitors and 2 power generators, so the cost of an access point at the big city ISP may be trivial next to that...
Anyone have any ideas on that? How far is a daywalk, anyways?
A girl that can argue with me all night over a search algorithm, or who can critique my programming technique in my latest hobbyist software... this girl I shall propose to when I meet her.
First I'd like to say that I really liked your character and I was upset when he was written out of the show.
A lot of questions have focused on either your level of geekiness or how many of your Trek co-actors you got to see nude. I have a bit more concrete question, which I think might tell us a lot more about you:
Did anyone understand the part about "It moves primarily through a cam in a cage. On contact with the wall, it applies through moving disc cam in cage, to the opposite axis"
I understand that this says basically that it moves away from walls when it contacts them, but I can't figure out for the life of me what a "disc cam in cage" is, or how this would help it push off of the wall?
Yeah, I was actually looking at using this method to do image compression until I ran across the patent. Hopefully the methods that I was looking at will still be valid in 2010... and they won't have been superceded by MPEG-8 or whatever.
As I remember, one of the major advantages, besides cheap decoding, was hardware encoding could be used relatively easily...
You are absolutely correct with regards to the 1:1 mapping. You might be able to get some compression in, in that you are storing the idea of a thing and not the thing itself (e.g. information as opposed to data)... but I think you are more accurate in the plausible worlds theory.
The big question is, is the representation "smooth" enough to encapsulate arbitrary real-life examples?
This is known as the Iterative Fractal System, or IFS, and is actually patented (not sure by who... remember the gentlemen's first name is Michael)
There was a great chapter in the book, "Programming Tricks of Computer Graphics Gurus" about the subject. Basically, lay out regions on your screen that represent the various parts of the fractal. Make a translation / rotation / scale matrix describing each one. You can make an IDE that applies the matrix to the entire screen (resulting in morphed rectangles at each vertex).
Then, assign a probability to each row of the matrix that is the area of the transformation compared to the total area. Use your random number algorithm to pick out which one to apply, and apply it to your point.
Most of the time this is an arbitrary process, such as "Do it 100 times without plotting to stabilize the jumping point, then do it 1000 times to get a good estimate of the final figure." A lot of people coding it take it one step further and basically end tracing when a certain percent of the last x points drawn were already present...
I just wonder how big their problem space is, and does it conform to the genetic algorithm definition of "smooth"... the existance of sliders would seem to indicate that this is so.
Smooth may be defined as:
function: all genotypes code for valid phenotypes
injective (compact, nonredundant): different genotypes lead to different phenotypes
surjective (universal): all phenotypes are representable
continuous: small variations in the genotype produce small variations in the phenotype
inversely continuous: small variations in the phenotype can be induced by small variations in the genotype
Where genotype refers to the parameters and phenotype to the representation of the world.
If this were true, then one could theoretically evolve (using GA techniques) a planet that is a reasonable facsimile of earth, or any other feature set. Want a detailed map of San Francisco Bay? Let me squirt my survey through my Genetic Algorithm MojoWorld Compression Algorithm. Oh good, it's done. Use these five numbers to recreate the map...
Hmmm... sounds like it's plausible, but I don't think that small changes in the genotype necessarily result in small changes in the phenotype.
I think one could easily build an MPEG-4 encoding cluster. Since the system is in an aircraft aluminum box anyways, it's not like you would be making it much less portable, especially considering the size and complexity of the camera in the first place.
Just use some PC/104 or similar embedded technologies to build a cluster that does realtime MPEG-4 encoding. Or even better, use some of TI's new high-speed Digital Signal Processors (I have one sitting on my desk that runs approx. 2.4 GIPS and cost here is a company that has already done an embedded MPEG4 encoder for videophone apps...
There are solid state solutions to this, mostly involving fractal antennas and the like, which don't require any moving parts. But, even a simple dish antenna is possible. The problem is that the entire system becomes a bit more complicated as a result...
I was watching it last night at about 7:00 EST and noticing how much vidphone technology had improved, and wondering how they were doing it...
Actually, now that my nostalgia processor has kicked in, I was actually musing that this was the worst live feed I'd ever seen and that it must therefore be some new, super-portable digital application that I hadn't heard of yet...
Well, first off, cut out the full duplex operation. Send voice only out to the field, and use the extra bandwidth for more frames. The reporter on the other end rarely needs to see what's happening in the home office, while the whole world would appreciate a clearer picture.
They're using H.263 compression algorithms... some dismal figures (it was made to be used at 10 fps, for instance!) Here's a nice page detailing the standard and some comparisons to MPEGs...
Here's a great page comparing H.263 to MPEG-4... Hmmm... Jurassic Park encoded in High Quality MPEG-4 beat the 64 Kbit/s rate of H.263 by nearly %20... the video phones are, according to the article, 112Kbit/s... Anyone have any clue about using MPEG-4 to do this? Sounds to me like it'd be a much better compression algorithm...
Slashdot Mirror
Are you new to FPGA's?
Kind of... I've been reading about them, and have a full dev kit sitting next to me on my desk, but I haven't had the time to actually crack it open and try it out yet. Maybe next weekend... I have been meaning to build that DAC...
Why? And while we're at it, why as an AC?
Opencores.org is /.ed...
google cache here
Wow, I'm such a karma whore.
Seriously guys, cool site. FPGAs are dynamically reconfigurable logic circuitry that can emulate almost any other hardware, AT THE HARDWARE LEVEL. Tell it with software how to connect the transistors up, and that's what it does. OpenCores.org focuses on creating CPUs for FPGAs (verilogic being one of the two big manufacturers of FPGAs) that will run standard instruction sets, such as ARM or Intel (mostly focusing on embedded applications, because an FPGA emulating a core is SLOW... they can get up to about 50 MHz clock speed, but not much more)
Alright, now I don't feel like such a ho'...
First off, most commodity imaging hardware does not have specified shutter rates, so anything that's timing dependant may be a problem. On the other hand, at the slightly more money than commodity but still less than lab equipment point, are industrial CCDs... usually they can be had for sub $500, and have a lot more options and better specs.
Assuming that you are going with a commodity imaging device, calibration is going to be important. Do it yourself with test patterns. Also, try to work in greyscale if possible. Many CCDs, when in color mode, have some built in color / light level compensation that will kill all your chromatic accuracy.
I'd just like to second that, and throw all my karma to the wind by going completely offtopic at the same time.
Wil, if I was a cool kid, I would definitely save you a seat. Post more often on slashdot! I've been reading your old comments, nothing I saw that I didn't think belonged here.
Oh, and good luck with the comedy. If I'm ever in the area, I'll be sure to check out one of your shows.
Well, then I hope they have lots of money to spend. 8TB of storage is not cheap, no way around that. For the amount you'll be spending to store that much data indefinitely (call indefinitely 3 years), you could probably develop holographic memory and use that instead.
See my previous post here on the subject. Basically, what you'll be looking at for this will be a large, robot-run facility that can archive that much daily. An 8 TB tape drive (and tapes) isn't that expensive, but the machinery to keep the tape drive fed is. Plus, I'd suggest making 4 tapes for every one. IIRC, tapes fail an average of 68% of the time... but of course that was 2 years ago, so the industry may have gotten a little better by now. And the failure rate is more related to storage time and handling conditions than brand of tape or drive.
Okay, mod me as redundant, but I'd like to know what the possible real world application is...
First off, there are commercial solutions that tape 10:1 onto VHS tape... maybe you could take one of these a step further (custom ASIC dev) and do 100:1 for grayscale.
Now, assuming analog is not the way to go (sounds like you want to stay digital), first you'd probably want to do motion detection. Only capture the stream from a camera that is reading changes. Depending on the application, that can cut your storage space down significantly, especially in off-peak hours.
Second, I'd probably rethink 30 fps. 15 fps is nearly as good, and takes half the storage space. ATM cameras can range from 5 fps to 1/5 fps... and give good enough results in most circumstances.
That combination should take you down to between 1 TB and 100 GB per day (maybe less depending on usage)... which is definitely more manageable. At that point, an HSM is the answer... look at any of the other excellent posts regarding this.
I worked at one point for a major US corporation with similar needs, and they have a data backup center... it's basically a huge warehouse with tape drives, robots to change tapes and cart them around the warehouse, and tons of archive space for the said tapes. Perhaps this would be a good solution for you? As I recall, they spent about $5 MM for the hardware, and about the same for the actual installation (which is terrorist resistant, etc.)
Hope that helps!
Yeah, but Tell-Me-Thrice has relevance even if two bits out of three always agree... it basically makes the assumption that if any of the bits don't agree, then something has gone wrong, and the minute chance that two of your processors are wrong and one is right is enough of a risk to a critical application (e.g. guiding a couple billion dollars worth of hardware around the solar system such that it gets where its going) that its best to just consult a known-good bit source (ground computer) in that case...
As one of the replies pointed out, this is clearly not the case.
What you're describing is known as Tell Me Thrice bitwise redundancy. Three-way bitwise redundancy relies on three processors, any time a bit doesn't match, it has a best of two rule. Tell Me Thrice consults a seperate computer, usually on a slower link but in a secure, controlled environment, in that case.
I don't think Tell Me Thrice has ever actually been implemented, though. If anyone has done it, it would be NASA... any idea what program it might have been?
Gee... guess it's my day to be wrong.
I distinctly remember reading that some NASA program had a setup like this, but can't recall where I read it...
In any case, I do want to take a look at the redundency / parallelism stuff. Should be some really nice code there...
I'm just disappointed they didn't release the shuttle sync stuff... the shuttle runs two computers, the ground runs another... and they have software that keeps in sync, down to the system clock. I've even heard rumor that it runs on commodity (radiation-hardened) 386 CPUs.
That would be some cool software to get my hands on...
Okay, this guy's got the problem of how to get the internet into his village. He laments that the nearest access point is in the city, a day's walk away, and that he can't afford a satellite phone...
How far is a day's walk? Is it farther than an 802.11b? With tuned antennas? I mean, an 802.11b access point could be the answer... big upfront cost, but no ongoing cost. And he's already bought 15 monitors and 2 power generators, so the cost of an access point at the big city ISP may be trivial next to that...
Anyone have any ideas on that? How far is a daywalk, anyways?
Geekess all the way!
A girl that can argue with me all night over a search algorithm, or who can critique my programming technique in my latest hobbyist software... this girl I shall propose to when I meet her.
Hi Whil,
First I'd like to say that I really liked your character and I was upset when he was written out of the show.
A lot of questions have focused on either your level of geekiness or how many of your Trek co-actors you got to see nude. I have a bit more concrete question, which I think might tell us a lot more about you:
What's your geek code?
A gyro! Of course!!! Thanks everyone!
As for the moving away from walls part, I think it means orienting away from the wall it just touched...
Did anyone understand the part about "It moves primarily through a cam in a cage. On contact with the wall, it applies through moving disc cam in cage, to the opposite axis"
I understand that this says basically that it moves away from walls when it contacts them, but I can't figure out for the life of me what a "disc cam in cage" is, or how this would help it push off of the wall?
Yeah, I was actually looking at using this method to do image compression until I ran across the patent. Hopefully the methods that I was looking at will still be valid in 2010... and they won't have been superceded by MPEG-8 or whatever.
As I remember, one of the major advantages, besides cheap decoding, was hardware encoding could be used relatively easily...
You are absolutely correct with regards to the 1:1 mapping. You might be able to get some compression in, in that you are storing the idea of a thing and not the thing itself (e.g. information as opposed to data)... but I think you are more accurate in the plausible worlds theory.
The big question is, is the representation "smooth" enough to encapsulate arbitrary real-life examples?
This is known as the Iterative Fractal System, or IFS, and is actually patented (not sure by who... remember the gentlemen's first name is Michael)
There was a great chapter in the book, "Programming Tricks of Computer Graphics Gurus" about the subject. Basically, lay out regions on your screen that represent the various parts of the fractal. Make a translation / rotation / scale matrix describing each one. You can make an IDE that applies the matrix to the entire screen (resulting in morphed rectangles at each vertex).
Then, assign a probability to each row of the matrix that is the area of the transformation compared to the total area. Use your random number algorithm to pick out which one to apply, and apply it to your point.
Most of the time this is an arbitrary process, such as "Do it 100 times without plotting to stabilize the jumping point, then do it 1000 times to get a good estimate of the final figure." A lot of people coding it take it one step further and basically end tracing when a certain percent of the last x points drawn were already present...
Smooth may be defined as:
- function: all genotypes code for valid phenotypes
- injective (compact, nonredundant): different genotypes lead to different phenotypes
- surjective (universal): all phenotypes are representable
- continuous: small variations in the genotype produce small variations in the phenotype
- inversely continuous: small variations in the phenotype can be induced by small variations in the genotype
Where genotype refers to the parameters and phenotype to the representation of the world.If this were true, then one could theoretically evolve (using GA techniques) a planet that is a reasonable facsimile of earth, or any other feature set. Want a detailed map of San Francisco Bay? Let me squirt my survey through my Genetic Algorithm MojoWorld Compression Algorithm. Oh good, it's done. Use these five numbers to recreate the map...
Hmmm... sounds like it's plausible, but I don't think that small changes in the genotype necessarily result in small changes in the phenotype.
Here's the Google cached copy (which isn't doing much better)
If you have to see the images, BryceWorld got a beta release and posted a gallery of images online.
And if you want to download it immediately to start playing with it, you can do it by filling out this questionairre
I think one could easily build an MPEG-4 encoding cluster. Since the system is in an aircraft aluminum box anyways, it's not like you would be making it much less portable, especially considering the size and complexity of the camera in the first place.
Just use some PC/104 or similar embedded technologies to build a cluster that does realtime MPEG-4 encoding. Or even better, use some of TI's new high-speed Digital Signal Processors (I have one sitting on my desk that runs approx. 2.4 GIPS and cost here is a company that has already done an embedded MPEG4 encoder for videophone apps...
There are solid state solutions to this, mostly involving fractal antennas and the like, which don't require any moving parts. But, even a simple dish antenna is possible. The problem is that the entire system becomes a bit more complicated as a result...
I can definitely second that...
I was watching it last night at about 7:00 EST and noticing how much vidphone technology had improved, and wondering how they were doing it...
Actually, now that my nostalgia processor has kicked in, I was actually musing that this was the worst live feed I'd ever seen and that it must therefore be some new, super-portable digital application that I hadn't heard of yet...
The new generation of satellite phones don't need dishes, though the antennas are usually large and bulky, not to mention the power supplies...
Actually, a lot like cell phones 15 years ago...
Well, first off, cut out the full duplex operation. Send voice only out to the field, and use the extra bandwidth for more frames. The reporter on the other end rarely needs to see what's happening in the home office, while the whole world would appreciate a clearer picture.
They're using H.263 compression algorithms... some dismal figures (it was made to be used at 10 fps, for instance!) Here's a nice page detailing the standard and some comparisons to MPEGs...
Here's a great page comparing H.263 to MPEG-4... Hmmm... Jurassic Park encoded in High Quality MPEG-4 beat the 64 Kbit/s rate of H.263 by nearly %20... the video phones are, according to the article, 112Kbit/s... Anyone have any clue about using MPEG-4 to do this? Sounds to me like it'd be a much better compression algorithm...