model train intelligence unit - realtime embedded · realtime embedded (rte), the firm of...

Model Train Intelligence Unit

By Oscar Wahlström

Supervisor and Examiner: Ahmed Hemani, KTH Industrial Supervisor: Göran Lindgren, Realtime Embedded AB

Master’s Thesis School of Information and Communication Technology

KTH Royal Institute of Technology

Abstract

Realtime Embedded wanted to demonstrate a multi core system with different operating systems by wirelessly controling a model railway. To do this, a wireless communication module with a small die FPGA, thought to fit a model train, was chosen to be implemented. This job was assigned to me. I looked up hardware components and programmed the FPGA to interact with them and assembled the result into a demonstration arrangement. The arrangement featured radio communication, train position determination and train speed assignment but it had not been shrunk to fit a train. The work provided Realtime Embedded with the first step towards realizing their wireless train control.

Acknowledgements

I would like to thank Göran Lindgren for guiding me through the work, providing valuable experience. I would also like to thank Ahmed Hemani for giving me advice and also Realtime Embedded for providing the thesis opportunity.

Abbreviations

Abbreviation Full Text Page introduced

CRC Cyclic Redundancy Check 8

EAN European Article Number 20

FIFO First In First Out 9

FPGA Field Programmable Gate Array 1

HDL Hardware Description Language 4

IDE Integrated Development Environment

4

LSByte Least Significant Byte 14

MOSFET Metal Oxide Semiconductor Field Effect Transistor

22

MU Main Unit 1

OS Operating System 1

PCB Printed Circuit Board 22

PWM Pulse Width Modulation 6

RTE Realtime Embedded 1

RTEMS Real-Time Executive for Multiprocessor Systems

1

RTL Register Transfer Level 34

RTOS Real Time Operating System 1

RX Receive 9

SPI Serial Peripheral Interface Bus 9

TU Train Unit 1

TX Transmit 9

VHDL Very high speed integrated circuit Hardware Description Language

3

Table of Contents 1 Introduction .........................................................................................1

1.1 Purpose........................................................................................1

1.2 Problem Description ......................................................................2

1.3 Report Setup ................................................................................3

1.4 Important Design Aspects .............................................................3

1.5 Development Platform ..................................................................4

1.5.1 FPGA Board ........................................................................4

1.5.2 Development Software ........................................................4

2 Component Study and Experimentation .................................................5

2.1 Train Tipping Detection .................................................................5

2.2 Speed Monitoring..........................................................................5

2.3 Obstacle Detection........................................................................6

2.4 Radio Circuit.................................................................................8

2.4.1 Requirements .....................................................................8

2.4.2 Data Throughput Estimation ................................................9

2.4.3 SPI Protocol ......................................................................11

2.4.4 Control .............................................................................11

2.4.5 Enhanced ShockburstTM .....................................................13

2.4.6 IRQ ..................................................................................13

2.4.7 Data and Control Interface ................................................13

2.5 Position Determination ................................................................15

2.5.1 Barcode Reading ...............................................................16

2.5.2 IR Evaluation ....................................................................16

2.5.3 Laser Evaluation ...............................................................16

2.5.4 Comparison – Laser vs. IR .................................................19

2.5.5 Digital Interface ................................................................20

2.5.6 Barcode format .................................................................20

2.6 Speed Assignment Circuit............................................................21

2.6.1 Input Response .................................................................22

3 FPGA Implementation .........................................................................25

3.1 Overview....................................................................................25

3.2 Radio Communication .................................................................26

3.2.1 Operation .........................................................................26

3.2.2 State Descriptions .............................................................27

3.2.3 SPI Communication Block ..................................................28

3.2.4 File Organization ...............................................................28

3.2.5 Demo Module....................................................................29


3.3.1 Parameter definitions ........................................................32

3.3.2 Width determination..........................................................33

3.4 Speed Assignment ......................................................................38

3.4.1 Variable magnitudes..........................................................39

3.5 Thesis Demonstration .................................................................41

4 Evaluation and Practical Considerations ...............................................43

4.1 Radio .........................................................................................43

4.1.1 Problems Solved ...............................................................43

4.1.2 Unsolved Problems ............................................................43

4.1.3 Evaluation ........................................................................43

4.1.4 Application Notes ..............................................................44


4.2.1 Problems Solved ...............................................................44

4.2.2 Evaluation ........................................................................44

4.2.3 Application Notes ..............................................................45

4.2.4 Possible Improvements .....................................................45

4.3 Speed Assignment ......................................................................46

5 Summary and Conclusions ..................................................................47

6 References .........................................................................................49

Appendix ................................................................................................51

– 1 –

1 Introduction

1.1 Purpose Realtime Embedded (RTE), the firm of consultants that provided the opportunity to perform this thesis, has a project named “Modesty”, which is a platform for evaluating different technical solutions and demonstrating competence as well as centralizing and raising knowledge within the company.

Recently, a demand among customers of RTE has emerged for multicore processor systems with hybrid operating system (OS) solutions. This was why Modesty was introduced. Until today, the most common reason to increase the number of processor cores has been to increase performance. All cores are then operated by a single OS. However, in embedded multi processor designs, different OSes within the same system is gaining popularity since different aspects of the embedded design are particularly suitable for a certain OS. For example a real time OS (RTOS) may take care of executing periodic tasks while another OS like Linux may take care of the user interface and interaction. The multicore system of Modesty consists of two cores, one with RTEMS, and one with Linux.

Demonstration of this multicore system will be performed with a model railway system with a number of trains where the RTEMS core will handle the safety critical train scheduling processes and similar while the Linux core will take care of other less priority processes. From here on the multicore system with the two processors will be referred to as the main unit (MU) for simplicity. The model railway will be of the kind Märklin gauge Z, which is a miniature system that scales 1:220 to real size. A basic railway fits a small table.

In order for the MU to be able to keep track of and give commands to each train, a wireless radio link to each train shall be implemented. The trains also need some additional abilities that do not come with regular gauge Z locomotives/cars. Therefore, an FPGA (Field Programmable Gate Array) intelligence unit will be attached to each train that will be able to interface different components, one of them radio communication. Implementation of the train FPGA system, from here on referred to as the train unit (TU), is the goal of this thesis.

1 Introduction

– 2 –

1.2 Problem Description

Figure 1: Setup of Modesty with a multicore system communicating by radio with

FPGAs. © Realtime Embedded

From the beginning, some characteristics of the TU were wanted. It should be able to:

Communicate by radio. Detect obstacles on the track, preventing the train from advancing

if detection was present. Determine position of the train. Speed assignment based on sensor data and incoming radio

commands. Detect if a train has tipped.

As the work progressed, it was realized that the above characteristics were more extensive to implement than first thought, although a complete implementation during this thesis was not thought to be feasible even from the start. Therefore, the final requirements of the

1.3 Report Setup

– 3 –

thesis are implementation of these VHDL modules with corresponding electrical equipment:

Radio Communication. Speed assignment. Position determination.

1.3 Report Setup The decision was made to put together the completed parts in a demonstration arrangement in order to make the presentation enjoyable and to explain the functionality.

In the report, the component study is first occurring, followed by FPGA implementation and evaluation. In each of these main sections, the above VHDL modules take consist of one subsection. The component study covers everything that took place before the implementation could start. The evaluation discusses the resulting modules.

Some parts were work has been invested but no tangible result has been produced is described in subsections, such as “Obstacle Detection”, section 2.3.

1.4 Important Design Aspects Overall goals of the design are:

Stable and Robust functionality. Modularity. Visibility of functions in a show off perspective. Low power consumption. Well documented.

In our case a deficient functionality may not harm any real person, in a worst case scenario two locomotives may collide and one or both of them may break but even that is very unlikely. However, since the platform is thought to be demonstrated to potential customers that may want to use some part or some functionality of the platform in a real world application, making the system as stable and robust as possible is considered important.

An important functionality of the TU is the wireless communication. That may be useful in other applications within Modesty further down the road such as rail switch controllers and boom barriers. If parts of the TU module can be used in such applications without a lot of altering of the original module it is considered a clear advantage. So an implementation with modularity in mind is important.

The ultimate goal of the design is to have a platform to spark the interest of customers and provide a good solution for them to use in their own

1 Introduction

– 4 –

production. In order to do so the functions must be clear and entertaining to watch at a demonstration.

Low power consumption is considered an advantage because the TUs may be battery driven in the future.

Since part of Modesty is being a knowledge raiser within the company it is important that the design is well documented and has a good structure.

1.5 Development Platform

1.5.1 FPGA Board

The FPGA circuit of choice for the implementation was Actel’s IGLOO, mainly because of its tiny footprint. This was a decision made by RTE. IGLOO’s smallest package is 3x3 mm in size [1] which will nicely fit on board of the train. These are some features of the FPGA [1]:

Very small packages. Lowest power consumption in the industry. On board clock conditioning circuits. Up to 250 000 system gates (in a 5x5 mm package). 250 MHz system performance. Up to 71 user I/Os.

The “IGLOO nano Starter Kit” [2] was used for development. It has these features:

