About

The Amiga can be conveniently controlled via a WeMoS D1 Mini board in order to either pull data from the Amiga (such as CPU temperature) or turn the Amiga on or off via triggers such as Amazon Alexa.

The designing iLO devices project relies on a battery to sustain a Raspberry Pi when the power is off. However, a better approach is to create a circuit parallel to the entire power supply in order to draw $5V$ regardless whether the computer is on or off.

Another approach is to use the $+5V$ VSB power line from the ATX power supply itself, however the line is not meant to support heavier loads and that may have consequences on the other pins of the power supply itself.

The following modification to a towerized Amiga 1200 will consist in the following steps:

  • modify the power supply to add a parallel circuit that will provied $+5V$ directly from the mains,
  • use Arduino combined with a WeMoS D1 Mini board and a junction switch, that can be toggled either via the power button or via a wireless signal, in order to power the Amiga on or off.

The project assumes that the Amiga has a Mediator board and is towerized using a PC case.

Requirements

  • a $220-110V$ to $5V$ step down module - such modules are easily found and manage to step down mains power to $5V$ at about $600mA$. Since a WeMoS D1 Mini board, even at full speed wireless connection (11Mbit) only consumes about $170mA$, such a step down module is more than sufficient and has a conveniently small size that it can be hidden inside the power source case.

  • jack power plugs - the plugs will be used to provide power through the power supply case and power the WeMoS board.

  • WeMoS D1 Mini board - there are many variations of this board and they all are based around an ESP8266 processor that bundles WiFi and the boards reach up to $4MiB$ of RAM which is even overkill for the purposes of this project. The difference between "pro" and standard boards is that the "pro" boards are usually delivered with an USB port so the board can be programmed directly without having to wire the serial port beforehand.

  • the following electronics components will be used to build a pass-through and simultaneously GPIO triggered switch:
    • 2N3904 transistor,
    • a $240k\Ohm$ resistor,
    • some Dupont cables,
    • IC pins with $2.54mm$ pitch matching the Dupont cables,
    • small piece of blank double-sided PCB,
    • some copper thin wire for the PCB
  • a micro USB cable - this will be used to connect from the newly added power socket on the power supply and to the WeMoS board.

Adding the Parallel Circuit to the Power Supply

The power supply modification is needed to power the WeMoS board even when the Amiga is powered off. The modification adds a secondary power converter and step down that converts $220-110V$ to $5V$ using a small module (internally, a Wheatstone bridge converting alternating current to direct current plus a step down circuit to $5V$) connected to the mains pins and with two leads for $5V$ and $GND$ leading out of the power supply box.

One part of the power plug jacks is mounted on the power supply case itself by drilling a small hole to fit the jack as shown in the image above. The leads outside of the power supply box that are not connected will be soldered to a micro USB cable in order to power the WeMoS.

Designing the Pass-Through and GPIO Switch

This is a very easy to understand circuit that uses a 2N3904 to make contact between PS_ON and PS_ON / GND whenever a $3.3V$ current is supplied to a GPIO pin on the WeMoS board. Furthermore, PS_ON and PS_ON /GND are additionally connected to the PC tower power switch such that the computer can be turned on using the standard power button as well.

To PC tower Case Switch
   <---+------------------------------+---------+---------> to motherboard PS_ON
                                      |         |         
                                      |         |         
                                      C         |         
                                    |/           /        
             +-- GPIO +---+/\/+----B|  2N3904   + Case    
             |           460kOhm    |\          | switch  
             |                        E         |         
             | GND                    |         |
             |                        |         |
   <---+-----+------------------------+---------+---------> to motherboard PS_ON / GND
To PC tower Case Switch               |
                                      - GND

The assembled result looks like the very small PCB on the right in the following image:

where:

  • the board on the left is the WeMoS board,
  • the board on the right is the pass-through switch.

The pass-through switch has six Dupont cables leading to:

  • the WeMoS board - GPIO and GND,
  • the Mediator pins to which the PC case switch used to connect to,
  • the PC case switch

Programming the WeMoS D1 Mini for GPIO Toggling

Using a PC or a Mac, the WeMoS can be connected to the USB port and programmed using the Arduino IDE. The sketch to be programmed can be programmed with a boilerplate pin toggling template.

