Establishing connections between the host module and the player modules takes a long time, however the connection once established is fairly fast.

We had issues the seven-segment displays on the player modules flickering.  This was especially prominent when the module was moving, but was not very noticeable when the device was still.  We also had problems with the buzzer button on the player module being very sensitive.  Sometimes the buzzer light turned on even when a person just brought their hand near to the button.

On the host side, delay in the touchscreen’s operation is minimal, but there is some noticeable delay after one of the Send, Reset, or Clear buttons are pressed.  This is because several commands are transmitted after each one of these button pressed.  The delays are not as long as during the system startup, but they are noticeable.

These delays exist because it takes some time for UART data to be processed by the Bluetooth chip.  We hardcoded delay values, but we would probably be able to change these to dynamic values based on when the UART buffers were prepared for more data.

A significant problem was encountered concerning reading UART data from the host side.  The correct data was confirmed to be showing up on the RX pin into the PIC, but the onboard UART module failed us.  We spent significant time attempting to get this functionality working.  By jury-rigging an error check accounting for overrun errors to also poll a value from a specific location in PT_term_buffer, we were able to get it about 70% working 30% of the time.

After a some research we came to the conclusion that the combination of Protothreads and the PIC itself makes reading the particular piece of data we care about out of the notification messages from our central Bluetooth (Low Energy) chip is exceptionally difficult.  An overrun error is when the UART receives new data before the old data is completely read.  When the error occurs, it throws a flag that locks up the receiver and prevents any further data from being read in.  Receiving large amounts of data at any baud rate very quickly will throw an overrun error and this was thrown when receiving data from the BLE chip and also when receiving multi-character data from the PC terminal.  We tried several ways to fix this like manually clearing the error flag and trying to salvage what was in the buffer when it was thrown.  Another way was to write our own UART read function to make sure we weren’t jumping to random places in the middle of our read to hopefully avoid the overrun error, but we had still had similar problems with freezing up mid-receive.  Ultimately, time became a factor and we abandoned the attempt.

As such, we ended up implementing a Plan B. This Plan B was to have the person acting as the host pick which player buzzed in first by eye (based on when the buzzers light up) and select that player on the LCD touch screen, which will turn off the other players’ lights and set the target module address in the software.

In terms of usability, the design is fairly straight forward, but would be relatively difficult to use without documentation.  More detailed instructions would certainly make using the system easier for others.