Pin headers for enabling connection to all of the 68 AGLN250 IOs [1].

8 LEDs, 4 red and 4 green. 8 DIP switches. 4 push buttons. USB uart connected to the FPGA. Battery or wall jack power source operability.

1.5.2 Development Software

Implementation was coded in VHDL which is a widespread hardware description language (HDL) for use in modern FPGAs. Actel provides a tool for FPGA development, Libero IDE, which was used in this thesis. A one year node-locked license was provided by Actel for free, so there were no need to pay for an otherwise expensive license.

– 5 –

2 Component Study and Experimentation The components necessary to satisfy the requirements of the TU are listed below.

Component Purpose

Accelerometer Detect if a train has tipped.

Distance sensor Measure the distance to potential track obstacles.

Radio communication circuit Handle communication between MU and TUs.

Position detector Keep track of the position for the MU to organize the trains on the track.

Speed assigner Determine the speed of the train.

Table 1: Components needed for the TU.

2.1 Train Tipping Detection A 3 axis accelerometer will be used for detecting if a train has tipped. Let us say that the x axis points in the forward direction of the train, the y axis in the direction that crosses the track (in the horizontal plane but perpendicular to x) and z the direction pointing into the rail, seen from above (perpendicular to both x and y). If the train is standardly oriented, standing on the rail with the wheels on the track, the z axis will detect normal gravity if a flat railway is used. A tipped train will be detected by deviating z axis acceleration.

Some potential uses other than tipping detection are double tapping to start the train and speed monitoring which will be discussed below.

2.2 Speed Monitoring Speed measurement will be needed for two purposes, one is for calculating the distance traveled and the other is for evaluating the risk of collision. Calculation of traveled distance will be needed in order to determine position which is discussed later. Evaluation of collision risk will be performed by the MU which keeps track of risk evaluation parameters such as speed, position and track blocking obstacles. There are a few alternatives considered for measuring speed:

Alt 1 - Integrating the accelerometer output.

Alt 2 - Counting railway ties with an optical detector in the bottom

of the train.

Alt 3 - Reading the PWM output duty cycle.

Alt 4 - Measuring back electromagnetic force (EMF) generated by

the train engine.

2 Component Study and Experimentation

– 6 –

Alt 1 is a natural choice and cheap, in terms of extra work and circuitry (none), since the decision already has been made to have an accelerometer on board for other purposes than measuring speed.

Alt 2 requires a bit of effort but in combination with barcode position determination will probably not be very expensive since the two purposes will use the same detection hardware.

Alt 3 would not be a viable choice at all if our module environment would be a real train and railway. In that case the pulse width modulation (PWM) duty cycle of the speed assignment module (see section 2.6) would set the acceleration of the train and not speed. However, since our module is intended for a model train, the inertia of the train in comparison to the engine power is very low and the PWM output is a very good approximation of the actual speed of the train. An indication of this is when disconnecting the train voltage at full speed, the train stops within approximately 0.2 seconds (casual testing). Alt 3 is also the cheapest alternative since we already have the PWM output as an internal digital quantity in the TU VHDL module.

Alt 4 would probably be a very precise method due to the linear relation between motor speed and back EMF motor voltage. The windings of the motor have to float in order to get an accurate measurement, which would require some kind of switch to be connected to the motor. The circuitry required for the switch and the voltage measurement would be quite big in relation to the overall module, however, and the time required designing this would also not be negligible.

The decision has been made to neglect alt 4 due to its disadvantages of big development effort and large circuitry. Alternatives 1-3 will be tested and evaluated, alt 1 & 3 due to their simplicity and alt 2 since optical detection will anyway be tested for position determination. A combination of different methods may also be considered.

2.3 Obstacle Detection A lot of alternatives were considered for this purpose. There are two major categories of techniques here, IR and ultrasonic. Generally this can be said about IR:

Suggestible to interference from ambient light. Cheap. Simple. Narrow detection angle.

And ultrasonic:

Good accuracy. Long range. Requires a couple of components requiring interconnection. Big.

2.3 Obstacle Detection

– 7 –

Wide detection angle.

In the end, three alternatives stood out. They were SHARP GPY0D810Z0F, SPM0204UD5 and HSDL-9100. The SHARP is an IR module that makes use of a special triangular method for detecting and object. It only detects the returning IR beam if it is from a certain direction and can therefore decide with good accuracy if the light is from its own source and thereby eliminate the risk of detecting ambient light or other light sources.

The SPM0204UD5 is an ultrasonic detector that in combination with a transmitter provides a sophisticated system due to the good characteristics of ultrasonic described above. The detector is tiny but transmitters are generally significantly bigger than the detector.

The last sensor, HSDL-9100, is a simple, tiny IR module with an emitter and a receiver in a surface mount package.

Sensor GPY2Y0D810Z0F HSDL-9100 SMD0204UD5

Dimensions [mm]

13.6x7x7.9 2.7x2.75x7.1 4.7x3.8x1.2

Detection range [cm]

1-10 0-6 >100

Table 2: Overview of considered distance sensors.

To summarize, my conclusion is that the HSDL-9100 seems to be the best choice. It is decently small and will not look oversized on the locomotive. The disadvantage of the IR in this case is that it may suffer from ambient light interference. This may be overcome, however, if modulation with a certain frequency is added to the module. An example of how this may be done is in the datasheet of the component. Another disadvantage of the circuit is its limited distance range of detection. As it is described in the datasheet, it is a "proximity sensor" and the detection range is stated to be up to 60 cm. This may sound like a tiny range but the actual braking distance of the train should be taken into consideration. My own measurements suggest that the braking distance is about 2 cm, with the locomotive and two cars of the demo module running. This is not full voltage however, 9 V instead of the allowed 11 V, but with some confidence I can anyway say that 6 cm will be enough to let the train stop safely.

Another thing to take into account, however, is the simulated inertia that is a feature of the PWM speed control VHDL module. In the above case where braking distance has been measured there is an immediate transition from max voltage to zero voltage. If the simulated inertia is applied the voltage is decreased linearly from max until the train stops. If this should be applied also when breaking for an obstacle, which would be the most advanced alternative, HSDL-9100 would not be a viable sensor


– 8 –

since the braking distance will increase significantly. In this case the GPY2Y0D810Z0F would perhaps be a better choice. The obvious disadvantage of that is the bigger size.

However, another problem arises as well, which is that in curves, distances bigger than 6 cm will probably be impossible to detect due to the straight orientation of the train on the curved rail. The SPM0204UD5, however, doesn’t have this limitation. Whereas the Sharp only measures straight forward (due to its triangulation measurement method), the ultrasonic measures at a wide angle. In the ultrasonic case, however, objects at the side of the track may be undesirably detected.

2.4 Radio Circuit

2.4.1 Requirements

For interaction between the MU and TUs, radio communication was chosen. There were a few requirements for the radio circuit that were important:

R1 - Must use a frequency that requires no license fee.

R2 - Must perform CRC check for validation of data.

R3 - Must acknowledge received data.

R4 - Must provide sufficient data throughput for our purpose.

In addition, the following aspects were considered advantageous:

A1 - The use of standards where possible, both in the wireless

communication and data interface.

A2 - Small footprint.

A3 - Low power consumption.

A4 - Low cost.

A5 - Possibility of further use in other applications within the

company.

2.4 Radio Circuit

– 9 –

An employee of RTE suggested a circuit named NRF24L01P (from here on called NRF). It has these features [3]:

2 Mbit max data transfer rate.

Uses the 2.4 GHz ISM band.

SPI data interface.

CRC check.

Auto acknowledge and retransmit functionality.

Multiple virtual address pipelines for receiving from different TX

units.

11.3 mA maximum transmit output power.

13.5 mA maximum receive power.

32 bytes TX and RX FIFOs of size 3.

It uses 2.4 GHz as communication frequency which is an ISM, unlicensed, frequency so R1 is met. It possesses both CRC check and auto acknowledge as embedded features so R2 and R3 may be checked as well. R4 will be proven met in section 2.4.2 below.

The cost is 41 SEK which meets A4. Since it was recommended from an employee it also meets A5. It is a 4x4x0.9 mm sized IC and since the width of the train body is 1 cm wide it is well suited for onboard mounting, hence meets A2. Maximum power consumption, calculated from the datasheet [3] page 14 (13.5 mA @ 3.3 V) is 44.5 mW. This is generally considered to be very low. The standby consumption is even in the order of µW, therefore A3 is met. SPI is used for data interfacing but there is no standard for the wireless data. A1 is therefore considered half met. In summary, it meets the A conditions well enough.

A demo circuit [4] provided by Sparkfun will be used in the development phase of evaluation. It has an on board antenna and other components, so it can be directly connected to the FPGA.

2.4.2 Data Throughput Estimation

A calculation will be made to evaluate requirement R4 that regards data throughput. The data messages that will be exchanged between the MU and TUs are not determined but a qualified assumption is tabled below. They are “Status Report” and “Command”. The status report will be sent from each TU every second in order for the MU to keep track of each train. The command will be sent from the MU to a TU in order to control and assign orders to the train.

