In this section, I will focus on the internals of the DAS240-BAT main unit and channel module to uncover what powers this multi-channel recorder and what the unit looks like under the hood, both hardware and software.
Disassembling the Main Unit
Surprisingly, the main unit is held together mostly by using plastic rivets which makes disassembly very easy.
Removal of the plastic rivet is done by prying on the head, removing it, then removing the collar from the hole. Once all of the plastic rivets securing the rubber ends and strap eyelets have been removed and the rubber ends are removed, it’s interesting to see that the weight of the device is still 1.653kg which is above the claimed 1.5kg in the datasheet.
Opening the main unit requires breaking a warranty seal that is placed over the two metal halves of the case.
Removing the remainder of the plastic rivets allows the case to come apart.
The rear half of the case houses the battery and a heatsink for the system-on-module (SoM). The front half of the case contains the remainder on a single large PCB, with quite a bit of free space.
The PCB appears to be laid out in sections, with the analog section on the right side of the image, the power control in the centre, the digital in the centre-bottom, the SoM with all interfaces occupying the left half of the PCB. A closer look at each of the sections is made in the next section.
The onboard 32GB memory storage is a microSDHC card that lives in a socket on the main PCB. As there is no slot in the case, the card cannot be reached externally – this may be due to design as the unit could malfunction if the card is removed during operation.
The underside of the PCB does not contain any components.
Removing the PCB from the chassis requires removing six screws. This reveals the LCD screen assembly from Ampire (AM1024600L-series).
Breaking Down the Main PCB
We can take a closer look at each section of the main PCB to understand which components are used in this solution. We begin with the analog section of the PCB.
There is one tall component, a Traco Power TMV 0505D EN +/-5VDC 100mA 1W DC-DC converter.
The analog section consists of the following identified components:
- Analog Devices ADuM1401CRMZ Quad-Channel Digital Isolator
- Xilinx XC2C64A CoolRunner-II CPLD
- Analog Devices AD7694 16-Bit 250kS/s PulSAR ADC
- Analog Devices ADR02 Ultracompact, Precision 5.0V Voltage Reference
- Texas Instruments TLV2372 500uA/ch 3-MHz Rail-to-Rail Input and Output Operational Amplifiers with Shutdown
- Vishay Siliconix DG412LE 16-ohm Low Parasitic Capacitance and Leakage Quad SPST Switches
- Analog Devices AD622A Low Cost Instrumentation Amplifier
- Ixys OAA160 250V Dual Normally-Open Single-Pole 8-Pin OptoMOS Relay
It seems the board has two errors in this section, with two of the traces manually cut and patched with Kynar wire. Perhaps this is an early revision of the design.
Furthermore, a look underneath the board shows that the channel interface connection to be likely hand-soldered with some flux residue and untidy soldering of the retention pins.
The power supply section uses two Monolithic Power Systems MP2358DS 2A 23V 370kHz Step-Down Converters. Unfortunately, the TI controller in the centre bottom was not identified (marked C1F TI 82K C5PC), nor is the controller in the top left of the board which seems to handle the soft-power button (marked LCWT NB53 804). There seems to be a construction issue with the inductor at the bottom near the TI controller with it seemingly nearly completely sliding off its intended pad. While the board itself is of good quality, this may be a sign of quality issues with the manufacturing process.
The digital I/O section has two Texas Instruments LV165A Parallel-Load 8-Bit Shift Registers with a number of transistors seemingly used for level shifting. The power supply is passed through a polyfuse and resistor to provide current limiting.
The area near the System-on-Module has the following identified components:
- Toradex Colibri T20 256MB System-on-Module (Nvidia Tegra 2, Nanya 256MB DDR2, 512MB (or 1GB) NAND Flash)
- Maxim Integrated DS3231S Extremely Accurate I2C Integrated RTC/TCXO/Crystal
- Texas Instruments TPS2042B Current-Limited Power-Distribution Switch
- Texas Instruments (formerly National Semiconductor) DS90CF363B +3.3V Programmable LVDS Transmitter 18-bit Flat Panel Display (FPD) Link 65MHz
- Golden Peak (GP) CR2430 Lithium Coin Cell 270mAh
Above the SoM, there is a Xilinx Spartan XC3S200 FPGA and Murata piezo-speaker.
The microSDHC card is a Transcend Premium 32GB Class 10/U1 with UHS-I interface, Made in Taiwan. This appears to be a consumer-grade card, although I suspect the large capacity should mean that the amount of write cycles accrued in regular usage should not exhaust the card’s endurance.
When inserted into a regular card reader, the card is found to be FAT32 formatted. The performance appears to reach up to 98MB/s read in a card reader, with writes about 23MB/s except for an odd spike at 128kB accesses. This seems to be a fairly average result for a modern Class 10/U1 card.
Battery Pack
The battery pack is restrained into the rear casing of the device with a cage. Removing the bolts allows us to free the pack from the case for further analysis.
The battery pack is a Jauch Li 18650JP 3S3P rated at 10.8V / 8.85Ah for a total capacity of 95.58Wh with a date code of Week 46 of 2018. As the pack is terminated into two wires into a plug, replacement of the battery is not difficult. However, this does not appear to expose any “intelligence” to the host system to accurately determine state-of-charge.
Slitting the heatshrink open and examining the pack inside shows that the unit is made of Panasonic NCR18650A cells which are rated minimum 2950mAh each with a typical capacity of 3070mAh. The configuration is 3-series, 3-parallel with balancing connections to ensure safety.
The PCB at the top takes care of protecting the battery pack and balancing the cells. I did not further disassemble the pack to avoid damaging the pack beyond repair as it requires some desoldering.
Channel Module
Unlike the main unit, the channel module is held together with six Phillips screws, one at each corner. Removing the rear cover gives a clear view of the insides.
The rear casing features plastic “boxes” around each of the sets of three connections to the pluggable terminal blocks for each channel as a form of extra safety isolation. The PCB itself is seen to contain a whole bunch of IXYS OMA160 Single Pole, Normally Open OptoMOS Relay and OAA160 250V Dual Normally-Open Single-Pole 8-Pin OptoMOS Relay and an ST 24C64WP 64kbit EEPROM.
The OptoMOS relays use a package similar to a DIP that is surface mounted. That was a bit of a surprise to me.
The top side has the remainder of the OptoMOS relays, with an Xilinx XC2C64A CoolRunner-II CPLD. The connectors appear to belong to the Phoenix Contact SM STB 2,5/5,08 series based on the markings on the terminal blocks.
The Software
Using the right techniques, it is possible to close the operating software without causing the unit to shut-down, allowing for exploration of the operating system that powers the device. It is running a Toradex-prepared Windows Compact Embedded (CE) 7.0 image from 2010. This is not a particularly recent operating system, so I would not be surprised if it has a number of security vulnerabilities (including a potential issue which allowed me to access the OS in the first place).
Interestingly, despite its age, the configuration of the Ethernet adapter seems to suggest the device has an IPv6 stack installed which may mean that the device could be reachable over an IPv6 address even though the device does not normally graphically offer any means of configuring the address. The devices mounted can be seen in the background - \FlashDisk, \SDCard, \USB HD.
Because of the system architecture, it seems the flash boot image that contains the software is mounted at \FlashDisk and as it is part of the ROM image, it is not directly modifiable. The software starts via the \FlashDisk\Autorun\demardas240.exe file which appears to be a stub that calls the main \FlashDisk\DAS240.EXE. The software itself has a name of ‘SilverlighttoCpp’, which is suggestive it probably was developed in Silverlight. The VNC server is provided by \FlashDisk\WINVNC.EXE which is “Efonvnc Server WinCE Edition”. Within the root of the image is XCDAS240.BIT which appears to be an FPGA bitstream file and various configuration files. The \FlashDisk\System folder contains netrtwlanu.dll which is a Realtek driver for Wi-Fi which suggests the ability to support certain USB Wi-Fi adapters. This is hinted in the manual, but no further information is provided. A look through the registry hives allowed me to extract the PID and VIDs for which this driver is registered against (no guarantees that the driver will actually work however):
- 050D 1102 Belkin Components F7D1102 N150/Surf Micro Wireless Adapter v1000 [Realtek RTL8188CUS]
- 050D 2102 Belkin Components F7D2102 802.11n N300 Micro Wireless Adapter v3000 [Realtek RTL8192CU]
- 0586 341F ZyXEL Communications Corp. NWD2205 802.11n Wireless N Adapter [Realtek RTL8192CU]
- 06F8 E033 Guillemot Corp. Hercules HWNUp-150 802.11n Wireless N Pico [Realtek RTL8188CUS]
- 4855 0090 Memorex? Feixun_90
- 4855 0091 Memorex? Feixun_91
- 4856 0091 ? NetweeN_91
- 07AA 0056 Corega K.K. CG-WLUSB300NS
- 07B8 8178 AboCom Systems Inc RTL8192CU
- 07B8 8189 AboCom Systems Inc ?
- 7392 7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]
- 7392 7822 Edimax Technology Co., Ltd EW-7612UAn V2
- 0BDA 5078 Realtek Semiconductor Corp. ?
- 0BDA 5088 Realtek Semiconductor Corp. RTL8188CUS
- 0BDA 8170 Realtek Semiconductor Corp. RTL8192CU
- 0BDA 8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
- 0BDA 8177 Realtek Semiconductor Corp. RTL8192CU
- 0BDA 8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter
- 0BDA 8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter
- 0BDA 817A Realtek Semiconductor Corp. RTL8188CUS
- 0BDA 817B Realtek Semiconductor Corp. RTL8188CUS
- 0BDA 817E Realtek Semiconductor Corp. RTL8192CU
- 0BDA 8191 Realtek Semiconductor Corp. ?
- 0BDA 8192 Realtek Semiconductor Corp. RTL8191SU 802.11n Wireless Adapter
- 0BDA 0179 Realtek Semiconductor Corp. RTL8188ETV Wireless LAN 802.11n Network Adapter
- 0BDA 018A Realtek Semiconductor Corp. RTL8188CTV
- 0DF6 0052 Sitecom Europe B.V. WL365
- 0DF6 005C Sitecom Europe B.V. WLA1001v1
- 0EB0 9071 NovaTech ?
- 103C 1629 ? Realtek 8188CE
- 13D3 3357 IMC Networks ?
- 13D3 3358 IMC Networks ?
- 13D3 3359 IMC Networks ?
- 2001 3307 D-Link Corp. ?
- 2001 3308 D-Link Corp. DWA-121 802.11n Wireless N 150 Pico Adapter [Realtek RTL8188CUS]
- 2001 3309 D-Link Corp. DWA-135 802.11n Wireless N Adapter (rev.A1) [Realtek RTL8192CU]
- 2001 330A D-Link Corp. DWA-133 802.11n Wireless N Adapter [Realtek RTL8192CU]
- 2019 AB2A PLANEX GW-USNano2 802.11n Wireless Adapter [Realtek RTL8188CUS]
- 2019 AB2B PLANEX GW-USEco300 802.11bgn Wireless Adapter [Realtek RTL8192CU]
- 2019 ED17 PLANEX GW-USValue-EZ 802.11n Wireless Adapter [Realtek RTL8188CUS]
- 20F4 648B TRENDnet TEW-648UBM 802.11n 150Mbps Micro Wireless N Adapter [Realtek RTL8188CUS]
Unfortunately, if you attach another adapter which has the same chipset but incorrect VID/PID, a box pops up stating that it is an unrecognised USB device and to provide the name of the driver. I’ve tried many variants of the driver name but with no success. It is also not possible to modify the registry to accept new PID/VIDs as it is part of the ROM image that is read-only. I decided to order a pair of cheap Wi-Fi adapters which claim to have compatible chipsets in the hope of finding one with a compatible PID/VID combination. The first one that arrived was an RTL8192EU rather than the CU that was ordered, but the second was an RTL8188CU with the right PID and VID for a cost of under AU$4 delivered. Plugging this into the DAS240-BAT enables the Wi-Fi connectivity which appears to function just fine (although manual address configuration is not possible). Considering the fact the official Wi-Fi option is not available in Australia and is on backorder with a high price overseas, this was a good find.
Some odd files I spotted include files named ‘POLICE.BIN’ and ‘Sniffeur.bin’ whose purposes are unknown. It appears that HTTP, FTP and SMBv1 is served by the inbuilt Windows CE server. The SMBv1 connection is protected by a password which is not provided.
A nmap scan revealed the following:
PORT STATE SERVICE VERSION
21/tcp open ftp oftpd
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| 01-01-00 00:13 <DIR> FolderREC
|_01-01-00 02:54 <DIR> FolderBMP
| ftp-syst:
|_ SYST: Windows_CE version 7.0.
23/tcp open telnet?
80/tcp open http Microsoft Windows Embedded CE Web Server
| http-methods:
|_ Supported Methods: GET HEAD POST
|_http-server-header: Microsoft-WinCE/7.00
|_http-title: Did not follow redirect to \WebService\index.html
139/tcp open netbios-ssn?
443/tcp open tcpwrapped
445/tcp open microsoft-ds
| fingerprint-strings:
| SMBProgNeg:
|_ SMBr
502/tcp open modbus Modbus TCP
5800/tcp open vnc-http RealVNC 4.0 (resolution: 400x250; VNC TCP port: 5900)
| http-methods:
|_ Supported Methods: GET HEAD
|_http-server-header: RealVNC/4.0
|_http-title: VNC viewer for Java
5900/tcp open vnc VNC (protocol 3.8)
| vnc-info:
| Protocol version: 3.8
| Security types:
|_ VNC Authentication (2)
8080/tcp open tcpwrapped
|_http-cors: GET POST
| http-methods:
|_ Supported Methods: OPTIONS
|_http-title: Site doesn't have a title.
8181/tcp open intermapper?
123/udp open ntp NTP v4 (secondary server)
| ntp-info:
|_ receive time stamp: 2019-12-30T19:29:12
137/udp open netbios-ns Samba nmbd netbios-ns (workgroup: d)
The results of the scan suggest that it’s probably not a good idea to leave the unit running on an insecure or shared network as there are many servers running with some available with no credentials (FTP, HTTP) or insecure versions (SMBv1). There also seems to be a Telnet port open which is used by DasLab to retrieve and push set-up information without authentication. The HTTPS port does not behave the way you might expect - it does not complete a connection. It seems the VNC server also serves an HTTP page on port 5800 with a Java applet for in-browser viewing which is a “hangover” of the past, now that Java is no longer permitted to run within web browsers. The use of Port 8080 and Port 8181 are a bit mysterious, along with the serving of NTP when I only requested that the unit use NTP to synchronise its own time. Of note is that because the unit does not allow the configuration of a DNS server address via its main interface, NTP servers must be entered in as an IP address (unless DHCP is used presumably).
Conclusion
The B&K Precision / Sefram DAS240-BAT feels to be a sturdy and chunky unit held together by plastic rivets. Disassembly is simple and can be done without tools, voiding the warranty/calibration seal. Internally, the unit is built around a Toradex Colibri T20 System-on-Module, with an Analog Devices AD7694 16-bit 250kS/s PulSAR DAC and ADR02 Ultracompact, Precision 5.0V Voltage Reference as the core of the analog solution. This is supported by a number of other components including a number of Xilinx FPGA/CPLDs, solid-state optoisolated relays, isolators, real-time clock, LCD panel driver and power converters. The digital side appears to rely on a set of level shifting transistors and parallel-load shift-registers, with power supply via a resistor and PTC self-resetting fuse. Power is supplied from a Jauch 18650JP 3S3P pack rated at 10.8V / 8.85Ah / 95.58Wh constructed using Panasonic NCR18650A cells of 2950mAh (min) / 3070mAh (typ). The channel module makes plentiful use of IXYS OMA160 and OAA160 OptoMOS Relays for switching each channel and module. Storage is provided by a Transcend Premium 32GB microSDHC Class 10/U1 card.
The unit itself runs a Toradex-provided build of Windows Embedded Compact (CE) 7 from 2010 with a custom-developed application from the internal ROM image that houses the OS. The unit hosts VNC using Efonvnc Server WinCE Edition, with ModBus TCP served by the custom application and the remainder by the operating system’s included servers. I would not recommend attaching the device to an insecure or shared network as many of these servers do not need credentials for access (FTP, HTTP, ModBus) or are themselves insecure (SMBv1). The fact that I was able to crash their custom application to gain access to the OS suggests the security is less than optimal. The support for Wi-Fi connectivity appears to be limited to those supported by netrtwlanu.dll which include a range of Realtek-based adapters with specific product IDs, mostly from the 802.11n generation.
---
This post is part of the B&K Precision/Sefram DAS240-BAT Multi-Channel Recorder RoadTest Review.