Using the D-Link DWA-X1850 Wi-Fi 6 USB adapter on Linux (RTL8832AU 802.11ax)

After the introduction of wireless routers, phones and PCIe cards featuring the next generation of Wi-Fi, known as 802.11ax (or simply Wi-Fi 6), finally the first USB 3.0 adapters have arrived on the market:

The ASUS USB-AX56 adapter has two external antennas, while the D-Link DWA-X1850 comes in a more compact case with built-in antennas.
Both support 2 streams dual band on 2.4GHz and 5GHz, labelled “AX1800”, which translates as:

  • 40 MHz channel width on 2.4GHz, using MCS index 11 and short GI (0.8µs), resulting in a nominal rate of 573.5 Mbps
  • 80 MHz channel width on 5 GHz, also MCS 11 with short GI (0.8µs), resulting in the nominal rate of 1201 Mbps

Combining both rates, these are marketed as AX1800, although you typically can’t bond connections and will rather end up with a Link Rate of 1201 Mbit/s only, which may be somewhere around 500 Mbit/s of real throughput (all while assuming you are located very close to the router, and none of your neighbours are transmitting on the same wifi channel, of course).

While the Link Rate will degrade quickly when a few walls need to be penetrated, the receive sensitivity of this new generation of chips can still be considered superior to previous ac adapters, although the limitation to 2 streams might be an issue. Especially if your router supports AC with 3×3 or 4×4, older adapters like the infamous “Death Star” D-Link DWA-192 might still be a better choice.
It uses RTL8814AU and supports AC1900, i.e.

  • 3 spatial streams with 40 MHz channel width on 2.4GHz, using MCS index 9 and short GI (0.4µs), resulting in 600Mbps
  • 3 spatial streams with 80 MHz channel width on 5GHz, using MCS index 9 and short GI (0.4µs), resulting in 1300Mbps

This may seem like not much of a difference, but keep in mind that MCS11 will degrade more quickly with a few walls in between, and when the connection is at MCS9, 2 streams of AX will only be a rate of 960.Mbps compared to 1300 with 3 streams AC.

But back to the first USB AX adapters hitting the markets right now:
Both the ASUS USB-AX56 and D-Link DWA-X1850 are based on the Realtek RTL8832AU chipset, which is the 2-stream variant of the RTL8852AU – this is the most important information when it comes to finding a driver that works on Linux.

When searching github, you will find the repository
which contains the driver source code from Realtek. There are also a few documents that explain how to introduce your device’s USB VID and PID into the driver:
The relevant file to modify here is os_dep/linux/usb_intf.c, the USB VID e.g. for D-Link is 0x2001, the PID for the DWA-X1850 adapter is 0x3321. For the ASUS USB-AX56, it would be 0B05:1997.

You can find this already patched in my fork of the repo on github:

// Update: The most current maintained fork of this driver is now available from the repo of lwfinger, please use this instead:

Now just clone that repo, make and sudo make install, then re-plug the dongle.
After being plugged in, the DWA-X1850 is in USB Mass Storage mode, which can be switched to network adapter mode by ejecting the virtual drive (eventually, it seems this device should be added to the USB modeswitch project).

The blue status LED is currently not working, maybe this needs some addition GPIO definition which is specific to this device.

Also keep in mind that this driver, although being built from source, uses the Realtek proprietary structure, which may not be what the Linux Wireless developers are aiming for.

A corresponding Linux Wireless compatible driver would be “rtw89”, which currently supports only the PCIe version of RTL8852, but I’m sure this may soon be updated to include the USB variants, and one day be available with Ubuntu and other common distributions. For now, at least we have the Realtek driver.

Interfacing the MH-Z14A carbon dioxide sensor with OLED display and ToF Laser distance sensor on STM32

When it comes to indoor air quality, especially during the cold days, we usually think of trying to keep the humidity at an acceptable level to prevent irritation of the respiratory tract occurring from dry air caused by ventilation, which reduces the relative humidity of outside air (that was well-saturated with moisture while it was still cold) by heating it up indoors.

However generally avoiding ventilation will sooner or later result in poor air quality, which is way more difficult to measure than humidity itself: indoor pollutants, mostly from human metabolism (but also furniture and everything else in your house) can vary among countless groups of complex substances that would be impossible to quantify analytically by reasonable means.

The carbon dioxide level is thus often used as an indicator of how much the air is “used up” by human respiration, so you can get a good estimate about air quality in your room or office by just monitoring that single component:

While fresh air is close to the average outdoor level of around 400ppm CO2, you should try to keep your indoor level below 1000ppm to prevent fatigue and reduced cognitive performance.
Exceeding 4000ppm can show significant negative effects on concentration and feeling comfortable.

