Check out my first novel, midnight's simulacra!

InaMORAta: Difference between revisions

From dankwiki
No edit summary
 
(46 intermediate revisions by the same user not shown)
Line 1: Line 1:
Let's fuck hard with some fans using an [[Arduino|Arduino Uno]]. This will be used for my [[MO-RA3]] to collect realtime data (fan RPMs, temperatures, etc.) and provide realtime control (fan PWM, RGB signals).
[[File:PXL 20220916 080028177.jpg|right|thumb|the completed apparatus]]
[[InaMORata_2.0|Updated in 2024]]
 
Let's fuck hard with some fans using an [[Arduino|Arduino MEGA]] and a [https://heltec.org/project/wifi-lora-32/ Heltec LoRa ESP32 v2]. These will be used with my [[MO-RA3]] to collect realtime data (fan RPMs, temperatures, etc.) and provide realtime control (fan PWM/RPM, RGB signals). We will also need an LM2596 buck converter and six IRLB8721 logic level MOSFETs, a TXB0108 level shifter, and various resistors.
 
We use a 12V PWM+DRGB hub for the many fans of the MO-RA3. Only one fan's RPM will be reported (whichever one is plugged into the red fan hookup), so it's important that we use the same model throughout. The hub has a two-wire hookup for tach and PWM (12V and ground are provided through the SATA power hookup). Looking at the hub with the clear side oriented up, the left wire is the PWM input, and the right wire is the tach output.
 
The goal is to have nothing running between the case and the MO-RA3 except for the coolant tubing. No USB, no RGB, no 4-pin fan, no power. That way, I can spring my quick disconnects (Koolance QD4s) and boom, the two units are distinct. The MO-RA3 won't pull on any easily-loosened 9000AWG wires, and there will be no electrical signals between the two.


==Communication==
==Communication==
We'll want to report RPMs to the controlling host, and probably take PWM and RGB orders from it. We might use e.g. [[LoRa]] for this later. For now, we'll use the serial channel over a USB connection.
We might use [[LoRa]] for this later; for now, we use MQTT over WiFi from the Heltec. The Heltec exists purely to make the network connection and broker between MQTT and the MEGA; the latter does all the actual work and sensing.
===MQTT topics===
* <tt>sensors/mora3.therm</tt> floating-point temperature in celsius
** published once per second by Heltec, subscribed by controller
* <tt>sensors/mora3.rpm</tt> integer rpm extrapolated from the most recent second (i.e., multiplied by 60)
** published once per second by Heltec, subscribed by controller
* <tt>control/mora3/rgb</tt> accepts six hex digits BBRRGG specifying the fan color
** published by controller, subscribed by Heltec
* <tt>control/mora3/pwm</tt> accepts an integer 0–255 specifying the fan PWM
** published by controller, subscribed by Heltec
===Recovery===
Currently, the controller sends messages only on change. This doesn't fly if the components can go down. We ought have the Heltec publish two more data, the effective PWM and effective RGB, and it ought get these from the MEGA. That way, the controller can publish whenever the effective values do not equal the desired values.


==Powering the micro==
We could have the controller simply regularly publish the desired states, but the protocol above lets the controller know when the MEGA has an incorrect understanding of state (if e.g. the Heltec stops passing along control messages).
So long as we're using the USB connection, we can get power from it; later, if we cut the cord, we'll need to take power from the fans' power source. If we're using 12V fans, that's right at the top end of the supported voltages. 5V is not going to cut it as a Vin supply (it'll work over USB, though). Arduino claims to support 6–20V through Vin, and recommends 7–12V.