Type Contents Size Period

Status Report Speed (8 bits), Position (16 bits)

3 bytes 1 sec

Command Command (8 bits), 2 bytes Sporadic


– 10 –

Value (8 bits)

Table 3: Kinds of data packets to be exchanged between the MU and TUs.

The number of trains supported by the system has not been decided but will most probably not exceed 12, so that is the assumed maximum. The rate of sporadic commands from the MU to each TU is assumed to be less than once per sec so a worst case of twice per sec and TU is assumed. One retransmission for every 5 transmissions is also assumed. Address width is assumed 3 bytes, CRC control one byte and air data rate the maximum 2 Mbps. The automatic transmission delay is set to 500 µs.

, and ARD are described in the NRF datasheet [3]. They are the base upon which the transmission delays are calculated. In the table below, the respective durations per transmission is calculated for no retransmission and with retransmission, respectively. The average duration is then based upon the assumed retransmission ratio.

Quantity Value

Average Packet Load [bytes]

Packets/sec

[bits] [3], p. 42

[µs] [3], p. 42

[bits]

[µs]

[µs]

Duration/Transmission, no retr. [µs] [3], p. 43

Duration/Transmission, with retr. [µs] [3], p. 44

Average duration/transmission [µs]

Utilization

Table 4: Estimated radio throughput utilization.

The utilization tells us that the capacity of the radio circuit is not used very well. However, there is room for improvement of the protocol and addition of more commands. If the utilization would be high, the response time of each command would also be greater and the risk of sending simultaneous messages from TUs to the MU would increase,

2.4 Radio Circuit

– 11 –

which would cause CRC errors and further delay the response times. Finally, as R4 is considered met, all requirements are satisfied and NRF24L01+ is considered a good choice.

2.4.3 SPI Protocol

SPI (Serial Peripheral Interface bus) is a full duplex digital serial data interface specification. Full duplex means parallel send and receive. A master unit may connect to multiple slaves but only one at a time. The signals used are:

Name Description

MISO Master Input Slave Output

MOSI Master Output Slave Input

SCK Serial Clock

CSN Chip Select

Table 5: Signals used in the SPI protocol.

SCK is an output from the master to all slaves and the signal dictates communication. CSN is an individual signal to each slave for deciding which slave the master shall communicate with. MISO and MOSI are data bus lines that go from the master to the slaves (MOSI) or from the slaves to the master (MISO). The MOSI only has one driver, the master, whereas the MISO is driven by each slave, so there has to be some high impedance functionality of the slave MISO port when CSN has not activated the chip.

During every clock cycle, a data bit is output on the MOSI line from the master to the slave and another data bit is output on the MISO line from the slave to the master. Both directions are not always relevant, however. On a rising clock edge when CSN has been pulled down, data is read by both master and slave, and on the falling edge, output data is altered by both parties. Termination of a communication cycle is done by raising CSN. Normally, some kind of shift register is used in both master and slave for sequential output of each bit of data. The same shift register can be used for storing incoming data but in that case, a single bit register must be used for storing the incoming signal on the rising clock edge until data is shifted on the falling clock edge. In Figure 3 further down is an example of how the SPI signals may appear.

2.4.4 Control

The NRF operation is based on different states [3]. When connecting

power, the power down state is entered, and if the POWER_UP bit is set to ‘1’, standby-1 is entered. This is the start state for all active operations of the NRF.


– 12 –

Reading is achieved by setting the PRIM_RX bit to ‘1’ and then raising CE. Then RX Mode is entered, in which state incoming data is listened to. If CE is set back to ‘0’ Standby-1 is reentered. Writing is performed by

writing transmission data to the TX FIFO, setting PRIM_RX to ‘0’ and then keeping CE high for at least 10 µs. Then the first data packet in the TX FIFO is sent and standby-1 is reentered. If CE is kept high until the first data packet has been sent, the TX FIFO is checked for more data which if found is sent. Otherwise standby-2 is entered. The advantage of the standby-2 state compared to standby-1 is that new data entering the TX FIFO is sent faster. However, more power is consumed.

Figure 2: NRF24L01P state diagram.

© Nordic Semiconductor [3]

2.4 Radio Circuit

– 13 –

2.4.5 Enhanced ShockburstTM

Enhanced ShockburstTM(ES) [3] is a packet handling layer that simplifies a lot of aspects of radio communication. Automatic acknowledge, CRC check and multiple receive pipelines are realized in this layer.

The ES practices a certain packet layout containing certain fields for both sending packets and acknowledgement packets. One field is address. The TX unit is configured with a certain TX address which it stores in this field. The RX unit is configured with an RX address which must match the address of the incoming packet if it shall be validated and put in the RX FIFO.

Multiple receive pipelines is also supported, which means an RX device may be configured with different RX addresses to receive from in order to know from which address a packet was transmitted. Receiving to different addresses is stated as receiving through different pipes, according to the ES specification. Up to six different pipes is supported.

Automatic acknowledge (Auto ack) is performed in order for the sender to confirm the sent data has been received. If the data was not received, an automatic retransmission may be performed by the sender. The number of repeated retransmissions is adjustable. For auto ack to work, the same address as the TX address must be configured as RX address of pipe 0.

When receiving a packet, validation in form of Cyclic Redundancy Check (CRC) is also performed. The CRC is calculated over the address, payload and an NRF specific packet control field. One or two bytes CRC check is supported.

2.4.6 IRQ

The NRF has an IRQ output pin which may be configured to signal different events. The events are “RX FIFO full”, “TX message sent” and “maximum number of retransmits reached”.

2.4.7 Data and Control Interface

Figure 3: NRF24L01P SPI read operation.

© Nordic Semiconductor [3]

Communication is performed in sets of bytes with CSN indicating where a cycle starts and finishes. SCK tells the slave when to exchange each data bit. The command set of the NRF SPI interface consists of read, write and


– 14 –

execute commands. All execute commands are single byte operations. The read and write operations consist of a command byte exchange followed by one or more data byte exchanges. In Figure 3 above, a read operation is visualized. All data transfer exchanges are performed with the LSByte first.

The commands used for the purpose of the thesis are shown below in Table 6. Each command is associated with a specific data byte which is not included in the table.

Command Description

R_REGISTER Read a setting or status register.

W_REGISTER Write to a setting register.

R_RX_PAYLOAD Read incoming data payload.

W_TX_PAYLOAD Write outgoing data payload.

FLUSH_TX Flush the TX FIFO.

Table 6: Commands of the NRF that have been used.

Registers that have been edited and/or read are listed in Table 7. Byte addresses are excluded.

Register Description

CONFIG Sets interrupt enable, CRC number of bytes,

PWR_UP and PRIM_RX bits.

SETUP_RETR Configures number of automatic retransmissions.

RF_CH Sets communication frequency channel.

RF_SETUP Sets radio output power.

STATUS Contains info about interrupts, data pipe number of incoming data and TX FIFO full.

OBSERVE_TX Has info about number of lost and retransmitted packages.

RX_ADDR_P0, RX_ADDR_P1

Sets addresses of used RX data pipes.

TX_ADDR Sets transmit address.

RX_PW_P0, RX_PW_P1

Sets payload data width of used data pipes.

2.5 Position Determination

– 15 –

FIFO_STATUS Has info about the TX and RX FIFOs.

Table 7: NRF status/control registers used.

2.5 Position Determination Position determination is needed in order to keep track of the trains and avoid collisions. The position of the train will be estimated speed integration but small speed measurement errors will accumulate in the distance calculation and if the train travels for a long time period the error may continue to grow. In order to prevent this a number of locations along the railway where the TU can pick up its actual position and correct the calculated position are thought to be set up.

The methods below have been considered for position determination.

Alt 1 - IR emitter/receiver pair.

Alt 2 - Barcode reading.

Alt 3 - RFID wireless interaction.

Alt 1 is realized with an IR emitter embedded in the railway or placed at the side of a passing train and is constantly emitting an array of bits indicating an address. An IR receiver is placed in the train and it listens constantly for an external address signal. When the train passes the embedded track emitter it identifies the signal as an address location. Advantages are cheap components, little space occupied on train and simple implementation. The obvious disadvantage is the additional modules required for each address. Either a local FPGA implementation could be constructed for each address post or wires could be connected between the MU and each address post.

Alt 2 is a solution that is based on the reduced reflection of light from a black surface compared to a white. A light source is placed emitting from the bottom of the train together with a light sensitive detector while a barcode is placed between the rails in the track (covering multiple sleepers). Based on the received intensity in the detector, either black or white is indicated. The address will be indicated black and white “bars” of varying width. Advantages are there will be no modules at other places than the TU, in other words no need to dispatch wiring to different places of the track. However, extra space consuming components on the train will be required.

The last alternative, alt 3, is wireless communication and detection within a close proximity. Similarly to alt 2, this requires no development of external modules because the tag, that in our case would indicate the address and be embedded in the rail or somewhere along the track, is a passive component that requires no voltage supply, but responds to received radio waves.

After doing some research, alt 2 has been determined to be the best. Alt 1 was neglected at an early stage due to the external modules required.


