Case: Environment sensing, part 3

Posted on su 24 syyskuu 2017 in Articles

Planning what the weather station should or could do:

1. We made a list of all kind of sensors one can easily get to know our options. Some sensors just were way too expensive (like oxygen or CO2) and some were not super accurate (like methane which actually gives stronger signal from hydrogen gas...), so we would not get any good data as they would just give zero unless world was about to end (we tested carbon monoxide and when it would alarm, we would have been dead long ago). And some sensors just did not make too much sense in our device (like alcohol gas sensor or magnetic field). So, we ended up just with humidity, temperaure and air pressure. Of course we have the option to add more interesting sensors afterwards if we wanted, like light sensor for helping to grow plants efficiently.

Only thing that separates our device from any ready made weather station is that we could add multiple sensors into our network ang get things like heat maps and study changes in multiple locations.

sensor list

2. Physical layout What we needed for the device are sensors, something to read sensors and communicate their information forward ( ==main board ), way to transmit the data to internet so we can store and play wih the data. Practically we ended up with this sort of design:

physical layout

3. Physical wiring Parts need to be connected somehow. Changes in measured variables are not super fast or at least we would not need that big accuracy -> one measurement in minute should be sufficient for our purposes. This means that the bandwith does not need to be huge as not too many messages are going back and forth. Means processor does not have to beefy and main communication bus does not need to be super highly effective or complicated. Sensors are small and to make them usable and handy, the wiring to them should not be huge -> small cable is enough for them as the wire needs only to carry simple messages and not often. Meaning small wire is sufficient for these purposes.

Main board needs to be connected with RaspberryPi with some easily available standard cable: small single wire is not sufficient to carry all information and power, therefore multicore cable is needed. That sort of cable transfers power in one or more wires, and different types of messages are transferred in their own wires also. RJ45 was chosen because they are everywhere, that sort of connector is easy to put into a PCB and it has enough of cores ( 8pc ).

Originally RaspberryPi did not have wifi but newer versions do, so it is easy and simple way to transmit the data forward. So, no wires needed :)

But only wires don't yet make messages go forward and device receiving also needs to understand the messages and their purpose to act accordingly. Different kind of busses are used to trasfer messages in standardised way: meaning that trasmitting and receiving devices just need to follow the standard and it does not matter what is in the other end and things will work. There is plenty of options for bus standards because all different manufacturers have made their own. However, some busses are more commonly used in certain fields and applications.

Sensors and other microchops often support I2C standard bus. This is special bus because it does not only spec messages and way of transimitting and receiving them but also th electrical side of how this is done: what voltages are recomended and that when transmitting device wants to send zero, it needs to ground the connector line ( ==active low driving only, "open drain" ). Other way would be to activly drive both high and low ( ==active push and pull) but this is bit dangerous as if two devices are sending messages in same time, there may overload something as there is too much current going on. So, I2C bus was chosen as our sensors were supporting it diretly and it is really easy to use and implement (known from previous experiences).

Main board and RaspberryPi have a lot more complex communication, so simple I2C would not work, specially as this connection has to tolerate a lot more interferences ( like 50Hz from mains power, and noise bursts from washing machines, microwave oves and cellphones ), longer cables and errors in messages (==more error handling and therefore also longer messages). RS-485 was choces as it is the most used one and the most common way of doing this. Modbus was chosen as communication protocol as it is common automation protocol, it has good documentation and error handling, ready made commands/message types for all things needed ( just previous knowledge... ) AND it is publicly available and royalty free. One other possibilty could have been for example SCPI which would transfer for example numbers with sign and unit unlike Modbus where every number is unsigned and there is no units. So, that would have been a good feature but it's defination seem sprety broad and we had no experience with it, so Modbus was safer option.


4. Outcomes from these choises RaspberryPi can communicate in total with 32 main boards because RS-485 would otherwise get electrically too loaded. This information can be found from the manual of RS-485 trasceiver chip that is used on our main board.

Main board can communicate with sensors that are approximately 1 meter away because wire capacitance would otherwise be too much. This is written in the I2C specification ( limit is 400pF which means approximately 1 meter thou it varies some depending on what sort of wire you use ). If one wanted to have longer distances, they would need to use I2C amplifier in the middle, so that messages would remain intact, crips and clear.

Each sensor need to be unique: no one wants to get random data they have no idea where it came. This limits number of sensors as they need unique IDs == I2C addresses. Depending on chip, you can use only one address but some do support few different addresses. This is why one board can only serve one or few sensors unfortunately. And like if one wants to make a heat map, one needs to choose sensors that support multiple addresses.