Digilent just launched the Cerebot MC7 development board. It is based on the Microchip powerful dsPIC33FJ128MC706A digital signal processor and it features 4 onboard half bridges circuits rated for up to 25V 4A. Compared to their previous development boards based on Microchip microcontrollers like the PIC32 this one has a dedicated DSP which should improve your performance when doing digital signal processing. The board is currently priced at $119.

This was actually the first time I ever needed to multiplex analog channels so it was a good opportunity to learn how to use them. My task was to measure the temperature of 32 thermistors (NTC) with a microcontroller and later process that data. Obviously you cant find that much analog input channels on your common microcontroller so you need to multiplex the signals. First I looked for large analog multiplexers with 16 input channels but those are way too expensive. As it turns out its cheaper to use more smaller 8ch multiplexers(example Digikey pricing: 2pcs 16:1 mux from TI is $7.84 while 3pcs of 8:1 mux from TI is $1.53). I was able to get the 74HC4051 at a good price so I started creating the design around it.

With just four 74HC4051 I can multiplex 32 input channels to 4 outputs. The 74HC4051 has 3 select lines A,B,C and one enable line E. These 4 lines are used for control and they can be tied together like I did for controlling all 4 chips with the same 4 lines. By a combination of state (high/low) for A,B and C you can control which input gets connected to the output. In the schematic you will also find a table with the address select concerning the 3 pins A,B and C. The enable pin is used to disconnect all internal switches (when high) or allow connection (when low) by selecting the appropriate address. Each 74HC4051 got its own 0.1uF decoupling cap close to its supply pins and if you’re design is very sensitive to noise you can further optimize the layout and place more filtering on the supply lines.

To get a more stable reading at the output of the thermistor(actually at the output of the multiplexer) I also placed a low pass filter which later on after assembling and testing turned out to be unnecessary even creating problems because I was switching the lines faster than it took the filter to settle so I left the filter components out during assembly.

The PCB was manufactured at home hence the big vias and it was designed to allow a second board with the microcontroller to be stacked on top of it. Everything was tested on an Arduino and it works perfectly. The schematics and board file are released under CC-BY-SA and can be downloaded from the link bellow.

Downloads:

Eagle schematic and board file.

I spent the past 3 hours debugging my code that was absolutely fine. So just a quick note for everybody who’s working on pic32′s, if you’re using any math functions you have to include math.h; it is not enough to include the peripheral library (plib.h). The compiler won’t complain but you will get garbage out of your math functions.

And if you’re wondering what I was doing with all that math is just computing the temperature for a thermistor using the Steinhart–Hart equation.

I bought this multimeter(Minipa ET-870C) a while ago for $17, great value. I got it because its nice to have around multiple meters for when you wanna measure both input and output voltage/current. I believe it was advertised to have an auto-off feature for 15 mins but it didn’t. This eventually lead to many drained batteries because I often forgot to turn it off after using it. So during a boring weekend when the weather outside was bad I decided to add this nice feature to the meter. I knew it had to be a small circuit to be able to fit inside the multimeter so I picked the tiny25 the smallest micro I had around.

I quickly put together a simple schematic in Eagle, just the mcu, a voltage regulator a npn transistor and the associated capacitors and resistors. The circuit is powered from the multimeter 9V battery and cuts off the ground path to the meter to turn off its power. No ISP connector was placed on the board to save space but extra long pads were added so I can solder some wires for programming the mcu.

The npn transistor has its base pulled down so when there is no signal coming from the mcu the transistor is off. The pcb was made using the photo etching technique and it was assembled with some solder paste and hot air gun. I also soldered some wires to connect to my MKII programmer and I started writing the code.

To keep track of the time I used Timer0 to generate an overflow interrupt. Knowing the CPU frequency and the prescaler we can find out how often that interrupt will occur. Knowing how often the interrupt will occur we know how many times we need that interrupt to trigger to account for a given time in seconds. This is all calculated inside main.h where you can also specify the time in seconds.

To start the counting process I’m using a tact switch connected on INT0. When the button is pressed the level changed interrupt will trigger on INT0 and we change some flags to start counting as well as turning on the transistor to turn on the multimeter. When the counting reaches the setpoint, the flags reset and the transistor is turned off, thus turning off the meter. At this step the code was running ok except that for a 15 mins period there is ~12s error. I suspect this is because I’m using the internal oscillator which is not very precise.

