Observations on Aversion to Opportunities

Telemarketing. The one word brings a host of responses: shudder, disgust, annoyance, etc… all guaranteed to be negative. And while so many blogs and informative literature address the issue of soliciting with calls, I feel a disappointment towards potential customers on par with what they may feel about me.

Now, to be fair, most of the customers I reach aren’t a) decision makers or b) target audience. My job is the sift through the a large pool of “potential” customers who’s likelihood of needing the tool varies wildly. However, just as my inability to reach a customer may inhibit my success, the customer’s inability (or unwillingness) to be reached may be a missed opportunity for improved efficiency.

For my first project, I am calling customers who might have an interested in Mentor Graphic’s LP Wizard tool. This powerful little tool is:

• The only CAD library generation tool approved by IPC
• 89% faster than manual part creation
• Powerful search tools improve design efficiency
• Includes a starter library of 10,000+ components

just to name a few features.
I suppose the key selling point of this (or any) tool is efficiency that leads to a reasonably (or better) ROI. 89% time savings on a library cad creation may be only 50 minutes at a time, but over the life of the tool, those 50 minutes can become many hours. At the cost of paying an engineer to spend those tedious hours, the tool genuinely pays for itself. The additional guarantee of quality through the elimination of human errors makes LP Wizard even more enticing.

LP Wizard is only a small example of how tools are ignored. Innovation and growth comes from understanding the resources we have to streamline our processes. I wonder if construction workers, lets say framers (those who frame houses), were so adverse to, oh, let’s say, the nail gun. How many builders, so bent on hammering by hand, lost the opportunity to minimize time to completion of projects?

Again, not to say that everyone needs the tool. If you have a small company that outsources the layout process, or don’t work with a lot of new components wont have any use for the LP Wizard. But, it could be argued that as engineers, we should want to make things better. Taking a few hours to examine a new tool and running some rough cost/benefit calculations is a worthy investments if it can help with time-to-market, quality, or any other metric of product development.

But telemarketing isn’t easy. It’s a combination of technique (which I have yet much needed practice to develop) and persistence to wade through the long list of “potential customers.” It’s unfortunate that the stigma of solicitation calls can hurt those on the receiving end.

Tighter Integration of PCBs: Start to Finish

One the EDA Tech Forum website is an article by Mr. Clive ‘Max’ Maxfield regarding a shift in manufacturing of PCBs towards tighter integration. He argues for the importance of designing for manufacturing, testing and fabrication (DFx), as well the the importance of a clear line of communication from front end designers all the way to fabrication and manufacturing.

With one week’s experience in the industry, this makes such intuitive sense. The walls between schematic design, layout, verification and production requires luck to avoid ECO-s. The same test-driven design as used in high-level software needs to take place with to avoid the costly rework. As important is using a tool that allows for every step of the PCB production process to be able to communicate with each other.

Mentor’s visECAD program is an enterprise-wide viewing tool that displays everything from schematic to cad/cam files. Features include the ability to mark up designs and do collaborative work. The viewer itself is free. visECAD allows for the tighter integration between design and production stages to allow seamless communication that decreases errors and rework. Give it a try.

Mental Block

I am studying the idea reference counting for shared objects in Java. This piece of code threw me for a loop:

class Shared {
private int refcount = 0;
private static long counter = 0;
private final long id = counter++;

It’s laughable, but I couldn’t figure out how the counter kept counting as I created new objects, challenging my understanding of Java and OOP. Such a simple piece of code seeming so clever and (pardon the word) cute.

Checking In

I haven’t been posting lately, as most of my time as been going to learning Java and I haven’t devoted much time to studying anything else. I don’t want to waste time reposting the blogs or articles of others or stray from the mission of making this blog a repository of my studies. That is exactly what this post does. It’s maintenance.

The book I’m using to learn Java currently is EXCELLENT. It’s available here. Genuinely readable and informative. The text has a great flow, providing digestible bits of examples and exercises that are clear in intent.

I’m finding it much easier to devote time to the study of coding than in working with electronics for several reasons:

1) Cost

Eclipse and Java are free. Electronics projects are not. Even with affordable components, there’s usually a shipping charge.

2) User friendliness

Without test instruments (I could definitely use a digital scope – debugging with LEDs can only go so far. This ties back to cost ; test equipment is expensive) it’s difficult to troubleshoot circuits that don’t work. It could be argued that circuits should be built right the first time, but software allows for much quicker iterations and much less labor (hence, the next point).

3) Time consumption

