LEDodecahedron

2023-09-03 19:22:08

Been a minute and I've currently found some motivation to work on animations and make the code run faster plus also mapping things finally.

Found out the ESP32 only has a 64 byte hardware buffer for I2C and that I need to use endTransmission after 63 bytes, stole some adafruit code for I2C oled displays and put it in the library I'm currently using for the IS31FL3733.

Here's a snippet of the I2C write section.

Wire.beginTransmission(i2c_addr);
Wire.write((byte) reg_addr);

uint16_t rounds = 1;
uint16_t bytesOut = 1;
uint8_t *ptr = buffer;

#if defined(ESP32)
    while (count--) {
        if (bytesOut >= 64) {
            Wire.endTransmission();
            Wire.beginTransmission(i2c_addr);

            Wire.write((byte) reg_addr + 63*rounds);
            bytesOut = 1;
            rounds++;
        }
        Wire.write((byte)(*ptr++));
        bytesOut++;
    }
    Wire.endTransmission();
    return 1;

#else
    Wire.write((byte) reg_addr);
    for (uint8_t i = 0; i < count; i++) {
        Wire.write((byte)(buffer[i]));
    }
    Wire.endTransmission();
    return 1;
#endif

2023-09-03 19:22:08

Been a minute and I've currently found some motivation to work on animations and make the code run faster plus also mapping things finally.

Found out the ESP32 only has a 64 byte hardware buffer for I2C and that I need to use endTransmission after 63 bytes, stole some adafruit code for I2C oled displays and put it in the library I'm currently using for the IS31FL3733.

Here's a snippet of the I2C write section.

Wire.beginTransmission(i2c_addr);
Wire.write((byte) reg_addr);

uint16_t rounds = 1;
uint16_t bytesOut = 1;
uint8_t *ptr = buffer;

#if defined(ESP32)
    while (count--) {
        if (bytesOut >= 64) {
            Wire.endTransmission();
            Wire.beginTransmission(i2c_addr);

            Wire.write((byte) reg_addr + 63*rounds);
            bytesOut = 1;
            rounds++;
        }
        Wire.write((byte)(*ptr++));
        bytesOut++;
    }
    Wire.endTransmission();
    return 1;

#else
    Wire.write((byte) reg_addr);
    for (uint8_t i = 0; i < count; i++) {
        Wire.write((byte)(buffer[i]));
    }
    Wire.endTransmission();
    return 1;
#endif

2022-12-27 18:51:43

There are some "between the years" events happening in Europe that follow the spirits of the chaos communication congress that got cancelled this year. In a small venue with 400 people I gave this talk about my Dodecahedron! :) Was a fun first talk of this kind for me.

2022-12-27 18:51:43

There are some "between the years" events happening in Europe that follow the spirits of the chaos communication congress that got cancelled this year. In a small venue with 400 people I gave this talk about my Dodecahedron! :) Was a fun first talk of this kind for me.

2022-11-18 10:38:28

Did some more "perfect scenario" calculations for the possible frame rates, after failing math hard at supercon, thinking that I am sending out half a million bytes for a frame on the cube.

• 12 displays
• 192 bytes of data  - 12x16 pwm values for 64 LEDs, even though I'm using only 51 LEDs
• every byte is followed by an ACK from the peripheral

So we have 12 * 192 * 9 bits to fly over of raw data, not including addressing and setting PWM page. At a 400kHz clock speed or 400000 bits/s we arrive at a hypothetical 19.3 fps. 

What did I change to get here? After sending the data for the LEDs in bursts, I arrived at roughly 10fps and hooked the cube up to the oscilloscope to see what's going on. Turned out the clock was at roughly 200kHz instead of the expected 400kHz o.o

This might look very obvious at first sight to some, but the spikes aren't supposed to look like this and there is this magical thing that you can add to I2C lines, when it looks like that - I forgot about pull-up resistors! To allow for a fast rise you need resistors connected to VCC to help rise the potential of the capacitive natured data and clock line. To be honest I have no idea how to better explain this, but I hope the image helps a bit.

I've added 2.2k resistors to the module and suddenly arrived at 16fps! I might be able to go even faster with a different controller, but I still like the XIAO NRF52840 sense too much with all its features that I have yet to use :D

https://cdn.hackaday.io/images/7903821668763860986.jpeg

2022-11-18 10:38:28

