Characterizing a device with LXI equipment

Usually, to measure the characteristic curve of a component, a Source Measure Unit (SMU) is needed, which sources a voltage and measures the current it provides with great accuracy. A similar task can be done with a power supply, together with a multimeter to have better accuracy. What is important about those measurements is automation. SMUs can be easily automated through scripts (TSP scripts for example for the Keithley SMUs) and can generate the characteristic curve autonomously, by sourcing different voltages/current and measuring the results.

To conduct similar tests with equipment of different manufacturers, a master controller is needed. With the use of LXI (LAN eXtensions for Instrumentation), this can be done with a computer as the master, commanding the test equipment and logging the results. MATLAB can be used to control the test equipment, log the results and present them in graphs.

All of the LXI compatible equipment use an Ethernet port, the easiest way is to connect them directly to the router, so that they are available to all of the other machines in the network. However, if the router is not close to the test equipment, a raspberry pi can be used to bridge the wireless network with the ethernet network, if all of the test equipment are connected to the raspberry pi. The lnxrouter can be used to setup the connection of the two networks. The routing table on the router or on the controller machine needs to be updated as well.

MATLAB does have an Instrument Control toolbox with some test equipment libraries, but I selected to write my own libraries for the power supply that I am using (Aim TTI MX100TP) and the multimeter (Keithley DMM6500). All of the functions I wrote for the LXI test equipment can be found in the github page. From MATLAB, the procedure is common to any other communication. The connection is opened, and the user writes to the device with an fprintf function call, and gets from the device with a query function call.

A simple example to control the power supply and log measurements from the power supply, as well as from the multimeter. The power supply has overcurrent and overvoltage protection, which can be set manually in the instrument to ensure that an erroneous code would not supply more than the load would handle. A loop is formed which increases the power supply output voltage by 0.2V step on every iteration and gets the voltage measurement from the power supply as well as the current measurement from the multimeter. The measurements are logged and plotted in real time. The multimeter is setup to get 10 measurements and report back the average.


%%% Defines %%%%
clear all;
MX100TP_ip = '';
DMM6500_ip = '';
CurrentLimit = 0.5;

% Connect to MX100TP %
MX100TP = instrfind('Type', 'tcpip', 'RemoteHost', MX100TP_ip, 'RemotePort', 9221, 'Tag', '');

if isempty(MX100TP)
    MX100TP = tcpip(MX100TP_ip, 9221);
    MX100TP = MX100TP(1);

% Connect to DMM6500%
DMM6500 = instrfind('Type', 'tcpip', 'RemoteHost', DMM6500_ip, 'RemotePort', 9221, 'Tag', '');
if isempty(DMM6500)
    DMM6500 = tcpip(DMM6500_ip, 5025);
    DMM6500 = DMM6500(1);

%%%%% Setup DMM6500 %%%%%%
DMM6500_Setup(DMM6500, 'FUNC_DC_CURRENT', 1, 10, 10);
%%%%%%% End of Setup %%%%%

voltage = 0;
current_MX100 = 0;
current_DMM6500 = 0;
disp('Start of Measurements');
M100TP_SetOutputValues(MX100TP, 1, 0, CurrentLimit); % Set current limit for Channel 1

close all;
f1 = subplot(2,1,1);
h1 = plot(voltage,current_MX100, '-o');
hold on;
h2 = plot(voltage,current_DMM6500, '-*');
xlabel('Voltage [V]'); ylabel('Current [mA]'); grid on; legend('MX100 Current','DMM6500 Current', 'location', 'southeast');
f2 = subplot(2,1,2);
h3 = plot(voltage,voltage*current_MX100, '-o');
hold on;
h4 = plot(voltage,voltage*current_DMM6500, '-*');
xlabel('Voltage [V]'); ylabel('Power [mW]'); grid on; legend('MX100 Power','DMM6500 Power', 'location', 'southeast');

