PROJECT: Half-Life 2 AR2, Update #18 - RGB LED Driver Revision

LINK TO PREVIOUS POST

The last few months have been quite the rollercoaster for us, from Putin's unjust invasion of Ukraine, to me starting a new job... And only recently have I had the headspace to get back to the AR2

So in this quick update I want to show yous the revised RGB LED driver configuration. Basically I will be halfling the barrel LED zones from 4 (2x3S & 2x4S) to 2 (2x7S). Doing so reduces the complexity of the barrel PCBA's (like halfling the RGB LED driver IC's from 4 to 2, and lowering the LED connector pin-count from 28P to 16P), which is a welcome change as each RGB LED driver (LT3496) goes for ~13AUD/pc in low quantities

Now you might be asking, why not just drive all the 14 RGB LEDs in a big series configuration? Well I tried to simulate this scenario and soon realised that the forward voltage drop for the big LED chain would be too much for the LT3496 (who's SW pin is rated to 45V). I should also mention that I configure the OVP (Over-Voltage Protection) to 35V, so anytime the SW pin goes beyond this the IC shuts down for that switching cycle. Lastly below is the total forward voltage drop of each LED chain, and as you see in both cases we are over the 45V/35V limit:

• RED ⇒ 2.6Vf * 14 ⇒ 36.4Vf-tot
• GRN/BLU ⇒ 3.5Vf * 14 ⇒ 49.0Vf-tot

While if we break up the chain into half (2x7S) we are nicely under the limit:

• RED ⇒ 2.6Vf * 7 ⇒ 18.2Vf-tot
• GRN/BLU ⇒ 3.5Vf * 7 ⇒ 24.5Vf-tot

So with all that out of the way, here are the latest simulations of the 2x7S RGB LED configuration:

And here is an updated power losses & expected temperature rise (per IC) table:

IC	Type	RθJA, [°C/W]	IC losses average, [mW]	IC losses maximum, [mW]	Temp above ambient, [°C]
LT3496	Switching	34°C/W	RED 68mW GRN 57mW BLU 57mW	RED 113mW GRN 91mW BLU 91mW	6°C to 10°C

Couple of interesting things to note with above simulations/table:

1. I highly suspect that the LTspice model I am using for the BLU/GRN LED is not the best as I am seeing massive ON/OFF & OFF/ON transients (like in orders of 100's of mA). I am certain that the peak current would be more closer to that of the RED LED simulation (~20mA above nominal), but to test this I plan to place an inline 0R jumper which I will then use to measure the actual peaks with a fancy oscilloscope at work
2. The RED LED channel is showing a higher power loss, this is due to the RED LED current being double that of the GRN/BLU channel (40mA vs 20mA). So think greater I²R losses

UPDATE: Ukraine 2022

I am so utterly disappointed with Putin's decision to invade Ukraine. His lengthy dictatorship of Russia has put him out of touch with his people and the world as a whole, and it's so heartbreaking that he is willing to risk so much only to separate the many friends and families of two nations...

The only sane voice in this conflict seems to be that of Ukraine's president, Volodymyr Zelenskyy, who released a well put plea for the Russian people to look beyond Putin's propaganda and see him for the tyrant he is

28/02/22 Update

A YouTube channel I follow called Супер Сус just released a video showing current life in Kyiv. In their usual videos they would show off abandoned metro tunnels or even explore the Chernobyl exclusion zone, all in a very colourful/expressionist way. But the thing that hit really hard in their latest video is seeing the hermetic doors being shut in the Kyiv Metro to protect the civilians on the other side... Like in their older videos whenever they come across a hermetic door they would explain that the door would close in the unlikely event of an attack on Kyiv... and here we are...

05/03/22 Update

For those that have friends & family living in Russia that are too deep in Putin's propaganda, below is a good website that shares a similar experience between a son living in Ukraine and a father living in Russia:

https://papapover.com/

https://papapover.com/en/

The important thing is to keep the communication channel open. Don't be be angry and blame them for Russia's war/invasion of Ukraine. Make it clear that you are against Putin and his chokehold of the Russian people

PROJECT: Half-Life 2 AR2, Update #17 - RGB LED Driver

LINK TO PREVIOUS POST

Guess who is back to crunching simulations in LTspice, this time trying to figure out how well the RGB LED driver works ;^)

RGB LED, Configuration, & Driver Overview

The RGB LED I have decided to use is the BROADCOM ASMT-YTD7-0AA02, which also comes with a diffused silicone cap to mix the emitted light

The LEDs will be divided into 4 zones/strings inside the AR2 Barrel:

Finally, after comparing LED drivers like HV9980, LT3597, LP5009... I decided to settle on the LT3496 to drive the above configuration. The thing that makes this driver special is that it has a Buck-Boost mode, which is a must when the nominal battery voltage hovers close to the total forward voltage of the LED sting (particular for the GRN & BLU channels). Below is the LTspice simulation for the RED string:

A few key points about this LT3496 configuration:

1. Reducing the current sense voltage (CTRL pin) from 100mV to 50mV lowers the peak LED current during ON-OFF transition from 110mA to 80mA (think reducing swing range of error amplifier). LEDs are rated for 100mA peak 100ns pulse and though the 110mA pulse was only for 25ns, I really wanted to be sure I am not hitting the 100mA maximum limit
2. Reducing the switching frequency from 2.1MHz to 1.25MHz improves converter efficiency, as ON losses are lowered from 96mW to 76mW. Reducing the frequency beyond this brings diminishing returns, as losses are more or less ~70mW, while LED ripple current is increased (for same size inductor, 10μH)
3. Chosen VC filter (22K & 470P) helps minimize LED current overshot and improves settling time (during OFF-ON transition)
4. OVP resistor divider sets the LED string over-voltage protection to 35V. So if in the unlikely scenario that say a single LED fails in the RED string, the string will be safely shutdown to make sure it does not impact the GRN/BLU strings 

RGB LED in Detail (Or Why We Need a Buck-Boost Mode)

Remember when I said having a Buck-Boost mode is super useful when the nominal battery voltage hovers close to the total forward voltage of the LED sting? Well lets look at this in more detail... First off I will be using a 4S LiFePO₄ battery, so I expect the voltage to be:

• 14.4V maximum
• 13.6V nominal
• 10.0V minimum

I plan to drive each LED channel at 80% maximum DC current rating, so I expect the individual forward voltage to be:

• RED 2.3Vf nominal @ 40mA, & a maximum of 3.0Vf
• GRN 3.1Vf nominal @ 40mA, & a maximum of 3.6Vf
• BLU 3.1Vf nominal @ 40mA, & a maximum of 3.6Vf

So with a 3 series LED string the forward voltage will be:

• RED 6.9Vf nominal & 9.0Vf maximum
• GRN 9.3Vf nominal & 10.8Vf maximum
• BLU 9.3Vf nominal & 10.8Vf maximum

And with a 4 series LED string the forward voltage will be:

• RED 9.2Vf nominal & 12.0Vf maximum
• GRN 12.4Vf nominal & 14.4Vf maximum
• BLU 12.4Vf nominal & 14.4Vf maximum

Note how the LED string forward voltage spans the range of the battery voltage, meaning we can't just use a Buck or Boost regulator, as we will run into cases where battery voltage is too high/low for regulator to function. This is exactly where the Buck-Boost mode saves the day, as it can happily regulate the string voltage to required value :D

Linear vs Switching (Or When Things Get Hot)

So first of all we can't use a linear regulator to drive 4 series LEDs, unless we increase the battery voltage (as it would need to be ~2V higher than maximum forward voltage of the string). A linear regulator can just about drive 3 series LEDs, as in this scenario the battery voltage mostly gives enough headroom. With that said, lets compare how a linear regulator compares to a switching one

NOTE: I am setting the LED string brightness with a 1kHz PWM waveform that is at 50% duty

So using a switching regulator reduces the average dissipated power by ~70% (from 145mW to 40mW), and the ON dissipated power by ~80% (from 290mW to 56mW)... and that's just for the RED LED string/segment (as in not including the GRN/BLU string)! 

Next lets expand the simulation to include the GRN/BLU LED driver losses and see what the expected IC (just the one, not the 4 I need to drive all barrel zones) temperature rise above ambient is:

IC	Type	RθJA, [°C/W]	IC losses average, [mW]	IC losses maximum, [mW]	Temp above ambient, [°C]
LP5009	Linear	54°C/W	RED 145mW GRN 120mW BLU 120mW	RED 290mW GRN 239mW BLU 239mW	21°C to 42°C
LT3496	Switching	34°C/W	RED 40mW GRN 46mW BLU 46mW	RED 56mW GRN 69mW BLU 69mW	5°C to 7°C

And with all that waffle out of the way... we can see that using a switching regulator is the way to go, as:

1. It is more energy efficient, resulting in a cooler AR2 Barrel ;^)
2. It can actually drive 4 or more RGB LEDs in series, while being powered from same 4S LiFePO₄ battery

