Firstly the seemingly random restarts are solved, and will be pushed to github later. A shared function and a shared list between the threads were to blame. Had 12 hours uptime without wavering. I'll make it a new point release. Pybytes also starts on boot so in that respect it is pymesh compatible. However, the code isn't fully pymesh compatible, yet.  Secondly, gluing the devices together has been an utter pain. With standard epoxy and super glue both failing frequently to adhere to the abs casing. To counter this I've bought some JB Weld plastic weld two part liquid epoxy and two part putty. Both list as being effective on abs and ideal for attaching metal to plastic. We'll see! The hitch in development is now my arm, or more specifically my elbow. As a result of an unscheduled meeting with a van whilst I was cycling home from the day job, my elbow is in a few more bits than it's supposed to be. One handed gluing with two part, one handed soldering, one handed wo

I can tell the day job has started again, development work has been somewhat on hold. However, it was race day on Saturday! Which meant registration duties for me. And the system has had it's first real life test! Wild Running very kindly volunteered their Race With No Name ultra to use it. It was a small race due to covid restrictions, so very easily manually timed if the system failed. The race was brilliant, and the system worked. However, it has generated a job list- The PCB header pins used to connect the RTC to the Pycom Pyscan are too long, meaning the chance of a short with either the RTC of the prototype board holding the LED and buzzer is too great. Temporarily solved with some hastily attached plastic, but a better solution is required. Did get the odd, weird restart in first 30 mins of operation. This is manageable for a race this small - but not acceptable. Digging into this further. The IP rated aerial connectors come loose. Going to use the standard ones instead and