The post MOSFET Power Loss Calculator appeared first on DMC, Inc..

The ease of implementation of USB largely depends on the hardware and software infrastructure that the microcontroller manufacturer provides. As of release 5.12.0, ARM Mbed OS began supporting USB device for several targets. This provides a nice layer of abstraction between the various manufacturers’ USB implementations and the USB class code. There are a variety of USB classes that are supported by default: USB MSD, USB HID, and USB Audio.

In this blog, I’m going to try out this new USB device support and create a USB Mouse out of an old joystick.

Setting up the Project

I want to test out the USB HID class which will allow the device to interface with the PC as a USB mouse. I am going to start by creating a basic ARM Mbed OS project. If you have never done that before, take a look at this guide.

For this project, I am using a NUCLEO_F429ZI development board which is one of the supported targets for using mbed’s USB device. I set the target in my project by using the command “mbed target NUCLEO_F429ZI”. Make sure that your compiler is also set correctly according to the compiler that you have installed.

For the test, I am going to copy-and-paste the example main from the file mbed/usb/device/USBHID/USBMouse.h.

#include "mbed.h"
#include "USBMouse.h" 

USBMouse mouse;

int main(void)
{
  while (1)
  {
      mouse.move(20, 0);
      wait(0.5);
  }
}

#include "mbed.h"
#include "USBMouse.h" 

USBMouse mouse;

int main(void)
{
  while (1)
  {
      mouse.move(20, 0);
      wait(0.5);
  }
}

Try and compile the project by running “mbed compile.” If you successfully build this project, then you are ready for the next steps. If not, make sure the target you are using is supported by ARM Mbed OS’s new USB device.

Note, not all of the targets with hardware USB support Mbed’s USB device abstraction! Also, make sure you have the latest version of ARM Mbed OS in your project.

Running a Quick Test

Load the compiled program onto your target development kit. I am using a NUCLEO which has a STLINK on-board, so the development kit shows up as a drive when I plug it in. Just drag-and-drop the compiled “_your_project_name_.bin” onto the drive to program.

To test the USB HID device, plug in the User USB port to the PC in addition to the debugging port which is needed for power. On your PC, you should see that a new USB device is detected. Once setup, your PC’s cursor should slowly move across your screen in 0.5-second steps.

We are now ready to bring in the retro hardware to complete our USB device!

Adding Some More Hardware

I have an old Apple Joystick IIe that I want to use as a USB joystick; so I need a custom USB adapter. The joystick electronics are very simple. There are two pushbuttons with pull-down resistors and two variable resistors, one for each axis, with one side tied to V+.

To interface to the joystick, I connect 3.3 V on the NUCLEO to the V+, connect the GND on the NUCLEO to the joystick ground, connect the push-button outputs to digital inputs on the NUCLEO, and connect each axis output to a NUCLEO analog input with a 100 K ohm resistor to ground.

I pulled all of this together quickly with a small prototyping board. The connector itself is just half of an RS232 serial cable.

Now, with a bit of firmware, we can get this retro joystick to operate with any modern OS.

The code below is what I quickly put together to read the analog inputs of the joystick, read the button presses, and send corresponding USB Mouse events. When using one of the various supported USB device classes, Mbed can substantially decrease the required development time.

#include "mbed.h"
#include "USBMouse.h"

USBMouse mouse;

AnalogIn ainx(A0);
AnalogIn ainy(A1);

DigitalIn right_button(D6);
DigitalIn left_button(D7);

int main()
{
	float x = 0;
	float y = 0;

	bool prev_right_button = true;
	bool prev_left_button = true;
	
	const float mid_x = ainx.read() * 100.0;
	const float mid_y = ainy.read() * 100.0;
	
	while (1)
	{
		// Update the X, Y position
		y = ainy.read() * 100.0;
		x = ainx.read() * 100.0;

		float x_move = x - mid_x;
		float y_move = y - mid_y;

		if (x_move < 0)
			x_move = 2 * x_move;
		if (y_move < 0)
			y_move = 2 * y_move;

		if ((abs(x_move) > 4.0) || (abs(y_move) > 4.0))
		{
			mouse.move(-1 * x_move, -1 * y_move);
		}

		// Update the button presses
		bool current_right_button = right_button;
		bool current_left_button = left_button;

		if (prev_right_button != current_right_button)
		{
			if (current_right_button)
			{
				mouse.press(MOUSE_RIGHT);
			}
			else
			{
				mouse.release(MOUSE_RIGHT);
			}
			prev_right_button = current_right_button;
		}

		if (prev_left_button != current_left_button)
		{
			if (current_left_button)
			{
				mouse.press(MOUSE_LEFT);
			}
			else
			{
				mouse.release(MOUSE_LEFT);
			}
			prev_left_button = current_left_button;
		}

		wait_ms(10);
	}
}

#include "mbed.h"
#include "USBMouse.h"

USBMouse mouse;

AnalogIn ainx(A0);
AnalogIn ainy(A1);

