Sunday, June 2, 2024

Visual Studio Installer: ERROR: The system cannot find the file specified - following system restore


A long story short, a bad USB adapter killed motherboard USB headers. The system was old enough that buying a new CPU/motherboard would be as much as buying a used motherboard. I decided to do a new build, and with a fresh install my OS. While installing Visual Studio Community 2022, I found that the installer would download files, but then die when trying to perform the install. I had earlier had a BSOD issue with a PCI card, and ended up running a repair on my system. This messed up a lot of my just installed applications including Visual Studio. Oddly, the installer did not list a specified file, the rest of the error popup was blank.


After researching their cleanup tool (which you can only get if you successfully installed VS) and reading a couple SO posts, I decided to just try something. I renamed my application directories for 

    C:\Program Files (x86)\Microsoft SDKs 

    C:\Program Files (x86)\Microsoft Visual Studio 

and tried the installer again. This time it worked. 

Keep in mind this will likely mess with any settings you have already in place. 

Monday, April 29, 2024

Addressable LED Strip Odd Colors with Arduino | Weird Behavior

I was trying to run some test code using a strip of addressable LEDs and my Arduino, but every time I ran the program, I got odd colors and the last LED color was green. Sometimes I would get a stronger color in each LED - especially when trying to set them to all white. In my case it was Red, Green, Blue (repeating 1 time) then all the other LEDs were unlit.

It dawned on me (later than I would have liked) that the order of values was wrong for the LED strip I was using (you can visibly see the large White diode in each white square). I had initialized my LED strip (using NeoPixel) to NEO_GRBW instead of NEO_GRBW as my strip has a dedicated white LED. My major mistake here was that I thought I had a strip of WS2812B LEDs but really they were SK6812RGBW LEDs. 

Adafruit_NeoPixel strip(NUM_LEDS, LED_PIN, NEO_GRBW + NEO_KHZ800);

void setup()
strip.begin(); // INITIALIZE NeoPixel strip object (REQUIRED);  // Turn OFF all pixels ASAP

void loop()
auto color = strip.Color(255, 0, 0, 255); //  Optional 4th param is White
  for (int i = 0; i < strip.numPixels(); i++)
    strip.setPixelColor(i, color); //  Set pixel's color (in RAM);                  //  Update strip to match
    delay(50);                     //  Pause for a moment

Friday, March 8, 2024

SiteGround SSH Login Trouble - Permission denied (publickey).


Working with a company that uses SiteGround for hosting, we setup SSH access on the website using keys. The SiteGround system forces a specific SSH passphrase for your key pair and it appears to be randomly generated, which is fine and considered fairly secure to my knowledge. 

After setting up SSH config on my local machine and leaving things for a while, I came back to find that I could not login anymore. I confirmed my access should still work and that nothing has changed with the keys or passphrase but I continued to get: 

Permission denied (publickey).


New solution: try a pass phrase with limited special characters. This does require you to setup a new ssh key through the website, but has ultimately solved my issue. My original solution seemed to be that somehow logging in was associated with when the passphrase would work and when it wouldn't. This is not the case. I also talked to support but they were only able to verify that my IP address was not being blocked while debugging the issue. 

Original solution: For some reason, SiteGround requires you to log back in on the their website before you can login with SSH. If you are already logged in, then you may need to log out and back in. As a guess, I think this is probably just a way they have chosen to try and combat potential bad actors, but it certainly has a lot of friction to it. 

Wednesday, January 3, 2024

Process Explorer - DLL Inspection

 I've been working with a DLL I got that doesn't have very great documentation. After trying a couple different things (ILSPy, and custom python to load and print callable functions) and all failing, I asked the great chatGPT. It suggested Process Explorer. 

I started my application, then searched for the DLL. Once I found the DLL, I was able to right-click and examine it's properties. This loaded a window with two tabs, Image and Strings. To be honest, I'm not sure off the bat what those mean, and the data on each tab seemed to be the same as the other at quick glance, but I was able to find functions I knew existed along side functions that I was not aware of. 

Exercise caution when calling any undocumented functions in your DLL, they may produce undesirable or event irreversible results.

Tuesday, December 26, 2023

Edit-as-you-go Sound Recorder

