Some useful links

DIY Consult protocols and register tables

Consult Schematic for a DIY interface

The question then becomes how can this happen… most of the blog commentors are going its labor. Well, perhaps development labor, but realistically, in volume production of technical devices, labor often pails in comparison to material costs and overhead.

A friend who used to run a contract manufacturer said he could compete with China any day, if it were not for his costs of capital and the US tax code in contrast with China’s subsidies of capital equipment when it came to pick and place operations.

In a lot of cases, overhead becomes a dumping ground for accounting games. In other cases, overhead is an under the radar way for folks to skim right off the top. Case in point, for the average US product produced in other than vertical integration methods, taxes passed along from vendor to vendor and subcontractor to subcontractor end up multiplying, such that a 15-25% hit overall is not unrealistic. On the other hand, the cost of labor and capital for state of the art vertical integration would be even higher. Ie, if you need a $9 billion fab, to ship 100 million units over a products life cycle… well at a $90 hit + interest+investor returns per unit… its not going to fly.

By the same token… how about a $1 million dollar fab to ship 100 million units. Namely an older 200mm, lower density process to make low cost parts. I’ve seen 100mm fab gear sell for microcents on the dollar. The same with the mechanical side. I remember in my younger days, a buddy sold a 20 ton injection molder for its scrap value.

System integration is another thing to consider. Back in the Apple II plus days, and while crude by todays standards, millions of pages were written on Apple II plus word processors. In 1982, I even had a Hayes 300 baud modem on an Apple II plus wired up to the cable tv audio channel so we could send files back and forth between schools. We also had pong and tetris. Now the Apple II plus of that era had a massive PCB with a kazillion socketed 16 pin dips, had 48K or memory and cost almost as much as a used car. In 2004, we built up a demo unit with a Atmel Mega 128, which also ran tetris, had a keyboard interface, and without too much hoop jumping could also be a webserver. It was a 64 pin TQFP, with 128K of flash and it sold for under $20 for qty 1. Granted the LCD we used was 6x the cost of the processor at qty 1.

As a result… mature parts and processes, vertical integration, and significant automation, combined with modest govt subsidies for the necessary capital equipment, and $10 doesnt seem unreasonable at all. Just dont expect all the bells and whistles of an ipad.

Such devices are normally monitored via computer 24 hours a day by the Key Biscayne, Fla.-based company, and a laser system determines when the beans are done and the roasting terminated, Weisberg said.

But lessee’s are responsible for maintaining Internet connections, as well as proper cleaning and maintenance of the roasters to ensure there aren’t stray beans or other combustibles where they shouldn’t be.

He also said the machines should not be used unattended, and said operators are warned in particular about periodic updates to Microsoft Windows that can lock up hardware needed to make the system work.

No doubt the manufacturer had some type of over temperature device on the heater assembly as it would be required for UL or NRTL approval. BY the same token, over temperature devices while they do protect the heater, and provide some level of fire protection are no guarantee one wont have problems. Even more so, if the system is controlled with an embedded PC.

For systems operating at low temperatures and or long process times, the heating elements will never ever reach process material combustion temperatures in normal operations. In such cases something as simple as a thermal fuse is adequate for protection, provided it is located and sized appropriately. Such a fuse would then disconnect the heater elements if a system failure were to occur.

In other cases, due to process speed, or the need for higher temperatures, it is exceedingly likely the heater surface temperature will be higher than the combustion temperature of the process material. While a thermal cutout is still a must to protect the heater elements, if combustible materials contact the heater surface, fire is likely to occur. In such cases, the mechanical design must be such to keep combustible material from the heater, and/or provide for an environment where a fire can’t start, or be self extinguishing. This can be pretty challenging.

Then to add insult to injury, there are often compelling reasons to use an embedded PC to control the process. From a bean counter point of view, adding a second controller, and thirdly, an thermal over limit device seem overkill. Why not let the PC directly control the process? It could monitor the system for over temp conditions, it can shut things down, and it can even send off an email if a problem occurs. Why should we add the cost of 2 more devices?

The problem… PC’s do a multitude of things, add in unattended operating systems updates, and there is a significant probability that the PC will lock up sooner or later. If the PC is the solitary control device, and it locks up the following is likely. The heater outputs will either go full on, or full off, and its impossible to predict which will occur. Being the PC is locked up, it cant detect over temperature conditions, should the heaters be full on. Being the PC is locked up, it cant send out an email, or SMS telling of the problem. The end result… if the PC locks up, with the outputs powered down, no problem. On the other hand, if it locks up, with heaters at 100% power, they are likely to over temp the process, and may reach the combustible stage. Thus at a minimum, a secondary overtemperature protection device is a must. Ideally though, the actual process would be controlled external to the PC, such that all the PC does is deliver a set point value to the aforementioned controller.

