LILYGO TTGO T-Wristband

This is the LilyGo TTGO T-Wristband that turned up today, catchy name.

LilyGo are known for producing a lot of 'maker friendly' development boards where they cram a lot of useful stuff together on a board in various combinations, lots of it based around the ESP8266 or ESP32.

Chances are there's a combination that might not be exactly what you want, but close enough you don't need to build something up from scratch or a tangle of different modules. Want an E-paper display, OLED display, LORA radio, Cellular connectivity, LiPo charging circuit and ESP or some random combo of 2-3 of these on one board they probably make it. It's all cheap and cheerful AliExpress/Banggood fare and I've bought a few things from them over the years.

This here is closer to an actual product, it's a 'fitness band' looking much like one of the sea of cheap BLE ones available for attaching to your phone but it's maker friendly with a programming cable and apparently usable code for all the components on GitHub.

Based around the ESP32 it's probably not the best platform for something like this as it's too power hungry, but it should be something I can program myself.

I have plans to tie it into my mesh network and directly deliver messages over ESP-Now with no need for a phone.

This is a kind of speculative purchase, I may not find the time to get the code in order for when I need it, but it was cheap as chips and if it does work it will be great.

If it does work I may buy 2-3 more.

ESP32-CAM case, selfie lens and mount - part 1

Poundland (the major UK 'dollar store') had selfie lenses for 50p so I picked up a few to play with on my stash of ESP32-CAM modules.

I've 3D printed a mount that protects the board and lines up the lens perfectly with the existing camera. The lens is an interference fit, at least on my printer, and screws in firmly.

Initial testing seems positive as it really expands the field of view. It's never going to rival a GoPro but makes the module much more versatile. You can buy a wide angle cameras for the ESP32-CAM but typically you have to buy that separately, almost doubling the cost so this was a cheaper way to get similar effect.

It also gives it a 'big lens' look rather than the pinhole camera of the usual module. Which is the aesthetic I want.

I still need to design a back to the case but this should give me a robust housing for these things. Different backs could have different options including a battery holder and switch.

The flash LED is exposed close to the lens but this would work better with a bit of acrylic rod acting as a light pipe and make it possible to make the whole thing passably waterproof with some thought.

The nasty thing with the LED is it shares a pin with the SD card interface so if you access the card it flashes. This is a problem. I have no idea who would have thought that was a good idea, it's not like there aren't any free pins. Fine if you use the camera over the network but makes the flash useless in situations you want to write to SD and if it's battery powered will chew power. Just why?

Mesh networked computer terminals with RFID logon - part 5

After a chunk of work I've got file syncing working fully. The code does a simple manifest of everything on the SD card except for the irritating "System Volume Information" directory Windows puts on there if you view the card on a Windows system.

As my mesh network isn't designed to be high bandwidth and I'm not expecting the files on there to change often, this is a slow, lightweight process. After all it's only running on an ESP8266, don't expect BitTorrent.

The steps the mesh takes to sync are broadly...

• Recursively iterate the whole file system on the SD card
• Open each file and do a CRC16 of it
• Store the full path and filename, size and CRC16 in a data structure
• Write this to a simple flat file to save this across restarts. Each file is given a sequence number starting at one that increments with each change
• Once all the files have been read, XOR all their CRC16s together and store it
• The total number of files and this XOR of the CRC16s are advertised periodically by each node flooding the whole mesh
• If a node receives a XOR that doesn't match its own it asks for the CRC16, size and sequence number of each file on the other node, one at a time
• Some simple if/then/else logic decides if it needs the other node's version of the file
• Files are transferred 64 bytes at a time in a TFTP-esque manner
• Once the XOR and number of files match the two nodes are considered synced and stop
• To detect change from an initially synced state, if a file is changed the new CRC16, size and sequence number are flooded to the whole mesh immediately
• Notification of deleted files use a similar mechanism and stay in the data structure
• There are timeouts and retries on the various steps in the process so it will fail fairly gracefully and restart

This is probably full of edge case horrors and has no way to handle file conflict resolution. I don't care, this is not an enterprise class distributed file system, it's a bunch of microcontrollers in a field that I need to have the same files on, mostly, and stay in sync, mostly.

Watch the awesome log output!

Mesh networked computer terminals with RFID logon - part 4

This is another little update, I have basic file transfers working, woohoo!

There is no authentication but some basic sanity checking of the data, ie. is the packet from the station it expects, for a file it expects and the chunk it expects next. It's pretty much like TFTP but done over my proprietary mesh network stuff.