My friend, Mason, is an actor in film, stage, and voice projects. One of his enjoyed past times is to record audio books. Y'know, long ones, the ones in the public domain (his still sound great though). All from the kindness of his heart. The problem is that his typical workflow included recording long takes often with restarts or variations. Then, when he went to edit the hours and hours of audio, it would take him a really long time to narrow things down to the ones he really wanted. All this and he still had the other audio processing he likes to do before he publishes. 

As we were hanging out, I had the idea that one could substantially cut down on time if you make the decision about selections as you record them. More often than not, he has a good ideas what recording segments he thinks will work well. This is when I got to thinking about the Edit-as-you-go Sound Recorder (I'll call it EAYG). The idea was simple, write a program that would record your microphone and then when you knew you had something you liked, you would hit a keyboard shortcut and it would automatically be stored for you. Another benefit is that each clip already has a natural cutting point by virtue of being a self-contained clip or segment. Using ChatGPT a bit (haven't done much with sound in Python), and after putting things together for a couple hours, I had a working version of the program with managed memory buffers, recording flow, and even restoring your last recording if the program crashes mid-take. 

The program records audio at 96kHz 32-bit. This could be easily changed in the code, and maybe from a preference menu or something. 

Another note, Mason is always inside his recording booth, and not next to his computer. Using a simple wireless keypad, and the program shortcuts, he can trigger whatever action he wants to have happen to the clip and get audible confirmation through his headphones. 

You can checkout Mason's stuff here:

Mason Willard - Stage, Film, and Voice Actor
Email: [email protected]


Before recording, choose session directory. This directory will be the location of one or two more directories after you finish recording your session (based on good/bad takes).

Next, choose your recording device or interface.

To begin recording, start the session (F10). Once the recording has started it is now recording audio. When you are happy with the take, click Finish Good Take (F11).
If you don't like the take, click Finish Bad Take (F12).
If you are not sure about the take, click Replay Last Take and you can listen to the take on repeat, then choose Finish Good Take or Finish Bad Take.

Choosing Finish Good Take or Finish Bad Take, saves the audio segment in a respective folder, and then begins recording again automatically. 

When you are done with the session, click End Session (F10). The last segment of recording prior to the session ending will be discarded.

Your good takes will all be in a folder called /recorder-keep and the rejected audio files are in a folder called /recorder-discard. All files have been named using timestamps so they are sortable. The location of these folders can be selected prior to starting a session.

Keyboard Shortcuts

These can be changed in the code easily enough. The reason behind these was specific to the original use case of using a mini wireless keyboard to trigger recordings from inside the recording booth.

Assembly in Audacity

For quick assembly in Audacity, you can select all your good takes and drag them into a new session. Next, select them all and choose Tracks from the top menu. Then choose Align Tracks -> Align End to End.

Also, it may be helpful to turn on ripple edit so as you modify each take, the other audio files don't fall behind. You can enable this by going to Edit -> Preferences and the go to Track Behaviors and check the box "Editing a clip can move other clips"

More Help or Desired Changes

The code is available as is. If you find bugs, please submit them on GitHub and I will address them as I am able and time permits. In the event you would like bugs fixed sooner, customizations, or personal help setting up and using the program, I can be available to help at my hourly rate. 


Wednesday, December 13, 2023

Lolin32 Lite Notes

These are on-going notes I have for the Lolin32 Lite board.

Specs and graphic:

Flashing the Board

  • Plug in device
  • Start flash, wait for the Arduino ide to report 'Connecting'...
  • Connect the EN pin to GND briefly using a wire or something
  • The thing starts to flash!

Wednesday, November 8, 2023

Connecting to and Controlling an Optidrive E3 VFD using Arduino and Modbus RTU

Note: For those interested in virtual production, I have published a version of this on this website as part of a collection of virtual production resources.

While working on building some automations for a large rotating platform, I determined I would need to communicate with a the VFD (variable frequency drive) which drives the large turntable motors. From my research, it seems that many modern VFDs generally support the Modbus Protocol, generally over RS485. The Invertek Optidrive E3 that we are using, specifically supports Modbus RTU (Modbus over serial) by way of an RJ45 port. The connection for RS485 (or two wire signal configuration where one wire carries the inverse signal) can be implemented in various ways, this one is through the RJ45 port, but sometimes you will find connections for this on the terminal strip on the VFD. 

Invertek Optidrive E3