DigitalIn right_button(D6);
DigitalIn left_button(D7);

int main()
{
	float x = 0;
	float y = 0;

	bool prev_right_button = true;
	bool prev_left_button = true;
	
	const float mid_x = ainx.read() * 100.0;
	const float mid_y = ainy.read() * 100.0;
	
	while (1)
	{
		// Update the X, Y position
		y = ainy.read() * 100.0;
		x = ainx.read() * 100.0;

		float x_move = x - mid_x;
		float y_move = y - mid_y;

		if (x_move < 0)
			x_move = 2 * x_move;
		if (y_move < 0)
			y_move = 2 * y_move;

		if ((abs(x_move) > 4.0) || (abs(y_move) > 4.0))
		{
			mouse.move(-1 * x_move, -1 * y_move);
		}

		// Update the button presses
		bool current_right_button = right_button;
		bool current_left_button = left_button;

		if (prev_right_button != current_right_button)
		{
			if (current_right_button)
			{
				mouse.press(MOUSE_RIGHT);
			}
			else
			{
				mouse.release(MOUSE_RIGHT);
			}
			prev_right_button = current_right_button;
		}

		if (prev_left_button != current_left_button)
		{
			if (current_left_button)
			{
				mouse.press(MOUSE_LEFT);
			}
			else
			{
				mouse.release(MOUSE_LEFT);
			}
			prev_left_button = current_left_button;
		}

		wait_ms(10);
	}
}

Testing it Out

Plug it into the PC and try out this retro joystick working with a modern machine!

This is a great way to get a simple USB device going, but often a product will require more customization or non-supported USB class. If this is the case for you, come talk to our embedded development and programming group to see what solution makes sense for you!

The post Trying Out ARM Mbed OS’s New Support for USB Device with Some Retro Hardware appeared first on DMC, Inc..

The DMC boot loader has three important features that help improve its use. The first of which is it has an onboard micro USB port. This port allows for serial communication with a CPU via a USB to micro USB cord (like you would use to charge a phone).

The second important feature of the boot loader is that it has onboard reset and boot buttons. This allows for the user to easily put their MCU into boot loading mode by resetting the MCU while pressing the bootloader button.

The third feature of this board that is important is the five-pin connector. This connector is how the bootloader communicates with the target MCU.

For most DMC embedded projects, there is a standard 5 pin header that is compatible with the boot loader’s connector. Through this mounting, we can send and receive the serial data, as well as reset and put the board into boot loading mode. Even if a board doesn’t have a compatible mount, you can manually connect the boot loader’s TX, RX, boot, ground, and reset pins to the appropriate locations on the target board to achieve the same functionality.

This tool is one example of many internal initiatives DMC has undertaken to be more efficient and profitable.

Learn more about DMC's Embedded Development and Programming Solutions. Contact us for additional information.

The post DMC’s Custom Bootloader appeared first on DMC, Inc..

Fortunately, the Siemens S7-1200 series PLCs are quite easy to disassemble, and I was able to replace the damaged components and restore it to a proper working condition. I definitely wouldn’t trust this refurbished PLC to run a critical system, but for testing code in our lab, it should be just fine. I would also recommend reaching out to the manufacturer if you are running into issues with a production PLC, keeping in mind that any warranty may be voided if you attempt to fix it yourself.

Opening the Enclosure

Using a small flat blade screwdriver to push in the side tabs, it’s easy to pull the enclosure apart and separate the power conditioning PCB from the main board.

Surveying The Damage

I immediately noticed the burn marks coming from the positive voltage supply pin, but everything else looked okay, and there was no visible damage on the main board.

The first component in the circuit is a fuse, designed to limit the damage from precisely this type of mishap. Using a multimeter to check for continuity showed that it was in fact blown, as one would expect. I went ahead and jumpered it out with a wire wrap connection.

Now What?

Unfortunately, the fix wasn’t going to be that easy. Measuring the resistance across the voltage supply terminals, I found there was now a short circuit. After checking all the components that go across the voltage bus, I found that the culprit was a small Zener diode.

Its purpose is to suppress spikes in the supply voltage, but unsurprisingly, applying 120 VAC far exceeded its maximum power dissipation rating and caused it to short out. Simply desoldering the offending diode from one of its pads fixed the short, and after reassembling the PCBs and applying power, I was surprised that the PLC powered up and was fully functional. Clearly, the protection circuitry had done its job.

Patching Everything Up

Even though I now had a working PLC, leaving it as-is would mean that it would most likely not survive a second jolt of high voltage, so I went ahead and replaced the fuse and Zener diode to make it almost as good as new at a cost of less than $2.

After that, it’s easy to snap everything back together, power it up, and watch the blinkenlights turn on!

Conclusion

I hope you enjoyed this sneak peek under the hood of a device that we work with on a daily basis. It was nice to see that Siemens designs their PLCs to be pretty robust and easy to disassemble, unlike the typical consumer electronics devices you tend to see these days. Share your own stories of hacking PLC hardware in the comments section below!

