What was the problem to be solved?
The City of Jupiter, FL had a problem with an upswell in outdoor businesses violating noise ordinances.
Restaurants with outdoor entertainment became vogue in the posh town.
However, these eateries would run afoul of the city ordinances which regulated sound levels at certain times of days.
The city relied on residents to report the violation and these reports were based on conjecture. The residents THINK the noise is too loud.
This meant that the city would have to respond to the complaints and send out a tech who may arrive only to find out the sound levels were within compliance.
At the same time, the businesses also didn’t know if they were in violation so they, too, had to guess at noise levels.
What was the proposed solution?
Kurtrox proposed a solution that the city jumped on, which was to build devices connected to solar power which could be mounted outside such facilities.
The devices would monitor sound levels and change from green to yellow to red, allowing all parties involved to know if there was a violation.
The businesses would know if there was a violation by looking at the stop-light-like device to see if they were approaching red.
Once the device hit red, the onboard computer would notify the city who would know immediately a violation occurred.
We built the software for Kurtrox’s embedded solution.
What challenges arose during the project?
There’s no question this was a tough project.
Converting a raw volume reading into a decibel ratio required us to baseline each device upon deployment.
Over-the-air firmware updates also became a challenge as did the sheer amount of data we had to send via cellular data and also store for historical review.
What was the technical approach to the project?
Internally, the embedded devices were Beaglebone Blacks that ran off of constant power from a solar panel backed up by a battery.
When the devices came on for the first time, they would use Node.js to capture a baseline and then used this baseline to capture, calculate and broadcast a decibel level every second.
The raw data was stored in AWS S3 buckets where it was streamed via AWS Kinesis and Lambda to DynamoDB and also Athena.
The insertion into DynamoDB tables placed the data in another stream which another Node.js Lambda process handled responding with the acceptance of the reading via a persistent socket (Green, Yellow, Red).
Additionally, if Red, the Lambda function would notify the city via an email sent by AWS SNS and SES.
The entire setup was pretty much headless and serverless relying heavily on AWS IoT.
If the city desired, we could generate ad hoc reports based on device from the time it was first turned on.
What was the project management approach to the project?
Finding the right data plan and device was a huge unknown, so we ended up starting the project with four research sprints to determine the best combination.
After that, we used feature/bug sprints to build a device prototype that could run Node.js.
After we had a functional device prototype, we begin working on a standard sprint schedule until release:
1) One week function sprint where we added new functionality
2) One week QA sprint
3) One week bug fix sprint
Repeat until finished.
What did you learn from working on this project?
We learned a lot about Big Data – especially in conjunction with AWS.
We have worked on projects with tons of data, but this one exceeded all the others.
Also, we learned how to use persistent web sockets via IoT to communicate with the remote devices.
Why was Gunner selected for this project?
Kurtrox had worked with Gunner on a number of IoT projects so there was a built-in familiarity here.
Kurtox also had offices located close to Gunner, which made collaboration relatively easy.