To complete our objective, we need several things: 

  • Setup Arduino to communicate using the same means (RS485) and with an understanding of the Modbus RTU protocol
  • Setup the VFD correctly to handle accepting and responding to the Modbus RTU protocol
  • Debugging capabilities (in my case, a USB TTL to RS485 cable), tools, and software

Admittedly, this is my first time working with Modbus RTU and VFDs. I previously did a little work with building some DMX adapters which also uses the RS485 wiring configuration, but this was going to be quite a bit more involved.

RS485 and MAX485

Starting with RS485, we first learn that this unique configuration allows for data signals to travel fairly long distances without much risk of data loss or noise. These long runs are perfect for large entertainment venues (DMX) or factories and warehouses (PLCs, VFDs, etc.).

For a great and fairly comprehensive guide on RS485, take a look here. For our setup, we will only be implementing 2-wire (half-duplex) communication. With our two wires, one wire carries the normal signal and the second wire to carry the inverted signal. These two signals can then be compared to one another to determine what is intended signal and what may have been inadvertently introduced or lost, like noise. Most common Arduino boards do not have accessible RS485 capability which  means we need to add another chip. The MAX485 is a common chip that has been around for sometime and can take a single signal, and create our two versions of it for transmission. For me, I decided to work with the MAX485 module boards instead of the chips directly as that tends to make prototyping much quicker. 

MAX485 Module

Connecting the MAX485 module to and Arduino is fairly simple and many guides exist out on the internet which are more or less the same (see image below). The big take-aways are that you use two GPIO pins on the Arduino to send and receive data, the same way serial works. The second is that you connect a third GPIO to signal the MAX485 to listen or speak (Note: this is actually two connections on the MAX485 module, but most people jumper these together with the send/receive signaling pin). This signaling GPIO pin tells the module if it should receive data or send data. 

You might be wondering why, if serial already sends and received data, why do we need an entirely separate module? This is important for a couple reasons, but primarily because the MAX485 module is half-duplex (although you could add a second MAX485 module for full-duplex configuration - also known as 4-wire). That means it can only send data OR receive data, but it can't do both at the same time. You can think of it like this: half-duplex means only one device can speak at a time. So, with regard to the module, in order for us to make sure it works as we expect, we need to tell it when to do what. So the module is kind of down-grading (in a sense) our communication, but remember, because we are using 2 wires to send the signal and the invert signal, we get much more reliability much further distances in exchange. 

The basics of wiring the Arduino Uno to the MAX485 look like this.

Basic Wiring for MAX485 and Arduino Uno

I would recommend using an Arduino with multiple UART serial ports. This allows you to continue debugging the Arduino program while it is also communicating with the MAX485 module. I have had success using SoftwareSerial, a coded implementation of the serial interface. It is slower, but it seems to work fine for this. Turns out the communication was more flaky using SoftwareSerial, and I had to switch to using an Arduino with a second dedicated Serial (I went with the Arduino Mega2560 for now -- wiring is very similar to the above image just connect the RE to RX1 and DI to TX1). Also, if you decide to connect up a different board, make sure the operating voltage of the MAX485 match the GPIO operating voltage (i.e. 5 volts).

You may have noticed that DE and RE on the module are connected together. This is because one of those is set HIGH when we want to send data and the other is set LOW when we want to receive data. This combination means that while we have the flexibility to customize our interactions further, for our usage, we don't want the board to receive data at the same time we are sending data. Connecting both pins from the MAX485 allows us to use a single GPIO on the Arduino, and just toggle it's state when we send or receive. 

You may have also seen MAX485 modules (or similar modules) that have flow control. To my understanding, flow control essentially tries to automate the toggle for you based on when data is being sent or not. This sounds great in theory and has been reported to work well with DMX, but some users have reported issues when trying to use flow control modules specifically with Modbus RTU.

Modbus RTU

Modbus is a fairly well-established protocol and has been around for sometime. By protocol, I mean it dictates what the data on a line looks like, how to read it and write it. Modbus does not actually care how it is transmitted, which is why you will see similar things like ModbusTCP, etc. With regard to Arduino, we usually don't have transport layer capabilities without adding a shield or ethernet module. In our case, this E3 VFD does not support ethernet (there are warnings in the manual about treating the RJ45 port as an ethernet port and the damage this would likely cause your other devices - DO NOT DO THIS).

