Week 19 - lglik/Portfolio GitHub Wiki

01/14/19 - 01/18/19

Day One:

I kept looking for a way to make i2cget return more than one byte since it seemed unlikely to me that there would not be a way to do that. From looking through the documentation online, I found out that the function could be set to return a word which would return both bytes in this case. Strangely, the parameter w that sets it into "word mode" is simply added at the end of the command in termit and not with the standard "-[parameter]" format. I successfully got both bytes from the register and used that information to determine that the board was in "single shot" mode. This was what I had expected since this was the default mode according to the documentation. I opened up the library for the board and took a look at the code. I first went about trying to understand how the parameters I would pass in my code were manipulated and then passed to the board. First, the channel number passed as a parameter was converted into a byte, then a second empty byte was append to it. Using bitwise "|=" operations, the gain, mode, and data rate were all added as bits to the word. Then, the bytes were split apart and individually sent to registers on the board.

Day Two:

Pictured below is the _read function which is in the library of the ADS1015 and contained the bit-wise operations discussed in the previous portfolio entry. The function I called in the code I wrote is not this function but a different one that only has one line which calls the _read function. However, I discovered that one line had a hard-coded parameter that set the mode to be single-shot. For testing purposes it seemed useful to me to try to be able to modify the registers from the command line and manually set the mode to be continuous. I typed out what I would want the bytes to be and then converted them to hex. I used i2cwrite and the same protocols with the pointer register to write that hex number to the register. To see if this worked I again used i2cget to return the register. I was semi-successful. The bit I had wanted to change was changed correctly, but another bit was also changed. I have absolutely no idea why this happened because the default value for that bit was the same as the value in the bit I put in the new register. I tried to change it again to what I wanted and tried changing some other things, but for some reason that bit would just keep changing. This was quite an issue since that bit would change the datarate to something that would not work with my program.

The _read function in the ADS1015 library.

Day Three:

I took a step back from trying to change the bits to think about what exactly I was trying to do. I realized that it really was not necessary or useful to be able to change the register by writing to it from the command because even if I was able to successfully, the code in the library would immediately change it back. Therefore, I would need to modify the code so as to pass different bits to the register when it runs. One of the parameter passed into an intermediary function in the library was "ADS1x15_CONFIG_MODE_SINGLE". I changed this to a different variable I found defined but not used else where in the code called "ADS1x15_CONFIG_MODE_SINGLE" on the theory that this would change the mode from single-shot to continuous. When I then ran my code the numbers did not change. It was certainly possible that changing to the continuous mode would not have changed anything, but upon using an i2cget, the register had not changed. I tried to change some other things in the code such as data rate, but none of these changes actually seemed to take affect when I looked at the register. It occurred to me that perhaps the ADS1x15 library I was editing was not actually the one being used by the code in the project.

Day Four:

I put print(Adafruit_ADS1x15.file) to return the location of the ADS1x15 module that the code was using. The location returned was definitely no the location of the file I been editing. I made the same changes I had made in the other file, but this time these changes were actually reflected by the values of the bits in the register. The numbers output by my program seemed to actually be reflective of the real voltages this time. These numbers were much more consistent as well. Now that I was at least a little confident in the validity of the values I was getting I added in some code (pictured below) that would drain a battery, switch the other battery, and so on. The idea being that by the time one battery is drained the other would, hopefully, be fully charged. This is a better system that simply switching to whichever one has more voltage, because the batteries will maintain their better when they spend longer fully charged. I also made it so that there was code to exit the program if both batteries were drained. The reason that this code is necessary is that the project will keep running and drain the batteries to the point that they are permanently damaged.

The code to control which battery is used.

Day Five:

Absent. 🧐😔🤠