On the other hand, even with a dedicated control system apart from the pc, and tertiary over temperature protection… good mechanical design as mentioned before is required. Combustible material build-ups in the wrong area is beyond the ability of the pcs, secondary controllers, or tertiary overlimit devices to prevent fire.

Some have suggested such integration could enable remote patient monitoring… which I think could be pretty cool. Of course the problem of patient education would need to be addressed, as well as healthcare system reimbursement, after all someone does have to pay. Adwords driven analysis of PHR captured auscultation data is probably not the answer.

Its also interesting to note the comment on the bluetooth stethoscope software.

Zargis(R) Cardioscan(TM) software easily pairs with the Littmann Electronic Stethoscope Model 3200 to guide the clinician through four main cardiac sites, then after approximately one minute, indicates whether or not the patient possesses a suspected diastolic or systolic murmur–and whether or not the murmur is suspected to be a Class I indication for echocardiography referral.

On the one hand, this could be a majorly cool thing. On the other… its sort of like an early stage autopilot. Bean counters will always push to cut costs, and the ability to shift intrinsic knowledge to automation is a major temptation. The intrinsic knowledge of a highly experienced cardiologist, is not the sort of thing that lends itself to automation, much less scaling.

Now, if the software can just take some of the routine burden away, ie running down checklists, and capturing the obvious, and thus open up more time for the cardiologist, its a good thing… the problem will be the bean counters temptation to replace experience and intrinsic knowledge base with technology.

I can understand the rationale….

The experiment comes amid rising concern among governments and health insurers that they are not seeing the health improvements claimed by drugs companies because patients do not take the medicines as prescribed unless they are closely supervised in clinical trials.

Yet, my thinking is, egads, there has to be a better way, and perhaps more importantly, a way in which to do so to avoid locking into a single vendor. Obviously while Novartis is not against a more elegant or transparent solution, they most certainly want some type of proprietary solution.

Certainly simple solutions which have been tried in the past, such as pill cap timers, or even timed pill boxes haven’t worked, probably because they require the user to transfer meds. In other words, the tech is not seamless. On the other hand, wearing a reader on ones shoulder isn’t exactly seamless either, but it is a lot more fool proof. Ie, the RFID reader only logs an event when the pill is within a few cm, thus ensuring a valid time/date stamp when the pill is actually swallowed.

Years ago, I was thinking of this as well. One of the ideas was a pill bottle holder with a strain gauge, such that every time the pill bottle was removed, an event was logged. In addition, the pill bottles quantity could be checked via weighing the bottle every time it was returned. The problems were two fold. First, its yet another gadget for the user to mess with, and secondly, just because the pill bottle was removed and a pill was removed, doesn’t mean said pill was actually taken.

Another idea was a pill bottle ring containing an RFID tag that could be transferred from bottle to bottle. A reader was implemented in a wristband, such that time and date stamps were made every time the bottle was opened. In addition to audio and visual reminders, it also had the provision to upload data to the internet for ease of analysis, and/or potential physician monitoring. Such a system also suffered the issue of transparency and extra gadgets. Alas, such was during the dot bomb days, and it also died on the vine.

The thing is, flash dryers are the type of thing that are very easy and pretty inexpensive to build, but not necessarily so easy to engineer because of the numerous trade offs involved. I remember telling the young fellow, if you build your own, you can have a much better unit than you can buy for not a great deal of extra money… but, you need to balance out how much time and money it will take to develop a design. That is where the rubber hits the road so to speak.

For those unaware, a flash dryer is used in screen printing in order to bring freshly screen ink to a partially cured state (gelled) in a short time frame such that other inks can be overlaid on top. In dark colored t-shirt printing, its common practice to put down a layer of white, flash dry it, and then proceed to screen print the rest of the colors.

For those somewhat aware, a flash dryer is no substitute for a conveyor oven for purposes of final curing. It would be similar to using a pipe wrench as a hammer… it can work under some conditions, but its far from the optimum, and unintended consequences can abound.

The reverse is also true. One can use a conveyor oven to flash cure ink, but its slow, could affect durability, and it opens the door to major registration hurdles in removing and replacing items on the platen.

The driving off of solvents is really the key part of the flash drying process. The ink must not to be fully cured, or its likely the additional inks will not adhere properly, and as such the durability of the final article would be compromised. By the same token, if one tries to cure too quickly, the solvent may bubble off, and produce pinholes, or in other cases, the shirt/ink ends up scorched. And of course, if the article enters the next stage before being in the gel state, expect a mess.

