5.1.1 Concept Feasibility Test
The preliminary feasibility test was performed during the first stage of the project to verify the concept and the performance of the components used. The main concerns were about the capacity of the electronics to wake up in time on an incoming vehicle, the magnitude of accelerometer response to an overpassing vehicle, and the ability to transmit data from a close proximity of a conductive and ground plain.
The measurement chain was assembled from the evaluation boards shown in Fig.5.1a.
The wireless sensor consisted of the accelerometer EVAL-ADXL313-Z-ND, the evaluation board DK-EVAL-04A equipped with an inbuilt battery, and the RF module TR-72DAT.
Data were transmitted wirelessly to the second RF module of the same type, which was connected to the CK-USB-04A programmer and by USB cable to the computer.
The accelerometer sampling rate was set to 400 Hz and the magnitude of acceleration to ±2 g with a sensitivity of 1 mg. The EVAL-ADXL313-Z-ND was equipped with four magnets with a thrust force of 7 kg each, which were placed on the rail-web with a total aggregated force of 28 kg, as shown in Fig. 5.1b. Measuring was triggered automatically by vibration propagated ahead of the incoming train once the level of acceleration rose above the specified threshold. Data were automatically transmitted over the structure into the C# application running on a computer which displayed them on a chart.
A light passenger train passing once in each direction was measured at a spot about hundred meters from the railway station. The incoming train was decelerating as it approached the station and passed over the sensor, as shown at the top of Fig. 5.1c.
After stopping in the station, the train accelerated and passed over the sensor again on the way back, as shown at the bottom of the same figure. The measurement of the second pass was triggered manually as soon as the train moved from the station, so without the
5.1. Preliminary and Laboratory Measurements
function of sensing the oncoming train. It took the train about 7 seconds to reach the sensor and its velocity as it travelled over the sensor in each direction was about 10 kmh-1. The level of acceleration exceeded the dynamic range of the sensor which resulted in the signal being saturated visible on both characteristics of the train passings. However, if the sensor had had a maximum magnitude of ±4 g, the signal would either be in range or would end up saturated just at the highest deflection peaks when the train’s axles were above the sensor. It is expected that the transmission of vibration through the magnets was higher than it will be when the sensor is enclosed in the plastic casing that will protect the electronics from the hostile outdoor environment, as it will also introduce some damping. The accelerometer was positioned on a rail-web between the sleepers where the rail deflection is highest. The wireless sensor can be placed on the rail-web above the sleeper or, in the worst-case scenario, on the sleeper between the two rails. This should bring the values closer to those reported by Chraim [9]. If none of the above would contribute to getting into the measuring range, the inertial sensor would have to be replaced with another one from the list shown in Table3.1.
This measurement produced limited results and showed that it may be possible to measure using a±4 g sensor. The wireless sensor can be woken in time by the vibrations from incoming trains cruising at low velocities, and the data can be transmitted from the sensor’s position close to the rails for short distances of at least few metres. However, due to the significant uncertainty of the measurements performed, further steps should be cautiously taken and more tests should be done. This should involve the range test to verify the communication performance of gateway and wireless sensors placed on rails at various locations and different environments to find the transmission limits. Next, a multi-day test should be arranged to measure a wide range of vehicles passing wireless sensors at multiple locations, as both of these tests would clarify the system limits.
(a) Communication schema
(b) Installation of the sensor (c) Incoming (top), outgoing (bottom) Figure 5.1: Feasibility test on a rails in Trondheim
5. Evaluation
5.1.2 Bottleneck on IQRF Cloud
Affected devices—IQRF {GW-ETH-02A, GW-GSM-02A, GW-WIFI-01}
The original idea of using a combination of an IQRF gateway and an IQRF Cloud outlined in Section 3.2 appeared infeasible with regard to the originally-anticipated parameters.
During development a communication bottleneck between the gateway and the cloud was discovered that was significantly impairing the flow of the data. As a result there was insufficient capacity to transmit the expected data volume in the given time (Fig. 5.2).
The IQRF TR-7x series, the successor to the TR-5x series, was announced at the end of 2012 and released in mid-2014 as part of the Early Adopter Program. The official release date was about a year later as we started to work on the DESTination RAIL project. Since the TR-7x modules offer far better parameters than their predecessor, we decided to use them. This came with certain limitations because some of their components had not been released yet. The programming was therefore realised using the substitute RF modules TR-72DAT rather than TR-76D. The same applied for the IQRF gateway, where the Global System for Mobile Communications (GSM) version was used rather than the Wi-Fi version. All of these components are identical from the programming perspective and migrating from one to another is requiring only changing the headers and loading the code into the new device, RF module or gateway. The development could thus proceed using substitute devices while planning to use others in the final installation.
During the implementation phase the communication bottleneck between the GSM gateway and the IQRF Cloud was at first attributed to technological limitations to General Packet Radio Service (GPRS) throughput, which usually reaches up to 20 to 40 kbps on upload but varies based on local coverage, the number of devices connected, and the protocols implemented in the gateway itself. This latter was later excluded as the other two types of IQRF gateways had the same issue. Investigation found that the IQRF company outsourced the IQRF Cloud to an external company which imposes an undocumented limit on the number of packets that can be transferred over a certain period of time. This led to a bizarre situation where data that could be transferred from the wireless sensors to the gateway in about 10 minutes took more than 83 minutes to be transferred to the IQRF Cloud. The situation was resolved by creating a custom gateway v1.0 that bypasses the IQRF Cloud and sends the data directly to the CMS server.
Figure 5.2: IQRF Cloud bottleneck