Summary of today: We will not work with the counter reset for the time beeing, we might change it or remove it completely in the final product. To learn why we ended up with that decision read on.

What you see is the same Python test program we wrote the last week. We wanted to confirm that the counters are working. We can confirm, that the change we made solved the issue with increasing the second counter too early. However, if we look closely into the counter we see this:
0x7FE
0x8FF
0x800
The second counter increases and then the first one is reset to 00. It might be not important because the counting still works as intended just the increase is a tick too fast. But we need to keep that in mind if we write the program! Otherwise when we read the values at exactly this time we end up beeing wrong by a full 0xFF or 255 counts.

After further testing, we encountered a big problem: The MRC trigger does not reset the counter instantly, there needs to be another CPC tick. This is fine for the first counter, but the second counter gets this pulse only after the first counter has counted to 255. So send the reset command and we have to wait for the first counter to clock up to 255 again to send one pulse to finally reset the second counter. We could add additional hardware to work with that, but for the time being we shift the solution to the software side and don’t use the resets at all.

This session we started to work with Python to read the data. The final dataflow Brice suggested (http://www.ulm-experience.com/) should look something like this: I2C -> MQTT -> Telegraf -> InfluxDB -> Grafana. For now python is in charge of reading the I2C data.

Hardware

We found another flaw in the schematics. The second counter is not counting correctly, it is counting once the highest bit of the first counter turns to 1 (hence at 1000 0000 or in hex 0x80) instead of at 1111 1111 to (1)0000 0000. To solve this we use the RCO output of the counters instead of the highest bit.

Software

We wrote a small python script to be able to read the values from the two counters and verify that they are counting correctly. For this to work we start a putty (https://www.putty.org/) SSH connection and a WinSCP connection (https://winscp.net/eng/index.php). I use Sublime (https://www.sublimetext.com/) and the SFTP package (https://packagecontrol.io/packages/SFTP). With that I can write python code directly on the raspberry with a remote sublime connection and then run the script in the SSH with putty.

On the raspberry you create a folder named “Test” in the home directory (/home/pi/) and create a file named test.py. The code looks like this:

import smbus
import time
bus = smbus.SMBus(1)
address = 0x20
GPIOA = 0x12
GPIOB = 0x13

def readCounterBytes():
	lowerByte = bus.read_byte_data(address, GPIOA)
	higherByte = bus.read_byte_data(address, GPIOB)
	return ((higherByte << 8) | lowerByte)

while True:
	iobits = readCounterBytes()
	print('Hex: ', hex(iobits))
	time.sleep(1)

To run the python you switch to the “Test” folder and the run it with “python test.py“

If you want to work with sublime you have to configure the raspberry server connection in SFTP. My file looks like this:

{
    // The tab key will cycle through the settings when first created
    // Visit http://wbond.net/sublime_packages/sftp/settings for help
    
    // sftp, ftp or ftps
    "type": "sftp",

    "sync_down_on_open": true,
    "sync_same_age": true,
    
    "host": "192.168.1.159",
    "user": "PI_USERNAME",
    "password": "PI_PASSWORD",
    "port": "22",
    
    "remote_path": "/home/pi/",
    //"file_permissions": "664",
    //"dir_permissions": "775",
    
    //"extra_list_connections": 0,

    "connect_timeout": 30,
    //"keepalive": 120,
    //"ftp_passive_mode": true,
    //"ftp_obey_passive_host": false,
    //"ssh_key_file": "~/.ssh/id_rsa",
    //"sftp_flags": ["-F", "/path/to/ssh_config"],
    
    //"preserve_modification_times": false,
    //"remote_time_offset_in_hours": 0,
    //"remote_encoding": "utf-8",
    //"remote_locale": "C",
    //"allow_config_upload": false,
}

Link to the Github: https://github.com/TheCell/Weatherstation