TerreStar does the reverse: they have "massive" beamforming on the satellite itself. The satellite, in essence, tracks your phone with a dedicated beam.
A transaction draws money from your account immediately, good luck trying to reverse that later, I mean it is YOUR money gone, not the bank's money.
Do you have trouble reading?
There is no money in the account, ever, except when I'm just about to buy something, and then only enough to pay for the thing I'm buying. I never have to worry about reversals, as no unauthorized payment can be taken to be reversed.
LOL. It doesn't matter whether you have money in the account. One day you'll wake up to a negative balance, and guess what: the bank will have you pay it, or your credit rating will take a dump.
There are two aspects of space radiation: errors and cumulative damage. When you shop for mission-critical equipment, especially for the control computers, you want them to work just fine in spite of radiation. For a camera like that: who cares if there are upsets in individual pixels periodically, or if it becomes noisier after a few days. COTS laptops work just fine on IST, and it's hardly a radiation-tight environment, so I think that the space buffs here who are used to $1E6 through $1E8 price tags for cameras just need to calm down. It's not a Cassini mission.
A "current" camera is essentially a chip the size of a SO-8, a small cast lens retainer that's attached to the PCB, and the lens -- everything fits in under a cubic centimeter. It'd take tremendous accelerations to "dissolve it into tiny bits" -- if the camera would disintegrate, there would be nothing left of the rocket. F=m*a after all, with m on the order of a gram.
If you go for a pinhole, it'd be even simpler -- the pinhole and enclosure (light shield) are a little cast piece that can be bonded to the PCB while the PCB itself is being laminated. Probably the cable will weigh more than the camera, even if you manufacture the camera and cable as a flex PCB, as many aerospace gadgets are done for weight savings and reliability (at least one connector less).
My definition of a toy goes hand-in-hand with how much productivity is afforded by it. Tk's canvas's functionality was AFAIK available and surpassed already in Qt's graphics canvas in Qt 3.x. Qt 4.2 had a completely redone canvas system that is pretty much state of the art.
For hard realtime applications -- yes, stock linux kernel is a toy. If you need realtime performance, that is. Not all embedded products need it. I'm not familiar enough with various realtime extensions and patches to linux kernel to know whether the linux kernel becomes less of a toy then.
You also need to compare apples to apples, as QNX is a whole distribution, not merely a kernel. I presume that, say, WindRiver Linux coupled with Qt Embedded provides similar feature set to QNX.
Be careful: The mechanical shock induced by cooling things down rapidly with liquid nitrogen may be well enough to detonate things. And what would the inert atmosphere be good for I just don't know, explosives don't give shit about atmosphere. Explosive bolts are used in the vacuum of space, duh.
TRWTF, IMHO, is that Tai's article is cited almost 40 times. I'd like to think it was meant as an April Fool's joke and got published too soon (in February).
Qt's power is precisely what you want it for: your prototype can be that much closer to the real thing. IMHO, of course. This is to a point where developing a semi-working mockup of a vector graphical editor with rather advanced functionality (path stroking, filters, etc) can be done in a day.
Is the Makita you have the one that got a multi-pin signal connector (in a yellow shroud) on the Li-Ion battery pack in addition to the large end-of-string terminals?
I still think that cell monitoring is only good to an extent: you can certainly prevent over[dis]charging of a cell, but you cannot balance out the charge in the cells. To do the latter takes a shunt across each cell. Every EV with lithium batteries has it; it's not like it'd have to be expensive. What's an N-mosfet in series with a P-mosfet going to cost, especially that they don't have to carry full load current. To keep dissipation low while doing partial shunting, the shunt can be chopped. When a cell goes dead, it can be shunted permanently. What's a few dozen milliohms between friends;)
Every battery pack I've ever had and did a post-mortem on (a dozen or so), that had a half-decent charger, would have a single cell fail, rendering the whole pack useless, while the other cells had plenty of useful capacity left. This is for both Ni-Cd and Ni-MH packs. I didn't have a lithium pack die on me yet that wasn't covered by Apple warranty (lucky me, I guess) -- thus no fiddling with the innards.
Many battery-powered implements, such as cordless phones and tools, implement next to no battery management. It is only fairly recent that brands like Makita or Milwaukee offer battery packs where each cell is monitored, and presumably can be bypassed to prevent overcharging or over-discharging. An EV will have networked individual cell monitors that include shunts to bypass dead cells, and overcharged or under-discharged cells.
It's very unfortunate: most low-end cordless tools (and other cordless devices) treat the multicell battery as a unit, and charge/discharge with no regard for individual cell's well-being. It only takes one overstressed cell to make the whole pack useless then! And you're lucky when they correctly charge that compound battery to begin with.
And yes, there are some absolutely insane designs. I'll give two concrete examples from the U.S. market. #1: the ~$13 Black-and-Decker cordless 9.6v screwdriver/drill that essentially charges the Ni-Cd battery with a current-limited trickle. The pack lasted about 6 months. #2: the otherwise very nice Summer 900MHz cordless video baby monitor. The portable receiver has a rechargeable battery, and the manual helpfully advises that you should only plug it in overnight and use it unplugged during the day to prevent overcharging the battery and shortening its file. Because Ni-Cd charger chips that handle all aspects of the charging are so hard to come by. It just makes me cringe.
Look, I have plenty of experience using Qt's graphics canvas system. I have read through the docs of Tk canvas, and I have got myself to play with the Tk canvas yesterday. The latter is a toy, when compared to Qt's QGraphicsItem/Scene/View. So unless you give me some hard facts and address the shortcomings I gave in the other post in this discussion, you're just flamebaiting.
Tk provides a proof-of-concept canvas. Something that basically shows how it could be done, and how a nice API might look like, but provides a far cry, functionality-wise, from what one gets with Qt, and what one would expect to get in real application development. So as far as I'm concerned, it doesn't exist.
Specifically: - no support for items of arbitrary shape (for this you need painter paths and path strokers), - no support for variable level of detail (likely because there are no complex items anyway), - no support for user-defined items within Tcl -- you need C code for that, - no support for arbitrary transformations (no rotation/shears), - no model/view (the canvas widget contains its model -- model can't exist without the view), - no hierarchy -- all items are stored in an array called the display list, there is no parent/child relationship, - no support for embedding Tk widgets (you can "embed" widgets, but they are top-level native widgets), - it's not explicitly mentioned if there a spatial index (say a BSP tree)?
I'd do it in a different way that may well be lower cost and more scalable than any wavelength- or polarization-based selectivity.
1. Run the Kinects off a common reference frequency. The onboard circuitry probably uses one crystal oscillator and PLL-controlled VCOs to generate various derivative frequencies to time everything. A common reference will keep all Kinects phase-synchronized, while the phase itself may well be random.
2. Figure out how to discover the phase angle when the IR camera shutter is open (vs. reference frequency), and figure out how is this angle initialized. Is that fixed at power-up, or is it related to the timing of the USB commands? All we care for is to know when the IR camera is sensitive to light, and how to control the initial reference phase for that. It may even be that the IR light is strobed for thermal or power management -- that would need to be in sync with the camera. Anyone out there with a Kinect and a scope to probe the drive voltage to the IR illuminator? Or perhaps the camera is a separate chip and there simply are clock lines to be sniffed out. In any case this should be fairly easy to do.
3. Set up a simple mechanical sector shutter for each Kinect's camera. A symmetrically notched CD glued to a spindle assembly from dead CD or DVD drive will do just fine. The illuminator can be chopped electrically.
4. Add an optical interrupter sensor to each shutter for feedback, and run a PLL on a microcontroller to keep the mechanical shutter in phase sync to the IR camera's electronic shutter.
Since we can control the camera shutter phase and can keep those phases synced across multiple Kinects, we can do time division multiplexing. With very many Kinects one needs to increase the power to the illuminator; perhaps moving to a higher-powered IR LED or laser diode as a light source. The camera shouldn't be a problem -- heck, it will become less sensitive to background IR as the time division gets shorter.
You miss on how much more expensive the non-CG movies would have to be to allow this. In many sets, if you'd move the camera just a bit outside of what it views, you'd see all of the production equipment, other people, etc. In classical 2D and stereoscopic (market-speak 3D) filming on a set, you only build enough of an expensive set to let you film what's in the screenplay. Anything more is a waste.
Same goes for 3D CG movies: no point in making the character and scene models any more detailed/extensive than they need to be -- it all requires work: either for modelmaking, or to develop software to procedurally generate the model (usually for environments).
Again -- I agree, with a little but: they "deserve" it just for being human. That they put a bad name to humanity -- sure. Those are really orthogonal.
While I mostly agree, freedom is not something one "deserves"t. It's a basic human right. Everyone "deserves" it simply because they are human, cowards or not.
There are no analogies that one needs. Explain it like it is. Use new concepts. Kids are great at compartmentalizing away what they don't understand; they'll come back to you with questions later.
Different kids can be very different at same age. You can have a 4 year old that fluently reads two languages, and another one who just watches TV all day and is useless for anything else. My daughter is no genius, but she can navigate YouTube just fine at age 6, and is quite interested by space- and weather- science flicks. A couple days ago I caught her watching an illustrated lecture on the origins of the solar system. She found it herself. It doesn't matter whether she understands everything out of it, but at least she is exposed to knowledge and gets seeded to ask more questions.
Slashdot Mirror
TerreStar does the reverse: they have "massive" beamforming on the satellite itself. The satellite, in essence, tracks your phone with a dedicated beam.
Do you have trouble reading?
There is no money in the account, ever, except when I'm just about to buy something, and then only enough to pay for the thing I'm buying. I never have to worry about reversals, as no unauthorized payment can be taken to be reversed.
LOL. It doesn't matter whether you have money in the account. One day you'll wake up to a negative balance, and guess what: the bank will have you pay it, or your credit rating will take a dump.
There are two aspects of space radiation: errors and cumulative damage. When you shop for mission-critical equipment, especially for the control computers, you want them to work just fine in spite of radiation. For a camera like that: who cares if there are upsets in individual pixels periodically, or if it becomes noisier after a few days. COTS laptops work just fine on IST, and it's hardly a radiation-tight environment, so I think that the space buffs here who are used to $1E6 through $1E8 price tags for cameras just need to calm down. It's not a Cassini mission.
A "current" camera is essentially a chip the size of a SO-8, a small cast lens retainer that's attached to the PCB, and the lens -- everything fits in under a cubic centimeter. It'd take tremendous accelerations to "dissolve it into tiny bits" -- if the camera would disintegrate, there would be nothing left of the rocket. F=m*a after all, with m on the order of a gram.
If you go for a pinhole, it'd be even simpler -- the pinhole and enclosure (light shield) are a little cast piece that can be bonded to the PCB while the PCB itself is being laminated. Probably the cable will weigh more than the camera, even if you manufacture the camera and cable as a flex PCB, as many aerospace gadgets are done for weight savings and reliability (at least one connector less).
Agreed, through there are some people who spend quite a bit of time replicating all the imperfections -- say in the Arturia MiniMoog emulator :)
Not a realistic one, though. IOW: tell that to people who code Spice-like modelling software :)
My definition of a toy goes hand-in-hand with how much productivity is afforded by it. Tk's canvas's functionality was AFAIK available and surpassed already in Qt's graphics canvas in Qt 3.x. Qt 4.2 had a completely redone canvas system that is pretty much state of the art.
For hard realtime applications -- yes, stock linux kernel is a toy. If you need realtime performance, that is. Not all embedded products need it. I'm not familiar enough with various realtime extensions and patches to linux kernel to know whether the linux kernel becomes less of a toy then.
You also need to compare apples to apples, as QNX is a whole distribution, not merely a kernel. I presume that, say, WindRiver Linux coupled with Qt Embedded provides similar feature set to QNX.
Be careful: The mechanical shock induced by cooling things down rapidly with liquid nitrogen may be well enough to detonate things. And what would the inert atmosphere be good for I just don't know, explosives don't give shit about atmosphere. Explosive bolts are used in the vacuum of space, duh.
This deserves to be modded up. Very true.
Worse yet, the hubris to name the method after yourself.
TRWTF, IMHO, is that Tai's article is cited almost 40 times. I'd like to think it was meant as an April Fool's joke and got published too soon (in February).
Qt's power is precisely what you want it for: your prototype can be that much closer to the real thing. IMHO, of course. This is to a point where developing a semi-working mockup of a vector graphical editor with rather advanced functionality (path stroking, filters, etc) can be done in a day.
Is the Makita you have the one that got a multi-pin signal connector (in a yellow shroud) on the Li-Ion battery pack in addition to the large end-of-string terminals?
I still think that cell monitoring is only good to an extent: you can certainly prevent over[dis]charging of a cell, but you cannot balance out the charge in the cells. To do the latter takes a shunt across each cell. Every EV with lithium batteries has it; it's not like it'd have to be expensive. What's an N-mosfet in series with a P-mosfet going to cost, especially that they don't have to carry full load current. To keep dissipation low while doing partial shunting, the shunt can be chopped. When a cell goes dead, it can be shunted permanently. What's a few dozen milliohms between friends ;)
Every battery pack I've ever had and did a post-mortem on (a dozen or so), that had a half-decent charger, would have a single cell fail, rendering the whole pack useless, while the other cells had plenty of useful capacity left. This is for both Ni-Cd and Ni-MH packs. I didn't have a lithium pack die on me yet that wasn't covered by Apple warranty (lucky me, I guess) -- thus no fiddling with the innards.
Many battery-powered implements, such as cordless phones and tools, implement next to no battery management. It is only fairly recent that brands like Makita or Milwaukee offer battery packs where each cell is monitored, and presumably can be bypassed to prevent overcharging or over-discharging. An EV will have networked individual cell monitors that include shunts to bypass dead cells, and overcharged or under-discharged cells.
It's very unfortunate: most low-end cordless tools (and other cordless devices) treat the multicell battery as a unit, and charge/discharge with no regard for individual cell's well-being. It only takes one overstressed cell to make the whole pack useless then! And you're lucky when they correctly charge that compound battery to begin with.
And yes, there are some absolutely insane designs. I'll give two concrete examples from the U.S. market. #1: the ~$13 Black-and-Decker cordless 9.6v screwdriver/drill that essentially charges the Ni-Cd battery with a current-limited trickle. The pack lasted about 6 months. #2: the otherwise very nice Summer 900MHz cordless video baby monitor. The portable receiver has a rechargeable battery, and the manual helpfully advises that you should only plug it in overnight and use it unplugged during the day to prevent overcharging the battery and shortening its file. Because Ni-Cd charger chips that handle all aspects of the charging are so hard to come by. It just makes me cringe.
Look, I have plenty of experience using Qt's graphics canvas system. I have read through the docs of Tk canvas, and I have got myself to play with the Tk canvas yesterday. The latter is a toy, when compared to Qt's QGraphicsItem/Scene/View. So unless you give me some hard facts and address the shortcomings I gave in the other post in this discussion, you're just flamebaiting.
OK, I was wrong. s/zero functionality/toy functionality/. Doesn't change things for much better IMHO.
Tk provides a proof-of-concept canvas. Something that basically shows how it could be done, and how a nice API might look like, but provides a far cry, functionality-wise, from what one gets with Qt, and what one would expect to get in real application development. So as far as I'm concerned, it doesn't exist.
Specifically:
- no support for items of arbitrary shape (for this you need painter paths and path strokers),
- no support for variable level of detail (likely because there are no complex items anyway),
- no support for user-defined items within Tcl -- you need C code for that,
- no support for arbitrary transformations (no rotation/shears),
- no model/view (the canvas widget contains its model -- model can't exist without the view),
- no hierarchy -- all items are stored in an array called the display list, there is no parent/child relationship,
- no support for embedding Tk widgets (you can "embed" widgets, but they are top-level native widgets),
- it's not explicitly mentioned if there a spatial index (say a BSP tree)?
I'd do it in a different way that may well be lower cost and more scalable than any wavelength- or polarization-based selectivity.
1. Run the Kinects off a common reference frequency. The onboard circuitry probably uses one crystal oscillator and PLL-controlled VCOs to generate various derivative frequencies to time everything. A common reference will keep all Kinects phase-synchronized, while the phase itself may well be random.
2. Figure out how to discover the phase angle when the IR camera shutter is open (vs. reference frequency), and figure out how is this angle initialized. Is that fixed at power-up, or is it related to the timing of the USB commands? All we care for is to know when the IR camera is sensitive to light, and how to control the initial reference phase for that. It may even be that the IR light is strobed for thermal or power management -- that would need to be in sync with the camera. Anyone out there with a Kinect and a scope to probe the drive voltage to the IR illuminator? Or perhaps the camera is a separate chip and there simply are clock lines to be sniffed out. In any case this should be fairly easy to do.
3. Set up a simple mechanical sector shutter for each Kinect's camera. A symmetrically notched CD glued to a spindle assembly from dead CD or DVD drive will do just fine. The illuminator can be chopped electrically.
4. Add an optical interrupter sensor to each shutter for feedback, and run a PLL on a microcontroller to keep the mechanical shutter in phase sync to the IR camera's electronic shutter.
Since we can control the camera shutter phase and can keep those phases synced across multiple Kinects, we can do time division multiplexing. With very many Kinects one needs to increase the power to the illuminator; perhaps moving to a higher-powered IR LED or laser diode as a light source. The camera shouldn't be a problem -- heck, it will become less sensitive to background IR as the time division gets shorter.
You miss on how much more expensive the non-CG movies would have to be to allow this. In many sets, if you'd move the camera just a bit outside of what it views, you'd see all of the production equipment, other people, etc. In classical 2D and stereoscopic (market-speak 3D) filming on a set, you only build enough of an expensive set to let you film what's in the screenplay. Anything more is a waste.
Same goes for 3D CG movies: no point in making the character and scene models any more detailed/extensive than they need to be -- it all requires work: either for modelmaking, or to develop software to procedurally generate the model (usually for environments).
Again -- I agree, with a little but: they "deserve" it just for being human. That they put a bad name to humanity -- sure. Those are really orthogonal.
While I mostly agree, freedom is not something one "deserves"t. It's a basic human right. Everyone "deserves" it simply because they are human, cowards or not.
A successful career in politics may not necessarily be a good thing, you know.
There are no analogies that one needs. Explain it like it is. Use new concepts. Kids are great at compartmentalizing away what they don't understand; they'll come back to you with questions later.
Different kids can be very different at same age. You can have a 4 year old that fluently reads two languages, and another one who just watches TV all day and is useless for anything else. My daughter is no genius, but she can navigate YouTube just fine at age 6, and is quite interested by space- and weather- science flicks. A couple days ago I caught her watching an illustrated lecture on the origins of the solar system. She found it herself. It doesn't matter whether she understands everything out of it, but at least she is exposed to knowledge and gets seeded to ask more questions.
OP wants a canvas, not a dinosaur. Tcl/Tk provides exactly zero functionality needed for an interactive canvas.