Thoughts on Digital Electronics, Embedded Systems Design, FPGAs, and the odd personal ideas.
Thursday, December 31, 2009
Are you still alive?
Friday, October 2, 2009
You get what you pay for
The other week I was passing one of my local car dealerships and I noticed a car brand that I hadn’t seen before. It was a Chinese manufactured 4x4 and it was listed at about $20K less than a similar 4x4 that I’ve had my eye on for awhile. Of course my initial reaction was it couldn’t be all that good but in spite of that, I took one for a test drive.
To my surprise, I can honestly say that it wasn’t an entirely horrible experience and I was seriously considering my options. There were a few niggling things such as very heavy suspension and a driver’s side mirror that didn’t fold out far enough but overall it felt like a pretty solid vehicle. When I returned it and started talking turkey with the salesman, I asked him about the extra options. I wanted tinted windows, a tub-liner and canopy for the rear tray, and a towbar. As expected, they were all additional options that pushed the price up by about $3000 but hey, you get what you pay for right?
Ok, I agree. For most things you do in fact get what you pay for. But does that also mean that if I want less, I can expect to pay less? Altium Designer is a unified design tool that includes (amongst other things) PCB, FPGA,
How you respond to this question really depends on your philosophical position. If you think FPGA or Embedded Software is an optional extra, then you’d rightly expect to not have to pay for it if you didn’t want it. But what if it isn’t? What if FPGA and Embedded Software development is a necessary part of sustainable product development? Surely it should always be included as part of the ‘base model’.
Put another way, what if I wanted to buy a Volvo without airbags? Will they sell it cheaper? What if I only want two forward gears, can I remove the top three gears and get a discount? Of course not. The reality is that these features are so much a part of the complete product that it doesn’t make much sense to try to remove them.
In the same vain, Altium views FPGA and Embedded design capabilities as being so fundamental to the future of electronics product development that it makes no sense to treat them as optional extras or ‘delete items’ that you can take off the price. We are all heading towards a future built on smarter products that continue to increase their reliance on functionality defined in the soft realm, and whether today’s customers choose to use these capabilities or not will not change the inevitability of that future.
Maybe you do get what you pay for, but maybe you need more than you realize.
Monday, July 27, 2009
Being free to succeed
Wednesday, July 15, 2009
Avoiding conflict with customer service
At the time of making the booking, I had requested a dinner reservation for 7:30pm. When we arrived however, the hotel reception informed us that a reservation had been made for 7pm. Later, when we fronted at the restaurant at 7pm, we were told that the reservation had, in fact, been made for 8pm and that a table would not be available until that time. Slightly inconvenienced, we went back to our rooms with the prospects of our stomachs churning over for another hour. But at 7:30, I received a call from the restaurant to inform me that a table had now become available and we could begin our dining immediately if we so desired.
So in the end, we got the dinner reservation at the time we originally requested but not without some mucking around. I noted all of this on the hotel feedback form when we checked out. The hotel receptionist was very pleasant and smiled warmly as she finalized the invoice. "Did you consume anything from the minibar?, No? Well that's all paid up then. Did you enjoy your stay?"
I hesitated for a moment. Do I tell her that we had been stuffed around by the dinner reservation? Or do I simply return her smile and not mention it?
I chose the latter after convincing myself that I had written all my grievances in the hotel feedback form and that there was no need to make a scene by going over old ground. But as I walked back to my car and drove off, I pondered this interaction.
I've done enough customer service stuff to know that for every 1 person who complains about something, there are at least 10x that many people who have probably felt similarly but have chosen not to say anything for fear of 'making a scene'. So when someone does indicate that their expectations have not been met, it is well worth the effort to resolve things both for them and to ensure the same thing doesn't happen again. But for me, telling the hotel receptionist that I had felt let down by the restaurant booking would have created a position of potential conflict between the two of us and that really wasn't something that I wanted to come between my weekend away with my wife. It was just easier to avoid the conflict altogether and move on.
But in doing this, I had let an opportunity for improvement pass by the hotel.
I started thinking if there was a better question that the receptionist could have asked that would have solicited my feedback without creating a sense of conflict between us. I concluded that a better question might be, "Is there any feedback that you would like me to pass on to management for you?" All of a sudden, the receptionist is no longer my adversary but is now my advocate. My grievance was not between me and her. It was with a faceless hotel reception system that had mucked my dinner plans around. And yes, that IS something that I would like passed onto 'management'.
By asking this slightly better directed question, the receptionist would have created the opportunity for much better feedback without creating a position of confrontation between us. By introducing 'management' as a third party into the discussion, she would invite me into her confidence and create an atmosphere of much better customer service. So while I honestly did enjoy my stay, the hotel is much more likely to receive the valuable feedback it needs through a better framed question.
Monday, June 29, 2009
Avoiding Premature Evaluation
When I questioned 'NoName' about their conclusion, they revealed, "We evaluated the design tool in line with how we felt a design tool should work." It's hard to argue with that logic and the reality is that their conclusion wasn't actually wrong - Altium Designer does allow you to do FPGA design using a schematic-based workflow. But it offers so much more than that and it was my job to help them see that.
Given that we all live in such an information rich environment, most of us have developed sophisticated filtering systems that allow us to order the information we we receive each day into nicely contained buckets. This works really well with well-behaved information that conforms with our pre-existing classification system. But what about the other things? How do we handle that?
That depends on whether we think the information is likely to be well-behaved or not. If we think it is well-behaved, then we will probably try to stuff the new information into one of our existing buckets. If we think it isn't well-behaved then we may try to put it into a couple of buckets. And in very rare circumstances, we may even consider making a paradigm shift and changing our entire bucketing strategy.
The problem with paradigm shifts is that we don't always know when we need to make one. Because we spend most of our time packing new information into existing buckets, our brains get very used to that sort of routine. So when something comes along that would warrant a paradigm shift, we may overlook it in our haste to stuff it into a pre-existing bucket.
That is how I would describe 'NoName's' initial reaction to Altium Designer. They thought they knew what they were looking at, they confirmed their ideas through some initial investigations, and once the classification process had concluded, they saw little reason to reconsider their conclusion. But to their credit, 'NoName' proved extremely open-minded and allowed me to discuss Altium Designer further with them. As a result, I was able to show them the features beyond the schematic entry capabilities and the overall exchange of information was quite valuable.
So if you're suffering from premature evaluation too, then maybe its time we talked about it.
Wednesday, May 20, 2009
The Best Switch Debounce Routine Ever
Consider the following ‘bouncy’ signal.
Up until t=3, the input signal is in a low state. At t=3, some EMI induces some spurious noise on the wire that we want to reject. At t=5, the switch is in a bouncy state as a result of being activated. And at t=6 and beyond, the switch is in a stable high state.
The goal of the debounce routine is to reject spurious signals such as those found at t=3 while still reporting a valid transition within a timely fashion. This can be done by taking periodic samples of the signal and reporting an update once several samples agree with one another. The exact number of samples and periodicity will depend on the environment that your application will be used in and the immediacy that you need to report an update.
So let:
A = Current Switch Sample (T=0)
B = Previous Switch Sample (T=-1)
C = Sample taken prior to B (T=-2)
Z = Last reported debounce value
Z’ = New debounce value
If (A = B = C) then
Z’ = A
Else
Z’ = Z
EndIf
We can create a karnaugh map for Z’ using the inputs A, B, C and Z.
There are a number of benefits to this routine over other routines I've seen:
- It works for debouncing an entire input port as well as individual bits.
- It doesn’t consume any timer resources other than those required to periodically call the routine.
- It can be readily implemented in programmable hardware, and
- It is perfectly scalable. So you can expand the number of samples without modifying the basic algorithm. For instance, the equation for debouncing across 4 samples is:
Z’ = Z(A+B+C+D)+A.B.C.D
And the equation for sampling across 5 samples would be:
Z’ = Z(A+B+C+D+E)+A.B.C.D.E
A sample C routine is listed below (please excuse the formatting):
int debounce(int SampleA)
{
static int SampleB = 0;
static int SampleC = 0;
static int LastDebounceResult = 0;
LastDebounceResult = LastDebounceResult & (SampleA | SampleB | SampleC) | (SampleA & SampleB & SampleC);
SampleC = SampleB;
SampleB = SampleA;
return LastDebounceResult;
}
Thursday, April 30, 2009
What is your sense of entitlement?
In a study of maths skills tests among students in eight nations, Americans ranked lowest in overall competence and Koreans highest, but when researchers asked the students how good they thought they were, the results were exactly opposite; Americans highest, Koreans lowest.
Monday, April 27, 2009
Altium's new pricing model
Friday, March 13, 2009
Fail fast, fail cheap
So in a word, my first attempt failed, but that's what lead me to the second attempt and a greater understanding of what I am working with. I now know that I need to leave provision in the application code so that I can calibrate for any servo to ensure I get the full range out.
Thursday, March 5, 2009
Forget what you know. It is hindering your progress.
- The things I know that I know
- The things I know that I don't know, and
- The things that I don't know that I don't know.
- The things I think I know that I really don't know
Thursday, February 26, 2009
The project begins
One of the devices I had to check out was a 2W audio amp. Now apart from the poor english in the datasheet (Example: When driving a speaker load suggestion set to the BTL mode for get the more power output.), the application circuit was drawn with the shutdown connection wired ON - i.e. to VCC. So without thinking, that's how I wired up the test circuit. When I got nothing coming out of the amp, I probed a little further, went back and read the data sheet, and realized that ON meant the shutdown was on, not the amplifier was on. Shutdown ON = amplifier OFF!
A quick rewiring of that pin and everything came to life - and quite impressively too. Given the mistake I made, I checked over the circuit that our hardware guy had created and sure enough, he'd been tripped up by it too. So it was well worth doing the quick prototype.
Next job was to test out the quality of some low priced speakers. They were tiny surface mount things and they sounded crap! I'm glad we did that check because it would have been a real let down if we'd gone ahead with them. It forced us to probe a little further and our sourcing guys found some great little beasties for about 70c each. They are 30mm across and use rare earth magnets and boy they can pack a punch. Unfortunately I don't have the specs on them just at the moment but I'll post a link later on.
I checked out a few other components such as an SPI-based Real Time Clock and One-Wire ID chip. Fortunately there were no surprises there but I've got to say, using Altium Designer to do the testing was a real breeze. They already have software drivers for SPI and One-Wire devices so it was pretty easy to get some basic test applications up and running.
So it looks like we are just about set to begin developing our first reference design. We had a brainstorm yesterday and came up with over 50 project ideas. But as we narrowed it down, we didn't want to spend all the time on developing the application. We wanted a project that would let us demonstrate the way to approach building a system without getting bogged down in the detail of developing a complex application. So it looks like the project will be a Natural Disaster Reporting System. The basic idea is that these units can be installed in people's houses and will log weather data back to a central site. In return, that site can send emergency response information back to the units based on immenent danger from fires, hurricane, tsunami etc. It'll give us a chance to show how to interface to a number of IO devices as well as build a nice user interface for the LCD and perform some Ethernet comms. I'm looking forward to building it.
Oh, and as a very topical side note, we drove down to Melbourne last weekend and had to drive through some of the areas affected by the bushfires. We weren't trying to be nosey but you can't help but notice the huge devastation. There are warnings that the weather tomorrow might be pretty bad as well and my mother in-law is going to evacuate just to make sure. No one wants to take any chances after what happened three weeks ago. So maybe our little project might get some people thinking about ways to use technology to better manage people during Natural Disasters.
Sunday, February 15, 2009
What would you like to see me design?
As an idea, I was hunting around Harvey Norman today for an Ethernet-USB adapter. Basically I want to have a portable hard drive available to my home network but without needing to have any one specific PC on. So the adapter would simply present the portable harddrive to the network so anyone can access. Even better would be the ability to limit certain PCs to certain folders of the hard drive so everyone can have their own storage space. (BTW, I did find one but it was $199 - way too pricey!)
Another idea might be a USB - Hard disk drive adapter so you can use one of those cool Everio hard disk based camcorders and dump the contents to a much bigger portable drive every so often without needing a PC/laptop.
So give me your ideas and let the world know what hot new gadget it needs.