Introduction

This guide intends to help you quickly and easily get the TS-7250-V3 up and running; the following guide provides a more casual step-by-step approach for setting up everyday connections, networking, and environments to begin development.

The official manual contains more detailed and advanced information if you want to dig deeper into the specifications.

Connections

The connections most commonly used for development are serial console, power, and Ethernet. An optional chip that delivers WiFi/Bluetooth connectivity (with a u.FL Antenna) is also available; this chip is part of the development package but is a special request for the standard package.

Serial Console

The serial console allows direct access to the embedded system device and is generally the most reliable. The TS-7250-V3 has two separate options for connecting to the serial: the DB-9 port via the enclosure (“RS-232”) or the micro USB connector inside the enclosure. As a side note, the DB-9 port might require a separate adapter if there is no serial port on your workstation.

The DB9 port uses 115200 baud 8n1 with no flow control. The built-in USB serial device is hard coded to the correct baud/mode and does not require configuration.

To access the micro USB inside the enclosure: flip the enclosure over and remove the four screws on the bottom. Pull the enclosure apart; on the inside, there will be four more screws on the device to remove for access to the micro USB.

Until power is connected, the console window will be black. The device will output information via console once power is connected.

The preference is always to use Linux OS for our products, though the official manual contains all the information necessary to connect to the console on any OS. 

Your serial device name will depend on the OS used, but the typical names to expect are

• Linux: /dev/ttyACM0
  • The Linux device number might change based on the number of devices connected to the system.
• Mac OSX: /dev/tty.usbmodem00D069C0FFEE1
  • The MAC address determines the Mac OSX device number; it will be different for every device.
• Windows: use Device Manager to discover the COM port

Power

The TS-7250-V3 accepts power two ways: variable input voltage between 8 to 28 VDC via the enclosure and fixed input voltage of 5 VDC inside the enclosure. Only connect to one power source at a time.

Ethernet

For network access, the device supports two independent Ethernet ports, eth0 (or end0) and eth1 (or end1), both labeled on the outside of—and accessible via—the enclosure. These ports will fit a standard Ethernet cable; connect the other end to a router or switch and continue reading for setup instructions.

Wireless Module (Optional)

The development kit includes an optional wireless module. This module is otherwise available by request for other kits, such as the standard kit.

The wireless module requires a separate u.FL Antenna and can be ordered through embeddedTS. Carefully plug the antenna into the available port on the WiFi chip, accessible within the enclosure.

The wireless module allows easy updating of your device over a WiFi connection. We will cover the basics of setting up networking over WiFi further down. For more detailed information on setting up the WiFi module, start at the “Networking” section of the manual.

First Linux Boot

With serial and power applied, the TS-7250-V3 will by default boot to the Embedded MultiMedia Card (eMMC), which is pre-programmed to load our default Debian 12 – Bookworm image. Once this version of Linux loads, it will ask the user to log in with their username and password. 

The default password is “root” with no password. You can change this any time after logging in by using the command “passwd” to set an account password.

About the Embedded Linux Environments 

The TS-7250-V3 can boot to several different operating systems and environments via U-Boot, a preinstalled bootloader on the device. U-Boot is installed in the eMMC hardware boot partition and can be customized to boot images from the microSD, eMMC, NFS, or USB.

By default, U-Boot will look for a USB mass storage device before using the pre-programmed eMMC with our Debian 12 image. For U-Boot commands, both basic and advanced, see the “U-Boot” section of the manual.

As mentioned, the TS-7250-V3 will automatically boot our Debian 12 – Bookworm image unless configured otherwise. More detailed and advanced information is available in the “Debian 12 – Bookworm” section of the manual. The rest of this guide uses Debian 12 commands.

A new addition to Debian 12, relevant for the next section, is that network interfaces now follow predictable network interface names; eth0 and eth1 are no longer the default for Ethernet connections. You can find a thorough explanation for the new network naming here, but this guide will cover the basics of getting set up with the new naming schemes. 

(If booting from an older version of Debian, you can refer back to the “Debian 11 – Bullseye” section of the manual for examples using the older naming scheme, such as eth0 and eth1, for Ethernet connections.)

Networking Set Up

The TS-7250-V3 allows both wired and wireless methods to connect to a network. This section will walk you through how to set up Ethernet or Wireless connections, get an IP address dynamically or statically, and, using WiFi, connect to various types of access points.

Full details are available in the “Debian 12 – Networking” section of the manual. As mentioned above, Debian 12 uses new naming schemes; generally, eth0 is now end0 and eth1 is now end1.

To start, in your console, list network interfaces by running

ip addr show

The most common network interfaces are

• end0 – Ethernet device 0 (CPU Ethernet) 
• enp1s0 – Ethernet PCIe port 1 slot 0 ethernet 
• usb<mac> – USB ethernet 
• wlan0 – WIFI

Pro-Tip: The interface marked as “1” on the enclosure (reference designator “T2” on the PCB silkscreen) is end0; the interface marked as “0” on the enclosure (reference designator “T1” on the PCB silkscreen) is end1. 

Wired

The Debian networking wiki has more advanced details, such as adding IPv6 to dynamic or static IP setups. The steps below also apply to end1 if you want to use both Ethernet ports.

Dynamic IP

Getting an IP via DHCP is convenient for most applications.

In your console of choice, edit the file

/etc/network/interfaces

go to the bottom of the file and paste 

auto end0

iface end0 inet dhcp

These commands will enable the end0 network interface and allow the device to get an IP address dynamically; both will happen automatically on future boots.

Any changes made will take effect on the next boot; you can also manually cycle the network interface to apply the changes with

ifdown end0

ifup end0

Double-check the connection information on the next boot by using the ifconfig command. The example device was assigned a dynamic IP of 10.10.10.193.

root@tsimx6ul:~# ifconfig

