Tech Flashback: Radio Scanning (feat. Uniden UBC93XLT, DSE DTS-96, Icom IC-R20)

Towards my later high-school years, in the mid-2000s, armed with a small amount of money, I picked up the hobby of radio scanning. As a person who was curious by nature and had built a number of FM radio microphone “bug” kits, I always wondered exactly what was going on “behind the scenes” – what were those employees on their handheld radios talking about? For a modest outlay of about AU$300, a radio scanner promised to let you into this “secret” world, kind of like “gossip for nerds”. While it was already late in the days of the scanning hobby, there were still many transmissions worth listening to.

What is “Scanning”?

The hobby of scanning is pretty much named after the “scanner radio”, aptly named due to its scanning mode of operation. Unlike a regular broadcast receiver, or a handheld radio transceiver (sometimes known as a walkie talkie) that would be set to a channel and stays on that channel, a scanner radio is configured in such a way that it has a number of channels (e.g. by having a crystal bank or programmable PLL/VCO synthesizer) which it scans across, only stopping when it receives a signal strong enough to break the squelch.

As most professional radios are only used in case of an immediate need to pass messages, the channels (simplex or repeater output) often remain quiet for a lot of the time. A radio that only listened to one channel wouldn’t be much fun because it’d be silent most of the time. As a result, the scanner allows you to monitor multiple systems (e.g. police, fire, ambulance, delivery drivers, taxis etc) by tuning rapidly between their frequencies and stopping only when it receives a transmission. When multiple simultaneous transmissions are occurring, you will miss one (or the other) transmission, but this was an “acceptable” trade-off compared to sitting in silence or having an (expensive) radio for each frequency!

The transmission frequencies used for these professional radios are outside those normally used for broadcast and use much narrower modulation modes, lower transmission powers and can also convey low-speed data using various modulations (e.g. paging). This is why a specialist radio is needed, however, due to the state of radio technology in the early 2000’s, most transmissions were still analog narrowband FM in commercial bands, so all you needed to get started was the frequencies that a given organisation uses!

Back in those days, wide bandwidth SDR receivers were not a reality – even the computing power needed to realise the DSP computations needed to handle multiple channels simultaneously were too taxing for many home computers. It was not until 2010 that I obtained my first 2Mhz-bandwidth SDR which was enough to stress out even a decently specced dual-core Intel Centrino Duo T2300E-based laptop on a single channel decode!

Uniden Bearcat UBC93XLT Scanner

My first scanner was actually the prior model – a UBC92XLT, however, I ended up selling that off as surplus to needs while keeping the UBC93XLT which I purchased second hand at a good price. To my knowledge, the two units shared identical specifications, with the exception of an updated included radio frequency database CD-ROM. While a big deal is made about their inclusion, those CD-ROMs were woefully out of date – it was just more useful to look up ACMA’s Radiocommunications Register directly for the frequencies we needed! Otherwise, you could just do a blind sweep of the frequencies hoping to catch a transmission …

The UBC92XLT and UBC93XLT was sold as a whole retail bundle including a frequency database CD-ROM, “rubber ducky” antenna, earphones, rechargeable batteries, a car cigarette lighter adapter and a power adapter for about AU$300 in Dick Smith Electronics. This model was the “upgraded” UBC72XLT which featured support for the UHF band, making it a little more expensive but was something I felt was good to have. It had a 200-channel memory separated into 10 separate banks, support for 25-88, 108-174, 400-512, 806-956Mhz frequency ranges and “close call” capture of high-powered nearby transmissions allowing for detection of unknown frequencies. There were also pre-programmed service search banks for police, railroad, air, marine, UHF CB and AM CB, although these weren’t exactly that useful.

The front of the unit had a keypad, with most buttons having more than one feature that can be accessed by using the Func+ key combinations. This was already considered slightly complicated by some due to the segment-LCD display being slightly unintuitive to operate. The speaker in the unit is also in the front, although often when out and about, you’d rather use the headphone output.

On the rear, there is a belt clip that allows for you to conveniently wear the unit when out and about. I have also modified the unit to provide the “discriminator output”, basically an unfiltered output from the demodulator for use with data signal decoding over the sound card. The battery compartment door can be completely detached, with the scanner running on 2xAA batteries. An internal switch controlled whether the unit would attempt to charge the cells or not.

The side of the unit has the DC barrel jack input for a 6v 500mA power supply that can charge the batteries and run the unit at the same time.

The top of the unit has a BNC connector for antenna input. It also hosts a 3.5mm headphone socket wired for use with analog and stereo plugs – however, this arrangement caused stereo headsets to have two channels “anti-phase” which wasn’t the best. Two knobs are present – the squelch and volume controls.

The unit was a relatively basic model, but it was quite a robust model which served as a good introduction to the hobby. I wore it around from time to time, getting curious looks from some and being mistaken as a “security officer” by others. It was rare, although not impossible, to come across another scanning enthusiast from time to time but this wasn’t a particularly exciting unit.

When it came to scanners, there were a number of metrics used to compare them – the most important includes the frequency bands supported, the sensitivity of the radio receiver (e.g. 12dB SINAD value), the number of memory positions, the scanning step rate and modulation modes supported. As a rather basic unit, it didn’t feature a stellar specification in any regard, but the biggest limitation was that of the sensitivity. I found that even with an aftermarket antenna with higher gain, many signals were noisy/scratchy. For home use, this wasn’t as big of an issue as the location can be tuned carefully, but when mobile, it can get difficult.