– 16 –

Alt 3 was a very exiting option but was concluded to be too big for the train, after looking at alternatives available on the market. One module was for example 26x25x7 mm big which considering the train width of roughly 1 cm is impossible to fit onboard. The components required for barcode are for comparison at biggest two diodes of 3 mm diameter.

2.5.1 Barcode Reading

For implementing barcode reading there are a lot of components available. These alternatives were picked for evaluation:

Alt 1 - HSDL-9100, a tiny IR module with an emitter and receiver

with dimensions 2.7x2.75x7.1 mm (actually the same one

considered for obstacle detection, see 2.3).

Alt 2 – Laser diode in combination with photo transistor.

Both these options have been concluded possible solutions. Alt 1 is smaller whereas alt 2 theoretically should have better accuracy and be able to measure thinner stripes.

2.5.2 IR Evaluation

HSDL-9100 [5] is an IR transmitter/receiver pair mounted in a tiny package measuring 2.7x2.75x7.1 mm. It has a maximum power dissipation of 165 mW which is high. However, maximum effect is probably not going to be needed and both the receiver and transmitter may be pulse modulated, adjusted for the sampling frequency and duration of each sample.

When experimenting with the HSDL-9100 it was found to be able to read 3 mm wide black/white lines on a paper with good accuracy. Ambient light was not considered a problem because the roof lights were turned on and off without any big disturbances.

2.5.3 Laser Evaluation

The next barcode alternative for evaluation was a laser diode together with a detector. Components used were these:

Laser diode ADL-65055TL [6]. Laser driver IC-WK SO8 [7]. Phototransistor TEPT5600 [8]. Phototransistor TEMT6000X01 [9].

Laser compared to IR is more focused on one spot which makes it more precise while reading as well as more energy efficient. The disadvantage is the higher cost and bigger circuitry because a laser driver is recommended to use with a laser diode.

The laser diode was connected to the laser driver according to an application note [10] recommended connection diagram which can be


– 17 –

found in the appendix. A picture of the optical setup is found in Figure 4 below.

Figure 4: Optical setup of the laser diode together with the photodiode

TEPT5600.

The TEPT5600 was connected to a 10 kohm resistor to indicate high/low voltage caused by the photocurrent through the phototransistor. The bars seen in the same figure were swept over and the voltage recorded on an oscilloscope DSO3014A [10]. The result is seen in Figure 5.


– 18 –

Figure 5: Oscilloscope resistor voltage from the experiment with TEPT5600.

As can be seen, the voltage does not contain very sharp transitions. The bars swept were the ones of Figure 4 which where 3 mm wide. The goal was to read thinner bars than that so the result was simply not good enough. Some aspects were thought of as particularly negative factors for the result:

The height difference between the laser diode and phototransistor was 1 cm. This increases the light scattering as well as the distance between the laser diode and the barcode surface.

The width of the phototransistor was 5 mm which absorbs a too big width of light for detecting transitions accurately.

Some further experiments were conducted, covering part of the phototransistor and reducing the length of the leaders of the phototransistor to put it at the same height as the laser diode and thereby reducing the distance to the barcode surface. These steps led to marginally better results but it was not until the phototransistor was changed to TEMT6000X01 that the results were improved significantly. The TEMT6000X01 is a phototransistor with a 1 mm wide detection area. It is suited for surface mounting so legs of wire strips were added to make it fit in the setup. It ended up looking like this:


– 19 –

Figure 6: Final setup of the barcode reader.

The resulting oscilloscope view looked this way after a sweep over both märklin gauge z rail and 3 mm bars (the same as in Figure 5):

Figure 7: The final oscilloscope view of phototransistor resistor voltage.

The only thing that was changed between the sweep of Figure 5 and Figure 7 was the phototransistor and the physical distances between the parts. In Figure 7, the voltage reaches almost the supply voltage at a high state and ground at a low state. These were the clear transitions that were sought so now the optical setup was considered acceptable.

2.5.4 Comparison – Laser vs. IR

For reading 3 mm wide black/wide bars, the alternative with IR was considered good enough. However, ultimately the goal was to read real barcodes and this would probably be hard to achieve with that limited accuracy. The other possible use of the barcode reader – being able to


– 20 –

determine speed by counting rail ties – was also difficult because of the height difference between the ties and the surface below. Therefore, the laser alternative was concluded the best choice.

2.5.5 Digital Interface

For connecting the analog signal to the FPGA, a one/zero signal was needed from the barcode reading circuit. For that purpose the circuit in Figure 8 below was used. The operational amplifier used was MCP600 [11]. The appropriate threshold voltage of the comparator was set to

. This seemed an appropriate choice after looking at the oscilloscope view from Figure 7. Relatively high impedance resistors were used for voltage splitting to reduce power dissipation. The output in the figure is connected to an LED which was used for testing. However, the 5 VDC output was later voltage divided by resistors to connect to a 3.3 V input port on the FPGA.

Figure 8: Comparator for digitizing the phototransistor output.

2.5.6 Barcode Format

Code 39 was chosen as the barcode of choice at an early stage due to its simplicity. Generally when you see a barcode on groceries and other items in stores you will see an EAN (European Article Number) barcode (see Figure 9 to the right). Each bar may be of variable width with four different bar widths. Reading an EAN is normally no problem for a commercial barcode scanner. An important feature of such a device, however, is that they read with more or less constant speed. The beam of light (normally laser) is swept back and forth over the barcode and displacement variations due to the instability of holding the scanner are relatively small to the speed of the light beam.

In our application, however, the speed of the reader may vary because the train speed may be altered at any time, therefore, an EAN barcode would be difficult to read. So code 39 was chosen, which is a barcode

Figure 9: An EAN barcode.

2.6 Speed Assignment Circuit

– 21 –

format with only two width alternatives; wide and narrow. There are different fonts for printing code 39 barcodes that use either twice or three times as wide bars for the definition wide, compared to narrow bars. For simplicity, a font that practiced three times width difference was used for our application [12]. Other features of code 39 are:

Originally 39 characters but was later extended to the current 43.

3 wide and 6 narrow bars per character.

5 black and 4 white bars per character.

Characters begin and end with a black bar.

Characters are separated by a narrow white bar (whitespace).

Barcodes start and end by a ‘*’ character which is asymmetrical.

43 characters are enough for using only single character barcodes since there will be roughly 10 different address posts on the track. Single character barcode means of format “*C*”, that is three characters of which the first and last is the code 39 start and end indicator ‘*’, with any of the other 42 characters in between. If a single bar read error should occur, it will not be accepted because of the requirement of 3 wide and 6 narrow bars. The asymmetrical start/stop character enables direction to be detected as well.

2.6 Speed Assignment Circuit For controlling the speed of the model train PWM modulation was a natural choice since the functionality of the design is digital. PWM is a type of output where pulses of the same amplitude are output with a constant frequency. The widths of the pulses are modulated to output a certain average. Since for example an train engine has a certain inertia and cannot start and stop for every single pulse, the rotation speed is determined by the PWM average.

A circuit named BD6220F, which is of H-Bridge type, was chosen for PWM modulation. An H-bridge is an electrical setup where two control inputs connect to driver transistors so that the output current can be either positive or negative from the same voltage supply. In that way the locomotive can move both in forward and reverse direction from the same voltage supply.

The following aspects were important for the BD6220F choice:

A1. Suitable functionality for the purpose.

Figure 10: A code 39 barcode.


– 22 –

A2. Enough output current.

A3. Requires no external MOSFET driver transistor (saves PCB

space).

The obvious requirement was being able to interpret PWM input. BD6220 does that and enables forward/reverse direction as well as breaking (meets A1). Maximum train current has been tested to be 200 mA so the maximum specified 500 mA for the circuit covers that with a margin (meets A2). Everything is included in a single package so A3 is met as well.

2.6.1 Input Response

For testing the circuit, a square wave with peak to peak voltage of 3.3 V was connected to the input and the output was connected to the rail track on which a train was running. The input and output was measured with the same oscilloscope used earlier and the result is seen in Figure 11 below. A spike on the output showed up for some unknown reason. Speculation led to the assumption it was caused by the switched power supply that propagated noise. The spike was extra surprising because the BD6220 has built in over voltage protection diodes that are supposed to cut the voltage at 0.7 V above the supply voltage, which in this case was 9 V. It can even be seen that the spike were propagated to the input which may potentially have harmed the FPGA in the long run.

Figure 11: Curve form of the PWM input (green) and output (yellow) connected

to the railway.

2.6 Speed Assignment Circuit

– 23 –

The datasheet [13] suggested that pull down resistors were added to the inputs to suppress this noise, so that was done. The result is shown in Figure 12 below.

Figure 12: Curve form of the PWM input (yellow) and output (green) after pull down resistors were added.

Now the spike has been reduced and no input noise is any longer detected. The spike was still there but reduced and not considered big enough to hurt the train.

– 25 –

3 FPGA Implementation

