Archive for the ‘Benchmarks and Reviews’ Category

Probotix X90 CNC – Cutting Servo Mounts in Sintra PVC Foam Board



This is the first cut of my Probotix X90 CNC. Absolutely amazing!

I am using the EMC2 Linux CNC installed on an old computer installed using their Live/Bootable CD.

The model was created in Sketchup 2013 then exported to STL using this plugin :

Then I used MeshCAM 5 to convert the STL to GCODE file.

As a cutter I used a 1/16 4 flute carbide bit normally used for PCBs – the only one that I had available, but specialized 2 flute cutters should work better – I might try that. You’ll see this bit creates a lot of burring so parts needed cleanup.

The bit is mounted in my trusty Dewalt DWP611 router :

I am using a 1/4 to 1/8 collect adapter since the DWP611 comes with only 1/4 adapter.

It gives me good run-off of max 2-5mil which is ok for my application.

However ultra-precise collets can be found here:!!!Dewalt_611!!!Kit!!!PG!!!

They claim a runout of ~  0.4 mil

Here is the final result, I simply glued 2 parts together to make them thicker. You’ll see that this is a servo mount for 9g Hitec servo on 13x13mm aluminum tubing that I got from HobbyKing



Hope this helps. Happy CNC-ing !


Build a really fast pulse generator (50ps rise time) using an ultra fast SiGe comparator.


If you purchase a new or used scope you will probably need a way to test its advertised bandwidth. One way to test the bandwidth of the scope is to feed a really fast pulse into the oscilloscope and measure its rise time.  The reason why this makes sense is because a square wave contains many higher frequency harmonics. The frequency of its highest harmonic will determine the steepness of its falling or rising edge. If you look at a sinusoid wave of 1Ghz and one of 1Khz – the 1Ghz wave will have a steeper slope than the 1Khz sinusoid. A square wave or a pulse consists of the sum of many sinusoids, your scope bandwidth limitation will discard or attenuate the higher frequencies components and thus will alter the steepness of the wave that you see on your screen.

The bandwidth of the scope will be then given by the formula:

Bw = 0.35 / Tr      (Note: 0.4 / Tr  is sometimes used for modern digital scopes)

where Tr is the measured rise time of the pulse on the oscilloscope. This formula only stands when Tr >> Tra (Tr is much larger, usually at least 10 times than Tra)  , where Tra is the actual rise time of the pulse. I will describe a quick circuit for building a fast pulse generator with a Tra of 50ps. 50ps corresponds to a  bandwidth of  0.35/50ps  = 7Ghz, so you should be safe to evaluate bandwidth of scopes up to 700Mhz. For scopes with larger bandwidths you can still use same method but you need to take into account Tra, the formula becomes then:

Bw = 0.35/SQRT(Tr^2 – Tra^2)


The Circuit

The circuit uses a single chip, ultra fast comparator ADCMP580 available from Analog Devices.




For this circuit you will need a dual rail power supply (+5/-5V) , if you don’t have one you can use an ATX power supply from a computer case – it has both +5V and –5V rails. You will also need a way to generate a (slow rising) input pulse that the circuit above will convert to a fast rising (50ps) pulse.

The input pulse must not exceed +3V/-2V according to ADCMP580 datasheet. Keep this in mind If you’re using your Arduino  or a 555 timer circuit to feed in the input pulse , you will probably want to feed the pulse through a voltage divider if it exceeds these levels. Take into consideration that the ADCMP580 already has an internal 50Ohm resistor that you might use for your voltage divider.  Also please note that if you signal goes only from 0V to 5V , Vn will need to be somewhere in-between, again you can form a voltage divider to set it at about 2.5V. The outputs Q/Qb will toggle when your signal crosses the threshold set by Vn. In my case since I have a pulse generator that feeds a pulse from –1.25V to 1.25V (2.5Vpp) I am setting my Vn  threshold to ground. I am also using the internal 50Ohm termination just to place some “weight” on the circuit and filter out any noise pickup.