Since the circuit was intended for extending the battery life, itself had to consume as little as possible. All measurements were made right before the voltage regulator at the battery leads. With no optimization the current draw at 9V was 3.67mA. The tiny25 has 3 sleep modes: Idle, ADC Noise Reduction and Power-down mode. The Idle mode would be good for when we are counting until the setpoint is reached, and the power-down mode for when we are waiting for the button to be pressed(INT0 interrupt trigger). So I’ve added some new lines of code to set the processor into Idle mode when the button is pressed, and to set it to power-down mode the the setpoint is reached and the transistor is turned off.

// Prepare for sleep mode in Idle mode so Timer0 can continue working and providing interrupts
set_sleep_mode(SLEEP_MODE_IDLE);

and

set_sleep_mode(SLEEP_MODE_PWR_DOWN);	// Prepare for sleep mode in Power Down mode

With these new settings the numbers are: in Idle mode the current draw is 3.57mA(only 0.1mA saved) but in power-down mode the current draw is only 17.9 uA(a whopping 3.652mA saved). This will ensure the battery life is not affected by the small timer circuit.

Now that everything was finished all I had to do is mount the small pcb inside the meter. Luckily there was plenty of space between the LCD and the logic board. I attached the pcb with some double sided sticky tape and drilled a hole for the tact switch in a pre marked place(this was probably the place designated for an original on/off-standby button that would of reset the internal auto-turn off feature). The tact switch was fixed in place with some hot glue. The wires were carefully routed on the side of the case and everything was assembled back together.

Now I know what you’re thinking, this mod makes the meter more dangerous with all the wires running so close to the high voltage input jacks but this meter did not have much protection to start with. Only basic 250mA fuse on the small current scale so I don’t think I’ve made it more dangerous than it already was. I really don’t recommend getting this meter if you’re working with high voltages or currents. This is only suitable for small currents/voltages where the input protection isn’t going to make a big difference.

Also you should know that the mod will certainly void your warranty if there is one. I certainly didn’t had any real warranty with this meter.

The source code and Eagle schematics are accessible on github here. As you can see this was also a nice opportunity to get me started with using a code repository. And here are some pictures from the construction/assembly process:

If you ever get the message “Entering programming mode.. FAILED!” while trying to program your AVR device don’t start messing with your MKII or upgrade its firmware 10 times or messing with the windows drivers like I did, cause that’s probably not the cause and you risk damaging you’re perfectly working MKII. As it turns out its just a faulty connection between the programmer and the target board. This is not likely to happen if you only use the programmer occasionally but I used it for like 50+ times a day and that meant inserting and removing the little 6pin connector a bunch of times. I removed the old 6pin connector, crimped a new one and its working again, so long live the MKII because it is a great tool.

You might be wondering why would I need to use that many times, well its because I’m working on this new project, a quadrocopter based on an atmega64. The microcontroller was chosen because I had a bunch around and ATMEL was kind enough to send me a ATAVRSBIN1 for my project.

The Inertial One System Board delivers a full 9 degree of freedom sensor platform comprising a 3 Axis Magnetometer from AKM (AK8975); 3 Axis Accelerometer from Bosch (BMA150) and a 3 Axis Gyroscope from InvenSense (ITG-3200) connected through an I2C interface.

At $54 its probably the most accessible 9DOF breakout out there and it comes with great sensors. Unfortunately I only managed to test and fly with the ITG-3200 gyro before I had a crash(you crash allot when developing from scratch a new firmware for a quad). Because of the crash a short-circuit happened somewhere on my board and it messed up the ATAVRSBIN1 sensors.

The ITG-3200 is a very good gyro with low noise so to replace the damaged ATAVRSBIN1 and to continue flying I got a wii motion plus which has the ITG3205 inside(its supposed to be just an OEM version of ITG3200). I haven’t done allot of testing with this new ITG3205 but I did notice some problems on the I2C bus, like sometimes the sensor does not respond , which is strange.(maybe the 400KHz freq is too high for the ITG3205 ?).

Anyway enough for now, I’ll post some updates on the project soon.

I have also been working on the new expansion board pictured bellow. The Expansion Board was created to help you create bigger custom displays for the Spectrum Analyzer. The Expansion Board works by switching the signals from the spectrum analyzer with the help of high current MOSFET transistors thus giving you the possibility to output higher voltages and currents for your custom setup. You can read more about it on the forum.