3.1 Overview In the final design, the TU is thought to be built around a control module that gives each active module, such as speed assignment, their data and at the same time monitors input from the sensor modules. It shall takes orders via radio and report data about itself at a regular interval. In its simplest form, this control module could consist of a simple receiver that takes the data from the radio and writes it to registers that are directly connected to the active modules such as speed determination. An alarm timer could trigger a send of all data from the sensor modules via the radio. By this approach you could regard the MU as the central “brain” of the trains that makes their decisions for them.

Another approach is that the control module has its own state diagram and makes intelligent decisions based on every sensor input it receives and the orders received from the MU and applies the appropriate output to the active modules.

For an example of how to use the implemented FPGA modules, see section 3.5 “Thesis Demonstration”.


– 26 –

3.2 Radio Communication

Figure 13: State diagram of Radio Unit, a VHDL controller for the radio circuit NRF24L01P.

The module is built upon main states and sub states. Each main state is either a transfer state or not. If a main state is a transfer state it has some data interaction with the NRF. If a main state is not a transfer state it has some other purpose than interacting with the NRF.

A transfer state is divided into two sub states, “write_cmd” and “trans_data”. “write_cmd” always writes a command to the NRF24L01P (NRF) by Serial Peripheral Interface bus (SPI) and “trans_data” either reads incoming data or writes outgoing, based on what command is executed. If a main state is not a transfer state, the sub state has no purpose, it is always “done”.

3.2.1 Operation

At startup, the module initializes by writing some commands to the NRF (main state “init”). Then read configuration is activated (main state “read


– 27 –

set”) and it goes on to listen for incoming data (main state “wait data”). From here on two loops are possible, one for receiving and one for transmitting.

Transition from main state “wait data” alt. 1: If an IRQn, which is active low, is received, receive configuration activated means new data has arrived so data is fetched (main state “get”), IRQ acknowledged (main state “ack irq”) and output for reading (main state “output data”). When all incoming data has been read progression is made back to main state “wait data”.

Transition from main state “wait data” alt. 2: If outgoing data is written to the internal registers, transmit configuration (main state “trans set”) is activated. If a new transmit address has been written to the internal register, that address is updated in the NRF (main state “txa set”). Then transmission data is written to the NRF (main state “put”) and a pulse to transmit data (CE high for 10 µs) is generated (main state “send data”). Since transmit configuration is activated, IRQn received means data sent. In order to assure data is sent before proceeding, IRQn is awaited before continuing from main state “send data” to acknowledge the received IRQn (main state “ack irq”). If new data for transmission has been written to the internal registers since last the main state, “put”, that state is looped into again as well as main state “txa set” if the address has been updated, otherwise configuration to receive data is activated (main state “read set”).

3.2.2 State Descriptions

State “init” writes configuration values to the NRF. It powers up the circuit and configures CRC. If multiple pipes shall be used it sets their widths and addresses. A standard TX address is set as well as the number of automatic retransmissions. Radio channel and power may also be set. State “read set” configures the NRF for receiving data. PRIM_RX is set to

zero for going into RX mode when raising CE. The RX_ADDR_P0 is also reset to the regular value for receiving. This is done because the register

is altered when entering TX mode to be the same as TX_ADDR, according to the requirements for auto ack to work.

State “wait data” is simply a transitional state which moves on to “get” if a low signal is detected on the IRQn pin or to “trans set” if outgoing data is detected in the internal registers.

State “get” reads data from the TX FIFO.

State “ack irq” acknowledges the detected IRQ by writing to the STATUS register. It also flushes the TX FIFO in case data was not sent in order not

to fill the FIFO with old data. It also reads the registers FIFO_STATUS and

OBSERVE_TX in order to simplify debugging. These registers may later be read in state “wait data” but simply being able to see their contents when using a logic analyzer is a significant help. A note can be made that the


– 28 –

same “ack irq” state is used both when in RX and TX mode. This is because the operations for acknowledging IRQ don’t differ between the modes. An internal single bit signal is used to indicate weather in TX or RX mode.

State “output data” waits for a signal from the user indicating that data has been read. After each incoming byte that has been read, it outputs the next byte. When all bytes have been output, it transitions to the next state. Optionally, the received data pipe number may also be read.

State “trans set” configures the NRF for transmitting by writing a ‘1’ to

PRIM_RX. It also alters the address of pipe 0 to the same as the transmit address in order to enable auto ack.

State “txa set” is entered if a new transmit address has been written to the internal register since the last transmission. It alters the address registers for TX and RX pipe 0.

State “put” writes data to the TX FIFO.

State “send data” first raises the CE signal to the NRF for 10 µs. This is a requirement for making the NRF go into TX mode. Then it waits until an incoming IRQn has been received. Since the NRF is in TX mode this means either that the maximum allowed number of retransmissions has been reached, which means the transmission failed, or that the message was successfully sent.

3.2.3 SPI Communication Block

The data that is transferred between a radio_unit and the NRF goes through a dedicated SPI block. The radio_unit is the master and the NRF is the single slave. The radio_unit writes and reads data through 8 bit wide data buses, one for each direction, and the SPI block translates the data to the right format.

3.2.4 File Organization

The two files “radio_TU.vhd” and “radio_MU.vhd” are exact copies with two exceptions, they provide different entities corresponding to their file names and they include “pkg_radio_TU.vhd” and “pkg_radio_MU.vhd” respectively. The package files define most of the commands with corresponding data that are executed during the transfer states. For example if you want three automatic retransmissions instead of two or if you want to enable six pipes instead of four, you edit the pkg_radio files, inserting the wanted data. Each of the radio units are connected to an SPI block “spi_main.vhd”. The SPI blocks are directly connected to the respective NRFs.


– 29 –

3.2.5 Demo Module

Figure 14: Block diagram of the demo circuit for Radio Unit.

For demonstration of the ability of a Radio Unit instance to receive and transmit data, as well as to use different pipes, a demo module including two instances of Radio Unit was built. radio_MU and radio_TU are identical instances of Radio Unit but the thought is to alter their init sequences to make the Main Unit (MU) communicate with multiple Train Units (TU). The NRF has a specific functionality for communicating between one “server” and up to six “clients”.

radio_MU has the ability to transmit two different settings. The first is “CMD: ON/OFF” and the second is “CMD: pipe 0/1”. When received, the commands will be stored in a setting register controlling radio_TU. The communication from radio_MU to radio_TU always goes through the same pipe.

radio_TU takes action based on the settings stored in its control setting register. If “CMD: ON” is set, an alarm that triggers every second is active. A DIP switch on the TU receives the alarm and transmits its momentary 4 bits to the MU. Depending on if “CMD: pipe 0” or “CMD: pipe 1” is set, radio_TU transmits the 4 bits through the corresponding pipe. If “CMD: OFF” is set instead of “CMD: ON”, the alarm counter is paused.


– 30 –

When the radio_MU receives data, it checks on which pipe the 4 bits were received. If they were received on pipe 0 the red LEDs are updated with the bits. Pipe 1 updates the green LEDs.

3.3 Position Determination The detection sequence for reading a barcode is divided into the three states ”waiting”, ”rail” and ”addr”. State ”waiting” is active when no transitions from the incoming black/white signal are detected. State ”rail” is active when transitions are detected but no info is extracted. The name rail has when this report was written nothing to do with the actual state. This is a consequence of the planning of an additional feature thought to be added later. While not reading an addr, the incoming black/white signal will be detecting black if located over a sleeper and white if located between sleepers. By measuring the distance between the sleepers or the width of the sleepers and comparing them to the transition durations picked up, train speed estimation should be possible. State ”addr” is active while an actual barcode is being read.

3.3.1 Functionality

The state diagram is seen in Figure 15 below. After reset, state ”wait” is active. If in state ”wait” and detecting a transition black to white or vice versa, state ”rail” is entered. Timeout is detected if there is a delay before the following transition that is greater than 0,44 s, in which case state ”wait” is entered again.

Figure 15: State diagram of the barcode reader.

If a ’*’ character (the start indicator of a code 39 barcode) is detected in state ”rail”, state ”addr” is entered. Then the actual data read is initiated.


– 31 –

In state ”addr”, the behavior differs when detecting a ‘*’ as opposed to any other character. The latter causes a store of the detected character in the temporary character register. If a ’*’ is detected instead, the characters currently in the temp char register are output and cleared, and the state returns to ”rail”. The temporary character register has an application specific size which is defined in the package library file for the barcode reader. If no ‘*’ is detected before the temporary character register is full, all characters currently in the register are cleared and a single ‘?’ character is output at the same time that state “rail” is entered.

Let us take a user case for an example. The barcode from Figure 10 shall be read and it is assumed that a lot of white space exists to the left and right of the code. The characters of the string “*code 39*” will be read, one after another. At the start, enough white space to the left of the first character ‘*’ exists to cause a timeout, the state then is “wait”. When black color of the first bar is read, a color transition is detected and the state becomes “rail”. Every subsequent transition will be within 0,44 s, thus no further timeout will be detected before every bar is read. The logged widths will be checked at every subsequent transition to white (a character always ends with a black bar) but no match will occur before all bars of character ‘*’ are read. Then the state becomes “addr”. The barcode characters “code39” will be stored as they are read, in the temporary register. At index 0 the ‘c’ will be stored and at index 5 the ‘9’ will be stored. Finally, as the last ‘*’ is detected, all registered characters will be flushed to the uart and the state becomes “rail” again.

