Implementation

Taking inspiration from the problem we faced during our internship we designed and built the room occupancy system for our college project. We tried our level best to make the system ready for implementation in a real-world scenario. This involved taking into consideration factors like range, power consumption, enclosure design etc. So in June-July of 2018, I did an internship to actually implement this system at their office in Mumbai.

Two problems which I faced and were a great learning for me are described below.

  1. WiFi Interference

We used off the shelf radio modules for the communication between the devices. During testing at home they worked flawlessly for hours, however when I implemented the same in the office environment, the devices behaved erratically.

I observed various issues like

  • The devices would randomly go dead for no apparent reason
  • The radio modules would be non-responsive but started working as soon as I touched the module
  • The current consumption indicated that the radio modules would randomly fail to wake up from sleep and thus became non-responsive

I tried various software and hardware solutions to fix this problem but none of them seemed to work.
After over a week of troubleshooting, I eventually figured out that the cause of this erratic behavior was due to the high intensity of WiFi signals in the office. Due to the interference, the radio module would not wake up from the sleep state I would put it in to conserve power. The solution was to shield the radio modules using a piece of ESD safe plastic. This greatly reduced the intermittent behavior of the modules.
You can see the effect the ESD safe bag has on the WiFi signals.

 
WiFi interference

2.  5v supply issue

After all the issues were resolved, I was confident to leave the system running 24/7. However, the radio module on the master node stops working randomly after a few hours. I was surprised, as the master node had never failed during all my months of using it.
I tried to make it work by restarting the master node but it would work for a couple of hours before failing again. When I went 2 days later to try and debug the problem, I just couldn’t replicate it even after a lot of testing.

I thought about what could be causing the problem like supply noise, WiFi interference etc. A week later I discovered that the supply voltage to the radio module was 5V, up from the maximum rated voltage of 3.6V. The reason it did not cause me any problems earlier was that I had switched the FTDI module a day ago. I had no reason to doubt that this one would be any different than the previous one. However, the new module supplied 5V instead of the expected 3.3V.

The surprising part of the problem was that supplying 5V instead of the rated 3.6V didn’t fry the radio module instantly; instead caused the radio module to behave erratically. This made the problem all the more difficult to debug.

In conclusion for implementation of the project there were a lot of upgrades that needed to be made to the system to make it implementable and robust; like using watchdog timer to come out of system hangups, adding exception handling, proper design of the enclosure, battery life consideration, database management etc.

Implementing this project was challenging and gave me an exposure of issues faced in real life implementation due to the unique nature of problems I faced – they were non-reproducible and intermittent: and hence testing any solution would take a long time.

Leave a Reply

Your email address will not be published. Required fields are marked *