The element14 roadtests are a great way to learn new things. Whenever I see a test that interests me, I enroll.
Success is not guaranteed. I've been selected for some, not for others. In this series I'll explain how I decide to enroll or not.
I'll also show how I build my case, including some examples from my applications.
I might also try to build a case for a new roadtest interactively in this series... You can give me advice on what I should add, delete, change, improve...
I've applied to five roadtests. Two of them were accepted, the other 3 weren't. (edit: I've updated this list with more successes and failures, most of them evaluation boards)
There are more tests that I considered, but didn't apply for.
When I submitted my first application, I didn't fully understand how things work, and I just submitted a brief text.
This piece of quality prose is my very first post on the element14 community:
|Tektronix MDO3054 Oscilloscope|
|I'm planning to use the oscilloscope in a videoblog series on the Hercules safety MCU features </snip> and other digital and analog related electronics topics</snip>.|
I'm currently using one of the earliest digital scopes from Philips/Fluke for the analog domain and an Arduino as logic analyzer. An upgrade wouldn't be bad.
It should be no surprise to you that I wasn't one of the selected testers. I think that many of the first time applications look like that.
Some you Win, Some you Lose
For my other roadtests, I've put much more effort in the application. I'll give a summary of the text. I'll leave out the blatant self promotion pieces and focus on the arguments I use to become the chosen one.
There's multiple reasons for non-selecton. The most obvious one is that there are enough better submissions so that you fall out of the selection. Another factor is that test gear roadtest have an order of magnitude more enrollers than other tests, so your chances are lower by default.
I am planning to put the oscilloscope at work in analog and digital scenarios.
I am previewing GaN technology. I have GaN drivers that are intended for switch mode devices with switching frequencies in the MHz range.
I am investigating dead time control, propagation delays, edge times and other attributes that are in the low ns range.
Using the scope to measure the input driver
I have a test circuit that generates time delays, that can nicely be traced from input to output.
I can use the scope's multi-channels - and need its high bandwidth - to trace how a simple block signal is turned into a differential signal with asymmetric delays.
That would allow me to show on the scope screen the theoretical trace that I have on paper:
I can also compare the resolution difference when comparing it to a scope with a lower sampling rate:
The exercise may also be of interest to owners of the book 'The Art of Electronics', because it's an implementation of a circuit that's explained in chapter 1 of that book.
Using the scope to measure the switching behavior and the output:
I am also examining the performance of the GaN technology on the output side. How can we measure the dead time, what do the output signals look like.
I have been blogging on element14 on those things that I can achieve with my current toolset :
Other measurements, like propagation differences between high and low side of the switching FETs, are only possible with a higher bandwidth scope.
My plan is to probe all reachable signals of the power stage, and correlate them to each other. I would use the oscilloscope to visualize the relationship between all the things happening in the device.
I would also exercise the scope's remote capabilities, the quality of the software, and how to use the scope to document laboratory findings, and how to automate test setup and logging.
In the digital domain I would like to use the scope in a CAN bus context. I have a big interest in automotive applications, and have access to a multiple-node CAN test setup.
I would use the oscilloscope to view the CAN data and use it's decoding capacities to visualize what's happening on the bus.
I have done several videos on the subject where I show the traffic, but lack the ability to decode the data with a logic analyzer:
The ability of the scope to see and decode the CAN packages moving back and forth allows me to compare what's on the oscilloscope screen with what's exchanged between the different CAN message boxes.
If that option is part of the roadtest, I would also show how to trigger and search for particular messages in the traffic.
Overall Oscilloscope Performance:
I will review the usability of the scope in both domains, the ease of finding and using the different options, the ergonomy of the user interface and logic of selecting options
I plan to judge on the quality of the documentation - as reference and as tutorial.
I also want to thoroughly test the client software and validate if that is of high quality and adds value to the use of the oscilloscope.
I want to check how easy it is to extract info out of the oscilloscope, and add that info to project documentation.
</blatant self promotion snipped>
|EFM32 Zero Gecko Starter Kit w/ Sensor Card|
I'd like to profile the energy use in combination with the element14 fueltank boosterpack.
That investigation would become part of the video blog at </snip>
|Keysight 34470A and Texas Instruments DAC8734EVM|
|My plan for this road test are|
To check the performance of the meter, specifically in low voltage and low current conditions;use it in combination with the EEVblog µCurrent to do measurements on low power microcontrollers, dc-to-dc converters, battery management circuits,precision opamps and precision DAC and ADC ICs.
I will use the TI precision DAC as an object under test for the Keysight meter, and will explain to the audience how a device is specified,and how a chip manufacturer does the measurements for datasheets.
I will also compare it to another precision DAC I have in my lab from Texas Instruments (DAC8564), and try to show the differences using the Keysight meter.
I will use the Keysight meter to evaluate the specifications from the datasheet, and explain how these attributes can be verified.
The data logging capabilities of BenchVue can help to show that the drift of the parameters is impacted by external factors such as temperature and time.
|Enchanted Objects Design Challenge|
I want to enchant both mechanics and electronics of analog audio gear.
I'm looking forward to your comments and critiques. How and where can I improve? What would you do different?
In my next post I'll start applying for a new roadtest. Looking forward for your help.