TTGO T-Display I2C pin location

You can’t always trust the datasheet.

The TTGO T-Display is a great little dev board, incorporating an ESP32 processor (with WiFi and Bluetooth support) and a small OLED display. With the header pins soldered on, it’s breadboardable — and even has a battery connector to use (and presumably charge) a small Lithium-Ion battery. Not bad for about $10.

Unfortunately, one effect of using such new technology is that the specifications sometimes change out from under you — and the firmware (let alone the documentation) takes a while to catch up. Production changes are made to solve problems, other changes are made that make these changes unnecessary, and then they’re reverted for only part of the system.

You’d think that something that breaks I2C would have been caught by now, though, especially when it’s a simple fix. Sometime in the development of the TTGO T-Display board (or a predecessor), an onboard LED was apparently placed on GPIO pin 22 (which serves as the SCL clock pin for I2C.) This LED was said to cause problems with I2C communications, so the solution was to remap SCL in the board definitions to pin 23 from pin 22.

The TTGO T-Display pinout, according to LilyGo.
Unfortunately, Pin 22 isn’t SCL. That’s defined as Pin 23…
…which isn’t brought out to a header.

Great — except nobody ever updated the pinout — or bothered to bring Pin 23 out to the header. A pin intended to connect to external peripherals is useless if it isn’t brought out to a pin where you can get it to the breadboard or external device.

A quick “Blink” clone test convinced me that nothing blinks when Pin 22 is made an output and toggled high to low, so most likely whatever LED was associated with Pin 22 was deleted long ago. Trying out SoftWire (a software-based I2C implementation) on pins 21/23 worked fine, clearing the way to change it back.

A quick Google search led me to the location of the pin definitions file for the T-Display board:

C:\Users\<user>\AppData\Local\Arduino15\packages\
esp32\hardware\esp32\1.0.4\variants\ttgo-t1\pins_arduino.h

SDA and SCL are defined just a few lines into this file. Once SCL was changed back to 22, the built-in Wire library started working. If I2C doesn’t work on your TTGO T-Display, this is why. Make the change to the file listed in bold above, and it should work.

I’d submit a pull request, but I can’t figure out who’s responsible for maintaining the ESP32 variant in the Arduino libraries. Searching through the TTGO T-Display Github doesn’t pull up any references to the SCL pin (only SCLK).

Posted in Arduino, C, Coding, Digital, Troubleshooting | Leave a comment

It from Blit

This is at least the second time I’ve stumbled across a Sierpinski Triangle.

Sometimes a bug turns out to be more interesting than the original intended result.

The above image was supposed to be a simple moving-sinewave test of bit blitting (moving most of the display and just drawing one new pixel per frame, to produce a rolling display.) Something clearly went wrong and somehow created a feedback-loop cellular automaton.

I did not expect to see a Sierpinski gasket here — but this actually isn’t the first time I’ve come across one unexpectedly. Back in high school, I wrote a program to draw the Sierpinski gasket on an HP plotter a friend had given me. That worked well enough (I think I still have the plot somewhere), but I didn’t expect the unrelated cellular automata I was playing with at the same time (on a different computer, outputting to a printer) to also draw it — outwardly fractal instead of inward.

It’s a pattern that seems likely to emerge from any of several different processes (I know of at least four ways of making this now, once I figure out what is going on with this latest version). Even Nature has joined in…

A seashell displaying cellular-automata patterns in its markings.
(Image from Wikipedia)

(The title is a play on and homage to John Archibald Wheeler’s “It from Bit” idea.)

Posted in BASIC, Coding, Fractals | Leave a comment

Coffin Corner

Fly high enough, and “too fast” becomes slower than “too slow.”

Planes are amazing things. With almost turnkey reliability, we can jump in a flying machine that can transport us at over three quarters of the speed of sound, over six miles in the air.

Like everything else, though, this amazing technology has its limits due to some basic physical laws. Wings require a certain minimum airspeed to generate lift — and you want to make sure that you fly somewhat faster than that, so the airplane keeps flying. At low aircraft weight, especially with flaps out, the minimum speed can be quite low — maybe only 120 knots or so.

There’s also an upper airspeed limit, too, of course. Dynamic air pressure increases as the square of the speed. On the 737-800, this is something like 340 knots indicated airspeed at sea level. We’re carrying a ridiculous amount of fuel on this test flight (a mission to find the magnetic North pole and also to see if a 220,000lb 737-800 can fly), so our minimum clean airspeed is higher than usual (the wing must generate more lift to offset the weight of the fuel.) This higher speed still isn’t anywhere near the maximum of 340, though, so we’re good to go, at least at first.

The problem is that there’s also a maximum Mach number. Fly faster than this, and shock waves can be set up that can cause instabilities or stresses. And the same Mach number happens at lower indicated airspeeds, with increasing altitude.

Eventually, the highest speed that the plane can safely fly dips uncomfortably close to the minimum speed required to keep it in the air. Welcome to “coffin corner.” Fly much faster, and the airframe is overstressed. Fly much slower, and the plane falls out of the sky.

