Seeing as I’ve been playing with my internal PBX and modems, and I recently just had an ATA power supply fail on me, I thought it would be a good time to order a few ATAs before they disappear entirely.
It seems that the number of choices in the ATA market has been dwindling mainly because of reduction in VoIP phone costs with more brands entering the market, and the recognition that dedicated VoIP phones offer better user interfaces, higher audio quality with true HD voice, with less hybrid-induced echo problems, faster dialling and better multiple-line support. The number of people wishing to purchase POTS based gear or to continue running POTS based equipment is expected to reduce over time.
Aside from the Cisco SPA112 I looked at earlier, another option which is slightly cheaper is the Grandstream HT702.
The unit comes in a rather plain, but small sized, glossy white cardboard box. The side panels have the information about the unit and the UPC barcode.
Inside, we get the unit, which has five LEDs on the front and is about 80% of the size of a PAP2T. The smaller size actually makes it quite cute.
All connections are on the rear, including the two lines, Ethernet, 12v DC power and a reset button.
The side is vented, and has a warranty label over the seam.
The underside of the unit has labels with information regarding the unit.
It comes with a power supply from Mass Power, with an efficiency rating of V.
Also included is a vertical stand for the ATA, a short CAT5e ethernet cable and a notice that the unit uses GPL licensed software in its firmware.
I decided to go ahead and void the warranty for my unit on day one to do a teardown.
Internally, we can see that it uses the DVFD8187 + DAP1912 chipset from DSPGroup similar to the SPA112 which used the DAP1902. The flash memory used is physically smaller, and the RAM is from Etrontech. The Ethernet controller is a Micrel KSZ8081 10/100 PHY.
Removing the label shows that the line drivers are Nuvoton N681387 codecs which appear to support HD Voice, although it doesn’t seem like that is strictly needed.
The unit has capacitors from Fcon and Xunda, all of which are not very highly reputed brands. However, as it is unlikely they are subjected to high ripple currents, this could be just fine.
Components are also mounted on the underside, which helps to save space.
A nice bonus is the inclusion of a polyfuse on each of the lines leading out from the unit – namely one for tip, one for ring, on both lines. This seems to make good sense to protect the lines from transients where users use the ATA to provide service to whole-house cabling or suspect equipment to limit the current in and out of the line codecs.
Configuration and Testing
Configuration can be done via the web browser, or via Telnet.
The first thing I did was to upgrade the firmware as 188.8.131.52 was available. This was achieved by downloading the firmware from Grandstream’s support pages, unzipping and uploading the firmware to the unit.
The process takes several minutes, and minimal feedback is provided.
After the update, the new firmware version is shown. It’s rather interesting to see that the firmware release dates from 28th September 2015, indicating active support and bugs in the unit.
In terms of configuration, the device offers a plethora of options, some of which are not available on other units (e.g. pulse dialling, certificate provision). However, their organization is, at times, haphazard and the system uses different conventions to other ATAs.
Limitations in the tone specifications seem to result in only two tones being generated for dial-tones. For Australian tones, I decided to enter the frequencies as follows (noting that others published online don’t seem to work for me):
There is an impedance setting for Australia, which is nice, but it didn’t seem entirely effective. It was nice to see that the full complement of codecs is allowed, namely including iLBC and G.723 above that offered by the SPA112. The unit does run relatively cool, which is good.
On the whole, when it came to voice quality, it seemed to be marginally inferior to the SPA112. The echo return loss measured about 20dB in the Australia setting, and which it seemed sufficient, the jitter buffer on low/fixed was quite long meaning the echo became more apparent. The one-way decode latency appeared to be about 130ms measured by the audio echoes. Testing with dial-up modems seemed to show a T.38 implementation which captured and subsequently had issues with passing through data mode calls, and limited connect rates of 31.2/28.8k rates despite heavy tuning of the gain figures.
However, it seems that its performance under network loading was more acceptable, with no audible interruptions when accessing the configuration interface (likely as the jitter buffer was longer, and the interface was simple). However, it seemed to share a similar heritage with the SPA112 in spewing out ARP and other frames with FCS errors – something which should be inexcusable for a commercially available piece of hardware.
While the Grandstream HT702 shares a similar chipset configuration to the Cisco SPA112, and also shares the odd packets with FCS error issue, it performs somewhat differently. On the whole, when it comes to voice quality, when testing with dial-up modems, it seems they were less happy when working with the HT702, only offering 31.2/28.8k connections rather than the 36.6/31.2k that SPA112 is easily able to achieve. Part of the issue seems that the jitter buffers in the HT702 are generously sized even at the fixed/low setting, resulting in a decent amount of latency making echo more noticeable. The Nuvoton line codecs also don’t seem to offer as perfect impedance matching, and the gain settings only have limited effect on the echo. The configuration is also quite dated and slightly random in its arrangement.
However, the HT702 is more compact, cheaper, and it does work correctly. It offers the full complement of codecs that the chipset supports. It also has some features which other ATAs don’t seem to have (pulse dialling) which I didn’t test. It also doesn’t have any great issue with accessing the interface during calls (probably because there are no line statistics shown).