Archive for the ‘Projects’ Category

Functional Eclipse Computer

August 8, 2017

I have progressed on the eclipse computer project past a prototype to something that mostly works. There a few minor bugs in the code, but it is usable as-is. I’ve got fixes for them, but need to test before committing. The system still doesn’t use its buzzer for an audible prompt, and I haven’t written anything yet to help take a sequence of pictures showing the progression of the eclipse. I may not get to that for a day or two to deal with travel related issues. I plan on taking it, and a bunch of camera gear, to the Nashville area to view the eclipse.Eclipse ComputerThe picture shows what is nearly the final hardware, but older software. This video shows the current software. The hardware changes between the two are all to help keep everything from moving around in the case, and to keep the barrel connector that supplies power to the upper breadboard close to the board. The connector was moving away from the board too easily and causing a reduction in the supplied voltage.

All of these problems were solved by applying solid copper wires in the right spots. I use solid copper with breadboards a lot because I can cut the wires to the length I need and the conductor is stiff enough to be inserted into the breadboard without tinning or the addition of some connector. I used a few more of these wires to hold down the barrel connector and to apply some pressure against the top of the case. It worked out quite well.

I changed the display from a 16×2 LCD to a 20×4 one just for the additional text. The video shows how I’ve made use of the space. The 20×4 display is a bit dark and needs a backlight to be readable unless it is in bright direct sunlight. The 16×2 display didn’t have this problem; it is more like a common digital watch display in how it handles light. I made and adjusted an automatic backlight control program that gets brightness measurements from a TSL2591 at its minimum gain setting and uses one of the Raspberry Pi’s PWM outputs. It seems to make the display readable enough in bright light and keeps it from being brighter than it needs to be most of the time. I’d rather have a 20×4 that is more like the 16×2, but I haven’t got the time.

I tested the computer running on 8 Eneloop NiMH 2000mAH batteries. For most of the test, the computer was indoors and used the minimum backlight setting. It recorded around 600mW power consumption under these conditions. In brighter light, power consumption got as high as 850mW. Working out a new times of totality can add about 400mW, but I wrote the code to limit how often that occurs.

The batteries kept the computer running so long that I couldn’t finish a battery life test in one day. The combined runtime before exhausting the battery charge was around 25 hours. That was much longer than I anticipated when I decided on 8 AAs. I’m still going to use 8 because I can, and the backlight will make the runtime a bit shorter, maybe 16 or 17 hours, about twice what I need. Also, a smaller battery pack would have more room to move about, and I already wrote low battery detection code based on 8 batteries in series.

I’ve got the Raspberry Pi Zero running Gentoo Linux. I made modifications to the configuration used by OpenRC to boot up the system so that it starts the program that provides information on the LCD and the separate backlight control program. A simple Bash script keeps re-running the software until it terminates without error, or the script is killed. No GUI is installed. I’m going to see if I can get it to set the clocks on my cameras, and bring up a network connection, when the corresponding device is plugged into USB. Nothing critical, but it would be nice. Hopefully plugging in a camera won’t cause it to reboot.


Eclipse Computer Prototype

July 30, 2017

I’m going to see the upcoming total solar eclipse on August 21, 2017 somewhere north of Nashville. I’d like to get some good photographs of the event, which makes anticipating when certain eclipse events will occur very helpful. For this purpose, I put together a custom computer system to provide me with some information about the eclipse based on my location.

The prototype eclipse computer

The prototype eclipse computer

The computer is based around a Raspberry Pi Zero running Gentoo Linux. I used a GPS receiver from Adafruit along with GPSD to query the location, and NTPD to synchronize the system’s clock with the atomic clocks of GPS. I also used a 16×2 LCD that is readable in bright light, and with the help of its backlight, is readable in the dark. To power it, I’m using Adafruit’s Verter product; it takes 3 to 12 volts in, and produces 5.2 volts to run everything. It makes for a flexible power supply that doesn’t require me to buy a special battery that I might not use much in the future. I plan to use 8 AA batteries.