Did some more "perfect scenario" calculations for the possible frame rates, after failing math hard at supercon, thinking that I am sending out half a million bytes for a frame on the cube.

• 12 displays
• 192 bytes of data  - 12x16 pwm values for 64 LEDs, even though I'm using only 51 LEDs
• every byte is followed by an ACK from the peripheral

So we have 12 * 192 * 9 bits to fly over of raw data, not including addressing and setting PWM page. At a 400kHz clock speed or 400000 bits/s we arrive at a hypothetical 19.3 fps. 

What did I change to get here? After sending the data for the LEDs in bursts, I arrived at roughly 10fps and hooked the cube up to the oscilloscope to see what's going on. Turned out the clock was at roughly 200kHz instead of the expected 400kHz o.o

This might look very obvious at first sight to some, but the spikes aren't supposed to look like this and there is this magical thing that you can add to I2C lines, when it looks like that - I forgot about pull-up resistors! To allow for a fast rise you need resistors connected to VCC to help rise the potential of the capacitive natured data and clock line. To be honest I have no idea how to better explain this, but I hope the image helps a bit.

I've added 2.2k resistors to the module and suddenly arrived at 16fps! I might be able to go even faster with a different controller, but I still like the XIAO NRF52840 sense too much with all its features that I have yet to use :D

https://cdn.hackaday.io/images/7903821668763860986.jpeg

2022-11-15 13:14:15

I've spent 3 hours hunting down the speed settings for I2C on the Seeed XIAO NRF sense board in Arduino, but couldn't find it. My goal was to have a frequency of 1MHz for I2C instead of 100kHz, but so far there was no chance.

it's quite frustrating that I still have no idea where the seeed library based on mbed for the XIAO NRF sense defines how the I2C works with the wire library in Arduino. I found so many registers and values where I was "aha! That's the two wire interface speed value that I was looking for!" but then nothing changed when I edited the sdk_config.h file.

The other thing that slows down the animations is the code for writing to the LEDs. Looks like the code first writes a select page and then writes a single byte for the LED pwm value. There's definitely optimisation possible in streaming plenty bytes after selecting a page, instead of ping pong-ing that often to effectively set one byte.

[UPDATE] 10 frames per seconds reached

managed to send complete frames to the I2C controllers and now reach 10 frames per second on the NRF52840 board. After some datasheet reading I'm not so sure I can easily reconfigure the I2C to go 1MHz on the NRF52 and ordered an ESP32-S2 QT PY board to play around with. Last hope for the NRF52 is using the adafruit board libraries instead of the XIAO mbed library as I am fairly certain I saw code there that makes more sense. Would be nice to be able to use the NRF board with all its sensors (mic+accelerometer) on board.

FLASHING LIGHTS WARNING 

2022-11-15 13:14:15

I've spent 3 hours hunting down the speed settings for I2C on the Seeed XIAO NRF sense board in Arduino, but couldn't find it. My goal was to have a frequency of 1MHz for I2C instead of 100kHz, but so far there was no chance.

it's quite frustrating that I still have no idea where the seeed library based on mbed for the XIAO NRF sense defines how the I2C works with the wire library in Arduino. I found so many registers and values where I was "aha! That's the two wire interface speed value that I was looking for!" but then nothing changed when I edited the sdk_config.h file.

The other thing that slows down the animations is the code for writing to the LEDs. Looks like the code first writes a select page and then writes a single byte for the LED pwm value. There's definitely optimisation possible in streaming plenty bytes after selecting a page, instead of ping pong-ing that often to effectively set one byte.

[UPDATE] 10 frames per seconds reached

managed to send complete frames to the I2C controllers and now reach 10 frames per second on the NRF52840 board. After some datasheet reading I'm not so sure I can easily reconfigure the I2C to go 1MHz on the NRF52 and ordered an ESP32-S2 QT PY board to play around with. Last hope for the NRF52 is using the adafruit board libraries instead of the XIAO mbed library as I am fairly certain I saw code there that makes more sense. Would be nice to be able to use the NRF board with all its sensors (mic+accelerometer) on board.

FLASHING LIGHTS WARNING 

2021-12-30 12:38:40
I missed that one LED wasn't correctly placed in the schematics and one connection is missing. Have to go in with magnet wire and fix that on all 15 boards :)

