edit: I wrote this post before I knew the outcome of the last three road tests.

This is the first time I'm selected for an instrument, after 4 years of applying. Perseverance helps.

This is the technical part of my application for the TI SWIFT Power Module EVM Road Test

I'm selected for this one.

Reason for the RoadTest:

This Road Test is a very nice fit with the blog series I have here on element14 related to switched mode DC conversion.

I am verifying different converter topologies and technologies and document my findings here on the community.

Although my blogs usually aren't product reviews (they are explanations and experiments) I have the skill, tools and will to verify the educational value of the offer.

For this road test, my plan is to check the performance of the IC compared to the specifications and discuss interesting aspects like efficiency, footprint size in a finished product .

I will also discuss the aspects of the reference design (pcb layout, how it compares to the guidelines, interesting aspects of the design that are specific to this board).

It'll also be a learning experience for me and I'll blog about that on element14.

My last roadtest application related to switch mode converters was TI-PMLK Buck Experiment Board: TPS54160 & LM3475  earlier this year.

The review resulted in a review: TI-PMLK Buck Experiment Board: TPS54160 & LM3475 - Review ,

and a number of blog posts

<over-promoting myself is not your business>

==============================================================================================

This is the technical part of my application for the Ultra-Low Power Arm Cortex-M4 Darwin MCU EVM  Road Test

At the time of writing I don't know if I'm selected. The Road test is still open. I'm selected for this one.

This is when the new structure for road testing started. It shoe-horns the application in a rigid structure. There are pros and cons. I think that for element14 and the suppliers, the pros are helping to get more good applications.

As a creative writer, the structure limits me a little, but I don't mind. Looking back at this submission, I think I was a bit over-impressed by the new ways of working.

(b) Why you are applying for this roadtest?

I am interested in low power designs and in optimising firmware to use the low power and sleep modes of a controller.

I have blogged about this subject on element14 (e.g.: SimpleLink Sub-1 GHz Wireless Microcontroller - Side Note : Measure Power Use of Sensor Controller Engine ).

This controller is being positioned as a low power device, and I’m interested in evaluating that.

(c) What is your testing procedure?

I will review the documentation and examples of the manufacturer, and validate how well they help a designer to minimise energy use.

I will design an application that collects data from a sensor at regular times, collect that info, then share in bulk with a consuming device. I will check how low the energy use is inbetween the measurements. I will also check how easy it is to wake up, what the possible wake-up triggers are.

I will check if it is easy or hard to work with the device’s peripherals.

==============================================================================================

This is the all in the open part of my application for the Keithley Bench Digital Multimeter  Road Test

Again, at the time of writing I don't know if I'm selected. The Road test is still open. I'm selected for this one.

This time, I left much of the own-chest-tapping in. It's blatant self promotion but true.

I'm not going to blush. Everyone does this.

(a) What is your background?

I studied electronics with a specialization in measurement and feedback theory and have a graduate in management information systems.

I work as <I removed my current employment because because>

I'm interested in automotive and industrial microcontrollers, functional safety in hardware and software, power electronics, test automation and external data acquisition.

I won the hackster.io Industrial Design contest last year (organised by element14 competitor RS Components)

I am not a hacker. I try to use industry standards and practices.

Specific to my application for reviewing the Keithley DMM6500:

I have experience with building and automating test instruments. I designed test instruments that support SCPI, wrote LabVIEW drivers for them and have used them in combination with commercial devices.

I have published these projects here on element14. See section (d) for examples.

(b) Why you are applying for this roadtest?

This is the first time that I select "complex project" instead of "testing to a procedure or standard".

I have an interest in automating test processes. Reviewing the Keithley DMM6500 enables me to share the experience of including a programmable meter in a test.

I'm expecting that the majority of proposals will focus on the specs, options and precision of the meter.

By focusing on the programmable interface, I may bring a different and unique aspect of the  DMM6500  under attention of the community.

It's also a chance to review a Keithley device. I have never owned or used instruments from Keithley before.

(c) What is your testing procedure?

I plan to focus on using the instrument in automated tests, controlled via SCPI and LabVIEW.

I'll review the SCPI drivers and building blocks, any examples that are provided, and my experience using these.

I will include the DMM6500 in a test setup, use it to capture points of interests during long running tests. Then show how that data can be used in reporting and in pass/fail situations.

I also review the

• overall ease of use of the instrument,
• experience with the software that comes with it,
• quality of the documentation

My review and score will be based on that experience. Critical, fair and balanced.

When I encounter difficulties during the review I'll contact the supplier to help resolve these. I will document those experiences too as part of the road test posts.

(d) Give some examples of your element14 community participation.

I have more than 200 blog posts here on element14. I summarize initiatives related to what I'd like to perform with the Keithley DMM6500.

They often relate to test instruments and using them in automation.

I developed a SCPI programmable load - hardware, firmware and LabVIEW drivers - together with two fellow element14 community members:

Programmable Electronic Load

The instrument is used in several projects to characterize switch mode supplies and other devices, e.g.:

Programmable Electronic Load - Automating a DC Switcher Efficiency Test with LabVIEW

Programmable Electronic Load - LabVIEW Test Automation: Characterise the Instrument

I have built and reviewed power electronics and functional safety designs:

Project14 | Clustered MCUs:  Functional Safety with Lockstep CPUs

High Voltage GaN FETs - Part 2: Test Setup with LMG3410 Half-Bridge

DAC8775 Quad-Channel DAC EVM - part 4: Current Mode

The GaN BoosterPack Series: LMG5200 Evaluation Pack and Smart Instrument