The software figures out when totality, the part of the eclipse when the moon’s umbra blocks the sun from view, begins and ends using some data published by NASA. The data shows the irregular shape of the moon’s umbra projected onto the irregular shape of the Earth at one second intervals. Using this, I made the program search for which of the umbra shapes contains the location provided by GPSD. The resulting totality time information, plus the current time and location, cycle across the LCD. Its results don’t exactly match many of the interactive maps available online, but I think they may be using a simplified, maybe circular, umbra shape and may not account for the Earth’s terrain.

At present, the program doesn’t take any user input. I’m considering changing that, but I want it to be useful without input. I’m going to put it inside a sturdy case that is water resistant enough that it should survive a strong downpour, just in case I have to deal with less than ideal weather. The top of the case is transparent, so the current version of the system can be useful without opening the case.

What it doesn’t do right now is show when the very beginning and ending of the eclipse occurs. I’m having some trouble figuring out how to do this. I’d also like it to show the azimuth and elevation of the sun for the current time, the beginning and ending of the eclipse, and mid-totality. I hope to make a time-lapse video of the event, and want to keep the sun in the frame, but do not want to disturb the camera once it starts. I did make an attempt at computing the values based on an algorithm published by NOAA, but what I made doesn’t produce correct azimuth values. Unfortunately, that is the more important value of the two for this eclipse.

I have published my source code as two repositories on Github. The first is a library I wrote intended to provide a C++ happy high-level style interface to using low-level hardware. I called it DUDS, for Distributed Update of Data from Something. I’m not very good at names. The name shows what I’d like to do with the library in the future, but I’ve got to build up other functionality first. It is already useful for this eclipse computer, so I hurried a bit to publish the code.

The second repository is for the eclipse computer program. It also includes a program to test finding totality times that does not use DUDS, and takes longitude and latitude values from standard input.

I’ll be doing more development and testing for at least a couple weeks.

I2C repeated starts implemented on the Raspberry Pi

July 13, 2013

Update: If you just want a kernel module for something close to kernel version 3.10.25, look here.

I’m working on a project that uses the Raspberry Pi and various sensors. One sensor is a MLX90614 IR thermometer; this communicates using SMBus. One of my goals is to avoid making the project specific to the target hardware, the hardware that actually runs my code. I want the code that communicates with the sensors to be Linux specific but not Raspberry Pi specific.

Communication with a MLX90614

Communication with a MLX90614

One of the problems a lot of people have had with the Raspberry Pi is with getting SMBus communication to work. SMBus is built on I2C, a way of managing serial communication between many devices with only two wires: clock and data. I2C is more flexible, while SMBus is made to be more reliable. As part of guaranteeing reliability, mostly in a multi-master setup, SMBus requires the use of I2C’s repeated starts for read operations. The I2C master driver for Linux on the Raspberry Pi does not support this, and I have been unable to find a patch or custom version anywhere that adds support. Most people have solved the problem by using code that directly interfaces with the Raspberry Pi’s hardware, ignoring the Linux kernel support altogether. This solution not only fails to meet my goal of avoiding code specific to the target hardware, it also won’t work well if more than one process on the same host attempts to use the I2c master hardware.

I decided to solve the problem by modifying the Linux kernel’s support for the I2C master of the Raspberry Pi. I succeeded. My implementation may not be the best or bug free (works for me is a weak guarantee), but it does allow for communication with a MLX90614 using the user-space (unprivileged code outside the kernel) SMBus interface provided by Linux. Since examples with SMBus are more difficult to find than I2C, here is my test code. I also tested with a BMP085 sensor using the support for it already in Linux. This sensor uses I2C rather than SMBus, and it also functions correctly. It doesn’t need a repeated start, but it gets one anyway.