Learn more about DMC’s Siemens S7 PLC programming expertise and embedded design expertise. 

The post How To Disassemble and Fix a Fried S7-1200 PLC appeared first on DMC, Inc..

Our engineers created this overview of the product development process to demystify how to bring your product to market. 

Learn more about DMC's Custom Software and Hardware Development services.

The post The Product Development Process: How to Bring Your Product to Market appeared first on DMC, Inc..

Altium Designer has an excellent tool to assist the embedded engineer in managing changes between revisions and within different variations of a base design: Design Variants (sometimes called Assembly Variants).

Introduction to Design Variants

So, when do Design Variants come into play? At DMC, we use this tool primarily to manage situations where components that exist on the schematic are not intended to be installed on the PCB. There are many reasons why a component might be placed on the schematic but not on the final board. Here are a few key cases:

• Designs with functionality that can be stripped away for “basic” flavors of the product/solution
• Prototypes intended to test functionality of two or more similar (but not identical) circuits; one example would be evaluating two 5V power supplies for the lowest noise
• Designs with a matrix of pull-up and pull-down resistors to indicate the PCB/hardware revision to the microprocessor so that it can re-assign I/O addresses or enable/disable functionality accordingly

Let’s take the first case above. DMC recently executed an embedded design for Chicago Dial Indicator (CDI), a company that manufactures (among many other products) high-quality electronic dial indicators. DMC originally connected with CDI to help innovate their flagship electronic dial indicator (read more about that project). After launching that product, CDI approached us again to revitalize their EMS device, which connects multiple indicators to a single device to show data, log measurements, and provide an easy interface to a PC or measurement system.

DMC suggested designing a PCB that could interface with an expansion board to double the channel count without any additional hardware designs. Sure, we could have designed and managed two separate boards, but with Altium’s Design Variants functionality, this was a breeze. Let’s take a look!

Variant Management

Below is an excerpt of the schematic that shows the device interface channels. Rather than copy-pasting each individual channel, we’re using the multi-channel functionality of Altium, which you can see above the sheet symbol for a device channel: REPEAT(MTI,1,4) will create four copies of the sheet, MTIA, MTIB, MTIB, and MTIC

In the upper-right hand corner (by default) of the schematic editor, you’ll find the Design Variants button, which launches the Assembly Variants Management window.

Adding a New Variant

Launching the Variant Management window will show you a screen like the following:

For the Basic version of this PCB, we only want to populate two of the four channels (MTIA and MTIB). First, let’s add an assembly variant called “Basic”. Find the “Add Variant…” button on the bottom left of this window and click it. You will see the “Edit Design Variant” window below:

I selected “Allow variation of fabrication outputs.” This isn’t critical, but sometimes you’ll want to omit certain footprints for components that are not installed.

After clicking OK, you should see the Variant Management window again with a new column for the variant you created. Let’s find the components that will not be fitted for the “Basic” variant of this design. In my case, I am de-populating channels MTIC and MTID, so I’ll highlight any components with either of those prefixes in the “Designator” field.

To bulk-edit these parts, right-click on the highlighted “Component Variation” field, hover over “Set Selected As” and then click “Not Fitted”.

After this action, all of the highlighted parts should now show “Not Fitted” in the Component Variation field.

Design Variants and the Schematic

Now that your design variant has been created and configured, it’s time to take a look at the schematic to check our work. Find the Design Variants button again (in the upper-right hand corner of the schematic editor by default). Next to it is a drop-down menu that shows the selected Design Variant. This field will probably show “[No Variations].” Click on the drop-down and find the variant you just created.

The default view of the Schematic Editor is the “Editor” view (so creative). If you look on the bottom toolbar, however, you will see one or more tabs next to “Editor.” In the case of multi-channel schematics, each of the individual channels will be accessible here. If the schematic is only used once, there will only be a single tab.

If I click on channels MTIC or MTID, the two channels that will not be installed on my Basic variant, the schematic editor will show red x-marks over all of the components that are marked as Not Fitted.

Nice! I would encourage you to double-check all sheets of your schematic when creating design variants, as this is an easy way to spot mistakes (such as a component that has been marked Not Fitted by accident).

Generating Outputs – BOM

Now comes the most powerful part of creating design variants – generating design outputs! The first document we’ll generate is the Bill of Materials, or BOM. The BOM lists all of the manufacturer part numbers in your design and links each one to a schematic component. This document is very important to the PCB assembly house, who typically purchases the components in the BOM and loads them into a pick-and-place machine.

When managing design variants manually, it’s necessary to indicate which components and designators will not be populated. One way to do this is to label the unused components with DNI (Do Not Install), DNP (Do Not Populate), Not Fitted, or something similar. Unsurprisingly, this is not a fool-proof solution, as some manufacturers may not recognize or understand these directives.

