GPS GRANDMASTER WITH ARM EMBEDDED LINUX AND SNMP

Janani
19. January 2022 · Write a comment · Categories: ARM, Embedded System, Linux

The process of checking and verifying that the system clocks of computers are in sync with the time source is known as time synchronization. Nowadays, with a large number of contemporary computers spanning across locations and are performing time-critical operations, it is essential to have the clocks are synchronized and accurate with in the order of few tens of Nano-seconds. Some of the use cases for such a it might be necessary to time stamp event occurrences, co-ordination of media broadcasting, phase corrections in small cell base stations, power generation, air traffic control, timing stock trading. One of the easiest and proven mechanisms is the use the constellations of GPS/GNSS satellites and create a globally acceptable clock with high accuracy.

The key components of Time synchronization are Grandmaster, Master and slave.

The Grandmaster clock is the major time source in a multi-clock network, sending time downstream to other master clocks. It has exceptionally accurate timing synchronization.
There could be options Master clocks acting as distributor aligning Grandmaster and slave clocks.
A slave clock is a device or clock that synchronizes with the master clock but does not provide timing.

In this blog, with the advent of powerful embedded systems, we will discuss in detail about the GPS grandmaster and realizing it with a low-cost ARM based Embedded Linux system and the associated technologies.

GPS Grandmaster

As mentioned, Grandmaster clock is the primary source of clock in the network. Some of the major features expected of a Grandmaster includes:

Accuracy – This is the most important feature of Grandmaster, and it is determined by system design, timestamping accuracy, and many algorithms such as BMCA (Best Master Clock Algorithm) and processes that run in the system (e.g., filtering, servo, etc).
Scalability – It refers to the overall number of physical interfaces a Grandmaster can have as well as the number of clock instances it can handle.
Resiliency– It is the capacity to handle numerous timing inputs that act as alternate time sources.
Portability – Sometimes it is essential to have the Grandmaster mobile.

Today, every part of the world is practically covered with Global navigation satellite systems (GNSS)such as USA’s NAVSTAR Global Positioning System (GPS), Europe’s Galileo

Today, every part of the world is practically covered with Global navigation satellite systems (GNSS)such as USA’s NAVSTAR Global Positioning System (GPS), Europe’s Galileo, Russia’s Global’naya Navigatsionnaya Sputnikovaya Sistema (GLONASS), Indian Regional Navigation Satellite System (IRNSS), China’s BeiDou Navigation Satellite System. These satellites not only provide navigation data but also are time-transfer systems. Even a low-cost GPS receiver can provide accurate time information with stability very close to one part in ten to the fourteenth over one day (1ns/day).

Grandmasters can be created with such GNSS/GPS based receivers. A typical, GPS Grandmaster architecture looks like as shown in the below diagram

GPS Grandmaster - Block Diagram — GPS Grandmaster – Block Diagram

GPS-PPS Synchronization

Typically, GPS receivers provides the time of the day (ToD) information over a serial interface such as RS232/USB Serial as NMEA text. As this is not sufficient to synchronize, the GPS receivers provide a synchronization mechanism called pulse per second (PPS). This pulse, which has a rising edge synchronized with the GPS second, is of high accuracy, and can be used to discipline local clocks in order to keep them in sync with Universal Time (UT).

With a capable timing system inside the embedded Linux, it is possible to maintain the system clock with in few Nano-seconds of UT. With the system clock synchronized, now it has to be transferred to the slaves via a standard mechanism such as PTP or NTP.

NTP Server

One of the early and widely used Time Synchronization protocols is NTP – Network Time Protocol. The hierarchical architecture of NTP is divided into strata. Atomic clocks, like those in GNSS satellites, and GPS are examples of stratum 0 devices at the very top. Stratum 1 servers, also known as primary time servers, have a one-on-one direct link with a Stratum 0 clock, can achieve microsecond-level synchronization with Stratum 0 clocks, and can connect to other Stratum 1 servers for quick sanity checks and data backup. For tighter synchronization and increased accuracy, Stratum 2 servers can link to numerous primary time servers. NTP can support up to 15 strata, although each one reduces client synchronization by a little amount compared to Stratum 0.

Because NTP networks are software-based, all timestamp queries must wait for the local operating system, they have more latency and poorer accuracy. NTP provides a precise enough time resolution for most enterprises to settle conflicts quickly, but those requiring a much higher level of synchronization need to go for more precise PTP.

PTP Server

PTP, or Precision Time Protocol, is a network-based time synchronization standard that aims at nanosecond or even picosecond-level synchronization rather than millisecond-level synchronization of NTP.

