PrezenzQ is a sensor or button-triggered experience to queue and play videos on a PC via bluetooth connection.
This project is intended to be used with Windows only.
The final state of this research is to have developed 5 controllers that are each connected to an LED strip, a time of flight sensor, and a manual button. The controllers use the time of flight sensor or the manual button to trigger communication with the listening PC via bluetooth. The video queue software running on the PC is connected to all 5 devices at once via bluetooth as serial 'COM' ports. Once the PC receives an 'on' or 'off' communication from a controller, it will queue or dequeue a video to be played. After, the state of the video queued is evaluated (not playing, waiting to play, or playing) and that state value is sent back to the controller. Upon receiving this state value the controller updates the LED strip that is connected to the controller accordingly.
This project was broken down into two sections:
We developed a single controller and replicated it 5 times so that 5 different videos could be controlled/queued.
For any information in this section going forward, assume this information is only for a single controller, so multiply by however many you need.
- Power
- 24V, 2A max
- Communication
- Serial Bluetooth via HC05 module
- Sensing
- Teyleten Robot VL53L1X time of flight sensor
- 24V LED strip single channel control
- ELEGOO Nano Board (Arduino Nano)
- HiLetgo HC-05 Wireless Bluetooth RF Transceiver
- Teyleten Robot VL53L1X Sensor
- eBoot Mini MP1584EN DC-DC Buck Converter
- Horizontal Slide Switch
- FQU20N06L N-Channel Mosfet (x2)
- 5 Pin LED Extension and Connector (x2)
- 22mm Momentary Push Button w/ 24V LED
- 4 Pin Female Header
- 24V .8A (.2A per channel) RGBW LED Strip (*We retrofited L-X520436L LED strips purchased from NexmoSphere for this purpose)
- PCB Prototype Board (4x6 cm)
- 2-Channel Screw Terminal
- Resistors
- 10k Ω (x3)
- 1k Ω (x2)
- 576 Ω (x2)
- 2k Ω
- Wire
The schematics were created with KiCad and can be found in the controller directory of the repo. The schematics are incomplete in that they were designed solely for documentation of the controller creation process. Given the controllers were prototyped/assembled/soldered by hand, the schematics may not be using the appropriate symbols for some of the devices, or may not have any PCB footprint attributed to it (This is something that will be added in the future so that the boards can be printed and shipped).
All of the devices were soldered and assembled by hand.
The devices have 2 states: NORMAL and DEBUG.
- In the NORMAL state, the device operates as it should, detecting sensor or button press, sending a command to the PC, receiving a command from the PC and chaning the LED lighting state, etc.
- In the DEBUG state, with the Nano on the controller plugged to a PC via usb cable, via serial communication the device's HC05 module can be calibrated using AT commands.
-
Because there are five 24V controllers that need powered at once, a special power cord was developed for this that ends in 5 barrel jacks. These 5 barrel jacks connect to the barrel jacks on the power cables that connect to the controller via screw terminals. As for screw terminal polarity, when looking at the device with the screw terminal facing you, the left terminal is positive.
-
the 24V for the LED isn't techinally 'necessary' and another voltage LED strip could be used. We only went with 24V because that was the rating for the Nexmosphere LED strips we had at the time.
-
We only went with screw terminals because we had them on hand. It would be best to have a non-
The video queueing application was written in C++ using the OpenFrameworks framework so that videos could be loaded, queued and played.
Initially, we wanted to be able to queue and play videos through IntuiFace but that wasn't as responsive as we wanted and we ran into some issues early on that changed our development direction. Our plan was to use Raspberry PI's for the video playing device to keep it small, but even the new Raspberry PI 4's weren't able to keep up when we tried, so we decided to develop this little app ourself to see if it could handle being played on the PI and to also try and eliminate any 'unknowns' that might arise from interfacing with code/applications that we cant control.