project: skipper

2024-08-23 - ongoing
no picture yet

this project consists of two main parts, a library and a test executive

library

this is a virtual instrument library, it does not attempt to implement any ivi standards(though it may in the future).

this library is for control of (generally electronics but may support other) test equipment such as

and many more

so far there is a support for

and more will be added in time

test system

this is an exciting future development and is subject to massive change... the basic idea is to make some form of GUI test composer that is able to programmatically design and run tests on E/EE/PE assemblies and possibly others... the simplest way to describe this would be along the lines of: "given the hardware and test equipment configuration, step the input voltage and output current producing graphs of efficiency and load regulation". the ability to also define states and others will also be needed

the concept is underworked so far but given the reasonable level of drivers i am now in a position to design this

blog

date: 2025-04-20 05:27:44
recently a project was undertaken to rewrite the skipper build system in cmake. this is complete.

the new build system has an improved test system by enabling coverage and generating gcovr reports

there is now 100% coverage unit testing of the datastructures and >90% coverage of the utils directories. the utils are lower as there seem to be some redundant checks leading to never-followed branches. the pruning of these is planned


date: 2025-03-22 23:19:05
the oscilloscope interface rework project is now complete!

the new interface is easier to extend and to read

the testing was fun, the switchBox was connected to a toy keyboard from argos in such a way that each individual key could be pressed and the speaker was connected to an oscilloscope. the keys were then pressed in turn with the oscilloscope measuring the signals. this measurement was verified and was within a reasonable bound(given that the keyboard has lots of jitter and drift)


date: 2024-12-19 01:46:47 other projects: switchBox
after a little testing, the source of a major inaccuracy of the skipper PSUTester has been discovered. the root cause was the PSU current measurement was rounded to 2DP by the instrument but the load current measurement was not and had many extra digits which could, when PSU connected directly to load, output an efficiency of >100%(up to 104 in fact!); after similarly rounding the reading from the load everything returned to a realistic figure(loopback was somewhere around 99.99% which is good enough).

here are some outputs of the power tester. they are regulation and efficiency graphs for the flyback on the switchbox project


date: 2024-12-17 20:48:24
there has, for several days now, been a Qt frontend which provides a PSU testing tool

the tool in the frontend is not desirable, it was produced to provide some insight into how best to proceed while also providing useful output(was used to verify that the switchBox PSU operated correctly(it did))

the plan is still to have a frontend that can be used to open and run tests that are stored in config files. how it will do this is still TBD...


date: 2024-11-06 00:00:02
even more quality improvements! (still no unit testing) the quality checks have expanded to also use clang-tidy

this has all led to a fairly large change in development environment, i now have the following in emacs

  • eglot (LSP)
  • company-mode (autocompletion)
  • have left the terminal! i use the GUI
  • a nice start-of-day function that sets the frames and tabs up how i like

as this is a makefile project, it needs a clang compile_commands.json for the clang utilities to work. this is done with bear which was in the debian repos. all that is done is either: call make through bear bear -- make -j or(if there are existing build remains) make compile_commands.json

it wasnt so good at the start as clang-format(which eglot-format-buffer uses) uses the wrong formatting style. this was fairly straightforward to configure though so not too bad

clang-tidy is a big beast, it can be fooled into breaking things by telling it to fix code enough times!(im still learning lots about modern C++!) but can be reigned in like other static analysers... i settled on the following checks configuration performance*,modernize*,-modernize-use-trailing-return-type,readability*,-readability-redundant-control-flow,-readability-identifier-length,-readability-magic-numbers,-modernize-redundant-void-arg,-readability-else-after-return,-modernize-use-equals-default,-modernize-pass-by-value which seem reasonable?

all of this because i want to be able to control some instruments!


date: 2024-10-23 02:55:10
woop! SDM3055 support is now here!

there are loads of quality improvements though

  • docs
  • proper compiler error flags
  • unit testing

docs are simple and are being worked on, when reasonable docs will move over to being an ongoing process

compiler error flags should have been done when the Makefiles were written and there is a big chance that enabling the normal -Wall -Werror -Wextra flags will cause some nontrivial rework

unit testing will be new, ive only done a little bit of CPP unit testing and that was in TESSY which is out of my price range


date: 2024-10-22 00:16:35
ive decided. the SDM3055 will first gain a SDM3055 driver which does not use the scancard. this will implement a new DMM interface

when the SDM3055-SC driver with scancard support is written it will implement a new scanningDMM interface

there is now also some minimal support for gitea actions


date: 2024-09-23 22:05:34
the next device that will be supported by skipper is the siglent SDM3055-SC. i have not yet decided whether to support the front panel or scan card first; there is a forced exclusivity between the two as when the scanner card is active, the chosen input is routed to the front panel

this will lead to a new DMM and scanningDMM? interface. the interface name for when a DMM with a scan card is used is currently undecided as this may fit better under a DAQ label but this is uncertain as i have not looked at DAQ that deeply