Project

# Title Team Members TA Documents Sponsor
3 CCD image sensor board for film camera retrofit
Ayush Garg
Ethan Greenwald
Jason Guo
Haocheng Bill Yang proposal1.pdf
# CCD Resurrection - modernizing film cameras to digital with salvaged image sensors

Link to idea:
[https://courses.grainger.illinois.edu/ece445/pace/view-topic.asp?id=76215 ](https://courses.grainger.illinois.edu/ece445/pace/view-topic.asp?id=76215)

Team members:
- Jason Guo (jkguo2)
- Ayush Garg (ayushg6)
- Ethan Greenwald (ethanmg4)

# Problem:
Multiple current factors create the need for a cost-effective solution to converting film cameras to digital using CCD sensors.
The sudden explosion of demand for old CCD-sensor-equipped cameras amidst the digicam trend is mismatched against a supply of 10-20 year old cameras that are increasingly unreliable and outdated. High failure rates of the cameras themselves and their old, scarce accessories (proprietary batteries and storage cards) are decimating the supply of working examples and creating a glut of broken cameras which present opportunities for salvage. Thus, a remanufacturing of old sensors (which are rarely the point of failure) to modernized cameras presents a solution to this demand.

# Solution
Our proposal is to create a PCB that accepts commonly available salvaged CCD sensors and drops them into an advanced film camera. This would satisfy the rising demand for CCD-equipped cameras. Combining salvaged CCD sensors with modern microcontrollers and components keeps BOM cost low and reliability high, and the plentiful supply of advanced film cameras will ensure that this conversion is practical. The rising price of film intensifies this glut of technologically advanced, usable film cameras that are cheap to purchase in working condition but too expensive to operate (akin to an inkjet printer).

In practice, our PCB and resulting conversion will emulate the Kodak DCS460 from 1995, but modernized to 2025 and created for different reasons. The PCB will contain the Sony ICX-453 CCD sensor, accompanying power supply, driving, and A->D conversion circuitry, an STM microcontroller with SDRAM buffer, an SD card slot, Li-Ion BMS for replaceable 2S 18650 cylinder cells, and buttons and 7-segment displays for user interface. The PCB will be installed into a 3D printed enclosure that holds the batteries and interfaces with the Nikon N90s camera (“Host Camera”), and the enclosed PCB (“Module”) will synchronize with the Host Camera through its Nikon 10-pin serial interface.

# Subsystem 1: CCD sensor, driving circuitry, and A->D
Subsystem 1 includes the one each of: Sony ICX-453 CCD sensor as salvaged from old cameras, CXD1267 CCD vertical clock driver, EL7457 horizontal clock driver, AD811 low-noise op-amp, and AD9826 16-bit A->D converter. This subsystem will largely borrow its schematic from the open-source CAM86 astrophotography camera project, since driving the CCD sensor is the single most error-prone part of our project and a critical success criteria with no substitute.

# Subsystem 2: Power supply system
The ICX453 CCD sensor requires +15V, -8V, and 6V and may draw moderate current at times due to its large capacitances. Additionally, the supporting circuitry in Subsystem 1, Subsystem 3 (Microcontroller, SDcard, and UI), and Subsystem 4 (BMS) will require 5v and 3.3v rails to support their components. This totals to 5 discrete voltages used in our project, powered by 2s Lithium Ion battery cells (a source that varies between 6.0-8.4V)

The power supply architecture for our project primarily targets low noise and secondarily targets a small footprint and good power efficiency. Low noise is necessary since Subsystem 1 is partially analog and generates digital picture data, so best picture quality requires careful power rail noise suppression. Footprint and power efficiency considerations are driven by the desire to minimize Size, Weight, and Power (SWAP) on a hand-held, battery-powered device.

Correspondingly, we are considering an architecture that uses DC->DC conversion followed by low-noise LDO regulators for all rails used by Subsystem 1 (+15V, -8V, 6V, and independent 5V), and DC->DC conversion only for the remaining 5V and 3.3V rails to maximize power savings. Where possible, we will use compact, efficient, and highly integrated DC->DC converters such as TI ‘Micro-SIP’. We may also add MOSFETs to selectively gate power to these rails and maximize power efficiency, thus enabling MCU-controlled power-saving functionality.

# Subsystem 3: MCU, camera I/O, SDcard, User Interface
Subsystem 3 will consist of an STM32H7 MCU, SDRAM buffer, MCU programmer circuit, SDcard slot, user-accessible buttons, and 7-segment or dot-matrix display. The MCU will be responsible for the following:

- Controlling Subsystem 1 and receiving its image data
- Synchronizing with the Host Camera through the camera’s Nikon 10-pin interface (including a triggering signal and a serial interface for querying the camera’s state and configuration)
- Buffering images to SDRAM to enable rapid shooting
- Processing and saving images to the SDcard over SDIO, maximizing readout speed to flush the buffer as quickly and possible
- Accepting user inputs via button press and reacting accordingly, including configuration changes and a delete button that erases the most recently saved file. This will include the user-accessible power button, so that a power-off does not cause data loss.
- Driving the 7-segment or dot matrix display to display the module’s state to the user

Since these tasks require high-speed I/O and significant processing power, the MCU must have a native SDIO capability and a JPEG engine to enable real-time JPEG compression while minimizing cost. For these reasons, the STM32H7 family was selected. While the JPEG compression and preceding Bayer conversion are not part of the success criteria, we will target this functionality since it would significantly enhance the camera’s practical usability.

As Subsystem 1 is largely based on the CAM86 project, some of the code from CAM86 may also be referenced or borrowed to form the interface between Subsystem 3 and Subsystem 1. Any borrowed code will require substantial revision due to the integration of substantially more functionality and since this project uses an STM MCU as opposed to CAM86’s AVR MCU.

# Subsystem 4: Battery Management System
Subsystem 4 will consist of an integrated BMS system and a USB-C charging port for the 2S 18650 Li-Ion power source, as well as a power kill switch for use during debug and assembly. This subsystem will integrate primarily with Subsystem 2 (Power regulation), but will also integrate with Subsystem 3 (MCU) to enable a user-visible battery level readout and to ensure that data is not lost during an over-discharge scenario.

The BMS will provide battery level readout, short circuit and overcurrent protection, as well as overcharge and overdischarge protections to the sensitive and dangerous Li-Ion battery cells. The BMS system should be able to charge the battery cells from a USB-C port that is exclusively used for charging. We may incorporate USB-C fast-charging capability, but it will not be part of this project’s success criteria.

# Criterion for Success
In short, the completed project should resemble the Kodak DCS460 from 1995.

Technical specification:
- The completed module will connect to the Nikon N90s camera, and it will save 6 Megapixel color images in uncompressed RAW format.
- The UI will consist of, at minimum, 3 buttons (Delete, Navigate, Select) and a 7-segment or dot-matrix display.
- The module will accept SDHC/SDXC cards.
- The N90s camera and module should be able to shoot at a rate of 1 picture per second, with no loss of data.
- The module will be powered by 2s 18650 Li-Ion batteries.

Form Factor:
The PCB containing the ICX-453 CCD sensor, all accompanying circuitry, and MCU/BMS/SD card will be integrated into a 3D printed module that contains batteries (2S 18650s) and bolts onto (and may protrude from) the back of the host camera, replacing the film door. In form, this will resemble the [DCS410/420/460](https://upload.wikimedia.org/wikipedia/commons/9/9e/Digitalback_dcs420_02.jpg) but should be much smaller.

Usage:
- After installing the module onto the camera and connecting the Nikon 10-pin interface cable, the N90s film SLR camera will behave like a digital SLR camera: each time the user presses the camera’s shutter button, the camera’s shutter will fire and the module will save the resulting color image onto the SDcard in RAW format.
- The RAW images that are saved onto the SDcard can then be imported into a computer and viewed or converted to JPEG as desired.
- The user can configure the module and delete previous images using buttons, and the module status and battery charge will be visible on the 7-segment or dot matrix UI, but there will NOT be an LCD for image review.

# Resources/Citations
Some schematic and code may be used from CAM86 project.
Since english language resources are sparse and distributed, all of the following links are describing the same project (or same family of projects).
- https://www.cloudynights.com/topic/497530-diy-astro-ccd-16-bit-color-6mpx-camera/
- https://www.astroclub.kiev.ua/forum/index.php?topic=28929.0
- https://github.com/smr547/cam86
- https://github.com/axsdenied/cam86_fw
- https://github.com/vakulenko/CAM8_software/tree/master
- http://astroccd.org/2016/10/cam86/

Additionally, resources for interfacing with the Nikon 10-pin interface:
- https://github.com/schoerg/nikonserial/tree/master

While the Sitina camera exists, we consider it to be more of a parallel development than a useful resource due to differences in sensor and architecture. In any case, we would like to declare it here in case there is a coincidential commonality.
- https://gitlab.com/zephray/sitina1

BusPlan

Aashish Kapur, Connor Lake, Scott Liu

BusPlan

Featured Project

# People

Scott Liu - sliu125

Connor Lake - crlake2

Aashish Kapur - askapur2

# Problem

Buses are scheduled inefficiently. Traditionally buses are scheduled in 10-30 minute intervals with no regard the the actual load of people at any given stop at a given time. This results in some buses being packed, and others empty.

# Solution Overview

Introducing the _BusPlan_: A network of smart detectors that actively survey the amount of people waiting at a bus stop to determine the ideal amount of buses at any given time and location.

To technically achieve this, the device will use a wifi chip to listen for probe requests from nearby wifi-devices (we assume to be closely correlated with the number of people). It will use a radio chip to mesh network with other nearby devices at other bus stops. For power the device will use a solar cell and Li-Ion battery.

With the existing mesh network, we also are considering hosting wifi at each deployed location. This might include media, advertisements, localized wifi (restricted to bus stops), weather forecasts, and much more.

# Solution Components

## Wifi Chip

- esp8266 to wake periodically and listen for wifi probe requests.

## Radio chip

- NRF24L01 chip to connect to nearby devices and send/receive data.

## Microcontroller

- Microcontroller (Atmel atmega328) to control the RF chip and the wifi chip. It also manages the caching and sending of data. After further research we may not need this microcontroller. We will attempt to use just the ens86606 chip and if we cannot successfully use the SPI interface, we will use the atmega as a middleman.

## Power Subsystem

- Solar panel that will convert solar power to electrical power

- Power regulator chip in charge of taking the power from the solar panel and charging a small battery with it

- Small Li-Ion battery to act as a buffer for shady moments and rainy days

## Software and Server

- Backend api to receive and store data in mongodb or mysql database

- Data visualization frontend

- Machine learning predictions (using LSTM model)

# Criteria for Success

- Successfully collect an accurate measurement of number of people at bus stops

- Use data to determine optimized bus deployment schedules.

- Use data to provide useful visualizations.

# Ethics and Safety

It is important to take into consideration the privacy aspect of users when collecting unique device tokens. We will make sure to follow the existing ethics guidelines established by IEEE and ACM.

There are several potential issues that might arise under very specific conditions: High temperature and harsh environment factors may make the Li-Ion batteries explode. Rainy or moist environments may lead to short-circuiting of the device.

We plan to address all these issues upon our project proposal.

# Competitors

https://www.accuware.com/products/locate-wifi-devices/

Accuware currently has a device that helps locate wifi devices. However our devices will be tailored for bus stops and the data will be formatted in a the most productive ways from the perspective of bus companies.