Vis a vis NTP’s software-based approach, PTP timestamping is particularly precise because it uses hardware timestamping.

A total of four messages are exchanged between the master and slave in every PTP sequence:

The master’s first sync message to the slave
A slave to master sync message is sent as a follow-up
A message from the slave to the master requesting a postponement
The master sends a final delay response message to the slave

There are four different timestamps produced by this sequence:

T1 is the time when the master sends the first sync message
T2 is the time when the slave receives the first sync message
T3 is when the slave requests a delay
T4 is when the delay request is received by the master

During the delay response phase, the master delivers all four timestamps to the slave, and the slave can calculate the network latency between the master and slave in both directions.

IEEE 1588 enabled Ethernet PHY

As mentioned earlier, PTP needs a dedicated hardware time stamping mechanism. This is possible with single-chip Ethernet Physical Layer Transceiver (PHY) that are provided with IEEE 1588 based timestamping. While these are very similar to conventional Ethernet PHY’s, they have high precision timer that can timestamp transmission/receive packets in pico-second resolution. Some of the 1588 enabled PHY’s includes are Renesas UPD60611, Microchip KSZ8441, TI DP83869HM, Broadcom BCM81384 etc.

Embedded Linux based Grandmaster

Earlier days, it called for very powerful dedicated system to achieve time synchronization. Nowadays, even low-cost systems have enough power to act as Grandmasters. It is possible to achieve the high precision with some support from hardware such as IEEE1588 based timestamping. There is a plethora of open-source projects addressing the needs and it is quiet easy to create Embedded Linux based Grandmaster systems.

Some of the utilities that can be used are :

Ptp4l

Ptp4l is an IEEE-compliant implementation of the PTP. It implements both network master and slave clocks. For Grandmaster implementation, the master functionality can be used which will consider system clock as reference clock. Typical output of Ptp4l running as master on eth0 port is as follows:

ptp4l[1760.714]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES

ptp4l[1760.715]: selected local clock 0e8a76.fffe.6b8917 as best master

ptp4l[1760.715]: port 1 (eth0): assuming the grand master role

Phc2sys

Phc2sys is an application that synchronizes the system clock with a PTP hardware clock (PHC).

PHC follows PTP time in hardware time stamping mode, while the system clock follows UTC time. phc2sys maintains the time difference between these two clocks in nanoseconds

Ts2PHC

ts2phc can be used to synchronizes PTP Hardware Clocks (PHC) to external time stamp signals. A single source may be used to distribute time to one or more PHC devices.

In addition to above tools, testp2p utility can be used to perform various operations such as driving external signal at PPS, setting/getting PTP time and date etc.,

With the GPS/PPS inputs, it will be possible to synchronize the Realtime clock to globally accepted accurate time. The PTP server can serve this time to other slaves.

Running phc2sys will produce the following output :

CLOCK_REALTIME phc offset 1635162324159518479 s0 freq +0 delay 160546

CLOCK_REALTIME phc offset 1635162324159518096 s1 freq –375 delay 160606

CLOCK_REALTIME phc offset 0 s2 freq -375 delay 160606

CLOCK_REALTIME phc offset 8 s2 freq -367 delay 160545

CLOCK_REALTIME phc offset 12 s2 freq -368 delay 160540

CLOCK_REALTIME phc offset -25 s2 freq -365 delay 160541

…

As it can be seen the time offset between the PHC and the System clock is shown in the offset information. The System clock is synchronized if the offset is continuously less than 30 ns.

The offset is kept within a nanosecond range of +/-50 nanoseconds. The clock servo states are indicated by the s0, s1, and s2 strings:

s0- unlocked
s1- clock step
s2- locked

The clock will not be stepped until the Servo state is locked (s2) (slowly adjusted). The freq value is the frequency adjustment of the clock in parts per billion (ppb).

NTP servers too, synchronize the NTP client with server time (Stratum 1).

Other management protocols such as SNMP can be used to monitor various clocks in the system and their characteristics like accuracy, precision, resolution, current synchronization states etc.

About Embien

Embien Technologies is a high-tech services provider in the embedded systems segment catering to such niche requirements. We have helped customers achieve sub- 30 nanoseconds compliance for PTP and sub-100 microseconds accuracy for NTP with Linux based embedded systems. Our other credentials include GPS anti-jamming system development, MIR-DIAL- Mid-infrared differential absorption LIDAR systems etc.

Controller Area Network (CAN) – In Detail

