Plat Home OpenBlocks IoT VX2 Instruction Manual

OpenBlocks IoT Family
Developer Guide
Version 3.1.0
Plat'Home Co., Ltd.

■About trademarks
・Linux is a trademark or registered trademark of Linus Torvalds in the United States
and/or other countries.
・Company and product names mentioned in this Developer Guide may be trademarks or
registered trademarks of their respective companies.
・Product names and other proper nouns in this Developer Guide are trademarks or
registered trademarks of their respective companies.
・Docker and Docker logo are trademarks or registered trademarks of Docker, Inc. in the
United States and/or other countries. Docker, Inc. and other parties may also have
trademark rights in other terms used herein.
■Before using this product
・No reproduction of this material is allowed without written permission of Plat'Home Co.,
Ltd.
・Content and information contained within this material may be changed or updated
without prior notice.
・We consistently aim to keep the content in this material as precise as possible. However,
should any errors in descriptions, etc. be noticed, please contact Plat'Home Co., Ltd.
The latest version of this material can be downloaded from our website.
・While using this product, please be aware that it is not designed or assumed for use in
fields where there is a risk to life.
・Regardless of the aforementioned, in no event will Plat'Home be liable for any special,
incidental, indirect or consequential damage arising out of use of this product, including
but not limited to damage to profits or loss.

3/39
Table of contents
Chapter 1 General.................................................................................................................. 5
1-1. Items included in package for VX2.............................................................................. 5
1-2. Names of parts (VX2 main body)................................................................................ 6
Chapter 2 Before starting to use the OpenBlocks IoT Family................................................ 8
2-1. Product overview......................................................................................................... 8
2-2 Cautions about SSD-based system development ....................................................... 8
2-3 About SIM cards ..........................................................................................................11
2-4 eMMC storage partition information............................................................................11
2-5 Storage mode............................................................................................................. 12
2-6. Connecting PC to OpenBlocks IoT Family................................................................ 13
2-7. WEB UI...................................................................................................................... 14
Chapter 3 Using the OpenBlocks IoT Family....................................................................... 15
3-1. Indication colors of status indicators......................................................................... 15
3-2. Modem control for mobile networks.......................................................................... 18
3-3-1. On-demand connections........................................................................................ 20
3-3-2. User control of mobile network modem ................................................................. 21
3-4. Backup....................................................................................................................... 24
3-5. Restoration ................................................................................................................ 25
3-6. Applications................................................................................................................ 26
3-7. WEB UI extensions.................................................................................................... 27
3-7-1. Script editing........................................................................................................... 27
3-7-2. Command execution .............................................................................................. 28
3-7-3. SMS command execution...................................................................................... 28
3-8 Switching boot modes................................................................................................ 29
3-9. WEB UI extensions.................................................................................................... 29
3-10. Special setting of WEB UI filter table ...................................................................... 29
3-11. Sending SMS messages ......................................................................................... 30
3-12. Switching operations of LTE module (KDDI)........................................................... 30
3-13. Factory Reset (Reset to condition at time of factory shipment).............................. 32
3-14. Recovery startup ..................................................................................................... 33
3-15. Building a cross-development environment............................................................ 33
3-16. Automatic external storage mounting in WEB UI.................................................... 34
3-17. Recommended device files to use.......................................................................... 35
3-18. Docker ..................................................................................................................... 35
Chapter 4 Product specifications ......................................................................................... 36

4/39
4-1. Open Blocks IoT VX2 main body specifications ....................................................... 36
4-2. OpenBlocks IoT VX series options............................................................................ 37
4-2-1. 3G module.............................................................................................................. 37
Chapter 5 Cautions and supplementary information............................................................ 38
5-1. Countermeasures against delays due to script processing...................................... 38
5-2. List of ports used....................................................................................................... 38

5/39
Chapter 1 General
This manual is a developer guide for the OpenBlocks IoT Family.
If a general user, please refer to the OpenBlocks IoT Family WEB UI Set-up Guide.
1-1. Items included in package for VX2
Standard configuration of OpenBlocks IoT VX2 is as follows:
1 x VX2 main body
1 x USB Type-A Micro USB cable
1 x Start-up Guide
1 x AC adapter
1 x Heat radiation and installation bracket

6/39
1-2. Names of parts (VX2 main body)
No.
Name
Remarks
①
USB serial console port
Micro USB Micro-B
②
Ethernet port 0
10BASE-T / 100BASE-TX / 1000BASE-T
③
Ethernet port 1
10BASE-T / 100BASE-TX / 1000BASE-T
④
Power switch
Shuts down OS if in operation.
Starts up OS if not in operation.
⑤
FUNC switch
Enables allocated functions.
⑥
Status indicator
LEDs illuminate or flash in seven colors.
⑦
RS-485 (half duplex) connector
⑧
Wide range power supply input
⑨
USB host mode port
A-Type/USB3.0
⑩
USB host mode port
A-Type/USB3.0
⑪
FUNC switch
Enables allocated functions.

7/39
No.
Name
Remarks
⑫
Power switch
Shuts down OS if in operation.
Starts up OS if not in operation.
⑬
Status indicator
LEDs illuminate or flash in seven colors.
⑭
SIM slot
Slot for inserting SIM card.
*Supports mini-SIM card format (2FF) (standard
SIM)
⑮
MMC slot
As MMC cards cannot secure sufficient reliability
for system operations, use them for file exchanges
and log storage only.
⑯
Expansion slot 2
Expansion slot for EnOcean, Wi-SUN and other
modules.
⑰
Expansion slot 1
Expansion slot for mobile adapter card of mobile
networks.
Mobile adapter card supporting carrier To be use is
mounted. Essentially, this is a factory option.
⑱
DIP switch
As this switch is set prior to factory shipment, do
not alter the settings.
SW1-3: For modem identification
SW4-5: Not used
SW6: OFF=RS485 terminator ON (default)
⑲
Holes to install external antenna
Holes are unopened in image.
⑳
Holes to mount heat radiation
and installation bracket
*To insert a SIM card, turn the VX2 main body upside down and insert into the back of the
slot. Similarly, to remove a SIM card, turn the VX2 main body upside down and extract the
card.
●Modem type identification
Modem type
SW1
SW2
SW3
3G module
ON
OFF
OFF
Modem uninstalled
ON
ON
ON