for Voltage=0:0.2:35
    M100TP_SetOutputVoltage(MX100TP, 1, Voltage);
    fprintf('Voltage setpoint: %.1fV\n', Voltage);
    measvoltage = MX100TP_GetVoltage(MX100TP, 1);
    meascurrent_MX100 = MX100TP_GetCurrent(MX100TP, 1);
    meascurrent_DMM6500 = DMM6500_Read(DMM6500);
    voltage = [voltage measvoltage];
    current_MX100 = [current_MX100 meascurrent_MX100];
    current_DMM6500 = [current_DMM6500 meascurrent_DMM6500];
    set(h1, 'XData', voltage);
    set(h1, 'YData', current_MX100*1000);
    set(h2, 'XData', voltage);
    set(h2, 'YData', current_DMM6500*1000);
    set(h3, 'XData', voltage);
    set(h3, 'YData', voltage.*current_MX100*1000);
    set(h4, 'XData', voltage);
    set(h4, 'YData', voltage.*current_DMM6500*1000);

disp('End of Measurements');
M100TP_SetOutputValues(MX100TP, 1, 0, 0);

I used the code above to measure two resistors. One was a 100R resistor with the result shown below. As expected, the characteristic is linear.

The second resistor was a 10k one. Because of the much smaller current, the quantization error on the current measurement of the power supply is evident. Even if it has a 0.1mA resolution, still this is not enough. Whereas with the multimetre which has 6.5digits and a 10mA scale, the quantization noise is significantly lower.



Di2 Electronic shifting bike groupset upgrade

My road bike is a 2013 Merida Scultura Comp 905, with an electronic shifting compatible carbon frame and the 10-speed Shimano Ultegra 6700 groupset and rim brakes. I recently purchased the Ultegra 8050 groupset and, in this post, I describe the steps that were needed to install on the frame and some observations based on the experience.

But first of all, since I have changed already some components from the stock Scultura 905, the before-after components for the changes from mechanical groupset to electronic groupset are shown in the table below

Component Original Upgraded
Front Derailleur FD-6700 FD-R8050
Rear Derailleur RD-6700 RD-R8050-SS
Chainset 6750 50/34 R8000 50/34
Cassette CS-6700 11/28 CS-R8000 11/28
Shifters ST-6700 ST-R8050
Brakes Merida Pro BB-R8000
Seatpost Deda Elementi Superleggero 27.2mm [same]
Wheelset Fulcrum Racing Comp Fulcrum Racing Zero Black
Chain Ultegra 6700 10-speed CN-HG601
Bottom bracket Ultegra 6800 [same]
Battery - BT-DN110-A
Junction boxes - SM-EW90-A (frame) and SM-JC41 (internal)
Wireless unit - EW-WU111

The components already changed aided the electronic shifting upgrade:

  • The original seatpost (Merida Carbon) was broken in 2018 and replaced with the Deda Elementi one. It supports the internal battery using seatpost battery holder 
  • The chainset (FSA Energy Mega 50/34) was broken in 2018 and replaced with the Ultegra compact equivalent. I changed the bottom bracket at the same time from the FSA Mega Exo to the Shimano 6800 one. This ensures compatiblity with the updated chainset.

Some more components to consider, which were used for the installation and operation:

  • Deda seatpost battery holder: Needed to mount the battery inside the seatpost. You could make something custom, but this is pretty neat.
  • EW-SD50 wires: Various lengths, depending on the frame size and location of each of the components.
  • SM-GM01 and SM-GM02 grommets: Used to secure the wires when entering the frame.
  • SM-AD91 band adapter: Needed if the frame doesn't have a front derailleur hanger
  • EW-SD501 wire holders: Place on the wires that are routed inside the frame. Prevents rattling noise and helps you keep your sanity.
  • Concerning the wheels, the hub was only 10-speed compatible, so an upgrade was needed :)
  • The wireless unit is not mandatory, but it allows to connect the di2 mechanism to the GPS head unit. This function is used to check the current battery and gear combination, as well as to control the head unit from the shifters.

 Here is the bike at its mechanical shifting state, together with all of the components. Logistics to get all the compatible parts is not the easiest part in the world.

Before starting to route cables through the frame, it is a good idea to check that all of the components are working with the intended connections, on the bench (or table). I connected the wireless transceiver between the top and bottom junction box and upgraded the firmware of all the components.

There is a junction box that goes next the bottom bracket. I also placed the wireless transceiver next to it and packaged it to avoid any rattling inside the frame. Although Shimano does not recommend placing the transceiver inside the frame, I haven't had any connection issue with the head unit or phone. Because of all the various connections inside this tight space, I labeled all the cables, in case modifications/troubleshooting are need in the future.