PROJECT: Half-Life 2 AR2, Update #16 - Barrel Flex PCB

LINK TO PREVIOUS POST

So there are a couple of ways to add RGB LEDs to the AR2 barrel, and since I prefer to use SMD components I can either use a rigid PCB or a flex PCB. Normally I would go the rigid route, but this time I chose to use flex as I have never used them for hobby projects

VS

Next up I simulated the possible LED viewing angles in SOLIDWORKS (just like I did with the IR LEDs). From this I was able to see that the RGB LEDs need to have a viewing angle of at least 120° to have a good barrel coverage

NOTE: Below simulation is super crude as it only looks at the 50% angular/spatial distribution (as in angle at which the brightness is at 50% maximum value), and does not account for the bright spot in the LED centre or the light diffusion within the material. Normally you would simulate all this with something like OpticStudio, but hey using SOLIDWORKS is better than nothing ;^)

PROJECT: Half-Life 2 AR2, Update #15 - Barrel Planning

LINK TO PREVIOUS POST

With the AR2 Receiver at 95% completion (just need to fix up loom runways once all electronics are finished) the next step is the AR2 Barrel. So below is me scoping out what's involved:

LEDs

I am hoping to closely match the barrel & muzzle light colours, though I can already tell this is going to be difficult using a single colour/wavelength LED. So suspect will be using a bunch of RGB LEDs to mix the colours till I have something close

