Project Main page 👇👇👇👇

[Active] Seven Segment Display Driver

An extensible hardware and software solution for driving a wall of seven segment displays

Spencer's Projects and WeblogSpencer Maroukis

Prototype System Overview

For the testing prototype I dropped the "daisy-chainable" modules idea since it seems like setting up the two DMA channels for full duplex send/receive (Shift-Register like), allowing us to "shift-through" data may be difficult with the low performance C0 series STM32 chips, see here. However, this is a key part of the "extensibility" goal of the project, so it will have to be revisited.

The architecture of the testing prototype is as shown:

The "Manager" is just a pin header for a micro to send the LED serial data to the Modules; a shift register (SR) is added as a GPIO expander for addressing, and since the SRs can be daisy-chained without additional MCU GPIO pins it is technically extensible.

The Modules center around a single STM32 each driving (4) x TM1637 LED drivers. Each TM1637 can drive a maximum of 6 digits, which I've utilized here by using two 3-digit displays (not shown). Thus each module controls 6*4=24 digits.

Timing

Each module will receive the serial data corresponding to the LED segments it is driving and store it using DMA into memory-mapped SRAM. Once the SPI serial data transfer is complete the module will shift out the data over I2C as required by the TM1637 driver. Note that we can send the data to the driver chips without displaying the data as there is a special display command code that we will send later once the Module receives a Display Enable command from the Manager. This allows us to send the display command to the driver chips in "faux-parallel" by interleaving the slower 250kbps I2C max speed of the TM1637 driver, resulting in all the segments updating at once (one hopes).

The timing diagram for a 24fps update rate is as shown:

For a 24Hz display refresh rate, transmitting data to each module in series can take a maximum of 42ms/N_modules or e.g. 2ms for 21 modules. Within the 2ms we just have to send the data over SPI to the STM32 Module. Here since we are not including brightness data it is just bits = (no. segments) * (no. digits) = 8 * 6 = 48 bits or 6 bytes per module. The data is stored in memory mapped SRAM and all segment data should be shifted out to the drivers after the SPI transfer from the Manager is finished. Note that the displays will not be updated at this moment, but only after the "Display Enable" pin is set will the MCU send the proper Display Update command to the LED drivers.

Each MCU module is driving 3 of the TM1637 driver chips at a max speed of 250kbps per the datasheet so it is most efficient to interleave the serial output to all three at the same time. Continuing with the rough calculation for a 21 module example above, this means we can get about 1500us with 250us of buffer on each side to fit within the 2ms period. The auto incrementing setting of the TM1637 chip auto-increments the address for each byte, so we just have to send the address corresponding to the first digit we want to update. To update 6 digits means we would send 9 bytes. The first two bytes are the write command and address bytes, the next six are the data with auto-incrementing enabled, and the last is the display command, which will update the displays with the data [[1]].

[[1]]: The MCU/module will send this display update command when the Display Enable pin is set, and all the displays should be updated nearly simultaneously

So \( (250\text{kbps}/8)^{-1}\times 9\text{ bytes} \) gives 288us to update 6 digits. The theoretical display update at this speed is about 3.5kHz. This gives the theoretical maximum size display to be

$$N_{modules,max} = \frac{3.5\text{ kHz}}{24\text{ Hz}} \approx 145\text{ modules} \\ \Rightarrow 145\times 18 \approx 2600 \text{ digits}$$

This is approximately a 50 x 50 digit wall, although this doesn't include the internal delay of the driver chip to drive the digits. Each display is about 19mm tall gives almost a meter by meter wall. Note the TM1638, which can drive up to 10 digits, can run twice as fast. Just if you were wondering 😉.

Component Cost

Component costs are shown below for the major components sourced via LCSC since that is where I could find the TM1637 the cheapest. This doesn't include discretes like resistors and capacitors or the PCB fabrication price.

PCB Layout

I added a bunch of 0.1"/2.54mm pitch header pins for testing purposes and for the main controller/Manager. In tight places I had to go down to 0.05"/1.27mm headers when I wanted to keep the test point close to the STM32 chip.