Proper ink selection is also key. Not all inks are equally suitable for flash drying, some are subject to after flash tack, which requires an additional cooling station. Such an extra process step could impact production speed, but also if the ink is misplaced, impact durability. Ultimately, one needs to review the manufacturers ink specifications for flash drying, both as for suitability, but also the proper temperature.

Now that we’ve looked at the need for flash drying, and some of the issues involved, lets take a look at design. Earlier, I mentioned that the manufacturing of flash dryers is pretty easy, but the design part is where things get a lot more complex. There are a multitude of things to consider, and the fact that each one impacts one or more other factors makes for a challenge. As such, the old school printers are probably correct that DIY flash dryers are probably not the best way to go. Yet, if one is willing to trade design time for final performance, most certainly a DIY dryer can exceed the capabilities of pretty much any commercial product on the market. As I go through the design issues involved, I’ll throw out a few blue sky ideas, that are not commercially viable for a product manufacturer, yet for the dedicated experimenter may prove useful.

Being each design issue can end up being fairly long, I’ll break them out into individual entries. As I do so, I will hot link them here for ease of navigation.

Some of the design issues and tradeoffs:

• safety in use
• safety in manufacturing processes chosen
• speed of cure vs energy used
• speed of cure vs production bottle necks
• static uniformity
• dynamic uniformity
• manufacturing labor costs
• raw material costs and availability
• usability
• user maintenance
• product costs and features
• time to market, and engineering costs

* disclaimer… I’m a hardware designer, not a screen printer. While I’ve been in a ton of shops ranging from 1 man opt with a single press to 300 employees with a multitude of octopus presses and others, my hands on time is exceedingly limited. Keep such in mind, some of the concerns and concepts I have may not necessarily be the optimum for your operation, or any operation for that matter.

Whats interesting about this case, is the two devices worked well for 3 years, and short of any recent repair or modifications, something is starting to go bad. It could be a component level problem, or possibly a system problem.

Its difficult enough to build in suppression and immunity during the design stage, its another deal entirely to deal with failures during the latter part of a products life. Being the PDA is 3 years old, the time sounds about right for solder wisker formation, especially so if the user lives in a northern climate. By the same token, 3 years of realistic use can cause any number of solder fractures to occur… Of course, it could also be shifting values, thus detuning filter circuits, especially if manufacturing processes were not controlled.

Otoh, it could also be the start of a failure in the ovens wiring. Certainly corrosion of a ground lead internally could cause this, yet issues with house wiring are not all that common either. Some places still provide for grounding via water pipes, and galvanic corrosion can take a serious toll. Its not the sort of deal which affects safety, well not until its very severe and pipes are nearly leaking, but by all means, it could seriously affect EMC susceptibility.

Sadly, the consumer is pretty much left holding the bag. Short of bringing in an EMC guy and a spectrum analyzer, only obvious things can be checked. Ie, oven connections, ground connections in the house, fuse box, water pipes etc, yet it could take unless one knows what to look for, it could be a massive exercise in frustration.

Had this been an iphone rather than a PDA, then I’d really be wondering. Ie, Iphones, just like all devices are tested to comply with FCC regulations. Ideally such tests are done with a worst case scenario, yet there in lies the problem. Defining a worse case scenario is a pig in a poke.

Do you run the phone in max transmit power? Do you put the code in a loop? If so, what period, what duty cycle, what about ringing, what about charging, what about different states… All best guesses, well other than charging, being most phone manufacturers prohibit the use of their phone from being used, while attached to a wall outlet.

The remaining elephant in the room is the iphone app. Certainly Apple runs through a bunch of tests for compliance, yet they cant expect every possible permutation a developer might come up with. Its certainly possible, sooner or later an app is going to result in an Iphone going far out of compliance. Hopefully should such happen, it ends up being a minor inconvenience, but again, near impossible to predict when, or what would be affected. Short of pacers which must operate with high margins, I see a lot of potential for trouble, even more so as devices age. No matter what, it will be interesting.

Relationships
A twitter newbie has an initial barrier to overcome, being they are not known, and that anyone we know, doesnt know them either. Thus, most have to just throw things out, typically by the twitter bio, and tweet content, and hope that someone randomly comes across it. Another option is events, where like minded individuals tweet and discuss.

Contrast this with 3d, where We build relationships in most cases, by who we know, and by who they know, and/or as part of a peer group at an event.

Information
We search out information via who we follow, but also with hashtags, and even with textual search. This is not unlike our peer groups and goto people, but is also a 3d legacy of tables of contents and indexes.

The process of communication
Visual is by far the fastest way of sorting, and capturing data. The picture being valued as a thousand words is very true. Of course the issue in realm time communications is a lack of space necessary to display many images, albeit new tech has made massive steps in this domain.