Rh is the hysteresis resistors this can be  anywhere between 0 to 10Kohm. I found that a value of 100Ohm worked great for me . Let’s say your signal is going up but then because of the noise it decides to go a little down, hysteresis feature of ADCMP580 protects against the output reacting to that noise, the output signal will only go back down when the voltage will fall Vhys below the point that made it go up. Below is a chart that describes the relationship between Vhys and Rh. You can see that in my case since I am using a 100Ohm resistor I have about 55mV of a buffer zone, so my output will not fluctuate if the noise level is less than roughly 55mV, in other words it will always take more than 55mV change in signal to toggle the comparator back in opposite state.



The Build and Results

Luckily Analog Devices offers an inexpensive ADCMP580 demo board, I picked mine from Mouser for around 50 dollars. The board is basically a breakout of the ADCMP580 chip with some decoupling capacitors and 2.9mm connectors for signals and standard 4mm banana sockets for the power supplies. Fear not the 2.9mm connectors , they are generally compatible with SMA connectors so I used some SMA-M to BNC-M cables to connect the signals to my scope and signal generator. (Some people will warn you that if you have some very expensive equipment do not use SMA connectors with 2.9mm connectors – the tolerances might be different and you might break the connectors on your expensive equipment). I also used some 50Ohm SMA terminators, on the QB, LE and VN connectors. The schematic above calls for LE and VN to be connected to ground via wire, however I found that a 50Ohm cap did the job. In case of QB connector it must be terminated with 50Ohm to ground, even if you’re not using its output so the 50Ohm terminator is required. LEB is connected to VEE (-5V) via a 1Kohm resistor and you might notice in the picture I have a 100 ohm resistor in the HYS slot (see between the black Q and red VEE cable).  You can see that the VTF_F, VTP_F, VTT, VCC0, CGND are left unconnected (the necessary connections are made by the blue jumpers on the board). Please note that although VCC1 may appear unconnected on the picture there’s an alligator clip under the board that connects it to the +5V rail of the power supply.




Once I completed the setup above I fed in a 2.5Vpp(@50Ohm load)  1Khz square wave into  VP,  my Q output was connected to my 500Mhz bandwidth oscilloscope, below is the result of this experiment:




The rise time of my input signal (Ch4) is 16.57ns while the rise time of the output (Ch1)  is 536ps (average) with a dispersion of 36ps, the momentary reading when the screenshot was taken was 590ps. So let’s calculate the bandwidth of the scope, I am taking a conservative approach using the worst number of 590ps:

Bw = 0.35 / 590ps =  0.35 / (590* 10^-12) = 0.000593 * 10^12 Hz = 593 * 10^6 Hz = 593 Mhz

So my scope has a bandwidth of no less than 593Mhz on Channel 1.  This is above it’s rated bandwidth of 500Mhz.


Conclusion and some notes

For around $50 I created a very fast pulse generator setup that allowed me to evaluate the bandwidth of my scope. 

Please note that if you read the ADCMP580 datasheet you will find a Rise/Fall Time of 37ps, however this is the rise time from 20% to 80%, the scope measures the rise time from 10% to 90%. I simply prorated this number  37ps * (90-10) / (80-20)  = 49.3ps ~ 50ps to get the rise time from 10% to 90%.

You will also see in datasheet the advertised equivalent rise time bandwidth of 8Ghz , I believe this comes from the formula 0.4/50ps = 8Ghz that applies to many modern digital scope. In my calculations I used the “old” conservative formula of  0.35/Tr instead of 0.4/Tr.

Finally please note that the output of ADCMP580 uses CML levels of  0V(High) and –0.4V(Low) according to datasheet. I found these levels to be actually lower in my setup (-0.472V High and -0.868V low), but with same difference of about 400mV as you can see in the scope screenshot below. If you have an explanation for this please leave a note in the comments section.





ADCMP580/ADCMP581/ADCMP582 Datasheet:

EVAL-ADCMP580BCPZ Evaluation Board

Evaluating Oscilloscope Bandwidths for Your Application

Digital Oscilloscope Bandwidth Measurement – direct and using risetime

