Please post what you're working on!

Since I have collected a number of Puck.js devices and some MDBT42s there is the current need to improvise a cycle track lap counter for some 2..8 riders on a 250 m cycle track.
The project has progressed beyond POC now, what I do is:

• let the pucks just advertise with frequency cranked up to the max and mounted to the bikes
  
• have the MDBT42 scanning (bigger battery here, so no worries) at the start/finish line
  
• whenever a puck comes in range, monitor RSSI and count a lap right after RSSI has maxed out (probably after RSSI either drops significantly or connection is lost completely). I assume the connection is lost at the far end of the track anyway (~ 100 m), otherwise I have to adjust the external antenna to a lower gain model
  
• have the MDBT42 track/queue each id + lap timestamp and advertise this as a service to be pulled and visualized by a laptop via Web Bluetooth (this is a todo).
  
  

Simple tests were very promising. I will have to check if passing at 50-60 km/h at 5-8 m distance carrying 8 Pucks all advertising will work flawlessly just to be sure...

Question here (I am not so much into the internals/Espruino architecture):
I connected a Pixl display to the MDBT42. Will additional load through interfacing/drawing or doing other calculations decrease the receive rates from received Pucks or will BTLE scanning always have priority (like interrupt handling)?