Devices that measure and display the CO2 concentration (just like we are used to from countless thermometers displaying humidity) are still rare and very expensive, also they would require a little more power than a humidity meter running for years on two AA batteries.

Among the first devices bringing a low-cost solution to the mass market was the weather station from netatmo: The pack contains several sensors connected to a base station that will collect all CO2 measurements and transmit them over WiFi – directly to the netatmo cloud servers. The only way to see your local air quality in the same room is by touching the top of the base, which will then illuminate in one of three colours to give a vague estimate of the situation. Everything else works exclusively through the cloud service: They will monitor human activity (and even sound levels!) in your house and show you fancy-looking graphs on the app or website in return.

If that does not sound like the solution you would want to be running and connected to the internet 24/7, you will quickly stumble upon those MH-Z14 / MH-Z14A sensors that sell on AliExpress for less than $20 USD, shipping included.

They come with their own microcontroller and several interface options like Analog, PWM and UART.

The UART interface is somewhat straightforward, especially if you keep sending the same command over and over to query the current value (so there’s no need to calculate the checksum but rather use the static one that matches the command, as given in the datasheet): Send 9 bytes at 9600 baud and receive 9 bytes with the measurement. There’s not even the need to verify the checksum of the received reply – if you’re lazy, you can just read the value from the third and fourth byte of the reply.

For the beginning, you can just wire it up to some USB CP2102 UART module – the sensor module is perfectly fine with using the 5V from your USB port.

Which results in this little proof-of-concpet Python script that will write the current value to the console each five seconds (make sure to pip install pyserial first and adjust your /dev/ttyUSB or COM port number):

import serial, time

z14 = serial.Serial(port="COM13",baudrate=9600)

while True:
	z14.write(bytearray.fromhex("FF 01 86 00 00 00 00 00 79"))
	result =
	print(result[2] * 256 + result[3])

You will notice it takes a few minutes for the sensor to warm up and deliver plausible results.

Also, there seems to be a difference between ZH14 and ZH-14A modules regarding calibration: The 14A variant performs automatic calibration within each interval of 24 hours – in other words, you have to make sure to let in some fresh air from outside at least once per day, so it can calibrate the lowest reading within the previous 24 hours to be around 400ppm! This seems quite annoying, but also makes using the sensor a lot easier on the other hand.

Now a console window scrolling the latest sensor reading may seem quite appealing to the average nerd, but if you want to go for a more netatmo-ish style of standalone device, how about adding a microcontroller with an oled display and a tocuh sensor? The display would show a tiny version of the CO2 graph, similar to the netatmo apps, on the device itself after you activate it with a touch.

And to make it even cooler, I used one of those new-fangled VL53L0X Time-of-flight laser distance sensors from ST – those are basically the successor of the tiny sensors you have in smartphones to detect user presence (to disable the touch screen while holding the phone close to the head) and allow for range measurements of up to two meters. So you don’t even need to touch the device itself, but could rather hover your hand over the device to switch on the measurements display, or use gesture recognition (upwards or downwards motion) for additional functions.

Here’s some example using an STM32F103C8T6 board (mostly since those are less than $2 on AliExpress for an ARM Cortex MCU and also code for VL53L0x is readily available from ST; also there are Chinese clones of the ST-Link / v2 debugger availably for very little money, compared to e.g. JTAGICE debuggers for AVR controllers, or platforms like ESP8266 or Arduino where you have no live debugging by default at all). Also it has built-in USB that you can use for USB to serial or even mass storage (how about donwloading your measurements from a dynamically created .csv-file for example?).

Using STM32 CubeMX from ST you can graphically set your desired pin functions and generate all the hardware-related code, similar to the web-based tool availbale from Microchip / Atmel at for the AVR and ATSAM MCUs).

Here’s my CubeMX file (I actually used both I2C cores for separating the OLED and the ToF sensor for mere simplicity in wiring).

But after all, you should of course use the platform you feel most experienced with, considering that SSD1306 OLED drivers are available almost everywhere, and you can check the VL53L0x library from Pololu for a more lightweight alternative to ST’s bloated C library to control the laser distance sensor.

Next thing would be to make decent case for it: currently my prototype resides in a 3D-printed cylinder without any bottom plate, and I still need to figure out how to fit a battery in there and how to charge it (or probably just run a cable to the nearest usb port).

The final goal would be connecting it to the USB port of some OpenWRT router for data logging and network access, but then again you might as well go for ESP8266 in the first place… And after all, summer is coming closer, making this the ideal project for some spare time in next winter…

pictures will follow 🙂

Neue VR-Bankcards: girocard kontaktlos ohne V-PAY kontaktlos?