Saravana Pandian Annamalai
16. November 2018 · Write a comment · Categories: ARM, Embedded Hardware, Embedded Software, Embedded System, Technology

In the last blog, we have covered the basics of CAN communication. Now, we will see about some of the advanced concepts involved such as Bit Stuffing, frame types, error types, Synchronization etc. We will also look into some of the non-standard extensions available in modern CAN controllers.

Generally, all CAN modules support the classical CAN protocol. It can receive and transmit both CAN base and the CAN extended frames. The transmission and reception of CAN FD frames is optional. Classical CAN Implementation do not support 29-bit identifiers. CAN 2.0B passive nodes were compliant with ISO 11898-1:2003, but it used very rarely. In this context, let us explore some of other concepts in detail.

Bit Stuffing

Bit Stuffing is used to ensure the synchronization of all nodes even when transmitting consecutive information with same value either 1 or 0.
During the transmission of message, a maximum of five consecutive bits may have the same polarity. In this case, the transmitter will insert the one additional bit of opposite polarity into the bit stream before transmitting the further bits. This will ensure that there is always some activity in the bus with in 6-bit intervals and hence avoid DC Voltage build up as well as being in sync with the transmitter.

Stuffing and De-stuffing

Stuffing and De-stuffing

On the receiving end, similarly the receiver also checks the number of bits of same polarity and removes the stuffed bits again from the bit stream in a process called de-stuffing.

CAN Frame Types

There are 5 types of frames in CAN protocol;

Data Frame (DF):

Carries Data from transmitting node to receiving node.

Remote Frame (RF):

Some times, a node might want to request some data from another which is made possible by Remote frame.
There are two differences between data and Remote frames.
RTR field of a data frame is dominant and RTR field of remote frame is recessive.
In data frame format data field is present, whereas in Remote frame format data field is absent.

The receiver will understand that transmitter is requesting some date and then prepares and sends the Data frame based on the protocol.

Error Frame (EF):

This type of frame is transmitted by any node to signal error.
The error frame consists of two different fields in CAN.
superposition of ERROR FLAGS (6–12 dominant/recessive bits)
ERROR DELIMITER (8 recessive bits).
There are two types of error flags:

Active Error Flag

When the Transmitting node transmitted six dominant bits, the error will be detected in network and the error sate called active error flag.

Passive Error Flag

When the Transmitting node transmitted six recessive bits, the error will be detected in network and the error sate called passive error flag.

Active and Passive Error Frames

Now let us see, how the CAN manages error states. In every CAN node, there are 2 error counters – Transmit Error Counter (TEC) and Receive Error Counter (REC). When the transmitter detects an error in the transmitted frame, it increments the TEC by 8. A receiver detecting an error will increment its REC by 1. On successful transmission/reception the error counters are reduced by 1.
Based on the error counts, the node behavior varies.

By default, the Active Error frame will be transmitted on the bus, when TEC and REC < 128. Thus, it will invalidate the frame globally.
But when 127 < TEC \ REC > 255, the passive Error frame will be transmitted on the bus, without affecting the bus traffic.
Finally, the node enters into the Bus off state, when TEC > 255. If node enters into the bus off state then no frames will be transmitted.

In any case, both transmitter and receiver reject the erroneous frames completely and do not process it any further.

Overload Frame (OF):

Overload frame contains two fields such as Overload flag and Overload Delimiter.
The over load frame will be generated, when the receiving node is overloaded – i.e. it is not able to detect and receive the incoming messages. The format is very similar to Error Frame but without the error counters incrementing. An Overload frame indicates that its transmitter require delay before receiving next data or remote frame and is mostly not used in modern CAN controllers.

Inter Frame Space (IFS):

Data frames and remote frames are separated from preceding frames and succeeding frame by a bit field called interframe space. It consists of three consecutive recessive bits. Following that, if a dominant bit is detected, it will be regarded as the “Start of frame” bit of the next frame.

Frame on CAN Bus

Frame on CAN BUS

Error Types

There are 5 types of error in CAN protocol.

Bit error:

Every node reads back, bit by bit from the bus during transmitting the message and then compares the transmitted bit value with received bit value. If bit received does not match with bit sent, then Bit error is said to be occurred.

Stuff error:

Set when more than five consecutive bits of same polarity are received in receiving node.

CRC error:

A transmitted always transmits the CRC value in the CRC field of CAN frame. The receiving node also calculates the CRC value using same formula and compares with received CRC value. If receiving node detects mismatch between calculated CRC values and received CRC value then it is called CRC error.

ACK error:

