Category Archives: Electronic Projects

CoAP / Swift 3.0 / ESP32 research

Today, I started back into my C++ coding and research for my DMX controller.
For work, I bought the City Theatrical DMXCat in the meantime to get some semblance of what I am after out of a device.  I have even used it on set a few times.

I will probably also get an Android tablet and make it an entire controller in a case with independent power.   It has a lot of promise, but I might be working on something that can do more.

Been looking into the ESP32 micro-controller lines.  I see that they can do BLE and have an even faster clock speed than the Teensy 3.6 and have Wifi built-in.  It sucks that Wifi and BLE are so hard to do but PJRC is WAY behind on this one and I need this device now.  I have considered putting an ESP 8266 on the Pockonsole board.

However, I won’t be able to parse wifi data through CoAP unless I want to go with the much more capable ESP32..because BLE is a huge part of the requirement.

Perhaps that is how it will end up.  Looking into this guy’s work (https://github.com/oneam/Esp32LedControl), I might already have all that I need to do this.  It’s just parsing the CoAP data into a 512 value array of 8 bit ints then into the DMX Protocol working with ESP32’s UART that I need help on.

Also, an 8266 interfaced with the Teensy 3.6 doesn’t do BLE, so it is kind of useless in being a open source DMXCat replacement.  I used to think that MQTT was the way to go, but this CoAP standard seems even more interesting and robust because you can have BILLIONS of nodes asynchronously communicating.

As always, I want to think beyond current capabilities at the outset.  So CoAP looks REALLY good to ensure that…and would take care of much of the asynchronous behavior that has to happen that I have NO CLUE about at the moment.

Imagine an asynchronously programmed mesh network of LED’s  !?!?!?  It would be mind-blowing what lighting affects could be achieved.

More on this later.  I need to think on it. Just learning about CoAP now.

Pockonsole Prototyping Platform

I am a big fan of Teensy Microcontrollers and have been working with them for a year now. The best thing about them, to me, is the speed and massive I/O compared to any other arduino board.

I recently started a project where I was going to build a simple DMX circuit with 9 faders for controlling DMX levels. As I got further in, I was inspired by Tall Dog’s Teensy 3.1/3.2 Breakouts on Tindie. I contacted my friend who is a talented EE and we sat down and worked on a custom circuit that not only breaks out the Teensy 3.6, it adds, an RS485 chip for DMX transmission, over-current protection, a regulator for up to 36V in, 9 faders, an SPI OLED screen, and a prototyping area that is inspired by breadboards with a full breakout of all unused pins all on a fairly big circuit board. I am excited about it because it will not only allow me to have a robust version of the circuit I was originally going to wire together with point-to-point wiring, it adds some of the bells and whistles (and esoteric electrical best practices) that I would have avoided (for example, a .1 uF capacitor on each potentiometer was NOT in my plan) along with being an excellent platform for future projects.

There’s a lot of expansion that has happened on this project.  Since getting a custom circuit made and designed is so damned expensive, I wanted to be getting the most bang for my buck.  More on this topic in a few minutes.  I need to document all of the stuff that Steve and I came up with as well as a fe wprojects that I haven’t quite had the time to mention and document.  Big things are happening in my life as far as learning about and transitioning to a side career in inventing film tools/engineering…and this is the coolest one yet.

FPGA’s and their benefits to embedded systems.

This week, among my actual work responsibilities, I started learning about and my mind was partially occupied by thoughts of FPGA’s (or field-programmable gate arrays).

They are a type of chip that is able to be configured (similarly to microcontrollers) to perform simple logic on hundreds of inputs in perfect simultaneity (unlike microcontrollers). Instead of, as we see in the arduino, a single processor, cascading down a set of instructions in sequence, they do a simple task in parallel hundreds of thousands of times a second.
They are essential to applications that require arrays of simple logic gates on huge amounts of input signals. The most common modern use is GPU’s, camera sensors, industrial automation, and advanced scientific calculation.

In my estimation, they would make the project that I am currently working on around 1000% more efficient. An on-chip array of quadrature decoders would be able to take signals from hundreds of rotary encoders on one chip. In contrast, a powerful 32 bit micro-controller like the PJRC Teensy 3.1 can only reliably read at MAX four rotary encoder inputs with far higher latency. For this reason, I am currently forced to use a micro-controller for EACH axis of my pan/tilt/roll controller. The teensy has the added benefit of having libraries for a hardware quadrature encoder, but even with that, it is easily bested by the simple parallel logic gates on an FPGA.

The hobbyist world is almost entirely devoid of FPGA’s (especially in the open source realm) and that is why I am watching this project with great interest.

For now, I must work in cascading algorithms for my microcontroller-based system. However, I may someday be able to port those capabilities over to a much more efficient, low-latency, and compact device.
__________________________

Another application that I foresee FPGA’s being useful in is electronic drumming and triggering of samples. In the electronic drumming world in particular, there has always been a problem with latency. 40 ms may seem like a short amount of time, but it is actually really SLOW if you are talking about musical performance (particularly with drums). 20-40 ms is considered a standard latency for most electronic music applications..and it has always been unacceptable. This has always been my problem with Roland’s V-drums, but a system like this might be able to decrease the latency by a factor of at least 10.