To avoid causing extra trouble, I implemented repeated starts for a subset of conditions under which they could be valid. I focused on SMBus communication. With I2C, a slew of messages going back and forth can be requested, all with repeated starts, but this isn’t normally done or required.  Also, the hardware requires that once the first message has begun transmission, the second message be setup in the registers ahead of the stop condition. To make matters worse, there is no interrupt condition for this, so polling in a busy wait is required. I stuck all this inside the bcm2708_i2c_master_xfer() function of i2c-bcm2708.c so it isn’t in the interrupt handler. After the second message is configured, the interrupt handler is used to receive the data. That avoids additional polling at the cost of not allowing additional repeated starts.

If you’d rather see the kernel change in source control, I stuck it on Github. It is a 3.6.11 kernel, but not the latest revision out there. I’m still using it for now. There is no kernel or kernel module for download here because I’m running Gentoo on my Raspberry Pi and I build my own kernels. If I gave you my kernel, you may well find that something doesn’t work anymore.

A stupidly simple way to connect 3.3V logic to a Sainsmart relay board

June 16, 2013

A lot of hobbyists are using Sainsmart relay boards with their projects because the boards cost less than buying the relays, or come really close. The boards include circuits to drive the relay coils so that a typical logic output can be connected directly to the board. Each driver circuit uses an optocoupler so that the driver and the coils only share a ground potential. This is a great scheme to allow the driver to work at a different voltage than the relay coils, but the board was intended for use with 5 volt supplies for both. The drivers start to work reliably from around 3.8V up to 5.5V or so. The result doesn’t work well with a 3.3V supply for the drivers operated by 3.3V logic; some relays will function, and others won’t. The solution is to give the drivers a 5V supply, but then the floating driver inputs should rise to 5V; the drivers are connected to the positive supply, and are two LEDs and a resistor in series that connect to an input pin. A common solution to using 3.3V logic with the Sainsmart board is to add another driver circuit to drive the driver circuit on the board. I thought that was annoying and sounded rather silly, so I investigated further and found a simpler method.

Test setup

Test setup with 10MΩ probe

I started by hooking up 5V supplies to the board and measuring the voltage of one of the driver inputs when left floating. This setup is in the picture; channel 1 (left) is measuring the voltage on a driver input, and channel 2 (right) is measuring the 5V supply. The first results showed a drop of about 2.2V from the driver’s supply. This occurs even when the only wire connected to the board, besides the measuring probe, is the positive power end, VCC, to the drivers. This voltage drop is made possible by the current passing through the probe; connect the probe’s reference potential to the board’s VCC instead of ground, and the voltage measured is zero.

I measured using a 1MΩ probe. With the supply voltage measured at just over 4.8V, I get 2.5V on an otherwise disconnected driver input. The current flowing through the driver is adequate for the LED to make a very dim light.  By switching the probe to 10MΩ (as pictured), the voltage measured is over 0.27V, meaning the voltage on the input is 2.7V.

This indicates that a small current is all that is needed to keep the drivers below 3.3V when using a 5V supply. Connecting a 3.3V logic output directly to one of the board’s driver circuits should work just fine without adding an additional driver circuit. In many cases, though, some 3.3V processor is used and its general purpose I/O lines are initialized as inputs after a reset. Clamping diodes are often present and can probably handle the small current through the relay board’s drivers trying to pull the line to 5V. Adding a 10MΩ resistor to ground should save the clamping diodes from any work, while connecting it to the 3.3V supply should work almost as well while eating even less power. The small current draw of the input might actually take care of the problem, but I lack any measuring equipment that can confirm this without drawing the small current that will take care of the problem.

Circuit to connect 3.3V logic to a Sainsmart relay board

Circuit to connect 3.3V logic to a Sainsmart relay board

I’ve been asked to post a circuit diagram for the solution I mention above, so here it is. I threw it together in Inkscape even though I don’t really know how to use Inkscape. The circuit will work for the Sainsmart relay boards like the one I tested when the drivers on the board are given a 4V to 5V power source.

False Steps

The Space Race as it might have been

You Control The Action!

High Frontier

the space colony simulation game

Simple Climate

Straightforwardly explaining climate change, so you can read, react and then get on with your life.