Occurs when no acknowledgment is sent by receiving node or no acknowledgment received in transmitting node.

Form error:

Set when fixed format fields in receive frame is violated. No dominant bits are allowed in CRC delimiter, ACK delimiter, EOF and IFS.

Synchronization and Re-synchronization

As there is no separate clock signal on the CAN bus, the node itself need to synchronize on the bus. For that reason, the underlying transmission format is NRZ-5 coding.
When the transmitting node sends CAN frame it consists the first bit of SOF (start of frame). All the receivers align themselves to this falling edge (recessive to dominant) after the period of bus idle. This mechanism is called hard synchronization.
After subsequent falling edges on the CAN frame are used to re-synchronize the nodes on bus and it is called soft synchronization. This resynchronization happens continuously at every falling edge (recessive to dominant transition) to ensure transmitting and receiving nodes stay in sync.

Additional functions

Some CAN protocol implementations offer optional functions that may or may not be a part of CAN specification. These include, for example, the single-shot transmission of data frames. This means that the automatic re-transmission in case of detected errors is disabled. This is useful for TTCAN add-ons and some tool applications.
Another option generally available is the bus-monitoring mode. The node can receive data and remote frames, but doesn’t acknowledge them and also doesn’t send error and overload flags. Nevertheless, these dominant bits are communicated internally in the CAN module.
In another optional restricted operation mode, the CAN module behaves equally, but it acknowledges received data and remote frames. The error counters are not incremented and decremented in this mode. If a node is the TTCAN time master, it must be able to transmit the time-reference message; other frames must not be transmitted.
For some applications, message time stamping is required. ISO 11898-1:2015 specifies that the optional time-stamp function features resolutions of 8-bit, 16-bit, or 32-bit. The time-base value is captured at the reference point of each data frame and it is readable after EOF (end-of-frame). Other (not standardized) optional functions include readable error counters, configurable warning limits, interrupt request generation, and arbitration lost capture.
If the CAN implementation allows changing the configuration of a node by software, the configuration data (e.g. bit-time configuration or operating mode) needs to be locked against changes while CAN communication is ongoing.

Armed with details of CAN communication, we will now attempt to understand general configuration of a CAN node for transmission and reception with examples from a real controller.

About Embien

Embien Technologies is a leading provider of product engineering services for the Automotive, Semi-conductor, Industrial, Consumer and Health Care segments. Working with OEMs in Industrial segments, we have developed numerous gateways, sensory modes on top of CAN network and protocols such as DeviceNet, CANOpen etc. Our Automotive experience enabled us develop Telematic units and In-vehicle Infotainment systems, Instrument clusters with CAN interfaces.

Geo Positioning System

Dhananjayan
26. April 2018 · Write a comment · Categories: Embedded System, Internet of Things, Technology

Geo positioning system or GPS has become more or less a norm for smart phones. Geo positioning system was first created for the navigation of defense vehicles in any part of world. But over the period of time, this system is being used in many other purposes outside defense and has proved itself to be a revolutionary technology in today’s world. Apart of the smartphone, most of the premium cars and commercial vehicle do have inbuilt GPS for fleet tracking, vehicle Telematics, and driver assistance.

Apart from such fleet navigation use cases, GPS are now being used for many applications such as locating nearby restaurants, hotels and gas stations and finds huge applications in tourism industry. Personal navigation devices also employ GPS technology.

Also most of the IoT/M2M applications use GPS modules. Some of them are as follows

Smart utility metering
Connected health and patient monitoring
Smart buildings
Security and video surveillance
Smart payment and PoS systems
Wearable devices etc

While the term GPS in general represents the technology, there are numerous systems being used to achieve this. In this blog, we will briefly describe about the various such Geo positioning systems and related concepts.

Geo Positioning System – Technology

Any geo positioning system uses about three to four satellites from more than a dozen of satellites orbiting in a group (satellite constellation) to provide autonomous geo-spatial positioning. These satellites transmit 1500 bits of data such as the satellite health, its position in space, propagation delay effects, constellation status, the time of information being sent, etc. This allows a small electronic receiver to determine its location in terms of latitude and longitude based on triangulation of the data obtained from at least three satellites. With four or more satellites, the receiver can also determine the 3D position, i.e. Latitude, longitude and altitude. In addition, a GPS receiver can provide information about the speed and direction.

Anyone with the GPS receiver can access the system. Since it is an open source and providing almost accurate 3D position, navigation and timing 24 hours a day, 7 days a week, all over the world, it is used in numerous applications even in GIS data collection, mapping and surveying.