I think most of us can agree that, despite time management, squeezing in an hour or two a day of productive project work can be difficult with a 40+ hour work week. Getting a solid project built on such a time budget can be difficult. On the other hand, building a simple application, aided by eclipse or MS Visual Studio, can be much less time consuming but just as productive.

In the end, I hope the two skill sets can be integrated for better projects in the future. One of the best engineers that I had the pleasure of working with was a programmer before being an alumni WWU’s program and an applications engineer at Cypress, after which he went to Stanford for a masters.

He was the first to show me the power of developing applications through C# and .net. Within 10 minutes he developed a windows app to control a stepper motor through USB and RS232.

So, until the next organize post of the more informative post, I will continue to explore the beauty of JAVA and OOP😀

Java! Eclipse!

I’ve been learning Java. It was between C# and Java. Java won. I’ve been at it for a couple months now, but I’m still figuring things out. At first, I was writing programs in notepad, compiling them online, then running them through the DOS command prompt (I had a good reason for doing this).

I’ve recently started using Eclipse, which I really enjoy. My NXP LPC1114 project is also using the Eclipse environment with GNU for C. Despite the usual frustrations associated with larger open-source software (I know this comment draws some hate), it’s easy to use and powerful.

I also found these tutorials, which are EXTREMELY helpful in both learning Java and Eclipse. Java is so complex, I feel the basics need to be drilled over and over again. These courses, especially the Total Beginner and Persistence tutorials, really put everything together. The tutorials are also a great introduction to test-driven development and JUnit testing.

Cancer Treatments

My father passed away from lung cancer about five years ago. Despite some experimental treatment, he lived about 6 months after diagnosis. My aunt died of esophageal cancer. One in four Americans die of cancer.They say that every man, if lived long enough, will eventually get prostate cancer.

Sometimes I am amazed that cancer is yet to be cured. With big pharma spending billions for a cure, and with all our advanced research and technology, we still can’t reverse advanced cancers.

Here’s a series of(really good) NY Times articles about testing of a drug called PLX4032 which targets a specific protein (called B-RAF), which occurs in about 50% of melanoma patience:

However briefly, PLX4032 had held off the cancer by blocking a particular protein in its cells that was spurring them to multiply. If such targeted drugs were ever to provide a lasting benefit, many oncologists believed they would need to be combined with others, much as cocktails of protease inhibitors have worked against H.I.V.

The article explains that the drug is able to stave of cancer growth for about nine months. I would have done almost anything for nine extra months with my father.

Another interesting development, and one that seems more applicable to a large variety of cancers, uses nanoparticles to deliver substance to block protein expression in cancer cells:

A multi-institutional team of researchers and clinicians has published the first proof that a targeted nanoparticle can traffic into tumors, deliver double-stranded small interfering RNAs (siRNAs), and turn off the production of an important cancer protein using a mechanism known as RNA interference (RNAi). Moreover, the team provided the first demonstration that this new type of therapy, infused into the bloodstream, can make its way to human tumors in a dose-dependent fashion, that is, a higher number of nanoparticles sent into the body leads to a higher number of nanoparticles in the tumor cells. These two findings were achieved in phase I clinical trials in which the investigators are testing a nanoparticle-siRNA construct as an anticancer therapy.

Death is a fact of life, so far, but I don’t believe it needs to be. Technology has helped us facilitate more “unnatural” phenomena (like wireless communication) as one day it may cure old age, sickness, death and cancer.

Fourier and Stanford

Academically and politically, my senior year at Western Washington University was a bit skewed by an angry yet tenured professor retiring with a quarter’s notice. In a scurry to fill gaps, the rest of the faculty was spread thin and some electives were made unavailable.

To mitigate, several “temporary” professors were hastily installed. I experienced one such professor for my senior digital communications class. Without experience teaching the course as in our curriculum and with us all being busy with our senior project, I can’t say it was the most I’ve learned in a class.

According to the course description, the course is:

An upper-division study of modern, digital communications concepts and techniques. Topics include sampling, quantizing, digital modulation and detection methods, baseband signaling and line codes, bandpass signaling, synchronization, and error detection. Several case examples will be presented throughout the course.

The stop-gap professor for the course spent a long time covering concepts in Fourier analysis (orthogonality, convolution) yet failed to discuss the more practical applications, which was the intention of the course. As an EET curriculum, we weren’t quite adept to the more rigorous math techniques involved.

In attempting to bridge the gap, I came up with a solution. I found these lectures from Stanford, presented by professor Brad Osgood. The course website has accompanying lecture notes and problem sets. I’m slowly working through them, brushing up on (and improving) my calculus in the process.