Nachdem bereits vor einigen Jahren bekannt wurde, dass die Volks- und Raiffeisenbanken die bundesweite Einführung von girocards mit kontaktlos-Schnittstelle beschlossen haben, zog vor kurzem auch meine Bank nach: Bereits in den Wochen vor der Auslieferung wurden Kunden über einen Hinweis im Online-Banking informiert, u.a. darüber, dass die Kontaktlos-Schnittstelle zunächst inaktiv sei.

Diese solle jedoch automatisch beim ersten Einsatz der Karte am POS oder Geldautomaten aktiviert werden – es geht hier also anscheinend tatsächlich eher um einen Schutz vor Erkennbarkeit des Inhalts der ansonsten neutralen Briefsendung auf dem Transportweg als um eine potentielle Paranoia-Linderungsmaßnahme gegenüber dem zukünftigen Karteninhaber. Dennoch soll dieser die Möglichkeit haben, die kontaktlos-Funktion am Geldautomat der eigenen Bank jederzeit zu de- bzw. reaktiveren.

Und tatsächlich antwortet die Karte im Auslieferungszustand in keinster Weise auf ein angelegtes ISO 14443-Feld – es ist nicht nur die Zahlungsfunktion deaktiviert, sondern wirklich die physische Kontaktlos-Schnittstelle.

Wenn nun die eigene Neugier nicht bis zum nächsten Geldautomaten- oder Supermarkt-Besuch warten kann, wird eben kurzerhand ein altes POS-Terminal aus der Bastelkiste gekramt, und siehe da: Es bedarf – wie erwartet – tatsächlich nicht einmal einer erfolgreich abgeschlossen Transaktion, um das Kontaktlos-Interface zu aktivieren; vielmehr geschieht dies bereits bei einer aufgrund nicht zustande gekommener Internetverbindung abgebrochenen Zahlung (die Kunst liegt am ehesten noch darin, das Terminal zunächst per DHCP-Lease davon zu überzeugen, dass theoretisch eine Online-Verbindung realisierbar wäre, um ein Fallback auf ELV-Offline mit Magnetstreifen zu verhindern)…

Weiterhin wird seitens der Volksbank darauf hingewiesen, dass die neue Karte nun nicht mehr über die GeldKarte-Funktion verfügt. Dies erklärt wohl auch den missglückten Ladeversuch meiner bisherigen Karte am Geldautomat noch vor einigen Wochen (“Sie sind zu dieser Funktion nicht berechtigt”), und auch die Online-Aufladung über unterstützt nun explizit nicht mehr die Aufladung von Karten der genossenschaftlichen Institute. Inzwischen ist sogar die erfolgreiche Durchführung einer kostenlosen Testladung in Höhe von einem Cent Voraussetzung, um den Service nutzen zu können. Anscheinend hat man hier bereits großflächig begonnen, die technische Infrastruktur der GeldKarte im Hintergrund soweit zurückzubauen, dass man sich auch bei EURO Kartensysteme (als technischem Dienstleister der Deutschen Kreditwirtschaft) nicht mehr ganz sicher ist, was nun noch funktioniert und was nicht. Immerhin: Von der Frankfurter Sparkasse ausgegebene kontaktlose girogo-Karten sind weiterhin über erhältnlich und können nach wie vor online geladen sowie an allen GeldKarte- und girogo-Akzeptanzstellen eingesetzt werden.

Möglicherweise ging es den Volksbanken auch darum, keine Verwirrung am POS zu stiften, wenn das Terminal bei kontaktloser Zahlung ungefragt das geladene GeldKarte-Guthaben verwendet bzw. girogo als erstbeste kontaktlose Zahlmethode erkennt, dann aber aufgrund fehlenden Guthabens den Vorgang abbricht.

So ist DF_BOERSE kontaktlos nicht vorhanden, jedoch lässt sich kontaktbehaftet immernoch ein EF_BETRAG in Höhe von 0,00 Euro auslesen. Das maximale Guthaben ist wie üblich beschränkt auf 200 Euro, die maximale Höhe eines Ladebetrags jedoch auf 0,00 – womit die GeldKarte technisch zwar nicht entfernt aber zumindest effektiv deaktiviert ist.

Es finden sich somit insgesamt nur zwei Akzeptanzlogos auf der Karte: girocard und V-PAY.

Gerade einmal neun Jahre nach Ausgabe der ersten Debitkarten mit kontaktloser V-PAY-Funktion durch eine italienische Bank scheint man nun also auch in Deutschland bereit zu sein…

Wie dem auch sei, funktioniert hat die erste Zahlung bei Aldi Nord jedenfalls nicht.

Das Terminal akzeptiert die Karte (ohne PIN) und baut zunächst ordnungsgemäß eine online-Verbindung auf, worauf die Zahlung mit “Systemfehler” abbricht. Kontaktbehaftet funktionierte es dann problemlos (die erste Vermutung bestand somit darin, dass die AID für girocard in der kontaktlosen Variante zwar vom Terminal, aber noch nicht vom Acquirer akzeptiert würde).

