Simmons LED Display Part 4: Django Web App

This is part four of my series on the Simmons LED Display. I'm going to describe the implementation of the web-based front end.

Here are some of the specs I wrote up for the web applic

ation:

1. Users go to the Simmons LED website to enter messages.
2. The Simmons LED website tells the user when their message will be displayed.
3. The Simmons LED server displays the message at the given time for a fixed time (2 minutes).
4. Only Simmons residents will be able to post messages.
5. Messages will be profanity/obscenity/inappropriate filtered.

It's a pretty simple idea, the only non-straightforward aspect is some misdirection in the form of a database. The database allows for separation betw

een the display code and the web page code. Here's the flow of the program:

1. A user visits the Simmons LED website.
2. The user is allowed access if they are a Simmons resident.
3. A message gets entered to the website.
4. The website profanity filters the message.
5. The website saves the message, with the current time, into the database.
6. The website asks the database how many messages there are in line.
7. The website tells the user when their message will be displayed.
8. The display service repeatedly checks the database for new messages.
9. The display service displays the oldest message for two minutes, then marks it as displayed.

The purpose of the database is to buffer the inputs, in case tons of users post messages all at once.

The Django code is shown below:

forms.py

models.py

views.py

Note: this code doesn't contain the profanity filter. I am planning on adding this as a validator in the message model.

The (very messy) html templates are coming soon.

Simmons LED Display Part 3: Software Implementation

This is part 3 of my series of posts on the Simmons LED Display. I'm going to discuss my implementation of the control software used to operate the display.

The software stack is comprised of four parts: a web service used to input messages, a cron-type service used to keep checking for new messages to display, a driver service used to convert the message strings into synchronized pin timings and the microcontroller code used to actually turn on and off the LEDs.

Even though the C/C++ environment of the Arduino is super-easy as far as microcontrollers go, I chose to keep most of the logic on the computer running the web service. This meant I could implement the hard code in Python, making my life much easier.

An overview of the software stack is shown to the left. It might look like a mess: that's because it is one. I'll attach all of the source code files soon, as well as instructions on how to use them.

Coming Next: Django App Sources