Apertus: Google Summer of Code Wrap 2020

October 6, 2020 fustiniapertus, axiom, GSoCLeave a comment

We always like seeing updates from the Apertus open source cinema camera project:

Google Summer of Code Wrap 2020

Google Summer of Code or short GSoC came to an end for this years season recently and here we want to showcase some of the cool projects students work on this year around the AXIOM camera.

AXIOM Remote: Bootloader improvement and extensions
“The task was split up in the following sub-tasks:
– Flashing of the PIC16 firmware using the PIC32 bootloader
– Self-programming of PIC32: In simple terms it basically means to flash the firmware-with-UI on the PIC32 microcontroller
– Establishing the communication between the bootloader and the firmware
– Power saving modes for PIC32, LED dimming etc.
I created a python script which runs on the host PC and it can take care of the first two sub-tasks. The user can select the connected USB-UART port, HEX file to flash and the operation to perform. The project proposal, code links and the phase-wise report are given here on the Project Wiki page.” – Priya Pandya (MetalDent)

Update from Apertus on the AXIOM open source cinema camera

December 10, 2019December 10, 2019 fustiniapertus, axiom, GSoCLeave a comment

Apertus is designing an open source 4K cinema camera called AXIOM. We are excited to see the latest news from the project:

AXIOM Team Talk Volume 15.2 is out!

Max and Sebastian again dive into recent project developments like Google Summer of Code projects and the AXIOM Remote.

Once again apertus° participated in Google’s sponsored program for students working with open source projects like this one. Here is a brief insight into what was worked on this year for Summer of Code. Six student slots were filled with excellent applications and four students finished the program successfully.

Google Summer of Code student Fares Mehanna.

Their projects deal with USB3 connectivity of the AXIOM Beta, JPEG1992 lossless encoding inside the AXIOM Beta’s FPGA, improvements to AXIOM Remote and the camera’s internal central control daemon.

There has been good development progress in several areas with the camera control device, the AXIOM Remote. The device features a small display with graphical user interface, a central rotary encoder dial and physical buttons providing haptic feedback where a touchscreen (think smartphone app) simply couldn’t. There is an enclosure concept, electronics prototype and software running on the device prototype already.

BeagleLogic Standalone featuring the Octavo SiP

December 4, 2017December 2, 2017 fustiniBeagleBone, beaglelogic, GSoC, hackaday, hackaday.io, kicad, linux, logic analyzer, Octavo, sigrok, SiP, SoCLeave a comment

Guest article written by Kumar Abhishek on the Octavo Systems website:

BeagleLogic Standalone – Featuring the OSD3358-SM

Three years ago, as a student under the Google Summer of Code program for BeagleBoard.org, I developed BeagleLogic – that turned the BeagleBone Black and its variants into a Logic Analyzer using the Programmable Real-Time Units (PRUs) on the AM335x SoC to capture up to 14 inputs up to 100 MSamples/sec. It is possible to fill up to 300MB of the 512MB DDR RAM in the BeagleBone with logic samples – that’s 3 seconds of data at 8 channels (1.5 secs at 16 channels). I also designed a cape for the system – called the BeagleLogic cape that would allow buffering the external logic signals up to 5V TTL so that they do not damage the BeagleBone.

The launch of Octavo Systems and its OSD3358 SiP got me excited, and the idea of a turnkey version of BeagleLogic was rekindled as the design would be greatly simplified due to the SiP integrating the core components, leaving me to focus on the features I want to add to the system.

From concept to completion, this project took 4 months working on it part-time. I relocated in August so work happened at an even slower pace during that month

https://octavosystems.com/2017/10/31/beaglelogic-standalone-featuring-the-osd3358-sm/

The schematics were originally based on the OSD3358, however Jason encouraged me to design based on the newly announced OSD3358-SM as it was smaller and had a more optimized ballmap. The schematics were then migrated to the OSD3358-SM in late July. At the beginning of the routing exercise, I was really apprehensive if the design could be routed in 4 layers but thanks to the optimized ball map of the OSD3358-SM, the routing was easily completed so.