Hantek 6254BD Initial Evaluation
I received the Hantek 6254 BD oscilloscope in the fall of 2018 but had little time to do a thorough evaluation. However, the initial findings were good – after I learned to cope with a software oscilloscope instead of switches and dials.
To do a quick evaluation I used a STM32F4 Discovery board that I had handy – the one with four lights you can program in a carousel. It was handy because I could blink the four lights in a circle and show the resulting pulse on one of the channels – something like this…
My first reaction was “Wow, look at all the noise!”. The next reaction was “Why?”. Well, there is a lot of reasons including the ability of the scope to “see” the noise and the ability of the 250MHz capable scope probes to transmit any noise from the circuit. So, at this point, I’m not terribly concerned about the noise but will look at it further later – including the ability of my PC to generate clean 5V power on the USB circuits. The oscilloscope can average readings to minimize noise and chatter from the ADC converters.
You can see my sophisticated test bed for my oscilloscope evaluation. The lights are blinking at the 211KHz frequency so they are a little dim, but you can see them between the two switches with the blue and black push buttons.
As I work through the oscilloscope features, I’ll see what I can do to provide information on the ability to trigger on and decode (if possible) I2C and SPI data being sent to various devices. I have shock sensors and barometric and temperature I2C units to test. As well I have various forms of Ultrasonic distance measuring units with Serial and I2C interfaces that I use in various development efforts.
For those interested the program for the STM32F401C Discovery is listed below. Most of it was generated using the MX Cube program. I simply added three more blinking lights to the original program. I also added instrumentation to observe registers etc. – but that’s a story for another day.
Program Excerpt:
while (1)
{
/* Turn on LEDs */
//puts("Starting LEDS...");
STM_EVAL_LEDOn(LED3); //Orange GPIO13
Delay(0x000001);
STM_EVAL_LEDOff(LED3);
STM_EVAL_LEDOn(LED4); //Green GPIO12
// Delay(0x3FFFFF);
Delay(0x000001);
STM_EVAL_LEDOff(LED4);
STM_EVAL_LEDOn(LED6); // Blue GPIO16
//Delay(0x3FFFFF);
Delay(0x000001);
STM_EVAL_LEDOff(LED6);
STM_EVAL_LEDOn(LED5); // Red GPIO14
//Delay(0x3FFFFF);
Delay(0x000001);
//printf("Flashed all LEDs...\n");
STM_EVAL_LEDOff(LED5);
/* Infinite loop */
i++;
}
}
As you can see the program is simple. Turn on a LED, Delay, Turn the LED off – go to next repeat forever.
The only objective was to generate a set of signals for this quick review.
Comparison of Debug and Release Mode.
The first scope image is the program running in Debug mode the next image is running in Release mode – see the difference? Check the first image.
Hint: Check the frequency. Same code – just a release versus a debug version.
One of the things I like about this modern scope (I started on a Tektronix 453.) is the ability to turn on the measurements and not have to quint at the scope face. My calculator (or slide rule) can stay in my pocket protector.
Future Test Bed units
Hopefully, I’ll be able to use the Atmel Sam4S Xplained unit shown here to show off the I2C capabilities. Stay tuned.
The demo program has an interface analog and I2C data collection units. I’ll see if I can extract some data.