Basics of Analog Oscilloscope Bandwidth

Analog Oscilloscope bandwidth considerations

EEVblog #306 – Jim Williams Pulse Generator

EEVblog #311 – Jim Williams Pulser Followup

EEVblog #316 – More PFANG, More 13GHz Scope, & More Pulser


Parts List


SMA-M Bnc Cable

SMA Terminator 50Ohm

Triple Power Supply

Function Generator




Shpero – a robotic project success story

I recently got my first Sphero and I have to admit as with any new product I was skeptical in the beginning. However just after few minutes of playing with it I had to admit – boy, this stuff really works and is  lots of fun !  Sphero is a simple ball (well, not so simple on the inside) robot that you can control via your tablet or phone via bluetooth (major devices supported). There are many available apps on the market besides the stock control app. It also has a nice SDK that allows to use Sphero for your own projects. Because it contains an IMU sensor inside, Sphero can be used as controller for a game or application.

Only few years ago Shpero was just a crazy idea. Now Ortobotix is a company with dozens of employees. As it happens with many new projects Sphero was not perfect from the start. At their lowest point the founders (Ian Bernstein and Adam Wilson) admit they were so depressed that they were contemplating to pull out of CES 2011 at the last moment. Then something magical happened and the team was able to sort out all problems making it a hit at 2011th CES ! Morale of the story – never give up!

To find out more about the Sphero’s success story read up here: .  Sphero is available on Amazon and other retailers. Get yourself one, I guarantee it – it’s not just a toy but also a great research tool if you’re into electronics or robotics !


Tenma 72-7740 Autorange Multimeter Review

When it comes to test equipment a hobbyist is often asking himself – should I invest in top of the line equipment or can I compromise and go with a mid-range or even low-end version ? It obviously depends on the budget you have. The truth is that not everyone has $300-$500 dollars to invest in a top-of-the-line multimeter.

In this article I will review the Tenma 72-7740 Multimiter which aims to provide most of the functionality of an advanced multimeter , but at a lower price. So let’s see how well it does it.

First let’s have a glance at the specs of this device:



These specs are not the best you can get , but very reasonable for the price tag you pay (around $72 at element14). For instance a Fluke 87-V could give you a DC Accuracy of 0.05%+1 but at a much higher price tag.

Next let’s go through some features of this millimeter and examine them in more detail.

Box Contents



The box contents are: the multimeter, a set of probes (sharp ends and decent quality) , a temperature probe, the manual and the battery.

Basic Operation, Look and Feel

The multimeter seems well build, no flimsy parts , the dial does not have well defined detents so it is actually possible to move it to a position between two points. The stand is solid an you can operate the dial and buttons with one hand while the multimeter is resting on stand.

Autoranging  Feature

I tested the auto-ranging speed of this multimeter in Voltage mode and it seems to lock within 2 seconds – pretty impressive and much faster then I expected. The lack of a bargraph that you would find on a higher end multimeter is however a minus and you might miss some fluctuations that cannot be represented by the digit display. Other measurements such as Resistance and Capacitance seem to be slower to lock but still fairly fast.

Voltage Measurements

Perhaps 90% of measurements you do with a multimeter are voltage measurements. And this multimeter does it well and within specs – no complains here. If you don’t like the autoranging feature you can switch to a fixed range by pressing the “Range” button.

Resistance Measurements

Seems to be within specs, however if you touch the leads of the probes the multimeter will start with a value that seems to be the true resistance of the probes (~0.4Ohm) but then will slowly decrease to (0 Ohm). This seems to be a very odd behavior, perhaps some “clever” way to compensate for the resistance of the probes,  but I would prefer it showing the true value of the leads resistance, rather then trying to compensate for it. If I would want to exclude the resistance of the leads , I could press the REL button while touching the leads, thus nulling out the leads’ resistance.

Current Measurements

In current mode this multimeter has a considerable internal resistance, this is particularly noticeable in the low-current ranges. So be aware if you measure small currents this multimeter might actually affect your current by as much as 10% based on my tests.

