05/28/2016 at 01:22 •
I've implemented a basic virtual serial interface that runs over the USB port. The current implementation just prints all the temperature values in a grid format whenever there is a new reading available. Each reading is separated by a row of dashes. The temperature values are rounded down to the nearest degree. The sensor does report temperature with 0.25 degree resolution, but I am currently doing everything using integers only.
It would be pretty straightforward to write a small program to capture and display this data if, for example, you wanted to log something over a period of time. I'm planning to write a python script which demonstrates this eventually.
Here's a screenshot of the output when pointing the device at the same two resistors used in the last post. The two dead pixels are visible in the second row, last two columns, with the values of (0 32).
05/27/2016 at 21:31 •
I've gotten the GridEYE sensor working on my prototype board. I've implemented a simple linear mapping of -25 - 100 degrees = 100% blue to 100% red. It seems like a linear mapping doesn't produce entirely intuitive results, and doesn't photograph well, either. My intention is to tweak the display mapping quite a bit. I would ultimately like to implement the standard "iron" color scheme that is common on commercial thermal imagers, and have several different color scheme options to select from.
Unfortunately, the sensor I have seems to have two dead pixels. This means that the maximum temperature reported is always at least 34 degrees. I may eventually implement a software feature to disable dead pixels and take the average of the pixels around them in order to fill in the resulting blank space.
Here's what it looks like when looking at two resistors dissipating about 5W, as well as some ice cubes.
05/25/2016 at 06:18 •
I've been working on getting the LCD display working. This display uses an ILI9341 controller which has built-in RAM. The display is interfaced with the microcontroller using the SPI bus running at 24 MHz. I am using the uGUI library for this project, and I currently have one of the example projects up and running. Since the microcontroller doesn't have anywhere near enough RAM for an internal frame buffer, the image is drawn to the display directly, one element at a time. I've implemented the uGUI hardware acceleration functions, and made a few improvements, so that straight lines, rectangles, images, and text are sent in sections, rather than pixel-by-pixel. It currently takes between 0.1-0.2 seconds to draw a full image. This does depend significantly on the complexity of the interface being drawn. (Filling rectangles is faster than drawing text, for example.) In addition, I am currently operating the SPI bus in blocking mode, so the CPU is locked up while the rendered region is being sent to the display. There is potential for significant speed improvements if DMA were implemented so that the next region could be rendered while the current region is being pushed to the display over SPI. It's on my to-do list.
Next up, I'm going to try to get the GridEYE sensor working.
05/16/2016 at 05:51 •
I added the GridEYE sensor footprint to another board I'm putting together for a customer. I just got the boards and the parts should arrive this week. This board uses the same CPU and LCD that I plan on using for this project. This will give me the opportunity to test the following things before making the final version of the boards:
- Touch Controller
- SD Card
- GridEYE Sensor
I have also been doing some initial software prototyping using a dev board; I hope to have an update on that in the next couple of days.