Geo Positioning System – Types

At present there are many options available for geo positioning system each of them owned and operated by countries such as US, Russia, European Union, China, etc. They are as follows

NAVSTART GPS – GPS, Global Positioning System is a one among the various satellite navigation system designed and operated by the U.S. Department of defense. Official name of GPS is Navigational Satellite Timing and Ranging Global Positioning System (NAVSTAR GPS).

GLONASS – Global Orbiting Navigation Satellite System, GLONASS developed by Russian, is an alternative to GPS and is the second global navigational system in operation providing global coverage with comparable precision. A GLONASS satellite design has various upgraded versions and the latest is GLONASS-K2 which is expected to operate in early 2018.

Galelio – Galelio is created by European Union with the aim to provide an independent high precision positioning system for European nations.

BeiDou – BieDuo Navigation Satellite System (BDS) is a Chinese satellite navigation system consisting of two separate satellite constellations BeiDuo-1 and BeiDuo-2. BeiDuo-1 is decommissioned and BeiDuo-2 also known as COMPASS offering services to customers in the Asia-Pacific region with a partial constellation of 10 satellites in orbit.

IRNSS – Indian Regional Navigation Satellite System also known as NAVIC (Navigation with Indian Constellation) is a regional satellite navigation system covering the Indian region extending 1500Km. This constellation is already in orbit and expected to operate in early 2018.

Satellite Based Augmentation System (SBAS)

All the above systems are autonomous and governed by the respective countries. Other than autonomous systems, other regional augmented systems are available that run with the aid of other autonomous satellites. These augmentation systems will provide reference signals (Signal in Space- SIS) via satellites to the receivers including correction information with the objective of increasing the accuracy of the position. In addition to the accuracy they also help to maintain the reliability and availability of the navigation system. The whole system is known as SBAS (Satellite Based Augmentation System) and satellite providing the SIS signal are known as SBAS GEO satellites. Some of them are as follows,

GAGAN – GPS-Aided Geo Augmented Navigation – It is the implementation of SBAS by Indian government. It supports pilots to navigate in the Indian airspace by an accuracy of 3m.

QZSS – Quasi Zenith Satellite System is a project governed by Japanese government and operated in order to receive the US operated GPS in the Asia-Oceania regions with Japan as a primary focus.

Other commonly available SBASs are WAAS (US), EGNOS (EU) and MSAS (Japan).

GNSS

The above mentioned satellite systems such as global, regional and augmented systems are integrated together to form Global Navigation Satellite System, GNSS. It is a standard term for satellite navigation systems providing autonomous geo spatial positioning with global coverage. It is a satellite system that is used to pinpoint the geographic location of a user’s receiver anywhere in the world. Three GNSS systems are currently in operation: the United States’ Global Positioning System (GPS), the Russian Federation’s Global Orbiting Navigation Satellite System (GLONASS) and the Europe’s Galileo.

Most degrading factor of a receiver, i.e. Line of Sight degradation can be solved with the GNSS system due to its accessibility to multiple satellites and if one satellite system fails, GNSS receivers can pick up signals from other system.

Navigation Messages

Any satellite in the constellation will transmit a detailed set of information such as each satellite position, network to receiver called the navigation messages. Following are available in the navigation message,

Date and time together with the satellite status and an indication of its health

Almanac data – Contains coarse orbit and status information of all the satellites in the constellation. It allows the GPS receiver to predict which satellites are overhead, shortening acquisition time. Almanac data can be received from any of the satellites. The receiver must have a continuous fix for approximately 15 minutes to receive a complete almanac data. Once downloaded it is stored in the non volatile memory.

Ephemeris data – Contains precision correction to the almanac data necessary for the receiver to calculate the position of the satellite. It is continuously updated every 2 hours and so ephemeris data of a deactivated receiver will become stale after 3 to 6 hours.

Time-To-First-Fix (TTFF)

For a receiver to get a fix, it needs a valid almanac, initial location, time and ephemeris data. When a receiver is switched ON, it requires some time delay for the first fix. This delay depends on how long since the stored data’s being used. The time delay is commonly termed as Time To Fist Fix, TTFF and it is one of the main factor for receiver selection.

About Embien

Embien Technologies is a leading provider of embedded design services for the Automotive, Semi-conductor, Industrial, Consumer and Health Care segments. Embien has successfully designed and developed many products with GPS for various domains such as Wrist wearable based tracker device for healthcare, Vehicle Telematics device for automotive, Data acquisition/logger devices for industry etc.