One layout mistake I made was to route power last. I started with the critical clock and data traces but then kept going and going until I finally got to power last... the increased track width forced me to move a lot of already-placed vias and continuously re-stitch power planes as I moved things around 🤦.

As always, footprint datasheets were scrutinized thrice over, but only custom footprints for the TM1637 and the Seven Segment Displays were needed (the other footprints were found in the KiCad default libraries).

• TXS1080E Level Shifter & STM32C0: TSSOP-20, Body=4.4x6.5mm, Pin Pitch=0.65mm
• TM1637: Custom, SOC-20, Body=12.6x7.5mm, Pin Width = 1.27mm; Pin Width =0.44mm
• Seven Segment Displays: Custom, pin pitch is 2.54mm apart (3 digit footprint is same as 4 digit with one pin unconnected)

Power Supply Voltage Levels

Although the red-LEDs with their ~2V voltage drop should be able to be driven by the TM1637 at a 3V3 supply, for testing purposes I added in a 5V rail via a solderable jumper. The driver voltage is set by soldering either the 5V side or the 3V3 side. Both 5V and 3V need to be provided separately via screw terminals (no converter included).

Here is the finished board without the headers soldered:

With the displays:

Prototype Schematics

Here are some schematics:

Next Up

Next up will be testing the hardware and writing the firmware for the Modules as well as looking into the Manager controller firmware (decoding GIF images/etc. and converting to the serial bit stream).

The final hardware will change depending on the timing and voltage requirements, as well as being made more modular.

A stretch goal would be to test firmware that allows for daisy-chaining the STM32 modules instead of using a SS chip select pin with the Shift Register. This would allow the system to work more like the daisy-chainable WS2811 or APA102 RGB LED driver chips.

Frustrated by learning arcane embedded-C commands with no documentation? HAL bloat got you down? Don't know how the hell STM32CubeIDE's build process works? Worry not, you can be comforted by the fact that those 10 hours debugging linker errors is 10 hours towards your 10,000 of mastery. And when you get there you won't even think, "it's not even a real clock, there's not even an RTC module" – it doesn't matter since you're a Master now.

(yes, you can even use this timer to count your hours coding in C++, nay Python, this is an Arduino project after all)

snippets/02-Arduino-ESP/Arduino-Mega/03-tm1637-counter/03-tm1637-counter.ino at main · smaroukis/snippets

Contribute to smaroukis/snippets development by creating an account on GitHub.

GitHubsmaroukis

Fun things from this project

EEPROM.write() / EEPROM.put() take ~3.4ms both for 3 bytes and a struct with those bytes. The docs mention that any EEPROM.write() will take about 3.3ms, so it's the setup and access to the ROM that busies the CPU, not necessarily how many bytes are written.

1000uF capacitor across USBVCC extended 5V—3.3V turn off time from 1.5 ms to 40ms (hopefully enough for an EEPROM.write())

Posts in this series: Phase 1 – Architecture Overview and Hardware Prototyping

Overview:

An extensible hardware and software solution for driving a wall of seven segment displays. A "display module" will consist of multiple LED driver chips each driving a maximum number of digits, commanded by a single STM32 driver MCU. A master controller decodes animated gifs and sends a serial byte command of SPI to the display modules, then sends a synchronized update command. Per-segment brightness control will be implemented in version 2.

Goals:

• lowest possible cost – a preliminary calculation is at $0.20/digit, so for a 36x36 digit display around $260
• module-based – user can string modules together to drive bigger and bigger display walls
• (stretch/v2) individual segment-level control — see why this is a v2 goal below (depends on driver chip)
• (stretch/v2) integrates with current libraries like SmartLED/FastLED

Links and Supporting Posts:
See supporting blog posts and links below. You can always drop me a line if you have comments, advice or want to collaborate.

• Detailed post on Tm1637 library and logic analyzer captures (In Progress)
• General post on multiplexing architectures (In Progress)

System Architecture

The system consists of