end0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 10.10.10.193  netmask 255.255.255.0  broadcast 10.10.10.255

        inet6 fe80::ea1a:58ff:fe00:60d5  prefixlen 64  scopeid 0x20<link>

        ether e8:1a:58:00:60:d5  txqueuelen 1000  (Ethernet)

        RX packets 332  bytes 28642 (27.9 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 54  bytes 4644 (4.5 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

        inet 127.0.0.1  netmask 255.0.0.0

        inet6 ::1  prefixlen 128  scopeid 0x10<host>

        loop  txqueuelen 1000  (Local Loopback)

        RX packets 3968  bytes 309280 (302.0 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 3968  bytes 309280 (302.0 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The device can now ping an external URL to test the connection.

root@tsimx6ul:~# ping debian.org

PING debian.org (151.101.194.132) 56(84) bytes of data.

64 bytes from 151.101.194.132 (151.101.194.132): icmp_seq=1 ttl=59 time=4.29 ms

64 bytes from 151.101.194.132 (151.101.194.132): icmp_seq=2 ttl=59 time=3.62 ms

64 bytes from 151.101.194.132 (151.101.194.132): icmp_seq=3 ttl=59 time=7.25 ms

64 bytes from 151.101.194.132 (151.101.194.132): icmp_seq=4 ttl=59 time=3.63 ms

64 bytes from 151.101.194.132 (151.101.194.132): icmp_seq=5 ttl=59 time=3.78 ms

64 bytes from 151.101.194.132 (151.101.194.132): icmp_seq=6 ttl=59 time=6.99 ms

^C

— debian.org ping statistics —

6 packets transmitted, 6 received, 0% packet loss, time 5014ms

rtt min/avg/max/mdev = 3.619/4.926/7.245/1.565 ms

Static IP

The static IP setup is similar to the dynamic IP setup from above.

In your console of choice, edit the file

/etc/network/interfaces

go to the bottom of the file and paste 

auto end0

iface end0 inet static

    address 192.0.2.7/24

    gateway 192.0.2.254

These commands will enable the end0 network interface and force the device into the assigned IP; both will happen automatically on future boots.

Any changes made will take effect on the next boot; you can also manually cycle the network interface to apply the changes with

ifdown end0

ifup end0

Double-check the connection information on the next boot by using the ifconfig command. The example device was assigned a static IP of 192.0.2.7.

root@tsimx6ul:~# ifconfig

end0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.0.2.7  netmask 255.255.255.0  broadcast 0.0.0.0

        inet6 fe80::ea1a:58ff:fe00:60d5  prefixlen 64  scopeid 0x20<link>

        ether e8:1a:58:00:60:d5  txqueuelen 1000  (Ethernet)

        RX packets 2989  bytes 243473 (237.7 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 107  bytes 7648 (7.4 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

        inet 127.0.0.1  netmask 255.0.0.0

        inet6 ::1  prefixlen 128  scopeid 0x10<host>

        loop  txqueuelen 1000  (Local Loopback)

        RX packets 3968  bytes 309280 (302.0 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 3968  bytes 309280 (302.0 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Test your connection by pinging your gateway, 192.0.2.254. 0% packet loss in the below report means your connection is running as expected.

root@tsimx6ul:~# ping 192.0.2.254

PING 192.0.2.254 (192.0.2.254) 56(84) bytes of data.

64 bytes from 192.0.2.254: icmp_seq=1 ttl=64 time=6.80 ms

64 bytes from 192.0.2.254: icmp_seq=2 ttl=64 time=3.81 ms

64 bytes from 192.0.2.254: icmp_seq=3 ttl=64 time=3.62 ms

^C

— 192.0.2.254 ping statistics —

3 packets transmitted, 3 received, 0% packet loss, time 2007ms

rtt min/avg/max/mdev = 3.621/4.741/6.797/1.455 ms

Wireless (Optional)

The wireless section only applies if you have ordered the development package or have requested the optional wireless module. Please make sure the u.FL antenna is attached.

This part of the guide will cover setting up a protected access point, which works for WPA and WPA2. It will be utilizing the wpasupplicant utility. For more detailed information on WiFi configurations, see the Debian guide on how to use WiFi.

If you want to use the TS-7250-V3 as a Wireless Access Point, see the “WiFi Access Point” section of the official manual.

Important note: embeddedTS includes many applications in the Debian 12 image that are useful. The instructions below should work seamlessly; however, if you have issues getting WiFi to work correctly, install “wpasupplicant” using your console of choice.

Install wpasupplicant

apt-get update && apt-get install wpasupplicant -y

Protected Access Point

Scan for available access points using

iwlist wlan0 scan

or filter so only the essid names are visible by using

iwlist wlan0 scan | grep ESSID | cut -d’:’ -f2

Once you know the protected network you want to connect to, run

wpa_passphrase yourssid yourpassword

The command output will look similar to the text below but contain your personalized information.

 network={

        ssid=”yourssid”

        #psk=”yourpassword”

        psk=151790fab3bf3a1751a269618491b54984e192aa19319fc667397d45ec8dee5b

 }

Use the hashed pre-shared key (PSK) in the specific network interface file for added security.

In your console of choice, edit the file

/etc/network/interfaces

go to the bottom of the file and paste 

allow-hotplug wlan0

iface wlan0 inet dhcp

    wpa-ssid yourssid

    wpa-psk 151790fab3bf3a1751a269618491b54984e192aa19319fc667397d45ec8dee5b

Be sure to edit “yourssid” with your ssid and the PSK characters with the PSK output you received when you ran wpa_passphrase. 

In the text above, allow-hotplug wlan0 makes the WiFi connection persistent upon rebooting the device; iface wlan0 inet dhcp automatically assigns a dynamic IP.

Any changes made will take effect on the next boot; you can also manually cycle the network interface to apply the changes with

ifdown wlan0

ifup wlan0

Conclusion

The Practical Guide to Getting Started with the TS-7250-V3 covered the available ways to connect to the console for communication with the device, apply power, and set up Ethernet and WiFi networking. These will allow you to begin development on your application.

The official manual will fill in the blanks for other advanced information.

Did the TS-7250-V3 Getting Started Guide miss anything? Comment below so we can get it added!

su -

2.) Plug in your SD card and then use the following
command to see which /dev/ node it’s located on (be sure of this!):

fdisk -l

3.) Unmount the disk (using /dev/sda as example, verify with step 2):

umount /dev/sba*

4.) Use the ‘dd’ command to copy the image file (ts-image.dd) to the
entire disk:

dd if=ts-image.dd of=/dev/sda

Also, you can write the image to the specific partition number with:

dd if=ts-kernel.dd of=/dev/sda1

Mac OSX

1.) Become root:

su

2.) Plug in your SD card and then use the following
command to see which /dev/diskN node it’s located on:

diskutil list

3.) Unmount the disk where “N” is the number of the disk taken from the above
command:

diskutil unmountDisk /dev/diskN

If the above command was successful, you will see:

Unmount of all volumes on diskN was successful

4.) Use the ‘dd’ command to copy the image file (ts-image.dd) to the
entire disk:

dd if=ts-image.dd of=/dev/diskN

Also, you can write the image to particular partitions of the disk with (N is
the disk number and P is the partition number):

dd if=ts-kernel.dd of=/dev/diskNsP

The process to do this under Linux is very similar except that it’s not
required
to un-mount the drive before using the ‘dd’ command and the commands are a
little different. For example, you would use “fdisk -l” instead of “diskutil
list”, your device node would be located at “/dev/sda” instead of “/dev/disk”
and the un-mount command is “umount” instead of “diskutil unmountDisk”.

Windows

Currently, there is a ‘dd’ command for Windows, but it does not support writing to block
devices, which is what an SD card is. You will need to use a Linux box near you or use a Linux
virtual machine. Technologic Systems has put together such a virtual machine, TS-VIRTUAL-DEV which uses VirtualBox.
You can download the virtual image here: https://files.embeddedTS.com/misc/virtualbox/ts-virtual-dev/    or  Home

Imagine for a moment that you’re in charge of a new scientific research project where a remote device will be deployed to automatically collect data samples and report back to the lab. The device might be deployed several times to different locations throughout the year, and one requirement is that a scientist back at the lab can send a command to actuate some mechanical device, like a motor, and respond with collected data or status at any given time. For a project like this, you’ll need to somehow wirelessly communicate with the device. These remote areas are likely well beyond the reach of cellular or other far-reaching radio signals.                      Home

Enter the Iridium global communication satellite solution. With a constellation of over 60 low orbit satellites, it covers the entire globe allowing communications to and from any location you might deploy your device to. The Iridium service is used by many organizations that rely on global coverage such as Garmin’s InReach and similar products to ensure the safety of outdoor enthusiasts, forest service personnel, and aid in search and rescue efforts.

In our scientific research project scenario, this technology fits perfectly with the communication requirements, but there are other considerations. For instance, the computer system that will be using sensors and actuators to collect and perform actions in the environment needs to be able to function reliably where there isn’t a proper power grid and temperatures swing from one extreme to the next.

Enter the Technologic Systems line of embedded computers, which have very low power requirements and are engineered to withstand even the harshest environments. These computers can run off of a battery for a long time and are easily powered using solar, wind, or water energy. Operating temperatures are advertised as -40 °C to 85 °C (industrial temperature range), enough of a range to deploy to anywhere on the planet. They are easy to program and have a host of inputs and outputs to connect sensors and actuators that make automation straightforward.

Pairing Iridium with a Technologic Systems embedded computer would satisfy the requirements for this scientific project in a big way, not to mention reducing the time it would take to deploy and get started collecting data!

This is the TS-IRIDIUM peripheral paired with the TS-7800-V2 single board computer. This embedded solution uses an Iridium 9602 short burst data modem, giving you access to the entire Iridium satellite constellation. The embedded computer is powered by a fanless, dual-core 1.3 GHz ARM CPU and has tons of GPIO, several analog to digital converters (ADC) and UARTs for gathering sensor data and controlling external components. The TS-7800-V2 and TS-IRIDIUM combined require less than 5 W of power to operate, and only consume an extremely low 3 mW power while in sleep mode.

The TS-IRIDIUM along with the Iridium modem command set are fully documented on our website. The documentation covers topics such as how to check for proper Iridium antenna positioning for best performance as well as a quick start tutorial on sending and receiving your first message. The TS-7800-V2 manual contains plenty of reference code for interfacing with sensors and other devices through UARTs or GPIO pins. These resources give you a jump start on your project so you can reliably send computer commands and gather data remotely.

The Iridium global communications technology paired with Technologic Systems’ line of products makes for a very compelling solution to any project where wireless communications and low power are requirements.

If this example scenario sounds like something similar to what you’re needing, we encourage you to reach out to our sales team today either by phone (480-837-5200) or email to discuss getting this technology in your hands as soon as possible.                                                  Home

Single Level Cell (SLC) NAND flash is no longer the stuff of headlines. Consumer markets are chasing the latest nodes and densities in Multi Level Cell (MLC), Tri-Level Cell (TLC), or the up and coming 3D NAND memories, leaving SLC NAND to the smaller “high reliability” market. However, in the world of embedded systems where product life cycles are measured in decades rather than years, SLC NAND is still in heavy use. Despite continued use in applications requiring long life or high-reliability solutions, NAND manufacturers have quietly made changes to their SLC NAND offerings that have slowly decreased the endurance of SLC NAND.                                                      Home

A Completely Different Story

The SLC NAND being manufactured today is not the same as the SLC NAND that was available even a few years ago. While today’s SLC NAND still has higher endurance than any other NAND technologies manufactured today, the endurance is significantly less than the 5x nm and larger SLC NAND of yesteryear. The 5x nm and larger SLC NAND devices need very little management to be reliable in an embedded system. Simple single bit error correcting algorithms more than suffice to make 5x nm and larger SLC NAND useable in most applications. A little bit of management and redundancy can make an embedded system with this NAND practically impervious to flash wear out, and even industry experts view wear-leveling as a “plus” in 5x nm SLC applications. Today’s SLC NAND devices, however, are a completely different story, and the industry has downplayed or overlooked the changes to SLC NAND in favor of its flashier cousins.

Along with DDR RAM, NAND flash has been a driver of lithographic process node scaling. When NAND was introduced in 1984, the size of the process node was 0.7μm and endurance was 100,000 or more program/erase cycles. This endurance was maintained through the 5x nm process nodes, but as it transitioned to 4x/3x nm technology, the endurance dropped to 70,000 and fewer program/erase cycles per cell (Figure 1). Current leading NAND lithographies are less than 2x nm. A closer look at NAND flash technology shows that even users of SLC NAND need to be concerned about decreasing NAND endurance, especially in embedded or high reliability applications.

The number of program/erase cycles a cell can endure before the erased state of cell is no longer discernible from the programmed state determines NAND flash endurance. However, in practical application it is determined by how long a flash cell can be used before unrecoverable data corruption occurs. There are several methods of data corruption, all of which are impacted by shrinking process lithographies.                                                            Home

Flash Memory Construction

A single bit of flash memory is constructed of a transistor with a floating gate. The floating gate can be used to store electrons for an extended time. Electrons get to the floating gate by tunneling through to the thin oxide layer that isolates the floating gate (Figure 2). This tunneling effect is created when a large gate voltage is applied to the device. The gate voltage creates a field in the channel, increasing the energy of the electrons and causing some of them to tunnel through the thin oxide layer. The charge can be removed from the floating gate by reversing the gate voltage and pushing the electrons back through the thin oxide layer.

When electrons are stored on the floating gate, the threshold voltage, or the gate voltage where the transistor begins to conduct, changes. If there are no electrons on the gate, then the transistor acts like a normal MOSFET. When electrons are stored on the floating gate, their negative charge shields the conductive channel from the gate and prevents or limits the current flow from the source to the drain. This change in the threshold voltage modulates the current/voltage characteristics of the cell, so the status of the floating gate can be read by simply applying a voltage to the terminals and measuring the resulting current.                  Home

As the NAND flash lithography nodes are scaled down, the number of electrons available to move to the floating gate decreases. This is a well discussed fact for MLC NAND, but the same physics applies directly to SLC flash as well. In smaller lithographies, a small change in the number of electrons on the floating gate can dramatically affect the threshold voltage (Figure 3). With each reduction in NAND flash lithography, it becomes very difficult to achieve the same performance and endurance of the previous process node. The reduced number of electrons available makes smaller lithography devices even more susceptible to threshold voltage shifts caused by damage, leakage or disruptions.

The gate threshold voltage is variable regardless of what lithography a NAND cell is made on. As it can be affected by a number of factors, it is typically expressed as a statistical distribution. The statistical distribution of the threshold voltage on new flash defines the difference between a programmed and an erased cell. The voltages used in programing a NAND flash cell slowly damage the thin oxide layer that isolates the floating gate, allowing more charge to be trapped on the floating gate. At any geometry, this damage will accumulate over time, narrowing the gap between the threshold regions and pushing the threshold voltage of an erased cell over the detection threshold used to detect the programmed state (Figures 4, 5). At smaller lithographies the geometries used in the NAND construction are even smaller, resulting in faster wear out and lower endurance. In an embedded system this means that the same software application can wear out newer SLC NAND at much faster rates than ever before.

Another source of variability in the gate threshold voltage is accidental charge collection. Flash cells are structured in vast arrays, with each cell packed tightly with its neighbors. Programming or reading a cell will apply elevated voltage stress to all the neighboring cells. Occasionally this stress will cause electrons to accidentally tunnel up onto the floating gates of the neighbor cells. As any change in charge will affect the threshold voltage of a cell, these accidental electrons can cause a cell to appear programmed when it should be erased. Luckily the acquisition of accidental electrons does not wear out the oxide layer, and the electrons are easily removed with an erase of the flash. With shrinking lithographies bringing individual cells closer to each other, the chances of accidental charge collection are much higher.              Home

Error Correcting Techniques

Accidental charge collection from a neighboring NAND cell being programed or read can be detected by using error correcting techniques. There are several error correction algorithms used with NAND flash, but all of them entail calculating and storing an extra value that allows an error to be detected, known as the Error Correcting Code (ECC). By utilizing the error correction algorithm as data is read back from the NAND flash, program or read disruptions in NAND cells can be detected. In addition to detecting the error, a small enough error can also be corrected. If the error is correctable, the affected NAND cell can be erased and reprogrammed again with the correct data and remain useful in an embedded system for many more program/erase cycles. Smaller lithography devices require more bits of ECC in order to compensate for the increased likelihood of a disruption due to the smaller geometries (Figure 6). A higher number of ECC bits required for a NAND flash device is frequently the best indicator that a smaller lithography is in use, and that the overall endurance of the device has also decreased.                                                                

SLC NAND manufacturers have been quietly rolling out smaller lithography devices with little comment about the decreasing endurance of the devices. SLC NAND flash users are being forced to transition to smaller lithography NAND flash as larger lithography devices are no longer available on the market. Embedded systems’ need for high reliability storage hasn’t changed, but suddenly the endurance of the SLC NAND has. The days of inherently reliable SLC NAND have silently slipped away leaving many embedded systems stuck with NAND flash that no longer endures under the same real life applications. How will the market adjust to address the needs of the end customers? Technologic Systems will be addressing it in its products by offering a state of the art SLC NAND management solution. For details about this new NAND management layer please read our white paper “XNAND2: NAND Device Driver for Today’s Lower Endurance SLC NAND”.                  Home

References:

• “Advanced Flash Technology Status, Scaling Trends & Implications to Enterprise Scaling Trends & Implications to Enterprise SSD Technology” by Jung H. Yoon & Gary A. Tressler, IBM Corporation, Aug 21, 2012
• Cypress Semiconductor “AN200602 SLC Versus MLC NAND Flash Memory” Document No. 002-00602 Rev. *A, Nov 6, 2015
• “The Inconvenient Truths of NAND Flash Memory” by Jim Cooke, Micron Technology, Aug 2007
• “Modelling of the threshold voltage distributions of sub-20nm NAND flash memory” by T. Parnell, N. Papandreou, T. Mittelholzer, H. Pozidis, IBM Research — Zurich, Switzerland, March 2015
• Santa Clara University,COEN 180“Floating Gate Basics” by Thomas Schwarz, 2003
• “Nonvolatile Memories: NOR vs. NAND Architectures” by L. Crippa, R. Micheloni, I. Motta and M. Sangalli, Qimonda Design Center & Numonyx, 2008
• New Electronics Digital Magazine “No FLASH in the pan” by Axel Stoermann, Toshiba, Oct. 14, 2014
• Cactus Technologies, “SLC vs MLC and The Impact of Technology Scaling”

Home

I’d like to take a moment to shine some light on an area of our business that is generally unthought of and under appreciated — packaging and shipping. The stuff that happens to get your product from the shelf to your doorstep. If you’ve ever received a package from us, I think you’ll fully agree that great pride and care has been put into the packaging to ensure your product arrives undamaged. The packing department has obviously learned quite a lot over the course of 35+ years of business and developed a fantastic process for creating robust packaging. They’ve thought of everything from perfectly sized, double-walled boxes and foam lining down to extra heavy duty packaging tape. Before moving on, let’s take a moment to really appreciate the time and attention the packing department puts into it. The team truly deserves it and I’m genuinely impressed every time I get a package from them. The Amazon smile packages got nothing on them!                                                            Go Back

Now, I’d like to lighten up a little and suggest that the well protected packaging is almost comical. If you’ve ever received a duct tape wrapped gift, and understand how difficult and funny it can be to open, then you know why I’m suggesting that. When you get the package, the first thing you’ll notice is that all the seams have been taped shut to prevent any debris or water from getting into the packaging while in transit. Again, another moment of appreciation for the team for their attention to small details. You’ll need something sharper and stronger than your hands to get in…    Go Back

A quick trip to the shop later, and we’ve got the tools we need to get into this thing. Remember, safety first! Let’s begin by getting one side free so we can work some other tools into it.

We can finish up the other sides by running one end of sharp scissors down the heavy duty tape covering up the seams.      Go Back

Once you’ve pulled the box’s front tabs out and opened the lid, you’ll notice a perfectly lined inside of bubble wrap. The product is very nicely secured into place and isn’t going to bounce around anywhere.

Here’s another example of a well thought out packing plan: the inclusion of extra jumpers just in case they get bumped off during shipment. A small thing, but when you get them, you can certainly appreciate it. Same with extra standoff screws if your product uses them.    Go Back

Moving on, taking the product out of the box, you’ll notice it’s not only wrapped in one layer of bubble envelopes, but two layers of bubble envelopes! From what I understand, the product would normally be enclosed in an anti-static bag, but since ours is in an enclosure, it didn’t require one. The extra padding is to remove any wiggling room.

Work your way through the first layer and you’ll be met with your second layer. This one has a California Prop 65 compliance warning label on it. It’s not too tough to get through.                                Go Back

One of the last things you’ll notice is the use of some hefty rubber bands holding down some gasket material in order to protect the LCD screen on this particular product (TS-7553-V2 with HMI enclosure). Another good example of paying close attention to detail.

The real final step is to take a step back and appreciate the brand new, scratch free product. It has already been tested for you, so find that power adapter you ordered with it, plug it in, and fire it up!          Go Back

While I put these tools away, I’d like to reflect more seriously on the Technologic Systems’ packing department.

They work like a well oiled machine, quickly churning out high quality packaging for various products and quantities. This unboxing was just a single product, but the same great care and protections are used for orders of 50 or 200 or 1,000 quantity orders. Thanks to these efforts, you can feel confident that your product is going to arrive safely every time you place an order.                                                  Go Back

Technology has become more than just a battle of sheer numbers. It has somewhat morphed into a “less is more” philosophy to see what’s possible with less. We pitted these three ARM CPUs together to find out if there are any positive impacts to using a slower clock speed CPU:

• 800 MHz PXA166 ARM CPU (TS-7250-V2)
• 1066 MHz PXA168 ARM CPU (TS-7250-V2)
• 696 MHz i.MX 6UltraLite ARM CPU (TS-7553-V2)

What we found is very promising in that in most tests, the 696 MHz i.MX 6UltraLite provided a huge advantage over the 800 MHz PXA166 and even the 1066 MHz PXA168. Let’s take a quick look at our findings.

Home

Here, we are using the Sysbench multi-threaded benchmark tool to calculate prime numbers per second. You’ll notice an obvious difference in performance, where the i.MX 6UltraLite comes out ahead at about 24 primes per second. Compare with about 13 primes per second with the PXA168 and 10 primes per second with the PXA166.

Furthermore, we use Sysbench to test RAM transfer speeds (using 1K block sizes). You’ll see from the graph above that the obvious winner here was the i.MX 6UltraLite with about 135 MB/s. The PXA168 was around 55 MB/s, and the PXA166 was about 41 MB/s.    Home

Now, we test read speeds from eMMC flash drive using DD, a utility to convert and copy files. We found that the i.MX 6UltraLite read at about 34 MB/s, while the PXA166 read at about 12 MB/s and the PXA168 at about 11.5 MB/s. Note that the PXA166 outperformed the PXA168 because the PXA166 runs the RAM slightly faster than the PXA168.

Finally, let’s throw some OpenSSL crypto benchmarks at the CPUs. Here, we’ll see that PXA168 performed slightly better than the i.MX 6UltraLite in a couple of cases and visa versa for the other half of the tests. While there is a difference, it’s not significant. Still, for a CPU with a slower clock speed to keep up with or beat out the others is impressive.      Home

Conclusion

These days the hertz count of a processor is not a very good measurement of performance. The important differences are more complex than just the clock rate, but essentially newer architectures are able to do more per clock.

The PXA166/8 is a customized ARM core originally from Intel/XScale called PJ1/Mohawk which follows the ARMv5TE architecture. This is compatible with the standard ARM9 core, but includes further customizations from Marvell.

The i.MX 6UltraLite is a 696MHz Cortex-A7 which follows the more recent ARMv7-A architecture. This architecture is a partially dual-issue architecture while the PXA166/8 is a single issue architecture. This means the PXA166/8 will execute one instruction per clock, but the i.MX 6UltraLite will execute multiple instructions in parallel when possible.

The Cortex-A7 also includes NEON instructions which support SIMD (single instruction, multiple data) operations. For code performing math on large blocks of data this allows one instruction to operate on blocks of data rather than using many instructions to iterate over that same block of data. Users typically have to go out of their way to use NEON code in their application, but some performance sensitive libraries such as fftw will use NEON without the users needing to change their code.

The i.MX 6UltraLite includes a floating point unit while the PXA166/8 does not. The i.MX 6UltraLite will offload floating point operations to its VFPv4-D32 core. The PXA166/8 uses armel/eabi code that will generate software floating code. Any floating point operations will see massive gains going to an i.MX 6UltraLite.

There will be many more nuanced changes between the CPU architectures, but ultimately performance has improved significantly in most cases going to this newer architecture. Suggesting that less really can be more.

• 800 MHz PXA166 ARM CPU (TS-7250-V2)
• 1066 MHz PXA168 ARM CPU (TS-7250-V2)
• 696 MHz i.MX 6UltraLite ARM CPU (TS-7553-V2)  or  Home

Servos are a ubiquitous and versatile part of everyday electronic gadgetry. From unlocking doors to dropping a soda out of the vending machine, nearly anywhere a computer needs motion you will probably find a servo. Servo control is an important trick in any embedded systems software engineer’s repertoire.

The TS-7180 SBC makes a conveniently apt servo controller, however there are some caveats that might surprise the uninitiated.    Home

You can also read this article in Servo Magazine!

Assumptions

This article does make some assumptions:

• You already know how to obtain serial console on the SBC.
• You are already familiar with basic Linux usage and the Linux command line.
• Your TS-7180 is running the standard shipping image as provided by Technologic Systems.

Definitions

There are actually a whole lot of different kinds of “servo”. Many more than the scope of this article can handle. Servo is generally short for “Servomechanism,” defined thus:

A powered mechanism producing motion or forces at a higher level of energy than the input level, e.g., in the brakes and steering of large motor vehicles, especially where feedback is employed to make the control automatic.

As a very general concept, a servo is a motor device that will seek a specified position and then exert force to hold that position against competing forces. For our purposes, from here on when we say “servo” we mean a typical hobby servo like the one in the photos herein. In this article, we’ll explore just two types of “servo”, both of them fall fairly readily into the familiar “hobby servo” category.

Servo Basics

Inside the typical hobby servo housing is a DC motor and gearbox attached to an ASIC or microcontroller (microcontroller in fancier, more expensive servos) that listens to a control line for a 3 to 5 volt pulse every 20 ms (approximately). The length of that pulse tells the control chip where to place the servo’s armature (also known as the “Servo Horn”). This pulse is usually between 1 and 2 ms wide with 1.5 ms being the typical “neutral” or “center” position. This “pulse train” needs to keep coming at the rate of once every >20 ms in order to keep the servo’s control chip actively seeking the requested position. When the signal stops, so does the servo, whether it made its destination or not. Timing may vary slightly from one servo to the next, and may vary significantly from one servo vendor (manufacturer / brand) to the next. Always check with the servo vendor’s data sheet if available and experiment with your exact hardware to tune or trim servo performance before deploying a “live” application. Normally, the servo will expect 20 ms “low” between positional pulses.

180 Degrees of Freedom

The typical hobby servo has a “sweep” of 180 degrees. It’s used in all manner of thing from toy cars to optical lens shutters. They’re usually cheap, and available from just about every hobby shop in the world. This is the kind of servo we will use to explore the true-to-form “servo” functionality of seeking and holding a position. As mentioned above, its typical control signal involves a pulse train where pulses of less than 1.5 ms mean turn proportionally left, and pulses more than 1.5 ms mean turn proportionally right.  Home

Constant Rotation

As mentioned before, there are a lot of different kinds of servo, even among the hobby servos we are exploring here. One of the most interesting types is the constant rotation servo. Interesting because it turns a hobby servo into a cheap but powerful high torque gear motor complete with electronic speed control. Is it even a servo anymore? It is certainly not effective for a production design, but it is a quick way to bang out a proof of concept, and a handy way to re-use old electronic parts you might otherwise end up throwing away.

The modification is done by removing the motor stop from the gearbox and disconnecting the position-measuring potentiometer from the drive shaft, either replacing it with a fixed resistance representing “center” position for the retired potentiometer, or setting the potentiometer’s position to be always centered. This modification is difficult to do by hand, but has become very popular among hobbyists and garage inventors. So popular in fact that some manufacturers offer what we now call “constant rotation” servos which basically have had this modification done in the design of the servo to begin with.

With this kind of modified servo, the pulse train is the same, only the behavior is now different. Now instead of controlling specific position, the servo is tricked into chasing an unobtainable position, so the farther from the center the pulse would indicate a move, the faster the servo will turn!

For either type of servo chosen for your application, the control mechanism at the TS-7180 is the same.

The TS-7180 SBC

This Single Board Computer offers a wide variety of available access options, with serial ports, Ethernet, and various wireless networking options, it is an ideal controller for a remote sense and control network. Direct to our need for this article, the focus will be on two of the four screw terminal banks located at the “front” of the SBC.                                        Home

Connections

In specific, DIO #1 at P3-A pin 1, GND at P3-A pin 12, and OFF-BD-5v at P3-B pin 9.

Using jumper wires for test purposes, loosen and remove the upper screw terminal with a small flat-head screwdriver (not shown). This will allow you to access the lower terminal to install the power wire.

Once these are done, we move on to wiring the servo:
Servo wiring varies between brand and model, but generally wires usually follow the same pattern: GND, power, Signal (control). It’s best to check with the manufacturer if there’s any doubt though. Note: Some servos may need more power than the 5W the TS-7180 can provide. A separate power circuit must be devised under this circumstance. When powering externally remember the TS-7180 and the servo must share a common ground.

Software Setup

With the wiring completed, it’s time to set up some prerequisites. For the curious, you may have already checked the OFF-BD-5V signal and found it isn’t outputting anything! That’s actually OK: That signal is designed for intrinsic safety, which means it starts out OFF. So, there are two main registers we need to set up before our servo will do anything. Run these:

tshwctl -a 309 -w 1  # this will turn on PWM, we'll need that in a minute.
tshwctl -a 0x10 -w 3  # this will turn on power to the off-board 5v line.

These and all other commands are also documented in the TS-7180 product manual. References are all in the Source Material section at the end of this article.                                                        Home

The Command Line Servo

While bit-banging a GPIO pulse train is technically possible, the device has a PWM generator already, so it makes more sense to save CPU time and use the built-in hardware. The TS-7180 uses the Linux PWM driver to operate the servo. This involves telling Linux which PWM chip to use, then setting the standard PWM parameters. There is an interesting “gotcha” though: PWM’s duty cycle is not “high” or “low”, the PWM is implemented on an “assert”/”de-assert” way of thinking. Since this DIO is active-low, it starts high. What this means is the PWM on DIO #1 is LOW on 100% duty cycle! Instead of giving the duty-cycle time in 1-2 ms with a ~20ms gap, the duty cycle must be expressed in terms of 22.5 ms, because the servo will be expecting a high-time of ~1-2 ms (again, with some variation, I suggest giving an extra 0.5 ms gap to ensure any potential jitter stays out of your 20 ms minimum low time). The math to choose your full period therefore is thus:

period = 20 ms + maximum sweep in ms

One servo tested actually had 0.6 ms to 2.4 ms full sweep, so in the case of this project, my full PWM period is 22.5 ms.

Try this to center the servo (pulse width set to about 1.5 ms):

echo 0 > /sys/class/pwm/pwmchip4/export
echo 22500000 > /sys/class/pwm/pwmchip4/pwm0/period
echo 21500000 > /sys/class/pwm/pwmchip4/pwm0/duty_cycle
echo 1 > /sys/class/pwm/pwmchip4/pwm0/enable

That should center the servo. From this point, you can vary the duty cycle between ~20500000 and ~22400000 to find the true center and full effective sweep of the servo. For the C-savvy programmer, each of the above echo targets are file handles, and can be opened in your program for manipulation with a simple write() call.

The Wrap-up

Whether building a balancing robot, keeping a toddler out of daddy’s special stash, or designing the next great braking system for your soap box racer, servos are an essential component in any embedded systems engineer’s toolbox. With a little luck and a bit of exploration, hopefully this article has helped add a servo control trick or two to your embedded systems repertoire.

Home

Source Material

• • General information about hobby servos:
  • TS-7180 GPIO Documentation
  • TS-7180 Terminal Block Definitions
  • TS-7180 PWM Documentation
  • Link  to buy the constant rotation servo in the photo

The basis of this project is to provide a solution to any resource monitoring applications that involve sharing a limited resource for increased productivity or throughput optimizing. The solution involves use of a single board computer to monitor remote sensor nodes, manage a queue for any assets waiting to use the resource, and notifying the assets. This specific example is monitoring and managing a queue for use of company bathrooms and notifying employees when they become available. Employees can subscribe to the bathroom status using SMS text messaging and become alerted when it’s available and their next in the queue. The code, schematics, and documentation in this practical (and entertaining) example will allow for better time management of resources in a variety of serious applications (human resources, assembly lines, industry, etc.).                                                                      Home

The Project

Contention can arise in any setting involving multiple people sharing a limited resource. As our company has grown, one resource that has increasingly become congested is the restrooms. With two restrooms for people numbering in the double digits, it was becoming increasingly common to find both facilities occupied. None of the existing options seemed befitting to a high tech company. Camping outside a restroom waiting for it to become available makes sure you get to use it as soon as it is available, but what if you pick the restroom which is going to be in use for the next half an hour while the other restroom was free right after you left? Walking back and forth in a polling fashion eliminates this problem, but may be less comfortable, and now you risk somebody else enter the restroom if it becomes free shortly after you are on your way to the next. In either case, one’s time would be unproductively wasted walking across the building just to discover they had to wait.

This paper documents a high-tech solution to the problem with the use of a Technologic Systems’ TS-7680 and node.js. The solution was created using node.js for fast development time. Users can send e-mails or SMS messages to the server to check the restroom state, request a reservation to use the facilities, or cancel a reservation. The server will send replies back in the same medium as the request came in, notifying the user of the current state and when their reservation is ready. Each restroom has a TS-7680 connected to the LAN via WiFi which the server polls to determine its state.

The server has four main tasks it must perform: maintain and log the restroom states, respond to commands, maintain the queue, and send notifications.

State

Maintaining the restroom states is done via two simple, inexpensive sensors. A magnetic sensor is attached to the door of the restroom and detects whether the door is open or shut. A photoresistor is used to detect whether or not the light is on. Of note, the restrooms in this model are of the single-user locking variety. For multi-user restrooms the solution presented herein would not work, and would be less likely to be needed in the first place. Not to worry! You can adapt the solution to any resource in your office which has contention and could benefit from a notification and reservation system!

We start with the simplistic model that restroom is considered occupied if door is shut and light is on. By DeMorgan’s theorem, another way to state this is that restroom is considered not occupied if door is open or light is off.

However, there is a potential issue with this model. Sometimes when somebody leaves the restroom, they may leave the light on and shut the door! This makes it difficult to non-invasively determine if the restroom is in use. In our office, there is insufficient contrast between the light being on and off to easily tell by looking at the small gap below the door, and bending over to look can be awkward. Some people are shy about trying the handle because occasionally the person in the restroom will forget to lock the door. Others are shy or oblivious and don’t respond to calls or knocks from outside, perhaps mistaking them from normal hall noise not directed at them.    Home

We don’t want to have to resort to more complicated sensors, so we are going to come up with some additional logic to try to detect this condition. The basic idea is that when someone leaves the restroom and closes the door leaving the light on, there is a short window during which the door is open and the light is on. So we will look for a transition from closed/on to open/on and back to closed/on within a limited amount of time. We can’t distinguish this case from the case where somebody opens the door, walks out, and somebody else immediately walks in, so we will call this state “unknown”. With the implementation of a reservation system we hope to cut down on the need to linger near the door waiting to pounce the moment somebody walks out, so a restroom in the “unknown” state can be flagged as such so that somebody such as the next person in line can go find out whether or not the restroom is really available. This model will also reduce the discomfort some may experience at having to try the door or call out loud asking if it is in use by laying out a clear signaling system in which this is acceptable due to the likelihood that the facility is empty being high.

In addition, we will add a state called “exiting”. This state will be entered as soon as the door opens but the light is still on. This will allow for the possibility of sending a notification that the restroom may be available shortly to give the person waiting a better chance against somebody outside the system who just happens by at nearly the right time.

Finally, we will add a state called “reserved”. We will enter this state when the restroom is unoccupied, but the scheduling system has notified a waiting user that they can now go.

Given this, a high-level over of our state machine looks like this:

At power-up, the state machine is initialized per the above table based on the current door and light inputs.

In the available state, we wait for somebody to either request the restroom, in which case we enter the reserved state, or for somebody to occupy the restroom, in which case we enter the occupied state.

Whenever we enter the reserved state we send a notification to the person at the head of the queue that the facility is now reserved for their use. We also send this notification if we remain in the reserved state and the head of the queue has changed, to the new person at the head of the queue.

When we enter the reserved state we set a timer to prevent anybody from tying up resources by requesting use of the restroom and then never using it. If that timer expires before the restroom is occupied, then we cancel their reservation and give it to the next person in the queue, or if the queue is empty, we go back to the available state. The user can also cancel their request with the same effect. But when we detect that the restroom has become occupied we then enter the occupied state and cancel the reservation timer.

Once in the occupied state, there are three things that can happen to cause the state to change. If we detect the door has opened and the light is off, then we go to the reserved state, unless the queue is empty in which case we go to the available state. However, if the door opens but the light goes on, then we start the exit timer and go to the exit state.

Once in the exiting state we wait for the light to go off or the exit timer to expire. If either of these happen then we transition to the reserved state unless the queue is empty, in which case we go to the available state. However, if instead the door closes and the light is still on, we enter the Unknown state, because we don’t know for sure if the leaving user shut the door or if another person walked in.                                              Home

In the unknown state, we can either transition back to the exiting state (starting the timer again) if the door opens with the light on, or if the light goes off we go either to the reserved state (if anybody is waiting) or the available state (if nobody is waiting).

For determining the optimal timeouts for the reservation and exit timers, the server can log all state changes with a timestamp for manual examination.

A graphical representation of the state machine is shown below. In this diagram:

Q is true if the queue is non-empty, i.e. somebody is waiting for this restroom
L is true if the light is on
D is true if the door is closed
R is momentarily high when the reservation timer expires (R+ arms, R- cancels)
X is momentarily high when the exit timer expires (X+ arms, X- cancels)

Architecture

The server is designed to separate the concerns of getting inputs, maintaining room state, and responding to commands.

Room

This object encapsulates the state of the room. It has a control loop that polls the inputs for the room (door state, light state, and reservation queue empty state), updates the state according to the state machine as documented below, and notifies all state listeners of state changes. There are also exit and reservation timers which are started leaving the Occupied and Reserved states, respectively, which can affect state if they expired under certain conditions.

The control loop pseudo-code looks like this:

Record current time as t0
Samples all inputs
Update state machine
If state changed, notify all listeners of change
Record current time as t1
Sleep for a bit, using t1-t0 to determine how long

Our room object is instantiated with two parameters: the name of the room, and a function that is called to get the inputs for that room:

var room = new Room("engr",get_engr_inputs)

After instantiation, default timing parameters can be modified if necessary:

room.poll_delay_ms = 1000 // default
room.exit_timeout = 15000 // default
room.reservation_timeout = 180000 // default

The poll_delay_ms variable holds how often (in milliseconds) the room object should call the function to get the inputs for the room. If this value is too high then it is more likely to miss input changes and fail to transition between states properly. If it is too low then there may be excessive resource usage.

The exit_timeout variable holds the number of milliseconds to wait after the door is opened and the lights remain on before assuming nobody is in the room. A good value to use can be determined empirically by observation. If this value is too low it increases the chance of mistakenly thinking the room is in use if the door subsequently shut by the person exiting. If it is too high, it decreases the responsiveness of notifications and increases the likelihood of somebody else entering the room and causing the unknown state to be entered.

The reservation_timeout variable holds the number of milliseconds to wait for a user to claim their reservation before cancelling it and giving the next person in line a chance. If we set this too low, users are going to have to rush or may not be able to make it to the room in time. If we set it too high, other users will be forced to wait longer if the current user does not respond promptly to their notification                                                  Home

Listeners can be added to the room by adding a function to process change notifications. This function takes three parameters: the name of the room, the new state, and the old state. The Room.State object can be used to convert the state into a readable string as shown in the following example. This adds a listener which will print state changes to the console:

function listener1(name,new_state,old_state) {
      console.log(new Date()+name
                  +":STATE CHANGE:"
                  +Room.State[old_state]
                  +"->"
                  +Room.State[new_state])
}
room.listeners.push(listener1)

Once the room is configured, call the start function to begin running the control loop:

room.start()

Input7680

The Room object requires an input function to get the current state of all the inputs in order to run the control loop. This function must take a callback function which must return the input values in an object containing the following keys:

• door: current state of the door, either “OPEN” or “CLOSED”
• light: current state of the light, either “ON” or “OFF”

This Input interface encapsulates the door and light state inputs for a room. It provides a function to get the current state of these inputs and notifies all state listeners when any input(s) change.

The Input7680 object implements the Input function above using HTTP requests to the ADC API of the ts7680-demo-server app. It also allows the input to be configured according to the lightning conditions in the room. It is instantiated by passing the name of the input, the hostname of the TS-7680 running the ts7680-demo-server, and a light threshold. In our installation we have two restrooms, “engineering” and “production”, and the instantiations for these look like this:

var engr_input = new Input7680("engr","engr.local.net",25000)
var prod_input = new Input7680("prod","prod.ts-local.net",4000)

The light threshold can be determined empirically by running the web interface on the server and monitoring the value of the ADC input for the photo-diode. While it is running, adjust the light conditions between light off and door open, light off and door closed, and light on from various locations in the room. With our circuit design, a more light equates to a high ADC value, so choose a threshold value that has all light-off conditions less than the threshold value, and all light-on conditions above it. If necessary, adjust the position of the photo-diode. Light from outside the room should not be sufficient to trigger a false “light on” condition when the light is off.

In the above example, the engineering restroom has a higher threshold value. This is due to the fact that the only suitable location for the photo-diode is prone to shadowing due to the position of the lighting and pattern of human movement in the room.

InputTest

For testing purposes, or trying out the code without having to set the hardware up, the InputTest adheres to the Input interface. However, instead of interacting with the real world, it provides functions that can be called to simulate input changes:

ob = new InputTest("room1")
ob.enter() // this sets the room in use, so another user can't enter
ob.exit() // this marks the room as not in use, so another user can enter
ob.open_door() // this marks the door as open. It will fail if the room is in use, and returns a boolean indicating whether or not it succeeded
ob.close_door() // this marks the door as closed
ob.turn_on_light() // this marks the light as on
ob.turn_off_light() // this marks the light as off. It will fail if the room is in use, and returns a boolean indicating whether or not it succeeded

Room State Machine

The state machine was developed by examining all combinations of input changes for each state as shown below:

States and Transitions:

The states in the state machine are shown below. The first three states are straightforward to derive the logic for, but the final two states are more complex. The waveforms below show the possible transitions and how they are handled. The character representing the state is shown at the top, the inputs are shown at the left side, and “ET” stands for “exit timer expires”.

Available (A)
Reserved (R)
Occupied (O)
Exiting (E)

Door opens, then closes before exit timer expires

Door opens, then light goes off before exit timer expires

Door opens, and timer expires without further change

Door opens, then lights is off at the same time door is closed

Unknown (I)

Light goes off. This could be because someone is in the room to turn off the light, the lights failed, or the light sensor failed.

Door opens. Someone could be entering or leaving. If they are entering, the door will likely close again very soon while the lights stay on. If they are leaving, the same could happen, but it is less likely.

Door opens and lights go off at once

Nothing changes

Responding to Queries

The server will accept emails or SMS text messages containing commands.

SMS messages are sent and received using the SMS to e-mail gateway offered by most cell phone providers. The user will send an SMS to the e-mail address the server uses. (We created a GMail account for our installation). The server then waits for e-mail messages, processes them, and then sends replies back to the originating address. This ensures that text messages will be forwarded back across the e-mail to SMS gateway of the corresponding carrier and finally to the user’s phone as a text message.                  Home

By providing SMS capability, we offer a more rapid method for sending and receiving responses. Once an entry is created for the server’s address it is only necessary to select that user and enter the message, rather than composing an entire e-mail. However, by also providing support for requests by e-mail, those users who do not have SMS capabilities can still take part in the system. However e-mail only access may have some inconveniences; for instance, if a user only has e-mail on their desktop computer, they won’t see any notifications received while they are away from the keyboard.

To make it simple, we use short commands that the user is likely to remember:

• “go” – This simple request indicates that the user would like to go to the restroom, and wants to know if one is available for them. If a restroom is available, it is immediately reserved for them and a reply is sent informing them that they can immediately proceed to the specified restroom. If a restroom is not available, the server adds the to user to the queue and replies with their position in line. As soon as they reach the head of the line and a restroom becomes available, they are notified.
• “cancel” – This request indicates that the user no longer needs to go. This command removes the user from the queue and notifies them of the result.
• “q” – This request is a command to query the current state of the queue and each restroom (occupied or not).
• “help” – In case the user forgets what they can do, any command containing the text “help” will result in a reply containing the valid commands and a short description of each.

The logic for each command is fairly simple. When we get the “go” request, we first check if the user is already in the queue, and if not add them to the end. This is done by aggregating an individual queue for each room. If the user is in any room queue they are in queue for use of a restroom. When users are added to the queue they are added to the queue for each room. The user’s position in the overall queue is the based on which queue they are closest to the front of. We notify the user of their position once they are added to the queue.

When we get the “cancel” request we remove the user from every queue that they are in.

When a restroom becomes occupied the user presumed to be using it is removed from the queue. A future enhancement could provide a mechanism to address the situation where the head of the queue is not occupying a restroom.

Another enhancement could be to allow users to set a restroom they prefer to use. We would need to store each user’s preference and use this info to select which restroom to assign them when more than one is available at once.

Sending notifications

The queue consists of a separate queue for each room. This is because the room will leave the reserved state as soon as the queue is empty. When we add a user to “the queue” we will actually add them to the individual queues of each room.

We listen for notifications from each room to determine what to do. We maintain a reservation object that maps users to the room that has been reserved for them. When the room state transitions to the reserved state, we check if the user at the head of the line for that room already has a reservation for a different room, and if so they are removed from the queue. Otherwise, we add them to the reservation list and notify them that their reservation is ready. When we receive a notification that a room has left the reservation state, we remove the user at the head of the line and cancel their reservation.

When suitable state transitions occur such that a request in the queue can be satisfied, the restroom is marked as reserved, and a notification is sent.
Notifications are sent back to the same message source that sent the original request for service.                                        Home

The Command Module

The functionality of responding to queries and sending notifications is performed in the command module contained in command.js. The file has the following functions, grouped by purpose:

Queue Management

Each Room object maintains its own queue of users waiting for that room as a javascript array, where element 0 is the head of the line. The functions below all aggregate the individual queues for each room in a single virtual queue.

QueuePosition returns the position of the user in line (0 = first in line) by finding the individual queue that the user is closest to the front in.

QueuePush adds the user to the end of the queue for each room.

QueueRemove removes the user from the queue of every room they are a part of.

QueueRemoveOther is like QueueRemove, except it provides the ability to keep the user in the specified room queue.

QueueLength returns the total number of unique users waiting across all queues.

Notification

state_changed is a function that listens to all changes for the Room objects. It uses this to manage reservations. When the room state becomes Reserved, or is already Reserved but the head of the queue has changed, it sends a notification to the new reservee that the room is ready for them. When it exits the Reserved state, it cancels the reservation for that room.

mail_reply_ob is an object which defines a send function which takes the reply object generated by the command processor as described below turning it into a string suitable for sending as an SMS or text message.

Command and Control

process_command is the function which interprets command requests. It takes three arguments: a string containing the command, a string containing who sent the request, and a reply object. The reply object must define a function send which takes the string identifying who to send the reply to and an object defining the reply. The format of this object consists of a pair of keys each of which identify a type of reply that can be sent and the value of that reply. Not every key is present in each reply. These keys and their possible values are listed below:

position: An integer representing the user’s current position in the queue, zero indexed, or -1 if the user is not in the queue.
change: A boolean which is true if the value of the position field has changed as a result of the command being replied to.

qlen: An integer indicating how many people are currently waiting in the queue.

ready: A string containing the name of the restroom that is now reserved for the user.

timeout: How long the reservation is good for, in milliseconds.

The purpose of sending the reply as an object instead of text is to separate the concern of formatting the reply to the user from the actual reply. This is used in the simulated user code to allow the reply to be processed by javascript code rather than needing to parse text. It could also be used for localization or customization of the reply message, or other automated processing.

start is the function that is called to begin listening to and processing commands. It takes three parameters. The first is a listen function which is called to wait for messages to be processed and which takes a callback which is called every time a message arrives. The second is a “get info” function which is used to translate the received message into separate “from” and “command” fields. Finally there is a reply object, which is passed to the command object to send replies. This function is very simple, calling the listen function to begin listening, and in the callback passing the information received to the “get info” function. The sender’s name or address is associated with the interface to allow multiple message sources to be replied to without knowing ahead of time who will be communication on which source. It then calls the process_command function to process the request and send the reply.

init is a general initialization function which must be called before anything else is done. It takes an array of rooms and a logger function, sets up some variables, and registers the state_changed function as a listener to all rooms. The logger function is used by the Log and LogQ functions which log state and queue changes for debugging, testing, and informational purposes.

Emails

The mail.js module is a wrapper around the e-mail sub-system which allows for commands and replies to be received and sent over both e-mail and SMS via the carrier’s SMS gateway. It uses two node modules found in the standard npm repository: mail-notifier, which listeners for new messages, and nodemailer, which allows us to send e-mail. The mail.js module looks for a simple config file in the user’s home directory (~/.ts-server-mail) for both the username and password of the e-mail account for the server to use. The format of this file must be a JSON encoded object with information about the account Further details on the nature of this object documented in mail.js.

Testing and Debugging

For testing the state machine quickly without needing to manually open and close doors and turn lights on and off there is the SimUser.js module. It defines the SimUser object, which is initialized with a test name, an Input object, and a logger function. This object has several configurable switches which are named in a self-explanatory manner in the constructor function (SimUser). These do things such a defining the minimum and maximum amount of times the simulated user will take to move between its states, as well as attributes such as “doesn’t turn off the light when done”.          Home

The simulated user moves through the following states to exercise the Room logic:

1. wait a random amount of time
2. send a request to use a room
3. wait for a message to be received that the room is available
4. delay a certain amount of time to “walk” to the simulated room.
5. try to open the door, returning to step 2 if it fails
6. set the presence flag in the room so another simulated user cannot enter
7. wait a random amount of time
8. turn on the light
9. wait a short amount of time
10. close the door
11. wait a bit to simulate using the room
12. open the door
13. clear the presence flag so another user can enter
14. if the user is configured to turn off the light when done, the light is turned off after another short delay.
15. if the user is configured to close the door when done, shut the door after another delay.
16. Go to step 1

The state machine can be tested by instantiating several user profiles with differing configurations. This can help reveal any situations where the state machine does not function properly; for example, if there are users waiting but no notifications being sent. The logger function StateChange in StateLogger.js stores state and queue changes. This module also sets up a signal handler when it is loaded. When CTRL+C is pressed all of the queue changes are dumped to a CSV file which can then be loaded into a spreadsheet for further examination.

Initialization

The main.js file contains startup code which initializes the program state and starts the command loop running. It has a debugging flag to indicate whether or not we are in debug mode or normal mode. Debug mode is entered by passing the string “test” as an argument on the command line. Running node main.js test will start in debug mode, while node main.js will start in normal mode. In debug mode, simulated inputs are started for each simulated room by instantiating InputTest for each room. While in normal mode Input7680 is instantiated for each real restroom, passing the name of the room, the hostname, and the light threshold. Whether in debug or normal mode, we instantiate a Room for each restroom, passing the inputs instantiated above. We also create and register listener functions. These functions listen for changes to the inputs and the room states in order to log them. We then initialize the command module. If we are in debug mode, we instantiate simulated users and start a command processor attached to each. Normal mode will start the command processor, attaching it to the mail listener. Finally, we then call the start function of each room to begin the monitoring process.

Software Installation

First, make sure that nodejs and npm are installed. Then run the following commands to install the TS-7680 demo server and set it up to be run automatically. We will use the pm2 utility, which is a program monitor which will automatically restart our server if it stops for any reason, and will start it automatically whenever the machine boots.

cd node 
npm install ts7680-demo-server
pm2 start node_modules/ts7680-demo-server/server.js
pm2 startup
pm2 save

The server can be run on any machine on the same network which is running node version 6 or greater. The server can be installed using:

npm install ts-room-server
pm2 start node_modules/ts-room-server
pm2 startup
pm2 save

Once you have installed the ts-room-server module, you will need to create a .ts-room-server-config file in $HOME to define your mail services. This file is expected to define the transport service, IMAP parameters, and room definition. It must be in JSON format as an object containing three keys: “transport”, “imap”, and “rooms”, respectively.

For using a GMail account you can use the following template below. Note that GMail requires that you “Let less secure apps use your account” before you run ts-room-server for the first time. For other e-mail services please consult the documentation on nodemailer (for sending) and mail-notifier (for receiving mail). The “transport” value is passed directly to the nodemailer.createTransport() function while the “imap” value is passed directly to notifier.                          Home

template ~/.ts-room-server-config:

{
    "transport": {
        "service": "Gmail",
        "auth": {
            "user":"<your email address excluding @gmail.com>",
            "pass":"<your password>"
        }
    },
    "imap": {
        "user": "<your email address excluding @gmail.com>",
        "password": "<your password>",
        "host": "imap.gmail.com",
        "port": 993,
        "tls": true,
        "tlsOptions": { "rejectUnauthorized": false }
    },
    "rooms": [
        { 
           "name":"<your device nick name users will see>",
           "Host":"<your host name>",
           "threshold":16000 
        }, { 
           "name":"<your device nick name users will see>",
           "Host":"<your host name>",
           "threshold":16000 
        }
    ]
}

The above template assumes two restrooms, you may add or remove as necessary. When using this template, be sure to tweak the light threshold values for your environment.

Hardware Installation

We installed a TS-7680 in each of the two restrooms in the Technologic Systems’ office. These rooms are named “engr” (engineering) and “prod” (production).

We built up a small perforated PC board to connect the switch and light sensor to the J1 header (on the PC board itself) and HD4 header (on the TS-7680), per the schematic below:

The PC board mounts to the HD4 header and connects to it electrically via the SWITCH and PHOTO signals. Note the 0 ohm resistors, these are provided in case the electrical characteristics of the door sensor or photoresistor require a different bias.

Each TS-7680 was installed under the sink in each restroom. The picture below shows the finished installed product including the custom PC board:

The wires to the magnetic door sensor and photoresistor are tucked out of the way under the sink. Power is provided by a nearby outlet:

The door sensor and conduit was painted to blend in with the surroundings:

The wiring for the light sensor runs across the back wall:

The position of this sensor was chosen to maximize the amount of light that falls on the sensor in all conditions. This means placing it where it can see the light source and is unlikely to fall into a shadow based on traffic patterns in the room. For instance, we would not want to place it at the front of the sink as anybody standing in front of the sink would greatly reduce the amount of light hitting the photoresistor. We also want to place it in the shadow of any light coming from outside the room. In the picture above, the restroom door is behind and to the left, preventing the sensor from being able to see any direct light from the room. This allows us to set a threshold that detects room light but rejects light coming from outside the room.

As can be seen in the image below, the light sensor sticks out just far enough to see the light source, in this case the fluorescent lights in the center of the ceiling above:                                              Home

See it in Action

[gfycat data_id="PeacefulMediocreCrocodile"]

Conclusion

If your office has a constrained resource, such as restrooms, which are frequently occupied you can benefit straight-away from this project. If you come up with a particularly clever idea or want to implement additional functionality you are invited to submit a pull request or fork your own project from the code. Some further enhancements could be to allow users to specify their preferred restroom, add support for additional sensors, or create more complex logic to more accurately detect the restroom states.

We have covered the application of handling contention for a limited shared resource such as a restroom. You can also adapt this demonstration to practically any situation in which it would be useful to be able to control or manage your embedded devices via e-mail or SMS. A device in the field, such as an oil rig or a weather station, could be instructed to send an SMS when any number of things occur. This might include errors or dangerous conditions detected, maintenance or servicing needed, or simply responding to queries asking about current conditions. Using node.js you will be able to develop your solutions on our product quickly and easily. The limit is really only your imagination. Oh, and those pesky laws of physics.        Home

Ferroelectric Random Access Memory (F-RAM) is a non-volatile storage technology that offers low power, fast write performance, and a greater write endurance when compared to EEPROM or flash technologies. For example, the write endurance of F-RAM from Cypress Semiconductor is 10^14 (100 trillion) write cycles. Presuming the device takes 4 ms to rewrite every cell, it would take a minimum of 126 years for a failure to occur. However, EEPROM and NOR Flash have write endurance of just 10^6 (1 million) write cycles. Additionally, F-RAM data retention is very robust, supporting a minimum of 10 years, and more than 121 years of data retention at + 85 °Cdeg;C, depending on the individual product.

The high-speed nature of the device combined with its non-volatility and data retention makes this memory device useful in many applications. The F-RAM used in Technologic Systems’ products is an AT25 compatible SPI device. The TS-7553-V2 board support package implements the F-RAM as an extra EEPROM-like memory and presents the whole device as a flat file.

Use Cases for F-RAM

Attached as a simple memory device, F-RAM can be used to store any data an application may need to retain in either traditional RAM or non-volatile memory. Having a secondary memory device can be useful for applications such as per-unit configuration/calibration data, non-secure storage of unique serial numbers or IDs, and boot flags. Applications that can take advantage of the high write endurance of F-RAM memory include temporary storage that needs to remain non-volatile, counters that require frequent writes, or data logging applications that need to store local data logs that will be read or transmitted later.

F-RAM has also proven to be highly tolerant to radiation effects that may be experienced in airborne and space applications. Typical memories retain state using various techniques that are susceptible to corruption from alpha particles, cosmic rays, heavy ions, and gamma- and x-rays. For instance, Dynamic Random Access Memory (DRAM) stores charge in a capacitor. Static Random Access Memory (SRAM) sets a latch. And EEPROM typically stores charge in an insulated floating gate. Each of these can experience a bit-flip, or soft error, as a result of a radiation event. Because the F-RAM cell stores the state as a lead zirconate titanate (PZT) polarization, an alpha particle or heavy ion hit is very unlikely to cause the polarization to change a given cell’s state, resulting in a robust tolerance to these events.

As the number of high altitude and low earth orbit projects continues to grow, especially for small-sat/cube-sat style projects, single board computers will rely on serial I/O boot code and data logging memories. F-RAM is the robust choice for these harsh environments.

Construction and Operation

The ferroelectric in F-RAM refers to a type of crystal material that is made of tiny electric dipoles where the positive and negative charges have a slight separation. This electric polarization is a natural spontaneous state of particular types of crystals and can be controlled via the application of an external electric field. The ferroelectric property is a phenomenon observed in a class of materials such as the PZT used in Cypress’ F-RAM (Figure 2).

Applying an electric field across the crystal causes the position to be aligned in the direction of the field and, conversely, when the electric field is reversed the crystal will be aligned in the opposite position. The polarization will remain in its last state until an electric field is applied, allowing reliable, non-volatile memory to be constructed from these crystals.

F-RAM Operation

FRAM is constructed of ferroelectric crystals used as a capacitor dielectric in a structure similar to DRAM. Where flash or EEPROM technologies rely on a charge being trapped on a floating gate, DRAM captures its charge in a capacitor. The capacitor in the FRAM cell uses a ferroelectric material, typically lead zirconate titanate, as the dielectric. By using a ferroelectric polarized dielectric, the cell is able to maintain its current state without the constant charge current required by DRAM, and the state is able to persist even without power.                                                            Home

The ferroelectric capacitor symbol (Figure 3) indicates that the capacitance is variable and is not a traditional linear capacitor. If a ferroelectric capacitor is not switched when an electric field is applied (no change in polarization state), it behaves like a linear capacitor. If it is switched, there is an additional charge induced, therefore, the capacitance must increase. The ferroelectric capacitor is combined with an access transistor, a bit line, and a plate line to form the memory cell as shown in Figure 3.

The operation of an F-RAM cell is also similar to DRAM. Writing is accomplished by applying a field across the ferroelectric layer in the capacitor by charging the plates on either side of it. The direction of the charge orients the dipoles in the ferroelectric layer one way or the other. This is how logical “0” and “1” are represented.

A read operation is destructive to both DRAM and F-RAM. This means that after a read a rewrite must occur for the data to remain in the cell. In a DRAM read, the cell is drained to a sense amplifier. Next, it is determined if the cell contained a charge or not.

F-RAM is read by setting the cell to a known logical state, for example a “0.” If the cell is already in this state, then the output from the cell shows no change, and it is known that the cell was in a “0” state. However, if the cell is in the opposite state, the output from the cell is a brief current pulse as electrons are pushed out during the ferroelectric polarity switch. The internal controller will then reset the cell to the correct value to be stored back, and the read data is transferred out of the IC.

F-RAM Benefits Over Other Non-Volatile Memory

Traditional writable non-volatile memories that use floating gate technology such as EEPROM or Flash use charge pumps to develop high voltages on-chip (10 V or more) thus forcing carriers through the gate oxide. With charge pumps there are long write delays and high power consumption for write or erase operations. Additionally, the write operation is destructive to the memory cell, which limits the operating life. F-RAM’s crystalline structure does not have this sort of wear out mechanism from forcing carriers through oxides, ensuring a longer operating life. Also, the switching speed of the F-RAM’s crystalline structure supports an “instant write,” guaranteeing that when data is presented to the device the data is stored without any internal chip delay. This eliminates “data at risk” in case of a sudden power loss. The mechanism used to apply an electric field to the F-RAM structure also requires significantly less power than the power used by the charge pumps in floating gate technologies.

By Kris Bahnsen and Eliza Schaub, Technologic Systems        Home

Originally published on eecatalog.com:
http://eecatalog.com/storage/2018/08/29/write-endurance-to-write-home-about/

I say, if your knees aren’t green by the end of the day, you ought to seriously re-examine your life. ~Bill Watterson, Calvin & Hobbes

Green-thumbed techno junkies rejoice! For today, we’re going to take an introductory, prototype look at what it takes to digitally monitor the soil moisture content of a common houseplant so we know when to water it. We’re talking about using a single board computer to read from a soil moisture sensor from an Analog to Digital Convertor (ADC) and toggle an indicator LED using Digital Input and Output (DIO). Specifically, we’re going to be using a TS-7250-V2, but this guide can apply to many different boards.

Admittedly, the TS-7250-V2 is a bit overkill for the scope of this simple project, where a simple microcontroller would work, but it does provide us with a solid foundation for full-fledged autonomous garden projects. The TS-7250-V2 has five ADC channels, so you could hook it up to five different watering zones. It also has plenty of DIO pins for controlling and interfacing with external hardware, like turning on or off water pipes for example. Where things get really interesting is having the ability to run a web or API server from the Linux-powered board for access from anywhere in the world. So, there’s definitely room to grow here (pun intended). With that, let’s dig in.

Things We’ll Need

Here’s a list of the items we’ll be prototyping with today:

• TS-7250-V2 Single Board Computer
• SparkFun’s Soil Moisture Sensor
• 1x Red LED
• 1x Yellow LED
• 2x 330 Ω Resistors
• Breadboard
• Misc. Hookup Wires

Setting Up The Hardware

Where the rubber meets the road, or rather, where the sun meets the photosynthesizer. We’re going to hook up our components to the single board computer. For the soil moisture sensor, we need power, ground, and an ADC channel for the signal wire.

In order to prevent oxidation of the probes, we’re not going to apply constant power. Instead, we’re going to hook it up to a 3.3 VDC DIO pin so we can turn it on only when we’re ready to read what’s on the signal wire. We’ll call this our power enable pin. In order to visually see when power to the moisture sensor is active, we’re going to hook up a yellow LED to the DIO pin as well. Finally, we’re going to need some sort of indicator to let us know when the plant needs watering, so we’re going to hook up a red LED to another DIO pin. What we’re left with is something resembling the wiring diagram below.

Notice, we’re connected to the DIO and A/D headers. The red LED is connected to DIO_03, or GPIO #77 in software. The power enable wire is connected to DIO_01, or GPIO #76 in software, which powers our moisture sensor and yellow LED. A ground pin for all of our components is conveniently located on DIO_01. After connecting everything, we can continue to software development, but before we do, let’s talk about protecting our sensor.

As we all know, electricity and water don’t get along, so before we go sticking our sensor into a moist environment, we should protect it. For indoor applications, simply using hot glue can provide good protection. For outdoor applications, hot glue won’t hold up to the sunshine and other elements very well, soconformal coatingwould be much better. Here, we’re working with an indoor houseplant, so hot glue was used, as seen in the image below.

Okay, let’s move onto the exciting software stuff!

Programming The Software

Tighten up your thinking cap; we’re going to unearth some C code. Now, this could very well be done in Python or another language, but we had someexample C codealready provided by Technologic Systems. Also, those coming from a microcontroller world might be more comfortable in implementing their hardware in C/C++, so we’ve shaped the ground to match that sort of landscape.

Start by taking a look at the code at theembeddedts/soil-watcher git repository. There are several files here including the example C code pulled directly from Technologic Systems calledevgpio.candevgpio.h. The evgpio library takes care of all the dirty details of dealing with the somewhat unique event driven GPIO of the TS-7250-V2. This is about the only thing specific to this example project. For other boards, you’ll need to utilize your own GPIO library. If your board happens to use the popularGPIO sysfs interface, you’re in luck because we have example code availablehere in Candhere in C++. Otherwise, refer to your board manual. With that said, let’s take a look at the main event —soil-watcher.c.

Essentially, what we’re looking at is a program that has a few functions, but primarily main(), setup() and run(). The setup() function sets everything up initially, preparing our system by turning off LEDs and initializing the GPIO pins. The run() function contains an infinite while loop that will continually monitor soil moisture readings and control the sensor power and red LED. The main() function simply parses command line parameters and calls setup() and run(). The other functions are mainly just helper functions. The code was heavily commented to make it easy to digest and understand so that we don’t have to dig into too many overwhelming details in this writeup.

Here’s what our program outputs as I leave it sit on my desk and then touch the two prongs together with my fingers:

Setting things up...
 >> Initialize the evgpio core
 >> Setting PWR and LED to output (76 and 77)
 >> Setting pins to low initially
Running application...

Ack! There was either a problem reading sensor data or things are bone dry (ADC Value: 8 mV)!  Flashing the LED.

Moisture content is OKAY (ADC Value: 1965 mV)!  Turning the LED off.
Moisture content is OKAY (ADC Value: 1977 mV)!  Turning the LED off.

Ack! There was either a problem reading sensor data or things are bone dry (ADC Value: 7 mV)!  Flashing the LED.

Moisture content is OKAY (ADC Value: 2186 mV)!  Turning the LED off.

Ack! There was either a problem reading sensor data or things are bone dry (ADC Value: 7 mV)!  Flashing the LED.

One of the finer points of our soil-watcher.c program is the (totally optional) ability to run as a daemon. This allows us to run the program in the background so-to-speak, although what’s actually happening is a little more complex. What we care about is that it frees up our shell as our program goes about its own way. We can see it running by using ps ax | grep soil-watcher.

This also redirects all output that the program would normally generate to /dev/null. So, no logging will be available using this method.

The next thing we’ll want to do with our program is make it start automatically when the system powers on. There are a few different ways of doing this, but the most popular is to add a init.d or systemd (example) script. For our TS-7250-V2, we’ll use init.d, as documented in the “Starting Automatically” section of the TS-7250-V2 manual. The file has already been created for you as soil-watcher.sh. To get it working on startup, follow these commands:

cp soil-watcher.sh /etc/init.d/soil-watcher

chmod +x /etc/init.d/soil-watcher

update-rc.d soil-watcher defaults

/etc/init.d/soil-watcher start

Then, when you reboot your system, our soil-watcher program should be running.

Closing Remarks

Now, the prototyping phase is over. If you’re satisfied with this mini-application, then you could start figuring out how to enclose the system and make it look like a finished product.

I would start by creating a false bottom in the planter in which to house the board and wiring. Then, I’d run some sort of flexible, thin conduit in which to run the wires for the LED and moisture sensor. A hole would be drilled in the planter and the red LED mounted in that hole, so it’s visible from the outside of the plant. Then, whenever I was walking by and seen the red LED, I would know it’s time to water the plant.

Really, this is just the tip of the iceberg. The principles taught in this tiny project of using DIO and ADC pins are applicable to many situations and projects. As mentioned earlier, using the TS-7250-V2 single board computer is massively overkill for this tiny project, but you now have a powerful and sturdy foundation on which to build so much more, which I hope you’ve felt inspired to do so.

If I were to take this further, I would want to build an automated garden with five different watering zones, hooked up to relays and solenoids to control water flow. I’d incorporate an online dashboard into the project by utilizing the Apache webserver and MySQL database to track and display historical data. With Node.js easily installable, I’d bring some IoT flare to the table by creating a REST API which I could use to monitor my soil in real time and open water valves with the push of a button on my phone.

Sources:

https://github.com/embeddedts/soil-watcher

https://wiki.embeddedTS.com/wiki/TS-7250-V2

https://files.embeddedTS.com/ts-arm-sbc/ts-7250-v2-linux/sources/