Keyboard entry otoh, is a slow way of communicating, albeit it is often significantly more precise that other methods, due to the pre-thoughts necessary. This can be even trickier when limited to 140 characters, yet the informal tone created does provide for greater spontaniety. It is an amazing balance.

Visual data entry is yet another matter, as its slow, and very skill dependent, yet when well done is an amazing tool.

Audio based communication is likely the most natural, and most convenient, and fastest from a data entry point of view. Yet, it is often error prone, and exceedingly difficult from a search and retrieval point of view.

The concept:
Audio data input and graphical display output… The implementation is the challenge, and technical bottlenecks abound. Otoh, its the sort of thing, where each bottleneck if solved has substantial stand alone value. It could well be the concept is too limited by current understanding, and something else could morph out of it too.

Some potential blue sky claims for such:
1. A voip wiretap system similar to the NaurusInsight, which would capture voice clips, based upon targeted text input. Voip/text enmass conversion is just too ungainly and slow, at least with current technology.
2. A mass conversion of said targeted voice clips to data, such as text which could indexed for search, error correction, or relevancy tests.
3. Based upon relevancy tests in 2, a graphical display would be created to present data to end users.
4. Beyond simple bio analysis, or hashtags, artificial intelligence could be used to analyze clips, as well as text snippets to facilitate bird of a feather grouping.
5. In addition, voice data of targeted clips could be analyzed for emotion, thus reducing the potential of errant communication.
6. Style of voice clips could be analyzed, and assigned a grouping of birds in a feather. Ie, those who are exceedingly literal and factual should be aware when joining a group, as to whether they live on satire, or are wiseguys, or dead serious etc.
7. The intent is not homogenity of groups, but more so greater initial understanding, thus fostering better relationships, and improved communication.

Spam marketing to the wrong market sector. Dont market real estate based SEO to a manufacturer, or food based SEO to an aviation concern.

Nothing instills a lack of confidence like showing your best efforts on your own broken website. Sure, its a pain to keep up with browsers, and even screen sizes. Otoh if you want to impress potential clients, a page with CSS splattering your content randomly on the screen, no matter how cool the art is, if its not readable is not cool.  Its the same with broken website navigation, or errors so bad, that a users browser throws up and is unable to render. Such does not inspire confidence.

Retro can be cool, and 1994 style websites can create authenticity in some markets. However, years old SEO techniques are not. While a cool sales pitch may impress the uninformed, is not going to fly worth a hoot unless there is little to no competition. (albeit, flying not worth a hoot, is better than not flying at all, but its still not cool)

A coder does not a website builder make. Ive built hundreds of sites over the years, and while technically they work and get the job done, I am no graphic artist. I know this, and as such outsource the presentation arena to people who are for other than my own sites. Sadly, far too many recently unemployed coders think they can do websites, and just as with my work, the underlying code is solid, but they dont spend the money for a graphics person. It shows, and it is not impressive.

SEO is only part of the game, and realistically, its a tiny part. Traffic without conversion is just burning up server dollars. It doesnt pay, and often times ends up being a negative ROI. Just as one would not go to the expense of prime billboard space or tv ads unless they had the ability to fullfill orders, it makes no sense to spend money on SEO without the rest of the game plan in place. Certainly there are situations where traffic can be more important than conversion, but they are a rarity, and often times more of a specialized internal thing, than an external deal subject to outsourcing.

A cursory view of patents, and applications shows everything from scented ink, to heated capilaries, to pressure, venturi, or heat based atomizing systems. Its not rocket science to add ethernet connectivity to such, but physical size and space constraints make variations a challenge. Otoh, such systems provide for the possibility of scenting an entire room, which most times is overkill.

An alternative solution might be a specialized scent printer, where in an array of scents are preprinted on paper sheets, but are only activated upon being mixed with printer ink. Mechanically, such a solution is exceedingly simple. COTS printers could be used, albeit significant resources would likely be needed in the paper, and ink chemistry domain. The end product could provide for hundreds of scents on a page, and being the amount of material used is miniscule, the time duration of a scent would be automatically limited. It is possible, the scent paper could even be reused.

Another possibility is a scribing type device, ie scratch and sniff, where in an internet controlled syllus surrounded by a gasket of some nature, and a fan to disperse the scent could be used. Such an approach would reduce the need for substantial chemistry resources, being it is riding upon well developed prior art. The scribing method could be implemented similar to the pen plotters of old, another well developed technology. The only real challenge is the gasketing to prevent cross contamination of the scratch and snift zones. Scribe cleaning between scent product may also prove a challenge, but less so than the gasket aspect.

ut may pose significant chemical challenges. The scribe method, sort of