Power Analyzer based on a COTS Power Monitoring IC

While thinking about the calibration wizard, the idea occurred to me, that empty EEPROM-space may be used to store user data. For example the calibration date. So I added read and write functions for whole addresses, to see if it works. 

It does work with unused EEPROM-Space, for example register 0x0F bits 20-23. Other unused bits may be used as well. They can be accessed by using the writeEEPROMValue function, with a 32-bit mask, where the corresponding bit-positions are 0.

Datalogging

For long-term datalogging, an SD card can be used. Because the space is somewhat limited, for such a bulky SD card, a 6-pin header was added. The SD-card can be mounted anywhere in the housing and connected to them, just like the display. And I added pin-descriptions, because I they were missing.

The goal for the next few weeks, is to develop a "calibration wizard", to guide through the calibration process.

Additionally, I will try to write build-instructions at least for the housing, in case someone wants to build it similar to this prototype.

When hitting "read" of the button in rapid succession, the Teensy somehow stopped working and had to be reset manually. To fix this problem, I used a Watchdog-Timer which is fed periodically and resets the teensy after 30s, if not "fed". The library used for this is the WDT_T4 library by tonton81.

The reason for the bug under load is yet to be determined.

Changing between "voltage", "current" oder "both"-mode does not always work.

I fixed it, by disabling the Radiobuttons while streaming. In addition to that, the bus-flush was improved, by clearing out the input buffer with the .reset_input_buffer() function.

The GUI connects with any port that is found, even if it's not the correct teensy port. For debugging, the teensy is used in dual-serial mode. Only one can be used for bidirectional communication. A handshake with the teensy should fix this issue.

The handshake implementation was a bit difficult, due to confusion decoding. 

The handling is done in the GUI.
Readings from the serial bus are represented as bytearrays, which have to be decoded with 

    ans = answer.decode('utf-8') .

This returns a string, which is shown by print(ans). The teensy is configured to send the string "tconn" upon request, which I double checked is the case.
But the comparison of ans == "tconn" didn't work, even if print(ans) returned the correct string. 

After some troubleshooting, I found the solution. The repr(ans) function returns the exact representation of the string. And apparently, the string contained a newline character, which should've been removed after reading. Naturally "tconn\n" == "tconn" returned false every time.

The issue was fixed in the readline function of the special linereader class. It returns the first value in a buffer which is separated by a newline character. The linereader looks for the next index i where "\n" is located in the buffer and returns all characters by accessing 

r = buffer[:i+1]  (representing "tconn\n") .

removing the "+1" solved the problem.

This fix is stored in a separate branch "BugFix_Handshake"

One of the most important things in any software program is readability. This does not only enable others to understand the program, but also decreases error-proneness.

As a first step, I reviewed how the code is structured.
Basically, all files are in one directory. The current structure is shown in the following diagram.

It is a simple structure. It consists of one page per general function. Because all of the pages look and function a bit different, it is not necessary to create an abstract base-class for pages. Utils can be used by all functions, while the serial_device ist instantiated by the backend.

One thing, that would make the GUI more intuitive would be to change the names of the pages. Something like "Values" seems to be more accurate instead of LivePage.

The names of variables should give a hint to what they do. While I'm at it, it is a good idea to make the page classes more consistent, too. They should all contain 

• an init_GUI-function, which contains style-definitions and all GUI-elements for the page
• A convention to function names. An underscore ('_') is used for internal use in classes
• Correct documentation

It is useful to add new pages later, in case the functionality should be extended.

Documentation

There are various documentation methods for python available. PyDoc uses docstrings (in triple quotes at the start of a method) and annotations in method signatures. More information can be found here.

All of that should increase the readability and extendability.

Apparently, I saved this as a draft...
The documentation of the code is finally done and a docs-folder now exists with the documentation to each python module, created with pydoc. It was interesting to learn about different documentation techniques, as there are many good solutions.

I used docstrings, because the project is kind of small and they were the easiest to do. For a bigger project, sphinx does look a lot more capable.