A better way is to eliminate the unused components and designators from the BOM entirely. Sure, you can delete them by hand, but this is inherently error-prone and can be quite time-consuming. Instead, let’s let Altium handle this for us. In your Output Job file (if this is a new project, you may have to add one using File -> Add New to Project -> Output Job File), select the appropriate design variant from the top of the window:

Then, simply generate your BOM. I selected the basic version of my PCB, which omits two of the four device channels. Let’s see what happened. The first image below is the default BOM, which does not omit any channels. Notice that you can see components with MTIA, MTIB, MTIC, and MTID prefixes.

The second image shows the BOM generated for the Basic variant, which shows only MTIA and MTIB components.

Nice!

Generating Outputs – Pick-and-Place

The second document of importance is the Pick-and-Place file, which contains the location and orientation of each component in the assembly. This is the file used by pick-and-place machines to mount components on a PCB prior to soldering.

Components that are not populated on the PCB are almost always marked as such on the BOM (or removed entirely as discussed above). The pick-and-place file is often neglected, which sometimes leads to confusion during the assembly process. I have seen situations where the “DNP” designator on the BOM was missed, and DNP components were installed anyway. Had those parts’ entries on the pick-and-place files been omitted as well, the assembly house would not have loaded the components in the pick-and-place machine in the first place.

Generating a pick-and-place file for your assembly variant is very simple. From the PCB Editor, make sure the proper variant is selected by choosing it from the drop-down menu on the toolbar (just as you did from the Schematic Editor earlier). Then, click File -> Assembly Outputs -> Generates Pick and Place Files. Voila!

Below is a WinMerge comparison between the default and variant pick-and-place files, which clearly shows that the DNP parts are completely omitted from the variant version. Even though it’s not essential to generate the pick-and-place file this way, it’s an additional way to validate the design during the hand-off to the manufacturer.

Summary

Design Variants in Altium are a powerful tool for handling situations where a base design can be assembled into multiple versions or “flavors.” This article covered the case where parts are not populated to create a “Basic” version (where the base design is the “Deluxe” version with more functionality). Design Variants can be used to change part parameters (like a resistor value or a part number) as well. If you find yourself managing a lot of design outputs manually, it might be time to let Altium shoulder the brunt of the work for you!

Learn more about DMC’s embedded design and circuit design services.

The post Exploring Altium: Using Design Variants appeared first on DMC, Inc..

Since the unit showed no signs of powering on, the first order of business was to verify the main power source. Finding nothing wrong with the 12V external power adapter, I set off to get my hands dirty and investigate the internal circuitry.

Thankfully, NI made the DAQ very easy to disassemble. The entire PCB assembly slides out in one piece after the removal of a couple screws. Nothing seemed charred or obviously damaged and nothing dramatic happened when I tried giving it power again. So, I started the highly technical operation of poking around at various chips to see if anything was hot.

Nothing felt scalding hot, but there was a section of circuitry warm enough to raise suspicion. Especially so because a nearly identical set of components nearby was cool to the touch. The hot circuits included an LM2673-ADJ adjustable switching regulator (U54) connected to a 33uH power inductor (L6) and 5A-rated BAT540C Schottky diode (D25). The circuit was regulating the 12V from the external adapter to a somewhat strange 1.2V. The neighboring circuit, on the other hand, was taking the same 12 volts and outputting a standard 3.3V.

Checking the datasheet for the LM2673-ADJ, I discovered that its output voltage is controlled by a resistive voltage divider. I found the appropriate resistors in the PCB, measured their resistances, and calculated the designed output voltages for the two regulator circuits. The circuit supplying 3.3V was designed as such while the one outputting 1.2V should have been outputting 5V.

The most likely cause of this discrepancy was that the regulator was supplying excessive current due to a damaged component somewhere on the 5V power rail. In doing so, it would trigger its over-current and/or over-temperature protection and reduce its output voltage. I checked and found that there was indeed a very low amount of resistance between the 5V power rail and ground. Whatever component was causing this would be sinking a lot of current and therefore necessarily be quite hot.

It didn’t seem like the sort of thing that’d be hard to find.

My prime suspect was diode D25 that sits across the regulator’s 5V output and ground. I removed it only to find that 5V and ground were still shorted together. I verified with my multimeter that the diode was damaged and contributing to the short, but it clearly wasn’t the only offending component. Thinking that the problem was isolated to the immediate vicinity of the regulator, I removed output capacitors C125, C126, and C127. No dice. A little desperate, I removed the regulator chip itself. 

Using an adjustable current limit lab power supply, I can feed power directly into the shorted 5V power rail. Whatever component was causing the short would surely heat up enough for me to detect. With the power supply voltage limited to 5V, I started cranking up the current. Eventually, I found myself pouring over 3A into the circuit board at a mere 1V.

