Who hasn’t experienced our annoying dorm’s laundry room?
Which student in the village has not been there before: one wants to do his or her laundry and heads out for our bright green laundry room in the communal house. Packed with several loads of clothes one enters the room and – disillusionment… All washing machines and dryers are already taken and the dryers do not even display how long they are going to run, since this depends on the amount of clothes and how humid they are.
So what to do now? Bring all your stuff back home and return later? Wait until one of the machines is finally free? What to do when you got a dryer but do not want to wait until it’s finished so nobody will throw your stuff out on the dirty floor, just because you are not standing right by to get all your things?
Some of us from OlyNet are living for quite some time here in the village and have been very annoyed many times by this dilemma. So we thought who, if not us, could provide a solution 🙂
The trail to our current design
Thus began the long development phase of this project. Following the KISS principle we first thought about the most simple solution where every user of the machines in the room would enter start and end times on a web page. The fact that this approach would never capture the entire states of every machine correctly was obvious right away.
So we passed over to surveil the machines, dryers and washers, on a electronic level. We first had in mind to utilize the integrated features of the devices, while we found out that they have the ability to communicate with a computer using extension cards. Unfortunately, those cards are very expensive and we would have to install many cables. In addition, this would have meant to alter the systems of a company that we do not have a connection to.
Together with the company who runs the machines, Rent-Wash, and who developed the vending machines, we created a first draft in which the signal on paying for a program was recognized and processed. But since the circuit in the vending machines is quite complex and we could not get any documentation on the systems inside them, we discarded that idea again. Besides others, we finally came up with measuring the current consumed by every machine directly on the wires to the sockets. One of the great advantages over the first idea above was that we could retreive a continuous measurement for every node.
The ideal place to install such a system is the large breaker box where all sockets of the laundry room are wired together. So we began to design a system that would fit into this box and simultaneously live up to our expextations:
- continuous measurements of current running to each machine
- easy elicitation and retrieval of data
- interface as web service to collect and process data
Magnetism (or: back to physics of ninth grade)
Although we initially had our feelers out in several directions, we found one concept the most promising: the “current clamp” with a bus connection. If one is not an electrician or has worked with that tool before, it is probably not very well known. So here is an example image from the german Wiki page:
The basic idea is quite simple: a current-carrying wire produces a magnetic field in an inductir. The ferrite core of the inductor has an air gap in which a part is placed that measures the strength of the magnetic field, a so called Hall sensor. The larger the current in the wire, the stronger is the magnetic field. Thus measuring the strength of the magnetic field allows to quantify the amount of current carried by the wire. The fact that no modifications to the machines in the laundry room is necessary made this solution the most promising to us.
Even if we did not have any substantial knowledge about electronics, schematic design or micro-controller programming, we started to do research about those topics and read about basic projects. The first designs were quite frustrating, our design software EAGLE CAD was not as easy to handle as expected, but we made progress and got used to all those new names and patterns. In addition we searched for a way to model the heart of our application in silico. The most promising software was LTSpice by Linear Technologies, which helped us to simulate the module with an operational amplifier.
In this way we created a circuit which delivers usable values even with a tiny values from the Hall sensor, since we amplify the signal through the op-amp. Particularly intricate is the fact that the polarity of the magnet field is related to the voltage in the conductor. Thus we have AC voltage, the polarity of the magnetic field changes frequently. The Hall sensor steadily provides a small delta in dependence to the magnetic field strength. In idle state we get an output of half of the supply voltage which is+5V, thus +2,5V output.
If there’s a constant current flow through the conductor, the polarity of the magnetic field will switch steadily between +2,4V and +2,6V. The delta is in any case of the same quantity: 0,1V. This fact is very important, especially for further processing of the signal!
The processed output voltage of the sensor is converted by a simple analog digital converter of a micro controller into a number, for easy analysis later. But first we need to get this number out of the memory of the micro controller. Therefore we use the previously mentioned data bus to connect the individual devices and interchange information.
In our draft we decided to use a CAN-Bus, which is used in most of the cars today (as well as in microscopes, robots, machines, etc….). The documentation and part supply is very good, even in the maker community you can find tons of instructions. Back to our model: the previously digitalised measurement is sent through the CAN-Bus to another device. We named it ‘controller’. One controller is in charge of many sensors and plays a very important part: it administrates all sensor nodes on its bus and regularly requests their mesured values that are saved locally. But of course these values need to be accessed from outside. Therefore, the controller is using the ethernet protocol as well. In a nutshell, we build a web server on this board that presents the measurements in a friendly data format.
All this data, information and thoughts “only” needed to be integrated into one comprehensive model. As mentioned earlier, we used the software EAGLE CAD for developing electronic circuits. As an example how this looks, here is an impression of the board layout of our sensor node:
This circuit design was handed to a manufacturer after intensive inspection and prototyping. At this point we would like to thank the IT department of the Studentenwerk München again for financing this project gracefully.
Since the EAGLE designs could be quite confusing after a while, we also modeled our creations in 3D. This helped us especially when placing the components on the board. Furthermore, we could easily fit our design to a case and print out drill templates for precise insertion. A case is necessary, since the controller node will be located outside the fuse box and should thus be protected.
Manufacturing these boards took a long time, unfortunately. By now, they are all finished and delivered. A very proud moment for us was the first view we had on the real PCBs:
To finish the boards, the ferrite cores needed to be cut in to get an air gap. Afterwards, they are glued on the PCBs. With a steady hand and patience this worked quite well. Here are Flo and Sebastian at work:
With this step, the “hardware” part of our project reaches an end and we now need to focus on the interface and thus how inhabitants will be able to use our service.
Simultaneously, OlyNet develops a smartphone app for all the people in our dorm (and those who are still interested in what is going on here). This app shall also interface our laundry service, so everybody can easily get a status on how many machines are currently taken. One very important feature will be a notification service that allows a user to register for a certain machine and be notified once the program ended. This will be accomplished by simple selection menus and QR-codes on the machines making it very easy to get a message once the program on your machine finished.
But the question remains: how do you get to this notification just by current running through a wire? Well, in theory the technique is described above but there is one key factor missing: the firmware of the circuit boards, i.e. the software that is controlling all actions and communication. This firmware (actually there are two, since we need two separate ones for our controller and sensor nodes) is being developed using tools from the microprocessor’s manufacturer Microchip. Since we decided to use PIC controllers, we went for their IDE MPLABX together with the latest compilers (XC8, XC32). Although the software had quite some bugs and was missing a lot of features, we got it running and were able to implement the required functions. All code was written in C. To make our lives even easier, we relied on Microchip frameworks to implement large parts of the programs. Although the Harmony framework has indisputable drawbacks and is mostly as slow as a snail, we had to focus on making progress for a first testable version.
The development of the sensor firmware could basically be done on the prototypes we ordered first. For the controller, this was a little more complicated, since the chips are more complex and two interfaces had to be integrated, Ethernet and CAN. To get a foot in the door, we used a pre-assembled demo kit from Microchip and developed the web server code for this. Since the schematics were available, we used them as a guide to developing the controller’s circuit.
The available demo projects for the starter kit were up and running quickly, but then the hard part began. We needed to develop our own administration panel and the logic to process the inputs. That included handling configuration for all registered nodes on the CAN bus. To make this a little easier, we decided to let every node send a message to the controller once it is starting up. The so created list is presented on the interface and lets the user edit the configuration for each node. Every sensor gets its own ID for mapping the measurements and for simplicity we set these IDs to the numbers of the machines in the laundry room.
This configuration needs to be saved permanently along with other important data in the program. Unfortunately, our MCU does not provide a dedicated EEPROM memory and we also forgot to include a distinct part connected by I²C or SPI bus. Hence, we digged a bit in the compiler’s manual and used special flags allowing to place our data in a reserved memory block exclusively. It is important that our data is the only residing at this location as the block needs to be erased every time before one can write new values to it. If other parts of the program would lie there as well, they were lost after an update.
So after we finished the web specific parts of the controller project, we decided to try the created firmware on our controllers, not only on the demo board. We were very curious the first time we flashed the firmware on one of the boards. And we were very happy to see that the programming part went well.
But the disillusionment followed straight after, since we did not get a proper network connection. We further observed that the chip responsible for the physical Ethernet layer did not heat up at all indicating that it was maybe not even running. So we started to go through the code and the designs looking for errors until we finally found it, a rather embarrassing mistake:
Right above the label “C5” there is a thin yellow line, which was exactly the problem. The pin of the Ethernet PHY-layer chip that is connected to the copper area under that label needs to be connected to +3.3V supply. Our electronic specialist Aqeel was luckily able to scratch of the protection from the copper and create a conducting bridge between the capacitor C24 and the respective pin on the PHY. Afterwards, the program was flashed again without any problems and, voilà, the web server worked and delivered all content as expected. Still, one little downer was left: both status LEDs on the Ethernet connector did not work, since we connected them wrong. But that could easily be fixed later on.
So now the CAN bus needs to be implemented on the controllers. In order to communicate properly with all the connected nodes on the bus, numerous configuration parameters have to be determined and set in the firmware making all bus nodes communicate at the same speed. The theory behind these timings is quite complex and will not be discussed in this article. The only important thing to mention is that we got it working after days of work. The manufacturer of our microchips did not really make it easy for us with his software frameworks and development environments. Although there is a plugin available that calculates all the parameters for the CAN bus, you cannot simply apply these values directly. We only detected this nasty caveat by chance inspecting a demo project of the manufacturer’s framework where we found the following line of code:
Without further issues, the connected logic analyzer detected the test messages between our nodes. First, an image of our setup (top left: Saleae logic analyzer with a custom board to connect it to a CAN bus, made by Aqeel; bottom left: controller, prototype and final measurement nodes with debugger and programmer; left: switch to test Ethernet and use the custom CAN-bus sniffing tool in the firmware):
After the adjustment, the ACK was given indicating a proper communication in the bus.
Now from the three core parts of the controllers, Ethernet, CAN bus and the SD card, two are working. The latter unfortunately is also the biggest problem. We missed several issues while designing the schematics of the board.
The SD card holder has several pins with different functions (see also http://en.wikipedia.org/wiki/Secure_Digital#Technical_details). Communication with the SD card is established using SPI bus, which needs four distinct signals: a clock, chip (slave) select and two data lines. Obviously it makes sense to connect the output of one side to the input of the other and vice versa. Sadly, we missed this crucial detail and connected both inputs and outputs together.
The card holder further has a pin for detection whether a card is inserted or not. If it is, a electric contact is closed signaling a logic “0” to the processor. For this to work, the signal must normally be a logic “1”. This is achieved using so called pull-up resistors. Our PIC32 does provide several of these resistors internally for selected pins but not on the one we connected this card detect line.
Thus quite a number of things needed to be fixed on our boards. The pull-up resistor needed to be inserted and the SPI data lines needed to be crossed. A (very) steady hand and a lot of patience with the soldering iron is necessary for that. At the end, it should look something like this:
The blue resistor connects the chip detect trace with the +3.3V signal (logic high or “1”) at the via connecting top and bottom traces. Enameled copper wires connect the vias of the SPI data lines with the copper trace of the respective other line. Both traces were cut close to the vias. The modified PCBs could now be tested so that the firmware can be finalized.
Sensor node firmware
The software for the sensor nodes was basically done on the prototypes, only slight changes had to be implemented on our final revisions. Here we approached the problem from scratch, created UML state diagrams from which we could build basic state machines (FSM) in the firmware. The most important point is that all nodes are basically in a deep sleep mode all the time, unless the controller explicitly asks them to wake up and perform the measurement. This way we reduce the overall energy consumption to a very low level. If all members on the bus would be active all the time, the total current consumption could grow up to a few Ampere, which would not be easy to handle.
So the sensors are sleeping until they receive a “personal” message to wake up. Afterwards, the enter the active state, perform the actual measurement and send the result back to the controller. Once they’re done, they go back to sleep 🙂
Another neat feature we implemented is a temperature sensor on every bus that is measuring the environmental temperature. The Hall effect sensor’s output voltage is depending on the temperature. To correct for this bias, we use DS18B20 sensors from Maxim using a so called One-Wire bus. Programming them was actually quite simple, since a lot of documents can be found on the net.
Processing the measurements for further usage
In order to finally serve clients with the generated data, we implemented a Java EE application that is running on our application server cluster. A high-available load balancer (based on Linux virtual servers) also acting as a stringent firewall distributes the incoming requests according to the load on the web nodes. On these, each one Apache web server and a Wildfly application server is running. The latter instances are connected to each other and are responsible for serving data (using a MongoDB backend) and processing input like registrations for notifications. Further, the code responsible for communicating with Google Cloud Messaging (GCM) and Apple Push Notification (APN) servers is located here.
We are currently still working on this, since setting up the servers took quite some time.
So, this is where we are right now. Are you getting curious about this project? Would you like to support us to finish it sooner? Or are you interested in other projects on our list? Don’t hesitate to contact us!
No matter if you have technical or other skills (or none at all, but are at least willing to learn), we need every helping hand in our association. Just come by at our office to one of our consultation hours or write us a message on Facebook or an Email. You will meet friendly and open-minded people that are not always talking about computers ;-). We can also offer extensions of your lease or a network to interesting companies. We are looking forward to meet you!