Dedicated Z-wave sites?

If the branch circuit has appreciable inductance, then when the current first increases and then abruptly goes to zero when the internal fuse blows, a small voltage spike could be generated. This could damage other equipment on the same branch circuit, but I have never seen or heard of such damage.

Yes, a failing incandescent lamp can cause a current surge if the filament arcs as it falls apart. That's been well known for years. Incandescent dimmer manufacturers usually handle the situation by inserting a small impedance in the output circuit to protect the solid state parts which, of course, act faster than the thermal fuse in the lamp.

General service inandescent lamps are gas filled and fused. That's because when gas-filled lamps were developed in 1913, manufacturers learned quickly that an arcing filament was bad for business as it caused lamps to shatter, bases to melt and sparks to fly around.

Terry McGowan

It's usually just a thinned section of the wire leading from base to filament.

snipped-for-privacy@yahoogroups.com

I knew that UK bulbs at 230V would arc and had fuses but until recently I didn't think it was a problem in 120V bulbs. Where is the fuse hidden?

-- bud--

The lead wire from the center of the screw base is a fuse wire.

The fuse is in one of the leads in the "stem" or glass support structure for the filament. If you take a lamp apart, you will see that there are different kinds of wire going from the base or cap up to the filament. The filament, of course, is tungsten. The support wires are Molybdenum, but they are welded to a wire of nickel-iron alloy covered with copper called Dumet which has the same coefficient of expansion as the glass which surrounds them. In one of the leads toward the cap, there is a fuse wire as well. It may be inside a tube surrounded with glass beads called ballotini which helps to quench any arc as the fuse opens. All lamps sold in the European Union must have a fuse which complies with IEC 432-1, a lamp safety standard. I don't know if there is a similar standard for the fuses used in North American lamps.

Terry McGowan

I don't think requesting proof for his more outlandish statements has anything to do with the kind of "stalking" that goes on here (ie. posting his BBB report, the "Grow up, Goofy" post and what you see as "typical" from Goofy Muderator and his many aliases). I'm fairly certain that if someone here were to infer you were a liar with nothing in the way of proof, you would ignore that individual which just makes you so much better than me.

All the garbage aside, here's wishing y'all the best of the holiday season and a happy (X-10 failure free) and prosperous New Year.

What are the physics of the mechanism(s) that would cause a INSTEON Lamplinc dimmer (TRIAC output device typical of residential US dimmers) to 'take out' lamps?

And why, as Dave thinks, is this "more likely" than the well-known phenomenon of a current surge owing to tungsten arc when the filament fails causing the TRIAC in the dimmer to fail?

... Marc Marc_F_Hult

Nonsense!

Be happy it wasn't a Z-Wave dimmer. Dave would have explained (with copious documentation) how RF vibrations blew the bulb. :^)

For the record, it spent basically 15 minutes getting CQC to run under Vista. Well, I spent four or five hours setting up a new machine and installing Vista so I could test it. Actually, I installed it twice because I screwed something up the first time. But, once installed, it turned out that there's a little tweak to .cmd file required to get the installer to run, something that I need to figure out how to do automagically so that the customer doesn't need to do it. And you have to run the installer via the file explorer (using the 'Run as administrator' instead of from the command line as most people do.) But that's it. Everything else seems to run just fine as is.

So it wasn't nearly as doom and gloom as you seemed to think it was. I figured it might take a code tweak or two, with a lot longer to figure out what to do than to actually do it, but it looks like none will be required at all.

--------------------- Dean Roddey Chairman/CTO, Charmed Quark Systems, Ltd

