Shared Projects by dewhisna

V2 Update to the Original I2C Character Display CPU Board. Identical to the I2C Character Display CPU V2 but with a reversed connector for the display. This is designed for OLED display modules that generally have their connector on the top edge of the PCB, whereas the original non-reversed version is for the ones with the connector on the side edge of the PCB. Otherwise, the two circuits are identical.

See the new I2C Character Display V3 board for a version with a higher powered MCU and better overall performance.

V2 Update to the Original I2C Character Display CPU Board. This board goes inline between a host CPU and an OLED (or similar) I2C/SPI graphical display. Its purpose is to convert the graphical display into a character-based display, removing the overhead of font rendering and pixel transfer over the slow I2C bus from the host.

Note that the CPU here is the ATmega328PB (PB version) with dual I2C ports. 12 MHz was chosen for the ceramic resonator, instead of 16MHz or 20 MHz, so that it will run at 3.3v within the specs given in the datasheet. You may, however, be able to overclock it successfully, especially if running at 5v. Be careful, however, of OLED displays with very noisy voltage inverters, as they will interfere with CPU overclocking. I managed to brick two ATmega328PB CPUs trying to run one with this board at 20MHz. 16MHz, however, was no problem.

An identical board with a reversed display connector is also available.

V2 Additions/Changes:

• Support for SPI communications with the display in addition to I2C

• Support for CPU Driven Reset Line to the display

• Support for either display driven or CPU driven I2C address (DC pin) option

• Ferrite bead on display power to reduce noise from the display’s power inverter

See also the Updated V2 version of this board which provides SPI display mode support as well.

Identical to the I2C Character Display CPU V1 but with a reversed connector for the display. This is designed for OLED display modules that generally have their connector on the top edge of the PCB, whereas the original non-reversed version is for the ones with the connector on the side edge of the PCB. Otherwise, the two circuits are identical.

This is the User-Interface board for the FPGA DRSSTC Interrupter V2. It provides the potentiometer and keypad inputs, plus adds status lights, etc. This method was easier to manage than the individual dangling components in the first version.

WARNING: This board has a lot of errata to contend with. While it can be made to work, it requires a lot of cutting, hacking, and part substitution to function correctly. Unless you have a pressing need to experiment with this board, I suggest waiting for V2.1.

Upgraded version (and intended replacement) of the original FPGA DRSSTC Interrupter V1. This version adds a VS1053 DSP coprocessor and switches from using a NetduinoPlus2 MCU board to a STM32F446RE Nucleo MCU board.

The FPGA logic has been changed to drop from 256 simultaneous notes per channel (which was insane) to a more realistic 64. And it enables Pulse Interleave Method in addition to the original Pin Pulse Method of 1-Bit digital audio synthesis. While still in the experimental phase, it’s hoped that the DSP addition will also allow for a direct audio drive mechanism by converting from PCM to Pulse Density to a variation of the Pulse Interleave Method to drive the coils.

This board is designed to be used with the FPGA DRSSTC Interrupter User Interface Board, or a custom variation of it.

Note: When using this board with a STM32F4 or similar host CPU, as with the intended STM32F446RE Nucleo host board, do not populate R111, R112, R113, Q101, and Q102. Those components allow a mechanism of USB renumeration which isn’t needed on the STM32F4xx, etc., that have USB-OTG support. They were placed in the design for doing experimentation with other STM32 variants that require it, like the STM32F103RB Nucleo board.

It’s also not necessary to populate any of the optional VS1053B flash boot components (U202, C203, J204, R215, R216, D201, and D202), outlined by the box on the silkscreen, since the VS1053B can be booted directly from the STM32. They were placed in the design in case there was a need/desire to experiment with that option.

Also, note that the connectors for the Nucleo board are 40-pin and not 38-pin. This was done because the 40-pin connectors are more readily available, since they are used on the RPi and such, plus the connectors for the Numato FPGA board are also 40-pin. So, instead of sourcing two different connectors, the PCB was designed to use 40-pin connectors for everything and just leave the extra two pins on each Nucleo connector unused. Just be sure to plug the Nucleo into the correct pins, as is noted on the PCB by the square pad for the Nucleo’s pin one location.

