NZXT GRID+ Review & Alternative Fan Control Software

I was looking for a digital chassis fan controller for my main rig and stumbled upon the NZXT GRID+ digital fan controller. As my current motherboard does not support non-PWM chassis fan speed control via software, I looked for a software based solution that I could stick inside my case to manually control the fan speeds as the Corsair AF120 fans in my rig are noticeably noisy even when my system is idling (probably because my motherboard is driving them at 1100RPM 24/7). I personally find slot and drive bay based rheobus/digital controllers unappealing as they somewhat alter the outer design of my case. LinusTechTips had some pretty decent things to say about the NZXT GRID+ so I decided to drop the 35USD and pick it up from a local reseller.


It arrived yesterday in some standard packaging. However, it wasn’t until I had setup the drivers and software that I realized the controller had a ton of limitations. Specifically :

  • It’s a 6 port, single channel controller. It can detect the RPM pulse signal from all 6 ports but speed adjustments are applied equally to all ports.
  • Speed adjustments are percentage based (with 5% increments) and are limited to between 40-100% (firmware limit).
  • You can’t turn off the fans completely.
  • The provided NZXT CAM software is an absolute piece of garbage. Cloud PC fan speed management? A ‘companion’ for my PC? Remote fan speed control software via a mobile app? The process is constantly between 1.5%-30% of CPU usage on my OCed i7-2600k and it’s memory usage hovers between 120-200MB’s. I wanted a fan speed controller for my PC, not an escort.
  • The user reviews at Newegg, Amazon as well as NZXT’s own support website highlight the issues with their provided ‘CAM’ software and it ranges from system stability issues, resource hogging and poor sensor readouts.

Not wanting to toss the device away, I decided to see if I could reverse engineer their drivers and come up with my own control software. It turned out pretty okay.

Figuring Out the Drivers

The first thing I did was to poke around my Device Manager to see what drivers the CAM software had installed. I was pleasantly surprised to find this :

NZXT GRID DriverIt had installed a ‘USB Serial Port’ COM device. This meant it was probably using some sort of USB-Serial adapter chip. After some further poking around in the CAM software folder, I noticed a folder called ‘GridChipsetDriver’ next to something called the Kraken driver (which I’m guessing is for their Kraken CPU cooler line — something that’s also probably severely broken by the introduction of their CAM software). Within this folder, there was a README which stated it was for the MCP2200 Driver INF File. The MCP2200 by Microchip Technology is a USB-UART serial converter which identifies as a USB CDC device. Okay, so I decided to check out what was being sent over in COM3 during the operation of the CAM software.

For this task, I downloaded a trial copy of Eltima’s Serial Port Monitor for Windows. The moment I started the NZXT software, I was able to see serial communication on the COM3 port and capture the serial read/write commands.

Debugging the Serial Protocol

This was the output from the serial port debug session :

NZXT GRID+ DebugIt was a binary protocol operating within 1-6 bytes of data per request/reply. The COM port operates at 4800 baud 8N1. I was able to map the protocol as follows :

Command Send (hex) Recv (hex)
Initialization C0 1F
Set FAN RPM 40% 44 00 C0 00 00 06 00 01
Set FAN RPM 45% 44 00 C0 00 00 06 50 01
Set FAN RPM 100% 44 00 C0 00 00 0C 00 01
Poll FAN1 RPM 8A 01 C0 00 00 [00 00] (uint16)
Poll FAN2 RPM 8A 02 C0 00 00 [00 00] (uint16)
Poll FAN3 RPM 8A 03 C0 00 00 [00 00] (uint16)
Poll FAN4 RPM 8A 04 C0 00 00 [00 00] (uint16)
Poll FAN5 RPM 8A 05 C0 00 00 [00 00] (uint16)
Poll FAN6 RPM 8A 06 C0 00 00 [00 00] (uint16)
Poll Total Voltage 84 00 C0 00 00 [00] [00] (uint8 uint8)
Poll FAN1 Amperage 85 01 C0 00 00 [00] [00] (uint8 uint8)
Poll FAN2 Amperage 85 02 C0 00 00 [00] [00] (uint8 uint8)
Poll FAN3 Amperage 85 03 C0 00 00 [00] [00] (uint8 uint8)
Poll FAN4 Amperage 85 04 C0 00 00 [00] [00] (uint8 uint8)
Poll FAN5 Amperage 85 05 C0 00 00 [00] [00] (uint8 uint8)
Poll FAN6 Amperage 85 06 C0 00 00 [00] [00] (uint8 uint8)