The biggest problem was that the radio market was just beginning to change at this time with the introduction of trunking systems using hybrid digital modes such as Motorola Smartnet, transitioning to full APCO P25 in later years, LTR, MPT-1327. Listening to trunked networks with a conventional scanner was difficult, as the base station changes the output frequency on a rotating basis, so following a complete conversation over multiple overs became difficult especially if the “break” between overs was long enough for the trunking controller to relinquish and reallocate a new channel. I was also getting into amateur radio, so the lack of any SSB modes was also not optimal.

Regardless, this model was enough to begin to listen to a lot of signals – the ethnic radio band, aviation band, transmissions from buses, taxis, amateur radio operators and CB radio users. It was also what introduced me to POCSAG pager decoding, ACARS decoding and P25 trunking system control-channel decoding. After I had this taste, I decided to take things further.

Even after it became less useful to me as a scanner radio or a signal source for decoding, there is a “hidden” button combination that enables a frequency counter mode, so it can be used to check an RF device for its output frequency.

Dick Smith Electronics DTS-96 Digital Scanner

With the evolution of radio towards digital technologies, the most important local radio system was the NSW Government Radio Network which hosts all of the fire, ambulance, roads and transport officer staff to name a few. This trunked system began as a Motorola Smartnet 3600bps system, making monitoring using a regular conventional scanner rather frustrating, but began transition to a P25 system with 9600bps C4FM transmission instead. To listen into these required an APCO P25 capable scanner.

I wanted to purchase a Uniden UBCD396XT “Trunktracker” scanner, but I wasn’t able to secure a good price on those, so I ended up buying a DSE DTS-96 second hand instead for about AU$300. This was a GRE/Radioshack Pro-96 rebadged for the local market, with a large boxy appearance and plasticky build quality. It has a 500 channel memory in 10 banks, which can be loaded and stored into 10 slots + 1 working memory, headlining a 5500 channel memory capacity. It supports a rather (disjoint) frequency range of 26.965-27.405, 28-29.7, 50-54, 68-88, 108-174, 406-512, 806-960 and 1240-1300Mhz. It was a very sensitive radio as well, which I modified with a discriminator tap, but it seemed to also be vulnerable to intermodulation and “birdies” – false signals which appear due to self-generated interference and non-linearities.

The unit had rubber strips on the side which have since fallen off due to age, but the paint is also starting to come off. There is a DC jack for power input and charging, as well as a PC interface port which could be connected to a PC to program the unit or to analyse the trunking data with Pro96Com. This worked much better than using Unitrunker with a discriminator tap, as other radios still didn’t provide a “clean enough” signal, whereas this worked purely in the digital domain relying on the radio to demodulate the signal.

It was a bit of a regrettable purchase, as it was physically rather inconveniently chunky (using 4xAA batteries) with rather shoddy build quality and a problematic volume potentiometer results in a situation where you’re not sure whether the radio is quiet because the channel is quiet or because the pot has gone wonky again. The DSP decoder also produces slightly lower-quality audio than some of its rivals, but is also incompatible with later P25 systems using Linear Simulcast Modulation (LSM). Even though my local station still uses C4FM at this stage, this may not be the case into the future. It was, however, my first and only digital audio capable scanner to date.

Icom IC-R20 Communications Receiver

In fact, two years prior, I decided to drop about $500 on something that isn’t technically a scanner, but more a communications receiver. Bought brand new, this is a much more sophisticated radio compared to the “scanners” above and it definitely shows. The IC-R20 arguably the best handheld radio receiver I have ever owned – and I don’t regret spending my money on it at all. Built like a tank, with a very sensitive front-end, this thing has almost all the features one could ask for in a handheld.

It has a frequency range of 0.15 – 3304.9999Mhz, support for FM, WFM, AM, USB, LSB and CW receive modes, 1250 memory channels with alphanumeric tags, TV audio reception, a 32MB integrated audio recorder (up to 20 tracks, 4 hours), rechargeable Li-Ion battery and is USB programmable and CI-V remote control compatible.

It also decodes CTCSS and DTCS tones, has a repeater offset monitoring button, adjustable RF gain, S-meter, spectrum scope and dual-watch for simultaneously receiving two channels at once (with limitations in each VFO’s range).

As a result, the unit is somewhat larger, but still relatively compact for what it offers. It was by far my favourite unit with a sensitivity that trounces the others. The interface was somewhat complicated – buttons could activate up to three or four different features depending on the mode, short press or long press.

It didn’t have any discriminator output and modifying it was a risk I wasn’t willing to take – but the dual-watch feature and high sensitivity actually made it possible to monitor multiple ACARS frequencies at once, thus this was my primary ACARS receiver for a number of years.

The unit’s recording feature was also particularly of interest, as this allowed for ADPCM recordings that could be downloaded to the PC (slowly, over USB to serial) but converted back into a .wav file with a special tool.

I carried this radio around a lot and it was the unit that I used to first explore shortwave radio and amateur satellites. Because of its wide frequency range, I even used it to explore the output from satellite LNB IFs, even before I got access to wide-range SDR radios. It led to my purchase of an IC-R75 later for shortwave monitoring – another lovely radio. Unfortunately, the IC-R20’s keypad keys have started to become sticky, along with the port covers making it a little less enjoyable to use. Its receiver performance is, however, still just as good as the day I bought it and I still get some use out of it.

