Some time over the holiday let me make quite a bit of progress with the tCam-mini firmware and desktop application software. A little more testing and I'm ready to post the v1.0 tCam-mini firmware to github, along with the rev 1 hardware design. Along with some cleanup the main change was to add the ability for the streaming enable command to include a mSec period between images and a maximum number of images. This change was made to facilitate the upcoming graph function in the desktop application.
The desktop application got a lot of work. Aside from slight UI modifications and various bug fixes the main changes include
- Support for radiometric data file vides and a new video file format (.tmjsn extension) that allows real-time playback of series of radiometric images.
- Up to four radiometric markers allowing sampling the temperature in more places than just the spot meter alone. These will also be used for the graphing function.
- A more accurate frames-per-second readout for streaming and video playback.
- Application and file icons
- Filetype registration with the OS so double-clicking an image or video file opens the application and displays the file.
- Drag and drop support. Dragging an image or video file onto the application automatically opens it.

I hope to be able to add a graphing function over the next couple of weeks that will complete the version 1.0 release of this application so that the temperature of multiple points can be plotted over time.
I also did a lot of analysis of the firmware running on tCam-mini to try to understand why streaming performance varied so much. I moved the Lepton readout task to be the only task running on the the APP (CPU 1) processor. I also had to increase its priority but it is capable of keeping up with the Lepton's ~9 fps output rate with no problem. The command processing and response tasks running alongside the WiFi stack on the PRO (CPU 0 processor do not require a lot of processing time. The largest chunk of time is spent converting the binary radiometric and telemetry data to Base64 for inclusion the the json packet sent over the interface but that's only a few tens of milliseconds.
The biggest variability comes from the system as it tries to send the data over the WiFi interface. I see times from about 100-400 mSec per image (~55k). This lead me to wonder about the antenna on the ESP32 module. Sure enough things like position of the device in space and my finger touching the module made huge differences.
The ESP32 hardware design guide has this to say about PCB layout.

I had knowingly violated that spec with my layout to keep the board size down. However chopping off the two little PCB wings designed to help mount the board had no effect - unlike my finger as can be seen in the almost double frame rate shown below.

I am still at a loss but think that I will use an external antenna in the future connected via a U.FL connector on the ESP32 module.
Up next is to try to finish version 1.0 of the desktop app, more testing and then upload everything to github in case anyone also wants to build a tCam-mini. I will also have a couple of extra assembled PCBs that I'll either sell directly or on tindie.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.