The 737-800 flight shown above is still relatively safe (getting that heavy a 738 airborne, even from KEDW, was the tricky part). It’s stable now, and the minimum speed will decrease as fuel is burned off. Even now, it’ll probably still fly at 220ish without flaps. Were there to be a problem, the solution is to descend.

…Now to figure out where to land. I wonder if CYLT (Alert, Canada) is modeled?

Posted in Aviation, Science, Uncategorized | Leave a comment

Magical Music Machine

Music is a fascinating blend of art and math. The creation of a song is absolutely an artistic, creative act — but one which generally follows quite a few explicit and implied rules. The music that we enjoy has patterns — if you play the major scale CDEFGAB and then stop, Western ears “want” to hear that final tonic C. We generally find major and minor triads to be harmonious, and generally find other combinations of tones to be dissonant.

A while ago, I came across a fascinating YouTube video on Shostakovich’s Fugue in A Major. Rather, it starts out in A and then goes on a harmonious tour of the Circle of Fifths, modulating only into keys that can be reached by a direct harmonious transition. C major, for example, could modulate into A minor, since C and E form part of the A minor triad. It’s beautiful, and seems to be able to just dance around the Circle of Fifths at will without creating any dissonances. It sounds like the sort of music gemstones would listen to.

That fugue (and video), along with having recently discovered FreeBasic’s MIDI capabilities gave me the idea to try writing a program to play random notes, choosing only from those which made musical sense. First, I had to find out what that meant — and an easy first answer turned out to be “those notes that form major or minor triads.”

From there, I made an Excel spreadsheet to figure out which transitions were possible. Neglecting octave duplicates, it turns out that for each pairing of two notes (that have to start out as either a minor third, major third, or fifth apart for this to work), exactly two new notes are possible — one major and one minor — since any two notes that are a minor third, major third, or fifth apart are musically ambiguous and can form one unique major and one unique minor chord. C and G, for instance, could form C major or C minor. C and E could make C major or A minor.

Seeding the system with C and E, I turned it loose and recorded the output with Audacity. The result is an aimless random walk around the piano keyboard, with few limitations — except that it never plays any dissonant notes. It’s a monkey at a piano keyboard, but either a minimally musically-inclined monkey or a charmed keyboard, enchanted to never play a sour note. (There’s also provision to bring the melody up or down an octave if it gets too low or too high — the farther from Middle C it gets, the more likely it is to be shifted.)

[Stochastic Sugar]

The next step was to add some variation. Tempo was easiest to change, so I added some code to vary the tempo between two limits. (In retrospect, the high limit may be a little too frenetic.)

[Chromatic Wanderings]

With the tempo variations, this sounds a bit more human, but still lacks any real sense of where it’s going. At this point, I started wondering what would happen if it were to show bias in which transition it chose. For each possible new note, it can pick major or minor — so I decided to try biasing it one way or the other.

First, I tried making it 95% likely to take the major branch and 5% likely to take the minor one. Even though I knew this would result in a lot of major-key scales, it was still fascinating to see what a change in the music’s mood could be made, just from tweaking a few numbers.

At some point (maybe here), I also added a 1/8 probability of simply repeating the second-to-last note played, allowing for the possibility for the melody to pause between keys and perhaps return to an original key before committing to a new one.

[Synthetic Optimism]

Biasing for major turned out well, so of course the natural thing to do next was to bias for minor. This didn’t result (at least to my ears) in a melancholy sound, but instead a more introspective one.

[Infinite Introspection]

Next, I wanted to try producing music which switched from major to minor. So instead of choosing the major or minor transition based on constant probabilities, I set it to choose major with 95% probability, but to switch this to 95% minor a small fraction of the time. This results in a piece which commits to major or minor scales, but periodically has mood changes. The music now understands both major and minor, and goes through phases of each.

[Major and Minor]

There’s still a lot to explore here — even with these rules, the melodies that result are still closer to the random, unscripted sound of windchimes than they are to Vivaldi or Mozart. Adding some dynamical systems to influence the mood would probably add quite a bit of interest. Teaching it about motifs, themes, counterpoint, and all the rest … will be trickier. For now, there’s enough musical knowledge baked into the rules that the sounds produced at least sound “syntactically” correct, though — and every so often, it stumbles across beautiful-sounding motifs and chord progressions.

Its output is plausible enough at this point that if it were playing quietly in the background of a posh store, most customers would think it’s fancy classical music (even if the music majors would be shaking their heads at the lack of any real musical plan.) It’s acceptable-to-decent meditation music as it is, and could provide some interesting raw materials for the creation of handcrafted music.

And if you want a constant stream of happy, overcaffeinated, upbeat Musak, basically guaranteed to create endless original-if-soulless major triads 24/7 with no repeats, now there’s an app for that.

[The Fountain Of Happy]

(All songs CC-BY-NC-SA 2020 M. Eric Carr / Northlight Cyberacoustics.)

Posted in BASIC, Coding, Math, Music | Leave a comment