The logic of detecting characters is described in Figure 16 and Figure 17 below. The logic is represented as a sequence diagram, however, in reality there is no sequence but a combinatorial block consisting of logic gates in the FPGA. In both states ”rail” and ”addr”, an array of registers is used to log the durations before the recently detected transitions. Every duration represents the width of a ”bar” from the read barcode. In state ”rail”, every new duration is considered corresponding to the potential last bar of a new ’*’ character. This is different from state ”addr” where only every tenth duration is considered. The reason for this is in state ”rail”, you don’t know the relation of the character bars to each other. Therefore you have to check the last series of bars at every new bar detection. In state ”addr”, however, you know where the characters are supposed to appear in relation to the start char ’*’. Then, only the last bar of every character needs to be checked and in our case this is every tenth bar since the barcode characters consist of 9 bars with a white space between every character. If ten new bars have been read since the last character and the bars do not match any character, an error has occurred.


– 32 –

new transition

store duration

state: rail

state => addr

widths match

’*’=010010100 and

colors match

BWBWBWBWB

convert 9 last

durations to

widths where

0=thin 1=wide

yes

Figure 16: Combinatorial logic of

character detection in state "rail".

new transition

store duration

state: addr

bars = 9 bars++

bars <= 0

durations

match

’*’

3 wide

6 narrow

BWBWBWBWB

store

character

invalid char

store ’?’

state => rail

no

yes

no

yes

no

yes

Figure 17: Combinatorial logic of

character detection in state "addr".

A valid character is when the colors of the bars are ”BWBWBWBWB” and three of them are wide and six narrow according to the described code 39 specification (section 2.5.6).

3.3.2 Parameter Definitions

The sampling period is the amount of time passing between each sampling of the incoming black/white signal. I consider 20 samples the minimum amount for a bar in a barcode to be a base for a calculation and 1 mm the minimum width of a bar. A speed test was performed with the train and a track length of 154 cm. At maximum speed, the train took 3,38 s to complete one round of the track. The biggest duration at which to measure a bar of any width was decided to 0,44 s. That means, if reading one bar takes more than 0,44 s, a timeout is detected and the barcode reading is terminated (state “waiting” is entered).


– 33 –

Description Name Value

Min samples

Min bar width

Track length

Track duration at max speed

Duration timeout

Clock frequency

Clock period

Sampling period

Clock ticks per sample

Max number of samples

3.3.3 Width Determination

As mentioned earlier, the durations that each correspond to a bar are stored in a register array. In order to extract any useful information from the durations they are converted to one bit each, where ’1’ represents a wide bar and ’0’ represents a narrow bar. This conversion is based on the characteristic of code 39 that, bar widths are always either wide or narrow. The used code 39 font [12] practices three times the width of narrow bars for the definition wide. This is advantageously used in this implementation, where a duration after another which is more than twice as big, is considered corresponding to a wide bar. The comparison is especially suitable for digital implementation since a twice as big or half as small number is a simple shift operation. If, however, none of the previous conditions apply, the bar is within the limits to be considered being of the same width.

A problem, however, arises when determining the first bar of a character because there is no comparison to a previous to be made. This is solved by assuming a narrow width and if the first switch between widths turns out to be wide to thin, all bars previous to the switch are changed to wide. Implementation is done combinatorially (all in one clock cycle), but a VHDL variable is used for simplifying and structuring the coding. In


– 34 –

Figure 18 is the pseudo code of the VHDL function calc_widths that

determines the widths from the durations. [text written like this]is

a substitute of a code chunk with text describing what the code does.

function calc_widths (durations : type_func_durations) return std_logic_vector is

variable widths : std_logic_vector(0 to 8); variable trans_found : boolean;

begin

widths(0) := '0'; trans_found := false;

for c in 1 to 8 loop if [duration c more than twice as big as c - 1, considered wide] then

widths(c) := '1'; trans_found := true;

elsif [duration c less than twice as small as c - 1, considered narrow] then

widths(c) := '0'; if trans_found = false then -- firs trans is wide to narrow, alter the assumed widths of the -- initial widths from narrow to wide [alter previous widths to wide] end if; trans_found := true;

else

-- duration within limits for unchanged widths(c) := widths(c - 1);

end if; end loop;

return widths; end function calc_widths;

Figure 18: Pseudo VHDL code of the width determination function.

First, the initial width is assumed ‘0’ and an indication variable

trans_found is set to false. The next width is tested and if the test generates wide, the width is set to ‘1’. If the test generates narrow, the tested width is set to ‘0’ and if it is the first transition, all the previous widths are set to ‘1’. If it is of the same width it is assigned the width of the previous.

3.3.4 Hardware Analysis

A sketch of a register transfer level (RTL) block demonstrating the principle of operation is found in Figure 19. The RTL description is present


– 35 –

to show the underlying thoughts of the coding as well as enabling possible future optimizations. The block is only taking 4 durations as input signals which is less than the used module which takes 9 durations, but 4 is all that is relevant for understanding the functionality.

Figure 19: RTL design of widths determination.

I will first explain every part of the logic circuit and then examine different possible input combinations where the input will be of the form “WNWN”, where ‘W’ means “Wide” and ‘N’ means “Narrow”. In reality each letter will be an N-bit number representing the width of a bar or a white space. The number N is determined by the number of bits required to count up to samples.

Below is the purpose of each functional mode of the decoders dec2 to dec4 described:

XY Description Code

“00” The duration is neither greater than double the previous nor less

“Equal”


– 36 –

than half the previous. It is therefore considered to be of the same width.

“01” The duration is less than half of the previous. It is considered thin.

“Thin”

“10” The duration is more than twice as big as the previous. It is considered wide.

“Wide”

“11” Forbidden output.

Table 8: The possible modes of the decoder blocks dec2 to dec4 from Figure 19.

Gray AND gates

If the corresponding decoder block is either “Thin” or “Wide”, it is deterministic. That means the decoder can decide for itself what the width shall be. If the decoder block is not deterministic, its X and Y signals will contribute to enabling this AND to receive width information from the left. The left width is determined by a blue OR that either propagates the width directly from the left X or receives the width from the next gray AND in turn. That AND performs the same logical operation and the pattern repeats. Theoretically, the rightmost width could be determined by the leftmost decoder through this chain. The code 39 format does, however, not allow this. There is one more condition that must be fulfilled, however, for the chain to be propagated – the output of the green ORs must be ‘1’. The reason for this will be explained below.

Green OR gates

These gates propagate a chain in the other direction compared to the gray ANDs, left to right. If the first decoder, seen from the left, outputs “Equal”, there is no information from the left to determine the width. If multiple decoders one after another from the left outputs “Equal”, none can determine the width. The width of all these decoders is decided by the Y signal of the first deterministic decoder to the right. Each gate in the chain of the green ORs tell the decoder to the right if a valid width is coming from the left. A ‘1’ from either X or Y of a decoder means the decoder is deterministic, so the OR combination of these signals and the resulting from the left is the appropriate logic. In this way, the chain will propagate ‘0’ as long as decoders output “Equal” and from the first deterministic decoder onwards, ‘1’ will be propagated.

Pink AND gates

If the output from the green OR indicates width not yet determined (‘0’), the width must be received from the right. Therefore this pink


– 37 –

AND is then enabling propagation of that width. The width is in turn

determined by an OR combination of the Y (decoder deterministic) to the right and the next pink AND output (decoder not

deterministic).

Yellow OR gates

To summarize, a width can be determined either by a deterministic corresponding decoder (alt 1), a deterministic decoder to the left (alt 2) or, if all decoders to the left as well as the corresponding are

not deterministic, by a deterministic decoder to the right (alt 3). In alt 1, both the grey AND to the left and the pink AND to the right

are directly disabled by the corresponding decoder and the width is determined by the X of the decoder. In alt 2, X is ‘0’ and the pink

AND to the right is disabled. The width is received from the grey AND. Lastly, in alt 3, X is ‘0’ and the grey AND is disabled. The

width is received from the pink AND to the right. This means the OR combination of the grey AND output, the X signal and the pink AND output is a valid representation of the width.

Case Input dec2 dec3 dec4

1 “NNNW” “Equal” “Equal” “Wide”

2 “WWWN” “Equal” “Equal” “Thin”

3 “WNNN” “Thin” “Equal” “Equal”

4 “WNWN” “Thin” “Wide” “Thin”

Table 9: Overview of the cases used for describing the widths determination

module.

In case 1 in Table 9 above, both green AND gates output ‘0’, since all decoders to the left of dec4 output “Equal”. dec4 is deterministic and its Y signal is propagated through all pink ANDs to set width1 to width3 to ‘0’. width4 is determined by dec4 directly from its X signal.

In case 2, the same data paths are activated but now width1 to width3 are set to ‘1’ by Y of dec4. width4 is set to ‘0’ by the dec4 X.