• Manager: The main controller that packages and sends the serial bit stream for each display frame.
• Shift Register(s): as a GPIO expander for the SPI CS pin for the modules. These aren't needed if we can daisy-chain modules together (see §Scope Creep below).
• Modules: Each has a single STM32 MCU that drives (4) x LED Drivers (TM1637). A level shifter may be included. Since each driver can drive 6 digits each module command 24 digits.
• Seven-Segment Driver chip: The TM1637 driver chip can drive up to 6 digits and is commanded by a max 250kbps I2C-esque serial signal from the MCU. A library for STM32 is readily available.

Each STM32-based module will then send out four interleaved I2C-like signals to the TM1637 display driver chips. Since each driver chip drives 6 digits each we will update all 6 digits, giving a digit refresh rate of ~290us for a 250kbps serial clock. The TM1637 modules then continuously multiplex/refresh the displays with this given data without further commands.

Since all of the driver chips are commanded at about the same time (the STM32 can easily interleave 3 bit-banged 250kbps Clock and Data lines) we should have a synchronized update across all digits.

The timing requirements are calculated based on a 24Hz refresh rate for the whole frame, giving for example a required processing period of a module of 2ms for a 24Hz refresh rate.

1/24Hz ~= 42ms → 42ms/20modules ~= 2ms/module.

Each module must take in the SPI data, update its internal memory mapped registers that hold the status of the display segments (or an internal array), and then wait for the command to send the data out to the TM1637 driver. In reality below only during the last module period will this command be sent since only at this time will all of the modules have their data.

Note that the limiting factor is how fast the TM1637 serial clock runs that updates the individual digits, which in this case with some buffer time is calculated around 288us for updating all 6 digits at 250kbps.[[1]]

Future / Scope Creep

Daisy chaining SPI (🔧)

The daisy-chained SPI configuration is on hold until I get further into the firmware capabilities of the STM32C0 series chip. Apparently implementing a full-duplex SPI peripheral is not trivial (issues with the SPI peripheral timing using a shared Tx/Rx buffer), although if the delays are deterministic and accounted for it shouldn't matter if it isn't truly fully duplex as long as the time delays aren't so large that they affect larger displays.

Inspired By

The DigitGrid

The DigitGrid is a new type of display. Typically used to display numbers, seven segment displays have been around in various forms for over 100 years. The t…

Movie-Style Hacking With A Wall Of Glowing Hex

Over the years, the media has managed to throw together some pretty ridiculous visual depictions of computer hacking. But perhaps none have gone as far down the road of obfuscation as The Matrix, w…

HackadayTom Nardi

[[1]]: Note that the limiting factor is how fast the TM1637 serial clock runs that updates the individual digits, which in this case with some buffer time is calculated around 288us for updating all 6 digits at 250kbps.

Overview

After being inspired by various USB cable testers, I decided to build my own to get familiar with STM32, KiCad and the USB-C standard. Mostly it was a hardware fork of this hackaday project that had a schematic but no firmware.

The device has some benefits over a simple continuity tester:

• displays the as-plugged orientation of the 4 different possibilities of the USB-C to C cable
• detects pullup and pulldown resistors on the CC lines as required by the USB standard for legacy cables
• identifies active cable with E marker (via the pulldown resistor present on VCONN)
• doesn't apply a +V to the Ground line/pin, instead it uses a MCU to test the presence of a connected ground wire
• exposes various pins to test cable and internal resistors manually with a DMM

I went through JLCPCB to manufacture the boards, choosing parts from their library coming from LCSC. The C code uses the STM32 HAL libraries, a further improvement would be to port this to lower level and publish a CMake file so that it is less reliant on the STM32CubeIDE.

Detailed documentation, firmware, and KiCad files are in the README on github. This blog post will describe more of my learnings and gotchas than the technical details of the project.

usb-sleuth/README.md at main · smaroukis/usb-sleuth

USB cable continuity tester ++. Contribute to smaroukis/usb-sleuth development by creating an account on GitHub.

GitHubsmaroukis

Interesting Tidbits