As Modbus has been around for some time, there are already some great libraries that exist that abstract much of the heavy lifting of implementing Modbus properly. This include format, encoding, decoding, and CRC (error checking). I chose to use the library ModbusMaster. This library is simple to install and is supported by many Arduino boards right out of the gate.

Essentially, the program lets us communicate with a Modbus device using a Serial interface. It also allows us to easily setup callbacks to call before sending data and after we have sent it. This comes in really handy when we want to signal to the MAX485 transceiver module that it is time to send, otherwise it defaults to be receiving data.

I've posted some test code here.

You should be able to upload this code to your Arduino.

Testing Arduino Modbus RTU and MAX485 

Now with our wiring of the Arduino to the MAX485 module in place, and our Arduino Uno programmed, we can now run a test. To make testing simpler, it is helpful to have another MAX485 board connected to another Arduino, or you can also buy a TTL/RS485 cable online. The prices on these cables can vary greatly, and some include more capabilities than others to support other hardware protocols. 

A TTL/RS485 Cable

For FTDI chip cables, you may need to also install the FTDI driver like I do with DMX. With that in place, you now can connect your adapter to your computer and connect the MAX485 A to RS485A/RS485+ of the adapter and the MAX485 B to RS485B/RS485- connector. This can trip people up -- with Serial, you connect RX to TX both ways, but with RS485, you connect A to A and B to B. This is because in half-duplex communication A will always be the regular signal, and B will be the inverted signal. (If you wired them backwards on accident, it should be fine, just switch them around.) One more important thing to keep in mind is that we need to establish a common reference between the Arduino and the adapter. Connect a ground (GND) wire between them. 

It all looks good, but how do we know it is working?

A great program for Windows is called Serial Debug Assistant which you can get for free from the Microsoft Store (and with awesome upgrade options). This is a serial interface program that provides many great basic options when interacting with serial communication devices. For our tests, select the COM port of the TTL/RS485 USB adapter, set the baud rate (i.e. 115200), set the data bits (for this setup it is 8), no parity bit, and 1 stop bit. Now click Open Serial Port. If the software was able to connect successfully, you should see the button change to say Close Serial Port. I also like to set the Receive settings in Serial Debug Assistant so that the HEX display is on and Auto break frame is set to 20ms. For Send settings, check the HEX send box to send responses (more later).

My Settings in Serial Debug Assistant

A note about communication using Modbus. Often, we setup these configurations with one main controller or master (the devices asking for data from others) with one or more peripheral or slave devices (the devices returning data). The connected slave devices will only respond when asked to update something or return a value, otherwise they are quiet. Also, there is only ever 1 master. In our Arduino setup, the Arduino is the master device. For testing with the PC, the PC is a slave device. That means that the PC should only respond when requested from the Arduino.  

With a connection between Arduino and the PC setup correctly, and Serial Debug Assistant successfully connected to our USB TTL/RS485 adapter via a com port, we should now be able to see the data coming from the Arduino. It may look like this if you left the Arduino code as it was:

01 03 00 06 00 01 64 0B 

Which breaks down like this:

Modbus RTU sent message breakdown using

These are created from which has some great tools to help with this process. If you wish to return a response from Serial Debug Assistant, you can enter this and hit send:

01 03 02 00 34 B9 93

This response just returns some random data (in this case the decimal value 34).

Modbus RTU response message breakdown using

Later, we will add a lot more meaning with how we handle use this. For now, however, we just want to make sure we have data correctly moving into and out of the Arduino. 

Invertek Optidrive E3

As I have mentioned before, the RJ45 port on the front of this particular VFD is NOT an ethernet port. This port, though, gives us access to the A/B lines for RS485. I made part of an ethernet cable and left the wires on the other end exposed. I decided to align the ethernet cable according to T-568B wiring spec, but for this it doesn't really matter, just make sure your using the correct wires positions as they are described in the manual. For this project, I clipped everything that wasn't wire 3 (GND), or wires 7/8 (A/B lines). I have no desire to accidentally connect something with 24v :). 

Page 36 snippet from the Invertek Optidrive E3 Manual