Aside from the three radios I’ve shown in this post, I also owned a Uniden Bearcat UBC355XLT car-mount unit for cheap from eBay, but that one failed after a long time serving as a trunking control channel receiver for Unitrunker monitoring the NSW GRN in the past. I also had a Realistic Pro-2021 I got for “scrap” as it wasn’t working, but I repaired it and used it for a few years but the limited sensitivity, frequency range and large size led it to be retired as well.

A Dying Hobby?

While scanning is still a cool hobby to me, with the idea of getting a behind-the-scenes seat hearing what is happening “at the front line as it happens” being a key part of its allure, it seems like this hobby is dying. For one, with the loss of many local electronics stores, scanner units are rarely ever advertised. I almost never see anyone with a scanner in the streets and it seems that the RadioReference databases for my area aren’t being kept up to date either. It’s a sad thing to see, but there’s a good reason for this.

Because of the limited overcrowded 400Mhz spectrum and a desire to “refarm” some of the former 800Mhz spectrum for use with mobile telephones, a number of changes were made to the bands. Former 800Mhz users were all taken off the air, with 400Mhz band users being given an ultimatum to move to more spectrally efficient technologies. To do this, initially, it would be possible to move to narrower NFM as an interim step, but the writing was on the wall – to get to 6.25khz equivalency, you really needed to go digital. To help them on their way, ACMA rejigged the frequencies in such a way that repeater offsets were chosen such that it would play well with digital technologies and since then, scanning enthusiasts have been living with the consequences – not just here but across the world.

Consequence #1: A Myriad of Incompatibility

The first problem is that the move to digital has splintered many services from a single type (e.g. NFM) into several incompatible digital systems. This includes systems such as APCO P25 (Phase I, Phase II), DMR (MotoTRBO), TETRA, NXDN/IDAS just to name a few that operate nearby me at this time. Each of these systems have different on-the-air characteristics requiring specific decoder implementations to decode the bitstream, but the difficulties do not end here.

Consequence #2: Legality Issues

Once you have the bitstream, the problem is that digital radio depends on different digital voice codecs (e.g. the MBE family). These codecs are optimised to carry voice signals using a very low bitrate (often 2kbit/s to 9.6kbit/s), but are patent encumbered. As a result, to produce scanners that can decode these audio streams, either a non-infringing implementation needs to be used (which normally results in audio quality trade-offs) or licensing fees (sometimes additional to the purchase price of the unit) needs to be paid.

Of course, with the popularisation of low-cost SDR technology (through RTL2832U TV-dongles), it is possible to now decode and even listen to these transmissions but either you have to build your own MBE decoder or download software which is of questionable legality.

Consequence #3: A Loss of Access

While the above points make monitoring digital systems somewhat inconvenient, the move to digital also enables easy access to encryption. Many of the systems allow for “basic” encryption which can be easily provisioned at very low cost to prevent anyone else from listening into the transmissions. More sophisticated encryption module based systems with 3DES/AES/etc are available and used by some agencies already. Transmissions on TETRA systems are encrypted by default. All of this serves to limit our access to the information – of course, it was nice to listen in while it lasted but the transition to digital definitely puts the remainder of the transmissions at risk.

More than that, because of the cost of handheld radios compared to the cost of smartphones, some agencies are foregoing the whole radio idea and instead substituting various telephone-based dial-in systems (e.g. Taxis in Hong Kong) or various application-based solutions to emulate a radio over LTE data.

Consequence #4: Reduced Audio Quality

While the use of forward error correction and robust symbologies, digital systems can provide increased coverage and better reliability with no static or hiss. However, in reality, it is not without its limits.

Tied in with the use of codecs, the digital systems frequently have reduced audio quality that makes listening fatiguing and produces intelligibility issues especially in the case of “reverse engineered” decoders. But even without such issues, many dispatch operators seem to request repeats more frequently due to interactions between background noise and the vocoders causing strange “burbles, underwater noises”. While the digital systems can mask a limited amount of errors, it seems some users like to push the limits of coverage while others are suffering from sub-par equipment installation or strong multi-path issues.

Consequence #5: Increased Expense/Complexity

As mentioned earlier, because of the variety of systems and patents involved, as well as the declining popularity of the hobby, the increased cost and complexity seems to make it even more difficult to affordably purchase a useful scanner.

For example, looking for a DMR-capable portable scanner today, the only options seem to be:

  • GRE/Whistler PSR-800 (Paid Upgrade Required)
  • GRE/Whistler Pro-668 (Paid Upgrade Required)
  • GRE/Whistler Pro-18 (Paid Upgrade Required)
  • Whistler WS1080
  • Whistler WS1088
  • Whistler TRX-1
  • Uniden BCD325P2 (Paid Upgrade Required)
  • Uniden BCD436HP (Paid Upgrade Required)
  • Uniden SDS100 (Paid Upgrade Required)

