By Cartsa Antariksa, Nick Alexander, Omid Ettehadi, Olivia Prior
The Queue Manager is the result of an exploration of connectivity using XBee radios and microcontrollers to organize, store, and utilize inputs from a human user. The Queue Manager envisions a classroom in which every attendee has a node XBee/microcontroller apparatus (which we have called a Student Node or just Student) and the instructor has a master XBee/microcontroller (the professor). When they want to speak, a user will press a button on the student to reserve their place in the queue. The professor will press a button to advance the queue. To let the students know it is time to speak, an LED with light up in the student’s circuit.
We were excited to work with unusual functionalities of the XBee. Looking at the suggestions we decided we wanted to try to combine:
- an on-the-fly rewrite of the XBee
- logging and re-using data
- a handshake between XBees
We considered desiging a system of haptic walkie-talkies but decided that would be too close to the existing Nudgeables. We thought of modifying them to have different channels that could be scanned through with a potentiometer but discarded it. It was this line of thought that brought us to our idea for The Queue Manager.
Initially, our idea was ambitious. We envisioned a system wherein the queue would be managed, would signal with LEDs when you were up next, and give priority to those who had not yet spoken. It would automatically adjust a user’s place in line based on how often they spoke, meaning those who entered the queue less were more likely to be placed highly in it.
We imagined we’d be logging incoming data on the Professor node, use the XBee rewrite to determine where transmissions from the Professor were going, implement a handshake to confirm with each Student node, and repeat. The idea was that while the Professor node would be listening to the entire group, the group would only listen for the Professor and the Professor would only transmit to one at a time.
In practice, as we will see, this was needlessly complicated.
Step 1: Initiate handshake between professor XBee and student node
Our first initial step was for the professor XBee to acknowledge the incoming information from any of the student nodes in class. The student XBees all had the ATDL set to “C” for the professor. When the student would press their button, that XBee would send the professor their ATMY. In theory, the professor XBee would switch its ATDL to the incoming ATMY, sending a signal that would be interpreted as “This student is registered in the class queue.”
We considered pairing the professor XBee with the registered student XBees using XBee I/O, but we needed to manage LEDs on the student XBees. Since the simplest way to manage LEDs would be with Arduino, we decided to eschew using XBee I/O and stick to using an Arduino with every node.
Upon implementing the Arduino rewrite we found a multitude of issues. The first was mixed and interfering data that was flooding our professor XBee channel. We found that this was a miscommunication of the type of data that was being sent between the student nodes and the professor. The student’s were sending characters but the professor was parsing for integers in the incoming messages. Getting this data type protocol correct was challenging due to the nature of the inconsistent transmitting and receiving of the XBee’s. When we were debugging the issue, we found that it was hard to tell if it was the physical hardware setup, the settings on XBees or if it was the code processing the information between the nodes.
When we were able to get clean data being sent from the student nodes to the professor node, we attempted to implement the ATDL rewrite for the professor node. This was challenging due to delays and inconsistent rewrites on the Arduino side. Each rewrite would take over a second long, which we found was problematic for the workflow of our code. Once again, we were unsure if it was the hardware setup, the rewrite library, or the XBees devices. One solution we found that worked was to move the XBees closer together. This allowed for more consistent sending and receiving of data.
Step 2: Confirm handshake and enter student node in the queue
Once we were able to have consistently clean data sending to the professor we wrote each of the student nodes to send their ATMY to the professor upon button press. We chose to still send this data because it is a unique identifier for the XBee, even though we decided to not use the Arduino rewrite for the professor node. We took inspiration from the initial assignment Metronome, rather than the professor rewriting the protocol the professor would transmit back the ATMY it had just received. This method was more of a call and response rather than a handshake. The professor would hear “6” coming in and then broadcast “6” back immediately. When the student node would process the incoming data and that data matched their ATMY, an LED would light up.
This step we found was necessary for our next iteration of the project. In our original scope, we had anticipated having another LED light that would indicate when the student pressed the button. The second light would turn on indicating that the student was now in The Queue.
We found this worked decently but not consistently. Sometimes the student node would send the ATMY twice, causing the LED light to flicker rather than light up. As well, sometimes the student node would miss the response from the professor node. We attempted to send the ATMY three times in a row back to the student in case their XBee dropped the first call. We found this did not work and was unnecessary. As well, we tried to have a general message that would be broadcast when someone would register on the queue. This was the one area we saw the most timing delays between the XBee radios. One student would press their button, and then, in theory, all of their lights should turn on. The lights would turn on arbitrarily depending on when the node had received the message. One thing that worked was having the XBee radios close to the professor node. Because this was unrealistic for the actual purpose of the project, we decided to move onto the next step.
Step 3: Professor logs a question queue ad cycles through with a button press
The final step to accomplish our minimum viable product was for the professor to log the incoming button presses and to store a queue. The professor would then have the ability to press a button that cycles through the queue and this would change the message that the node was transmitting. The professor would then transmit the ATMY of the next person in the queue and their node would process this information and have their green LED turn on. Our goal for this step was “to only have one LED on at a time”.
We created an array that would store every time a student button was pressed. The professor would then press the button and broadcast the first ATMY in the array, this would also move all of the data in the array over one spot closer to the beginning of the array. Our main issue with this step was figuring out how to transmit the data. Back to our initial issues in the development, there were conflicting data types that were not being processed properly and sending weird characters between the radios. Once we organized the information to all be the same data type we broadcast the ATMY to the channel. The LED light of the student who was first in the queue would light up, but also flicker. We realized this was because we were sending each command as a print line statement rather than a print. This extra character was being read and disrupting the LED light to turn on.
If the student was written in the array in two or more adjacent spots, we included a “quick blink” delay for the LED light before transmitting the next ATMY. This was to give feedback to the professor and the student, otherwise, it looked like the professor was clicking the button and nothing was changing or happening amongst the student nodes.
We placed our nodes together and created a queue through button presses and the professor node was successfully able to cycle through the queue, and as well register more ATMY slots in the array as they were coming in from the class.
Step 4: Introducing back the handshakes
After finishing our minimum viable product, we wanted to experiment with different mechanism that would allow us a much smoother experience with more reliable communications. The most effective way we was to create a handshake communication between the Student and the Teacher, so that every time the Student pressed the key, it would send its ATMY as a message to the the Teacher until the Teacher would respond back with a message to confirm the addition to the queue.
Another issue we found was that when the teacher pressed the key, sending the ATMY of the user first in the queue, it would also act as if the Teacher had received a request to add a person to the queue. In order to get around that, when the Teacher sends a data to the students, it will wait to hear its own message in the channel and then it will continue functioning as normal.
In addition, every time a student request for a place in the queue, the Teacher would check if they already are the last person in the queue, if so it will ignore their request.
As noted in our process the hurdles we encountered in the development of this project included the messy data received by nodes and the master sending unreadable data. Something we attempted to use as a way of monitoring the incoming was adding a “ghost” XBee to the channel. This XBee would listen to the channel and provide us with a serial monitor of all the data that was being distributed. Our development was stalled because the device transmitting mystery data that we frequently mistook for data being sent from our own nodes. Once we isolated the issue and continued development without the extra XBee, our team noticed that there was still messy data that was being sent amongst the XBees. We isolated the issue down to sending mismatching data types. Because we were using numbers, our data types were often confused between either integers or characters. We solved this by declaring all of our transmitted and received data as characters, and placed our numbers in string quotes so there would be no confusion amongst Arduino.
The XBee communication we found was not as reliable as we had previously experienced. We found there were delays in sending and receiving data, and sometimes data would be missed entirely. The only logical solution we found, besides frequently resetting our XBee settings, was to situate the devices close together. We suspected that there may have been some soldering issues or wiring issues that inhibited the distance the XBees could have amongst each other. Once the XBees were beside each other we found the communication greatly improved. This was useful for debugging but not a long term solution if we were to expand our project to include more than four users.
Through what we achieved in this experiment, we believe there is a lot of room to expand the scope to reach our initial concept. The Queue is particularly beneficial for students or participants who still struggle with confidence to voice their thoughts or raise their hand within many classroom contexts. The setup is also quite simple given that it exists within a kit that can be used to supplement lectures in classrooms that lack this ease in feedback method.
In terms of a future expansion, each of the student and professor nodes can be placed within a 3D printed case to hold the circuits in place and can be labelled accordingly. We could have also explored the possibility of having multiple LEDs to indicate different types of feedback for the student node themselves. For example, we imagined a blue LED turning on when the student was entered into the queue, a yellow light when they were next in line, and a green when it was their turn. Perhaps a red light could turn on when a student had entered the queue too many times. We also imagined a system wherein students who had not entered the list yet would be given primacy and placed higher in the queue than those who had. There was also a potential for a screen interface for the professor to see the queue in real-time, rather than its current view through the arduino serial monitor.
Within real life applications, this manager could expand to contexts outside of the classroom, especially within restaurants or cafes. It would act as a “smart” pager that can cater to customers who request service earlier on, or able to indicate urgency in terms of which customer needs the service the most. It can also function well in locations where internet access is limited, especially in remote conferences and even countries where radio communication is more accessible.
Inspired in part by the server-pagers at Mo’Ramyun Restaurant at 1 Baldwin St, Toronto ON, M5T1L1