Am I the only one who saw that headline in an RSS feed and read it as "Bad Meth Causes Explosion at CERN Collider", and laughed out loud at the office before realizing I'd misread it and feeling like a fool?
Or is it just too early in the morning for me to be posting?
I don't know what you do to your Hondas, but I've had 3 that have all lasted past 150k mi, and one that's going strong out to 200k, and can name at least 5 people with more than 200k on the original motor and transmission. The body is historically the weak point on H/A cars (rust), not the drivetrain.
Unfortunately, all it takes is a large rock weighing a few tons with a sharp edge to fall and cleave a cable that's laying against a flat rock on the bottom. I don't know precisely how the transcontinental cables are built, but the smaller ones I've dealt with for river and lake crossings are quite vulnerable. They're stiff as hell (don't react well to bending), somewhat brittle (don't react well to bending or crushing), and designed to be laid and buried, and never move again (don't react well to general movement). A sharp vertical motion could crack them, or a rolling motion could set them up to be crushed by flying debris (quakes can be very fast, even underwater, hence tsunami generation). There's lots of ways for a cable to die.
I think the core of your question is about giving away Windows licenses for free. We love developers, period. We're also not about to give away Windows client licenses.
I beg to differ. I think it's about tying IE so close to the OS (with WGA and limited version support) as to require someone to buy the latest version of Windows and a machine to run it on in order to continue to support Microsoft's broken browser. I'm sorry, but this is a bad answer. THe profit and market share motives were completely ignored, and shouldn't be.
If Microsoft was really concerned about the browsing experience, they'd bend over backwards to attain parity with the other browsers on the market WRT standards support. Acid2 is a nice test suite to show it. As a part time developer, I can say with certainty that the stuff they've fixed is nice, but it still doesn't come close to what's required for true partiy, and by that I mean the ability of a developer (me) to write a single document for the web that's rendered the same way by the 3 browsers I see in the top of my logs (IE, Firefox and Safari).
When they get there, I'll start listening. Until then...I trust IE as far as I can throw it's program manager.
I've spent more than my fair share of time in the field doing repairs due to blown transistors, failed drivers, and the rest. Every single failure (in an outdoor, harsh environment, intrinsically safe, and heavily abused embedded system for agricultire, which I'm using as an example here) was the result of amazing abuse of the output devices. Load dump spikes hundreds of times over the design limits, connecting 120VAC to a terminal marked 12VDC, lightning (which it survived with only one blown transistor out of thousands of parts), etc. Each and every time, the failures could have been prevented with proper protection of the I/O terminals and a little common sense on the part of the operator.
For an application like this, where the only connections to the outside world are power and network, it's a pretty safe bet that the LEDs won't fail and kill the drivers. LEDs, especially the high power ones, fail open in a blinding majority of cases. A failed open LED will present no killing load to the low side switch, and no killing load to the uC. Even if it failed shorted, the odds that it would take out both the FET and the uC pin, with a 1K gate resistor, are damn small. If I was designing a system like this for mass production in a harsh environment and it needed five nines availablity, then yes, drivers would be appropriate, along with load monitoring, optoisolation from the network, and a few other things. For a one off 6x6 hack, or even for a low buck small market (1-10k units) project, the simple limiting resistor is fine. I'd be all about a driver if he'd used BJTs instead of the FETS, or if he was driving really big FETs like I do for motion control and light dimming applications (10s -100s of kW). They make tons of sense there. Take the scope of the project into account...the driver just isn't needed here. And the +/-25mA current on the 74AC244 is the clamp current, where the chip says "oh shit" and stops the party. The operating current is a much mroe reasonable +/-8mA, with headroom for odd loads and capacitive situations, and with a 50mA package limit. It'd work fine, but like I said, in this particular application, it's not required. That's my only contention.
Oh, another thing. Do not put a resistor between the PIC and the MOSFET gate. Use a driver chip to translate the current levels. Cheap insurance. You're kidding right?
A resistor for gate isolation is just fine, especially for a low side FET drive. A driver chip would cost as much as the FETs, and is overkill to the extreme. In a perfect world, where money and time are infinite for design, it's easy to make anything better. For something like this, a little realism is in order.
My $0.02 on the design:
I've done something similar as a proof of concept for a customer...256 RGB LEDs (50mA/color, ~38A at full bright/full white) with 64 custom processors controlled by a big Atmel. It ran off a standard 600W ATX supply, and it worked just fine, no voltage dropouts at all. I don't think the ATX supply itself was the problem, rather the layout of the circuit. A normal ATX supply has rather good transient reacitve capabilities. Using a single power supply for an entire floor is likely the culprit. It looks like the run on each floor was about 60', and I highly doubt that he used the right sized wire for that run (25A @ 60'-> #8). The accumulated coltage drop would be pretty extreme, making the PICs low voltage brownout inevitable. Combine that with an improper power supply arangement at each processor location and bam, crashes. The 6600uF caps are a band-aid, I agree. A fat wire feeding the high sides of the LEDs, and a secondary wire feeding the PICs would be my choice. Yes, they can safely be tied together, but ONLY AT THE SOURCE. That long run of wire will be all the isolation they need. Standard long distance bypassing at the PICs will keep them happy (10uF/1uF/0.1uF) and a nice fat ground return keeps it all under control. There were a few mistakes, but by no means is it fatally flawed.
I work every day deisgning circuits and PC boards and working with mechanical 3D modelling (Solidworks and ProE). These things take up screen real estate like it's free, and my productivity depends heavily on being able to see a large area of whatever I'm working on on-screen at a high level of magnification. Big screens do that. Small screens do not. Right now, because of a job change, I have a single 19" LCD on my desk, and it's killing my throughput (but then again, so is/.).
More area is good for people who deal with visual work.
Lego Technics sets got me started with mechanics at a young age, and the book (my yellow covered, dog eared, marked up 1st edition) pushed me the rest of the way. I grabbed the books on the Rug Warrior from the MIT crew as a second step, though I didn't pursue them.
The Parallax BOEBot is wonderful too. it's a lot more expensive, but it's an all in one kit that can get you a light reactive robot in an afternoon.
A majority of CR123s aren't designed for contsant discharge at a relatively high rate. They are marketed to the photo market, where there are pulses of high power and long periods of very low draw. They do function at higher draws, but with reduced lifespan. This is hidden deep in the spec sheets, where the pulsed current recovery and discharge profile math is. I'm not terribly surprised that people have problems with lithium primary cells (NOT Li-po, Li-Ion, or any of the rechargable Li chemistries) in use for high current loads like the high power miniature flashlights out there like the Pelican M6 (the example cited in the second CandlePower link). The Xenon bulb version will suck the power out of a pair of CR123s in 1 hour. Calling the batteries 1300mAH (an average, according to Google), that means they're being loaded to about 1.3A each. That's a ~1C discharge rate. Most cells I found data sheets on didn't show a 1.3A discharge curve, instead showing a 1A curve or 1200mA pulse discharge measurement, using a 3s on / 7s off (30%) duty cycle. 10% can mean a lot in these cases. Odds are a lot of those cells are being used on the edge of or well past their design envelope. Beating up batteries like that can cause trouble, especially for cells that are fragile. Of course, not all are. The Energizer E2 photo lithium CR123 shows a capacity of 1.5AH and a 1000mA discharge life of 1.2 hours. It's probably the one used by Pelican to reach the rating of their flashlight, even if it looks like they did push the cells a little past their design limits.
Lithium primary cells generally do not have construction compatible with fast discharge. Often it can be gotten away with if the discharge is under 0.6C or is of a pulsed nature. Continuous discharge will kill them tho, a flaming, explosive kill.
Batteries have ever-increasing power densities, and deserve respect from designers. Just tossing 123s in is a BAD idea IMO. I was an engineer on a project where someone did just slap one in without consideration. When we put the test unit through its paces, blammo. Pulling 2A out of a 1.5A battery for 7 seconds is OK in NiCads and NiMH cells and even rechargable LiPoly prismatics if you know what you're doing. This was a dime store photo battery, and it went off like a small cannon after a few seconds.
People don't think about the design envelope for batteries as much as they should any more. It's unfortunate.
There are a lot of USB and FireWire sound output devices that are plenty good that use CoreAudio drivers. I'm particularly fond of the MOTU stuff. I have some older stuff kicking around that's not supoprted either, but with the mess that was the old driver system, I'm kinda glad to see the new stuff.
These days I use a USB to optical (TosLink) output adapter that I feed into an old DAC I have laying around. Much better than any of the onboard audio systems I've met, and it gives me total electrical isolation too (the TosLink cable is glass and plastic), so no more ground loop.
It's not as simple as the 2/6, but I don't have any complaints.
And no I'm not going to switch to a MAC. Emagic pulled the rug from under me once (just after I'd paid for an upgrade) so I Learnnt my lesson the hard way.
Actually, Apple bought Emagic and killed the PC version. Emagic didn't really have a choice once they'd been bought. The odds of Logic working on a Mac for a long long time are better than they ever were on a PC. Not to say you should get a Mac, just trying to clarify the history.
As for me, I'm still pining for the long gone Studio Vision Pro. Gibson...now there's a company to hate.
Well, the array size is governed by the memory cell size, but the actual storage geometry is governed by the controller. 500x8 was easier in my head than 250x16 when I was multiplying initially.
Power on time for the chips is significant WRT access time. 2-3mS as I recall. I don't have the datasheet handy at the moment though.
As for designing a big array, 32-128 of them is managable with conventional means, but getting to the levels of storage that HDs have makes it laughable. If I was actually going to design a system as large as I initially mentioned, well, there'd be racks with controller backplanes and inifniband or something for interconnects, not to mention 12 layer boards and (old school) Cray levels of hand optimization. Even then it'd be silly. I was just making it as obvious as I could;-)
I never tried to compare FRAM to MRAM. I'm an embedded guy, so FRAM is just fine for me. A 150nS cycle time might seem slow to the GHz crowd, but for the vast majority of computers on earth (the little ones no one pays attention to in their cars and STBs and phones) it's just fine.
As for the points: 1. They changed the process slightly, but that doesn't mean it's brand new news. I like the Freescale guys a lot, but touting it as a worlds first is misleading. 2. MRAM has had some very impressive scaling reported for a number of years now. Motorola poured an obscene amount of money into it back before they sold their memory businesses off and spun out Freescale. Even after all these years and hundreds of millions (if not billions) of dollars, we're only getting a 4Mbit chip. Plan on patience. 3. The day I can get a computer that uses no spinning storage and no volatile memory is the day I have the jack installed in my head. It'll happen eventually, I'm sure, but not soon and definitely not cheap. I'm betting military applications will drive it more than foreign innovation. 4. I talked about FRAM partly as a contrast (despite my fat-fingering the link to Ramtron), but mainly because it's what's on my desk right now. A few K of parallel FRAM storage for scratch space, and a couple of big I2C units for storage. 5. Of course. FRAM is for small things.
I'm not trying to be bitter or mean, but the chip isn't at all what the OP thought. It's for embedded systems, and I want people to recognize that.
That would be right on, but I quoted the CMOS sustained idle current. Write current jumps to 155mA, and read current is 80ish as I recall. Keeping the chips alive but idle is the easiest way to design the system. Switching the power to the chips required to store a chunk of data would require knowing the length and width of the memory required, and then knowing what blocks are free, and then powering on the required chips (with a huge current spike and associated noise), and then making the write. Designing the power switching infrastructure on that many sqft of PCB (damn TSSOP packages) would be impossibly problematic. The design of the chips isn't supportive of anything large scale...these are indeed for cellphone scratch pad use, or for NV storage in other small devices.
And remember, my numbers were only for a 500GB x 1 byte array. That's horribly inefficient. If they can bump the width and depth of the array up, then we can talk. Let's hope they scale it fast and well.
Freescale's MRAM technology isn't all that new...it's an old Motorola technology that they kept running with when they were spun off. It's taken them a few years to get going again, but it's already been done for a while.
That said, MRAM ain't a HD replacement yet. No one outside the aerospace industry is using it for storage right now that I'm aware of, and even if someone was, making a large enough FRAM based drive with 4Mb chips is HARD. 2 chips for every MB. 2048 chips for every GB. a 500GB FRAM disk would require 1,024,000 of these chips, requiring nearly 2,500 sqft of PCB space, and more power than a pile of overclocked P4s (~9mA * 3.3V * 1,024,000 chips = 30.4128kW at IDLE). Even if someone could build that, it'd be farking huge, run inconcievably hot, be incredibly power hungry, and sell for an obscenely expensive price, even for the most extr33m gadget hunters.
Wait for 32 and 64Mb chips. Then we'll talk.
Right now I'm too busy working with a serial FRAM from Ramtron to write more.
What makes you think we'd be able to fight back by the time we'd need to anyway? Between the chips in the head, the flouride in the drinking water, the CIA mind control waves, and all the other things the tinfoil hat brigade thinks are being used to take over the populace, we'd be screwed long before we realized it. I'm more worried about getting accosted by a member of the tinfoil hat club than fighting a patent like this. It's going to be a LONG time before this ever get near mass production. Things like it (and many, many simpler schemes for safety and accountability) have been on the drawing board for more than two decades, and yet only the most rudimentary steps have been taken toward ammunition fingerprinting and user lockout safety. The momentum of the industry and the strength of the lobby will prevent an overnight takeover by technology like this. Look how hard it's been to actually put a national ban on true assault weapons....full auto conversions are still easy to find and obtain if you know where to look, and suppressors can still be had legally with a $400 check to the ATF in a number of states.
Finally, the breech of most guns is a very tight piece of metal. Generating a signal to jam the bullet without setting it off would require a tightly focused beam down the breech of the barrel for most weapons. Only the plastic Glocks and their ilk that are so favored by law enforcement would be easily jammed. My 1911 would be tougher, at least if they were trying to avoid microwaving my right hand.
I'll worry later. YRO has more pressing matters. This needs at least 10 years to be marketable.
I seriously doubt that the practical implementation will be anything that touchy. The military has been using contact and induction programmed smart ammo for years in large calibers (the tests I'm aware of use howitzers and shoulder-fired guided missles). Honestly, I'm unconcerned about this. The lawful owners and shooters have nothing to worry about but the increased cost, and obtaining ammo for their grandfathered 'dumb' firearms. And yes, I'm an owner and a shooter. By the time I need to worry about things like getting smart ammo at the local sporting goods store, I'll already have a barcode on my neck and a chip in my head. There are bigger fights to fight.
Specifically, LiPoly packs explode in a shower of burning electrolyte propelled by gas (O2). This is a pretty well known phenomenon among the model airplane and helicopter guys that fly the little electric 'park flyers'. Overcharge a pack by even 200mV, and they start to heat exponentially. Keep going, and kabang, no spark needed (see overcharge explosion videos here or here.). Something as innocuous as a bad aftermarket charger (with the charger and pack management in 'fast charge' mode) or a partially failed onboard charge controller (seen plenty of those...due to bad chargers no less) can do that, if the charger ignores the charge meter data coming back from the computer for too long, and the local controller in the computer is designed to use a smarter or higher quality external supply (I've seen it happen before). The thing I've seen that distrubs me the most is the increasing use of LiPoly cells in packs that only contain a thermistor and a series PTC resistor for temperature monitoring and protection (like the old NiMh packs), relying on external circuitry to manage current and voltage protection. All it takes is a paperclip to turn one of those into a hazardous device. And for the record, most LiPoly cells use LiCoO2 or LiMn2O4 chemistry, without the OH-s we all loved from the NiMH and NiCd days (aka, no hydrogen, only oxygen, which is still very explosive in it's gaseous form)
I dearly love the power desnity of Li-XX batteries, but damn, be careful with them. They're nasty when you cross them.
Very obviously a LiIon/LiPoly/LiEtc battery explosion. They go off like small bombs when abused to an extreme (short circuit, overcharge). My guess is that something went terribly wrong with the charge controller, and fried the pack. The phenomenon isn't news, just that some other failure caused it. It's unfortunate that it happened, but it's a good lesson about why extra care is needed with volatile technologies. As a EE, I can say with authority that it's easy to design a very safe battery management system. It's when production cost reduction folks get involved and cut corners that things often go wrong, or when someone thinks they can optimize something without a full understanding
Slashdot Mirror
Innovation can be taught too. Ask anyone who has gone through the TRIZ process: http://en.wikipedia.org/wiki/TRIZ
It's not rocket science, it's a new way of thinking about problems and their solutions.
Some people are born with it, others are taught it. The results are essentially the same for all but the most esoteric and rare cases.
Heh...would that happen to have been one of the clubs involved with either a flying or wheeled machine? I have a vague recollection of that story...
Am I the only one who saw that headline in an RSS feed and read it as "Bad Meth Causes Explosion at CERN Collider", and laughed out loud at the office before realizing I'd misread it and feeling like a fool?
Or is it just too early in the morning for me to be posting?
I don't know what you do to your Hondas, but I've had 3 that have all lasted past 150k mi, and one that's going strong out to 200k, and can name at least 5 people with more than 200k on the original motor and transmission. The body is historically the weak point on H/A cars (rust), not the drivetrain.
Unfortunately, all it takes is a large rock weighing a few tons with a sharp edge to fall and cleave a cable that's laying against a flat rock on the bottom. I don't know precisely how the transcontinental cables are built, but the smaller ones I've dealt with for river and lake crossings are quite vulnerable. They're stiff as hell (don't react well to bending), somewhat brittle (don't react well to bending or crushing), and designed to be laid and buried, and never move again (don't react well to general movement). A sharp vertical motion could crack them, or a rolling motion could set them up to be crushed by flying debris (quakes can be very fast, even underwater, hence tsunami generation). There's lots of ways for a cable to die.
I think the core of your question is about giving away Windows licenses for free. We love developers, period. We're also not about to give away Windows client licenses.
I beg to differ. I think it's about tying IE so close to the OS (with WGA and limited version support) as to require someone to buy the latest version of Windows and a machine to run it on in order to continue to support Microsoft's broken browser. I'm sorry, but this is a bad answer. THe profit and market share motives were completely ignored, and shouldn't be.
If Microsoft was really concerned about the browsing experience, they'd bend over backwards to attain parity with the other browsers on the market WRT standards support. Acid2 is a nice test suite to show it. As a part time developer, I can say with certainty that the stuff they've fixed is nice, but it still doesn't come close to what's required for true partiy, and by that I mean the ability of a developer (me) to write a single document for the web that's rendered the same way by the 3 browsers I see in the top of my logs (IE, Firefox and Safari).
When they get there, I'll start listening. Until then...I trust IE as far as I can throw it's program manager.
I've spent more than my fair share of time in the field doing repairs due to blown transistors, failed drivers, and the rest. Every single failure (in an outdoor, harsh environment, intrinsically safe, and heavily abused embedded system for agricultire, which I'm using as an example here) was the result of amazing abuse of the output devices. Load dump spikes hundreds of times over the design limits, connecting 120VAC to a terminal marked 12VDC, lightning (which it survived with only one blown transistor out of thousands of parts), etc. Each and every time, the failures could have been prevented with proper protection of the I/O terminals and a little common sense on the part of the operator.
For an application like this, where the only connections to the outside world are power and network, it's a pretty safe bet that the LEDs won't fail and kill the drivers. LEDs, especially the high power ones, fail open in a blinding majority of cases. A failed open LED will present no killing load to the low side switch, and no killing load to the uC. Even if it failed shorted, the odds that it would take out both the FET and the uC pin, with a 1K gate resistor, are damn small. If I was designing a system like this for mass production in a harsh environment and it needed five nines availablity, then yes, drivers would be appropriate, along with load monitoring, optoisolation from the network, and a few other things. For a one off 6x6 hack, or even for a low buck small market (1-10k units) project, the simple limiting resistor is fine. I'd be all about a driver if he'd used BJTs instead of the FETS, or if he was driving really big FETs like I do for motion control and light dimming applications (10s -100s of kW). They make tons of sense there. Take the scope of the project into account...the driver just isn't needed here. And the +/-25mA current on the 74AC244 is the clamp current, where the chip says "oh shit" and stops the party. The operating current is a much mroe reasonable +/-8mA, with headroom for odd loads and capacitive situations, and with a 50mA package limit. It'd work fine, but like I said, in this particular application, it's not required. That's my only contention.
Oh, another thing. Do not put a resistor between the PIC and the MOSFET gate. Use a driver chip to translate the current levels. Cheap insurance.
You're kidding right?
A resistor for gate isolation is just fine, especially for a low side FET drive. A driver chip would cost as much as the FETs, and is overkill to the extreme. In a perfect world, where money and time are infinite for design, it's easy to make anything better. For something like this, a little realism is in order.
My $0.02 on the design:
I've done something similar as a proof of concept for a customer...256 RGB LEDs (50mA/color, ~38A at full bright/full white) with 64 custom processors controlled by a big Atmel. It ran off a standard 600W ATX supply, and it worked just fine, no voltage dropouts at all. I don't think the ATX supply itself was the problem, rather the layout of the circuit. A normal ATX supply has rather good transient reacitve capabilities. Using a single power supply for an entire floor is likely the culprit. It looks like the run on each floor was about 60', and I highly doubt that he used the right sized wire for that run (25A @ 60'-> #8). The accumulated coltage drop would be pretty extreme, making the PICs low voltage brownout inevitable. Combine that with an improper power supply arangement at each processor location and bam, crashes. The 6600uF caps are a band-aid, I agree. A fat wire feeding the high sides of the LEDs, and a secondary wire feeding the PICs would be my choice. Yes, they can safely be tied together, but ONLY AT THE SOURCE. That long run of wire will be all the isolation they need. Standard long distance bypassing at the PICs will keep them happy (10uF/1uF/0.1uF) and a nice fat ground return keeps it all under control. There were a few mistakes, but by no means is it fatally flawed.
Give me multiple large monitors. PLEASE.
/.).
I work every day deisgning circuits and PC boards and working with mechanical 3D modelling (Solidworks and ProE). These things take up screen real estate like it's free, and my productivity depends heavily on being able to see a large area of whatever I'm working on on-screen at a high level of magnification. Big screens do that. Small screens do not. Right now, because of a job change, I have a single 19" LCD on my desk, and it's killing my throughput (but then again, so is
More area is good for people who deal with visual work.
Greenspan's site with his side of the story is here, for now: http://www.freemyspace.com/
= brad+greenspan+myspace&btnG=Search+News
Other news articles with similar content: http://news.google.com/news?hl=en&ned=&ie=UTF-8&q
I started with the . It's not perfect, but the 2nd edition helped a lot, and the projects are decidedly garage oriented.
Lego Technics sets got me started with mechanics at a young age, and the book (my yellow covered, dog eared, marked up 1st edition) pushed me the rest of the way. I grabbed the books on the Rug Warrior from the MIT crew as a second step, though I didn't pursue them.
The Parallax BOEBot is wonderful too. it's a lot more expensive, but it's an all in one kit that can get you a light reactive robot in an afternoon.
A majority of CR123s aren't designed for contsant discharge at a relatively high rate. They are marketed to the photo market, where there are pulses of high power and long periods of very low draw. They do function at higher draws, but with reduced lifespan. This is hidden deep in the spec sheets, where the pulsed current recovery and discharge profile math is. I'm not terribly surprised that people have problems with lithium primary cells (NOT Li-po, Li-Ion, or any of the rechargable Li chemistries) in use for high current loads like the high power miniature flashlights out there like the Pelican M6 (the example cited in the second CandlePower link). The Xenon bulb version will suck the power out of a pair of CR123s in 1 hour. Calling the batteries 1300mAH (an average, according to Google), that means they're being loaded to about 1.3A each. That's a ~1C discharge rate. Most cells I found data sheets on didn't show a 1.3A discharge curve, instead showing a 1A curve or 1200mA pulse discharge measurement, using a 3s on / 7s off (30%) duty cycle. 10% can mean a lot in these cases. Odds are a lot of those cells are being used on the edge of or well past their design envelope. Beating up batteries like that can cause trouble, especially for cells that are fragile. Of course, not all are. The Energizer E2 photo lithium CR123 shows a capacity of 1.5AH and a 1000mA discharge life of 1.2 hours. It's probably the one used by Pelican to reach the rating of their flashlight, even if it looks like they did push the cells a little past their design limits.
Lithium primary cells generally do not have construction compatible with fast discharge. Often it can be gotten away with if the discharge is under 0.6C or is of a pulsed nature. Continuous discharge will kill them tho, a flaming, explosive kill.
Batteries have ever-increasing power densities, and deserve respect from designers. Just tossing 123s in is a BAD idea IMO. I was an engineer on a project where someone did just slap one in without consideration. When we put the test unit through its paces, blammo. Pulling 2A out of a 1.5A battery for 7 seconds is OK in NiCads and NiMH cells and even rechargable LiPoly prismatics if you know what you're doing. This was a dime store photo battery, and it went off like a small cannon after a few seconds.
People don't think about the design envelope for batteries as much as they should any more. It's unfortunate.
My US$0.02 as an engineer.
There are a lot of USB and FireWire sound output devices that are plenty good that use CoreAudio drivers. I'm particularly fond of the MOTU stuff. I have some older stuff kicking around that's not supoprted either, but with the mess that was the old driver system, I'm kinda glad to see the new stuff.
These days I use a USB to optical (TosLink) output adapter that I feed into an old DAC I have laying around. Much better than any of the onboard audio systems I've met, and it gives me total electrical isolation too (the TosLink cable is glass and plastic), so no more ground loop.
It's not as simple as the 2/6, but I don't have any complaints.
And no I'm not going to switch to a MAC. Emagic pulled the rug from under me once (just after I'd paid for an upgrade) so I Learnnt my lesson the hard way.
Actually, Apple bought Emagic and killed the PC version. Emagic didn't really have a choice once they'd been bought. The odds of Logic working on a Mac for a long long time are better than they ever were on a PC. Not to say you should get a Mac, just trying to clarify the history.
As for me, I'm still pining for the long gone Studio Vision Pro. Gibson...now there's a company to hate.
Osborn's Law:
Variables won't; constants aren't.
Thank the BSD fortune file on my machine at home.
Looks like they've gone and dashed our hopes for us ;-)
[We have] no intention to become a commodity MRAM vendor." - Saied Tehrani
from an Embedded.com article.
Well, the array size is governed by the memory cell size, but the actual storage geometry is governed by the controller. 500x8 was easier in my head than 250x16 when I was multiplying initially.
;-)
Power on time for the chips is significant WRT access time. 2-3mS as I recall. I don't have the datasheet handy at the moment though.
As for designing a big array, 32-128 of them is managable with conventional means, but getting to the levels of storage that HDs have makes it laughable. If I was actually going to design a system as large as I initially mentioned, well, there'd be racks with controller backplanes and inifniband or something for interconnects, not to mention 12 layer boards and (old school) Cray levels of hand optimization. Even then it'd be silly. I was just making it as obvious as I could
I never tried to compare FRAM to MRAM. I'm an embedded guy, so FRAM is just fine for me. A 150nS cycle time might seem slow to the GHz crowd, but for the vast majority of computers on earth (the little ones no one pays attention to in their cars and STBs and phones) it's just fine.
As for the points:
1. They changed the process slightly, but that doesn't mean it's brand new news. I like the Freescale guys a lot, but touting it as a worlds first is misleading.
2. MRAM has had some very impressive scaling reported for a number of years now. Motorola poured an obscene amount of money into it back before they sold their memory businesses off and spun out Freescale. Even after all these years and hundreds of millions (if not billions) of dollars, we're only getting a 4Mbit chip. Plan on patience.
3. The day I can get a computer that uses no spinning storage and no volatile memory is the day I have the jack installed in my head. It'll happen eventually, I'm sure, but not soon and definitely not cheap. I'm betting military applications will drive it more than foreign innovation.
4. I talked about FRAM partly as a contrast (despite my fat-fingering the link to Ramtron), but mainly because it's what's on my desk right now. A few K of parallel FRAM storage for scratch space, and a couple of big I2C units for storage.
5. Of course. FRAM is for small things.
I'm not trying to be bitter or mean, but the chip isn't at all what the OP thought. It's for embedded systems, and I want people to recognize that.
That would be right on, but I quoted the CMOS sustained idle current. Write current jumps to 155mA, and read current is 80ish as I recall. Keeping the chips alive but idle is the easiest way to design the system. Switching the power to the chips required to store a chunk of data would require knowing the length and width of the memory required, and then knowing what blocks are free, and then powering on the required chips (with a huge current spike and associated noise), and then making the write. Designing the power switching infrastructure on that many sqft of PCB (damn TSSOP packages) would be impossibly problematic. The design of the chips isn't supportive of anything large scale...these are indeed for cellphone scratch pad use, or for NV storage in other small devices.
And remember, my numbers were only for a 500GB x 1 byte array. That's horribly inefficient. If they can bump the width and depth of the array up, then we can talk. Let's hope they scale it fast and well.
Freescale's MRAM technology isn't all that new...it's an old Motorola technology that they kept running with when they were spun off. It's taken them a few years to get going again, but it's already been done for a while.
That said, MRAM ain't a HD replacement yet. No one outside the aerospace industry is using it for storage right now that I'm aware of, and even if someone was, making a large enough FRAM based drive with 4Mb chips is HARD. 2 chips for every MB. 2048 chips for every GB. a 500GB FRAM disk would require 1,024,000 of these chips, requiring nearly 2,500 sqft of PCB space, and more power than a pile of overclocked P4s (~9mA * 3.3V * 1,024,000 chips = 30.4128kW at IDLE). Even if someone could build that, it'd be farking huge, run inconcievably hot, be incredibly power hungry, and sell for an obscenely expensive price, even for the most extr33m gadget hunters.
Wait for 32 and 64Mb chips. Then we'll talk.
Right now I'm too busy working with a serial FRAM from Ramtron to write more.
There's a joke in here somewhere....mumble mumble Cindy Crawford mumble mumble Beowolf cluster mumble mumble Sports Illustrated mumble mumble.
I'm going to karma hell. I don't mind.
What makes you think we'd be able to fight back by the time we'd need to anyway? Between the chips in the head, the flouride in the drinking water, the CIA mind control waves, and all the other things the tinfoil hat brigade thinks are being used to take over the populace, we'd be screwed long before we realized it. I'm more worried about getting accosted by a member of the tinfoil hat club than fighting a patent like this. It's going to be a LONG time before this ever get near mass production. Things like it (and many, many simpler schemes for safety and accountability) have been on the drawing board for more than two decades, and yet only the most rudimentary steps have been taken toward ammunition fingerprinting and user lockout safety. The momentum of the industry and the strength of the lobby will prevent an overnight takeover by technology like this. Look how hard it's been to actually put a national ban on true assault weapons....full auto conversions are still easy to find and obtain if you know where to look, and suppressors can still be had legally with a $400 check to the ATF in a number of states.
Finally, the breech of most guns is a very tight piece of metal. Generating a signal to jam the bullet without setting it off would require a tightly focused beam down the breech of the barrel for most weapons. Only the plastic Glocks and their ilk that are so favored by law enforcement would be easily jammed. My 1911 would be tougher, at least if they were trying to avoid microwaving my right hand.
I'll worry later. YRO has more pressing matters. This needs at least 10 years to be marketable.
I seriously doubt that the practical implementation will be anything that touchy. The military has been using contact and induction programmed smart ammo for years in large calibers (the tests I'm aware of use howitzers and shoulder-fired guided missles). Honestly, I'm unconcerned about this. The lawful owners and shooters have nothing to worry about but the increased cost, and obtaining ammo for their grandfathered 'dumb' firearms. And yes, I'm an owner and a shooter. By the time I need to worry about things like getting smart ammo at the local sporting goods store, I'll already have a barcode on my neck and a chip in my head. There are bigger fights to fight.
Specifically, LiPoly packs explode in a shower of burning electrolyte propelled by gas (O2). This is a pretty well known phenomenon among the model airplane and helicopter guys that fly the little electric 'park flyers'. Overcharge a pack by even 200mV, and they start to heat exponentially. Keep going, and kabang, no spark needed (see overcharge explosion videos here or here.). Something as innocuous as a bad aftermarket charger (with the charger and pack management in 'fast charge' mode) or a partially failed onboard charge controller (seen plenty of those...due to bad chargers no less) can do that, if the charger ignores the charge meter data coming back from the computer for too long, and the local controller in the computer is designed to use a smarter or higher quality external supply (I've seen it happen before). The thing I've seen that distrubs me the most is the increasing use of LiPoly cells in packs that only contain a thermistor and a series PTC resistor for temperature monitoring and protection (like the old NiMh packs), relying on external circuitry to manage current and voltage protection. All it takes is a paperclip to turn one of those into a hazardous device. And for the record, most LiPoly cells use LiCoO2 or LiMn2O4 chemistry, without the OH-s we all loved from the NiMH and NiCd days (aka, no hydrogen, only oxygen, which is still very explosive in it's gaseous form)
I dearly love the power desnity of Li-XX batteries, but damn, be careful with them. They're nasty when you cross them.
Very obviously a LiIon/LiPoly/LiEtc battery explosion. They go off like small bombs when abused to an extreme (short circuit, overcharge). My guess is that something went terribly wrong with the charge controller, and fried the pack. The phenomenon isn't news, just that some other failure caused it. It's unfortunate that it happened, but it's a good lesson about why extra care is needed with volatile technologies. As a EE, I can say with authority that it's easy to design a very safe battery management system. It's when production cost reduction folks get involved and cut corners that things often go wrong, or when someone thinks they can optimize something without a full understanding