Even then, it’s not clear as to what the total cost is, as a number of these units seem to require paid upgrades to unlock these features. But if you also want NXDN on top, then you’re down to just the TRX-1, BCD436HP or SDS100. A quick search seems to show that all units are relatively hard to obtain locally, the TRX-1 is about AU$760, the BCD436HP is about AU$673 and the SDS100 is around AU$1032. Of note is the latter two will still require a paid upgrade to decode DMR and NXDN, so this is hardly a friendly “introduction” to a hobby which … frankly … you can’t be sure you’re going to hear anything at all. Part of the reason I say this is that digital systems also need some extra work to determine the correct frequency tables, offsets, talkgroups, etc so that you can actually listen to what you’re interested in. This information, while in the past, might have been kept up to date and openly shared is now rare to find.


Radio scanning was a hobby that I picked up relatively late in the game, but still, was something I enjoyed and led to a number of things including getting my amateur radio license, doing some shortwave DXing, following amateur radio satellites etc. It wasn’t cheap back then, but with the move towards digital voice for spectral efficiency, use of proprietary voice codecs and encryption, the days of scanning may well be numbered. To get into it in the same way now would entail a fairly expensive investment and uncertainty whether there is anything to listen to.

As a result, those who might want to try are better off using SDR radios and (sometimes questionable) software to decode the transmissions. It’s much more flexible and the information displayed is much more useful – the only downside is that it’s not very portable, the audio quality may be sub-par, the reception quality is limited by the SDRs as well and it can also be a bit buggy. Maybe I’ll talk more about this in an upcoming post.

Now with the internet, I guess people like to keep themselves entertained by other means (watching cat videos, perhaps) and old fashioned radio might continue to decline in popularity as communications over the internet become so effortless that it’s taken for granted. I’m a bit sad to see scanning in a decline … but I’m not letting it go. Not just yet.

Posted in Radio, Telecommunications | Tagged , , , , | Leave a comment

Tested: VLANs in the Home Through “Dumb” Switches

Being someone who has used consumer gear for a long time, I’ve always been rather frustrated at their inconsistent or general lack of support for VLANs. Long used in corporate networks, the VLAN concept can be extremely useful for realising unusual redefinable network topologies without needing to make physical modifications to cabling or installing extra hardware.

This month, I decided that my house needed to have VLANs to prepare for the future and to make my life easier by reducing the need to run extra cabling. But most of my gear is “dumb” … so will it even work?

What is a VLAN? Why YOU might need VLANs!

On a regular home Ethernet network, all packets are “untagged” and belong to the same network. You can think of any device attached to the Ethernet network as belonging to the one giant network – to have a second “independent” network would need to have a second set of switches or cables.

The term VLAN stands for Virtual Local Area Network and is a form of partitioning that is based on insertion of one (or two in a Q-in-Q configuration) four-byte 802.11Q tag into the packet header. The presence of the tag signals the packet as belonging to a VLAN (1-4094). This allows for up to 4094 independent VLAN networks to share the same physical network (depending on the hardware)! If you want two independent networks, you can – just set each to their own VLAN number. This works as the resulting frame is still a valid Ethernet frame, just with a different Ethertype.

“So what?”, I hear you say. The applications might not seem obvious, but there are good reasons you might need this:

  • Guest network separation – this is ideal for building a separated wired network segment for equipment that guests (or untrusted computers in quarantine) might use that won’t have access to your main equipment. Combine this with Virtual APs to extend the VLAN concept into Wi-Fi without needing VLAN over Wi-Fi support (which is rare). This is more flexible than the wireless-only guest network of your average consumer AP.
  • Control equipment separation – IoT equipment, sensors, surveillance require stable bandwidth and high priority connectivity while needing to be protected against unauthorised tampering or scanning. Using VLANs can both protect your IoT from local attack and prevent local network devices from being compromised due to IoT vulnerabilities.
  • High priority Voice over IP – for similar reasons, you might want to run VoIP over a separate VLAN to avoid performance degradation from excessive broadcast network traffic and to apply QoS prioritisation.
  • Not enough cabling/cost savings – perhaps you have a distance to span where bandwidth is not an issue but needing to keep two independent networks is necessary – e.g. to extend WAN to a router and the routed local network back to the point of connection. Using VLANs would eliminate any need to run dedicated cabling for each network – if later, more cable were to be installed, VLANs could allow for bandwidth sharing of both cables in a team.

But … What About?

However, as nice and simple as this sounds, VLAN support in consumer gear is sparse and there are many ways you can break a network. Routers which aren’t VLAN aware will make creating the desired network architecture difficult – luckily for me, Mikrotik stuff is here to save the day and if not, there are also various Linux possibilities. The next problem is at the “edge”, where the endpoint gear may not be VLAN aware.

Many computers running Windows using cheaper Ethernet chipsets are only capable of running a single VLAN at a time – the main exception is Intel Advanced Networks Services capable adapters. The situation in Linux is much better, given proper driver support, but in this case, the VLAN is based on configuration, so there can be a potential for misconfiguration and security problems. There are many appliances (e.g. DVR, NVR, Gaming Consoles, SIP ATAs) that are connected to the network that have no such support.

The traditional way around this is smart switches which are VLAN aware. Smart switches would be configured with a “trunk” port where VLAN tagged frames are aggregated and forwarded and access ports which are members of one or more VLANs (depending on the unit). This scheme is known as port VLAN – the smart switch takes care of tagging and un-tagging the frames, so non-VLAN aware devices can communicate as normal. This also can enhance security when configured correctly – preventing devices from VLAN hopping by accepting only untagged frames and enforcing the tagging in a consistent manner. Unfortunately, smart switches are generally pretty expensive.

