Hi Jeff and Rado -

Interesting discussion. The push to standardization is due to large company desire for stability. But it is not only they, but the medical facility themselves also desire this stability. Medical facilities, barring research facilities, are pretty allergic to supporting N different communication schemes. While most infrastructures are capable of supporting the multitudes, the people running those infrastructures must provide support for them all, and trying to understand impacts of various communication schemes becomes every more complex. It's much the same stance as company IT departments who don't want to support non-standard equipment or SW for the vast majority of people (I *do* take exception for R&D personnel and machines, and believe that companies should be prepared to support R&D separately).

DDS is highly attractive from so many perspectives - the toolsuites for them are quite robust and attractive and cost no more than Visual Studio/MSDN subscriptions. So device companies will be better able to develop and deploy systems. Such tools often have multiple modes, allowing novice to expert developers to participate. Compare this to less mature solutions which often require advanced expertise, or heroic efforts to implement. So, this becomes extraordinarily expensive from a business perspective - you may only need one or two experts, but what if they leave (for any reason )? Now what?

Now, you may think that I'm a dyed-in-the-wool corporate weenie. I can tell you that I'm as much an early adopter as the next Linux geek - having been involved almost since its inception - and a huge open source proponent. I have architected an embedded Linux medical device using the yocto distribution builder. However, I learned after 25 years that playing the "I can write that program in N lines" game doesn't play well in most companies - barring startups. Learning how to navigate in a company is just as important as knowing how to write pristine code.

So, by all means, investigate, but be prepared to be *scrupulously honest* in representing your results, and cover far more than how a solution is less complex, faster, or how "anyone who knows anything about programming" can do the implementation or support it after you have moved on to the next project or company. Be sure to show how using the technology you're championing can be supported by a team comprised of the average engineer, plus one or two experts. And be sure to include a plan for sequestering and patching/updating the technology so that products dependent on it don't get stuck with unsupported versions and become vulnerable from a security perspective.

Of course, as you two have already mentioned, sometimes there's no choice but to venture off into the unknown to get a project delivered. And hell yes, that's fun! :)

Best Regards,

Paul

Seems that you could clone the source PB840 classes and modify them to read all the parameters and publish them. I'm thinking that this would entail the serial driver and the DDS writer, including the IDL for the DDS.