I found two potential culprits. Just above the 3.3V regulator circuit, there was a circuit block that contained a power inductor designated L11 and a tiny 6-pin surface mount component designated Q38. Both were intensely hot. Under the assumption that inductors don’t just go off and fail, I turned my attention to Q38. I could make out the markings “A41AC” yet no amount of searching yielded any useful results. Frustrated, I decided to remove the chip altogether.

As soon as Q38 was gone, the short-circuit I was hunting went with it! I knew the DAQ wasn’t fixed, but I couldn’t stop myself from attempting to power it on right there. All I had to do was plug in the external 12V power brick while simultaneously using the lab power supply to replace the 5V regulator I removed.

Once connected over USB, NI MAX detected the DAQ immediately. I was ecstatic. It amazed me that the device seemed to be functioning normally. The digital I/O seemed to work, so I went to test what I needed from the DAQ in the first place: analog output. The behavior I saw was puzzling. When commanded to output +10V, I would get +2.5V. Similarly, commanding -10V would result in -2.5V and the voltages in between scaled linearly.

Of course, the one feature I needed from this DAQ was the one that was still broken.

When additional searching turned up nothing useful regarding the mystery chip, I started reverse engineering the schematic for the circuit block in which it lived. Very fortunately for me, just like the 5V and 3.3V regulators from before, there was a doppelganger to this circuit block as well. It too contained an A41AC mystery chip. Here is the partial schematic I came up with:

Q38 and L11 were the components that I had felt getting very hot. Q39 and L13 were cool to the touch. These two circuits look like classic voltage boost converters. To get a better feel for how these circuits worked, I used an oscilloscope to probe the undamaged circuit at the points indicated on the schematic.

Let’s assume the mystery chips Q38/39 are N-channel enhancement mode MOSFETs. Pins 1, 2, 5, and 6 would be the drain, pin 3 would be the gate, and pin 4 would be the source. On the undamaged circuit, the scope shows a ~1MHz square wave with ~80% duty cycle at the gate. When the gate is high, the transistor turns on and pulls the drain to ground. This forces current to increase in L11, allowing it to store energy. When the gate is low, the transistor turns off, forcing the current stored in the inductor to flow through the flyback diode, D23, to the output of the circuit. This operation matches exactly that of a boost converter operating in continuous mode. 

The relevant equation to be aware of here is Duty cycle = 1 – Vin/Vout. Since Vin is 3.3V and Vout is 20V, the duty cycle should be 83.5%. This result matches closely to what I saw being fed to the MOSFET gate. Out of curiosity, I checked what kind of waveform was being fed to the damaged circuit and found a ~1MHz square wave with ~75% duty cycle. With Vin being 5V in that circuit, Vout is predicted to also be 20V. At this point I speculated that the undamaged circuit was used to supply the reference for the DAQ’s +/-10V analog input and the damaged circuit supplies the reference for the analog output. With Q38 removed, the broken boost circuit would simply output the 5V that it was fed. This explains why I could only get the DAQ’s analog output to swing between -2.5V and +2.5V.

Now it’s time to tackle the issue of actually finding a replacement part for Q38. Using calipers, I measured the dimensions of the chip to match the TSOT-23-6 package. Searching for N-channel MOSFETS in this package on DigiKey, I found several pin-compatible parts!

Extremely satisfied with myself, I ordered a FDC5661N_F085 which had the highest rated power rating at 1.6W. I also grabbed a BAT540C and LM2673-ADJ to repair the 5V regulator circuit before running around the office to gloat over my victory.

The parts came in the mail the next morning and I eagerly got to work soldering them in their places. I first restored the 5V regulator circuit which fired up without a hitch. After that I dropped a new MOSFET to replace Q38. Giving myself a pat on the back, I powered up the DAQ to run a final test. This time, none of the DAQ’s status LEDs showed any activity. Not five seconds later, I detected a burning smell and saw the dreaded trail of smoke emanating from the new MOSFET.

After cutting the power and staring at the circuit board for a while in bewilderment, I set off to find out what went wrong. I made sure that I installed the MOSFET in the correct orientation and verified that its drain and source were not shorted together. The fact that the new MOSFET was burning up so quickly and taking out the entire power rail with it could mean that electrically it was connected directly across +5V and ground.

I decided it wouldn’t hurt too much to try to see what was going on with the oscilloscope. I hooked it up to the new MOSFET just as I had done previously with the undamaged circuit. I was able to get this trace by briefly toggling power to the board:

The strange waveform didn’t reveal much more information than I already knew. At least it was interesting to see the electrical havoc being wreaked.

I checked diode D22 to make sure nothing on the output side of the circuit could interfere with the MOSFET. That leaves us with a single remaining suspect: power inductor L11. Since inductors are simply coils of wire, I was incredulous that it could be damaged. Furthermore, a resistance measurement will reveal that they are indistinguishable from a simple wire.

Lacking an inductance meter, I set about building an inductor test circuit. Inductors resist changes to the current flowing in them, as shown by their characteristic equation: V = L * (di/dt). Applying a voltage V across the inductor will cause current to rise linearly with a slope of (V/L). The test setup I made looked like this:

The inductor under test was connected in series with a 1 ohm resistor. The oscilloscope measured the voltage across the resistor which would indicate how much current was flowing at any given time. The capacitor would be charged to 10V before being discharged through the inductor. Its purpose was to provide a low-impedance voltage source to the inductor under test.

First, I ran my test using a known good 33uH inductor I found in the lab. Here is what the scope trace looked like:

The current initially rose linearly for about 10us before jumping up to 10V. The discontinuity happened due to the core of the inductor reaching saturation. The slope of the linear region was slightly under 0.4V/us (which corresponds to 0.4A/us). Since V = 10V, we’d shown, experimentally, that the inductor was around 25-30uH.
I removed L11 from the circuit board and ran the same test. Here is the scope trace:

This time, the current jumped up to 10A immediately, showing that the inductor was behaving as a short. When this inductor shorted for an unknown reason, it caused a huge current to flow through Q38 whenever it was switched on. I figured that the 5V regulator would go into current limiting mode, dipping its output voltage to the 1.2V I measured at the beginning of my investigation. After several red herrings, we’d finally found the actual culprit!

The only thing left to do was to find a suitable replacement inductor. I found and ordered a 100uH inductor (Bourns PM3316-101M-RC) that had an almost identical footprint to our shorted inductor. In the meantime, I was impatient to get the DAQ working again. Referring back to the Wikipedia page on boost converters, we could see that as long as they were operating in continuous mode, the output voltage depended only on the switching duty cycle and was completely independent of inductance.

Feeling adventurous, I shoehorned the 33uH power inductor I found lying around into the circuit. I also replaced Q38 with another fresh MOSFET. With the oscilloscope connected, I cautiously turned on the power. Just like that, the DAQ came to life without any drama. I measured a solid 20V output from the repaired boost converter circuit and the scope trace showed a clean waveform:

I connected the USB DAQ to my computer and was able to get accurate and precise analog voltage outputs across the entire +/-10V range. Exhausted and relieved, I finally started on the proof-of-concept project for which I need the NI USB-6351 in the first place.

Learn more about DMC’s LabVIEW programming services.

The post Repairing an NI USB-6351 X-Series DAQ appeared first on DMC, Inc..

Here is a list of basic materials that you will need:

• White box fan
• Perforated board
• PIC (or any microcontroller)
• Darlington Chip
• 2 5 V voltage divider (power microcontroller)
• LEDs with resistors
• Emitter/receiver diodes
• Toggle switch (for power)
• Battery Pack
• 12 V power supply (old phone charger)
• Clay (for inertial balancing)

Here is a list of tools that you will need:

• Solder Iron
• Solder
• High gauge wire
• Knife (cut fan up)

General Process:

1. Wire Perf Board: wire LEDs in a parallel line starting at the center of the perf board and going to the edge of the darlington chip. Wire the Darlington to the switched power rail and wire inputs to the PIC. Wire the power out of the battery box to the voltage divider and then through the switch. Mount the battery box in the middle of the perf board for inertial purposes. Wire the receiver diode at the end of the color LED line facing towards the fan body.
2. Remove fan blades and keep the center plastic part for mounting the perf board. Cut grooves in the hub to fit the perf board securely, and use duct tape if needed to mount securely.
3. Mount the emitter onto the fan body so that the receiver passes directly in front of it. Use either a breadboard or solder parts of the voltage divider from the 12 V to the emitter. This will be your control aspect of the system.
4. As far as programming goes, I approached it so that the fan speed was relatively constant, and so there were programmed delays between each LED strobe to display numbers. I treated each number as an LED number display that would flash sequentially as the fan was moving in order to show the “floating” number. Then the receiver was a callback that reset the sequence.

If everything is done right, you can get something like this!

Please be careful if you try this project. Use your judgement with the use of PPE and managing voltage lines.

The post Pet Project: Turn A Fan Into A Clock appeared first on DMC, Inc..

I was eager to try it out, but unfortunately I don’t have a home phone line anymore. I hooked it up to my Voice Over IP (VoIP) adapter that I haven’t used in years. It almost worked! Well, it rang like it is supposed to – waking up dogs and babies in a two block radius. I could even have a pleasant conversation over it, but I couldn’t dial out. I heard a dial tone, but it ignored the number I was trying to dial.

The problem actually was not the phone – there is nothing could go wrong with it, ever. It’s probably bullet-proof and could easily survive a minor nuclear apocalypse (haven’t tried it, it is in my to-do list). The problem was in my Voice Over IP adapter. It’s not compatible with “ancient” rotary-dial phones, and is designed to work only with (well, also vintage) push-button phones.

Ironically, rotary dial (or pulse-dial) is actually digital protocol, and is supposed to be closer relative to VoIP than “modern” push-buttons phones. The later ones use analog encoding to transmit digits. This process has a fancy name: Dual-Tone Multi-Frequency Signaling (DTMF).