The VLAN system also doesn’t work so well with Wi-Fi adapters – while the frames are valid Ethernet frames, most Wi-Fi adapter drivers don’t support configuring VLAN IDs. Luckily, we can use Virtual APs to overcome this issue, broadcasting a separate SSID from the same radio, sharing the same channel, to access individual VLANs.

While pondering about this, the solution to the problem seemed somewhat obvious – running a pure VLAN-based network makes life with cheap equipment difficult and upgrading all my equipment was not a realistic proposition. The answer would be to run both VLAN and untagged traffic together – this is known as a hybrid trunking port. While this arrangement isn’t ideal from a security standpoint as it doesn’t protect against VLAN hopping, it should still allow me to reap the benefits of VLAN-based reconfigurability and partitioning where needed, deploying the necessary smarts only at those locations where VLAN access is needed.

There was only one catch – the 802.11Q tag adds four bytes to the Ethernet packet. This results in the regular Ethernet frame of 1538 bytes being stretched to 1542 bytes – a baby jumbo frame. These frames are in violation of regular Ethernet and consumer equipment isn’t VLAN aware so a number of possibilities can happen:

  • Equipment receiving such long frames can truncate, drop or discard the frame – if this is a switch, then connectivity to the VLAN will be problematic when packets with payloads of 1497-1500 bytes are sent as FCS errors are likely in the case of truncation or packet loss in the case of drops. If this is an end device intending to access the regular network (untagged), this should be of no consequence.
  • Equipment receiving a 802.11Q tagged frame can mangle the tag – this will possibly result in tagged frames being corrupted causing VLAN connectivity problems or VLAN to VLAN separation to be breached.
  • Equipment receiving such long frames can crash – this may happen if there are fixed length buffers and an overflow was not tested for.

Before I can go to a VLAN arrangement, I will have to test my equipment to see how it behaves. Even for a simple question such as whether “dumb” switches would pass VLAN-tagged frames, there was no consensus online with some suggestions of “catastrophes”, so I decided it would be easier just to test it.

Testing it Out

To test out the system, I added two VLANs to my hAP ac running upstairs on the main upstairs-to-downstairs link (now a hybrid trunk carrying untagged and two VLANs). These two VLANs emerged out of two ports on the hAP ac which were configured as port-VLANs connected to a Raspberry Pi each configured with a different static IP/subnet combination and a DHCP server.

This link was first terminated into the hAP mini to bridge into each of these two VLANs via the two remaining ports (i.e. simulating a port-VLAN based smart-switch). I tested using my laptop connected into each of these ports to check that I could get the corresponding IP address as expected (i.e. network separation was correct). I then tested passing the maximum ping packet with don’t fragment to another endpoint on the two VLANs to ensure the packets would pass without errors.

The maximum ping with don’t fragment is 1472 bytes – after some confusion and lots of calculation, it seems that many people calculate packet sizes differently depending on which layer they’re talking about and whether they’re talking about the whole Ethernet Frame or not. Regardless, a 1472 byte ping packet has a 1500 byte payload due to 28 bytes in the ICMP header. From there, adding the 14 byte Ethernet Header, 4 byte Frame Checksum (FCS), 8-byte Preamble and Start-of-Frame Delimiter (SOF) and 12-bytes Interpacket Delay (IPD), we arrive at the 1538 byte “maximum Ethernet frame” figure. When a single layer of 802.11Q is added, this expands to 1542 bytes.

This initial test was successful, indicating my configuration was correct and VLAN-to-VLAN separation was maintained without disrupting the untagged network thus far. Then I connected the trunk into each of the dumb switches in my collection and connected the hAP mini to an output and repeated the experiment.

TP-Link 8-Port Gigabit v7 TP-Link 8-Port Gigabit v8 D-Link 5-port Gigabit Rev. D1 Trendnet TEG-S50g Green 5-port Gigabit Skymaster 5-port Fast Ethernet Netgear DS104 Dual-Speed 10/100 Hub

To my surprise, and my delight, all the equipment seemed to pass VLAN tagged frames without any issue – the frames came out without being truncated or mangled. This means that it is actually safe to run VLAN tagged frames through dumb switches.

For the newer Gigabit switches, this is implicit due to their support for Jumbo Frames of 9KB-16KB. A slightly oversize frame is no drama for a switch that can handle this. The only question is whether its “smarts” will cause the tag itself to be mangled, but as far as I can tell, none of mine were bothered by it – although my Skymaster seemed to be a bit slower in forwarding the frame compared to the others.

For older equipment, I expected problems but I was pleasantly surprised. Part of the reason seems to be that packet length enforcement is not that strict. In older equipment, the unit would cut off equipment that was creating excessively-long transmissions to prevent tying up the media – this was known as Jabber. However, the jabber mechanism is not precise to the length of the Ethernet frame – the shortest time from Wikipedia seems to run from 25kbits which would correspond to a frame of 3125 bytes (!!) which is still much longer than the VLAN-tagged packet. The restriction will probably be whether the clocks in these units are stable enough over the longer period to decode the complete frame correctly.

Encouraged by this, I connected the hybrid trunk to my regular switch and slept soundly in the knowledge that I have VLANs in the home, at last!

My (Simplified) Network

The above (messy) schematic shows a simplified version of the present network and the main motivation for the VLAN investigation – my current router is located upstairs on the floor to be most central to the house. This places it in a location high-enough to have even visibility of the whole house, without being so high as to interfere with others and receive interference from others. In my previous investigation – at the front of the house and at the rear, the signal was a generous -55dBm, validating its position as being optimal.

