The best way to write weeknotes is as a genuine personal reflection of the week. Allow them to be personal. Allow thoughts and feelings to creep in, alongside news. Be open, be candid, be the sort of refreshing honesty that most colleagues are yearning for. That will result in excellent weeknotes. What did we release this week? What did we work on this week? What blockers did we hit? What did we maintain? What did we learn? What's on your mind?

Two noteworthy activities this week.

I had a productive day down at FACT, slaving over a serial terminal and staring out into the square at five lamposts topped with a ring of LED matrix displays.

The task for the day was to reverse engineer the protocol used to send messages to the displays, and check that the new Ethernet-to-RS485 hardware would do the trick. The hardware was the easy part—Brainboxes make good kit that just works.

Deciphering the protocol was a bit trickier.

I'd captured a dump from the old PC that used to drive the displays, so wasn't starting completely from scratch. Looking at the messages being sent out, the first thing I found was the sequence of bytes that seemed to mark the start of a message and the address—which of the five lamposts the message is for. The user guide for the PC software mentioned brightness and speed, and the start of the capture sent a bunch of small messages to each display. It wasn't clear what they were doing, but presumably some sort of initialisation that we could just replay (at least to begin with).

The display-some-text messages were also fairly easy to identify in the capture, given that the message was contained within it in ASCII and so was easy to read. However, trying to send messages myself led to a blank, unchanging display. Was the brightness not set? Were the initial config messages in an important order to bring it to life?

I tried all manner of things to no avail, and then tried sending the exact data from the capture. I probably should have tried it sooner, but all of the messages in the capture were hundreds of characters in length and I was entering them by hand... Unsurprisingly, the packet from the capture caused the display to spring to life and scroll a message round. Success! That confirmed that my packet order was okay, and that the displays were working. I just had to work out what I was doing wrong with my hand-crafted message packets.

There were three strange bytes at the end of each message: the last was always 0x03, so obviously an end-of-packet marker; but the two before that changed lots. That's a common location for a checksum, to allow the receiver to detect if the packet has been corrupted in transit.

But which algorithm is being used to calculate it? I spent some time calculating some of the likely candidates for one of the long, known-to-work messages and comparing my calculations to the checksum bytes, finally discovering that it was a fairly simple sum-of-all-the-bytes, minus one.

Using that to calculate the checksum for the display messages that I was sending resulted in my message scrolling round the display. I've now got code that can send any message across to the display of my choosing. And revisiting the config messages with my new found knowledge on the checksum let me decode those messages and work out which was setting the brightness and which the speed.

Now I can move back to working out the messages that we'll be displaying on the lamposts, and get the rest of the system built.

Being out on my bike, now that the nights are drawing in, has led to me thinking "what if My Baby's Got LED, but for bikes?!"

Obviously the big question was how many lights I'd need, and how much power that would draw. Is it just a too-crazy idea? I decided to mock something up to try it out—with tethered power and a My Baby's Got LED board—and you can see the results in the video above.

That's got a strip of 90 neopixels, which is pulling about 1.2A in the worst case scenario. Checking the beefy li-ion batteries available it should be possible to run for a few hours even at that power draw, so it's feasible...

Next step is to get some sample PCBs designed and fabbed to try it out properly. Obviously I can use the My Baby's Got LED board as a starting point, and then remove the extra components that aren't needed and add on a battery connection and a boost circuit to raise the 3.7V from the battery to the 5V that the LEDs need.

I've got the schematic almost finished. Next will be laying out the physical board and sending it off to be produced.