ERRATA: Since both the Spartan 6 FPGA board and the on-board VS1053B DSP share the same SPI port, it’s necessary for the U302 buffer chip for the MISO line to provide a bi-directional or at least tri-state mechanism. However, this was overlooked when porting from the original FDRSSTC-V1 design. In that original design, the 74LVC1T45GW125 chip with a fixed direction mode was sufficient as the FPGA was the only device on the bus. But not on this board.

Fortunately, there’s a fairly easy workaround by using a TXB0101DCKTG4 chip in place of the 74LVC1T45GW125 for U302. The TXB0101DCKTG4 is an auto-switching bi-directional level-shifting buffer and the pinout is nearly identical. Unfortunately, pin 5 needs to be tied to +3.3V instead of ground, as that pin is an enable signal on the TXB0101DCKTG4 instead of a direction control signal as it was on the 74LVC1T45GW125.

Before soldering the TXB0101DCKTG4 on, it’s necessary to cut the ground trace underneath U302 that goes between pins 2 and 5. And to also cut it where it exits at pin 5 and ties to the rest of the ground plane. This will disconnect pin 5 from ground. Then, when soldering the chip on, intentionally short pins 5 and 6 together, which will supply the necessary +3.3V. Technically, it should be tied to pin 1, since it’s referenced to VCCA (the STM32 side) instead of VCCB (the FPGA side). This means the FPGA has to run at 3.3V for its I/O lines, but that’s its default configuration and generally works best anyway.

The above fix has been tested and works. However, one caveat is that it’s necessary for the STM32 firmware to wait until after the FPGA has finished booting before communicating with and initializing the VS1053B DSP. This takes about 5 seconds, which was needed anyway before talking to the FPGA. So the only difference is that the VS1053B initialization can’t happen during that 5 second window. However, the VS1053B boot, even when loading plugin code, is quite fast and so this change is hardly noticeable.

A potential alternative workaround is to leave the 74LVC1T45GW125 and do the same cutting of the traces going to pin 5 and then tie pin 5 to the FPGA_CS_N line of pin 3 on U304, which is the SPI chip select for the FPGA. This will make the MISO an output from the FPGA to the STM32 when communicating with the FPGA, but otherwise leave it as an input when communicating with other devices, like the VS1053B. This variant, however, requires much more complicated surgery, as soldering a jumper to a small TSSOP6 pin is much more difficult than just doing a solder blob to an adjacent pin, and so I’ve only tested and used the TXB0101DCKTG4 workaround.

With the TXB0101DCKTG4 workaround, I was concerned that the pullup in the STM32 on that MISO pin would have to be disabled, which I think is possible to do, but it seems to be working just fine as-is with them enabled, and that is the default in the PlatformIO STSTM32 Framework I’m using.

Another “errata” is in the adjustment of the LiPo battery low-voltage detection circuit. While the circuit itself is working just fine, the design makes it nearly impossible to calibrate the trigger voltage. This is because the pot to adjust it is located underneath the Nucleo board.

Originally, the design was using the LiPo’s voltage to drive the low-voltage LED, which would have worked just fine, as you could power the LiPo input via a bench supply and adjust things without the Nucleo board installed by using the LED on the UI board.

However, due to running short on pins to the UI board in the effort to make them use the very common 10-pin IDC connectors and to do the pin assignments in such a way as to prevent a melt-down if the connectors were swapped or plugged backwards, the low-voltage LED circuit on the UI board was changed to just use the +3.3V supply. That would have been OK, except that the voltage regulators are all on the Nucleo board, so the low-voltage LED doesn’t work unless the board is plugged in, but if it’s plugged in, you can’t get to the pot to adjust the low-voltage trigger point.

And worse, there’s no testpoint pin to use to adjust it without the LED and even if you solder a testpoint pin, which should go on the collector (pin 3) of Q401, it’s difficult to adjust because you don’t know the exact trigger voltage of Q403 – meaning you have to guess at what voltage to use for the adjustment.