The manual also will tell us how to setup the configuration for our VFD. Specifically, we need to make sure the values are setup correctly for P-36 (parameter 36). You can hold down the top center button on the VFD to enter into a settings mode, then using the arrow buttons, navigate to P-36, how click the same center button as before, it should change to show Adr 1. Clicking the same center button will let you cycle through all the settings for this parameter group. Make sure these settings match the ones from before (i.e. Baud 115200 [shown as 115.2]). The manual describes the other settings needed for this connection. 

Now let's remove the MAX485 and Arduino connection from our USB TTL/RS485 adapter and instead connect our ethernet wires up. Although slightly confusing, when the manual says RS485+, this is the same as A, and RS485- is the same as B. 

With everything connected properly (and double-checked), let's turn on the VFD and plug in the USB TTL/RS385 adapter. Open Serial Debug Assistant and make sure to connect to the adapter again with the same settings as before. 

Now in this configuration, the master device is going to be the PC and the slave device is the VFD. So we need to be first to send data to the VFD to have it respond. Let's send a request to see what the temperature of the VFD is. In the input area, enter:

01 03 00 39 00 01 04 0D

Now hit enter. If everything is working as it should, you should immediately get back a response like the one we sent out before. The data portion of the message should represent the temperature of the VFD.  

Connecting Everything Together

As you probably have guessed by now, we are going to connect the MAX485/Arduino directly to the VFD. The USB TTL/RS485 adapter won't do us much good here (unless you want to man-in-the-middle like I did), but by using the Arduino serial monitor, we can query any of the read registers on the VFD. We can also set new values for write registers. 

You should now have a working connection and communication between Arduino and the VFD. 

Hopefully you found this helpful, but feel free to ask questions. Fair warning, I do not know anything about other VFDs and would do exactly what you would (look in the manual) to try and figure it out. If you want to hire me to read your VFD manual, I suppose you could :). If there is no manual, I'm not aware of any easy shortcuts to figure out the connections. My advise would likely be to start with a multimeter and try to find voltage and ground, then operate the VFD and take measurements, maybe use an oscilloscope, and see what you can deduce. Although, it would probably be cheaper considering time/cost to just buy a VFD that you know has support for Modbus and has a good manual.

Support the Developers

If you find the free software referenced above useful, make sure you try to find ways to support those developers as that will go a long way to making sure these tools stay awesome for everyone.

Getting a TimedOut error in ModbusMaster (226)?

At first, I tried to connect everything with the baud rate 19200, and everything was working fine except that the responses back to Arduino would timeout every time. It turns out that there is a set amount of time to get a response, and if it doesn't happen quick enough, the library will timeout. You can modify the code, or in my case, I just increased the baud rate to 115200 which happens to be the default value for the VFD anyway. This change has been working well.

Flaky data transmissions? Random transmission failures?

My first attempt at this used SoftwareSerial to replicate a hardware serial with hopes that I could use an Arduino that did not have Serial1 or so on. After hooking my USB TTL/RS485 adapter into the communication between Arduino and the VFD, I found that all the values being exchanged were actually correct, but my Arduino program would randomly report bad CRC, TimedOut, or other errors. As I had already had a bit of trouble with the TimedOut error before due to timing, I determined this is likely also an issue with timing, but one I'm not sure I can code to fix. Instead of messing with all that, however, I decided to change my Arduino UNO R3 board for an Arduino Mega2560. The mega is a more capable board and possibly overkill for what I'm doing, but I had it on hand and I knew it has additional dedicated hardware Serial. After a quick update to my code (trading out SoftwareSerial for Serial1), and a switch over on wiring to use RX1/TX1 GPIO on the mega, I was up and running. The flaky communication issues from before have been resolved. 

VFD Doesn't Start / Register Values Don't Return Correctly

One thing to note is that ModbusMaster uses a zero-based addressing system for registers, but the E3 uses a 1-based addressing for registers. This means you need to subtract 1 from the register listed in the documentation to properly.

In the E3 documentation, it states:

NOTE For Master devices which use zero based addressing and therefore treat the first Register address as Register 0, it may be necessary to convert the Register Numbers detailed below by subtracting 1 to obtain the correct Register address.

Example Code:

Resources and Links: (Modbus protocol tools online) (comprehesive look at RS485 and MAX485) (Arduino Library for MAX485) (Serial Debug Assistant) (VFD Manual) (VFD Manual - Additional details, like corrected Modbus register map) (ModbusMaster timeout error) (An example of sending data to the VFD)