Data Acquisition: Round Robins & Serial Port Contention

Now that we have proven our ability to read multiple sensors via the Adafruit multiplexer it's time to think about how Spot:Bot will collect its sensor data on an ongoing basis.

The best way to do this is to write a data acquisition process that continually performs a round-robin of all the I2C sensors on its list of known sensors. We can write a configuration file that tells Spot:Bot about all I2C sensors on the network and the order in which we want to communicate with them. We will call this ordered list of sensors our scan loop.

We have decided to create a configuration file for this where we can switch sensor readings on and off easily by simply adding them to and removing them from the scan loop. This allows us to choose specific sensors to test with on the fly and/or easily switch sensors on and off on a per-challenge basis in production code simply by using challenge-specific configuration files where necessary.

Our chosen configuration file format is JSON. Here is a sample:

{ scan-loop : [1, 5], timing : { sensor_sleep = 100, scan_sleep = 100 }, "1": { "name":"distance-left", "type": "tof", "i2cbus": 1, "i2caddr": 29, "mux": 0, "config": { "range": 2 }, "readfn":distance, "writefn":null }, : : : "5": { "name":"compass", "type": "6dof", "i2cbus": 1, "i2caddr": 1C, "mux": 4, "config": {}, "readfn":bearing, "writefn":null }, }

Serial Port Contention & "Personal Assistants"

Imagine how you might feel if everyone was trying to talk to you at the same time. As more and more voices are vying for your attention it can become a little discombobulating trying to hear the messages above the din. However, if you employed the services of a PA to take all your messages and respond on your behalf using only the most up to date information that he/she has collected from you, all you would have to do is ensure that the PA's records are kept up to date by regularly updating the PA yourself in your own way and at your own pace.

Well, serial computer data buses (such as I2C) can suffer from a very similar problem if you don't manage the requests that need to be delivered over those data buses properly. In the computing industry we call this problem Serial Port Contention.

We will be adopting the personal assitant principle when collecting I2C data and supplying the processes that need to use it. Our data acquisition process will operate independently of our main control process and will be our single point of contact on the Raspberry Pi with all things related to I2C sensors, including the OLED.

We will determine how frequently it will poll sensors in our scan loop (similar to updating your personal assistant's records) and how long it pauses for between subsequent loops of the scan loop (how regularly you choose to feed your PA with updates). These values are specified in our config file in the sensor_sleep and scan_sleep values respectively (sepcified in milliseconds). We will call this our I2Cmaster (the sensors are its slaves).

For reasons of efficiency, rather than publish value updates with every sensor read, our master will simply publish a JSON data payload conatining all latest known values at the end of every scan loop. Other processes can simply take whatever values they need from the update.

comments powered by Disqus