NComputing RX420(HDX) Raspberry Pi 4 Thin Client Works with Citrix HDX

NComputing RX300 Raspberry Pi 3 thin client was launched in 2017 with support for the company’ vSpace Pro desktop virtualization solution for Linux and Windows, and I tested it accessing a Windows Server 2006 host located in Singapore, and performance was pretty good for a remote system as I could play 1080p YouTube videos, browse multiple tabs in Chrome, etc.. relatively smoothly.  This type of solution is aimed at businesses, for which it may be easier and cheaper to handle a fleet of devices using thin clients and servers, instead of traditional PC’s.

Beside its vSpace Pro RX300 thin client, NComputing also introduced another Raspberry Pi 3 thin client that same year with RX-HDX using a design similar to RX300 but instead integrating support for Citrix HDX virtualization technology. NComputing now unveiled an update for the latter with RX420(HDX) thin client based on Raspberry Pi 4 SBC with 2GB RAM.

Hardware-wise, NComputing RX420(HDX) thin client is basically a Raspberry Pi 4 board with an enclosure, a MicroSD card, and a power button & LED


  • SoC – Broadcom BCM2711 quad-core Cortex-A72 @ 1.5GHz with VideoCore VI GPU supporting OpenGL ES 3.0 graphics
  • System Memory – 2GB LPDDR4
  • Storage – 16GB MicroSD card
  • Video Output – 2x micro HDMI ports up to 4K @ 60 Hz
  • Video
    • Decode – H.265 up to 4Kp60, H.264 up to 1080p60
    • Encode – H.264 up to 1080p30
  • Audio – Stereo audio via 3.5mm audio jack, digital audio via HDMI ports
  • Connectivity
    • Gigabit Ethernet (RJ45)
    • Dual-band (2.4 GHz/5.0 GHz) 802.11b/g/n/ac WiFi 5
    • Bluetooth 5.0 BLE
  • USB – 2x USB 3.0 ports, 2x USB 2.0 ports.
  • Misc – Power button & LED, Kensington lock support
  • Power Supply – 5V DC via USB-C connector
  • Dimensions – 93 x 76 x 30mm
  • Temperature Range – 0 – 50°C

Granted the enclosure is cute, but the software part of the interesting part with RX-420 (HDX) running the “locked-down” Linux based Stratodesk NoTouch OS Thin Client OS optimized for Citrix HDX virtual desktop environment. As shown in the diagram above you could have a fleet comprised of RX400 (HDX), the earlier RX-HDX, and Intel-based EX400 thin clients and controlled from a single desktop running Stratodesk’s NoTouch Center software which aims to ease deployment, configuration, updates, and maintenance.

Some other features supported by RX42 (HDK) thin client include Skype for Business (RTME), Citrix Casting and Proximity Authentication part of Citrix Ready workspace hub ecosystem.


The Thin client can also be used for another type of application: IoT edge devices using Microsoft Azure Edge technology through Citrix Workspace IoT.

NComputing RX420(HDX) thin client should be available now, but the company did not disclose pricing. You’ll find more details including documentation and more videos on the product page.

Via LinuxGizmos

Share this:

Support CNX Software! Donate via cryptocurrencies or become a Patron on Patreon