Analog vs digital read on cable internal resistors: A USB A to C cable will have a 56K internal pullup from the CC pin to VBUS (since in the USB-C standard the CC pin on the host side should be pulled up to identify as a host, but of course the USB-A side doesn't have the CC pin, so it must be pulled up in the cable itself).

We test this as in the following schematic by pulling the B-side CC control pin, BCC1_CTRL , to 0V through a 1oK resistor and measuring the voltage at the divider point, BCC1_Sense. Note here we can't use a digital read.

In the USB B-to-C case, the B side is pulled down to GND pin with a 5.1K resistor. To test, instead of pulling BCC1_CTRL to 0V, we pull ACC1 high through an internal pullup. Since the internal pullup is ~50K, about 10 times weaker than the 5.1K pulldown, we can use a digital read (==LOW) to check if the pulldown is present.

This is also documented in the README.

Key Learnings:

1. Custom footprints and multi-unit symbols: Custom footprints are a pain at first, but better to pull that tooth out sooner than later (or end up with a misaligned part); multi unit symbols are a cool feature to make it easy to draw a 4 pole DIP switch as separate switches in the schematic but link to a single component.
2. Double check minimum clearances before routing traces: I had my minimum via size wrong from the start, which required a rework of all the traces off of the USB-C ports.
3. USB cable standards and pullup/pulldown resistor configurations: A-to-C will have a 56K pullup, B-to-C will have a 5K1 pulldown, and an active C-to-C cable will have a ~1K pulldown.
4. Existence of ESD diodes on MCU GPIO pins: I added an isolation switch to use during DMM testing of the resistor values, to avoid a path through ESD diodes on the GPIO pins causing bad readings. Once receiving the boards, the switch positions didn't have an impact on the measurements, so they could be removed in future hardware versions.
5. Generating correct BOM and gerber files: In KiCad for JLCPCB, I used the Fabrication Toolkit plugin, edited a bit of the python file, and used the DNP field of the KiCad schematic viewer to mark hand placed components which would be excluded from the auto generated BOM.
6. Using commodity parts with JLCPCB/fab houses: Once I found out how to search for them using JLCPCB/LCSC's abysmal parameter search, I tried to use commodity ("basic") parts since reels of these are already loaded on the pick 'n place machine; for each "extended" part number you pay a loading fee of $3 → this fee can be avoided for things like resistors, capacitors and LEDs but not for parts like USB receptacles or resistor arrays.

More Specific Learnings

• JLCPCB viewer doesn't have the correct orientation of the components - they will rotate them correctly on their side (but I paid an extra dollar or two for the final production file to be sent for my approval)
• I had a lot of back and forth between JLCPCB engineers about my pads sticking outside of the board edge layer – which I designed that way just to be clipped by the board edge layer.
• Renaming files and folders in the KiCad project is a bit of a workaround – for example when I wanted to rename the directory with the custom footprints, the easiest way is to rename the file itself and then use e.g. VSCode to "find/replace" all occurrences of the footprint path.

Scope Creep

• differential pairs and the drain wire in USB 3.0 (the drain wire is a return signal for any unbalance in the differential signal, and as a heavier conductor to ground the thin shield to divert large EMI spikes to ground)
• taller SMD capacitors (vs resistors) requires a wider pad in order to get a solder fillet all the way to the top of component (and avoid tombstoning)
• multi unit symbols in KiCad - useful for the creating 4 individual schematic switches for the 4 pole DIP switch.

Project Timeline Highlights:

• Feb 3: Published Hackaday.io project and was featured on Hackaday.com
• Jan 27: STM32 HAL code finished and all tests working. Rev 1 complete 🥳
• Jan 17: Testing and porting Arduino code to STM32 HAL C.
• Jan 3: Boards delivered.
• December 21: Back and forth with JLCPCB about pads extending beyond the board edge resolved.
• December 18: Sent the project for production.
• December 15: BOM generation using Fabrication Outputs plugin.
• December 13: USB port custom footprint edits, footprint calculator, and final edits.
• December 11: Second day of routing, with challenges in USB-C routing.
• December 8: PCB layout updates and considerations for taller SMD capacitors.
• December 5: Investigation of ESD diodes and DMM current injection paths for Ra/Rd/Rp.
• November 27: Hardware test for CC orientation, pull-down/up.
• November 17: Continued layout with logic for testing, wired up to Arduino.
• November 10: Bought USB-C and USB-A breakout board for testing.
• November 9: Research on USB pinouts, grounding, and differential signals.

Three tests were performed:

1. UBlox LEA-6H module vs. Notecarrier-Pi with Active Antenna
2. UBlox LEA-6H module vs. Notecarrier-A-v1.7 with on-board GPS Chip Antenna
3. UBlox LEA-6H module vs. Notecarrier-A-v2.0 with on-board GPS Chip Antenna

Analysis was done using the standard pandas, numpy, and matplotlib python libraries.

Generally the Ublox LEA-6H module

• dropped less samples ✅
• got a fix on more satellites ✅
• was less precise / had a lot more jitter in the lat/long ❌ (sometimes on the order of 100m) - note though that I wasn’t applying any filters to the data
• seemed more affected by worse weather or less-than-ideal placement inside. ❌

The Notecarrier modules

• have much more “precision” (it probably does its own filtering and also might be using assisted GPS with the cell tower reads as well) ✅
• was less affected by worse weather or indoor placement ✅
• got a fix on less satellites at ❌
• dropped more samples ❌

The old notecarrier with gps chip antenna (v1.7) and the notecarrier-pi with the active antenna were about the same, but the notecarrier-a v2.0 showed a big increase in precision.

Note that below we go from a span of 4-10 meter errors to 0.85 to 1.10 meter errors. The LEA-6H histogram is not shown since it was ranging between 1 and 100 m.

Improvement in Precision on Notecard Versions

Notecarrier Pi with Active antenna:

Notearrier A v2.0

Notecard Signal Dropped Comparison

Note we can’t really compare these because they were taken on different days, but look how the Notecarrier v2.0 drops less data samples.

Further

• Test cold start time-to-fix
• Add in bearing to get the directional skew (i.e. vectorize the error)

Appendix - Full Data

LEA-6H vs Notecarrier-Pi w/ Active Antenna

The error distance was calculated based on the distance from a “true” point picked on google maps, so at the <5m distance the “true” value may have been wrong.

The Notecard gps was much more precise with a smaller spread around the center. There is likely some filtering / averaging going on at the notecard level or they are using assisted GPS with the cellular tower data.

Summary for LEA:
Rows:  8639
Error Uptime (): 100.000000% (8639/8639)
Satellites Uptime (): 100.0% (8639/8639)
Summary for Notecard:
Rows:  8639
Error Uptime (): 97.789096% (8448/8639)
Satellites Uptime (): 100.0% (8639/8639)

Error/Distance Comparison

Uptime

Here we plot the same graph as above (error), but showing “null” values as zero. We see the Notecarrier-Pi drops a lot more data. The bottom plot is the “signal” value that the notecard reports, we can see some of the signal values drop to zero for the notecard, even when the Ublox module has a fix.

Number of Satellites

Ublox module had more satellites more often (average of ~12 versus ~8 for the Notecard with active antenna)

LEA-6H vs Notecarrier-A-v1.7 w/ GPS Chip Antenna

Note that this test was done at a different location than the previous test.

Summary for LEA:
Rows:  8639
Error Uptime (): 100.000000% (8639/8639)
Satellites Uptime (): 100.0% (8639/8639)
Summary for Notecard:
Rows:  8639
Error Uptime (): 86.595671% (7481/8639)
Satellites Uptime (): 100.0% (8639/8639)

Error/Distance Comparison

Uptime

Here we plot the same graph, but showing “null” values as zero. We see the Notecarrier-Pi drops a lot more data.

Summary:

• LEA-6H Error Uptime: 100% (8639/8639)
• Notecarrier-A-v1.7 Error Uptime: 86.595671% (7481/8639) i.e. ~1000 dropped datapoints

Number of Satellites

Same as before, Notecarrier gets a fix on less satellites

LEA-6H vs. Notecarrier-A-v2.0 w/ GPS Chip Antenna

Summary for LEA:
Rows:  8638
Error Uptime (): 99.120167% (8562/8638)
Satellites Uptime (): 99.12016670525584% (8562/8638)

Summary for Notecard:
Rows:  8639
Error Uptime (): 94.281746% (8145/8639)
Satellites Uptime (): 100.0% (8639/8639)

Error/Distance Comparison

The updated v2.0 notecarrier is very precise, so much that you can barely see its range of values when plotted on top of the Ublox module.

Zooming in on the “error” of the Notecarrier A v2.0 shows that its precise within 0.9 to 1.1 meters for all ~8k samples

Uptime

We still want to see the signal uptime for the notecard, which is also improved (less datapoints at 0dB SNR for the bottom plot).

Satellites

The Notecarrier is still only looking at between 3-9 satellites on average.

Time series:

The project demonstrares real time plotting of sensor data using MQTT. A Rasperry Pi functions as a MQTT broker listening to a specified topic, and the concurrent (using threads) python code logs incoming data to a csv file and concurrently plots the data in real time with matplotlib.

All the code and examples are at smaroukis/realtime-plotter.

Scope:

• Setting up a mosquitto MQTT broker on the RasPi
• Creating a Plotter wrapper class for the matplotlib animatefunc function
• edge device code in C++/Arduino on an ESP32 to take sensor readings and send as MQTT messages to the broker
• Python code to handle multiple concurrent processes using the threading library, as well as using the matplotlib funcanimate function to update a plot on the fly
• Concurrently saves the data in csv or json to the disk

Demo video using a temperature sensor and covering it with my finger to affect the reading:

Readme Description

Real time data logging to csv and concurrent plotting with matplotlib, creating an mqtt client to listen to the specified topic on a specified mqtt broker/host.

Logger is under raspi/app_logger/app.py. For example:

python raspi/app_logger/app.py -t # -d -h 192.168.0.17 -g 

i.e. "all topics ("#"), for mqtt broker on host 192.168.0.17, include plotting (-g)

Seperate threads and callbacks are made for plotting and writing to the datafile

• log_worker empties the data-to-log queue every 2 seconds
• plotter.update is the matplotlib.animate.funcanimation function that updates the graph every provided interval (also has a queue to process data)

Esp32 code for sensor and mqtt client/publishing is also included.

Setting Up the ESP32 sensor

A BME temperature sensor is used over Two-Wire/I2C.

Setting up the RasPi/MQTT Broker

On local machine:

# use SSH from a terminal to get into the Pi server
ssh pi@raspberrypi.local 
# ... enter user/pass ...

In a server terminal (or after SSHing in):

# print IP address (should match the one in `secrets.h`)
hostname -I 
# ...
# check the `mosquitto` status:
systemctl status mosquitto.service 
# ... if status is running try:
mosquitto_pub -d -t inTopic -m "ON" 
# which should turn the builtin on the ESP32 ON if it is OFF

If necessary restart the mosquitto service with
sudo systemctl restart mosquitto

If we want to see the outTopic responses from the ESP32 we can open up another terminal on the MQTT broker and subscripe to this topic e.g.
mosquitto_sub -d -t outTopic
Or to subscribe to all topics do:
mosquitto_sub -d -t "#"

Notes/Gotchas

• the mosquitto broker has to be configured to accept anonymous connections (disabled by default)
• put the ESP32 in "flash" mode by (1) pressing and holding BOOT (2) pressing and releasing ENABLE (3) releasing BOOT

Code Description - ESP32

Overview:

• publishes values to topic as e.g. GATEWAY_ID/DEVICE_ID/temperature/32.0
• was implemented using C style strings, should probably be refactored to smart pointers and std library strings
• currently implemented publishing from a bme280 temperature and humidity sensor (via Adafruit libary)

mqttHelper

Establishes a connection to an MQTT broker, subscribes to specific topics, and publishes sensor data to MQTT topics. including potential buffer overflow issues when dealing with large float values, minimal error handling, and limited documentation. Additionally, it lacks configurability for MQTT client parameters, making it less flexible for different MQTT broker setups

Need to add more error handling and confirugability for different MQTT client parameters (e.g. name, etc).

wifiHelper

Sets up wifi with the WiFi.h library.

I've worked on a couple projects creating electrical schematics for campervans. Using AutoCAD Electrical I created professional-grade schematics detailing the installation (done by yours truly) and protection schemes of the system.

Here are parts of various AutoCAD Electrical diagrams I created as part of these projects.

See https://van.maroukis.net/06-electrical-systems for system diagrams, also included here

Example 12V Distribution: https://van.maroukis.net/img/screen-12v.png

Example Main Battery Compartment: https://van.maroukis.net/img/screen-main-bat.png

Example AC system: https://van.maroukis.net/img/screen-ac.png

Example Battery Display and Protective Relay Wiring: https://van.maroukis.net/img/screen-bmv.png

Over two years my partner and I took a bare metal cargo van and converted it to an off-grid camper van including running water, an indoor shower, a skylight, solar powered induction cooktop, engine-heated hot water, and more.

Of note was the focus on going propane-less by using the engine coolant as a hot water heater and installing 600W of solar on the roof with 380Ah of Litihum Iron Phosphate batteries to power an induction stove.

A full project website has been built to share the work and help other builders out there:

Off-Grid Van Conversion –

An off-grid campervan with a Japanese-farmhouse aeshtetic.

This post details the engineering procedure of designing, developing a test program, and commissioning a temporary, 12kV-connected microgrid to support transmission work or a substation replacement.

The necessity of the a temporary microgrid comes from maintenance or emergencies in the electric grid system that renders a substation unable to provide power to the area. This could be due to transmission line work on a sparsely-connected grid system or due to emergency failure of substation equipment.

The project has a few main steps

1. Look for alternative solutions to temporary generators– can the load be supported by other distribution backties in the area? What if we just did the work during the night during low loads? Many times it is historical evidence that provides the justification – "we tried to offload the substation to the local network but we received many voltage complaints from customers". The power flow simulation software can only do so much and power engineers should lean on the side of safety and avoid pushing the system to its limits, especially for untried situations.
2. Feeder load calculations for the substation offload – to determine the amount of generation we need to procure, we look at historical loads for the area around this same season and take into account any system abnormalities, weather, or other reasons that the load might be different in the future. We also take into account minimum load requirements, reactive power flow, and the three-phase load balance of the system.

The generators also need a minimum amount of load to prevent "wetstacking". For example, the total minimum load should be greater than 30% of the total rated nameplate.

Also further de-rating of the generator is required if a majority of the load is single phase, which often happens in the same areas that have weak backties and require this type of work.

In addition to current, we must also take into account the power factor and VARs on the system. Typically diesel generators don't run too well supplying power to capacitive loads (leading power factor) and a "maximum reverse kVAR" will be supplied by the manufacturer.

3. Fault calculations and revised system settings – since we will be disconnected from the transmission system, our fault duty will be reduced. We have to look at the data sheet of the generators and see how much fault current they will contribute to a bolted fault. We model this in our power flow simulation software to see what the minimum fault current seen down the line and have to check that our protective equipment will trip for this amount of current.

Generator specs: The generator used was a 480V 4-pole 60 Hz generator is powered by a Cummins diesel prime mover. The three-phase synchronous generator has a separately excited permanent magnetic generator for field excitation. The generator is stepped up to the distribution "primary" voltage by appropriate step up transformers.

4. Single Line Diagram creation – Once the number and size of generators is chosen, a schematic is created to show the connection to the existing system

5. Test Program – one of the most critical points is writing a test program for the operators to execute that makes sure the temporary generator(s) are safely connected and disconnected from the grid. This involves detailed steps on open/close/test operations for the field personnel. The test program will depend on whether the generators are synchronizing into the existing distribution system or supplying an islanded system.
6. Construction – construction should be verified to align with the schematic. An important consideration is the grounding scheme, since many times there may not be a substation grounding grid to tie into, and a new multi-point grounding grid should be created that can handle the fault duty. Soil tests should be performed to make sure the resistance is adequately low enough to provide a good fault path.

7. Commissioning and Operations - once the site is constructed and the test program is approved, ideally the engineer who designed the program will be on-site for the commissioning. I was lucky enough to have this opportunity a few times, and typically I would monitor the loads and voltages to make sure they were in line with what I had calculated for that hour of the day. It's a good idea to check the loads and voltages during peak to make sure the voltage regulator on the generator is working properly.