dec2 is the only deterministic decoder in case 3 and its Y sets width1 to ‘1’. Both grey ANDs are enabled by dec3 and dec4 so width3 and width4 are set to ‘0’ by X of dec2. dec2 also sets width2 to ‘0’.

In case 4 all decoders are deterministic so all pink and grey ANDs are disabled and the widths are determined by the X signals of the decoders except for width1 which is set by Y of dec2.


– 38 –

A comment can be made about the decoders dec2 to dec4, they can actually be omitted and A connected directly to X and B directly to Y. However, in this example they have been used for practical reasons.

Another synthesis aspect to take into account is of the 9 bars of a code 39 barcode, a maximum of 6, counting from the left, can be of the same width since there must be 3 wide bars ( ‘Q’ is the character where this happens). Let us say dec2 is the first of eight decoders ending with dec9. To the right of dec6, no green ORs or pink ANDs are needed. Because the carry chain must be broken at latest to the right of dec6, the pink ANDs serve no purpose and consequentially, neither do the green ORs.

3.4 Speed Assignment The implementation of PWM modulation was chosen to simulate the inertia of a train. During speedup and slowdown, the magnitude of acceleration and deceleration was set constant for simplicity. The magnitude is the same for both acceleration and deceleration and will from here on be called delta speed. Constant acceleration during speedup is a good approximation since drag is not a big factor when it comes to trains. This is because the weight of the train is so big compared to the area that is suggested to winds. Delta speed, which is an input signal of four bits, may be varied. The signal must be bigger than zero or output speed will remain constant. Wanted speed is an input of eight bits and direction is an input of one bit. When changing the input speed, output speed will change with the size of delta speed at a rate of every fourth of a second, until the wanted speed is reached.

Figure 20: Illustration of the speed assignment variation.

A feature added for the second version was threshold values. When testing the PWM module with the train, a time gap was noted between stopping after deceleration and starting to move again before acceleration. This was caused by the delay between the duty cycle starting to increase from zero and the train actually starting to move. In order to prevent this delay from occurring, user definable threshold

3.4 Speed Assignment

– 39 –

values were added which are activated immediately at startup when accelerating from zero, as well as decreased from immediately to zero when decelerating. A delay for transitioning between acceleration/deceleration and vice versa was also introduced for sound operation of the train engine.

The names of the values are:

Threshold forward upwards – tfu. Threshold forward downwards – tfd. Threshold backward upwards – tbu. Threshold backward downwards – tbd.

Figure 21: Plot of the output PWM duty cycle (255=100%) as a function of input.

A theoretical PWM input-output scenario is plotted in Figure 21. First, input is set to 100% and the output immediately moves to tfu and then linearly moves toward the end value. When -100% is input, at tfd, the output goes immediately to zero and takes a short break before following the regular route to -100%. At time 45, the input is 0% and the output is moving towards tfd. Then the input changes to 100% and the output moves immediately to tfu before linearly moving to 100%.

3.4.1 Variable magnitudes

The PWM switching frequency was chosen to 20 kHz which is the lowest supported frequency of the chosen circuit. There is no reason for a higher frequency than that.

For setting a PWM duty from 8 data bits, the max duty must be and min duty 0, which gives us the PWM resolution 255. The PWM

resolution in this case means the number of different PWM duty cycle


– 40 –

output alternatives. In order to output the PWM signal, a clock frequency

divisible with kHz MHz is favorable because then a constant number of clock cycles represent one step in the PWM resolution. No

need was found requiring a clock frequency higher than that, so MHz was chosen as the global clock frequency.

For linearly adjusting the duty between the momentary and the one given

from the input, an update interval of every of a second was chosen.

Delta speed maximum is 15 due to the limitation of four bits. From that, the following maximum and minimum acceleration times from zero to max speed may be calculated:

Max: s

Min: s

This means that if delta speed “0001” is used and the threshold functionality is ignored, it takes roughly 16 s to accelerate up to full speed from zero. The maximum delay for any change in input value is when at full speed and changing direction which takes roughly 32 s. If delta speed is “1111”, a full speed change of direction takes roughly 2 s.

3.5 Thesis Demonstration

– 41 –

3.5 Thesis Demonstration When starting to summarize the thesis, we started to think about how the work could be presented. It didn’t seem practically feasible to embed anything in the train during the thesis due to limited time. The decision was made to control the speed of the trains and monitor their passages in one FPGA module, the rail module, while receiving manually input user speed data and outputting text data in another separate FPGA module, the operator module. Although the modules are separate in terms of VHDL code, they were implemented in the same FPGA since there only is one for me to use. An illustration is found below in Figure 22.

Figure 22: Overview of the thesis demonstration.

The user can edit the PWM input on the DIP switch, which triggers the operator radio to transmit a message which the rail module applies to rail track. The locomotive and cars will have barcodes attached to them, placed under the body facing the rail and the reader will be placed in the track pointing upwards. Each locomotive/car will have different barcode IDs. When the train runs by the barcode reader the ID is transmitted to the operator module which outputs the ID via UART on a COM terminal. Errors will also be registered and output on the terminal as well as PWM changes. By using this composition, the majority of the thesis work is demonstrated in a representative way even if it is not yet shrunk to fit the train. In Figure 23 below is a more detailed description of the structural FPGA design, where radio communication, position determination and speed assignment (PWM) are separate modules.


– 42 –

Figure 23: Structure of the thesis demo FPGA implementation.

– 43 –

4 Evaluation and Practical Considerations

4.1 Radio

4.1.1 Problems Solved

When the first implementation was complete and the first test was performed, a few transmissions went through and the switch data was reflected on the LEDs but suddenly the updates ended. The SPI frequency was then decreased and 1 MHz turned out to be the fastest working reliable frequency. After extensive testing with both a separate module that executed one command at a time, which required a lot of patience to use, and a logic analyzer, an indication of the error was found. For some reason the SPI data output was corrupted at random occasions when communicating with the NRF. This was later found out to be caused by wrong data output from radio unit to the spi block. After examining the radio unit structure in detail, the error was identified to be a sampling problem of one incoming NRF IRQ signal. It was directly connected to a logic block. Since the IRQ was raised randomly at some point during the clock cycle, with some probability the updated logic output would not reach the registers in time. The obvious correction was to add a buffer register to the IRQ so that the value remained the same during the whole clock cycle. After the buffer was added, the design works without any further noticed errors at an SPI frequency of 5 MHz.

One conclusion drawn from this particular error is that input signals that are not clock synced should always be buffered. Another conclusion is to try and be as objective as you can when looking for errors. The problem may very well not be what it seems.

4.1.2 Unsolved Problems

For being able to demonstrate that the modules used radio for communicating between each other, putting one of the modules in a “faraday cage” was tested. The attempt failed, however, even if a substantial effort went into experimentation. Then jamming was tested instead, which did work to a certain extent. However, the highest rate of successful blocks of radio packets was about one third of the packets sent. This was just not good enough to be of value at a presentation so in the end it was just accepted that the radio was not going to be touched.

4.1.3 Evaluation

The radio performance has not been evaluated specifically in terms of error probability and transmission distance. After the error described above was corrected, the error rate has been so low that no error has been detected at all during normal operation. By normal operation I mean the transmission power has been sufficient for the used antenna. Some errors may have passed by, however, because the operation of for example the thesis demonstration (see section 3.5) is not dependent on successful transmissions every time. The retransmission function has even been deactivated during this, which makes me confident that the error probability will not be a problem in the final environment.


– 44 –

The number of supported trains is at least twelve. However, if unique addresses are required for all trains and messages need to be monitored constantly from all trains, the hardware supported maximum number of trains is six (with the ES functionality of the NRF). This can be circumvented, however, with an address field in the message protocol packet definition.

4.1.4 Application Notes

When the final environment is set up with the trains running on the track and the position of the MU in relation to the trains fixed, I would suggest that some kind of radio error measurement is performed. If the error rate is then too high, the number of automatic retransmissions may be adjusted to decrease the error rate. The reason to wait until the final setup with the measurement is that otherwise, some antenna may be changed or the track length may be increased to extend the transmission distance, all of which affects the radio communication and the parameters would have to be altered again. In order to reduce power consumption, the transmission power may be edited as well. This may also be a subject for testing in the final design. I have also experienced no radio transmission passing through at all at one point and the reason for this was the transmission power having been set too low. I became really worried and thought perhaps some component in the radio circuit was broken, so acknowledgement of this parameter is important.


4.2.1 Problems Solved

When running the thesis demonstration, it was more difficult than expected to set up the optical arrangement. The optical detector must read from a distance of 1 mm. It may accept down to 0.8 mm or up to 1.2, but that is not very easy to arrange when reading from the rail on a barcode under the train (see section 6 for motivation as opposed to reading the barcode on the track from the train). The cars also have a bigger air gap down to the track than the locomotive so the cars need some material attached on the underside on which the barcode is glued, so that it gets closer to the track. The reason for the exact distance requirement is that the laser diode scatters the light and if the distance is far, the white spaces become too big in relation to the black.

