Adding a fan to improve air circulation in this filament drier is a common mod. Here is my variation.
The first step is to source a voltage for the fan. The PCB already has unpopulated locations for fan components. I added a connector, diode D2 and a 30V n-channel Mosfet Q1. The gate of Q1 is connected to pin 16 of the MCU. This means the fan will come on when the LCD backlight is on.
I fixed a 4010 24V fan behind the display with hot glue and cut a small opening in the hot plate to let the air circulate. I also wired up an MP1584 buck converter module to allow control of the fan voltage, speed and noise.
And here are the temperature profiles inside the unit measured at the top of a roll of filament. The first run is with the fan set to 12V. The second with no fan.
I have a wireless switch with a key fob style remote control. It works fine but the use of a toggle switch has been mandated 😉
First task is to reverse engineer the remote control. It uses the common EV1527 encoder chip and relies on the data pins’ internal pulldowns to sink current when a button is pressed. This turns on the PNP transistor and powers on the chip.
The device operates off two coin cell batteries and I wanted to keep the device low power. The modified circuit for toggled operation is below:
As shown C101 will charge to +6V. When toggled, Q101 will turn on followed by Q102. C101 will discharge via R102 so after a delay Q101 and Q102 will turn off. Q102 is connected across the push button contacts so this will mimic a short button press. At the same time C102 is being charged ready for the next toggle.
I made up the circuit on some copper clad board and wired it up to the toggle switch
Followed by some Kapton tape and hot glue sandwich to give a compact result:
I needed to connect some more test equipment to my LAN. Currently this is done with individual Serial-to-Ethernet adapters in takeaway curry containers but this was getting ungainly and wasteful of internet ports.
Commercial 8-port RS232 to ethernet devices are available, but expensive, so time to DIY! I had a teensy 4.1 on hand and this looked like a good contender with in-built ethernet PHY, eight hardware serial ports and an Arduino compatible software stack (Teensyduino). It just needs an external Ethernet jack with magnetics (from PJRC) and eight RS232 DB9 connectors with MAX3232 level shifters (£1 each from from china).
The level shifters typically come with just TX and RX pins connected. They can be easily hacked to add CTS/RTS support. Just connect CTS (pin 7 on the DB9) to pin 8 of the MAX3232 and RTS (DB9 pin 8) to MAX3232 pin 7. Logic level CTS/RTS are then available on IC pins 9/10 respectively. Here are some pics of the mods I made:
For software we need 8 TCP listeners each listening to a different port at the same IP address. I had trouble getting the NativeEthernet library to reliably support 8 connections but the QNEthernet library worked fine.
The algorithm just loops around each TCP port, and if there are any incoming bytes available reads them and forwards them to the corresponding serial port. And vice versa.
There is also an embedded webserver that allows configuration of the networking and serial port parameters.
Here is the teensy being tested with each serial port looped back to itself. Grounding the green wire reboots the board in webserver mode where device settings can be configured.
Next a 3D printed case was designed in Fusion 360
Here is the bottom section with 4 serial ports installed. A few dabs of hot glue can be used if needed to keep things in place. If you only need 4 ports then the top can be fixed at this point.
Here showing the middle 3D printed layer in place with the top 4 serial ports. A small tactile switch to enable config mode has been glued in. At this point all RX/TX pairs are looped back for testing.
And finally the top is added and all three layers sandwiched with 53mm M3 machine screws.
Now off to rip out the takeaway containers and tidy up the wiring!
A New Home Model 1585 was stuck in reverse. Can we fix it?
First step is to remove the front cover.
Pull off the knobs, remembering their position (there are some index holes if you forget)
The lump of metal indicated was the problem. It was not retracting when the reversing lever was released. Some cleaning and light oiling helped but the final solution was to slightly loosen the screw marked in red.
This Leitch studio clock is designed to work with a timecode signal for best accuracy. Timecode generators are expensive so I built one with an ESP32 dev board.
SMPTE/EBU description here and the bit format of timecode here
The timecode signal is a stream of digital data, 80 bits for each frame of data. In Europe there are 25 frames per sec (EBU) and in the US 30 (SMPTE). Each bit is encoded in Manchester style, with a signal inversion at the start of each bit period and a further inversion halfway though the bit if it’s a “1”.
Here is a snapshot of the generated EBU waveform representing 010000001111
For the software we just need an accurate source of time and accurate pulse generation.
Time is obtained from the internet NTP server using the ESP32 Arduino library to keep the ESP32 local time in sync with NTP and to handle GMT/DST issues.
A hardware timer is set to fire every 250uS (for EBU) to output start bit and mid bit transitions. When all 80 bits have been sent the frame counter is incremented. When all frames have been sent the whole data packet is updated with the current time and the process repeats.
Rather than using a separate enclosure I fixed the ESP32 module inside the case. A source of 5V power is available on the main PCB and there is a spare selector switch available for entering configuration mode. The timecode signal output is wired directly to the input of the clock. If needed this can be daisy chained to other clocks.
Here is a video of the modified clock powering up. There is a short delay while connecting to WiFi and getting the time. Once the timecode data starts, the clock registers all hands to the 12 o’clock position, moves them to the correct time and then maintains time in sync with the timecode data.
This sign is programmable via RS485 (the orange connector) but uses proprietary hardware and software so is ripe for reverse engineering. The 8 pin ribbon cable to the display board suggests a serial protocol and probing with an oscilloscope showed 0-5V digital signals. Time to attach a logic analyser.
Here is the overview on start-up:
This looks like some initialisation data and then regular data transmission every second. There is a 100Hz pulse train on pin8 (heartbeat from the display?) and a delayed pulse on pin6 about 15ms after each data transmission
Here is a zoomed-in trace for one of the data transmissions:
So definitely SPI style with a rising edge 2.4 MHz clock on pin5 and data on pin4. By default, the display powers on with the top-left led lit. The ’80’ byte in the first set of data suggests the data is being sent left-to-right, top-to-bottom, MSB first. The pixel data is gated by pin3 (active low). Each row of display data is preceded by a header, ‘3E’ for the first row and ‘BE’ for the second. Header data is gated by pin2 (Active High). Some further experiments showed that pin7 accepts an analog voltage to set the display brightness (0-5V).
In summary the function of the connector pins is:
HEADER_SEL (Active high)
PIXEL_SEL (Active low)
DATA (Idle high)
CLK (Idle high, rising edge, 2.4MHz)
EOT (End of data transmission)
BRIGHTNESS (analog 0=on 3V = off)
HEARTBEAT? (100Hz pulses from the display)
Now we have enough info to create a prototype. I used a Wemos D1 Mini (ESP8266) which has hardware SPI and WiFi support. 5V power is available from the sign itself so no other hardware is needed. Here are the pin mappings:
Some code was written to implement the above protocol. It subscribes to the MQTT topics “hanoverled/display” (64 bytes of display data) and “hanoverled/brightness” (0-1023) and updates the display as these topics change.
Here is an extract of the code showing the main display routine. It accepts 64 bytes of data being the pixel values in left-to-right, top-to-bottom order. Not sure what the header values mean so just used the captured values 3E and BE. The ‘EOT’ pulse at the end of transmission is required otherwise the display does not update properly.
void UpdateDisplay(byte data)
SPI.beginTransaction(SPISettings(2500000, MSBFIRST, SPI_MODE2));
// meta data row 1
// pixel data row 1
for(int i = 0; i < 32; i++)
// meta data row 2
// pixel data row 2
for(int i = 32; i < 64; i++)
// pulse EOT line
To test the display a version of Conway’s game of life was written. Random start populations are generated, evolved and sent to the MQTT “hanoverled/display” topic. The program generates a new population if a game starts to repeat.
I bought this Sinclair calculator off eBay with the intention of repairing it. The power supply rails, LED display and driver chips were working fine. The keyboard had several keys that did not show any connectivity which could be fixed. But the main C-595 calculator chip was faulty and outputting random signals.
The C-595 is of course unobtainable these days, so could we replace it with a suitably programmed Arduino chip and bring it back to life?
First job was to fix the keyboard. Several keys were not functioning so this needed a tear down and clean.
The keyboard was held in place by plastic pegs which naturally snap off when disassembling! Some small holes were drilled in the plastic frame using a hand held 1mm CNC drill bit taking care not to go through to the other side. Small lengths of 1mm ABS rod were then glued into the holes and melted with a soldering iron to keep the keyboard layers tightly sandwiched together.
With the keyboard working we turn attention to the main calculator chip. The plan was to design a small PCB carrier for an ATMega328 chip that could plug in in place of the original chip.
A datasheet is available for the C-595 (local copy here) and after some reverse engineering we arrived at the following schematic:
The C595 runs with a positive earth, so we’d have to install the Arduino upside down. A bit of a brain ache but it should work. I wanted to use the existing driver ICs to minimise changes.
Removed the C595 IC and replaced with a socket. Removed the coil to disable 15V and 9V generation. Added a jumper wire to supply -3V battery power to an unused pin 10 on the socket.
The LED display is a 9 digit, seven segment common cathode device. To turn on a segment requires the segment line to be at 0V and the corresponding digit cathode at -3V. Allowing for the voltage inversion by the driver and the upside down Arduino, that corresponds to a HIGH for the segment and a HIGH for the digit.
To add to the fun the keyboard is multiplexed to the digit driver pins. An INPUT_PULLUP pin on the Arduino will pull to 0V, so we need to strobe the digit pins with -3V (LOW) to detect a change in state on the KP, KN and KO input pins.
We need 17 digital outputs and 3 digital inputs. To run at low voltage we use the internal oscillator which helpfully frees up pins PB6 and PB7 for use as GPIO.
The software was developed initially as a prototype running on an Arduino Nano. It runs in a loop with three main functions; update the display, read the keyboard and update the calculation when a key is pressed. Updating the display is slightly complicated by the fact that the circuit uses the same pins to enable display digits as well as drive the keyboard. We need to take care to blank the display while the keyboard is polled. For the calculator part of the software a simple state machine is used in conjunction with a custom decimal floating-point library. Firmware can be found in this github repo
Here is a picture of the prototype:
The case wouldn’t close properly using the prototype so a small PCB was designed around a bare bones ATMega238P to fit in the C595 socket. The ICSP and Tx/Rx pins were connected to exposed pads for testing purposes.
An Arduino Uno was used as a programmer to flash the firmware to the ATMega using these pin connections.
This was originally designed to just mirror a Rigol DS1054 screen over a LAN, but I couldn’t stop myself adding a few features, so you can now:
Click on the Timebase box to change the timebase
Click on the channel numbers at the bottom to toggle the corresponding channel on/off
Click on the channel voltage displays to change the vertical scales
Click and drag a trace to move it up/down (in Turbo mode only)
Click and drag in the “waveform memory” window at the top centre to move the traces left and right
Right-click on the main display to copy an image of the display to the clipboard or to a file
Right-click on the main display to turn Turbo mode on or off. With Turbo mode on only waveform data is downloaded and drawn over a screenshot. This can give a faster update rate but will obscure measurement data etc. With Turbo mode off the app simply mirrors the display at 1 FPS.
Here’s a screen capture showing it in use.
With just 1 channel enabled you get about 6 FPS (in Turbo mode) which drops to about 1 FPS with multiple channels. With Turbo mode off the whole screen is refreshed at 1FPS.
On first run it will ask you for the scope’s IP address. Enter it and click Save
The app is packaged as a UWP app and doesn’t require any VISA drivers to be installed.