The completed project was able to meet the requirements set by the project managers. The device gathered weather information and the word-of-the day through Wi-Fi, and parsed through that information to display data of interest to the user by receipt paper. The LCD would give the user feedback as to whether a connection to the Wi-Fi was successful or not, and if the printer still contained paper and was ready to print. One difficulty the device has is in a situation of very low Wi-Fi signal strength. Though the situation was rare, if it were to lose connection to the Wi-Fi in the middle of receiving data or in between API requests, the device would freeze up.
One limitation to the functionality of the design is in handling large amounts of information, as some API services are capable of sending thousands of characters of data through to the microcontroller. Because such a large amount of data cannot be stored in most microcontrollers without external storage, I had to use parsing techniques in between single character transmissions rather than saving all of the data at once before parsing. The former method of parsing can be more tedious and error-prone than the latter, but it was still able to reliably do the job for my needs.
The work I have done for this design stands as a good basis for working with information transfer with Wi-Fi and being able to use information gathered from an online source to interface with a wireless device.
There are several ways this design could be improved, but the main ways would be to perform better in low signal strength areas, and being more efficient when parsing through very large amounts in incoming data.
The Wi-Fi module used in this project was a version with an on-PCB antenna, which performs poorly in low Wi-Fi signal areas. An easy way to improve this would be to use a module version with the option for an external antenna. Another improvement to the software would be better handling of lost signals mid-transmission. In its current state this would cause the program to freeze, but with some more advanced handling techniques, that could be avoided.
The other recommendation I would make is that if it were necessary to parse through very large amounts of data, it would be an option to do the data requisition by another server, parsing it there with more reliable techniques, and then sending only the data of interest to the Wi-Fi module. Though it would be more expensive and require more knowledge of HTTP, doing the heavy parsing server-side would free up processing for the microcontroller to do other things, and would make maintenance on the project much easier. If for example an API service shut down, I could find a new one and make the necessary changes server-side without having to reprogram the device. If one of the API services I used in this design were to close down, the device would be rendered useless, and would require updating and reprogramming.
References
Int: , (Introducing JSON),
Nic15: , (Kobie, 2015),
Dav07: , (Roos, 2007),
HTT: , (HTTP Tutorial),
Kas16: , (Kashino Technology Limited),
Glossary of Abbreviations
API: Application Program Interface
HTTP: Hypertext Terminal Protocol
IoT: Internet of Things
CSV: Comma Separated Values
ESC/POS: Epson Standard Code/ Point of Sale
RAM: Random Access Memory
USART: Universal Synchronous Asynchronous Receiver Transmitter
Appendices
Figure 6 - Block Diagram
|