I'm currently only shipping 64 bytes at a time, inefficiently packed too, so it's going to suck for large files but the process works and will chunk through a queue of files happily grabbing them.

Now the code needs cleaning up and to allow for things like failed transfers.

I also need to go back to the file manifest handling as it handles change, but not initial seeding. However this is a really positive step forwards.

Mesh networked computer terminals with RFID logon - part 3

The last couple of days I've been messing around with code for building a 'manifest' of the file system on the SD card then notifying changes to other stations.

This has taken a lot of time as I had a few false starts in my reinvention of this particular wheel. I think I trashed my plan and started again at least three times and it's probably still a quite naive scheme. As things stand it's just notification of change, the other station knows if there's an updated file but there's no method to transfer the file as yet.

Oddly I don't think file transfer will be hard. The way I've put my mesh library together makes it quite easy to push arbitrary data around. It will just need to be chopped up into chunks and sent. Maybe also 'lock' the file to prevent local changes while any transfer occurs, just in case.

Mesh networked computer terminals with RFID logon - part 2

Progress on the messaging application is going OK.

I'm having a little aggro with RFID. It works, but not reliably so after 3-4 uses of the card it becomes unresponsive. This may be related to the code I've cribbed from an example to continuously poll the card and check if it's been removed. This might crash the reader but I'm not 100% sure. It's also quite possible I've messed up the state machine that handles the logon process in some way related to idle logoffs.

What is going quite nicely is building a file structure on the SD card with global, per-station and per-user configuration files. This is massively old-school way of doing things but is easily human-readable without writing an admin interface.

An easy example, above, is the 'message of the day' above where the cyan text is 'global' and the 'green' per-station.

I'm now working on an interface for users to display their stored files. Once this is done I would like to make it sync across the workstations with a TFTP-esque setup where the station with the highest sequence numbered file distributes it to the others. This needs to be in place for persistent messaging across different workstations, but will make the configuration more easily maintainable. It's probably going to need metadata stored in each directory, hidden from the user and I can see myself using JSON for that.

Mesh networked computer terminals with RFID logon - part 1

I may have bitten off more than I can chew, but let's see if this works out.

While I've been developing my ESP8266 mesh network library one of the demo applications I've written for it is an IRC-esque chat client with an ncurses terminal interface. It mostly works, but needs some polishing.

This application means you can connect an ESP8266 board into any computer that will run a terminal emulator and chat with other nodes with no infrastructure at all, not even local Wi-Fi. It's completely self-contained, an actual VT100 dumb terminal would work, for that matter, with a little level-shifting of the serial port.

When I went away to Odysseus LARP, they had a forum-esque system that had in-game use, for communication between players, with the GMs and as a source of information. This was an unexpectedly good experience adding to gameplay and was the basis of the in-game hacking mechanic.

For the sci-fi LARP I'm helping run in March while chatting during a writing session we decided to see if we could offer something similar. Odysseus was indoors with a big IT back-end, large player base and huge development team. Our event is mostly outdoors, about 20 players and three GMs plus a few more people helping with props, so tiny by comparison.

Nonetheless I've got a working chat application and want to use the mesh network for other stuff in the game already. Stick some chat nodes connected to laptops in the covered areas where there's power and you're getting there.

Key things I need to add are...

• Logon credentials/tokens
• Persistence of messages across logons at different terminals
• A way to store and show files
• A 'hacking' mechanic for this that is in keeping with the game

So I've spent a bunch of time this weekend messing around with using RFID cards as logon tokens, storing structured info in JSON files on SD cards, planning and thinking things through a lot.

I think it will work, let's see.

ESP32-CAM programmer from Bitluni

I've got a bunch of ESP32-CAM camera modules and made myself a little breakout a while back as they need a separate FTDI to program. One of the Youtubers I subscribe to came up with a nicer breakout which includes an auto-reset circuit for only $10 on Tindie so I've replaced my scratchbuilt thing with one.

Strongly recommended if you're going to mess about with these boards.

First steps in paint weathering

For an upcoming LARP we are using Bopits for some concentration tests. These are childrens' toys that are a bit like 'Simon' but you hold them in your hand and twist/push/pull various bits in response to voice prompts.

In the game fiction these are supposed to be tools but it has always grated on me that they just look like toys, so I'm stripping them down and having a go at changing the look. This is stock in trade to cosplayers and replica makers but normally I don't bother much with it. I've got a few different ones to work on but so far it's going OK.

I'm going for a well worn look, might have overdone it slightly but it's already much better than gloss white. The weird rubbery lumps sticking out at either end might get replaced with more tool-like 3D printed pieces.