There are always tradeoffs between Non Recurring Engineering (NRE, or product development costs) and Costs of Goods Sold (COGS, or the cost of the final product). The balance between the two depends on the project. Simple products will require lower COGS. However, never forget about NRE costs. It is possible for you to increase COGS slightly and save a lot of money on NRE. One example of this is an embedded project requiring UART. Assuming your microcontroller or design has no UART capability, you can go either the software or the hardware route. Most will go the software route. Why? obviously because software is cheap (the most erroneous assumption by some).
When you look at software, development is very expensive. Sure, you can bit bang UART and it will work, but to get it to work reliably will require code design, development and debugging. For just a little added cost to COGS (the price of the final product), you can save yourself major headaches, not to mention that you won’t be burdening your microcontroller with handling UART itself.
If you don’t believe it, consider that IBM’s own analysis of hundreds of software projects finds that software development does not scale linearly with complexity. Simpler software costs less.
Nonetheless, there are cases where hardware won’t do. This is especially true when upgrades will be required. UART is standard and won’t require upgrades, but a proprietary algorithm that’s in flux will change.
When you think of Sensor Networks, 2.4GHz transceivers likely come to mind. The CC2420 is one of the most popular transceivers for sensor networks and other applications and it uses 2.4GHz as per Zigbee. Of course, Zigbee does allow Sub-1GHz frequencies, but I’ve yet to see many of those made. Undoubtedly this is due (among other reasons) to the smaller antenna which results in a smaller PCB. However, there are several issues with these transceivers, among them:
- Operating sensor networks and other devices at 2.4GHz can be a coexistance nightmare. Consider that most deployments will be done in urban environments where the 2.4GHz band is saturated with Microwave Ovens, Baby Monitors, Bluetooth, WiFi, etc. A node needing to survive in this environment will experience frequent collisions. There have been several papers analyzing the performance of devices in these conditions and needless to say the results were far from acceptable.
- Decreased range is to be expected from higher frequencies as per the Friis transmission equation.
2.4GHz devices do have some advantages such as popularity, small size, and ease of interoperability. However, next time you consider a transceiver, don’t disregard the sub-1GHz options which might be better.
Some useful transceivers:
TI CC1101 – sub-1GHz transceiver with multiple bands, 10dBm output power, flexible modulation formats and 500kbps
TI CC2520 – 2.4GHz Zigbee compliant transceiver
There are many other manufacturers of RF Transceivers (especially Zigbee/ 802.15.4) such as Microchip, but I listed TI transceivers because they seem to be quite predominant in the market and I’ve personally used them in several projects. The CC2520 is an update to the CC2420.
Let’s face it, many (if not most) engineering software is made to run on Windows. There are, however, many open source options that are worth while. I find gEDA to be one of these rough gems. gEDA is a Schematic capture, PCB layout, and simulation package. Although it’s missing features and is lacking on integration, it is close to Eagle CAD in its performance (and in some cases outperforms it). Many projects have used it successfully. I myself am working on some improvements I hope will be accepted upstream.
gEDA Home Page
If you’re looking to build from source (I highly recommend doing so, even if only to try), follow the instructions on this page. The only difficult part is to get all the dependencies, which is not that bad if you use apt-get or some other package manager.
I’ve been delighted to see the addition of price sorting at Digikey. It’s a long overdue feature that really helps speed up the component procurement process. I find many of the more expensive components are usually specialty components that I won’t need to purchase unless I search for them specifically.
Electrical Engineering is usually divided into many specialties - Power, Control, Microelectronics, Signal processing, Telecommunications, etc. and it’s rare for engineers to move away from their specialty. I’ve found that Embedded Engineers are sometimes required to work in many of these areas at once – to be able to get an application off the ground, you need to be able to understand many of the issues surrounding the system. Imagine how a microcontroller would perform if its supply rails were full of noise due to a bad power supply design or trying to perform an FFT on an 8-bit microcontroller? This clearly calls for knowledge in many disciplines.