https://cdn.hackaday.io/images/431351640864234113.jpeg
https://cdn.hackaday.io/images/7764001640864233547.jpeg
https://cdn.hackaday.io/images/4595981640864238012.png

2021-12-30 12:38:40
I missed that one LED wasn't correctly placed in the schematics and one connection is missing. Have to go in with magnet wire and fix that on all 15 boards :)

https://cdn.hackaday.io/images/431351640864234113.jpeg
https://cdn.hackaday.io/images/7764001640864233547.jpeg
https://cdn.hackaday.io/images/4595981640864238012.png

2021-12-17 20:33:31

Always tough googling something when you're looking for the name to google in the first place. I needed the "dihedral angle" of a dodecahedron, meaning the angle between the sides / faces of the body. It's 116.56505°. The cool thing is, with that Angle I can basically nibble away all sides and have the perfect folding angle for this! But for now I just eye-balled it.

// 

difference()
{
    cylinder(3, 35, 33.15, $fn=5);
    union() {
        color("red") cylinder(1, 30 , 30, $fn=5);
        color("red")translate([0,0,1]) cylinder(2, 32 , 31, $fn=5);
    }
}

translate([-31, -25, 6]) rotate([ 0, 116.56505, 0]) cube([5,50,5]);

https://cdn.hackaday.io/images/8071581639769531450.png
https://cdn.hackaday.io/images/2830701639769531657.png

2021-12-17 20:33:31

Always tough googling something when you're looking for the name to google in the first place. I needed the "dihedral angle" of a dodecahedron, meaning the angle between the sides / faces of the body. It's 116.56505°. The cool thing is, with that Angle I can basically nibble away all sides and have the perfect folding angle for this! But for now I just eye-balled it.

// 

difference()
{
    cylinder(3, 35, 33.15, $fn=5);
    union() {
        color("red") cylinder(1, 30 , 30, $fn=5);
        color("red")translate([0,0,1]) cylinder(2, 32 , 31, $fn=5);
    }
}

translate([-31, -25, 6]) rotate([ 0, 116.56505, 0]) cube([5,50,5]);

https://cdn.hackaday.io/images/8071581639769531450.png
https://cdn.hackaday.io/images/2830701639769531657.png

2021-12-15 18:02:08

Since I'm visiting family in America, I found some time to tackle those weird PCB designs that I always talk about, but never do. Two years ago I made the #Do or Donut SAO  , which rhymes with this project as in me using the same(?) chip to control a bunch of LEDs. When I started this, two things came clear: I did not want to use more than one chip on a board and that basically meant going for 51 LEDs. You can read up on all my minor design choices and routing issues on twitter: https://twitter.com/davedarko/status/1468990742316167171

The distance between the LEDs in not the same at all, as the five triangles that make up the pentagon have angles of 72-54-54 degrees and are there for not symmetrical in all the directions. But I'm happy with the spacing, so I proceeded.

I should be able to power everything with a considerate brightness from a smaller battery, as was the LED cubes I took inspiration from. Heat should not be a problem either, but we'll see about that. The dodecahedron will have a height about 5cm.

The chip can have up to 16 addresses, so that's perfect for controlling the 12 boards with one IC. I have not calculated the frame rates of anything, the chips talk I2C with up to 1MHz, to up to 12x16 LEDs. 

2021-12-15 18:02:08

Since I'm visiting family in America, I found some time to tackle those weird PCB designs that I always talk about, but never do. Two years ago I made the #Do or Donut SAO  , which rhymes with this project as in me using the same(?) chip to control a bunch of LEDs. When I started this, two things came clear: I did not want to use more than one chip on a board and that basically meant going for 51 LEDs. You can read up on all my minor design choices and routing issues on twitter: https://twitter.com/davedarko/status/1468990742316167171

The distance between the LEDs in not the same at all, as the five triangles that make up the pentagon have angles of 72-54-54 degrees and are there for not symmetrical in all the directions. But I'm happy with the spacing, so I proceeded.

I should be able to power everything with a considerate brightness from a smaller battery, as was the LED cubes I took inspiration from. Heat should not be a problem either, but we'll see about that. The dodecahedron will have a height about 5cm.

The chip can have up to 16 addresses, so that's perfect for controlling the 12 boards with one IC. I have not calculated the frame rates of anything, the chips talk I2C with up to 1MHz, to up to 12x16 LEDs.