There is also a new assembly guide for the audio spectrum analyzer V2.1 that will be helpful to those that get the kit unassembled.

When Gabriel Anzziani from gabotronics.com asked me if I would like to do a review of the XMEGA Xprotolab I said yes because although these small devices cannot replace a real tool in an electronics lab, they often serve as development boards for the devices used on them. The Xprotolab is a miniature mixed signal oscilloscope and waveform generator packed in a DIP module which makes it great for breadboards. It has a nice set of features for such a small device:

for oscilloscope mode:

• 2 Analog Channels, 8 Digital Channels
• Maximum Sampling rate: 2MSPS
• Analog Bandwidth: 320kHz
• Resolution: 8bits
• Input Impedance: 1MΩ
• Buffer size per channel: 256
• Max. Input Voltage: +/- 10V

for arbitrary waveform generator:

• 1 Analog Channel
• Maximum conversion rate: 1MSPS
• Analog Bandwidth: 44.1kHz
• Resolution: 8bits
• Low output impedance
• Buffer size: 256
• Max. Output Voltage: +/- 2V

The hardware is based on a ATXMEGA32A4 coupled with a Graphic OLED display 128×64 pixels and a TL064 quad op-amp for the analog side. What is not mentioned on the product page is that it also has FFT, Meter mode with voltage and frequency, X-Y mode and a logic analyzer. Sound nice but lets put it to the test and see how it performs.

First thing I wanted to test on the xprotolab is the meter mode; I think for beginners who build breadboard circuits it will be a very useful feature because you could use your multimeter to check some voltage or current while you use the xprotolab to check another voltage or frequency. Every electronics lab should have at least 2 meters to serve this purpose but if you’re a beginner its most likely you only have one. I must tell you that Gabriel was very helpful when I discovered some bugs in the firmware and he corrected them within hours. Unfortunately it is a work in progress and I could find other bugs even after upgrading. The firmware version used during tests is 0.95.

So to start testing I placed the xprotolab on a mini breadboard and supplied power at 5V. First thing to notice is the OLED display which is a very good choice for this application and provides nice & crisp display with good contras. The menu is not difficult, it takes about 10 mins to get used to it and learn what each menu/key press does. After switching to meter mode (VDC) I applied a 3.3V voltage through a 10k series resistor to CH1 and CH2. With both channels connected to the same signal at the same time CH1 was reporting 3.22V and CH2 3.28V while my multimeter was reporting 3.24V so CH1 was off by -0.02 compared to the multimeter while CH2 was off by +0.04. A slight offset between channels can be noticed ~0.06V. The firmware has an offset compensation feature which can be accessed by holding key 4 during power on.

After entering the offset menu it will ask you to ground all inputs and press start. I did that.. it acquired the new offset values and I continued using into meter mode to see how it affected the results. Connected to the same signal as earlier CH1 was now showing 3.19 V which is off with -0.03 compared to the multimeter but the surprise is that CH2 is not taking any measurements, its just stuck after the offset compensation. As you can see the values are pretty close to what the multimeter was reporting and really a 0.02 offset is not a big deal in most applications, but the software has a bug that’s preventing CH2 from taking measurements after the offset compensation. To fix this I just re-flashed the EEPROM and CH2 started working on meter mode again.

Next I tried the frequency measurement. I used a signal generator with a sine wave and the xprotolab was able to detect frequency down to 10Hz and up to 500KHz which is pretty good for a device so small and inexpensive. Next I tried the VPP meter mode which was able to detect values on a sine wave up to 100KHz, any frequency higher and the measurement got all weird.

Next test was on scope mode, and I was able to get a clean and accurate reading on CH1, up to 100KHz sine wave. Anything higher than 100KHz caused false readings and I could notice the amplitude going down.
I also did tests with square and triangle wave shapes and the results were the same. I did not have enough time to review the other features like the arbitrary waveform generator or the logic analyzer but I’m sure I’ll use it somewhere in a future project cause if you remember I wrote a post about how nice is to have a logic analyzer when debugging. There is one feature I felt it was missing from it though , the value of the frequency printed on the screen while taking scope measurements.(later edit: Gabriel pointed out that this feature exists and he was right, I somehow missed it. You have the option of activating and locking the cursors and this will show the frequency on the screen as 1/deltaT but I feel the position its not the best as it overlaps with the represented signal).  This is a feature commonly found on all modern scopes, and although you have the options of controlling two cursors from the menu its easier to just have the value on the screen without having to use the cursors.