The rear derailleur is easy to fit. However, it is difficult to make the grommet stay in place. It needs some patience. The high and low screws need to be setup (as is the case with a mechanical derailleur). However, the "cable tension" is setup electronically.

Shimano has very detailed diagrams on how to assemble the front derailleur with a band adapter (my frame doesn't have a derailleur hanger). I didn't need to do any adjustment after that.

I placed the junction box underneath the stem, with some velcro tape. Though I haven't needed to remove the junction box yet and don't think I will anytime soon. However, I didn't like Shimano's solution with the elastic band (I find it ugly). However, if you were to ride on cobblestones, perhaps this would be the only solution. I used heatshrink to increase a bit the the width of the Di2 cable and fit it between the junction box and the frame.

As I wanted to get extra buttons to shift the rear derailleur from the top instead of the hoods, I modified some buttons from eBay with the Di2 connector (cut a Di2 cable in half and soldered it to the end of the flexi of the button, and then applied hot glue). This can be connected to sprint shifter port of the Di2 shifters.

Finished result:

Not needing to adjust the cable tension every now and then is nice. As you lose the feedback on the shifter to understand at which point of the cassette you are, it is beneficial to have the current value on the head unit. It also provides audible feedback when you reach either limit of your gearing. Concerning battery, you forget to charge it (although it alerts you when the Di2 battery is getting low). Concerning traveling, I'd argue that it is easier to disassemble the bike (I leave the battery inside the seatpost and disconnect the cable, I also disconnect the two cables from the shifters to the junction box).


Desk clock based on an STM32 microcontroller

Based on my initial tests of Dot Matrix displays using either an FPGA or an STM32F4 microcontroller, I wanted to build a desk clock with the following features:

  • Low drift using an external crystal
  • Automatic setup using an NTP server via WiFi
  • Support for daylight saving
  • Temperature and Humidity measurement
  • Periodic update using an NTP server
  • Adjustable brightness
  • Single 5V supply
  • Minimum external components and wire connections
  • Support for WiFi credentials reconfiguration

The Dot Matrix display I selected was a 64x32 RGB display which has a 5V supply input. The microcontroller I used was an STM32F767 which has a maximum clock frequency of 216MHz (important, since, as analyzed in previous articles, to achieve a high refresh rate, a high clock frequency is needed, especially as a microcontroller would be used instead of an FPGA, to keep the cost low).

The F767 is mounted on a Nucelo144 board. I selected the specific board because it had an on board 32.768kHz crystal as well as the necessary 3.3V regulator. A lower cost F4 Nucleo could also be used, but I also wanted to check some other features of the specific board (especially the hardware double precision FPU and the Ethernet PHY).

To get the time from an NTP server, I used a Wemos D1 mini board, which uses the well known ESP8266 chip. Again, the D1 mini board has a 3.3V regulator, a UART to USB converter, a USB port as well as the necessary pull up resistors for the ESP8266. I have used the ESP8266 before, when I built WiFi Power switch. The chip can be programmed through Arduino (using all the available Arduino libraries as well).

Concerning the temperature and humidity measurement (which was a late request), I selected the DHT21 (AM2301) single wire temperature and humidity sensor, which I have also used before when building the Raspberry Pi Meteo Station. It has a very good accuracy for the application, and, because of its popularity, many libraries are already available.

The connection diagram of the different components is shown below. The external 5V power supply (4A maximum current, <1A expected during operation), powers both the Dot Matrix Display as well as the Nucleo board, via the external 5V Vin pin. Through the Nucleo connectors, the 5V rail is also supplied to the Wemos D1 mini board, and is stepped down to 3.3V through the onboard regulator. 3.3V is also supplied to the DHT21 sensor via another Nucleo header connector.

Concerning data transmission, the microcontroller and the ESP8266 will communicate via UART using a predefined protocol. In case of connection loss, the STM32 microcontroller will be able to reset the ESP8266 chip via the external reset pin, which is connected to an STM32 GPIO. The temperature sensor is also connected to the ESP8266 board, to decrease any processor load of the main STM32 microcontroller (which could result in display flickering if not taken into account). What is more, the matrix display data is sent through the GPIO peripheral of the microcontroller (13 pins in total) based on code analyzed previously.

The algorithm of the microcontroller also features

  • 1 second interrupts (via the WakeUp RTC function) to update the display
  • RTC alarm interrupt to get new NTP date and time
  • Reset of the WiFi chip if no data is sent back
  • Adjustable display brightness using the Nucleo User button
  • UART interrupts for received data and error checking

The ESP8266 handles the WiFi connection (and update of credentials), temperature and humidity data from the DHT21 sensor, NTP time requests as well as daylight savings settings. To implement all of the above, the following libraries were used:

The data display format was based on a Bluetooth FPGA Dot matrix clock. In that case, each frame was constructed through a Matlab script and sent via Bluetooth to a Xilinx FPGA. As shown previously, the FPGA, because of its parallel data processing, can achieve higher color resolution (or higher FPS). However to operate, it would always need to be connected to a computer. The display features greek font support, hour and minute vertical bars (left and right side of the display respectively), a seconds bar on the bottom edge of the display as well as color animations.

The mounting on the clock was also based on the above FPGA clock. The aim of the assembly was to eliminate any wires which would interconnect the four main components. All the wires are sandwiched between the Nucleo board on one side and the dot matrix display on the other side of the mount. The user button is accessible from the backside to change the display brightness, as well as the reset button. The micro-USB ports of the Nucleo board as well as the Wemos D1 mini board are also accessible for future firmware updates.

STM32 Dot Matrix Display

Continuing on the previous work on driving a Dot Matrix Display with an FPGA, the same concept was used to connect an STM32 Discovery board to drive the display. Again, a UART bluetooth module would get data from a server and display it on the matrix.

The Board that was used is an STM32F429 Board. It features a moderately high frequency of 180MHz (top of the line STM32F7 boards have a frequency of 216MHz). However, stil, for such a task, it is low clock, since, compared to FPGAs, all the code is sequential as it will be shown below.

To drive the 64x43 pixel RGBdisplay the following signals need to be supplied:

  • Four signals which select the row couple (0-15).
  • Three signal couples (RGB1 and RGB2) which select if each LED will be activated or not.
  • A clock signal for the shift register.
  • A latch enable signal for the shift register.
  • An output enable signal.

The GPIO peripherals of the STM32 microcontroller were used. The display operates by driving each row (or more precisely each high/low pair row) individually, using 64 shift registers. After that, the next row pair is driven. In order for this refresh procedure to be invisible to the naked eye, the clock frequency needs to be high. With a PLL clock of 200MHz, a refresh rate of 120FPS were achieved using an FPGA, with 8 bit per color and 64x32 resolution. However, this PLL frequency is even higher than the CPU frequency, meaning the CPU cycle time. As a result, even with such an advanced microcontroller, the refresh rate won't be nowhere as near as the one that was achieved with the FPGA.

The complete code for this project can be found on Github. Other than the GPIO peripherals, the microcontroller uses the UART peripheral to get new data. Since the UART baud rate is low, each transmission would be visible on the display. Since each frame is 64columns x 32rows x 3colors x8bits = 6KB, multiple frames can be stored in the on-board RAM. Pointers are used for the memory bank where the UART stores a new frame as well as for the memory bank from which the controller gets the frame to display. When a new full frame arrives from the UART peripheral, an interrupt is generate to switch banks. Since the processor is busy providing the timings for each pin of the Matrix Display, the DMA peripheral is used to store the data as it arrives from UART. The interrupt is generated by the DMA peripheral.

The timing of the different signals can be shown in the images below. As it can be observed, only about 75 frames per second can be achieved, which normally would be more than enough, since for example common VGA CRT displays have a refresh rate of 60Hz. However, since the LEDs switch off instantly, the switching of each row is visible in low frame rate. As a reult, instead of 8 bits color depth (which was the case for the FPGA driver), only 3 bits were achievable with the microcontroller. The different color depths (corresponding to different ON times can be seen as well).



Zooming in even further, the clock rate of the display is shown. The 180MHz microcontroller achieves only 1MHz of clock rate, meaning that on every shift, there are about 180 cycles. The code is not optimized, but the vast difference between this implementation and the FPGA implementation is noted.

As the row is switched from 15 to 0, each row signal switches sequentially, which is captured in the diagram. Since the OE is high during that time (meaning that the display is momentarily switched off), this is not visible.



PWM Generator on a STM32L152 Discovery

The STM32L152 Discovery is a compact board which includes an LCD display, a touch sensor (linear or four keys), a push button and two LEDs. Combining all of the above, a compact PWM generator can be made with variable frequency and duty cycle.

The LCD will display the current value to be adjusted meaning either the frequency or duty cycle of the pulse. To cycle between the two settings, the push button will be used. The values will be set using the touch sensor. Finally, the pulse will be output to the green LED in order to show the actual duty cycle (via the LED intensity). The second LED will be used to show which of the two values is currently adjusted (it will also be shown in the display).

So, the timer that will be used is TIM4 and Channel 2, in order to output the PWM pulse to the blue LED (Port PB7). A standard initialization function is first run, meaning starting the timebase, the output channel and finally connecting the channel 2 output to port PB7:

void TIM4Init()
TIM_TimeBaseInitTypeDef TIM_InitStruct;
TIM_OCInitTypeDef TIM_OCInitStruct;
GPIO_InitTypeDef GPIO_InitStructure;

TIM_InitStruct.TIM_ClockDivision = TIM_CKD_DIV1 ;
TIM_InitStruct.TIM_CounterMode = TIM_CounterMode_Up;
TIM_InitStruct.TIM_Period = 32000;
TIM_InitStruct.TIM_Prescaler = 1;
TIM_TimeBaseInit(TIM4, &amp;TIM_InitStruct);

TIM_OCInitStruct.TIM_OCMode = TIM_OCMode_PWM1;
TIM_OCInitStruct.TIM_Pulse = 100;
TIM_OCInitStruct.TIM_OutputState = TIM_OutputState_Enable;
TIM_OCInitStruct.TIM_OCPolarity = TIM_OCPolarity_High;
TIM_OC2Init(TIM4, &amp;TIM_OCInitStruct);

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_7;
GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_10MHz;
GPIO_Init(GPIOB, &amp;GPIO_InitStructure);

TIM_OC2PreloadConfig(TIM4, TIM_OCPreload_Enable);
UpdatePWM(frequency, duty);

Next, an easy backend to change the frequency and duty cycle must be used. The function UpdatePWM takes two operands (frequency and duty cycle) and appropriately configures TIM4. Since the L1 microcontroller can run in different clock frequency configurations, the "SystemCoreClock" variable used, which is set in the system source file (assuming that the APB1 Prescaler is 1):

void UpdatePWM(double frequency, double duty)
//frequency in Hz, duty 0-100.0
long int ratio;

ratio = (long)SystemCoreClock/frequency;
TIM4->PSC = (int)(ratio/0xFFFF);

ratio = ((long)SystemCoreClock/(TIM4-&gt;PSC+1));
TIM4->ARR = (int)(ratio/frequency)-1;

TIM4->CCR2 = (int)((TIM4->ARR+1)*duty)/100-1;

To update the LCD Display, the provided function LCD_GLASS_WriteChar is used for each character, whereas, a custom bargraph function is written to update the bargraph as a percentage value:

void UpdateDisplay(void)
bargraph((int) duty, 100);
if (state==FREQ) sprintf(displaystring,"f%4.2dk", (int) (10*frequency));
if (state==DUTY) sprintf(displaystring,"d%4.2d%%", (int) (10*duty));
LCD_GLASS_WriteChar((unsigned char *)displaystring + 0, 0, COLUMN_ON, 1);
LCD_GLASS_WriteChar((unsigned char *)displaystring + 1, 0, 0, 2);
LCD_GLASS_WriteChar((unsigned char *)displaystring + 2, 0, 0, 3);
LCD_GLASS_WriteChar((unsigned char *)displaystring + 3, POINT_ON, 0, 4);
LCD_GLASS_WriteChar((unsigned char *)displaystring + 4, 0, 0, 5);
LCD_GLASS_WriteChar((unsigned char *)displaystring + 5, 0, 0, 6);
void bargraph(int value, int max)
double percentage=(double)value/(double)max;
if (percentage>0.25) BAR0_ON;
if (percentage>=0.5) BAR1_ON;
if (percentage>=0.75) BAR2_ON;
if (percentage==1) BAR3_ON;

Finally, the touch sensor value is read using the provided STMTouch driver.

The full project of the PWM Generator for the STM32L152 Discovery can be found on my Github page.