I have been working to improve the reliability and tolerance of wifi disruptions on the messaging experience over the last couple weeks. Previously, the device would display a message animation, and then at the completion of that message, it would phone home to get the next message. For the most part this works great, the display message server is very quick to reply, and most modern US internet infrastructure is pretty fast and reliable. But there are always hick-ups, the original firmware I developed already had the concept of message queueing, so I spent a bit of time to refactor the entire HttpClient library to allow me to build an an event driven system for server communication, now the loop can fetch new messages in the background while it is also displaying the existing messages in the queue. Currently the firmware supports a 5 stack of 256 character messages.
This release also has significant performance improvements in the led display driver, previous firmware was struggling to get the led’s refreshed fast enough to not flicker visibly and also perform smooth animations. I reworked the entire led driver concept that I developed to be many many times faster, so now the led refresh loop is running 10 times faster, and also has freed up time for the little micro processor to keep up with its other tasks, like getting messages, and tending to the wifi state for instance. I am still tweaking the exact timing over the next couple releases but on my test fleet things are looking GOLDEN!
Next Items.
- user controlled animation speed, refresh rates, and other device parameters, from the dashboard
- updates to my queueing code to pack small messages more efficiently, and handle large messages
- refactor of the basic animation code to allow for new animations to be developed more efficiently.
- complete the basic suite of animations, currently only supporting single line left2right, and dual line