The reason for it being upstairs is because of my primary WAN being a USB 2.0 connection to a tether mobile phone – this link is necessarily limited in distance due to voltage drop and signalling. By positioning the phone up high, my signal to and from the LTE BTS is improved, ensuring I get better data rates at all times.

Add to this, my current back-up WAN is based on a long-range Wi-Fi link to a Telstra Air/Fon Wi-Fi AP which I rely on to activate new SIMs or for larger software updates to avoid exhausting my LTE service. This is a secondary network which I run on a separate subnet – running this downstairs through VLAN rather than requiring all devices connect via Vitrual AP would reduce noise on the Wi-Fi channels, reduce radiation exposure and improve reliability of the link.

Because of having some legacy gear and untrusted stuff, a third VLAN was desired just to connect this untrusted stuff for “guest” use. This way, any worms or nasties would not propagate to my main machines. But they still needed access to the internet in some way – having the ability to dynamically “cut them off” at the click of a button and/or rate limit them via queues is a definite advantage.

Then I decided I was going to run some telephony at home as well – I miss having my old Asterisk server, so a voice VLAN would be nice to reduce needless broadcast traffic from affecting my (rather underpowered) SPA112 ATA.

With all of this going on – I only had one 30m Ethernet cable to run from upstairs to downstairs. Ethernet cables are cheap but if I had to buy another three … not to talk about how ugly that would look as well! VLANs to the rescue!

In this configuration, all of the “dumb” devices access the network “untagged” as that’s the only way they know how. My RasPBX and ATA do so through an hAP mini which tags them to the voice VLAN. Because my main desktop has an Intel ANS capable card, I am able to create virtual interfaces for each VLAN and untagged LAN as well. This way, I can unbind most protocols from the VLANs and bridge them into virtual machines so I have an isolated way to access/administer/diagnose devices on those VLANs (save for a VM escape attack).

But the biggest reason to have it configured this way is to prepare for the eventual arrival of HFC NBN. As the outdoor demarcation point is now installed, it comes into the ground floor of the house in a corner. If I request them to install the HFC wallplate anywhere in the house, they will very likely do an ugly surface conduit run of the cable which is a mess. Instead, if I ask them to do a back-to-back, they might be happy (at the easy work) and the result might be a bit prettier but the CPE will now be at a bad location. So I decided that I could dedicate a VLAN to the Ethernet from the CPE by using a smart switch configured as Port VLAN (the TP-Link SG105E isn’t expensive and can definitely do this) – then it can patch using a shorter lead into my existing network on a less-ugly cable route. This can also allow for another guest network access port. Of course, now all the WAN traffic will go up the hybrid trunk/access line and most of it will come straight back down (wasting bandwidth, but there’s usually no contention – 100Mbit/s WAN + ~300Mbit/s 802.11ac file-copy is still <50% utilisation) but I can maintain just one router in the network and its good vantage point.

Alternative solutions can include:

  • Ethernet over Power – but as I like listening to shortwave, I can’t handle the interference. Add to that the fact it’s expensive and slow.
  • Dedicated Ethernet from here to the router – but that’s both expensive and unsightly just stringing cable around as I normally do.
  • Wireless Bridge – definitely a possibility, but latency, packet loss trade-offs, additional Wi-Fi radiation and channel congestion are something I’d rather avoid
  • Second Router near the CPE for WAN gateway- I do have an hAP ac² so that is a possibility, but why waste another router when you don’t need it? I don’t even need a better wireless signal!

The diagram itself is a little misleading, as the hybrid trunk is connected to a dumb switch, which really doesn’t enforce any port being a member of a particular VLAN or doing any tagging/untagging. This is both a blessing (meaning all ports can join all VLANs) and a curse (meaning all ports can inject traffic to other VLANs/participate in VLAN hopping). At home, this security compromise seems acceptable – after all guests/secondary WAN/voice VLAN users will be behind port-VLAN devices, they won’t be able to attack the untagged/other VLANs. It’s moreso that the untagged users may accidentally join a VLAN if they are misconfigured and that would be my fault entirely.


It’s unfortunate that more consumer gear doesn’t have VLAN support, but it can be quite useful to realise rather special network topologies and save on cabling hassle where sufficient bandwidth already exists. Discovering that tagged traffic runs just fine intermixed with untagged traffic even though older switches was a blessing, that allows me to add in VLANs to my network “transparently” – only those devices that need to access the VLAN have to be connected to an intelligent smart-switch or similar device (or have their VLAN settings configured appropriately if possible). The rest of the devices on my network operate as if nothing had changed – I haven’t noticed any strange behaviour and the switches seem to be moving traffic about as expected (no constant all-port floods, loops, etc).

With the emergence of cheaper smart switches (and the potential that other switches can be modified to gain VLAN tagging facilities), it may herald a new era where VLANs start to become more common in the home.

Posted in Computing, Telecommunications | Tagged , , | 2 Comments

Tested: EDUP 11AC 1900M Dual-Band USB 3.0 Wireless Adapter (EP-AC1621)

In my quest for more wireless throughput, my hAP ac with three-stream 802.11ac wireless seemed to be the right choice. The problem was that I had absolutely no three-stream capable equipment to use with it – so I wasn’t seeing any of the benefits of that third stream. In my case, maybe I should’ve gone with the hAP ac² instead and saved the money?