Easy, dude! We *were* talking about PCs and the things that make them stop working in *general* or at least one of us was! (-: I'm afraid you're taking my comments as slams against CQ, and they're certainly NOT meant to be. Along those more general lines, we were discussing driver problems and whether a typical end user had any way to tell whether an HA item he had purchased came with reliable drivers or "junk" drivers. I made that point because some of the buggiest, crappiest drivers and application software I have ever come across came from big name companies like Nikon, Panasonic and Sony.

As for gaming issues, didn't that signal we might *not* be talking about CQ exclusively? It would seem logical, though, that you might have CQ users that want to use CQ to be able to switch their game output from the PC screen to a large plasma screen and back. Might that not require talking to a video driver somewhere in the chain to control whatever's rendering the images for the screen?

My experience is that a Windows application program can NOT really isolate itself from drivers and code provided by others. This is an issue I find particularly relevant to HA and HT automation programs, simply because of the range of HW (from a *very* wide variety of manufacturers) that such programs are expected to support. From my perspective, HA and HT are perhaps among the most HW-centric applications on the planet.

Why am I "stuck" on this issue of drivers? We alluded to HomeSeer, if you recall, and their decision to begin offering "plug ins" for an extra fee. There was a lot of discussion some time ago about how that decision might have affected the overall quality of the product. While it's clearly only a guess, one reason they might have chosen to use third party plug-ins so was the sheer magnitude of the problem. There are so many devices needing "plug ins" or "drivers" (or whatever label one chooses for the SW that communicates among the application, the OS and the HW) that it's easy to see that the man doing the core programming might have trouble doing it all.

My admittedly faulty memory seems to recall that CQ did not follow that plug-in model early on but if I'm interpreting your help forum correctly, you also seem to have other people writing interfaces between HW and CQ, so the question seems pretty germane to me. I'm not certain, but it seems from this thread:

and this one:

that other people are writing drivers for CQ, too, or am I misreading that? If so, how does your schema differ from HomeSeer's use of plug-ins?

(The first above thread also tangentially makes a point I was making earlier. If you're very good at what you do, it won't be long before you're bought out, just the way Slim Devices was bought by Logitech, or forced out - we may never know the details.)

HomeSeer's use of plug-ins may have quite profound implications for CQ, which seems to be at least a few years and X number of users behind HomeSeer on the success curve. As you're painfully aware, the small SW startup guy has to wear nearly every hat: accountant, coder, marketer, secretary, documentor, tech support guy, mail room worker and more.

That's a *lot* of work.

Much of it can't easily be farmed out to others, even when the revenue stream permits because it's all so dependent on individual knowledge. All that you know about the HA field, about your particular program, about your particular SW techniques, about your clients and so much more does not transfer easily out of your head and into an assistant's. That's the age-old "keyman" problem I alluded to.

After reading through CQ's website and message base, I'm convinced that you've taken a lot more steps since last I looked to insure that you've got some assistance that's very well versed in many aspects of your business. That's very good and very rare in startups. CQ seems to have become far more of a group effort than it was the last time I looked, at least a year or so ago. Keyman issues have killed SW and HW projects both large and small so it's good to see you've addressed the issue more thoroughly than most. See, I'm not ALL negative, ALL the time. (-"

Part of my dubious attitude comes from starting out learning linear coding techniques and morphing through OOP. I'm still not certain that OOP has produced all the benefits that it promised although I'll grudgingly admit it has brought some. But who's to say what happened to Fortran won't happen to object oriented platforms five or ten years from now? There's a revolution coming in multiple CPU motherboards that's going to require an OS very different from anything the current Windows platform can deliver. A media-savvy home automation application program would seem to me something that would very much benefit from having multiple CPUs to handle decoding multiple video and audio streams.

Dennis talked about that but he also talked about the profound design changes in Vista that are going to seriously alter the way drivers are written and how they work. Vista represents such a change in a number of areas that even MS, the *authors* of the OS, couldn't get the new data-based file system working correctly in time for the initial release.

Forgive my skepticism, but even if you "roll your own" and avoid tight coupling to the OS by reducing your use of system calls, isolating an application from an OS is *very* tricky business. I'd liken it making sure the plumbing and electricity in the third floor of a house were working correctly even if someone remodeled and rewired and re-plumbed the entire first floor. The OS is the level you have to get through to get access to the HW unless something's changed quite profoundly since I studied the 7 layer OSI model of computing many, many core dumps ago. Physical, Data Link, Network, Transport, Session, Presentation & Application (I got 6 out of 7 correct from 20+ year old synapses!)

Correct me, please, if I am wrong, Dean, but I was under the impression that someone (most likely you) has to personally write a driver for each and every piece of HW that CQ supports? Isn't that task as limitless as the amount of HA and HT devices that a user might be expected to control? Doesn't it also involve making sure HW upgrades in devices that you control are reviewed to make sure they still react correctly to commands? I stopped buying Sony auxiliary control equipment because they could not standardize across model lines. It was in a constant state of chaos. According to this site:

"Sony has chosen to provide very little support for S-Link users or developers. An official site devoted to S-Link/VisionTouch developers was closed in April, 1997; since then, Sony has limited support to those enrolled in its professional developer program (which costs $5000 plus royalties)."

I imagine things have improved only slightly. (-:

Wow. I am impressed. You've never ordered something you've researched that says it works with "X" configuration only to find out it didn't? You never reviewed a specification document that failed to conform to the actual HW in hand? I see discussions about just such documentation deviations frequently here in CHA and elsewhere.

I'm glad you report you're untroubled by such things. I can't help noting that reading through your support forum about the problems supporting I-Tunes and I-Pods "gives me pause" as the Bard might say. How do you successfully put a wrapper around something that requires login, authentication and DRM control? How do you talk to a device where the maker has not revealed the internal protocols? Those seem like gnarly problems to me!

When CD-recorders hit the market there were waves and waves of incompatibility problems, from the low-level firmware in drive controllers to the recorders themselves to the recording software to the very blank disks themselves. For self-education, I just typed "Charmed Quark Problem" without the word driver into Google and the very first message I came across appears to be driver related. Simon from Surbiton, England had a Zoomplayer opening problem:

---------------------------------------------------------------------

Hullo,

I have three instances of ZP, one for movies and two for music. There are auto opening actions on the relevant templates.

If I go movies, music, all three open as they should. If I go music, movies, the two for music open correctly, but the movies one doesnt.

I dont get an error being shown on the app server, and if I enable action trace I get a Result=Success.

I dont want just to remove all the drivers for ZP and the app server without trying to figure out what might be causing it.

Any ideas please?

-------------------------------------------------------

Part of your one paragraph reply was: "are the CQC drivers correctly installed?"

That would at least lend *some* slight support to my contention that no software is immune from driver issues. I believe, based on experience, that driver issues are particularly troublesome in SW that controls the vast amount of disparate HW. Loads of very different HW from many manufacturers seems to be the norm in home theater, home automation and home security. I'm not trying to be a "nudge" here, I just can't help meeting your claims that you've insulated yourself from the things that trouble so many other software applications with a healthy dose of skepticism. When someone in a HW-centric field says they have no driver problems, it makes me want to learn how that's possible because it's so far out of my direct experience with such SW.

Speaking of drivers, in searching through the CQ support forums, I found what seemed to be an inability to deal with a customer's pre-existing MP3 library. Did I read that correctly? Is CQ, with its heavy emphasis on home theater, unable to import tagged MP3's correctly into its media repository? From what I could divine, you decided to support WMA rather than the MP3 format. Couldn't one say, if that's the case, that CQ didn't have any driver problems with MP3 files because it didn't have any drivers for them? (-:

Forgive me if this sounds rude, but you're not any typical user I know. If we reviewed, in detail, using system logs, what you've actually had to do to keep your machines running through various upgrades, we would find, I am sure, that you've taken care of some small "infelicities" that as a pro you'd barely notice, but that might stop some neophyte dead in their tracks.

Experienced users tend to minimize any problem that didn't stymie them for more than a minute or two. Inexperienced ones tend to call me (or someone like me) and say "I ran an auto update and now I've got a box on the screen asking me if I want to overwrite or keep File X because of . . . " Easy for you to answer that question, nearly impossible for them.

Microsoft's own list of problems created by the XP SP2 service pack upgrade

included Photoshop, Encyclopedia Britannica, Omnipage Pro and other programs such as:

? Multiplayer games and instant message programs that are used over the Internet. ? Windows XP SP2-based client programs that receive data from a server. ? Windows XP SP2-based server programs that respond to client requests.

So I guess I still don't quite understand how a client/server product like yours can truly insulate itself from the OS that's managing all the client/server traffic. More troubling, I can't see how a product that maintains a media repository isn't going to fall into the impending snake pit of digital rights management issues. Surely that has to be one of the issues facing you when considering support for I-Tunes and I-Pods.

You didn't have any issues with CQ or your machines when XP SP2 arrived or porting up from an earlier version? What version of Windows was CQ "born" under? As for your experience, that's a commendable data point, but that's all. Reading through support groups for HomeSeer, ADI and others would reveal other, incongruent, data points.

I'm all for research but it gets a little problematic in the modern age. By the time you fully research a PC, a newer model appears. To fully research a PC, you really have to be a PC expert. I consider myself just such an "expert" but I get fooled reading ads. The last one was a Fujitsu Tablet PC that "appeared" to have a network connector built in but all it really had was a network chip built it - you needed a docking station to connect to externally. Apparently, I wasn't the only one fooled, either. I noticed the same reports from one of your users on the CQ forum.

When I read through PC ads they're deliberately deceptive, hoping to pawn off a flat screen CRT monitor as a flat panel LCD display. As for Dell, you're one of the few I hear speak highly of them but as I've said before, these are all just data points that paint a larger picture. Maybe Dell isn't as poor at support as my friends have indicated. More likely, they're not able to support themselves they way that you can so poor support is more of an issue to them.

I think one of the problems we're having here is that we're talking about different things, or at least I *think* we are. I had (mistakenly) assumed that CQ was an automation program that an average user could deal with. Upon closer inspection, it seems to be clearly aimed at people who have fairly broad PC, programming, networking and configuration skills. I would say that it's probably a good fit for less than 10% of the people who stop by CHA to ask automation questions. That's not a knock, BTW, it's simply an acknowledgement that you're catering to a different crowd than, say, Activehome.

This is again, no knock, but how would or could we know that? We hear remarkable claims most every day here in CHA. In my experience, coding skills vary tremendously. I've known coders that can write super-tight assembler with executables so small and algorithms so ingenious that very few other people can understand their what the program does, let only how elegantly it does it. Often, they are truly people of few words, both codewise and wordwise. Documentation has to be forced out of them, often by means of coercion. ;-)

Other coders are superb virtualizers. They can trace simultaneous execution of process threads in their heads the way Beethoven could the various musical instruments. One of the ones I used to work with, Ygal, liked to play simultaneous chess games during his lunch hour with up to eight other opponents. He rarely drew a game, let alone lost one. I have great respect for people with such talent because they are very few and far between.

I'm not sure I recall all the detailed technical explanations of your cross-platforming features. I'm not sure what you've learned about marketing, but most advertisers know they have to repeat their meesages often if they want anyone to retain what they've been told. So, sorry, Dean, but I don't feel very badly about not recalling the details of a program I'm not ever likely to buy.

I do remember being surprised that a program that strove for such a high level of abstraction from the OS did not support other platforms, like Linux and the Mac. Or did I get that wrong? If you don't support Apple or Linux, does Apple's switch to an Intel CPU have any impact your future plans?

A lot of *very* smart AV people I know are heavily invested in Macs. The I-Pods and I-Tunes have incredible market share, AV-wise. I'd be interested to know how you incorporate such devices into CQ without having to deal with some very knotty digital rights management (DRM), driver and networking issues.

I'll readily admit being able to insulate yourself from serious changes in the underlying OS is nice, even if it's only from slight version changes in Windows. The problem I have is that my experience tells me that no matter how a programmer tries to insulate himself from the OS, the success of his efforts lies in how many OS upgrades he's survived, what the OS manufacturer has changed and the plain ol' luck of the draw. How many OS revisions has it been for CQ?

NASA puts loads of safety systems in place to prevent failures, but they still have them simply because unanticipated stuff happens and safety nets fail.

"No changes in the code" could be misconstrued. Who writes the virtual kernel for the new OS? (-: By using another layer of abstraction, you're simply moving the difficult interoperability issues to a different software layer, but the issues still remain.

It almost sounds as if you've built an OS for CQ within the Windows framework. While that might not be a workable solution for other fields, perhaps because of HA's relatively relaxed CPU requirements, the performance hit it would seem you would take re-creating system utilities and services embedded in the OS might be worth the gain in reliability. If, as you say, you have problems if another device chooses an IP address already in use, perhaps you're not as insulated from the OS as you'd like to be.

It would seem to me that an object platform created for both Windows and Linux would be a valuable thing to leave that way. Why did you decide to limit your implementation so it only runs under Windows? A limit to how much HW can be virtualized? Networking issues? Driver issues? (-:

That tends to assume there would be some |I've worked for almost five years now for almost nothing (average of less |than $10K a year, while spending over $40K of my own money, which was all I |had, and another $40K of Mark's money.) It will probably be another four |before I could even begin to consider buying a house so that I could even |have a mortage to pay, and moving out of this tiny, one bedroom apartment |and stop having to work 7x12x365.

I know it's the God's Honest Truth because I've seen it so many times before. I consider working 80+ hours per week a serious danger sign that you're not leading a terribly well-balanced life. If you're a very good programmer (that's hard for me to evaluate without looking at your source code) that can write complete, intelligible English sentences as well (that I *can* evaluate!), then you know that you're being seriously underpaid for your talents by a factor of ten. You also know that your friendship with someone is now tangled up in money and expectations of future profit. I found a business partnership to be just like marriage only with more headaches and heartburn but without the sex and affection. (-:

If you were working for me in a corporate setting I'd immediately flank you with a junior programmer and an AA. I'd make you take your vacation time for one thing, and might even put you part-time on another project to encourage the junior programmer to *really* step up to handle the load instead of just coasting behind you. Oddly enough, you'd probably come back from two weeks in Aruba with a whole raft of new ideas that came to you once you stepped back from the daily ground.

Why would I do this? Because a single person, grinding himself up slowly but surely with no other life but the love of his project, is creating something no one else can take over, no matter what the inducements. Your devotion to CQ is quite admirable, but it's likely to be very hard to find in another person. In my business, managers are rated on the success or failure of their projects. When I was in grad school, huge SW projects were failing left and right. Most management education at the time was geared towards recognizing what caused such large, apparently well-thought out and well-funded projects to fail. Burnout was an important factor, but ironically enough, so was lack of motivation. I wouldn't worry about that, though, motivation is something you independents have in large quantity!

Well, you're tense about something. While CQ may be immune to some of the issues plaguing Windows users, I assure you things are not well in Windows land for a lot them. I wish I can recall where I read a study that claimed that more than 50% of people surveyed feel they should get a lot more life out of PC's than they do. The claim was that naive end users are replacing their PCs frequently because it's the only way they know how to free themselves of spyware, adware and other anomalies.

In CHA, we're almost all in the upper percentiles when it comes to PC knowledge. I'm a little clearer now about your intended market so my concerns are fairly moot. People who can't set up a Windows network won't be using your product so I assume your users do know how to select drivers and perform system backups, etc.

Please, Dean, you don't really want to go on the record saying CQ has no driver issues. It's so easy to disprove it's hardly worth Googling again. The first message I found and quoted above was a driver problem. There's a thread going on right now about Z-wave's slow response in CQ because of a . . . (you guessed it!) . . . a *driver* issue, isn't there?

This is exactly what I meant by you appearing to be getting tense. What dog do I have in this "fight" compared to you? None. I'm not obsessed with CQ nor driver issues nor whatever things in my "imagination" that perversely speaking, you appear to be imagining are there. We see at least a dozen new HA programs announced here every year. It's up to you to tell us why your special. You're the one selling something, not me.

As for "imaginary problems" I've done a lot of PC support over the years. The problems I reported are well-documented throughout all netdom. No one ever said your product wasn't a quality product. To imply I've said so simply add weights to my observation that you seem tense and frankly quite defensive. I've been primarily trying to find out how a program that controls HW insulates itself from HW driver problems as well as you've been implying. I've been reading, as noted, comments about your Z-wave driver and how much you had to slow it down to make it communicate reliably. In looking for that URL, I found some more driver issues:

JRiver Media - XML file issue, driver won't load First Big Problem: Driver wont connect to DVD-5900 Homelink 1132 USB X-10 Driver Issue

As for interest in your product ramping up, I suspect, from the little economics I retained from grad school, that doubling the price of your product is going to flatten that ramp quite a bit, but economics is a soft science. Maybe those cost v. demand curves were all wet. (-:

I think my comments are far from "incomphensible" - I think they're very comprehensible; it's just that they're not very comfortable. To say that neither Windows nor CQ has driver issues strains credulity. That's why I pursued such comments so vigorously.

More importantly, you seem to be taking this all quite personally, as if I were talking *solely* about CQ. I would have thought it was quite clear when I wrote about video drivers for games, version upgrades from DOS to WIN3.1 you *must* know I am talking about the state of Windows, SW development and the PC industry in general. Yet you've taken those generalized observations and taken them as direct criticisms of CQ. I assure you, they were not. I simply assumed you'd be interested in discussing how CQ is built better. If I were to play amateur word psychologist, I'd say you were "frustrated" somewhere or somehow, but not necessarily here and now and by me. (-:

I don't think there's a user out there who hasn't been gored by driver issues, upgrade issues or network conflicts. You said it yourself a few messages back:

|The downside of course is that IP networks for the home have to get a lot |smarter and self managing. As the vendor of a networked automation product, |we have a fair amount of problems that are not related to our product but to |the network itself. It's too easy to get two machines on the same address, |or to mess up network settings or DHCP settings, or firewall settings and so |forth.

Perhaps the vendors of those products see the conflicts as arising from

*your* end, not theirs. At least that's been my experience. Vendor A's support almost always tends to blame Vendor B's products for whatever problems arise and vice-versa. As the author of NOOKs pointed out, (the topic that I really wanted to discuss!) the problems may be in the OS, but the solutions can be achieved at the application layer if the OS can't be made smarter. It sounds like that's what you've done in CQ, but it's hard to tell from your response.

Perhaps a truly bulletproof HA system *could* resolve the network conflicts that a "stupid" OS like Windows allows to happen. Perhaps the whole IP addressing system needs to be scrapped in favor of a "one device, one number" system like Ethernet MAC addresses where you really, really have to work to get two NICs reporting the same address at the HW level.

-- Bobby G.

notminor cosmetic polish, either.

Rest of 634 (!) lines deleted

Bobby:

Some restraint is required if one is to be successful.

One can break any PC ever built and one of the most dependable ways to break a PC-based instrument controller like a HA PC is to also use it to run games. It has always been this way. Remember the USCD-Pascal-based Flight Simulator which took over the whole PC?

The temptation to keep adding programs and hardware and drivers to a PC is great. Here's a photo of a part of my mobile environmental research lab ca

1989 with a early backplane 80386-16 running software I wrote to control a gas chromatograph with multiple detectors, and a mass spectrometer, and valves and pumps and temperature and pressure and flow sensors. 's%20GC%20setup.jpg Do you think that I also ran games on it?

... Marc Marc_F_Hult

I'm sure I've already explained this, but just for the fun of it... HS allowed people to write plugins in any language they want, and to pretty much do anything that the system allowed. CQC doesn't allow this. We have a strictly defined driver architcture and they can only write drivers in our PDL or CML languages, which means that we control how drivers are structured and what they have access to. We brought forward all our existing drivers to our 2.0 release without trivial effort. HS took years and still hasn't gotten them all moved forward.

OOP is the only way that our system could exist. It wouldn't be remotely practial to write this system any other way really. It would be too fragile and require far more resources than would be reasonable. OOP exists at two levels. One is the way you often here it waved around in the press, which is that you'll magically plug in software for various vendors and it'll all work. It can be done, but it's very difficult. We use it in a completely different way, which is to create a very powerful single OO framework that is all built as a system to work together. In that way, OOP is every bit as powerful as it is made out to be.

You making contradictory arguments. You argue that drivers are a problem because of errors that destablize the system, but you then argue that Vista is horrible because it changed the driver model in order to fix this problem. Yes, it will be painful in the sort term, but the long term advantage will be less problems with drivers because they'll be less able to destablize the system.

From our business standpoint, this isn't much of a problem, for reasons I've already indicated. Vista isn't a necessity for our customers any time soon, because there's no aspect of Vista that is immediately required. So there's not a problem to give it time to work itself out.

The whole point of the OSI model is that a layer CAN change without affecting the overall stack, because there are well defined interfaces between them. People write code that runs on completely different operating sysetms by using the same basic concept, i.e. of encapsulating the specifics of the OS so that their own code runs in terms of their own interfaces.

No, I don't know have to write those drivers. There are currently probably about as many third party drivers as those we have written. We want to write the ones for the things that are most important to us from a business standpoint. But if some user has a less commonly used driver, they are free to get some third party to write it for them.

There are no 'problems' supporting them. We just haven't done it yet. You put a wrapper around a device that requires login and authentication by having the driver login. This is already something that is commony done with security systems that are automated. The driver just logs in itself.

And these issues have zero to do with device drivers or OS problems or anything else. Obviously someone could create a device that's practically impossible to interface to. If so, then it just won't get sold to people who want to automate their systems.

I was just asking if he'd correctly installed the drivers, which he might not have because he was trying to control multiple instances of Zoom Player, which has some special considerations. So, no, this does not in any way support any of your conclusions really.

We are not trying to compete with J.River. We are more interested in competing with Escient and Kaleidescape. So we've not really made any effort to improt existing tagged content. We work in terms of actual discs at this time. It has nothing to do with drivers, it has to do with business decisions as to what we are trying to accomplish.

Any system whose DRM doesn't allow for external control will not end up in automated systems. If it applies to us, it'll apply to any competitor as well, generally speaking, so it will be just a general issue. But the folks who sell the content want to sell it. So DRM systems will accomodate automation systems over time. The AACS system used in the HD world has the ability to provide for systems like ours, actually better than DVDs do and legally, though they've not finallized how it's going to work yet.

No. I didn't. CQC started on W2K. It required no changes for XP other than a small change to ignore some graphics system errors that are caused when the system is locked. It now runs on Vista without any problems that we can see. It took me about 15 minutes to get it running on Vista, as I pointed out in another post. So your predictions of doom and gloom were a few hundred miles off base. I explained clearly why it probably wasn't going to be an issue, which is our abstraction from the system. I guess you have to be a software engineer to really appreciate what I'm saying, but take my word for it, it does work.

It clearly is a system targeted at automation professionals. That is true. But we have plenty of non-technical DIY customers who have created their own setups. They do have some spinup, much of it nothing to do with CQC.

As mentioned above, it took about 15 minutes. I spent 4 or 5 hours setting up a new machine and getting Vista installed (two times since I made a mistake first time and wanted to start over and change the drive configuration.) Then it took about 15 minutes to figure out the new rights management system and get the installer to run. Once the installer ran, everything else is working as is.

The difference is software engineering relative to some other companies.

There is not business argument for doing so. It would require a lot of extra effort (much of it nothing to do with software), that wouldn't bring in any substantially new amount of revenues.

We would deal with the DRM issues, which are easilly dealt with with iTunes (witness the many systems that incorporate iPods, so clearly it's not a problem.) There are things like the iPort that provide a well defined interface to interact with the iPod. And systems like the Russound, which we have a driver for, also incorporate iPod interfacing.

If you count the underlying object frameworks, it's been through OS/2, to NT, to XP/W2K, now to Vista.

No changes to the code means that nothing outside of the virtual kernel layer changes. Yes, a new layer (actually half a layer) needs to be written for the other OS. But that's less than a percent of the code base in size.

It doesn't 'recreate them' for the most part, it just encapsulates them. The layer is actually not very large at all, and in the context of a modern PC the overhead is minimal. The IP port issue has nothing to do with OS encapsulation. It's just a side effect of the world wide adoption of TCP/IP as the networking standard. It is not very well designed in this particular area.

Unfortunately, the real world doesn't work that way. You have to put in the time if you want to make it. I'm not going to burn out, because I don't even consider it a job. It's my life. I'm well designed for this type of life actually. I've been doing it for over a decade now, and I'm not burned out, and don't think I will.

What will burn me out is when we do actually bring on those other people and the company starts growing. At that point, the company won't depend on my anymore, but I'll find it much more stressfull than what I'm doing now, which is actually a pretty pure endeavor in which I have no one to argue with or be disappointed by but myself.

You read these things without understanding them at all, so I find it hard to even respond to them. You keep changing the argument to fit your needs of the moment. You talk about Windows drivers, which I said we don't have much problems with. Now you are talking about our drivers, and you don't understand what you are reading because you don't understand the context. I complain a lot about Z-Wave, because Zen-Sys changes a lot for their SDK and we don't own it, so we are restricted in our understanding of the Z-Wave system and have struggled to get it happy, particularly early on.

This has absolutely nothing to do with anything you've been saying. It's just a lack of information which has made it difficult to get a paritcular device interface as good as it should be.

Let's take a vote... Does anyone here think that Peter's arguments are comprehensible?

-------------------- Dean Roddey Chairman/CTO, Charmed Quark Systems, Ltd

I don't know how a discussion of driver reliability morphed into a belief that I want to run games on my HA PC, but that's not the case. For review:

I noted an article on NOOKS, that talked about 85% of crashes in PC's being the result of bad drivers.

I mentioned games as an application that caused video drivers, in particular, to be very heavily stressed and that caused bugs to be found and new drivers to be released, sometimes as often as every week when a video board is new. I had hoped that would have been a cue that this discussion was about driver issues, and not about CQ.

The same problems facing video drivers happen to be true for motherboard BIOS's when a new board is launched. As the boards leave beta testing and reach the real world, loads of problems begin to surface, many of which have to be fixed by rewriting the BIOS code.

When a manufacturer changes drivers or firmware frequently they often break something that was previously unbroken. That means there's a possibility that other programs depending on previous versions of that driver no longer work as expected. I used the example of video drivers used by gamers because those drivers get worked so hard by so many people in such a short time span that errors that might languish undetected for years in other types of drivers are quickly exposed.

From what the professor who developed NOOKS wrote, it's the driver bugs that only appear under certain circumstance and combinations of factors that are the most insidious. Truly bad drivers are shot down right away and fixed. Intermittent bugs, especially related to specific hardware interactions, are very hard to find.

It seemed to me from the discussion about I-Pods and other devices on the CQ site that CQ has at least *some* of the same issues with drivers that nearly everyone else has. It's not a slam against CQ, it's just what I consider a SW development fact of life. Often, one can divine where to "hook" into a program or device without having that program or device's source code. We've seen protocols reverse engineered right under our very eyes here in CHA. However, unless those protocols are in a manufacturer-sanctioned document, there's always a danger in writing an interface that "appears to work" with, let's say, the current generation of I-Pods. It may not work with any new ones.

You're old enough to remember how important this concept was to the competitors of IBM mainframes way back when they all sued to be able to make "plug compatible" computer equipment. My mainframe buddies tell stories of how IBM gave just enough information to satisfy the consent decree, but not a byte more. Sometimes, the information they provided was so inadequate that they were dragged back to court to make their systems accessible. Now, Microsoft is apparently carrying that anti competitive torch for them. (-:

From what I recall of a recent discussion between Charles S. and Dan L., even manufacturers seem unable to stick to their own published protocol or at least have produced conflicting documentation describing it.

-- Bobby G.

The problem we have with your arguments is that you continue to state the obvious (of course when you connect too things together there's a possiblity that it won't work and you'll have to figure it out) and act as if this is the end of the world, when in actual fact these same systems that you are discussing are running most of the world. Yes, anything that works now can break in the future. Yes there can be incompatibilities. But you continue to just go on and on about how impossible the whole situation is and how I'm going to die or burn out or be totally overwhemled by something that ended up taking a few minutes. It's pretty Chicken Little really.

Certainly there is room for improvement, as there is in any complex system. But, in the meantime, the realists get on with making what we have work, and it can be made to work very reliably if you know what you are doing. If you don't know what you are doing, then then you take your chances, or you get someone who does know what they are doing to do it for you.

And no, as I explained, the IPod and other devices that you quote are not of the same ilk. The I-Pod isnt' a problem, we just haven't gotten around to even starting on it. That's all. The Z-Wave discussion was just that we were limited in the information we had and therefore it took some experimentation to reach the correct compromise if speed vs. system integrity. Getting information was initially quite expensive because they assumed everyone wanting the SDK was a hardware developer and charged a lot for it because it included various bits of hardware and they assumed a lot of support costs for hardware development.

Anyway, bottom line, the computer industry isn't enormous for nothing. It can deliver and deliver reliably if you take the time to know how to do it right. It's no different than a car. Most people don't understand or maintain their own cars, therefore they either take them to professionals for that work, of the car eventually breaks down. But, somehow, people continue to drive cars and the automative industry makes a lot of money around the world.

--------------------- Dean Roddey Chairman/CTO, Charmed Quark Systems, Ltd

And if you don't run the games that 'stress' the video drivers that cause the crashes (HA apps don't or shouldn't), where is the problem? Don't run 'video-compute-intensive' apps on production servers, scientific instrumentation, or HA controllers and the 'problem' disappears. Stick to a $50, fanless, plain-Jane video card and the problems you cite disappear.

Reality check. You wrote that new MB's have bios updates as often as weekly. I have at this moment 7 PC's running. The only one that has *ever* had a bios update is an 11-year-old Thinkpad sold with W95/98 that needed a new BIOS to run W2K (which wasn't successful and IBM lost a class action suit over).

(Yes, I have had other PC's for which I did update BIOSes on -- for example, the first dual 1ghz Pentium III Tyan MB was a nightmare I won't forget. I bought it before the 1ghz chips were shipping. But I also bought a 1975 Pinto new ... nuff said ! ;-)

As I have written before, my experience in running CyberHouse HA SW

24x7x365x7 years is that IT DID NOT crash, or freeze, or hang, or have any of the problems that you seem to want it to have. I can't change my experience. I have also run scientific instrumentation that I built myself to run on PC when the MS OS _was_ notoriously unstable and succeeded even that problematic environment by *active* problem *avoidance* .

Does the manufacturer sneak into your basement in the dead of night and change out your video bios? Or do you cause the problem by applying every patch and update that comes along, needed or not? And what you write is universally true of _all_ computer code, firmware or not. It shouldn't paralyze one.

ROTFL. And "there's a possibility" that a problem that does not happen is not a problem ;-)

And there is no need to find the bugs if one doesn't use the particular, troublesome hardware involved because the bugs don't actually exist in one's hardware instantiation except as a hypothetical.

I found my spread sheet for the configuration of the instrument backplane

80386-16 that I referenced in my previous post. It all came back in a flood of nostalgia ;-) : multiple DAQ and PIO cards, four serial, two parallel, bus-mouse, IEEE-488, HP-IL, mono and SEGA video cards and more -- it took me forever to get all the interrupts and I/O addresses and drivers configured, working and stable. But I did. Do you think I loaded a new driver or replaced the BIOS chip jist because a newer version was available that fixed a problem with hardware that I didn't have?

... Marc Marc_F_Hult

DR> Let's take a vote... Does anyone here think that Peter's arguments are DR> comprehensible?

Geez, Dean, who the !*^& is *Peter*? (-:

I rest my case that you're underpaid and overworked. The underwhelming number of votes received indicates it's probably time to put this thread to rest, anyway.

So let's start over. I'm Robert and not the person, BTW, who talked about "gouging" earlier on in this thread (he's not Peter, either, FWIW). I think that comment marked the moments when the message flavor sadly turned a little sour. I believe you, as the vendor, can set any price you think fair for your product.

Gouging is when insurers report record profits yet raise rates through the roof because of the media attention to Katrina and other events. Gouging is when Big Oil raises prices way out of proportion to the damage caused by Katrina and report record profits even as they request more federal incentive money. Gouging is the retiring CEO of Home Depot getting 200+ million bucks. Imagine how much better off the stockholders would be if they spent that money paying bonuses to managers and employees who performed above and beyond the call of duty?

But I digress. You're certainly not gouging anyone. If anything, you're probably still seriously undercharging for your efforts, based on the time and effort you've obviously put into CQC.

-- Bobby G.

That was Bill Kearney but I didn't get the impression he was referring to Dean or any other participant in this newsgroup. I may be wrong but I thought it was more of a rant against some other vendor(s).

Agreed. However, the one who determines the value of a product is the buyer. I happen to agree that Dean is over worked and under paid. :^)