Temperature Measurements

Seems to be within specs, however while the rating of the multimeter is “up to 1000C”, the black insulation on the supplied probe will start to melt at about 300C – it seems to be a regular shrink wrap tube.  So if you’re planning to measure anything near 1000C you will need a different probe.

Capacitance Measurements

Seems to work well. I recommend pressing the REL button before measurement to compensate for the capacitance of the leads. One annoying fact about this multimeter but also others is the lack of the pico-farad range.

Frequency / Duty Cycle Measurement

Seems to work as advertised – a very useful feature if you don’t have an oscilloscope available for basic frequency/duty cycle measurement , however when I fed a certain round number frequency like  1000Hz from my frequency generator , it always seems to show one least significant digit lower like 999.9Hz. Since these are digital measurements I don’t think it is so hard to be spot on … especially on lower frequencies.


The backlight is non-uniform, the diffuser seems to fail doing its job. The green color is very “retro”. However honestly,  if I ever find myself using a multimeter in the dark I wouldn’t complain much as long as I can see the numbers .



The multimeter is held together with two screws that are hidden behind the rubber feet. However to completely remove the cover you need to reach two plastic latches with a flat screwdriver on the other side. There’s a basic shield, that is basically a piece of foil laminated in plastic – not sure how effective it is especially because the shielding is only on one side. The screws are self-tapping type , no metal inserts. The buzzer is mounted on the cover and two springs on the PCB are used to make contact with the buzzer. Input protection has two fuses – you need to remove the cover to replace them, it would be better if they were accessible from the battery compartment. There are no hanging wires – which is good , battery connectors are mounted on the PCB. The bottom part of the PCB has some calibration pots.




By removing more screws and flipping over the PCB we can reveal more components:


The main processor is a CS7721CN (by SEMICO). I couldn’t find the datasheet for this chip however an interested reader could fish it out on Google with some more research. The other 8-pin chip is marked as 220Z3 , again couldn’t find any info on it but I suspect it is either an ADC or an op-amp chip.

The assembly quality seems to be decent – mostly SMD parts. As you can see the input protection is very basic, no serious PCB isolation, or blast protection walls on the case. Although the multimeter is rated CAT IV 600V / CAT III 1000V, some might not be comfortable using it at such high voltages given the very basic input protection.


The Tenma 72-7740 is an affordable multimeter that has some advanced functions that can be found on higher end multimeters. It is a good compromise for those constrained by budget. It certainly does its job in the voltage measurements department, but some of the add-on features need some more refinement. Still a good value for the abundance of features that you get for the price.


Many thanks to element14 for providing this sample for review. For the full line of digital multimeters that element14 has to offer please visit:


USB firmware debugging with USBTrace, PicKit & MPLAB IDE

Ah, the joy of firmware debugging! I’ve been working on a USB firmware for my new upcoming product that involves a dual traditional TTL (Serial) and a USB-TO-SERIAL converter (CDC Communication Port) implemented in the same firmware. The firmware was written in C18 , using the USB stack from Microchip Applications Libraries.

Everything worked well until I suddenly discovered that while sending data over the CDC port from the computer to the device, the device would *sometimes* receive garbage data instead of what I sent. This wouldn’t be so discouraging if the data received would be the same, or at least this would happen always not *sometimes*.  The bug was caught in the act on the screenshot below, the arrows show the data I actually sent ‘stop’ followed by LF (0xA) char and the character codes (in decimal) actually received. This is garbage because 92,162,62,180 are note the ASCII chars for ‘stop’.  Please note that this will only occur *sometimes*, however I could almost consistently repeat it after several retries of sending a command to the device.


The tracking of this bug turned out to be so adventurous and involved that I decided to write a tutorial about it. It involved some tools that I didn’t use often before, but now they proved indispensable in locating this furry and fuzzy code pest . As you’ll see at the end of the article the bug was pretty obvious at least for me (I already made this mistake many times , but forgot about it), however it might be really useful for someone just starting working with microcontrollers,  C and/or  interrupts. It also provides an opportunity to review some tools I used in the process.