One thing to note about RGB LED colour mixing is that you can approximate a target wavelength BUT you can't match it 100% (think RED, GRN, & BLU peaks combining to give a wide spectrum rather than a sharp peak at target wavelength). This won't be an issue for me as it's not like I am making a medical device that requires a specific wavelength of light 

With that in mind I tried recording the RGB values from the game screenshots and then using this neato tool to get approximate wavelengths. Note how some wavelengths are "impossible" (shown with a ★) due to the RGB value being a mix of all 3 primary colours instead of 2; for example the YLW RGB value is comprised of 254/255/134, so here it's the BLU 134 that is being the "issue" as the resulting light colour is not continuous along the visible spectra

Lastly, the barrel has bugger all space for a large PCB (and by extension a large heatsink), so I might have to add a temperature sensor (like I did with the solenoid inside the AR2 Receiver) to make sure things don't get too toasty

Servo

The servo used in the AR2 prototype is the Turnigy TGY-R5180MG and as with most servos this is controlled by varying the pulse width. So the plan is to use an I²C compatible PWM generator like the NXP PCA9685 (suspect I will be using the spare channels to drive the RGB LEDs)

And to top it all off I will also add an end-stop sensor to make sure the servo does not do weird stuff. This will likely be the same IR LED & sensor combo that I used on the AR2 Receiver

UPDATE: Ashes 2063 & Afterglow (Doom II Mod)

Have just finished playing the latest expansion of Ashes: 2063, titled Ashes: Afterglow

I gotta say, it's criminal how good this Doom II mod is!!! The maps are semi open-world like S.T.A.L.K.E.R with the environments detail of Metro (within Doom II's limits of course), and then on top of that you have a story line that's so easy to be absorbed into AND to top it all off a banging soundtrack :D

Plus the mod now runs on Freedoom, so you don't even need to own the original copy of Doom II

PROJECT: Half-Life 2 AR2, Update #14 - Receiver Main Board

LINK TO PREVIOUS POST

I have completed designing the RECEIVER_MAIN-BOARD, a board that controls all AR2 reciever function. Below is a reminder of where the board lives, how it looks (banana for scale included), as well as what the 3 receiver boards replace on the AR2 prototype:

Key specs for RECEIVER_MAIN-BOARD:

• 40mm x 20mm x 1.6mm

• 4 layers (signal, 0V, PWR, & signal)

• All function (including external daughter boards) controlled by a single I²C line

• Houses a bunch of goodies like:

• Two DCDC converters

• Switching to convert 13.2V to 4.3V (MAXM15462)

• Linear to convert 4.3V to 3.3V (ADP7102)

• Low R_DSON MOSFET (BSC040N10NS5) based solenoid driver, with the MOSFET being driven by UCC27533 to further reduce power losses

• ADS7138 to read the analog/digital inputs and/or set digital outputs

Next up I will go over the good & bad design elements... Spoiler alert, most of it is OK, some of it is meh D:

The Good

1. GOOD, Input filters on all connectors

All nets coming in/out of board (as in nets transitioning the EM zone boundary, as Keith Armstrong would put it) go through a filter. For example:

• Board power (13.2V) passes through a 10A rated pi filter

• All logic nets pass through IP4252CZ8-4-TTL,13, a neat ESD filter that uses the diode junctions to form a low-pass RC filter

Deploying these sorts of filters is a good way of protecting your device from ESD as well as improving your chances of passing EMC (think slowing down those fast edges)... BUT the topology I used has room for improvement as I will discuss in the bad parts section

2. GOOD, Reduced loom conductors

