2018 / 1 avril

the Born of a new protocol : AriBus

back in Mai 2017, before moving to Tangier, I had to make a queue management system from scratch, it was a very challenging project since I had never driven a full project and dealing with everything from the idea of the fabrication process, for the ones who dosn’t know yet what I’m talking about let’s give a quick definition first to put you in the line because i know that when we think of a queue, the words that spring to mind are “annoyance”, “lots of people” and “waste of time”, but let’s put it scientifically:

What is a queue? A queue is a line of people awaiting services or products.
In economic terms, it’s even simpler — a queue is a textbook case of demands exceeding supply !.. When there are more people queuing up than there are clerks ready to service them, we get queues.

The bigger the disparity, the longer the queue.
So then, what is queue management?
Queue management is a set of principles aimed at controlling customer flow and streamlining the queuing experience.

Although usually we only take into account the effects of long queues on regular visitors, everybody — from customers to manager and top-level administration — benefits from proper queue management.

after knowing this, the first tough that come into the mind is there any ready use solution for that propose ? yes it does, but since we were tight in time, the shipping time and the customs rights didn’t matched our time requirement, in addition, our client didn’t want us to use wireless stuff inside the building,,, i know that this seems pretty weird request because we are already fully covered  by wireless radiation starting from our cellular phone to the high power wifi router on our desktop office… a small unpublished wifi’s name or BLE modules would be fine in all cases, and to be honest too, i was very excited to experiment myself how far i can go with such an exceptional case

so we started with project scheduling and specifying the working method for the hardware and the software  we classified the tasks by time requirement, the task that require much time must be the early ones to start with) excluding the queue terminal , it fabrication process was subcontracted externally before even schdeling due To lake of humain/time ressource, so mainwhile we focused in the developpement of the main firmware for the screen indicator, right bellow is the full schematic of the connections between all parts of the project:

as montionned in the illustration, since the queue terminal act as main head the red screen must always sync their data with it as for example gaining the new screen number if their was any changes and send the states of all buttons that is connected natively to the screen, while the the queue terminal that acts as sync master gather the states of all connected screen that i’d call them « nodes », and update a matrix exchange table on it memory with the states of all buttons of all those nodes, this would normalize






without going deep in the theory, types of queue management


No comments so far.