But if you do add a testpoint, it is possible to use a volt meter to set it and get it close to the desired trigger point. An alternative would be to use an external +3.3V regulator to provide power to the correct +3.3V pin on the Nucleo connector (left-16) and use the UI board with the low-voltage LED as designed.

During experimenting, it was found that a resistance of around 168-ohms on the pot set the trigger to about 7.4v, which was a touch on the high-side. And 310-ohms set it to about 6.9v, which is much more reasonable. The trigger point occurred when the aforementioned testpoint location had about 100mV relative to ground. So, if you add a testpoint pin, you can set it using a bench supply in place of the battery and adjusting the power supply to the desired trigger voltage and adjusting the pot until you read about 100mV on that testpoint.

Another annoying quirk on this board is that the two 10-pin connectors on the UI board should have been rotated 180-degrees. Since the connectors on the UI board are always facing the connectors on the main board in normal installation scenarios, this means that the 180-degree twist currently has to happen in the cables, which is annoying. The “twist” should have been put in the orientation of the connectors on the UI board, but this was overlooked.

The worst errata, however, is in the entire Fiber Optic output circuit and associated headphone monitoring jack. This part of the circuit turned into a colossal disaster. The “big surprise” was just how much difference there is between using MOSFETs and BJTs on those outputs. Yes, a MOSFET is a voltage based switch and a BJT is a current based switch, but I didn’t realize that the internal diode of the MOSFET would affect things as much as it did.

As designed, with the MOSFETs, the audio on the headphone monitoring jack is extremely distorted and the output to the fiber optics is way over driven. This isn’t going to work well with the Tesla Coil at all and sounds horrible when monitoring. And unfortunately, this is where the errata gets extremely difficult to deal with, as current-limiting resistors need to be inserted in the connections to the transistor bases. The easiest way to “fix” things would be to just not populate any of the output circuitry on this board and hand-wire a replacement board for it with BJT transistors and wire it in place of the onboard circuitry.

But, to keep with the circuitry onboard, Q301, Q302, Q304, and Q305 need to be replaced with BC847 NPN transistors. R302 and R309 on Q301 and Q304 should be changed from 1M down to 10K. Additional 10K resistors should be added between the base and emitter on Q302 and Q305. The traces from D301/D302 and D304/D305 to those transistors need to be completely cut and the bases on Q302 and Q305 isolated from the Q301 and Q304 bases. Four 1K resistors should added, one per transistor, and inserted between the transistor and the D301/D302 and D304/D305 outputs (i.e. their cathodes).

C318 and C320 should have 10uF capacitors, not the 10nF as labeled. And since the audio output drive is unipolar instead of bipolar, a voltage divider needs to be inserted on the collectors of PNP transistors Q303 and Q306. The easiest way to do this divider, given the PCB layout, is to hijack the high-frequency filters of R305/C317 and R312/C319, by replacing C317 and C319 with 0-Ohm resistors, allowing R305 and R312 (one on the left channel and one on the right) to become the bottom half of the voltage divider for the corresponding channel. Then cut the traces from the collectors of Q303 and Q306 and insert 220-Ohm resistors. This will form a voltage divider of 220-Ohms and 22-Ohms and gives a decent signal level for the output. It’s intentionally slightly low for a headphone output and slightly high for a line-out. However, it’s loud enough for normal monitoring purposes with headphones. And, it’s low enough to still be connected to a line-in on a recording device, and so is a good compromise.

This surgery can all be done onboard, but it’s a bit tricky. 0603 size parts work best for the 1K and 10K resistors into Q301 and Q304. The other resistor insertions can all be 0805 parts. A Dremel works well for cutting the necessary traces and a fiberglass pen works well for removing solder mask to create solder pads for the new components. And you can use wire-wrap wire for the necessary jumpers.

It’s quite a mess, though, and takes about a fourth the time to complete as soldering together this entire PCB itself. If starting from scratch, just putting the output circuit parts on a separate prototype board and wiring it in would certainly be quicker. But waiting for V2.1 of this board is the best bet, unless you are anxious to experiment now. I’m planning to look at adding a headphone amplifier circuit on V2.1 and completely reworking this part to address these issues.