The rotary dial is pure digital – transmitting numbers as a sequence of on/off pulses. One pulse corresponds to digit “1”, two pulses – digit “2”, etc; Ten pulses represent digit “0”.

Of course I could get another VoIP adapter that supports pulse dialing, but this would be too easy. Instead, I decided to make my own pulse-to-DTMF converter.

I had a few microcontrollers lying around and decided using them to generate DTMF signals should be trivial. Obviously, it’s been done before and I found an Atmel application note to do exactly that. There is nothing special there, just using a PWM (the same method I used to play audio on the TI Launchpad) to generate an analog signal. The only difference is that I am not using any external memory here. DTMF consists of just two sinusoidal waves, so we have to store one period of the sin wave and it is small enough to easily fit to the microcontroller’s internal memory.

As I mentioned before, reading pulses from the phone is very simple. It’s already digital, just count them up – and bam you get your digit. Here is a test setup with my adapter still on the breadboard

From left to right:

• Wi-Fi to Ethernet converter. Just because my VoIP adapter doesn’t have a Wi-Fi and I don’t like having Ethernet cables everywhere
• VoIP adapter. I had the old Cisco/Linksys PAP2
• Phone (kinda obvious)
• Breadboard. Schematic below:

The phone line voltage is in the “on-hook” state. Confusing term? It seems to have originated because you are supposed to keep the earpiece on the hook and “off-hook” it in order to answer the call.

Back to the voltage. So the “on-hook” voltage is quite high, around 48V DC and even higher (around 90V AC) during the ring. I decided to connect my board after the phone switch, so I am getting the power only when the phone is in the “off-hook” state (meaning the handset is not on the phone).

In the “off-hook” state, line voltage is supposed to drop down to around 5V DC, which is perfect for my AVR, but I still added a 5.1V zener diode D1 just in case.

The rotary dial module is disconnected from the phone circuit and connected to my adapter only. The purpose of the connection between pins F and RR is to make phone think that the dial is still connected.

I am generating DTMF/PWM signal on the AVR pin 5 and feeding it to the emitter follower Q1 via the low-pass filter (C1, R3).

If you are curious, you can grab an AVR source code.

Here is the video testing the adapter

During the test I ran into the interesting issue. I noticed that AVR power consumption at the power-down mode is much higher than I anticipated (~500uA instead of ~10uA). After poking around I traced the issue to the debugWIRE interface. I was using debugWIRE to download and debug code on the AVR. Yet apparently debugWIRE draws a lot of current (~500uA). Disabling debugWIRE via fuses and using ISP instead solved the problem.

The last steps were to wire the adapter on the perforated board.

Then mount it inside the phone (thank you again, hot glue)

Done! Just put the cover on. Obviously it looks exactly the same as before modifications.

Next steps. I guess there is none. Well, maybe to record how this phone rings and use it as a ringtone.

Contact us to get started on your next Embedded Development & Programming project. 

The post Updating Your Rotary Dial Phone for the Digital Age appeared first on DMC, Inc..

Unfortunately, none of them apply to PCB design.

Designing and developing printed circuit boards can be an unforgiving process: placing a critical analog line just a few millimeters closer to a noisy clock line might be the difference between a functional widget and an expensive drink coaster. Luckily, many modern software tools provide safeguards to catch critical mistakes before they’re sent out to your favorite PCB fabricator. The most fundamental of these safeguards are the Design Rules.

In the context of PCB design, Design Rules are a set of requirements, restrictions, and constraints that the board must meet in order to be considered a valid design. An example rule might be that the minimum distance between two copper board features (like a trace and the annular ring of a via) must not be closer than 5 mils (5 thousandths of an inch). As the designer places and routes components, Altium will check the board against this rule set. Depending on the user’s preferences, errors can either be reported in the background or prevented in real-time. Sounds great! What’s the catch?

The range of possible applications for a printed circuit board is amazingly broad. As a result, tools like Altium are made to be as flexible as possible. The downside is that there isn’t a single set of design rules that can play nicely with every PCB design. The standard rules that have been developed cover a large chunk of the playing field, but the designer of any reasonably complex board will need to refine these default rules to match the application. Luckily this is a straightforward process in Altium, and we’ve developed some best practices that you can use to get going quickly.

Design Rule Editor

To get an idea of the range of design rules available within the Altium PCB Editor, open an existing design or start a new PCB project. Then, open the PCB Rules and Constraints Editor by clicking Design -> Rules…

The editor window will look like the following:

The Design Rules are divided up into several different categories, like Electrical, Routing, Signal Integrity, etc. Expanding a category shows the individual rules that can be modified for each. Let’s go back to the example earlier in this post that defines a minimum separation between copper features. That rule is captured under Electrical -> Clearance. Highlight that rule in the tree view on the left side of the editor to show the details of the constraint.

