Quoting Robert Rolf : Ok, I kept silent up until this point, and found I have a few tidbits to offer > Unfortunately my installing one lousy USB > device cost me a HUGE amount of grief. Is there no quality & > performance 'certification' requirement (like XP's logo) before > someone can put the USB logo on a product? no, it's just a matter of paying whatever royalty payment goes to the USB people, hence the crappy designs PS: don't take the XP certification for actually meaning anything... > > > > It will be a cold day in hades before Samsung gets another > > > dollar out of me. > > > > Don't blame USB: Blame Samsung. > > I do, but I also hold USB standards body accountable for allowing > them to use the official USB logo on a product with a badly > flawed installer/driver/. they're not responsible. it's entirely samsung's fault > Consumers expect a certain > level of 'fitness and merchantability' in a product, and ever read the EULA ? if it doesn't work, they don't give a **** > I didn't get that. If it says it does Win98, I expect it > to -work-, not take down an otherwise very stable system. lots of people think otherwise of windows > > Don't bet on Firewire being that much easier. And of course, you can't > even > > get into the Firewire world without being able to handle that 400Mb/Sec > data > > rate. Certainly more expensive then the 1.5Mb/Sec or even 12Mb/Sec of USB. > > Of course. > I think the problem is one of USB trying to be too > many things at once. Firewire was doing nicely handling > 400mps streams, while USB covered the slower devices with packets. > USB 2.0 uses 480mps signaling, but the overall throughput is > lower. This doesn't seem to be an advantage. you can get firewire as a VHDL/Verilog IP to burn in a programmable logic chip > Unfortunately the 2nd part, 802.11 (they haven't decided on > which letter) is going to be a PITA. Nothing quite like dictating > a solution without their really understanding the problem. ok, that seems a buzzword induced requirement... one thing. Cellphones and other RF-inducing devices are forbidden in most hospitals, by fear of interference on other devices. I don't know how your boss could have some sort of waver for that... > He actually said 'I don't know what hardware/software you'll need to > use, but the solution should be quite simple'. > If he doesn't know WHAT I'll need, how can he tell me that the > solution should be 'simple'. no, there's *no* way the solution will be simple. > Nope. Comms need to be 'robust' since it's setting values in > a medical device. I must validate my data on top of the basic CRC > protection. And that doesn't even -begin- to cover the FDA > certification of software issues (which I leave to the deep > pockets people). This is a classic misconception. what you need to validate the data is easily done, if you use some form of cryptographic signature on the packets (a cryptographic hash should be enough). however, there is one big problem that your (stupid) boss hasn't foreseen in his complete ignorance of technology : 802.11 is a radio transmissions standard. as all radio transmissions, anyone close enough to receive the signal can read what you say, hence read that medical data. also, anyone could modify the devices values by crafting a program similar to use and wreak havoc on the whole hospital/practise. this means, you'd need to use strong encryption (RSA/AES) with authentication by certificates (read, integrate openssl) in the device. > A new job? > Suggest that they contract it out so they'll believe me > when I say it's very difficult? > > > What processor do you have in your instrument? > > PIC 16F876, with about 2k to spare. Obviously have to > go to one of the 18F devices to get the code space. > > It's also running slow (1.8432Mhz) to conserve power. > I could theoretically run it at 32khz were it not > for the need to stream data. It straps to a leg so > it has to be light, and very power efficient (except > with streaming). also, the 802.11 stuff is *very* power hungry. not a good solution if you ask me... > > What OS, if any, does it run? > > ASM. Timers and comms interrupts mostly, with a bit > of A/D and DSP filtering. you *so* need to use a much more powerful processor (arm something comes to mind) and some form of embedded linux or e-cos, it's not even funny. you're looking at a $300 cost increase or so per device... > > Thank you again everyone for your patience and help. > > Robert > You're welcome Amaury PS: sorry for the bad news ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body