So I thought I’d get myself a three-stream device just to test – hopefully one that would be a bit less problematic under Linux than the previous 802.11ac USB adapters I’ve tried. After some searching, I found some very expensive options available locally – about AU$120 which was just downright unreasonable. At that price, I’d just buy another hAP ac and use that as the adapter …

So I settled for a Chinese alternative – the EDUP EP-AC1621 for AU$45 posted after stacking all the discounts I could find. Lets see if it was worth it …


The unit comes in a colour print retail cardboard box. The front has an image of the adapter with its four antennas attached, making for an “imposing” half-octopus. I’ve got to wonder how well this works, especially given how closely those antennas are spaced.

The rear of the box gives the model as EP-AC1621, listing the specifications. Interestingly, it lists itself as “Draft 2.0”, which makes it sound like a pre-standard adapter. It claims support for up to 80Mhz bandwidth, although the claimed 1300Mbit/s throughput is at odds with its claims of 4T4R MIMO. In fact, it is technically a 4×4:3 – only three chains can be active at any time despite having four antennas. This isn’t necessarily a bad thing – it should be better than a 3×3:3 as it has an “extra” antenna to capture some more signal. The transmit power is 15dBm in 2.4Ghz and 12dBm in 5.8Ghz making it a little low. I wonder if this is a per-stream or total power output. There is also some strange English with the use of the word “Synchronization”.

When you open the box, you are greeted by the adapter inside a plastic tray.

Below the tray is the remainder of the accessories, including four antennas, the USB cable and driver CD.

The USB cable is especially thick and stiff, which makes it pull the adapter about. There is also a Quick Installation Guide hiding below the CD.

The adapter itself feels light and hollow. It features a glossy plastic exterior with a simple design incorporating an LED window on the top and RP-SMA connectors along the sides for the antennas. There is a microUSB3.0-B connector for power and data at the bottom, but the unit is otherwise featureless – no feet so it happily slides around.

Assembly is easy – unwrap the antennas and screw them in for your “half-octopus”. The orientation of the antennas may need some tweaking though, to maximise stream-to-stream orthogonality. Interestingly, these antennas are the same units provided with my “generic” AC1200 adapter.


The driver CD contained an outdated version of the driver:

Downloading the latest version from here, it was a simple task to run the installer and connect the unit and it was up and running. The VID is 0BDA and the PID is 8813.

Due to the RTL8814AU chipset in use, it’s slightly less sucky for use with Linux. Drivers can be found online from a number of places, however, it seems I’ve had success with zebulon2’s version. There is also a version from aircrack-ng that supports monitor and packet injection, however, I did find some instability especially on a surprise unplug.

Throughput Tests

Throughput testing was conducted using a server connected on the Gigabit Ethernet segment of the network, serving a 4GiB random-fill file over a network share. The adapters were connected to a Lenovo E431 laptop running Windows 10 through its USB 3.0 ports, while maintaining AC power connection to the charger to avoid Wi-Fi energy saving performance impacts. The network share was mapped to a drive and Cygwin was used with dd to read the file using 16MiB block size to /dev/null. The reported file throughput was used to compute actual data throughput, taking the average of three transfers. At the server, a regular process running in Cygwin “touch”-ed the random file at one second increments, invalidating any file caches on the test laptop. While iperf is generally regarded as most reliable, I found that in all cases iperf3 reported similar readings but often around 2-5Mbit/s less possibly due to its less aggressive transfer behaviour.

The throughput tests includes testing of:

Testing was based on a Mikrotik hAP ac which was serving a “live” network with other users and hAP ac² at close range only, serving a dedicated “best case” 802.11ac-only network.

The results are somewhat confusing, so lets break it down somewhat:

  • The test protocol worked, with direct GbE connection providing a reading of 954Mbit/s – close enough to the 940Mbit/s expected and is probably down to the timing errors in the dd method and rounding error of the throughput.
  • Throughput in the ideal case with the hAP ac² (supporting two spatial streams) showed all three 802.11ac adapters performed similarly, which is not expected. The single-stream USB 2.0 based TP-Link T2UHP managed to provide 268Mbit/s download, whereas the “generic” AC1200 two-stream managed 276Mbit/s and the three-stream EDUP managed 278Mbit/s. Ideally, we would expect throughput to scale (nearly) linearly with the number of spatial streams, assuming that stream-to-stream orthogonality could be maintained, thus I expected the two and three stream adapters to be able to do double of the single-stream.
  • Spot-checks seemed to show that the Broadcom two-stream 802.11ac adapter performed similarly to the single-stream TP-Link TP-T2UHP, whereas the Intel Wireless-AC 8265 was able to exceed all others even at a distance in the house.
  • I suspected USB overhead and poor drivers or chipsets may add a limitation to the achieved speed, so I tested two USB Gigabit Ethernet adapters on the Lenovo E431 using the USB 3.0 port, which was only able to achieve 320Mbit/s under the same benchmark. While this is faster than the 802.11ac, it is a long way from 1Gbit/s.
  • I verified that the hAP ac² was able to operate in two spatial streams and hAP ac was able to operate in three spatial streams to the respective adapters. Physical layer rates reported were 433.3Mbit/s for a single stream, in excess of 650Mbit/s for two streams and 975Mbit/s for three streams.
  • I expected to see something close to ~500Mbit/s in triple-stream mode and closer to ~350Mbit/s in dual-stream mode. This suggested some possibility of limitations in throughput in the Mikrotik equipment or in the compatibility between chipsets. To check this, I ensured the routers did not saturate their CPUs (they didn’t – utilisation < 50%) and tried from Mikrotik hAP ac to Mikrotik hAP ac² in bridge mode and was not able to increase the throughput over the USB adapters even at close range.