8/39
Chapter 2 Before starting to use the
OpenBlocks IoT Family
2-1. Product overview
The OpenBlocks IoT Family is a general-purpose server product employing Debian
GNU/Linux as an OS. Though customized to take advantage of hardware properties, it is
possible to use the OpenBlocks IoT Family in a general operational method for Debian and
other Linux products, apart from such customization.
2-2 Cautions about SSD-based system development
In recent times, cost reductions in flash memories have led to the employment of Solid State
Drives ("SSD"), replacing conventional hard disk drives used in smartphones, laptop PCs
and many other devices. This product uses embedded MMC (eMMC), which is a type of
SSD.
With advantages such as high-speed random access performance and solid-state design,
SSD has extremely high resistance against mechanical failures and environmental
performance. However, compared to hard disk drives, the data writing limit is a lot less.
SSD can generally be divided into SLC and MLC. The SLC type with tens of thousands of
counts of write performance was the mainstream in the capacity range of a few gigabytes,
but the low-cost MLC with a write count of thousands has drastically increased capacity and
is applied to smartphones and PCs. Currently, SLC SSDs are gradually being faded out.
In actual fact, SLC products as options for our micro-servers only remain in the range of
small capacity products.
Thus, the number of operations with micro-servers using MLC SSD is enormous.
Generally, MLC has a write capability of 3,000 times. Just beyond 3,000 times, it starts to
cause bit errors, which can be recovered with ECC.
As soon as MLC exceeds the limit for an ECC recovery, read errors will be caused.
Therefore, consider system design to avoid MLC being in this condition.

9/39
●Write count per cell and block size of flash memory
Despite a write capacity of 3,000 times per cell, just one byte of writing onto an SSD means
one count.
To support large capacity with a small number of address lines, recent flash memory is read
and written in a block as large as 512 KB.
In other words, writing one byte or 512 KB is counted once.
For this reason, in relation to writing on SSD, it is possible to minimize the number of write
counts on SSD by writing in large data sizes through accumulating as much data as possible
in a buffer, as opposed to writing in small data sizes with more counts.
●Wear leveling function
As SSD can endure only a relatively small number of write cycles in a specific block, it will
average the number of writes so that the writes do not concentrate on the same actual block
address against actions to write onto the same block over and over.
This is achieved by virtualizing block addresses.
OS will notify used and unused blocks to SSD. In order to be ready for a next write to be
performed, SSD will prepare a block with the smallest number of writes for a write.
By doing so, the number of writes to individual blocks are consequently averaged out.
●Static wear leveling
In the case of conventional wear leveling, it is assumed that 50% of data is in a used domain
and rarely rewritten. This means that since installation of OS, 50% of available blocks are
written only once.While these blocks are virtually new, the remaining 50% are rewritten over
and over. Compared to the case where rewriting is averaged, the end life for SSD comes
twice as fast.
As a countermeasure to this, static wear leveling was devised. Data in rarely rewritten
blocks are moved to frequently rewritten blocks, while applying blocks that are virtually new
to a domain for reuse.
By doing so, even if 50% of blocks are rarely written, the life of SSD is almost fully exploited.
●Assuming total write cycles of SSD
For example, supposing there is a 4-gigabyte SSD using 512 KB blocks and 3,000 write
cycles per cell available. If writing data of 512 KB or less, we can assume that the total
number of write cycles of SSD is as follows:
4,294,967,296 Bytes ÷ 524,288 Bytes = 8,192 (4 GB ÷ 512 KB）

10/39
Number of physical blocks is 8,192.
If each of them are rewritten 3,000 times:
8,192 × 3,000 = 24,576,000 times
In other words, if writing one-byte data per time, the life will end when writing 18.4MB.
(Actually, SSD promotes efficiency of such writes). Furthermore, if assuming that for writes
of 512 KB in size, a block segment does not overlap the border of 512 KB, it will be one write,
whereas in fact, file access by OS may start writing in the middle of the block, so even if a
write of 512 KB or less is written twice with a 50% probability.
i.e.
24,576,000 times x 75% = 18,432,000 times (Only 512 KB writes are assumed here).
Furthermore, with access from OS, one more write cycle is added.
This is due to the fact that updating a file control block in the file closing process will result in
at least one rewrite.
Of course, SSD further reduces the number of write cycles by, for example, using cache, but
basically, this is the mechanism for processing.
●Use an SSD that is as large as possible
For example, the above-mentioned 4-gigabyte SSD has 8,192 blocks, but if there is a
8-gigabyte SSD, it has 16,384 blocks, which is twice that of a 4-gigabyte SSD. Simply put,
the number of write cycles is twice.
If SSDs have the same block size, the number of write cycles will simply increase in
proportion to the size.
For this reason, by using an SSD as large in size as possible, it will resist against problems
caused by an increasing number of writes.
●Reducing the number of writes to SSD by using tmpfs
In a Linux system, system development without due consideration will assume that storage
can be used as a device that can be used infinitely.
Even if no data storage is required, storage domain will be carelessly used as a buffer for
operation.
To avoid reducing the life of SSD for such a reason, give due consideration to system design