Tatsächlich wunderte ich mich schon im voraus, ob auf dem Kundenbeleg hinterher wohl “girocard” stehen würde, oder stattdessen ein Fallback auf V-PAY stattfindet. Die Karte unterstützt laut Aufdruck schließlich V-Pay, und die AID A0000000032020 lässt sich auch über die kontaktlose Schnittstelle problemlos selektieren.

Schaut man sich dagegen den Inhalt des PPSE an, tauchen dort nur 3 AIDs auf:

A00000005945430100 // Girocard Electronic Cash
A0000003591010028001 // Girocard EAPS
D27600002547410100 // Girocard ATM

Grundsätzlich steht es einem Terminal natürlich frei, unabhängig vom PPSE auch wahllos andere AIDs durchzuprobieren, dennoch frage ich mich, warum V-PAY hier nicht enthalten ist. Somit wäre fraglich, ob die kontaktlose Zahlung im Ausland überhaupt funktionieren würde, oder die Karte weiterhin gesteckt werden muss (sofern man denn überhaupt einen Händler gefunden hat, der international nicht nur Maestro akzeptiert).

Kontaktbehaftet lief die Transaktion jedenfalls über die AID A0000003591010028001.

Zweiter Versuch bei Rewe: Hier sind die notwendigen Terminals (Ingenico IPP 350) schon seit Jahren vorhanden, irgendwann wurde die kontaktlos-Funktion dann aber abgeschaltet (vermutlich weil zuviele gleichgesinnte damals ebenfalls erfolglos versucht hatten, mit einer Mastercard zu zahlen, die kontaktbehaftet problemlos akzeptiert wird).
Ich bitte also darum, “mit Karte” zu zahlen (die Diskussion darüber welche Zahlmöglichkeiten denn genau unterstützt würden spare ich mir aufgrund entsprechender Erfahrungen aus der Vergangenheit) – und werde um meine Karte gebeten.
Ich stelle fest, dass ich gerade ebensowenig Interesse daran habe, vor Ort auszudiskutieren inwieweit das denn genau “nur zu meinem Schutz” diene, während die Banken doch gerade das nicht-aus-der-Hand-geben als zusätzliche Verbesserung der Sicherheit und Hygiene propagieren. Die Dame an der Kasse betrachtet jedenfalls die Unterschrift auf der Rückseite und drückt schließlich die Karte mit mehreren Fingern fest auf das Display, als würde sie diese fotokopieren wollen. Das Terminal bittet mich trotz des Betrags unterhalb von 25 Euro um Eingabe der PIN.
Auf dem Beleg steht dann auch girocard kontaktlos.

Dritter Versuch: Nun klappt es auch bei Aldi, allerdings ebenfalls mit PIN-Eingabe.
Auf dem Beleg ist wieder die AID A0000003591010028001 angegeben.

Die Bank verlangt laut Info-Flyer auch unter 25 Euro hin und wieder eine PIN-Eingabe (angeblich erst ab 100 Euro Umsatz bzw. einer bestimmten Anzahl Transaktionen ohne PIN-Prüfung), vermutlich war dies dann auch der Grund, warum es beim ersten Versuch nicht klappte (bei der ersten erfolgreichen Transaktion muss es wohl auch ein CDOL-Update gegeben haben!?), oder es bedurfte auch seitens der Bank erst irgendeiner Initialisierung, die durch das einseitige Aktivieren der Kontaktlos-Schnittstelle nicht erfolgte.

Zusammenfassend lässt sich also feststellen: Die Notwendigkeit einer PIN-Eingabe bei Aldi werde ich zunächst noch weiter beobachten, im Zweifelsfall bleibt es eben wie bisher bei der nicht-genossenschaftlichen Mastercard, wenn meine Bank das so möchte. Bei anderen Supermärkten (die durch gewohnt inkompetentes Personal auffallen) bleibt es ohnehin bei Bargeld, was auch immernoch schneller ist, wenn ich ohnehin erst etwas aus dem Portemonnaie herauspulen muss.

Immerhin: Vielleicht sorgt die steigende Akzeptanz in der Bevölkerung ja zukünftig für weniger irritierte Blicke an den Kassen.

Wozu die Karte übrigens einen Magnetstreifen hat, erschließt sich mir so langsam wirklich nicht mehr. Wahrscheinlich liegt es an den Geldautomaten, die nach wie vor keine Karten mit beschädigtem Magnetstreifen akzeptieren!?
(Wer dieses Vergnügen bereits hatte, oder z.B. auch nur spaßeshalber das Guthaben einer kontoungebundenen GeldKarte prüfen möchte, wird sich unter Umständen wundern, diese nur wenige Millimeter tief hineinschieben zu können…)