The return values for the RPM polling commands are 2-byte unsigned values while the fan voltage and amperage polling commands return 2x single byte unsigned values. You’ll need to convert to decimal representation to get the values. For example :

POLL FAN1 RPM – C0 00 00 03 00 = 0x0300 = 768 rpm
POLL TOTAL VOLTAGE – C0 00 00 0B 01 = 0x0B 0x01= 11.01 volts
POLL FAN1 AMPERAGE – C0 00 00 00 19 = 0x00 0x19 = 0.25 amps

Wattage calculation is performed by taking the total voltage multiplied with fan amperage readout.

Writing My Fan Control Software for the GRID+

Within a couple of minutes of figuring out the protocol, I was able to quickly prototype a simple .NET application in Visual Studio 2013 to control and read values from the fan controller.

GRIDfanGRIDfanWith serial port, fan speed and polling interval control, it uses about 0.1% CPU and 5MB+ of RAM while active (as opposed to the 1-30% CPU and 120MB+ resource usage of the original CAM software). The resource consumption of the software can further be lowered by increasing the polling interval with the downside being slower fan read/control times. It still needs CPU/GPU/ambient temperature readout which will allow for custom fan speed control curves — but I’m pretty happy with the software as it is.

If you’re using the NZXT GRID+ digital fan controller and are currently frustrated with the bundled software, the drivers, binaries and full VB .NET source code for my app can be downloaded here. Feel free to make any modifications you like so that the GRID+ hardware works better for you.


– Updated the source + binaries to include wattage calculation

Re-implementing Astro-Maxis IPTV

Astro Beyond IPTV

A couple of weeks ago, I visited a test site with my good friend klseet along with some representatives from a popular home router company to look at an issue they were having with their router firmware — they couldn’t get Astro IPTV w/ Maxis working over their routers. With Unifi’s HyppTV, it’s a simple task of tagging and untagging VLAN 600 traffic directly into the set top box which handles DHCP, HTTP and UDP multicast video streams. They had tried implementing this same method for Astro w/ Maxis which operates on VLAN 823 (when riding on TM infrastructure) with limited success — so I suggested a packet capture session to reverse engineer the Thompson/Technicolor equipment and how it handled the IPTV traffic.

Astro IPTV w/ Maxis Standard Configuration

Astro-Maxis IPTV Diagram

The network topology for Astro-Maxis IPTV and FTTH is rather simple. The Maxis Thompson router is usually connected to port 2/3/4 of the TM GPON/VDSL modem with 4x VLANs trunked over the cable. These are VLANs 621/821/822/823 which provide PPPoE, VOIP, TR069 (Management) and IPTV connectivity. The Thompson/Technicolor router binds multiple DHCP clients on VLANs 821-823 while running a PPPoE client on VLAN 621. This means that all Maxis services are handled by the Thompson and no VLANs are bridged through to the customers home network.