After the WeMoS has been programmed, the functionality of the sketch can be tested using a standard voltmeter and an MQTT client such as mosquitto_pub. For instance, the following message would be sent to the MQTT server that the WeMoS subscribes to:

{ "pin": 8, "state": "on" }

via:

mosquitto_pub -h MOSQUITTO_SERVER -t WEMOS_TOPIC -m '{ "pin": 8, "state": "on" }'

which would make the WeMoS set the GPIO pin 8 (as printed on the board) to logic HIGH ($3.3V$). Then, using a voltmeter, the difference between the GPIO pin 8 and the pin marked on the WeMoS GND can be measured - it should be approximately $3.3V$.

If the tests succeed and the WeMoS properly re-connects to the WiFi network and subscribes to the MQTT server, then the board can be assembled inside the Amiga.

Coupling with Node-Red

Assuming that the command-line tests succeed, the project would be done, however now that the WeMoS responds to messages on the MQTT bus, it is convenient to find a more humane interface to interract with that will switch the Amiga on or off. Whilst, the designing iLO project uses OpenHAB, for this project Node Red is used.

A sample Node Red flow would be the following:

where:

  • Amazon Echo Hub is from the node-red-contrib-alexa-local project and acts as Phillips Hue proxy for multiple devices devices,
  • Amiga is technically a Phillips Hue device, but the node just defines "Amiga" as the spoken word for Alexa,
  • the Amiga On is lambda node with the following method body:
// MQTT topic to send the message on
msg.topic = 'esp/amiga';
msg.payload = {};
msg.payload.pin = 8;
msg.payload.state = "on";
 
return msg;

where esp/amiga is the topic to broadcast the message on for MQTT,

  • the delay 250ms, as the name would imply, will delay a message for $250ms$,
  • the Amiga Off node just turns msg.payload.state from on to off,
  • the MQTT node is an MQTT output node that is connected to the central MQTT bus

This may seem counter-intutive: once Alexa is told to "turn Amiga on", the signal flows from the "Amiga" node to the "Amiga On" node where a message is generated to be sent to the MQTT bus. The message sent by "Amiga On" contains the "pin" and "state" keys that the WeMoS will intercept and set the GIO pin 8 to HIGH. However, some confusion may arrise why the message is split after the "Amiga On" into two - first sending a straight-through signal and then delaying the second signal for $250ms$ and then sending a message to set the GPIO pin 8 to LOW.

This can be explained by looking at the basics of digital pins, where the push-switch for the Amiga Mediator actually generates a logic 1 instead of "just making contact between pins" - quite so, since holding down the Amiga power switch will achieve absolutely nothing until the button is also released.

Imagine the signal as a digital 1 square signal where the period $T$ can be as narrow as a few nanoseconds $t_{p}$ and as long as whatever much time $t_{r}$, the difference thereof between $t_{r}$ and $t_{p}$ representing the period of the signal and also the duration of the button press:

^ voltage
|
|   
|  +-------------+ . . 5V
|  |             |
|  |             |
+--+-------------+------->
   ^\           /^      time
   . ----------  .
   .      T      .
  press         release

In effect, if the power button were to be pressed and held down, nothing would happen until the button were to be released such that the period $T$ does not matter.

The first message sent to the WeMoS would be:

{ "pin": 8, "state": "on" }

and would represent $t_{p}$, the moment when the button is pressed.

Conversely, the second delayed message would be:

{ "pin": 8, "state": "off" }

and represents $t_{r}$, the moment when the button is released.

The same proceedure takes place when the Amiga turns off and it is important to note that setting the GPIO pin to HIGH does not imply "turning the Amiga on" but rather "start pressing the PC power button".

Closing Notes

  • From the perspective of the Node Red flow, it is indeterminable whether the Amiga is currently powered on or off. In order to be able to tell at any time whether the Amiga is powered on, some form of persistent storage is needed, for instance, by adding a global persistent Node Red variable that would hold the current state or one could modify the Arduino sketch to remember the state or make the WeMoS advertise the current state on the MQTT bus.

hardware/amiga/making_the_amiga_smart.txt ยท Last modified: 2023/09/27 10:26 by office

Access website using Tor Access website using i2p Wizardry and Steamworks PGP Key


For the contact, copyright, license, warranty and privacy terms for the usage of this website please see the contact, license, privacy, copyright.