So where do we go from here ? Same data is send over a USB CDC Serial Emulator Port  but sometimes the microcontroller receives garbage instead of the original data. A general rule of thumb is – start at the source and go up. Let’s identify the possible problems:

#1  – the computer terminal, or USB driver has gone crazy, it is sending something else instead of what was typed
#2  – there’s a hardware noise problem on the USB lines
#3  – there’s a bug in the Microchip USB Stack
#4  – there’s a bug in my code

Ok so we start with #1 , how do we see that the terminal is actually sending the correct data ? We need a way to see the actual packets send via USB. For someone who had a hardware USB protocol analyzer it would be a good time to power it up. Unfortunately these devices are really costly (let me know in the comments if I am wrong and you know any affordable solutions), and luckily for us there are decent software USB protocol analyzers that we can use instead. The tool that I used and that I highly recommend is USBTrace. It is not free , but still affordable and a great value that will pay off if you value your debug time. The reason I like USBTrace is that is so easy to use. You know a good product because after you start it you don’t have to read a manual to perform a basic function. Once I started USBTrace on the left side I was able to find a list of all USB devices, it was easy to track down my virtual CDC Serial port because in the bottom panel I could see the device descriptors. Please note that I also had connected a FTDI serial converter that I could have confused with my device. However my device had some strings in the descriptor that I recognized from my firmware such as “CDC RS-23 Emulation Demo”. Once I checked my device I was ready to click the green Run buttons. And the packets started pouring in …


Wow , that was an overwhelming number of packets! My device was in streaming mode and sending a lot of data to the EndPoint #82. I only needed data that I send to device so how do I do that ? Again USBTrace was great and very intuitive , clicked on the funnel icon (Filter) and I got following dialog:


Here I was able to set the Direction of the packet – OUT. Please note that for USB packets , by convention , the direction is as looking from host – so OUT from computer to device. I also set the CDC OUT endpoint as specified in my firmware #2, finally I set the request type to BULK_OR_INTRRUPT_TRANSFER.

Now all I had to do is to send the ‘stop’ command couple of times until the bug happened again, that was easy to spot since the streaming would not stop once garbage was received. And once it happened, I checked the contents of the last packet in USBTrace, and what do I see:


The data is completely correct, so my first guess is ruled out. Let the bug hunt continue. Moving on to #2.

#2 – there’s a hardware noise problem on the USB lines

I had a look at the cables, I had a look at the device, I knew the hardware setup worked perfectly before. If I had a hardware USB analyzer I would hook it up. But I didn’t so I took a leap of faith and I skipped #2. This wasn’t by the books. However it was all I could do in reasonable time. So moving on to #3.

#3 – there’s a bug in the Microchip USB stack

Once you download the USB stack, and integrate into your project , it becomes part of your project. So tracking Microchip’s bug was no different than tracking my own code bug. So I moved to #4 and handled #3 in the same step.

#4 – there’s a bug in my code

Ok so here we are in the MPLAB IDE 8.83. My PIC device is capable of up to 4 Hardware breakpoints. This means that the MCU can halt on specific memory locations, it also can halt when a specific memory location is written or read.  By scanning through the USB Stack code, I found that it stores the incoming  USB CDC data in the cdc_data_rx[] buffer . From the .map file I was able to determine that this buffer address is starting at 0xE08. The MAP file is basically a file the compiler creates and where you can find all your variables and code and at what address they are stored, look for it in the same folder where you output .hex file is.

Setting a memory breakpoint is accomplished by clicking on the “ADV.B”  blue button in the debugger toolbar, this brings up a dialog like this:


I just punched in the address of my buffer, selected access type as Write. Now when the first byte in the incoming CDC buffer is written with good / or garbage data the code should break and point me to where the data writing happened. Again I stared sending data, and I had to click on the green debug run icon couple of times, to skip through good cases until the bad garbage write happened. The MPLAB debugger didn’t stop every time the bad case happened , I am not sure if this is a limitation of the debugger or something caused by my code bug, but finally it stopped at a place where I defined some code that was executed inside an interrupt.