Altium decides how to apply design rules by evaluating one or more queries. In the case of the electrical clearance rule, two queries are executed: one to pick the first copper feature, and the next to pick the second. By default, the query is simply “All” which means that the design rule is applied to every object in the design. For anyone new to the query system in Altium, I recommend reading this article on the Altium Wiki.

The Constraints are then evaluated for each object returned by the queries. Here, any two items that are on different nets (3.3V and Ground, for example) are required to be no less than 10 mils apart. Most of the rules have associated diagrams that illustrate what is being controlled.

Taking Advantage of Rule Priority

There may be situations in your design where two different constraints of the same design rule might apply for different groups of components or traces. An example that has popped up on a few of my past designs applies to the Short Circuit rule (Electrical -> Short-Circuit). In general, short circuits on a PCB are a bad thing. However, I will sometimes create separate nets for my Ground and Shield connections so that I can apply different rules and routing techniques to each. The tie point on the board (where the shield and ground meet) will usually be a copper region to which both nets will connect.

The default Short-Circuit rule will prevent me from making this connection (or at least give me a warning… more on this distinction later). However, I can modify my design rules so that this connection is allowed by manipulating the rule priority.

Notice in my rule hierarchy that there are now two short circuit rules, listed in descending priority:

1. ShortCircuit_GroundShield

2. ShortCircuit_Default

When there are multiple rules defined for a rule category, Altium applies a priority ranking system to decide which rule will be executed.  First, the query (or queries) for each rule is evaluated. If multiple rules apply to a set of query results, the highest-priority rule will be executed.

In this example, the ShortCircuit_GroundShield rule applies to objects where the first is in the net “GND” and the second object is in the net “SHIELD”. The ShortCircuit_Default rule applies to any two objects. Clearly, there is some overlap in the scope of these rules. If my board had three nets – 3.3V, GND, and SHIELD, no short circuits would be allowed between 3.3V and GND or 3.3V and SHIELD, but would be allowed between GND and SHIELD.

Editing rule priority can also be useful if a small number of components have requirements that differ from the majority of the board. For example if the minimum trace spacing for the board is 5mils, but a noisy net needs to be 10mils from any other, a new clearance rule (with a higher priority than the default rule) can be added that applies only to the noisy net.

Automating Rule Creation

Altium has a built-in tool called the Design Rules Wizard that provides a friendlier interface for adding design rules to the project. I haven’t used it often (I prefer the query system, which is immensely powerful), but I do know that it is very quick to add a new rule without needing to dig far into the Rule Editor window. You can access this tool in Design -> Rule Wizard…

Importing and Exporting Design Rules

“But Ryan, I’m a rebel and can’t be trusted creating rules! What can I do?”

Despite my thoughts on the matter, I understand that some engineers are just edgy by nature. It’s okay, you’re covered. Design rules can be imported and exported within Altium, so you’re free to use rules from a more responsible source. To import or export design rules, first open the PCB Rules and Constraints editor, then right click on any item in the rule hierarchy. Select either “Import Rules…” or “Export Rules…” If you’re exporting, you can pick which rules will be included in the output file by selecting the relevant items.

A handy tip: if you know what manufacturer will be fabricating your design, see if they have design rules available that match their capabilities. Sunstone Circuits (an Oregon-based PCB manufacturer) has a compatible set of design rules for Altium available on their Downloads page.

Design Rule Check

“Okay, my design rules are set up. Now what?”

At any time, you can check your design against the current rule set by clicking Tools -> Design Rule Check…  This will open the Design Rule Checker, which allows you to select which rules will be enabled, as well as how the results will be reported.

Clicking “Run Design Rule Check” will perform the DRC, and will display the results in an HTML report (this is also saved to the project directory for access later). An example report might look like the following:

Each of these violations are linked to the coordinates on the PCB that they were observed (clicking on the violation will take you there), which makes it easy to identify the cause and (hopefully) the remedy.

Online DRC

Seeing the mistakes you’ve made is one thing, but it’s more efficient to avoid mistakes instead of going back to fix them. Altium has a feature called the Online DRC that will prevent you from making mistakes in real-time, or at least warn you if you’re violating a rule. Enable this functionality in the Preferences window (Tools -> Preferences…), under the PCB Editor -> General -> Online DRC.

The default settings for the DRC are acceptable for most designs, but you can change which violations are checked and how they are displayed in real-time by navigating to the DRC Violations Display tab within the preferences window.

Final Thoughts

Congratulations, your safety net is now installed! Altium’s Design Rule functionality is one of the most powerful and important features of the PCB editor, and I recommend that careful attention is paid to setting them up before the design is started. Nothing is more frustrating than getting halfway through a design and then realizing that a critical requirement has been blatantly violated all over the place.

No safety net is perfect and you should always take steps to verify your design beyond the design rule check (whether that is a peer review or a prototype run). That said, I hope you found this tutorial informative and useful. Leave any comments or questions below and don’t forget to check out the other articles in the Exploring Altium series!

Pin Swapping

Document Management

The post Exploring Altium: Design Rules appeared first on DMC, Inc..