24 Replies to “NComputing RX420(HDX) Raspberry Pi 4 Thin Client Works with Citrix HDX”

  1. Sure the enclosure is cute, but I don’t see much room for the absolutely mandatory huge heat sink, so it’s possible that it will randomly throttle depending on what’s done with it :-/

      1. But the RPi4 heats like crazy even in idle. Mine has the sandwich-type heatsink and is still hot sitting on my desk doing nothing. So the small heat sinks on the photos above will not solve this. If they don’t need all this power they’d rather use the 3B+ where the A53s are way cooler than the A72.

        1. > the RPi4 heats like crazy even in idle.

          Mine idles at below 50°C with a slight overclock at 1850 MHz (0.9V Vcore due to over_voltage=2 and arm_freq=1850) at an ambient temp of 23°C. Neither enclosure nor heatsink.

          And when running sbc-bench not even the multithreaded 7-zip benchmark results in throttling below 1850 MHz:

          So while idle temperatures are somewhat high after applying all the firmware updates the other prominent heat sources are lowered and if no overclocking is chosen I guess applying a small heatsink will be sufficient even in such a tiny and cramped enclosure.

          1. If the hot air stays inside a plastic case, then that is basically an oven. No enclosure means no oven.

          2. I know. That’s why both willy and me constantly try to convince board makers to put the SoC on the bottom PCB side since in combination with a (partial) metal enclosure it allows to get the heat out of the enclosure.

            Anyway, just simulating an oven (putting a plastic cover on top of the RPi 4):

            And when running sbc-bench again now throttling happens and with the multithreaded workload ARM clockspeeds get reduced down to 1234 MHz:

            But if we keep in mind that DVFS seems to be broken on the RPi 4 right now (not lowering Vcore when clocking down the CPU cores only makes partially sense), then without overclocking and especially not setting over_voltage most probably no throttling will occur even at 1500 MHz…

          3. If only a RPI4+ had its processor on the bottom for cooling it would be awesome. Only that would be admitting they made a design mistake so won’t happen (soon).

          4. > that would be admitting they made a design mistake

            Well, maybe we should look at this from the target audience’s perspective: that’s mostly clueless people buying millions of these devices. Those people most probably prefer an enclosure that gets only a bit warm rather than getting hot since efficiently dissipating heat from the inside.

            From this point of view this all makes sense especially since average RPi users with an enclosure will not be able to tell whether their board suffers from overheating/throttling or not.

            Linux is still a 2nd class citizen on the RPi and every usual Linux tool that tries to display the CPU’s clockspeeds will show fake values in case the primary OS on the RPi (ThreadX) already started to clock the ARM cores down due to overheating or undervoltage. You need to query the VideoCore on those things to get actual clockspeeds but since nobody knows also nobody cares. And those who care can spend the 20 bucks for a FLIRC or similar enclosure.

            What’s happening in the comments sections here or somewhere else is completely irrelevant for average RPi buyers…

          5. The average RPI user will prefer a hot metal case over a throttled CPU, just like the people here. They too want to get what they were promised.
            The RPI Foundation keeps on hiding this RPi4 overheating problem deep inside their troubleshooting forum, where is has 27 pages of complaints vs just 23 for some HDMi problem which tops their front trouble page.

        2. > the RPi4 heats like crazy even in idle.

          With regard to this an annoying observation. At least with latest ThreadX release (version f9902d1dd832673e8296a737271a2eb0649265b9 from Jan 6 2020) they do not lower Vcore voltage when idle / running at low clockspeed:

          So maybe another future ThreadX update will implement DVFS more correctly which will result in a few degree less in idle.

        3. I bet with a proper downclock + heatsink the rpi4 temperature isn’t going to be a problem at all. I have an OrangePI PC2 with enclosure and tiny heatsinks and limiting the cores to 800Mhz it goes way cooler. I tested it for a logitech media server and there was virtually no difference between stock clock and 800Mhz, so why to bother addressing the issue with a higher price solution when you can fix it completely at 0 cost? I tell you for a thin client is much more than enough, because as been said here, what is used is basically gpu and network. I’ve used thin clients in the past with single core 1Ghz old cpu and they were perfectly capable of delivering fast response remote connections with no more help than the CPU and a very discrete GPU coupled with 128MB of memory.

          1. > an OrangePI PC2 with enclosure and tiny heatsinks and limiting the cores to 800Mhz it goes way cooler.

            The Allwinner H5 on your board got working DVFS (dynamic voltage frequency scaling) which has been done by us (linux-sunxi community, the tool in question was this: This is some part of the magic why limiting clockspeeds to 800 MHz with Allwinner results in lower consumption and temperatures: since the core voltage the CPU cores are fed with are adjusted to the clockspeeds.

            On the RPi 4 (currently) DVFS seems to be broken, the CPU cores are fed with the same voltage regardless of the actual clockspeeds. Most probably this happens to masquerade stability problems (the PMIC not ramping up voltages fast enough under full load for example) so maybe a future ThreadX update might fix this and then an idle RPi 4 or one with lowered clockspeeds consumes less and stays cooler. But currently lowering clockspeeds has not the same effect as on platforms with working DVFS.

          2. I get your point, but then better stick to RPi3. The A53 is way more efficient than the A72. The A72 reaches the highest performance numbers but at similar consumption the A53 will be faster. Oh and BTW the A55 in the VIM3L is even much better 🙂

          3. > I get your point, but then better stick to RPi3.

            The RPi 4’s advantage especially for this thin client use case is dual display support. And we should keep in mind that

            a) the consumption/heat problems of the RPi 4 are not directly related to the ARM cores (see the various firmware updates that addressed PCIe power management for the USB adapter, memory controller, PMIC ‘load-step’ behavior)

            b) the VideoCore has better graphics/video capabilities

            c) the A53 cores on RPi 3 are 40nm, while the A72 are 28nm. The difference between idle and ‘full load’ on the RPi 3B+ and 4 (with all updates applied) is almost identical at around ~4W while the A72 performs at least 1.5 faster. So at identical performance level the performance/consumption ratio of the RPi 4 is better.

            > Oh and BTW the A55 in the VIM3L is even much better.

            Khadas submitted benchmark results recently and I’ve to admit that I’m not that impressed by the raw numbers. But if you’re talking about performance/consumption ratio of course you’re right. 🙂

          4. Good point for the dual display, I don’t even use one 🙂

            Regarding VIM3L, yes I was speaking about power usage. You basically get the same perf as four 2 GHz A53 cores without even needing a heatsink. I installed a tiny one (a single DDR chip one) on mine before closing the box just to say I put one, but given that it was barely warm to the touch on the table before, I don’t expect it to bring any significant benefit if at all.

    1. (I’m an NComputing representative FYI) Thought we’d jump in and provide some additional information. You’re absolutely right, the Pi4 kicks off a huge amount of heat. Without some sort of cooling solution, putting it in a case would cook it. In addition to the passive cooling provided by the heat sinks we employed with the Pi3 devices, the RX420 also has a fan inside. We are actively measuring the core temp and adjusting the fan speed as needed – this helps keep it cool (and mitigates the noise of an always-on fan). No CPU throttling here!

  2. VMware support (using Blast, or PCoIP) would be huge for my company. I’d probably replace all my Wyse terminals with this, if it had VMware support (yes, I think it can use RDP; we don’t use RDP).

      1. This article is about terminals. I am saying it would be fantastic if this terminal supported PCoIP and/or Blast protocols.

        In the use-case of this article (running as a terminal) it makes no difference if it can run ESXi or MS-DOS.

  3. Our school uses L300 Ncomputing terminals with MS Server 2016 on Intel CPU servers: graphically not very capable but ok for Internet browsing, editing text etc. Less electricity usage so less backup needed.
    Do keep in mind software prices / licenses with Ncomputing; juicy hardware might dazzle you and they are a bit coy about the former.

Leave a Reply

Your email address will not be published. Required fields are marked *