This is the code for receiving the data over the other port the TTL USART, not the one having problems CDC Serial !  It basically fills out a buffer called usart_rx_buf, but this not the cdc_data_rx buffer so how could they interfere?  Eureka ! Buffer overflow – the index used to access the buffer byte  uasart_rx_pos was going crazy out of bounds. Indeed I looked at how usart_rx_pos was declared:


The only other place where this variable was used was in this non-interrupt code:


Now this is a big problem, let’s look at the last statement

usart_rx_pos = 0

If we look at the disable of this instruction, on a PIC 8 bit controller we can see that it takes actually 2 instruction to complete it:


This is because this is a 2 bytes variable . Now think what would happen if the interrupt happens between these two instructions. The interrupt mentioned above modifies the variable. So while the main code thinks it has “0” in usart_rx_pos, in fact it only sets to 0 the second part of the variable the first one could have been modified by an interrupt! Thus the unpredictable behavior … usart_rx_pos becomes a random variable which causes the buffer overflow. Data is written at random locations in program memory . Scarrrrrry !

So how did this happened , even if  “I’ve been there done that” many times ? Well the timer interrupt code was not inside an interrupt initially , I later migrated it to an interrupt and forgot to do a sanity check of variable types. In fact I don’t need an int for usart_rx_pos (the buffer is smaller than 255). So I changed it’s declaration  to:


Now that writing of one byte is done in single instruction there’s no risk of corruption by an interrupt updating same variable. However as we’ll see below this is only part of the solution. Below is the disassembly code of writing 0 to a one byte variable:


Please note that I also added an important ‘volatile’ specification in front of all variables modified by the interrupt code.  Actually the lack of ‘volatile’ was my second guess why the bug happened. Without ‘volatile’ compiler might think that there’s no other place where the variable can change besides the spot it compiles. So it might optimize the code in weird ways. Here is an example, if a variable is not volatile the compiler could theoretically update this code

x =  1;
y = 0;
x = 1;

to simply

x = 1;
y = 0;

It removes the second assignment of x since it considers it redundant, while in fact if you have an interrupt executing let’s say before y=0 , and modifying x=0 thus in this case the  x=1 at the end is necessary ! So ‘volatile’ basically tells the compiler that a variable can change suddenly ‘out of the blue’ and it should take care while optimizing the code and not to remove any assignments even if they look redundant.

I’ll now present my final solution to ensure the interrupt code does not modify usart_rx_pos and usart_rx_buf  while we’re processing it in non-interrupt code.  The solution is to prevent the interrupt from happening during that time. No worries, if interrupt has to happen while it was disabled by us -  there ‘s usually  a flag set and the interrupt will happen eventually once we’re re-enabling it. Because the processing in session_new_char() might take a while (and you don’t want to disable USART receiving interrupts for a long time) my strategy was to declare two SAFE non-volatile variables and copy data over quickly then re-enable the interrupt. Please note that this code would work fine even if usart_rx_pos was an int (dual instruction assignment) :





Please note that I didn’t have to disable all interrupts, it was enough to disable only the interrupts that would cause our variable to be modified (the USART Receive interrupt). It’s enabled  or disabled by the RC1IE flag in PIE1 register.

After testing this new code, the problem was gone. So now I am thinking “everything is for the best” , I spent some time tracing a bug, but I learned along the way and sure thing  I wrote this tutorial so I never again forget that interrupts can modify variables when you don’t expect to !

Bottom line:

A.  Declare variables modified in interrupts as  ‘volatile’ to stop compiler doing nasty things to them
B.  Disable the interrupts that can modify those variables, while working with these variables in a non-interrupt code (both reading and writing), this will create a so called ‘atomic’ code, called so because it cannot be split by an interrupt.
C.  Keep ‘the atomic’ code short – the interrupts can wait , but not for too long in some cases.  For example the hardware USART buffer on my device only has 2 bytes – so it would get filled and lost soon if the processing done in the interrupt   would be halted for too long.
D. Have fun. Life is beautiful even when debugging Smile


