You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
113 lines
7.2 KiB
113 lines
7.2 KiB
\section{Portable device requirements}
|
|
The duties of the device are:
|
|
\begin{itemize}
|
|
\item show information on the display
|
|
\item receive commands from user interface
|
|
\item maintain real time and date
|
|
\item obtain tag information from RFID reader module
|
|
\item store tag information along with time and date in a memory
|
|
\item process communication with PC
|
|
\end{itemize}
|
|
|
|
\subsection{Displayed information}
|
|
The information being shown to the user:
|
|
\begin{itemize}
|
|
\item user menu
|
|
\item actual time/date
|
|
\item actual set meeting
|
|
\item status information
|
|
\end{itemize}
|
|
|
|
\subsection{User menu entries}
|
|
\begin{itemize}
|
|
\item set time/date
|
|
\item create new meeting file with generic name
|
|
\item delete meeting file
|
|
\item set current meeting file to save into
|
|
\end{itemize}
|
|
|
|
\subsection{PC communication data set}
|
|
The device should be able to recognize and execute following commands on meeting files given from PC:
|
|
\begin{itemize}
|
|
\item show all
|
|
\item delete
|
|
\item create
|
|
\item rename
|
|
\item download
|
|
\end{itemize}
|
|
|
|
\newpage
|
|
\section{Hardware dependencies}
|
|
Things that needs to be considered about components/modules, when designing this kind of device are:
|
|
\begin{itemize}
|
|
\item power consumption
|
|
\item cost
|
|
\item availability
|
|
\end{itemize}
|
|
|
|
%The most crucial thing to consider, when designing this device is probably the power consumption, since it is powered from batteries. Another really important thing is, of course, the cost of components, because cost always drives the design in some ways. The third thing that is ultimately connected with the cost is availability. You have to consider this two factors when designing a product, in case it will get on the market eventually. Yes, we could just splat some pieces together and make it work, but then you will have to redesign the whole thing later to be able to compete on the market. To avoid this, it is easier to design the product with considerations about cost and availability of parts upfront.
|
|
|
|
\subsection{Viable microcontroller}
|
|
Microcontroller has to synchronize all the device duties, discussed earlier. These task are simple enough to be built around 8-bit microcontroller, which reduces cost and power consumption. Most viable options are:
|
|
\begin{itemize}
|
|
\item AVR ATmega168/ATmega328 has tons of available source codes
|
|
\item AVR ATmega32u2 has built in USB controller
|
|
\end{itemize}
|
|
|
|
\subsection{Display and user interface}
|
|
Display has to have low power consumption. Apart from that, it should have at least two lines to be able to show enough information.
|
|
|
|
Touchscreen is option that combines a display and an user interface. If push-buttons are used as a human interface, the display is needed. Viable display types are LCD, oLED and e-ink.
|
|
%\begin{itemize}
|
|
% \item LCD
|
|
% \item oLED
|
|
% \item e-Ink
|
|
%\end{itemize}
|
|
|
|
|
|
%The choices are PCD8544 compatible (LCD, Nokia3310), Hitachi HD44780 compatible (LCD, 16x2), e-ink (lowest power consumption but expensive), TFT (expensive, a lot of additional circuitry and software needed but no need for user interface), OLED (not that cheap but less power consumption that LCD).
|
|
|
|
\subsection{Keeping track of time and date}
|
|
Real-time can be tracked by either a MCU or using external RTC module.
|
|
RTC module has own battery supply, the algorithms for time and date built in and also provides some additional nvRAM for storing data that should not get lost, but microcontroller usually has some EEPROM memory for this purpose, which will be much faster.
|
|
|
|
\subsection{RFID reader module}
|
|
Reader has to be able to decode Mifare tag information. The most obvious reason is to use MFRC522 Contactless reader IC controller from NXP Semiconductor, because it does all the hard job. It is quite expensive alone, but you can get it from the China already soldered it as a module with driving electronics, and what is more important, an inductor working as an antenna, for the price for the IC alone! Choosing this module solves a lot of problems.
|
|
|
|
\subsection{Memory for storing lists}
|
|
Lists of information should be stored in some form of electronically programmable non-volatile memory, in basic structured format. Common types are:
|
|
\begin{itemize}
|
|
\item Flash (internal or as a microSD card)
|
|
\item EEPROM
|
|
\end{itemize}
|
|
MicroSD card needs its own special compartment, where it is inserted and makes electrical contact. User should be able to replace the microSD card within the device.
|
|
|
|
|
|
\subsection{Communication with PC}
|
|
Communication between the device and the PC has to be fast enough to provide quick way of downloading the lists stored in device memory. This can be accomplished with the use of USB. Using Bluetooth can be another or additional option for this purpose.
|
|
|
|
\subsection{A power source}
|
|
When considering a power source, a lot of options comes to play. First choice:
|
|
\begin{itemize}
|
|
\item replaceable power source
|
|
\item non-replaceable power source
|
|
\end{itemize}
|
|
Replaceable source could be standard rechargeable or non-rechargeable cell batteries of two 1.5V batteries or one 9V battery. Device will need stand-alone battery compartment for battery maintenance.
|
|
|
|
For non-replaceable power source, combination of these could be implemented:
|
|
\begin{itemize}
|
|
\item solar panel
|
|
\item Li-Po rechargeable battery
|
|
\item supercapacitor
|
|
\item wireless charging through RFID antenna
|
|
\end{itemize}
|
|
|
|
|
|
%Since the device is battery powered, obviously, the battery is needed. Basically, there are two types of batteries: non-replaceable and replaceable. The first option is an easy way - cheap a no additional devices needed. The problem is that batteries needs to be changed and also, the device needs a slot on the box for battery compartment. The second options is to use some rechargeable battery, that will be inside. For small electronics Li-ion or Li-Po battery is probably the best option. This fits greatly, because the device is already going to have an USB connector for data manipulation, so it can be used for charging, too. The disadvantage is added cost and space occupation by charging circuitry devices.
|
|
%
|
|
%There are also some other, rather impractical options. We could use a supercapacitor as a power source. Requires no additional charging circuitry, but the price is still relatively high. I may do some more research on this. Another option is to integrate some mini solar panel, but this again increases the cost greatly and makes practical advantage only on sunlight. Probably the most interesting option is to use the inductor, which is used for RF communication also for battery charging. This cool idea has quite a lot of problems, thou. The module I decided to use does not support this, so it will need custom made (expensive) RF module and it will need some kind of docking charging station. This will however made whole USB capabilities of the device obsolete, so it is maybe not that bad idea.
|
|
%
|
|
%Whichever option will be used is subject for further investigation.
|
|
|
|
\subsection{Firmware dependencies}
|
|
For the firmware there are again two options: program it from scratch and use some platform. The first option is viable mainly to applications which have limitations such as RAM or Flash memory space, or where timing is crucial. Since these are not the case here, because we are limited mainly with the amount of power stored in battery, a framework/platform can be used to greatly aid in firmware development. |