Someone on Youtube had what I thought was a clever solution: a piece of trim (looked like shoe molding) to bridge the 1" step. Cheap, and they claimed 100% effective.
> It also is very sensitive to resistance, to the point that I actually had to construct ramps for my car to climb the 1-inch lip at the entrance to my garage, otherwise it would stop at that point and refuse to go further.
The pictures of the car in a article linked elsewhere in this discussion (https://www.ksl.com/?sid=39727592&nid=148&title=utah-man-say...) show that the windshield was smashed. I'm finding it challenging to reconcile your personal example with the images of the smashed windshield; in my own experience, it takes some effort to break laminated safety glass. I would think (perhaps wrongly) that it would take more effort to break safety glass than would be stopped by a 1in. step.
> but I don't think there's much room to discuss safety here.
I couldn't disagree more. I don't understand why it should be possible to disable any safety interlock (at least, that's how I'm interpreting the feature description) in a consumer product, especially persistently.
This feature has me wondering what the SAE standards for automatic transmissions have to say on the matter, if anything?
I'm not familiar with them, nor do I have access, but I'm hoping someone here might be helpful on either aspect. Specifically, I'm wondering if the standards for automatic transmission controls recommend against having the Park setting do anything beyond activating the parking pawl and parking brake (when electronically controlled).
Experienced investors aren't going to invest much if the science isn't on a good foundation. Even if they would, that's a pretty expensive way to fund research: it's cheaper to fund it by grants or through revenue.
I would predict that it depends on where the money is coming from.
For VC firms that are experienced in the biomedical space, Theranos changes nothing because they were already suspicious of Theranos.
For firms that are inexperienced in the biomedical space, they have hopefully learned that growth cannot compensate for flaws in science or technology. If they continue to invest in biomedical, they will be much more careful in their DD; or perhaps they lose their appetite for biomedical and leave entirely.
I don't think things have changed for biomedical startups that are based on good science and technology and have an experienced team.
What would be wonderful is if the media learned a lesson from this mess. As I see it, they were a passenger in the Theranos hype machine.
This article (by way of the WSJ) claims that Walgreens skipped their standard DD in partnering with Theranos, and that the deal overall was atypically structured.
I remember playing around with REBOL a long time ago and it seemed useful and practical, but for reasons long forgotten I never used it. Maybe licensing? RED does look cool and I hadn't heard of it before, thanks for the tip.
Don't have any experience with Nim, but I share your interest for the same reasons. Haskell and I don't get along, maybe I'm too old and set in my ways?
I only use it like you guessed (and what I think it's best/appropriate for): gluing things together, embedded scripting, and Tk on internal tools/gizmos and early prototypes. I wasn't clear earlier, sorry.
To be perfectly fair, on the decision matrix Tcl gets a helpful boost due to my own familiarity with it and playing nice with C; if a butterfly had flapped it's wings just a little bit differently or I was starting out today I would probably be using something else. Probably Java. Ada would be great, but the lack of ecosystem diversity makes me apprehensive.
In terms of acceleration they're certainly impressive, but does any Tesla qualify as a supercar when other indices of performance are considered? They're pretty heavy for one, and while they wear it extremely well, a low CoG can only do so much.
Maybe Teslas aren't supercars, but they're instead super cars?
Thanks and thanks. To further bloviate, Tcl is my not-so-secret weapon. I first used it when doing exploratory work with some embedded one-off instruments and it made an impression because those doohickies are still running strong to this day, well beyond the design goal. They had sensors that were communicating over a serial console: Tcl made interfacing quick and painless, and a control GUI in Tk practically built itself. It's robust and a known quantity (flaws and all). There's also some level of je ne sais quoi where, like Lisp, I don't feel like I will paint myself into a corner: need more performance? drop down to C. language is limiting? make a better DSL. So I guess I'm either a fan or delusional (likely, both).
I don't personally know of anyone in medical using it, but your comment about no OS does prod me to say that I have wondered if running Forth on bare metal for medical is viable and/or desirable on a greenfield project. I'm not saying I would do it, but I would happily cheer on someone else. (OP, don't do this, I'm delusional)
And OP, I really hope that my wall of text won't be discouraging in any way. Personally, I found that documentation is (a la Homer Simpson) the cause of, and solution to, all of life's problems in a regulated environment. If you master that, document honestly and eagerly, it's downhill from there and life will be good.
I don't think there's any simple answer to your specific questions based on what you've provided so far. I'm going to word vomit a bunch of stuff that might, with some Google/Wikipedia searches, help give you a better view (I hope!). I hope this is helpful.
So much depends on the stage of the development process you're in, what the goal is of this project (i.e., internal testing, research use only, human use), when you're going under design control, and what market/regulatory framework you're working under (FDA, CE, CFDA, etc.).
Your requirements documents are a good guide here. I personally separate them as Engineering Requirements Document (ERD), Software Requirements Document (SRD), and Market Requirements Document (MRD); your questions would touch all of these.
You've hinted that you are wanting a display and also wanting to do calculations; as others have suggested, good practice would be to separate this functionality. Your ERD/MRD should specify a minimum duration for projected parts availability. Dealing with part variations is a pain, but having to replace an end-of-life'd (EOL'd) part is worse. For your own personal sanity, you probably shouldn't be looking at consumer-level parts and instead look for more industrial-style parts (a weak example might be to use a BeagleCore instead of an RPi for an internal project). You'll need to be mindful of your environmental requirements too, if for example your design called for a sealed enclosure that could greatly impact the parts you could include in your design due to thermal management. Even when using consumer level stuff, say USB, you should look for the industrial/ruggedized versions (e.g., that will have retaining screws).
Touchscreens for medical devices are, in my experience, a mixed bag depending on the application. If you're using a good design, they can be easier to keep clean and disinfected vs. buttons. On the other hand, depending on the touch technology you use and the type of information you're displaying, the display may not look great (i.e., a 2D plot can look fine on a resistive touch panel, but video may look foggy). Depending on what your users are doing, you could have smudges of some sort of fluid (or boogers, or giblets) obscuring info on the display. Also, I think users expect a modern multitouch experience now and I personally haven't been thrilled with that style of interface on anything other than capacitive displays.
If you're using a contract manufacturer (CM), they are a great resource. You'll be dealing with them during design for manufacture (DFM), but it's a good idea to engage them early so that you can design for DFM (if that makes sense). I don't know what your expected volumes will be, but on things other than durable goods (like scalpels), "high volume" medical quantities are considered "low volume" for other areas and this will greatly influence your design. I also found it frustrating because you're limited to suppliers/distributors/CMs/whatever that will be satisfied with the lower volumes.
Handwavy answers are that your safety-critical stuff is going to be hard real-time and running an OS developed under an appropriate quality system (QMS) like vxWorks, Integrity, QNX, etc. I don't have experience with it, but there is also FreeRTOS with an SIL (safety integrity level) 3 SafeRTOS option that could be an interesting contender. The software you develop will also need to be developed under a QMS as a broader part of your software development lifecycle (SLDC) and greater product lifecycle management (PLM). There are guidelines to use software of unknown pedigree (SOUP) by bringing it under your QMS, but this can be undesirable depending on circumstances. Most commonly the software is developed under C or C++ with an appropriate coding, review, and testing standard; for a greenfield project I think that considering Ada/SPARK or Java (with the appropriate compiler/VM) could be smart.
For things outside of the safety-critical areas, you have greater options, and it might be largely sufficient to develop under a QMS. You're going to need to be very mindful of software licenses to make sure that they are aligned with your project's requirements. If you're set on Linux then Yocto would be worth exploring, but NetBSD would be my first consideration due to licensing. For your GUI, FLTK could be worth considering if it met your requirements. Even if your product is Class A, it's maybe helpful to keep the more stringent requirements for Class B/C products in mind, so that you can (when and if it makes sense) develop expertise and institutional knowledge for Class B/C products later on.
Finally, considering your questions and I say this in the kindest intentions, you should be participating in the process but not be signing the decisions. If your company doesn't have the expertise in house, it would be worthwhile to either bring someone on board or engage a consultant.
I'm unclear on how Kuvée fits into the three-tier system [0]. Are they trying to supplement/replace the incumbent distributors, or are they in between the vineyards and distributors?
I should have also said in the original comment that Little, beyond the website, looks genuinely neat and I'm looking forward to exploring it further.
I just finished skimming through the paper you have linked on the site and liked it quite a bit. It directly answered another question I had, which was what would it take to implement Lisp-style syntax in the same fashion as you did for C-style syntax? I'd normally talk myself out of ideas like that, but your paper is talking me into thinking about it more.
I really, really like that "Why?" explanation page; I feel like many projects could benefit from copying that idea.
Frequently, the first thought I have when I see projects is, "okay, neat, but why does this exist?", and the answer takes some digging. It's wonderful that in this example the answer is made so obvious.