Hakko 808 Desoldering Tool Review

If you're into electronics sooner or later you will need to desolder something. Also, if you don't have the proper tools or skills you'll damage a component or two or even the PCB. Been there done that – desoldering braid, cheap one-shot mechanical pumps, running the soldering iron from one pin to another … until one day I decided to look for a good professional desoldering tool. First I  purchased an all-in-one system that among the soldering iron and hot air,  had a desoldering funtion. The pump was in the main unit and the desoldering iron was connected by a rubber tube. As it turns out these units have a typical design flaw – because the pump is so far away from the desoldering iron  tip the suction is somewhat weak. Keep in mind that air is flexible so the longer the tube the more pressure is lost along the way. So if you're buying such a unit make sure the pump is really strong and has a gauge that will allow you to monitor the pressure. That unit has been returned and I am not even going to mention its name ! Then I came across Hakko 808 and until this day this is one of my favorite tools in my workshop. The suction power of this tool is amazing, easy to handle , heats up quickly , not very expensive. It requires regular maintenance (it's almost like a pet), but if you take care of it you'll save hours of work and many components and PCBs. Here is an example of what it can do, I received this LiPo charger with some terminal headers that I wanted to replace with different ones:

Read More »

Exploring a digital I2C/SPI accelerometer (MMA7456L) with Bus Pirate

Bus Pirate is a great tool for exploring new chips using your PC , without the need to integrate the chip into a MCU project. Once I received my unit, i decided to put it to the test by exploring an accelerometer with I2C/SPI interface – the MMA7456L from Freescale. I am writing this in hope that it will help other people get started with BusPirate and I2C protocol in particular. I will only describe the I2C interface in this article but BusPirate is capable of so much more !

The setup of BusPirate was simple. Simply plug it to your USB port, install the FDTI driver (if necessary). After that it will appear as a virtual COM port on you computer. You then can use your terminal of choice to interact with it. Here is sample session in Termite (my choice of terminal software):

bus pirate terminal termite

Read More »

Accelerometer Experiments – Part 2: LIS331AL and DE-ACCM2G (ADXL322) . Filters, amplifiers and vibration response.

In a previous article I have analized 3 accelerometer side by side comparing their noise level. Today I am going to test a 3 axis accelerometer from ST  LIS331AL. I am going to compare it with the DE-ACCM2G accelerometer from Dimension Engeneering.

For testing purposes I have mounted the LIS331AL on a break-out board. If you're interested how this board can be done and device mounted make sure you read my article "DIY Surface Mount on a Budget".

I have connected both accelerometers to my USB Gamepad device  and will be using the Gamepad Configuration Software to trace the signals (although an osciloscope could be used instead).


Read More »

Accelerometer Experiments – Part 1: DE-ACCM2G (ADXL322), LIS244AL, Pololu MMA7260QT

In the process of developing my usb motion gamepad I got a chance to work with different accelerometers. In search of the perfect device I wish there was a place where I can go and compare them side by side.  The problem is that different manufactures have different methods of testing the noise parameters so the only way to get it right is to have them tested by a third party. I will start by analyzing 3 accelerometers I have in my possession, and hope to review more as I get my hands on them.

The accelerometers I will test are:

1) Dimension Engineering DE-ACCM2G (this is the older model based on Analog Devices ADXL322 chip datasheet ).  It is now being replaced by a different model DE-ACCM2G2 based on LIS244ALH chip from ST). This is a quality product that unlike other break-out boards has a built-in amplifier.

2) Second device is a bare-bone LIS244AL ,  a self-mounted using reverse mounting method (yes it still works ! :) ).

3) Finally is one of the cheapest accelerometer break-out boards out there the Pololu MMA7260QT.

Recently I completed my Gamepad Configuration Utility and decided to put  to use for something it was not necessarily built for. I connected 3 accelerometers (to precize their X axis output) to the analog ports of PIC18F4550 (one of my gamepad prototypes "The Brick").


Read More »