At one point errors were detected while reading at high speed (reading from the rail on the train). During normal speed everything worked as it should. This was caused by a lack of sampling rate recalculation/adjustment after changing the global clock frequency.

4.2.2 Evaluation

When the above requirements are met, the operation is stable. In the thesis demonstration, lap after lap may be travelled, and errors are


– 45 –

practically not occurring except when a bad barcode is presented which is fully according to specification. One previous error happened only when the train was running at full speed.

4.2.3 Application Notes

The specified calculation for the sampling rate must be performed if the clock frequency is decreased. Also if power consumption needs to be reduced, one way could be to fine tune this sampling rate, which will lead to reduced dynamic FPGA power consumption. Occasionally when the power supply to the laser driver circuit receives noise, the circuit shuts off and the diode stops emitting light. This can happen for example when the FPGA board is connected to the prototype board, which powers the laser. The other situation where I have encountered the problem is when the wheels of the model train, which supply the engine power, touch the casing of the laser diode which is grounded. In the datasheet of the laser driver [14] this is addressed and it suggests connecting a capacitor in order to suppress noise. This is the last resort, however, and if the root cause can be prevented it is preferable. I have not added the capacitor in my design because if the wheels don’t touch the laser casing and no extra component is connected to the power supply during operation, I have not experienced any problems with this.

4.2.4 Possible Improvements

During implementation there are often features you think about or are suggested to you by others but it is uncertain if they really are necessary and are therefore omitted. The time aspect also is a factor here. Here are some potential features for the position detection:

Shut down laser during inactive periods. Modulate laser to reduce power consumption. Focus laser to improve reading distance. Split sampling activity in the time domain.

When the trains stand still, there is obviously no need for the position detector to be active so if it should be shut down during this time, power could be saved. This may be taken even further by, from the trains perspective, keeping track of the address posts (barcodes) in the rail and only activating the barcode reader when a post is nearing to confirm its own assumption. In this way the laser would only need to emit light a fraction of the time it otherwise would and thereby only consume a fraction of the power.

The second point is also a power saver. If the laser were modulated, which means continuously switched on and off, and the detector was synced with the laser to only sample data when the laser was active, the same functionality would be achieved while the laser would be less active and consume less power. The time that the FPGA module samples the


– 46 –

detector value is only one out of = 1090 (see section 4.5.1),

so the potential is obviously there to save big amounts of power. The limiting factor here is the driver circuit which is said to be capable of “a

few kHz” [7] modulation. If this is more than kHz then it may

very well be possible. But if there is a lower limit in allowed duty cycle for the circuit, the gain in power reduction will be limited. My opinion also is that the detector response to the input of the laser driver should need to be studied by oscilloscope, in order to determine when to read the value in relation to when the laser is turned on.

When I looked in the ELFA catalogue after the laser diode had been ordered I noticed they had collimator lenses [15] for usage with laser diodes. If such a lens could be placed on the laser diode and potentially reduce the light scattering, the need for the exact distance between the barcode reader and code could potentially be reduced.

The last point is something that is a specific phenomenon where sampling occurs and the circuit is active during the sampling but then sleeps. What I suggest is that the flow charts of figures 14 & 15, which represent combinatorial logic, are split in the time domain into several clock steps. This is normally done to reduce the critical path of a synchronous system but in this case it may reduce block size of the with determination module because some steps are repetitive and could use the same combinatorial block. Specifically the function that determines width could be implemented in repetitive fashion instead of combinatorial. This would lead to reduction of decoders (see fig. 19) to only one.

4.3 Speed Assignment At first when the module was tested on the train, it ran very loudly. First of all, the locomotive did not start at all until about 50 % duty cycle. Secondly, it became quite warm after having run a few laps round the track and did not move at all even at 100 % duty after some more laps. The problem did not get fixed until a very late stage during the thesis when a webpage [16] gave the advice that every train no matter old or new, needs lubrication before being used. My supervisor Göran felt like tinkering with the train so he took it apart and applied oil and afterwards the performance was incomparably better. The train did not get warm at all and ran at very low speeds. Maximum speed was increased as well.

– 47 –

5 Summary and Conclusions The thesis arose from the need to control a model train wirelessly. The decision was made by RTE to implement an FPGA controller for the train that could handle the wireless communication as well as other features. I was assigned to achieve this. After half of the time dedicated to the thesis had been covered, the scope of the thesis was limited to finishing the three main features of the final product in the shape of VHDL modules and surrounding circuitry, not as a final, manufactured PCB for mounting on the train. The three VHDL modules, radio communication, position detection and speed assignment were put together in a demonstration setup.

The radio communication is stable and has enough bandwidth to interact with at least twelve trains, but with hardware address support the maximum is six. Position determination works but needs careful setup of the optics. Speed assignment may be disturbed by lack of lubrication of the locomotive but is otherwise fully functional.

Working with the thesis has provided me with valuable experiences in VHDL for FPGAs as well as deciding hardware components and deciding and adjusting surrounding circuitry. I have also learnt very much about the product development process and my eyes have been opened to a lot of things that can be realized in hardware.

– 49 –

6 References 1. Actel. Actel IGLOO Nano Datasheet. [Online] [Cited: 08 23, 2011.] http://www.actel.com/documents/IGLOO_DS.pdf.

2. —. Actel IGLOO Nano Starter Kit Datasheet. [Online] [Cited: 08 23, 2011.] http://www.actel.com/documents/IGLOO_nano_StarterKit_UG.pdf.

3. Nordic Semiconductor. nRF24L01+ Product Specification. [Online] [Cited: September 8, 2011.] http://www.nordicsemi.com/kor/content/download/2726/34069/file/nRF24L01P_Product_Specification_1_0.pdf.

4. Sparkfun. Transceiver nRF24L01+ Module with Chip Antenna. [Online] [Cited: 10 25, 2011.] http://www.sparkfun.com/products/691.

5. Avago Technology. HSDL-9100 Surface Mount Proximity Sensor. [Online] [Cited: 10 24, 2011.] http://www.avagotech.com/docs/AV02-2259EN.

6. Laser Components. AIGaInP Visible Laser Diode ADL-65055TL. [Online] [Cited: 10 24, 2011.] http://www.lasercomponents.com/fileadmin/user_upload/home/Datasheets/divers-vis/ari/655nm/adl-65055tl.pdf.

7. IC Haus. iC-WK iC-WKL 2.4 V CW Laser Diode Driver. [Online] [Cited: 10 24, 2011.] http://www.ichaus.de/upload/pdf/Wk_d1es.pdf.

8. Vishay Semiconductors. Ambient Light Sensor TEPT 5600. [Online] [Cited: 10 24, 2011.] http://www.vishay.com/docs/84768/tept5600.pdf.

9. —. Ambient Light Sensor TEMT6000X01. [Online] [Cited: 10 24, 2011.] http://www.vishay.com/docs/81579/temt6000.pdf.

10. InfiniiVision. InfiniiVision 3000 X-Series Oscilloscopes. [Online] [Cited: 10 24, 2011.] http://cp.literature.agilent.com/litweb/pdf/5990-6619EN.pdf.

11. Microchip. MCP6001/1R/1U/2/4 1 MHz Low-Power Op Am. [Online] [Cited: 10 24, 2011.] http://ww1.microchip.com/downloads/en/DeviceDoc/21733h.pdf.

12. ID Automation. Download Code 39 Barcode Fonts. [Online] [Cited: 10 24, 2011.] http://www.advancemeants.com/code39font/download.htm.

13. ROHM. 18 V max. H-bridge Drivers. [Online] [Cited: 10 25, 2011.] http://www.rohm.com/products/databook/motor/pdf/bd622x-e.pdf.

6 References

– 50 –

14. IC Haus. iC-WK iC-WKL 2.4 V CW Laser Diode Driver Application Notes. [Online] [Cited: 10 24, 2011.] http://www.ichaus.de/upload/pdf/WkAN_1911es.pdf.

15. ELFA. Lenses and optics for laser diodes. [Online] [Cited: 10 24, 2011.] https://www.elfa.se/elfa3~se_en/elfa/init.do?toc=20426.

16. Karp, D. A. Reviving Marklin Locomotives. [Online] [Cited: 10 24, 2011.] http://www.zscale.org/articles/revival.html.

– 51 –

Appendix

Demo Overall Electrical Layout

Created with Eagle CAD.

This is the thesis demo electrical layout. The NRF24L01P_EV circuits represent the evaluation circuits from Sparkfun that were used. The FPGA I/Os were connected to the FPGA dev board. 3,3 VDC is also taken from the dev board. C1, R5 and R6 were included from recommendations in the circuit application notes [17]. The T1 unit is not a BP103 but a TEMT6000X01.

– 52 –

Laser Driver iC-WK Connection Diagram

© IC Haus [7].

The power source was 5VDC. These component values were used together with ADL-65055TL:

R1=10 kohm C1=1000 nF C2=100 nF C3=100 nF C4=2.2 nF

http://www.rte.se/wookie/index.php/File:Laser_sched.png

model train intelligence unit - realtime embedded · realtime embedded (rte), the firm of...

Documents