Parsing and analyzing Minecraft ore distributions

Some months ago, my 6 year old son discovered Minecraft. His sister and I soon followed. It’s a great game and there’s a ton of good content out there about it. Reddit and forums are active. it has an excellent wiki, and lots of YouTube stuff. Not surprising given how popular the game is.

One topic that is covered a bunch is how to best mine for diamonds. The thing is that beyond a graph of diamonds by layer, I don’t really see any data involved.

In this post, I talk about how I parsed a Minecraft Bedrock world database to get some more numbers. Topics include:

  • Pictures of some fun situations and overall distributions.
  • Some numbers concerning the densities/distributions diamond, other uncommon ores and spawners.
  • How to parse the data yourself.
    • Mojang/Microsoft has released their variant of Google’s leveldb, but it doesn’t compile out of the box and it doesn’t come with a reference parser.
    • The wiki is very helpful but I find that actual code samples tell me more.

A big caveat…

This post mentions data from only one Bedrock world which hasn’t been traveled much. The seed is “-1337710146”. I don’t remember where I got it but it was from a YouTube video.

My version of a needle based foam cutter

Some time ago, I came across this forum thread about cutting foam with a reciprocating needle.  There’s also a pretty good summary that distills a bunch of the details.
Here’s a video that talks about my experiences in getting such a thing to work:

Here’s a link that I mentioned in the video about working with the HC-05 module
The other stuff is all pretty easy to find with some simple searches.

Organizing photos with exif and more

I’ve recently spent a bunch of time organizing a pile of picture files in various directories. This post is about some of the utilities I’ve found more useful.

I want this structure:
├── 01
│ └── 31
│ ├── 2012-01-30_17-26-35_65.jpg
│ └── 2012-01-30_17-26-39_533.jpg
├── 02
│ └── 13
│ └── 2012-02-13_15-37-29_814.jpg
I often have this structure:
├── IMG_20171204_140837.jpg
├── IMG_20171204_140838.jpg
├── IMG_20171204_140839.jpg
├── IMG_20171213_085000.jpg
├── IMG_20171213_085021.jpg
└── IMG_20171228_110227.jpg
├── IMG_20171204_140839.jpg
├── IMG_20171213_085000.jpg
├── IMG_20171213_085021.jpg
├── IMG_20171213_085025.jpg
├── IMG_20171217_160410.jpg
└── IMG_20171217_160411.jpg

Best option…

if you files have create date stamps in the picture files, this command is the best option:

This will set a file’s directory to reflect the CreateDate property. If there’s no such property, exiftool will do nothing.

Remove empty directories

After the “best option”, you may end up with empty directories.

Remove duplicates

This will keep the “first” of a set of copies and remove the rest. I’ve found it difficult to predict which will be first. I understand it’s by name but it often seems not to. Be careful for the situation where one copy is in a directory that tells you the date and another that perhaps isn’t.

Add a CreateDate tag

The date tag should look like this:
2018:04:22 16:50:28
You may have directory names that look like this:

Comparing register states in embedded gdb with regview

regview is a gdb based utility for viewing control register state. ADC, DMA, RCC,… I use it to view STM32 registers
I am not the original author, but I needed some additional features. In particular, the ability to save and compare states from two sessions. I had a reference prototype that worked and some code of my own that didn’t. Compare register states between the two helped me move forward.

The enhancement I talk about are here:
It is a fork of this original:
It uses register definitions from here:
gdb python is documented here:

Understanding and parsing SVG paths

I recently had the need to parse vector paths from an svg file generated by inkscape. I wanted to convert some graphics into kicad zones and/or boundaries. So I drew some stuff in inkscape and looked at the resulting svg file. Didn’t look so hard to parse.
Turns out there are a fair number of details to consider:

  • The path format itself. relative and absolute coordinates, closing polygons…
  • Transformation matrices embedded in the svg.
  • Global coordinate space. I want the graphics to be a specific size on my PCB.
  • Polygons can have holes. Inkscape doesn’t associate them for you. It doesn’t tell you which polys are boundaries and which are holes

You can find the python code I came up with here. It implements the svg parsing functions that I needed to turn this in inkscape:

Into this in kicad

This post only talks about the svg stuff. For the kicad side of things, go to my blog

The basic path

There are lots of online descriptions of svg paths. Like this one. The basics:

  • A path is stored in the ‘d’ attribute of a path node
  • A path begins either with a m or M. In both cases, it says to move to a specific, absolute value, point.

6 ways to communicate with STM32 part 4. Graphics, graphics, and I2C.

In this post, I talk mostly about displaying to graphics devices. One of those devices uses I2C interface, which I haven’t talked about in previous posts, so using I2C is an important topic I cover as well. I2C is a common communications protocol for talking to peripheral devices. Temperature sensors, memories,… anything.

As always, working code can be found in my github. I use the u8g2 library and most of the other code is STMCube generated. The interesting stuff I wrote to put it together is in main.c.

What parts will I be using?

  • stm32f103c8t6 board (<$2)
  • I2C OLED display based on SSD1306 (~$2.50)

  • SPI OLED display ($2.50). If buying on aliexpress, make sure the picture shows 7 pin connections. If you see only 4, it’s the I2C variant. They put SPI in the title, since the underlying hardware supports SPI.

  • Nokia 5110 display ($2). Bigger display, not as bright, lower resolution, but still very nice.

  • MAX7219 based 8 digit seven segment display ($1.25)

  • A logic analyzer module is helpful for getting things to work (~$5). I used this in my previous post.

I2C Erratta

The biggest gotcha, which I haven’t entirely overcome, is a bug in STM’s i2c hardware.…

6 ways to communicate with stm32, part 3. SPI to PulseView/sigrok

Edit Jan 30, 2018: fix udev permissions commands. updated firmware commands
In my previous posts of this series, I’ve gone from nothing to programming the stm32f103c8t6 to blink and interact with a terminal window. I’ve covered:

  • First post:
    • generation of boilerplate code with STMCubeMX
    • compilation with gcc for ARM
    • controlling digital output,
  • Second post:
    • sending and receiving UART communications both with blocking/polling methods as well as interrupt based
    • the non-obvious software installation steps needed to get it all to work.

All of the code can be found on github.

In this post

I cover two things

  • sending data over SPI. This is the easy part; if you understood my other two posts, you don’t really need help with this
  • receiving the sent signals with a cheap logic analyzer and the open source PulseView/Sigrok software. Being able to monitor digital signals is a handy, probably critical, tool to have.

Needed hardware

Beyond the stm32 module and stlink programmer, you’ll need a cheap 8 channel logic analyzer module from ebay/AliExpress. “usb 8ch logic” is a good set of search terms. Price is <$5 delivered.

Boilerplate code

For this project, I begin with the basic_uart STMCubeMX configuration. Only a few changes are needed:

  • In the pinout tab, I go to SPI1 and change the mode to “full-duplex master”
  • Under configuration tab -> SPI1 -> parameters, I change “prescaler” to 64, yielding a 1Mb/s data rate.