I developed some easy to use programmable lab tools for the Project14 community:

SCPI on a Linux Board - Part 4b: TCP/IP SCPI and Instrument Service 100% Working

Arduino in Test Instrumentation - Intro: SCPI Programmable Switch

micro:bit as Pass / Fail indicator in an automated test setup

Make a Logic Analyzer from your Dev Kit Part 2: Papilio FPGA

Here are example reports of a Road Test I did before:

EFM32 Zero Gecko Starter Kit w/ Sensor Card - Review

TI-PMLK Buck Experiment Board: TPS54160 & LM3475 - Review

==============================================================================================

This is the technical part of my application for the Rohm SensorShield-EVK-003 (Arduino Compatible) Road Test

I'm selected for this one. I've removed the self-enlightening this time because it's a repeat of the overpromotion above.

(b) Why you are applying for this roadtest?

I'm enrolling because I have interest in data acquisition and integrating sensors in (very) low power designs.

Example documentation  form a Road Test I participated in: SimpleLink Sub-1 GHz Wireless Microcontroller - Side Note : Measure Power Use of Sensor Controller Engine

In section (d) I provide a link to a Road Test that I made for an ultrasonic sensor.

I also apply because it allows me to show how datasheet specifications can be verified in an automated setup.

Here is a sample blog that I made about this topic: Programmable Electronic Load - Automating a DC Switcher Efficiency Test with LabVIEW

The third reason is that I have interest in new sensor technologies. Road Testing these sensors will allow me to grow my knowledge and share it with the community.

It's also my first opportunity to learn about the manufacturer. I have not used ROHM devices before.

(c) What is your testing procedure?

I will first try out each sensor as described in the User Guide, using the examples for Arduino.

Then I will try to get each of them working on a different microcontroller, and share the code I write to make them work. I'll document the communication between the controller and sensor.

I will validate the specifications from the ROHM datasheet. Where possible, I will show how automation can help to review the devices.

I will not make a big project. I will fully focus on evaluating, learning and sharing my experience with the sensors.

(d) Give some examples of your element14 community participation

I have about 300 blog posts here on element 14, mainly about:

• automotive electronics and functional safety
• Power electronics, specifically switch mode devices and new FET materials (GaN).
• LABView automation and developing programmable electronics
• Sub-1 GHz communication,
• automating sensor applications for long battery life,
• building programmable tests instruments and
• measurement and lab techniques.

I try to make each blog pretty, easy to read. Often with a video embedded.

This is a link to my contributions: Jan Cumps.

Together with 2 fellow team members, I designed and made an open source Programmable Electronic Load , with documented hardware, firmware and VISA integration library.

I have participated in several Road Tests and have always delivered additional blog material, during and after the end of the Road Test .

Here is an overview of the Road Tests I applied for: How I Enroll for a RoadTest - Part 2: success and failure

And below is an example of the blogs and reviews I wrote when Road Testing a Texas Instruments Ultrasonic sensor for fluid detection:

==============================================================================================

This is the technical part of my application for the Infineon Gate Driver with Truly Differential Input  Road Test

At the time of writing, I don't know if I'm selected ...

I'm selected for this one.

(c) Why did you apply for this particular roadtest?

I am interested in modern power electronics. I have an interest in switch mode solutions, GaN power FETs and technology innovations in the discipline.

I have reviewed FETs, Buck converters and half-bridges on the community, and posted own designs using these (see the end of this application for references). I have never reviewed a FET driver specific.

I have blogged about Infineon part before - motor driver and LED driver power components.

I believe I have the skills to validate the specific merits that are posted for the driver, and document on that in a community-engaging way.

(d) What is your testing procedure (Be as specific as you can)?

I will first review the behaviour of the test board with the on-board gate driver, with focus on the improved ground bounce handling that it promises to be good at in the documentation.

I plan to use the test approach of the board's application note for that.

I will then replace the low-side driver with a more traditional one and validate how the design is handling the DC offsets and AC distortion, using the same test procedure.

I will look for a generic gate driver part as replacement- if Infineon wants me to use a specific alternative, I am open to that.

==============================================================================================

This is the technical part of my application for the Renesas RX65N MCU EV Kit Road Test

At the time of writing, I don't know if I'm selected ...

I'm selected for this one.

...

(c) Why did you apply for this particular roadtest?

I am in particular interested in 2 aspects of the RX65N kit:

Hardware:

All the modules on the right side of the functional overview , related to security and safety.

I als would like to test the CAN peripheral and the DAC module.

Software:

It would be my first experience developing for a Renesas device. I’d like to verify how good the Eclipse based IDE is compared to other manufacturers, and if the examples are rich and helpo understand the device.

(d) What is your testing procedure or project plan (Be as specific as you can)?

For hardware:

• test the security specific options, in isolation on the device, and together with controllers of competitors, to check compatibility and openness in a mixed manufacturer design
• how is secure storage of keys implemented
• validate the DAC (not so common peripheral in a microcontroller)
• Use the CAN modules in a setup I have available. I made specific CAN driver here on element14 for this purpose.

Software:

• validate the IDE. I have experience with the solutions from other hardware manufacturers (TI, Maxim, Silicon Labs, Siemens). I would validate how well the integration of the Renesas utilities , libraries, examples and documentation is. How easy it is to get Project 1 running. How good the debug options are.
• Validate HAL and RTOS options
• Validate how well the examples help to understand the device
• validate the Man-Machine examples and if they give a headstart for industrial design control.
• validate the support options available, if applicable.

...

==============================================================================================

By showing my not-finished-yet applications I risk that someone rips of my story. I'm ok with that.

Don't be that guy.