On the home facing side of the network, customer PCs as well as the Astro IPTV set top box are connected to the same switch and obtain a dynamic IP in the same subnet from the Maxis router ( or This is a pretty neat way to setup the network but it does increase the routing complexity on the Maxis router — it’s handling 4x networks .. or 3x’s + 1 public IP /32 if you’re using the domain. There are a few reasons why Astro/Maxis would have selected this configuration :

  1. The Astro IPTV STB requires Internet connectivity. By keeping it on the same subnet as the user PCs, it can authenticate its digital smart card on Astro’s cloud via the Internet.
  2. Astro could choose to run Internet apps on the STB such as YouTube without running into any IP blocks from Google as every STB would have its own public IPv4 address.
  3. Unicast content (those video streams you can pause/rewind/fastforward) can be delivered over their web CDN however at the cost of the users internet bandwidth.
  4. The Astro STB uses the Internet connectivity to download EPG (Electronic Program Guide) data related to the users subscription..
  5. Users can setup multiple Astro STBs in the same household with minimal issues.

How Does It Work?

On the Astro IPTV STB ..

  1. When the Astro STB is booted, it first requests for a DHCP lease on the network it’s connected to (uses DHCP Option 60 Vendor Class Identifier == NDS:METRO:STB). In this case, the Maxis router assigns a IP to the box :
    astro-stb-seq-1If this step fails, the STB will report lack of IP connectivity and may or may not fallback to the satellite feed (if connected).
  2. Once it obtains a valid DHCP lease, it attempts to connect to the Astro CDN over the Internet to authenticate and download the EPG information. If this step fails because of lack of Internet connectivity or because the STB is in a VLAN 823 bridging setup, only 1 channel will be viewable once the STB fully boots and it will fallback to the satellite coaxial to retrieve the video stream. At the test site, this was channel 180 for whatever reason.
  3. Once the EPG data has been downloaded, the STB sends an IGMPv2 Membership Report (JOIN) for the channel that has been selected. This results in an encrypted MPEG TS UDP multicast video stream being forwarded to the STB by the Maxis router via VLAN 823 :astro-stb-seq-2
  4. When the user changes channels, the STB sends an IGMPv2 Membership Report (JOIN) for the new channel and an IGMPv2 Leave Group (LEAVE) for the previous channel. This cuts off the previous UDP multicast video stream while the video stream for the new channel is received .. ensuring that the bandwidth consumption does not go over the 10-14Mbps VLAN bandwidth cap :astro-stb-seq-3

On the Maxis Thompson/Technicolor router ..

  1. The Maxis router has both a public IPv4 address (via VLAN621 PPPoE) as well as a private IP (via VLAN823 DHCP).
  2. An igmpproxy runs on the Maxis router which takes the IGMPv2 group join/leaves from the Astro STB and converts it into an IGMPv3 message to send out over VLAN 823. This proxy also handles the replication of the encrypted UDP video stream towards the Astro STB :astro-stb-seq-4

So to recap, the Astro STB requires Internet and VLAN 823 multicast connectivity. It’s placed in the same subnet as other systems behind the Maxis router and the Maxis router runs an IGMP proxy which forwards multicast data between VLAN823 and the home network while converting between IGMPv2 and IGMPv3.

Re-implementing the Stock Configuration on a Different Router

Seet had brought along his Mikrotik RB751 on site to perform the packet captures and I decided that I could probably re-implement the IGMP proxy configuration on it. After setting up VLAN 621 and VLAN 823 on the Mikrotik and configuring the PPPoE client + masquerade NAT for the LAN clients, I downloaded the appropriate Mikrotik multicast.npk package for my router firmware (which comes with an IGMP proxy). Once that was done :

  1. I added VLAN823 to my Mikrotik and setup a DHCP client on the VLAN :astro-stb-mikrotik-1
  2. Configured the IGMP Proxy as such :astro-stb-mikrotik-2

I was then able to receive Astro multicast video via the Mikrotik router without any issues. With the IGMP proxy working at 10mbps for a HD video stream, the CPU usage on the RB751 was roughly 7-9%. I’m looking forward towards the new consumer router firmware with both Unifi and Maxis profiles but I don’t have an ETA on them. If you can’t wait and need a replacement router for Astro-Maxis that will handle everything except the VOIP, Mikrotik makes a great replacement router.

Unifi Uncapped – 1Gbps Home Broadband in Malaysia

Bonded 100mbps x 2 ports

One of the issues I have with home broadband in Malaysia are the ridiculously slow packages and high prices. I’ve been a Unifi VIP20 user since March 2010 and competitors have only introduced slightly faster packages at equivalent prices. TIME broadband users seem to enjoy jerking each other off with their 100Mbps packages limited at 100GB/month but the tiny quota and limited availability rules that out as an option for me (same goes for LTE based services). As such, I’ve spent a small portion of my time in the past month working on uncapping my VIP20 line with success up to 400Mbps upstream/downstream (200mbps uncap speedtest shown in the image above). I will highlight a few client side challenges of delivering >100Mbps internet service over the existing Unifi infra in this post.

Physical port limitations of GPON, VDSL and your BTU

Unifi currently uses two access technologies for delivery towards customers – VDSL2 and GPON. VDSL2 users will require 2 modems at minimum for >100Mbps delivery as the technology appears to hit a ~115Mbps ceiling in real world deployments based on my observations. A minimum of 2 copper ports would be required for stable delivery of any service exceeding 100Mbps. GPON users on the other hand have better luck — it’s pretty easy to hit 1Gbps assuming you have the right access equipment as the technology is specced for 2.5Gbps downstream delivery. The main issue with GPON on the Unifi network at the moment is that most of the BTU models only have FastEthernet ports (limited to 100Mbps full duplex). TM would need to replace their BTUs with models utilizing gigabit ports before >100Mbps service could be possible. As such, with PPPoE and VLAN overhead you’d see something like this if you attempted a >100Mbps uncap on your existing setup :


However, getting around the 100mbps port limitation is trivial. A working method appears to be channel bonding/link aggregation using the balance-rr option which spreads the layer 2 frames equally over multiple NICs in the bonding group allowing for greater throughput :


If you have Unifi or a similar service provisioned on all 4 ports (service VLAN accessible on all BTU LAN ports), you should now have 400mbps aggregated throughput on the bond interface. Usually, the switch on the other end of the bonded interface ports needs to be configured into a LAG (Link Aggregation Group) with the same bonding mode or you risk creating a switching loop, however in my experience it appears that the BTU switch ports are able to update its CAM table fast enough that the effects are minimal on PPPoE and TCP performance.

Logical Routing Limitations

Assuming you have 5x 30mbps PPPoE accounts to utilize (~150Mbps), the next challenge would be balancing your connection load over 5x sessions. Multilink PPP (MLPPP) appears to be rejected by the PPPoE server so the usual setup in client networks appears to be per connection/nth load balancing :


The downside of using this setup is that your client router would have to manage 5x distinct public IPs within 5x PPPoE sessions. IP connections by your clients would still be limited to the maximum rate of a single PPPoE link and you would need to utilize 5x threads at minimum to utilize the 150mbps aggregated bandwidth of your PPPoE sessions — only networks with large amounts of clients or protocols such as BitTorrent/HTTP with download accelerators would benefit from this. The easiest way around this limitation would be to utilize a bonded layer 2 VPN system such as OpenVPN in TAP mode over 5x sessions with balance-rr bonding configured on the client towards a nearby OpenVPN server with a large amount of available bandwidth (I’ve used dedicated servers in Singapore/Japan with much luck) :


Using this VPN architecture, connections from behind the router’s NAT will only have a single public IP on the Internet and it is possible to achieve maximum downstream/upstream throughput while only utilizing a single TCP/UDP connection as the bonding driver will handle load balancing at layer 2.

I’m hoping that the local ISPs will introduce faster + affordable broadband packages in the future as the current offerings are pretty slow compared to other countries and the existing PON access architecture can support 100Mbps+ speeds without much issues (based on my tests anyway).

DIR615 TTLI’ve been receiving a lot of messages regarding my old website —
as it’s been down for quite a while. I set it up back in May 2010 as a resource for new users .. right after the Unifi product launch. This was when everything was a bit murky and not many users knew how the service worked. Three years+ later however, there are newer, better resources available such as :

In any case, for those of you who would still like to access the old site .. I’ve setup a mirror over here.