We will *not* be powering the fans or LEDs from the Arduino directly. They draw too many amps, and Arduinos can't provide 12V power directly anyway.
==Powering the system==
[[File:12vpwmrgbhub.png|right|thumb|Power enters via SATA to a 12V RGB/PWM hub]]
We need 12V for our fans (Arctic P14 RGBs) and their RGB LEDs. This is accomplished with a SHNITPWR 12V AC adapter, plugged into a barreljack switch. This barreljack switch is then adapted to a 12V-only SATA plug (SATA normally carries 3.3V, 5V, and 12V). The SATA plug enters a 12V PWM+RGB hub. All fans are plugged directly into this hub, one port of which carries through tachometer readings.


When Vin is driven with at least 7.5V, it will take over from any USB connection. This is probably desirable, so that we are on the same power source and ground as the DUTs (but maybe it doesn't matter?).
A 12V plus ground pair are used from one of the hub's PWM hookups to drive a HiLetgo LM2596 buck converter. The LM2596 is configured to deliver 7.1V by adjusting a potentiometer. The output is displayed on the LM2596's LED. This is a safe output to drive both the Arduino and the Heltec. On the output side, we hook two barreljack pushbutton connectors up to the LM2596. One directly powers the Arduino. The other uses a microUSB adapter to power the Heltec.


The USB power <i>must not</i> be used in conjunction with power supplied through the 5V header. If a 5V source is to be used, it is desirable to use it through the USB receptacle, which enjoys polarity protection (unlike the 5V pin).
We will *not* be powering the fans or LEDs from the Arduino directly. They draw far too much current, and Arduinos can't provide 12V power anyway (well, unless you dump 12V in at the power jack, and then drive from VIN, but you're gonna be voltage regulating that 12 down to 5, and why burn dinosaurs when there's no need?). Everything else is powered by the hub directly. We only need 5V for the tachometer and PWM signals, but we need send 12V PWM to the LEDs. We thus connect another ground to one side of the breadboard, where we'll hook it up to the MOSFETs.


==Rotation count (RPMs)==
==Rotation count (RPMs)==
Most case fans have a tachometer inside, using the third wire to send its signal. It will be strobed once for every two revolutions. If it is e.g. strobed 80 times within a second, then there were 160 revolutions in that second, and we can extrapolate to 9600RPM (truly an insane case fan; I know of no such monstrosities).
Most case fans have a tachometer inside, using the third wire to send its signal. It will be strobed once for every two revolutions. If it is e.g. strobed 80 times within a second, then there were 160 revolutions in that second, and we can extrapolate to 9600RPM (truly an insane case fan; I know of no such monstrosities).


We'll need a digital input pin with interrupt support. On the Arduino Uno, this restricts us to pin 2 or 3.
We'll need a digital input pin with interrupt support. On the Arduino Uno, this restricts us to pin 2 or 3. We use pin 2, plus the necessary resistor.


==Control (PWM)==
==Control==
We set up a 25K PWM signal on digital output pin 9. We can't use the standard Arduino PWM system, which operates at lower frequencies (490Hz and 980Hz). We operate directly on timer registers:
===Fan PWM===
We set up a 25K PWM signal on pin 8. We can't use the standard Arduino PWM system, which operates at lower frequencies (490Hz and 980Hz). We operate directly on timer registers, using timer 4:
<pre>
<pre>
   const word PWM_FREQ_HZ = 25000;
   const word PWM_FREQ_HZ = 25000;
   TCCR1A = 0;
   TCCR4A = 0;
   TCCR1B = 0;
   TCCR4B = 0;
   TCNT1 = 0;
   TCNT4 = 0;
   TCCR1A |= (1 << COM1A1) | (1 << WGM11);
   ICR4 = (F_CPU / PWM_FREQ_HZ) / 2;
   TCCR1B |= (1 << WGM13) | (1 << CS10);
  TCCR4A |= (1 << COM4A1) | (1 << WGM41);
  ICR1 = 16000000 / (2 * PWM_FREQ_HZ);
   TCCR4B |= (1 << WGM43) | (1 << CS40);
</pre>
</pre>
This <tt>ICR1</tt> value comes out to 320. We can then set the desired PWM <tt>duty</tt> (0–100) with:
This <tt>ICR4</tt> value comes out to 320. We can then set the desired PWM <tt>duty</tt> (0–255) with:
<pre>
<pre>
   OCR1A = (word)(duty * 320) / 100
   OCR4C = duty;
</pre>
</pre>
 
===LEDs===
==Distribution==
We use three PWM-capable digital pins: 9, 10, and 11 for blue, green, and red respectively. <tt>analogWrite()</tt> is sufficient to set the brightness. These pins are used to control logic level MOSFETs, which are also hooked up to ground and the 12V input.
We use a 12V PWM+DRGB hub for the many fans of the MO-RA3. Only one fan's RPM will be reported (whichever one is plugged into the red fan hookup), so it's important that we use the same fan throughout. The hub has a two-wire hookup for tach and PWM (12V and ground are provided through the SATA power hookup). Looking at the hub with the clear side oriented up, the left wire is the PWM input, and the right wire is the tach output.


==Temps==
==Temps==
We want the water temperature, and ideally also our own temperature on the microcontroller.
We want the water temperature, and ideally also our own temperature on the microcontroller. The Uno's ATmega328P processor has an onboard temperature sensor:
 
===External (thermistor)===
We're using an [https://www.alphacool.com/shop/monitoring-controlling/temperature-sensor/21456/alphacool-eiszapfen-temperature-sensor-plug-g1/4-chrome Alphacool Eiszapfen 17365] plug sensor. Its datasheet can be found [https://www.alphacool.com/download/kOhm_Sensor_Table_Alphacool.pdf here]. This is a 10kΩ thermistor (resistance varies with temperature) with a β of 3435K and a nominal temperature of 25℃.
 
===Microcontroller===
The Uno's ATmega328P processor has an onboard temperature sensor:
<pre>
<pre>
int readTemp(void){
int readTemp(void){
Line 54: Line 67:
}
}
</pre>
</pre>
Unlike the Uno, it appears that the MEGA has no way to get its own temperature, lame.
===External (thermistor)===
We're using an [https://www.alphacool.com/shop/monitoring-controlling/temperature-sensor/21456/alphacool-eiszapfen-temperature-sensor-plug-g1/4-chrome Alphacool Eiszapfen 17365] plug sensor. Its datasheet can be found [https://www.alphacool.com/download/kOhm_Sensor_Table_Alphacool.pdf here]. This is a 10kΩ thermistor (resistance varies with temperature) with a β of 3435K and a nominal temperature of 25℃. To effect a better read, we'll use the 3.3V as our reference. This requires hooking 3.3V up to AREF and calling <tt>analogReference(EXTERNAL);</tt>. We pair it with a reference 10KΩ resistor, and hook it up to 3.3V, ground, and analog input pin A0.


==Wiring==
==Wiring==
* 5V pin goes to 10kΩ resistor, goes to tach signal
[[File:Inamorata bb.png|right|thumb|Fritzing diagram]]
* Take ground from power source
The breadboard has 4 vertical channels. We'll use GND at 0 (the leftmost), 5V at 1, and 3.3V at 2. Both MCUs will be tied to channel 0 for ground. The Arduino will supply our 5V, and the Heltec our 3.3V.
* Analog input pin goes to thermistor signal
 
* Digital output pin 9 goes to PWM
===MEGA===
* 3.3V pin goes to 10kΩ resistor, goes to thermistor signal
* 5V goes to breadboard channel 1
* 3.3V goes to AREF
* GND goes to breadboard channel 0
* Pin 2 goes to hub's tach output
* Pin 8 goes to hub's PWM input
* Pin 16 goes to level shifter B3
* Pin 17 goes to level shifter B6
* Pins 9, 10, and 11 go to MOSFET controls (dynamic fan RGB)
* Pins 7, 6, and 5 go to a second set of MOSFET controls (static reservoir RGB)
* Pin 20 goes to tach of first pump
* Pin 21 goes to tach of second pump
 
===Heltec===
* Pin 37 goes to level shifter A3
* Pin 17 goes to level shifter A6
* Pin 38 goes to thermistor signal
* 3.3V goes to breadboard channel 2
* GND goes to breadboard channel 0
 
===MOSFETs===
* Gate is connected to appropriate MEGA pin 9, 10, or 11
* Drain is connected to appropriate hub R/G/B pin
* Source goes to breadboard channel 0
 
===Level shifter===
* Va goes to breadboard channel 2
* Vb goes to breadboard channel 1
* GND goes to breadboard channel 0
* OE goes to breadboard channel 2


===Example breadboard===
===Thermistor===
* 1A: digital input pin supporting interrupts (2 or 3 on the Uno)
* Source goes to 10kΩ resistor, goes to breadboard channel 2
* 1B: tachometer signal
* 1C: 7C
* 2D: Arduino GND
* 7B: 10kΩ resistor
* 7C: 1C
* 16A: 5V
* 16B: 10kΩ resistor


==Protocol==
==Protocol==
The Heltec publishes desired PWM levels to the MEGA by writing a single byte over the UART. This communicates a value 0–255. It ought be immediately applied by the MEGA. It is published once a second, and whenever a new value is read from MQTT.
The MEGA publishes measured RPM and water temperature levels, along with the currently applied PWM, to the Heltec over the UART. Values may be published in any order, at any time. These values are published in a human-readable form, one after another with no intervening content. They are of the form `Tf`, `Ri`, and `Pi`, where `f` is a float and `i` is an integer.
===UART===
We can transmit from the Heltec to the Arduino directly; the 3.3V high logic level of the Heltec registers as high on the MEGA. Sending from the 5V MEGA directly to the Heltec will damage the latter. We instead go through a 1kΩ+2kΩ voltage divider from MEGA pin 16 to Heltec pin 36. The Heltec transmits from 17 directly to RX2 (pin 17) on the MEGA.
==Future work==
* This needs to get cleaned up, obviously. at a bare minimum, wires need be soldered into the Heltec.
* I ought power the Heltec through the 5V pin rather than the USB. In this case, it moves to the LM2596, and the only thing drawing 5V is the CODI6 (for ARGB LEDs).
* I think I can eliminate the MEGA2560 entirely? We only need move the three tachometer inputs and three RGB outputs at this point. Eliminating it would also (probably) eliminate the level shifter.


[[CATEGORY:Projects]]
[[CATEGORY:Projects]]
[[CATEGORY:Hardware]]
[[CATEGORY:Hardware]]

Latest revision as of 07:23, 1 May 2024

the completed apparatus

Updated in 2024

Let's fuck hard with some fans using an Arduino MEGA and a Heltec LoRa ESP32 v2. These will be used with my MO-RA3 to collect realtime data (fan RPMs, temperatures, etc.) and provide realtime control (fan PWM/RPM, RGB signals). We will also need an LM2596 buck converter and six IRLB8721 logic level MOSFETs, a TXB0108 level shifter, and various resistors.

We use a 12V PWM+DRGB hub for the many fans of the MO-RA3. Only one fan's RPM will be reported (whichever one is plugged into the red fan hookup), so it's important that we use the same model throughout. The hub has a two-wire hookup for tach and PWM (12V and ground are provided through the SATA power hookup). Looking at the hub with the clear side oriented up, the left wire is the PWM input, and the right wire is the tach output.

The goal is to have nothing running between the case and the MO-RA3 except for the coolant tubing. No USB, no RGB, no 4-pin fan, no power. That way, I can spring my quick disconnects (Koolance QD4s) and boom, the two units are distinct. The MO-RA3 won't pull on any easily-loosened 9000AWG wires, and there will be no electrical signals between the two.

Communication

We might use LoRa for this later; for now, we use MQTT over WiFi from the Heltec. The Heltec exists purely to make the network connection and broker between MQTT and the MEGA; the latter does all the actual work and sensing.

MQTT topics

  • sensors/mora3.therm floating-point temperature in celsius
    • published once per second by Heltec, subscribed by controller
  • sensors/mora3.rpm integer rpm extrapolated from the most recent second (i.e., multiplied by 60)
    • published once per second by Heltec, subscribed by controller
  • control/mora3/rgb accepts six hex digits BBRRGG specifying the fan color
    • published by controller, subscribed by Heltec
  • control/mora3/pwm accepts an integer 0–255 specifying the fan PWM
    • published by controller, subscribed by Heltec

Recovery

Currently, the controller sends messages only on change. This doesn't fly if the components can go down. We ought have the Heltec publish two more data, the effective PWM and effective RGB, and it ought get these from the MEGA. That way, the controller can publish whenever the effective values do not equal the desired values.

We could have the controller simply regularly publish the desired states, but the protocol above lets the controller know when the MEGA has an incorrect understanding of state (if e.g. the Heltec stops passing along control messages).

Powering the system

Power enters via SATA to a 12V RGB/PWM hub

We need 12V for our fans (Arctic P14 RGBs) and their RGB LEDs. This is accomplished with a SHNITPWR 12V AC adapter, plugged into a barreljack switch. This barreljack switch is then adapted to a 12V-only SATA plug (SATA normally carries 3.3V, 5V, and 12V). The SATA plug enters a 12V PWM+RGB hub. All fans are plugged directly into this hub, one port of which carries through tachometer readings.

A 12V plus ground pair are used from one of the hub's PWM hookups to drive a HiLetgo LM2596 buck converter. The LM2596 is configured to deliver 7.1V by adjusting a potentiometer. The output is displayed on the LM2596's LED. This is a safe output to drive both the Arduino and the Heltec. On the output side, we hook two barreljack pushbutton connectors up to the LM2596. One directly powers the Arduino. The other uses a microUSB adapter to power the Heltec.

We will *not* be powering the fans or LEDs from the Arduino directly. They draw far too much current, and Arduinos can't provide 12V power anyway (well, unless you dump 12V in at the power jack, and then drive from VIN, but you're gonna be voltage regulating that 12 down to 5, and why burn dinosaurs when there's no need?). Everything else is powered by the hub directly. We only need 5V for the tachometer and PWM signals, but we need send 12V PWM to the LEDs. We thus connect another ground to one side of the breadboard, where we'll hook it up to the MOSFETs.

Rotation count (RPMs)

Most case fans have a tachometer inside, using the third wire to send its signal. It will be strobed once for every two revolutions. If it is e.g. strobed 80 times within a second, then there were 160 revolutions in that second, and we can extrapolate to 9600RPM (truly an insane case fan; I know of no such monstrosities).

We'll need a digital input pin with interrupt support. On the Arduino Uno, this restricts us to pin 2 or 3. We use pin 2, plus the necessary resistor.

Control

Fan PWM

We set up a 25K PWM signal on pin 8. We can't use the standard Arduino PWM system, which operates at lower frequencies (490Hz and 980Hz). We operate directly on timer registers, using timer 4:

  const word PWM_FREQ_HZ = 25000;
  TCCR4A = 0;
  TCCR4B = 0;
  TCNT4  = 0;
  ICR4 = (F_CPU / PWM_FREQ_HZ) / 2;
  TCCR4A |= (1 << COM4A1) | (1 << WGM41);
  TCCR4B |= (1 << WGM43) | (1 << CS40);

This ICR4 value comes out to 320. We can then set the desired PWM duty (0–255) with:

  OCR4C = duty;

LEDs

We use three PWM-capable digital pins: 9, 10, and 11 for blue, green, and red respectively. analogWrite() is sufficient to set the brightness. These pins are used to control logic level MOSFETs, which are also hooked up to ground and the 12V input.

Temps

We want the water temperature, and ideally also our own temperature on the microcontroller. The Uno's ATmega328P processor has an onboard temperature sensor:

int readTemp(void){
  ADCSRA |= _BV(ADSC);
  while(bit_is_set(ADCSRA, ADSC)){
    ;
  }
  return (ADCL | (ADCH << 8)) - 342;
}

Unlike the Uno, it appears that the MEGA has no way to get its own temperature, lame.

External (thermistor)

We're using an Alphacool Eiszapfen 17365 plug sensor. Its datasheet can be found here. This is a 10kΩ thermistor (resistance varies with temperature) with a β of 3435K and a nominal temperature of 25℃. To effect a better read, we'll use the 3.3V as our reference. This requires hooking 3.3V up to AREF and calling analogReference(EXTERNAL);. We pair it with a reference 10KΩ resistor, and hook it up to 3.3V, ground, and analog input pin A0.

Wiring

Fritzing diagram

The breadboard has 4 vertical channels. We'll use GND at 0 (the leftmost), 5V at 1, and 3.3V at 2. Both MCUs will be tied to channel 0 for ground. The Arduino will supply our 5V, and the Heltec our 3.3V.

MEGA

  • 5V goes to breadboard channel 1
  • GND goes to breadboard channel 0
  • Pin 2 goes to hub's tach output
  • Pin 8 goes to hub's PWM input
  • Pin 16 goes to level shifter B3
  • Pin 17 goes to level shifter B6
  • Pins 9, 10, and 11 go to MOSFET controls (dynamic fan RGB)
  • Pins 7, 6, and 5 go to a second set of MOSFET controls (static reservoir RGB)
  • Pin 20 goes to tach of first pump
  • Pin 21 goes to tach of second pump

Heltec

  • Pin 37 goes to level shifter A3
  • Pin 17 goes to level shifter A6
  • Pin 38 goes to thermistor signal
  • 3.3V goes to breadboard channel 2
  • GND goes to breadboard channel 0

MOSFETs

  • Gate is connected to appropriate MEGA pin 9, 10, or 11
  • Drain is connected to appropriate hub R/G/B pin
  • Source goes to breadboard channel 0

Level shifter

  • Va goes to breadboard channel 2
  • Vb goes to breadboard channel 1
  • GND goes to breadboard channel 0
  • OE goes to breadboard channel 2

Thermistor

  • Source goes to 10kΩ resistor, goes to breadboard channel 2

Protocol

The Heltec publishes desired PWM levels to the MEGA by writing a single byte over the UART. This communicates a value 0–255. It ought be immediately applied by the MEGA. It is published once a second, and whenever a new value is read from MQTT.

The MEGA publishes measured RPM and water temperature levels, along with the currently applied PWM, to the Heltec over the UART. Values may be published in any order, at any time. These values are published in a human-readable form, one after another with no intervening content. They are of the form `Tf`, `Ri`, and `Pi`, where `f` is a float and `i` is an integer.

UART

We can transmit from the Heltec to the Arduino directly; the 3.3V high logic level of the Heltec registers as high on the MEGA. Sending from the 5V MEGA directly to the Heltec will damage the latter. We instead go through a 1kΩ+2kΩ voltage divider from MEGA pin 16 to Heltec pin 36. The Heltec transmits from 17 directly to RX2 (pin 17) on the MEGA.

Future work

  • This needs to get cleaned up, obviously. at a bare minimum, wires need be soldered into the Heltec.
  • I ought power the Heltec through the 5V pin rather than the USB. In this case, it moves to the LM2596, and the only thing drawing 5V is the CODI6 (for ARGB LEDs).
  • I think I can eliminate the MEGA2560 entirely? We only need move the three tachometer inputs and three RGB outputs at this point. Eliminating it would also (probably) eliminate the level shifter.