To conclude the Xprotolab is a small and cheap device which besides the features enumerated above doubles as a development board with schematics and source code offered on the product page. To me its clearly visible that someone has put allot of work into this project and is using every bit of processing power from the ATXMEGA32A4 to crunch the numbers.

you can read about the EMV interceptor in Omar Choudary’s thesis: The Smart Card Detective - a hand-held EMV interceptor and you can check for more info and source files on his project page.

 //configure SPI
OpenSPI1(SPI_MODE16_ON | SPI_SMP_ON | SPI_CKE_ON | MASTER_ENABLE_ON | CLK_POL_ACTIVE_HIGH | SEC_PRESCAL_8_1 | PRI_PRESCAL_16_1, SPI_ENABLE);
 
//start reading T1
mPORTEClearBits(BIT_0);		// pull CS low to prepare for reading
while(!DataRdySPI1());
T1 = ReadSPI1();		// read 16 bit word
mPORTESetBits(BIT_0);		// pull CS high

So what else could be wrong ? Well at this point it could be a faulty sensor or incorrect use of the SPI interface maybe I wasn’t generating the clock correctly or maybe some wiring issue. This is the point where you need to have a logic analyzer. While I don’t have a proper logic analyzer I do have a PicKit2 and it can emulate a 3 channel, modest logic analyzer. I hooked up one of channels to the SCK pin and I noticed I wasn’t getting any clock signal. But why isn’t the clock being generated ? The answer came from the Microchip forums, the guys there pointed out that in order to generate the clock signal you have to issue a dummy write. By issuing a dummy write you start generating the clock and you can do the reading. So I added a new line to the code and tried again:

//configure SPI
OpenSPI1(SPI_MODE16_ON | SPI_SMP_ON | SPI_CKE_ON | MASTER_ENABLE_ON | CLK_POL_ACTIVE_HIGH | SEC_PRESCAL_8_1 | PRI_PRESCAL_16_1, SPI_ENABLE);
 
//start reading T1
mPORTEClearBits(BIT_0);		// pull CS low to prepare for reading
SPI1BUF = 0x00;			// this sends a 0x00 just to make the clock toggle in order to read
while(!DataRdySPI1());
T1 = ReadSPI1();		// read 16 bit word
mPORTESetBits(BIT_0);		// pull CS high

This time I also connected a second channel from the logic analyzer to the SDI pin on the pic32 (data in) and it worked , here is the capture:

As you can see on channel 2 there are 16 clock cycles corresponding to the 16 bit word sent by the TMP121 and on channel 3 connected to SDI(data in on pic32) is the actual binary temperature. If we analyze the data on Ch3, for every falling SCK edge we get 0001101010100000 we can discard the first bit cause its the sign bit (0 = positive , 1 = negative) and plug the rest of the bits in a calculator just to check the data.

note: windows calc discards the leading 0's

Next we convert to decimal and we get a value of 6816.

6816 is not quite the number that we were looking for, but remember the data is represented in two’s complement so we have to divide it by 256 to get the actual temperature in degrees C.

The result after division by 256 is 26.625 degrees C. This was the room temperature at the time of this test. From here on everything is simple, I know I’m getting the right data out of the sensor its just a matter of processing and using it. And here is a picture of the PCB I made for the TMP121 in SOT23-6 package. Probably one of the smallest PCB I made at home, 30×10 mm.

Now I’m seriously thinking about getting the Logic Sniffer from Dangerous Prototypes, it’s a must have.

Grace is a graphical configuration tool for MSP430 developers for setting up integrated peripherals such as ADCs, OpAmps, Timers, Clocks, and other modules. This tool is a free and open source, eclipse-based plug-in for Code Composer Studio. The Grace Beta currently supports all MSP430 Value Line devices (MSP430G2xx) as well as the MSP430F2274 device.

I was thinking about starting some projects on the MSP430 in the near future and one big problem is that I would have to read allot of datasheets and other info to get me started, and there isn’t always time for that. Grace might solve that problem for you and allow you to skip the hard work. Let me know if you’ve tried it. I’m especially interested on how it can interact with one of their MSP430+RF SoC.