Blog 6 – Pause to plan

Up until now I was kind of flying blind. I had worked off a plan that I had formed in my project proposal and what I had in my head. I knew that I had to setup the Arduino and connect it to the cloud. I knew sort of knew how to do it from previous experience and what I had read online. But when I got it connected in the last blog I then was like what’s happening here? What have I done so far? I had an idea in my head of what was happening, but nothing on paper, so to speak.

I’m a visual person so I decided to come up with some diagrams that represent what I had done. I jumped on powerpoint, so I could create a series of diagrams, that represent what I had done so far. It allowed me to better visualise what was happening and come up with a plan of attack for what to do next.

Current Versions;

Version 1;

The first diagram was of the first iteration of the Arduino connecting to the cloud. This was before I implemented the error checking. This iteration (version I like to call it) didnt work as I couldn’t see what errors were being produced. Below is a diagram of this;


It was a very basic setup. The Arduino took the scanned UID and sent it to the PHP web page run by the web server in the cloud. This then took the UID and inserted it into the MySQL database. Well that was what was planned, in fact it failed somewhere along the way and I couldn’t figure it out. This is why I moved onto the next version, where I tried adding error reporting.

Version 2.0;

In this version I added the error reporting. In the previous version I got annoyed that I couldn’t see what was happening. I took a break from working on the Arduino and did some research and found a example that included error reporting. I took some of the basic code and ideas from version 1 and added the error reporting. This took some time but after some fiddling I managed to get error reporting working.
There were several errors which I fixed. I also added some features that will be needed for the project’s goal. I took what I had done and turned it into a series of diagrams. Below is an overview;

2016-09-28 (1).png

As you can see there is a bit more happening. I am not only sending the UID to the database, but also the Unit Number and the Timestamp. The Unit Number I added which will be used to identify which Arduino Unit and the room that the UID was scanned in. I am also sending the time in which the UID was scanned. At the moment the time comes from the web server but I am looking to change this in version 2.1, which I will explain later.
I did two more detailed diagrams that explain what is happening in more depth. The first is below;

2016-09-28 (2).png

This shows what is happening at the Arduino end. The user scans their student ID card using the card reader. This sends the UID to the Arduino. The Arduino takes that and its Unit Number and sends it, via the internet, to the cloud. Any errors that come back can be displayed via a serial monitor to the User on there computer.

The second diagram;

2016-09-28 (4).png

Above shows what is happening in the web server in the cloud. The information comes in from the Arduino, is processed and sent out to the database, including the timestamp. I added another page in the web server that allows the user to view the data that is stored on the database. This was solely for testing that data was getting written to the database.

Planned Versions;

Version 2.1;

As you can see that in version 2.0 that the timestamp comes from the web server. This was good for testing, but for my application it isn’t the best. This is because the timestamp is the time in which the add_UID.php was called by the Arduino. If the connection fails for a period of time before it reconnects and the page is called, the timestamp will be incorrect. As the timestamp is so heavily relied on in this system, this time needs to be when the card was scanned. Therefore I want to move it to the Arduino, so it sends it. This means if the connection fails then the time will still be accurate as to when the card was scanned.

Version 2.2;

I need to add some sort of visual interaction with the user. I am thinking of adding a RGB LED that will indicate it the Arduino system is working. For example; Green may mean the system is read for a card to be scanned, Yellow means the system is sending the UID, Blue flashes to indicate the system has succeeded in sending the UID and Red means the system has failed.

Version 2.3;

I need to remove the error reporting as it is not needed for the final version. It is useful for testing, but is just bloating the final version of the system. Some error reporting will be needed for the LED but the parts the report over the serial port aren’t needed. Plus they could be a security risk. Someone could plug into the Arduino and see what is happening, removing the serial reporting will put an end to that.

Version 3.0?;

Final implementation version. I am planning that this is the version that will be deployed. Any changes that are needed once the system has gone through testing will be made to this version.

What’s Next?

Since I have a working version of the Android I am planning on coming up with a database design that this system would use if it was going to be used at NMIT.

One thought on “Blog 6 – Pause to plan

  1. Pingback: Blog 14 – Finishing up the Arduino | Digital Insaniti

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s