Looking only at the 802.11n/ac comparison dataset on the hAP ac:

  • It is clear that 802.11ac trounces 802.11n throughput, as expected. In some cases, throughput was close to double whereas in extreme cases, the throughput even was close to triple.
  • The single stream T2UHP is at a disadvantage compared to the others, recording slightly less throughput. This is likely due to its single-stream nature and USB 2.0 connectivity. However, despite this, it is always capable of providing better results than a dual-stream 802.11n solution (!!).
  • The unbranded generic AC1200 adapter does provide solid results, until the signal gets weak outdoors where its performance degrades to that of the single stream. This was as hypothesized in the review due to the second “vestigial” antenna. For the price, the performance is quite solid.
  • Peak recorded 802.11ac throughput for the EDUP was 273Mbit/s at close range with the hAP ac, equivalent to the two stream adapter despite being connected with three streams.
  • However, while there was no real throughput advantage with my combination of equipment at close range, at long ranges, the advantages were clear, offering about twice the throughput in the garden as the single-stream and “one-and-a-half” stream solutions. Outdoors, it was able to offer almost four times the throughput of the dual-stream 802.11n solution.

Part of the reason for the rate differences may be due to differences in antenna gains and transmit powers – while the T2UHP was able to achieve maximum MCS for the single stream at close range, the other adapters never achieved the maximum MCS at any distance. This may mean that their signals were not separated enough, the transmit signal was unclean or weak. The Realtek-based cards do not boast high transmit powers – so this may indeed be part of the reason. There may have been differences in compatibility as well between beamforming techniques. Despite this, there is another advantage of higher spatial streams – even if single-client throughput is not improved, the airtime occupied by transmissions should reduce as a function of increased physical layer rates, leaving more airtime for other clients to use. The net “system” throughput should still increase.

Further research of the expected throughput from 802.11ac solutions provides varying reports of speed – this test with an Asus RT-AC68U (four-stream) showed close-range throughput of 230-310Mbit/s (with the exception of one adapter that provided 404Mbit/s). This test by Anandtech found throughput averages which ranged from 158-464Mbit/s at close range. Another test by TBG for an intermediate distance found data throughputs ranging from about 227-342Mbit/s.

In that perspective, while the results were not at the top end of the range, it wasn’t at the bottom either. While some people have been able to achieve even higher throughputs in practice, the likelihood of this happening with “random” low-cost consumer gear seems unlikely and it may boil down to running multiple transfers concurrently.


The plastic case is held together with clips internally that are difficult to separate without breaking. As a result, I don’t recommend taking apart the adapter as the casing will likely be partially damaged.

The board inside doesn’t occupy the whole case, instead having some clearance from the sides. The rear has some power conversion (switching) circuitry, a reference oscillator and some passive SMD components.

The opposite side features the RTL8814AU chipset, with a Skyworks SKYT85703-11 front-end module per port. The module is specified for up to 16dBm @ 1.8% EVM at HT80, MCS9. The PCB seems to have provision for a hardware WPS button that was not fitted. The USB 3.0 filtering seems to be strangely located too – one set near the chipset, the other near the connector. Much of the PCB (marked UMB814A03-3V3, dated Week 40 of 2017) isn’t strictly necessary, it seems, so the adapter could have been much more compact.

It seems that the top indicator would have functioned as a WPS button as well, but it is secured into place just as an indicator.


While it’s possible to buy a triple-stream 802.11ac adapter for less than the local shops might have you pay, it seems that the combination of equipment you use (e.g. laptop, adapter, access point, etc) can result in rather unusual results. In my case, through multiple tests, it seemed that the triple-stream adapter didn’t offer a big advantage over the dual-stream adapter in terms of maximum throughput where the signal was strong. Its main advantage was in weaker signal areas where it could maintain a higher throughput, suggesting there was some limitation with the AP (potentially), testing scenario or compatibility issue.

Despite this, the triple-stream adapter did connect with higher PHY rates, which should reduce air-time usage, allowing for an improvement in overall wireless system throughput. It also does have better Linux support than the ones I tested before, although it isn’t quite as stable as adapters from the 802.11n generation nor is it as convenient as it hasn’t been mainlined. The unit uses the same Realtek RTL8114AU chipset as in much more expensive units (e.g. Asus USB-AC68 ($99), D-Link DWA-192 ($89), Netgear A7000 ($99), TP-Link Archer T9UH ($79)), so it’s likely that I could have paid almost twice as much to end up with the same results.

However, as there wasn’t any gain in maximum throughput, it seems that the two-stream AC1200 solution was probably the far better value for money option depending on your needs. After all, most smartphones only ship with single-stream (or at most, dual-stream) solutions and most laptops are restricted to two streams. Triple and quad stream solutions still remain a niche category – along with commanding a higher price tag.

Posted in Computing, Telecommunications | Tagged , , , , , , , , , , | Leave a comment