💾 Archived View for benjaminja.info › projects › feed.xml captured on 2024-05-10 at 10:37:55.

View Raw

More Information

➡️ Next capture (2024-07-09)

-=-=-=-=-=-=-

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-us">
  <title>Benjamin Jacobs | Projects</title>
    <link rel="self" type="application/atom+xml" hreflang="" href="gemini://benjaminja.com/projects/feed.xml" />
    <link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/projects/" /><id>/</id>
  <updated>2024-04-30T02:17:07Z</updated>
  <generator>Hugo 0.125.4</generator>
  <entry>
    <title><![CDATA[Gemfra]]></title>
      <link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/projects/gemfra/" />
    <id>gemini://benjaminja.com/projects/gemfra/</id>
    <updated>2023-01-06T00:00:00Z</updated>
    <summary type="gemini"><![CDATA[A gemini CGI framework for rust
]]></summary><content type="gemini"><![CDATA[=> https://github.com/ttocsneb/gemfra View Gemfra on GitHub

This crate abstracts most of the boilerplate involved in creating a CGI application. You will be able to choose which type of CGI protocol you want your software to run.

Gemfra supports two CGI protocols:



These protocols will be implemented for all applications. You can use an application made from gemfra, or implement your own application. Currently there is only one pre-built application available:



## Async Runtime

Gemfra is an asynchronous library. It uses tokio as its runtime.

## Limitations

This software has not been tested with very many servers. It is possible, if not likely that there are incompatibilities with other servers. I would like Gemfra to be as portable as possible, so please report any issues that you find.

## Roadmap

Gemfra is still in development and there are a few things that are planned to be added to the library.


]]></content>
    <published>2023-01-06T00:00:00Z</published></entry>
  <entry>
    <title><![CDATA[OctoWeather]]></title>
      <link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/projects/octoweather/" />
    <id>gemini://benjaminja.com/projects/octoweather/</id>
    <updated>2022-08-01T00:00:00Z</updated>
    <summary type="gemini"><![CDATA[A webapp for weather stations
]]></summary><content type="gemini"><![CDATA[Octoweather has been a dream of mine for over 6 years now. I have never been able to complete it due to several reasons, but mostly feature creep. It will be a web service that can show you the current weather conditions of your own Personal Weather Station (PWS) from the web.

I want it to be the OctoPrint of weather stations. The thing you use to modernize your weather-station. When you install octoweather, you need to provide a driver to act as the bridge between your pws and octoweather. This could be done in any number of ways: A Raspberry Pi with weather sensors on board, to a commercial wireless pws where you reverse-engineer the protocol between the monitor and the hardware.

Ideally, there will be a plugin system that you can use to extend the functionality of octoweather, but that is a feature that I am not ready to start implementing until the first version is released. My hope is to be able to allow advanced features such as weather prediction or integrating with a distrubuted weather service like wunderground. For now, you will only be able to view the current weather conditions as well as history.

An API will also be made available for developing native apps. It will be a ReST API along with a websocket for gathering live data.

I’m still unsure of how I’m going to render weather conditions. I want to be able to accomodate a multitude of sensors, but each sensor needs to be handled in a different way and be in a different position. One possible solution is that I could create a custom template for all the main sensors (temperature, wind, and rain) then all other sensors are placed in a list. Another option would be to have a widget for each sensor type and render them in order. The first option will look nicer, but is more limited. The second option will have more possibilities, but look more samey.
]]></content>
    <published>2022-08-01T00:00:00Z</published></entry>
  <entry>
    <title><![CDATA[Timelapse Webcam]]></title>
      <link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/projects/timelapse_cam/" />
    <id>gemini://benjaminja.com/projects/timelapse_cam/</id>
    <updated>2021-02-01T00:00:00Z</updated>
    <summary type="gemini"><![CDATA[A janky timelapse camera for a construction project
]]></summary><content type="gemini"><![CDATA[=> webcam.jpg 🖼 Film photo of the webcam

My parents have done an addition to their house and they wanted to be able to watch the progress of the house as time goes on. Instead of buying a camera that could do the same thing, I decided to develop my own solution.

It is built with a Raspberry Pi, Django, and Vue. My first thought was to use the live mjpg feed that OctoPrint uses, but I found that it is difficult to have a lowish quality stream and a high quality timelapse so I developed my own streaming system.

## Design

The streaming system puts the camera in picture mode and takes a hi-res photo at a specified interval. If there is someone watching the stream, a second low-res photo is taken and sent to the client. The client will request for a link to the latest stream photo: if there is an active stream, then the latest photo link will be returned along with the time of the next stream photo, otherwise a new stream will be started and the client will be told to wait a few seconds for it to start.

I’ve setup the webcam to get a frame once every 5 seconds. When it’s running for up to 12 hours a day, you end up getting a large amount of redundant photos. To combat this, I compile all the photos into an mp4 file at the end of each day. The only problem is that the raspberry pi cannot handle that amount of load before the next day starts, so I setup a system where one of my servers will take care of rendering the day’s timelapse.

## Problems

If this system may sound a little sketchy, that’s because it is a little sketchy and that’s ok because it works… mostly. The biggest problem that I have faced with this project is the fragility of the Pi’s sd card. Because the house has become a construction site, it is common for the power to go out once every few months. Almost every time an unexpected power outage occurred, the sd card has become corrupted. I think that this is because it takes a photo every 5 seconds, so it’s very possible that the pi was in the middle of a write when the power got cut.

It has gotten to the point that I had to figure out a way to combat this as to not lose my hair. My final solution has been to use an external usb drive for non-volatile storage and boot the pi into read-only mode. I think that this has fixed the problem of corrupt Pi’s, but I’ll have to wait and see when the next power outage occurs.

Another problem that I have faced was from solar heat. The Pi would easily get up to 80°C when in the sunlight. So our simple fix was to put a bucket on top of it. I think I could have gotten away with putting some sort of reflectors on the back, but the bucket works well enough.

## Reflection

Overall, this has been a pretty crazy project. I think that most of my design decisions have been poor ones. Particularly when some problem happens months after I have forgotten about the project. But, seeing what has come out of it has been prety amazing.

If I were to do it all again, I would probably use mjpg streamer or at the very least use a websocket.
]]></content>
    <published>2021-02-01T00:00:00Z</published></entry>
  <entry>
    <title><![CDATA[TIX Clock]]></title>
      <link rel="alternate" type="text/gemini" hreflang="" href="gemini://benjaminja.com/projects/tix_clock/" />
    <id>gemini://benjaminja.com/projects/tix_clock/</id>
    <updated>2018-11-16T00:00:00Z</updated>
    <summary type="gemini"><![CDATA[A hard to read digital clock
]]></summary><content type="gemini"><![CDATA[=> https://github.com/ttocsneb/TIXClock TIXClock on Github

=> finished.jpg 🖼 TIX Clock

I am very proud of this project. It is the fastest project I have done from start to finish. I was in the middle of a digital logic class which inspired me to design a clock using some of the principles we were learning in the class.

## Hardware

Designing the case for the clock was pretty easy, I just needed groups of 3, 9, 6, 9 leds for each digit of the time and since there is a popular layout already for a tix clock, there isn’t much that needs to be done in the way of design.

The problems came in the form of how the leds looked during testing. There would be a very bright circle in the center of each cell. To fix this, I just added a sheet of paper to act as a diffuser. The next problem was that of bleeding light from one cell to another. Here, I printed black dividers that would go around the leds.

=> frame.jpg 🖼 The frame with difuser and blockers 

## Design

=> pcbs.jpg 🖼 A stack of pcbs

The plan was to lower the outputs required of 27 leds to work with an Arduino Pro Mini. The idea is was to use a matrix to reduce 27 outputs into 12 outputs which are still too many for the microcontroller. A demultiplexer can be used to reduce the 9 columns into 4 outputs with a total of 7 outputs used to drive the 27 leds.

> When implementing this, you would idealy be running as many leds as possible at a time. With the above setup, you would be able to control up to 3 leds at a time. The problem is that I have different colors for each section and I want each color to have the same brightness. I put a unique resistor value on each column for each color which would make each led in a column share an led. When driving leds, you must have each led have their own resistor to keep brightness independant of each other. So because of this limitation, I am only able to light one led at a time.

=> schematic.jpg 🖼 The clock with a picture of the pcb

## Software

Once I got the the circuit board printed and wired; all that was left was programming the thing. I separated the software into two abstractions:

1. matrix driver
2. modes

The matrix driver handles all of the logic and timing for controlling the display. You can set the number of leds to light up, set a specific row’s leds, and randomize the locations of the lit leds within a section.

The modes abstraction is where the main logic is located for the program. There are two main modes: time and settings. The time mode displays the current time, while the settings mode allows you to change preferences stored in eeprom. You can change the time, brightness (I don’t think brightness works), or the update interval.

=> finished_wiring.jpg 🖼 The clock with the finished pcb
]]></content>
    <published>2018-11-16T00:00:00Z</published></entry>
</feed>