RECEIVER_MAIN-BOARD houses 5 key signals which control all reciever function. Meaning if I was to control the reciever directly then my cable loom would need to have 5 IO conductors, not including the return path for each...

I already have bugger all room in the AR2 so this would be a pain. Instead I feed the key nets into the ADS7138, an I²C IO expander with ADC functionality. Doing so reduces the loom "IO" conductor count to 2, which is basically the I²C data & clock line (again not including the return for each) 

BONUS:

• ADS7138 function could be implemented using a MCU, but that would mean I would have one additional thing to program and test... So to reduce complexity it's way easier to use an off the shelf IC that contains everything I want

3. GOOD, Efficient 13.2V to 3.3V conversion

Majority of reciever boards are powered by 3.3V, with the only exception being the solenoid which is powered "directly" from the LiFePO₄ battery (as in 13.2V). Also here is the power budget for all reciever boards:

The question then becomes how to covert 13.2V to 3.3V? Here are 3 common ways of solving this:

1. Use a linear (or LDO) regulator
• PRO: Super quiet 3.3V rail
• CON: Efficiency will be 25%, so will have to dissipate 0.38W
2. Use a switching (or SMPS) regulator
• PRO: Efficiency will be 85%, translating to a power loss of 0.02W (as in bugger all)
• CON: 3.3V rail is not quiet, expect 10-50mV ripple depending on load
3. Use both ;^)
• PRO: Overall efficiency will be ~77% (0.07W loss), and ripple will be non-existent
• CON: Additional complexity, cost, and board real-estate

I would have probably been OK with option 2, but I wanted to try something new so went with option 3:

But why use 4.3V as the intermediate rail? Well there were two factors I tried balancing:

1. To have a high LDO efficiency (at a given current) your input voltage should be as close as possible to the output voltage (think lower "voltage drop")
2. To have a high PSRR (at a given current) your input voltage should be as far as possible from the output voltage (think having a greater buffer to reject all that ripple)

From the gif below you can see that PSRR for 4.8V & 4.3V is identical, while for 3.8V it get's a tiny bit worse. Hence why I went with 4.3V

BONUS:

• Am using a couple of TVS diodes to protect the key rails
• UCLAMP3301D.TCT for 3.3V rail
• SD15C.TCT for 13.2V rail

4. GOOD, Reference plane stitching CAP's

Because I am using a cheap 4L stack-up I am limited to two different potential reference planes:

• 0V, used as top copper reference
• 3.3V, used as bottom copper reference

A few of my tracks jump from top to bottom and in the process change their reference plane. To help make their return path continuous (think reducing radiated emissions due to odd return paths) I have stitched the two reference planes where the layer change occurs with 1N 5% 25V C0G capacitors:

One thing to note is that had I used a thinner 4L stack-up (as in one where 0V & 3.3V planes are ~0.2mm from one another), then I would not have needed the stitching capacitors 

5. GOOD, Adequate cooling for MOSFET

Having such a tiny board does not leave much space for cooling the MOSFET (BSC040N10NS5), which according to the datasheet has a thermal resistance of 50K/W for a 6cm² area. The most I can give it is ~3cm², and that's split up over top & bottom copper:

So I am expecting the thermal resistance to be ~100K/W, which seems to be enough as at full load (10A continuous) the MOSFET is expected to operate at ~35°C above ambient. Actual rise will likely be slightly lower as I am pulsing the MOSFET at ~7Hz 

BONUS:

• The top & bottom "heatsink planes" are stitched together with x12 0.4mm diameter vias
• I could add more but I would be getting to the point of diminishing returns

The Bad

1. BAD, Input filters on all connectors could be better

To improve radiated immunity (especially for a multi-board design) I need to pass all nets coming in/out of board through a common mode choke as soon as they transit into EMZ1. This would stop any transient voltages (say from a near ESD event) creating transient currents in the conductors, and confusing what each board considers 0V to be:

Next up, the 10A pi-filter I am using is not ideal as both source and load impedances are LOW, where as a pi-filter is better when both are HIGH:

2. BAD, Tack & pad clearance to reference plane edge

Current board envelope is the largest I have space for in the reciever, and even with that I am forced to cram component pads and tracks right up to the reference plane edge. If I had more space I should space the tracks & pads to be at least 3mm away from reference plane edge, otherwise I can expect to have worse EMC performance...

3. BAD, Board is not designed for manufacture ;^)

This one is not a huge issue as I will be assembling the board myself. But if I was to revise the board to make it more suitable for manufacture, I would:

• Add fiducials, so that pick and place machine has an accurate reference point
• Move SMD components to be at least 2-3mm away from board edge, so that pick and place machine can actually clamp the board. Otherwise give the board a meaty panel

Schematic

And for those curious here are the schematics so far: