Voron 2.4 Build Post Mortem

3D printing is a rabbit hole. In one hand, it is an extremely flexible tool. The possibility to quickly go from a drawing, from an idea to a physical object, at an affordable price, is simply amazing. In other hand, depending on the person (if one likes to thinker), it becomes a hobby in itself.

When engaging a new tool, a new hobby I usually start with a cheaper tool, and then decide if I should pursue the hobby further should I outgrow the tool. This is where I am at with my ender 3 V2.

Continue reading “Voron 2.4 Build Post Mortem”

Inercia Demoparty 2022 Trophy post mortem

Trophies under post delivery inspection after unpacking.

Context : Revival of the Inercia Association

As far as I am concerned, Jeenio’s initiative of reviving Inercia association, and thus ensuring continuation of Inercia Demoparty, was a very important milestone on the portuguese demoscene.

And, as such, I wanted to find a way to contribute to Inércia demoparty. One of the organizers, psenough, asked for someone to print the trophies for the compos , and it seemed to be a good synergy between what I like to do and what contribution would be useful to the party.

How it began

Work on the trophies for the Inercia Demoparty 2022 began on April of 2022, using harvestpt Inercia designs as basis.
I was given free reign on the design and materials to use.

The community on scenePT discord was consulted and regularly informed of the progress of the work on the trophy design as it happened.

Designs

The major goal was to have a custom designed trophy – I did not want to just get a trophy from thingiverse and stick a inercia logo on it.

The trophies were designed on blender, sliced on Cura and printed on a Ender 3V2.

Continue reading “Inercia Demoparty 2022 Trophy post mortem”

Getting started on SEGA saturn development – Part 2

After the Hello World

After writing a simple hello world, 2 things are needed before proceeding :

  • Get the execution time, (and in turn, frame times) in order to properly write time based animations
  • How to get simple primitives drawn on the screen

Getting execution time

libyaul supplies following function

static uint16_t cpu_frt_count_get(void);

However the return type is a problem : it quickly overflows.
After some digging on discord, as well as examples provided with libyaul:

#include <yaul.h>

#include <stdio.h>
#include <stdlib.h>

uint32_t elapsed_time = 0;
static void _frt_ovi_handler(void);
static uint16_t _frt_overflow_count = 0;

void main(void)
{
    //initialize dbgio
    dbgio_dev_default_init(DBGIO_DEV_VDP2_SIMPLE);
    dbgio_dev_font_load();
    dbgio_dev_font_load_wait();
    vdp2_tvmd_display_set();

    cpu_frt_init(CPU_FRT_CLOCK_DIV_32);

    uint32_t frame_time = 0 ;
    uint32_t frame_start = 0 ;
    uint32_t frame_end = 0 ;

    //init

    cpu_frt_ovi_set(_frt_ovi_handler);
    cpu_frt_count_set(0);

    /* Reset overflow counter after setting the FRT count to zero in case
     * there's an FRT overflow interrupt */
    
    _frt_overflow_count = 0;

    while(1)
    {
        elapsed_time += frame_time;
        frame_start = ((65536 * _frt_overflow_count) + (uint32_t) cpu_frt_count_get()) / CPU_FRT_PAL_320_32_COUNT_1MS;
        
        dbgio_printf("\x1b[H\x1b[2J");
        dbgio_printf("Elapsed time :\t %u
        \nFrame_time :\t %u
        \nFrame Start :\t %u
        \nFrame End :\t %u
        \noverflow cnt :\t %u\n", 
        (unsigned int) elapsed_time,
        (unsigned int) frame_time, 
        (unsigned int) frame_start,
        (unsigned int) frame_end,
        (unsigned int) _frt_overflow_count);
        dbgio_flush();
        vdp_sync();

        frame_end = ((65536 * _frt_overflow_count) + (uint32_t) cpu_frt_count_get()) / CPU_FRT_PAL_320_32_COUNT_1MS;
        frame_time = (frame_end - frame_start) ; // get tick count at start 
    }
}

static void _frt_ovi_handler(void)
{
        _frt_overflow_count++;
}


Now I’m able to measure the render time and also have the elapsed time.

Getting started on SEGA Saturn development – Part 1

A hello world on libyaul.

Nothing better than a simple hello world to get the feet wet on a new hardware.

My goal, as of April 2021, is to get a simple demo (as in demoscene demo) done by October, for Inercia Demoparty , for the sega saturn.

I’ve already had a USB dev cart for the sega saturn that I’ve brought from cafe-alpha, but had been gathering dust for several years.

Toolchains

As toolchains for the sega saturn I’ve found :

  • Libyaul : available for windows and linux. Tools such as emulators to test the code are already included.
  • Saturn SDK : SDK, libs and documentation.
  • Jo Engine : an open source 2d and 3d engine.

The list is not complete.
I´ve decided to stick to libyaul. On windows it was simple to setup, examples could be easy compiled out of the box, and it has a helpful and active community on discord , where the author of libyaul is also part of.

Hello World

Makefile

The make file was just a modified makefile already available from the exemples provided with libyaul.

Code

#include <yaul.h>

#include <stdio.h>
#include <stdlib.h>

void main(void)
{
    //init the subsystem to print debug text to the screen
    dbgio_dev_default_init(DBGIO_DEV_VDP2_SIMPLE);
    dbgio_dev_font_load();
    dbgio_dev_font_load_wait();

    //enable vdp2
    vdp2_tvmd_display_set();
  
    while(1)
    {
        dbgio_printf("\x1b[H\x1b[2J");  // clears the screen
        dbgio_printf("Hello World\n");  // actual text
        dbgio_flush();                  // flush 
        vdp_sync();                     // required at the end of each frame
    }
}

Measure Light – The quest for a light meter for analogue photography – Part One

Light Meter
Light meter with a FTDI USB – Serial Interface for sw development

I love analogue photography, even more when it’s with fully mechanical medium format cameras, such as the Flexaret Automat VII, and the Hasselblad 500c.

However, where are some situations where the correct exposure is difficult to determine. On such cases, one could use a second camera for TTL metering (such as DSLR), a phone app…or a light meter.

On my location, an new sektronick light meter price varies from 109 € to 600 € depending on the model. On ebay you could get an used, cheaper , vintage light meter, but your mileage might vary.

So since the price and availability of light meters were not to my liking, I’ve decided to build my own from scratch, based on an arduino board, with some help of Pedro Virtebo, at Maquinas de Outros Tempos.

Bear in mind this is not the first or last time anyone has done something similar, a simple google search show a ton of similar projects, with different levels of polish. But just implementing these would not give me enough understanding of how a light meter works.

Continue reading “Measure Light – The quest for a light meter for analogue photography – Part One”

The quest for a Home Monitoring System : Part 3

The quest for a Home Monitoring System : Part 3

Sensor Modules for data acquisition

Hardware choices

The initial sensor module was done with an Arduino + DS18B20 sensor and a ENC28J60 ethernet chip. It was pretty fast to build a prototype that would send data via ethernet to a server running a LAMP stack.
However, since I want to have sensors trough out the house (including the exterior), it became a problem since I’m unable to pass an Ethernet cable everywhere I might need a sensor module installed.

The cheapest to add wifi capabilities to an arduino based system would be to add an ESP8622 wifi module :

  • They are low priced  – around 1,7€  a piece on ebay.
  • Answer to AT commands via serial communication (thus an arduino board could simply send AT commands to the module with the data).

But upon more reading,  it was also noted that the ESP8266 could be used as a stand alone module, without the arduino hardware. This helps drive the cost and assembly complexity of each module down further. A major plus was the fact that the arduino IDE can be used with the ESP8266, work with most libraries already included, without changes to software development workflow.

Sensor Module Schematics for version 1.0. Notice the few component count.

And since the ESP8266 supports I2C  and 1 wire data buses, any sensor supporting those protocols can be added to a ESP8266 module.

Sensor module variants

ESP8266 based sensor Modules – PCB version 1 and Breadboard prototypes during code development

A total of 3 variants of the ESP8266 based sensor module, as of 17th February, were built:

  • A module only using a temperature sensor (the DS18B20), with no RTC on board. Exists in breadboard form only and it is currently in use.
  • A module using both a DHT22 humidity and temperature sensor, and also a DS18B20 sensor. Also without RTC support. Module was disassembled and parts used on the PCB version 1.0.
  • A module using a DHT22 humidity and temperature sensor, with a DS1337 RTC, as used on my Nixie Clock. This version was built on a PCB designed in KICAD, and it is currently in use.

Continue reading “The quest for a Home Monitoring System : Part 3”

The quest for a Home Monitoring System : Part 2

The quest for a Home Monitoring System : Part 2

Changes to the Home Monitoring System Architecture

Almost a year later, and a working prototype, the development of the monitoring system had reached a standstill, mostly due to the lack of time :

  • On the sensor side , the Arduino + ENC28J60 + DS18B20 combo works, although it is dependent on the availability of a network cable. But the hardware is functional.
  • On the server side , the development of a backend and frontend with the flexibility required (multiple sensor support, dashboard with user selected time intervals, etc)  was starting to take too much time.

Sensor : Arduino + ENC28J60 + DS18B20, Server Side : LAMP stack, chart done with chart.js

So I was faced with a decision regarding the server side of the system:

  • Fully development of a frontend and backend , using a LAMP stack and bootstrap templates. This would take time that I simply don’t have, and the project would probably still be stalled.
  • Or find a solution that would require less effort. And this was only an option when I was introduced to Elasticsearch + kibana stack.

On the hardware side, I had some ESP8622 (ESP-12) modules to try out.

ESP8622 Sensor Module prototype with a DS18B20 temperature sensor

Current Status

Server Side changes

The server side of the Monitoring system was the one that was the most time consuming.

One of the major changes was the replacement of the LAMP stack for elasticsearch and kibana for data storage and  visualization respectively. This removed the need to write a backend and a frontend from scratch. The time that would be spent on writing the back and front ends was spent on the sensor module development (both hardware and software).

Elasticsearch, according to the authors:

” Elasticsearch is an open source distributed, RESTful search and analytics engine capable of solving a growing number of use cases.”

With elasticsearch, the sensor modules sends data in json , instead of sending the data via http get to a php script with the previous Monit System architecture.
And a dashboard with visualizations of the data can be done in minutes.

KIbana Dashboard

Hardware changes

Although the arduino + enc28J60 sensor module was not entirely abandoned, hardware development focus was oriented on the ESP8622 based modules.

The ESP8622 have some interesting advantages over the arduino + ENC28J60 combination :

  • The ESP8622 can be sourced from around  1,7 € a piece (ESP-12) (and it replaces the arduino board and the ENC28J60 in one package)
  • It can be used with the Arduino IDE , and use most of its libraries (no need to learn a new SDK and new tools).
  • No additional network hardware required, since the ESP module is a wifi module first and foremost (DHCP, WPA2 supported out of the box), and thus I could place the sensor module anywhere as long as there is wifi coverage, including the exterior of the house.
  • Less parts per module, since the ESP8622 has an ARM CPU besides the WiFi capabilities : besides the module itself, only the sensor, a RTC (if needed) and some passive components are needed.

However the usage of the bare modules are not as “plug and play” as with arduino boards – additional hardware and wiring required . This is not an issue since the final goal is to have a custom made PCB for the sensor module.

 

The quest for a Home Monitoring System : Part 1

The quest for a Home Monitoring System : Part 1

General Architecture

For a long , long time I wanted to have a system to monitor, and perform data collection, on my home.
A modular system where I could gather data from indoor and outdoor temperatures to local power consumption.

CasaMonit Initial Architecute proposal
CasaMonit Initial Architecture proposal

The system is meant to be designed in such manner that the server side is fully abstracted from the sensor module side, more sensors modules may be implemented on different hardware platforms. There can be as many sensor modules as required, connected on a single Ethernet network.

 

Sensor Module Hardware (Prototype)

Prototype Hardware Sensor Module
Prototype Hardware Sensor Module

Continue reading “The quest for a Home Monitoring System : Part 1”