Networking

From regional-training
(Redirected from IEEE 802.11)

CAN bus

CAN bus is a robust vehicle bus to allow minicontrollers to communicate with each other's applications without a host controller. It uses a message based protocol designed originally for multiplexed wiring within automobiles to save on copper. A device transmits a data frame sequentially in such a way that more than one device can transmit at the same time. The highest priority device can continue while the other devices back off. Frames are received by all devices, including the transmitting device.

All nodes are connected to each other through a physically conventional two wire bus. The wires are a twisted pair with a 120 Ω (nominal) characteristic impedance. ghpc This bus uses differential wired-AND signals. Two signals, CAN high (CANH) and CAN low (CANL) are either driven to a "dominant" state with CANH > CANL, or not driven and pulled by passive resistors to a "recessive" state with CANH ≤ CANL. A 0 data bit encodes a dominant state, while a 1 data bit encodes a recessive state, supporting a wired-AND convention, which gives nodes with lower ID numbers priority on the bus.

  • ISO 11898-2, also called high-speed CAN (bit speeds up to 1 Mbit/s on CAN, 5 Mbit/s on CAN-FD), uses a linear bus terminated at each end with 120 Ω resistors.
High-speed CAN signaling drives the CANH wire towards 3.5 V and the CANL wire towards 1.5 V when any device is transmitting a dominant (0), while if no device is transmitting a dominant, the terminating resistors passively return the two wires to the recessive (1) state with a nominal differential voltage of 0 V. (Receivers consider any differential voltage of less than 0.5 V to be recessive.) The dominant differential voltage is a nominal 2 V. The dominant common mode voltage (CANH+CANL)/2 must be within 1.5 to 3.5 V of common, while the recessive common mode voltage must be within ±12 of common.
  • ISO 11898-3, also called low-speed or fault-tolerant CAN (up to 125 kbit/s), uses a linear bus, star bus or multiple star buses connected by a linear bus and is terminated at each node by a fraction of the overall termination resistance. The overall termination resistance should be close to, but not less than, 100 Ω.

Low-speed fault-tolerant CAN signaling operates similarly to high-speed CAN, but with larger voltage swings. The dominant state is transmitted by driving CANH towards the device power supply voltage (5 V or 3.3 V), and CANL towards 0 V when transmitting a dominant (0), while the termination resistors pull the bus to a recessive state with CANH at 0 V and CANL at 5 V. This allows a simpler receiver which just considers the sign of CANH−CANL. Both wires must be able to handle −27 to +40 V without damage.

High-speed CAN uses a 120 Ω resistor at each end of a linear bus. Low-speed CAN uses resistors at each node. Other types of terminations may be used such as the Terminating Bias Circuit defined in ISO11783.[9]

Garmin now use the CAN bus in some of their Avionics products, migrating them away from High-speed databus, which is ethernet based.[1][2]

The exact voltages for a logical 0 or 1 depend on the physical layer used, but the basic principle of CAN requires that each node listen to the data on the CAN network including the transmitting node(s) itself (themselves). If a logical 1 is transmitted by all transmitting nodes at the same time, then a logical 1 is seen by all of the nodes, including both the transmitting node(s) and receiving node(s). If a logical 0 is transmitted by all transmitting node(s) at the same time, then a logical 0 is seen by all nodes. If a logical 0 is being transmitted by one or more nodes, and a logical 1 is being transmitted by one or more nodes, then a logical 0 is seen by all nodes including the node(s) transmitting the logical 1. When a node transmits a logical 1 but sees a logical 0, it realizes that there is a contention and it quits transmitting. By using this process, any node that transmits a logical 1 when another node transmits a logical 0 "drops out" or loses the arbitration. A node that loses arbitration re-queues its message for later transmission and the CAN frame bit-stream continues without error until only one node is left transmitting. This means that the node that transmits the first 1 loses arbitration.

Since the 11 (or 29 for CAN 2.0B) bit identifier is transmitted by all nodes at the start of the CAN frame, the node with the lowest identifier transmits more zeros at the start of the frame, and that is the node that wins the arbitration or has the highest priority.

There are only two lines and no clock, so data are transmitted asynchronously using a bit resynchronisation process. Synchronization starts with a hard synchronization on the first recessive to dominant transition after a period of bus idle (the start bit).

Resynchronization occurs on every recessive to dominant transition during the frame. The CAN controller expects the transition to occur at a multiple of the nominal bit time. If the transition does not occur at the exact time the controller expects it, the controller adjusts the nominal bit time accordingly.

What is the link between CAN, J1939, OBD2 and CANopen?

  • SAE J1939 is used in standard in-vehicle network for heavy-duty vehicles e.g. trucks and buses.
  • OBD2 on-board diagnostics is what mechanics use to identify car issues. OBD2 specifies Diagnostic Trouble Code (DTSc)
  • CANopen is used widely in ebedded control applications e.g. industrial automation. It is based on CAN data.
  • CAN FD with flexible data-rate being an extension of the classical CAN data link layer. It increases the payload from 8 to 64 bytes and allows for a higher data rate. It is increasingly being used in Electric Vehicles.

See also #NMEA.

CAN FD bus

The primary difference between the classical CAN (Controller Area Network) and CAN FD is the Flexible Data (FD). Using CAN FD, Electronic Control Unit (ECU)s can dynamically switch to different data-rate and with larger or smaller message sizes. Enhanced features in CAN FD includes the capability to dynamically select and switch to faster or slower data rate, as and when required, and to pack more data within the same CAN frame / message and transport it over the CAN BUS / network in less time.

Faster data speed and more data capacity enhancements results in several system operational advantages compared to the classic CAN. Using CAN FD, sensor and control data can be sent and received by the ECU (Electronic Control Unit) software much quicker. Commands issued by the executing ECU software reaches the output controller much faster. CAN FD is typically used in high performance ECUs of modern vehicles. A modern vehicle can have more than 70 ECUs that use CAN FD to exchange information over the CAN Bus when the engine is running or when the vehicle is moving.

In CAN FD, the frame/message ID uses the 29-bits format used in the Extended ID version of classic CAN (Standard ID is 11 bits long). The message payload size has been increased to 64 bytes of data in each CAN-frame / message, compared to only 8-bytes in the classic CAN frame. CAN FD can handle CAN frames/messages with 11-bit ID as well. A frame is a message transmitted as a sequence of binary bit-pattern. In CAN FD, the data rate (i.e. number of bits transmitted per second) is increased to be 5 times faster than the classic CAN (5Mbit/s for the data payload only, the arbitration bit rate is still limited to 1Mbit/s for compatibility).

CAN FD protocol specification includes some other enhancements as well, such as better detection of errors in the received CAN message and the executing software flexibility to dynamically select (from a list) and switch to faster or slower data rate transfer, as and when required. On the CAN FD BUS, some sensors may operate at slower data rate while others at faster data rate.

CAN BUS is a shared pair of wires onto which electronic sensors, controller units and ECUs are connected. CAN Bus is used for exchanging information between operational units periodically or on demand. The electrical condition and configuration of the CAN Bus, i.e. the total number of units connected, the length of the CAN Bus wires and other electro-magnetic factors determine the fastest data transfer rate possible on that CAN Bus. The CAN protocol (and by extension CAN FD) has an excellent collision resolution mechanism that depends on the propagation time of the signal and the network configuration (ring, bus or star), and to, a lesser extent, the number of units on the bus. Therefore, a physically long network may limit the data rate below the theoretical maximum.

CAN hardware

NMEA

NMEA
NMEA-2000

NMEA 0183

NMEA 0183 is a combined electrical and data specification for communication between marine electronics such as echo sounder, sonars, anemometer, gyrocompass, autopilot, GPS receivers and many other types of instruments. It has been defined by, and is controlled by, the National Marine Electronics Association. It replaces the earlier NMEA 0180 and NMEA 0182 standards. In leisure marine applications it is slowly being phased out in favor of the newer NMEA 2000 standard,though NMEA0183 remains the norm in commercial shipping.

The electrical standard that is used is EIA-422, although most hardware with NMEA-0183 outputs are also able to drive a single EIA-232 port. Although the standard calls for isolated inputs and outputs, there are various series of hardware that do not adhere to this requirement.

The NMEA 0183 standard uses a simple ASCII, serial communications protocol that defines how data are transmitted in a "sentence" from one "talker" to multiple "listeners" at a time. Through the use of intermediate expanders, a talker can have a unidirectional conversation with a nearly unlimited number of listeners, and using multiplexers, multiple sensors can talk to a single computer port.

At the application layer, the standard also defines the contents of each sentence (message) type, so that all listeners can parse messages accurately.

While NMEA0183 only defines an RS422 transport, there also exists a de facto standard in which the sentences from NMEA0183 are placed in UDP datagrams (one sentence per packet) and sent over an IP network.

The NMEA standard is proprietary and sells for at least US$2000 (except for members of the NMEA) as of September 2020. However, much of it has been reverse-engineered from public sources.

Equipment manufacturers also provide data list examples that their equipment issues. Many cheap GPS modules emit NMEA0183 ASCII messages through their serial port. (See Time server using raspberry_pi.)

NMEA 2000

NMEA 2000, abbreviated to NMEA2k or N2K and standardized as IEC 61162-3, is a plug-and-play communications standard used for connecting marine sensors and display units within ships and boats.

Communication runs at 250 kilobits-per-second and allows any sensor to talk to any display unit or other device compatible with NMEA 2000 protocols.

Electrically, NMEA 2000 is compatible with the Controller Area Network ("CAN Bus") used on road vehicles and fuel engines. The higher-level protocol format is based on SAE J1939, with specific messages for the marine environment.

Raymarine SeaTalk 2, Raymarine SeaTalkNG, Simrad Simnet, and Furuno CAN are rebranded implementations of NMEA 2000, though may use physical connectors different from the standardized DeviceNet Micro-C M12 5-pin screw connector, all of which are electrically compatible and can be directly connected.

The protocol is used to create a network of electronic devices—chiefly marine instruments—on a boat. Various instruments that meet the NMEA 2000 standard are connected to one central cable, known as a backbone, by snoods. The backbone powers each instrument and relays data among all of the instruments on the network. This allows one display unit to show many different types of information. It also allows the instruments to work together, since they share data.

NMEA 2000 is meant to be "plug and play" to allow devices made by different manufacturers to communicate with each other.

Examples of marine electronics devices to include in a network are GPS receivers, auto pilots, wind instruments, depth sounders, navigation instruments, engine instruments, and nautical chart plotters. The interconnectivity among instruments in the network allows, for example, the GPS receiver to correct the course that the autopilot is steering.

messages

bibliography

IEEE 10BASE-T1S

bandwidth and cabling comparison

[3]

10base-T1x hardware

bibliography

IEEE 802.11

IEEE 802.11 is part of the IEEE 802 set of local area network (LAN) technical standards, and specifies the set of media access control (MAC) and physical layer (PHY) protocols for implementing wireless local area network (WLAN) computer communication.

Wi-Fi or WiFi is a family of wireless network protocols, based on the IEEE 802.11 family of standards, which are commonly used for local area networking of devices and Internet access, allowing nearby digital devices to exchange data by radio waves (it was invented by the CSIRO who held the patents).

apache activeMQ

Apache ActiveMQ® is the most popular open source, multi-protocol, Java-based message broker. It supports industry standard protocols so users get the benefits of client choices across a broad range of languages and platforms. Connect from clients written in JavaScript, C, C++, Python, .Net, and more. Integrate your multi-platform applications using the ubiquitous AMQP protocol. Exchange messages between your web applications using STOMP over websockets. Manage your IoT devices using MQTT.

MQTT

The Message Queuing Telemetry Transport (MQTT) protocol is popular for IoT devices. It is the new way of distributed monitoring.[4][5]


[5]

It is a light weight client to server, publish and subscribe messaging protocol. Specifically designed to reduce transport overhead and code footprint on client devices such as sensors and actuators, and is quickly becoming the defacto standard communication protocol for IoT.

MQTT provides 3 quality of service levels:

  • QoS 0 - at most once
  • QoS 1 - at least once
  • QoS 2 - exactly one

MQTT can also be requested to retain a message for an address where the message will be resent when a client subscribes after the registration.

MQTT can also mark a message as a will message, which means it will be sent to the will topic if the specified address does not handle it.

benchmarks

This benchmark was based on mqtt-bench [6][7]

Note that mosquitto is written in C, aedes is written in JavaScript (node,js), hivemq is written in Java.

It is alleged that activeMQ MQTT connector performance is below that of aedes.

TODO: run the benchmark against an activemq-MQTT connector and see what throughput it gets. This will involve also running it against a reference aedes broker in the same machine running across the network.

clustering

Clustering can be used for High Availability. A simple means is to use:

  • reverse proxy load-balance e.g. HAProxy, and
  • multiples of your favourite broker e.g.:
    • mosquito
    • aedes
  • bridges between each broker.

You can also use the load balance pattern from nginx [8]

An alternative means is to use the Java HiveMQ Cluster.

MQ providers

IoT hardware

bibliography

modbus

Modbus started out as an ancient 1970's master/slave serial communication protocol used by PLC components over async RS-485:[13][14]. Slave devices are polled bny the master device to make changes and elicit responses. It is not a very well suited protcol for environmental measures as measurements must be requested. [15]


See #MQTT for a more modern facility favoured by IoT.

It is a simple message format [16] There are various incompatible protocols:

  • Modbus RTU (Remote Terminal Unit) — This is used in serial communication and makes use of a compact, binary representation of the data for protocol communication. The RTU format follows the commands/data with a cyclic redundancy check checksum as an error check mechanism to ensure the reliability of data. Modbus RTU is the most common implementation available for Modbus. A Modbus RTU message must be transmitted continuously without inter-character hesitations. Modbus messages are framed (separated) by idle (silent) periods.
  • Modbus ASCII — This is used in serial communication and makes use of ASCII characters for protocol communication. The ASCII format uses a longitudinal redundancy check checksum. Modbus ASCII messages are framed by leading colon (":") and trailing newline (CR/LF).
  • Modbus TCP/IP or Modbus TCP — This is a Modbus variant used for communications over TCP/IP networks, connecting over port 502.[8] It does not require a checksum calculation, as lower layers already provide checksum protection.
  • Modbus over TCP/IP or Modbus over TCP or Modbus RTU/IP — This is a Modbus variant that differs from Modbus TCP in that a checksum is included in the payload as with Modbus RTU.[17]
  • Modbus over UDP — Some have experimented with using Modbus over UDP on IP networks, which removes the overheads required for TCP.[9]
  • Modbus Plus (Modbus+, MB+ or MBP) — Modbus Plus is proprietary to Schneider Electric and unlike the other variants, it supports peer-to-peer communications between multiple clients.[10] It requires a dedicated co-processor to handle fast HDLC-like token rotation. It uses twisted pair at 1 Mbit/s and includes transformer isolation at each node, which makes it transition/edge-triggered instead of voltage/level-triggered. Special hardware is required to connect Modbus Plus to a computer, typically a card made for the ISA, PCI or PCMCIA bus.
  • Pemex Modbus — This is an extension of standard Modbus with support for historical and flow data. It was designed for the Pemex oil and gas company for use in process control and never gained widespread adoption.
  • Enron Modbus — This is another extension of standard Modbus developed by Enron Corporation with support for 32-bit integer and floating-point variables and historical and flow data. Data types are mapped using standard addresses.[11] The historical data serves to meet an American Petroleum Institute (API) industry standard for how data should be stored.[citation needed]

Data model and function calls are identical for the first 4 variants of protocols; only the encapsulation is different. However the variants are not interoperable, nor are the frame formats.

On Modbus RTU, Modbus ASCII and Modbus Plus (which are all RS-485 single cable multi-drop networks), only the node assigned as the Client may initiate a command. All other devices are servers and respond to requests and commands.

For the protocols using Ethernet such as Modbus TCP, any device can send out a Modbus command thus all can act as a client, although normally only one device acts as a Client.

There are many modems and gateways that support Modbus, as it is a very simple and often copied protocol. Some of them were specifically designed for this protocol. Different implementations use wireline, wireless communication, such as in the ISM band, and even Short Message Service (SMS) or General Packet Radio Service (GPRS). One of the more common designs of wireless networks makes use of mesh networking. Typical problems that designers have to overcome include high latency and timing issues.

The architecture is simple master / slave over a multi-drop bus, of multiple client and servers over an IP bus, where the server is the slave modbus device.

It seems that the Noti Fire Network using modbus sensors, which will require the control panel to act as a master and to poll all the devices on the multi-drop bus.

architecture

Since there are various physical interfaces, and supported protocols, it is a bit of a mishmash with only the underlying concepts of the register map providing consistency. Aprior knowledge of the sensors is required in order to understand the register layouts and what the corresponding data represents.

Every type of devices (PLC, HMI, Control Panel, Driver, Motion control, I/O Device...) can use MODBUS protocol to initiate a remote operation. The same communication can be done as well on serial line as on an Ethernet TCP/IP networks. Gateways allow a communication between several types of buses or network using the MODBUS protocol.

message

The modbus protocol defines a simple Protocol Data Unit (PDU) independent of the underlying communication layers. The mapping on some buses or network can introduce some additional fields.

The size of the modbus PDU is limited by the size constraint inherited from the first modbus implementation on Serial Line network (max. RS485 ADU = 256 bytes).

Therefore: MODBUS PDU for serial line communication = 256 - Server address (1 byte) - CRC (2 bytes) = 253 bytes. Thus:

RS232 / RS485 ADU = 253 bytes + Server address (1 byte) + CRC (2 bytes) = 256bytes.
TCP MODBUS ADU= 253 bytes + MBAP (7 bytes) = 260 bytes

There are three types of PDU:

  • request (mb_re_pdu) - with [1 byte] function code, [n bytes] data
  • response (mb_rsp_pdu) - with [1 btyte] function [n bytes response]
  • exception response (mb_excep_rsp_pdu) [1 byte] function code + 0x80, [1 byte] exception code

Data is encoded b-g-endian for address and data items e.g. for a 16 bit register value of 0x1234 the first byte sent is 0x12 and the second byte is 0x34.

A modbus message frame is formatted with an address, function, register map, and data. A checksum may be provided depending on the physical transport layer, though that may be omitted in the TCP protocol as checksums are inherent in that protocol

A modbus message

Where the types of registers referenced in Modbus devices include the following: • Coil (Discrete Output) • Discrete Input (or Status Input) • Input Register • Holding Register

modbus functions

The modbus device has a simple concept of register stores addressable via the modbus protocol functions.

data model

The modbus function codes have been extended over time

modbus functions code pools
modbus functions expansion

security

Modbus has introduced a security protocol [18] for use of MB-TCP.

variants

Johnson Controls uses modbus for their sensors/actuators and they use MB-TCP and have the concept of an NFN [19] which is implemented within their modbus gateway. The sensors being connected via multi-drop RS485 and the results of polling from the NFN are avaiable on the TCP/IP side of their gateway. I.e. their gateways are intelligent and obviate the need to poll sensors from the TCP/IP side, which may substantial reduced the burdeon on the integration. (I have not read the full manual yet though.)


The Modbus Gateway provides a communication link between networks that use the Modbus/TCP communication protocol and Fire Alarm Control Panels (FACPs) resident on an NFN network. The Noti_Fire-Network integration communicates with the Modbus Gateway through an HS-NCM-W/SF/MF or NCM-W/F network control module that is on that NFN network. The Modbus communication protocol is consistent with Modbus Application Protocol Specification V1.1b


The NFN lists a large number of device categories.

modbus hardware

RS-485

Traditionally modbus was originally wired with RS-485 multi-drop where signals are marked A- and B+, provided by the Idle or Mark states. An idle state is the open-collector non-driven state, while the Mark State is the driven logic 1 state, and the Space state is the driven logic 0 state. It is usual that the idle state differential voltage is about 0.3 Volts.

Modbus requires at least one master to poll the sesnors. See also CM4 for how this module is used for modbus controllers and IoT systems,

gateways

CM4 based

  • Standard 9500-CM4 cluster module with Compute Module 4 and chosen configuration:
    • I/O Controller with range of DI, DO, AI, 1-Wire, RS-232/485 and CAN interfaces
    • Communication Gateway with wired (1/2x Ethernet, Serial Ports) and wireless interfaces (LTE-cat.M1, 4G, 5G, LoRa, ZigBee, Z-Wave, Wireless M-Bus)
    • AI Gateway with 1x Coral from Google via PCIe M.2, introduced in December 2020: https://iiot-shop.com/product/ai-gateway/ or up to 4x Coral from Google via USB3.0
    • https://modberry.techbase.eu/#
  • clusberry https://linuxgizmos.com/rackmount-raspberry-pi-cm4-cluster-system-offers-modular-i-o/
    • NAS File Server with 2x/4x SSD SATA III and RAID support, managed with Nextcloud or ownCloud software
    • USB3.0 Hub for 5G communication, Modems, AI Cluster and peripherals
    • Gigabit LAN/WAN Router with additional 2.5GbE network card as an independent switch/router shielded from the mainboard cluster network
    • SuperCap / Power management module for backup power supply (supercapacitors / Li-Ion battery) and sleep mode management aided with ESP32-module
    • Additional expansion cards, with resources suited for the installation (DIO, AIO, Serial Ports and dedicated sensor cards, detailed below)

See also CM4 [22]

CM3 based

routerOS

knot

The newest addition to the MikroTik IoT product family – KNOT – is a truly universal device with exceptional connectivity options and protocol support. It is an IoT Gateway that uses Narrow Band and CAT-M technology. Because of the low cost, low bandwidth cellular connection, it is supported by countless mobile operators around the globe.

KNOT can monitor onboard GPIOs, convert Modbus protocol to TCP, and even forward Bluetooth packets to TCP/IP network via HTTPS and MQTT.

You can use the KNOT as a TCP bridge from wired Modbus sensors to send readings to a Modbus server. Yes, the KNOT brings wireless connectivity to wired sensors, such as electricity meters and relays.

It could be used as a backup connection for the Ethernet or as a management channel for your network. NB/CAT-M monthly plan is much cheaper than LTE. Why spend extra money on bandwidth you don’t need? For example, you can manage a KNOT-powered vending machine with temperature and liquid sensors with only a few megabytes per day!

KNOT features so many protocol support and connectivity options:

2.4 GHz wireless, Bluetooth, 2x 100 Mbps Ethernet ports with PoE-in and PoE-out, Micro-USB. Maximum convenience at the lowest cost!

other

PLC

pi kits

SPI

The Serial Peripheral Interface (SPI) is a synchronous serial communication interface specification used for short-distance communication, primarily in embedded systems. The interface was developed by Motorola in the mid-1980s and has become a de facto standard. Typical applications include Secure Digital cards and liquid crystal displays.

The MOSI protocol is an extension of the basic MSI cache coherency protocol. It adds the Owned state, which indicates that the current processor owns this block, and will service requests from other processors for the block.

I2C

I2C (Inter-Integrated Circuit, eye-squared-C), alternatively known as I2C or IIC, is a synchronous, multi-controller/multi-target (controller/target), packet switched, single-ended, serial communication bus invented in 1982 by Philips Semiconductors. It is widely used for attaching lower-speed peripheral ICs to processors and microcontrollers in short-distance, intra-board communication.

1-wire

1-Wire is a device communications bus designed by Dallas Semiconductor Corp that provides low-speed (16.3 kbit/s[23]) data, signaling, and power over a single Electrical conductor.

1-Wire is similar in concept to I2C, but with lower data rates and longer range. It is typically used to communicate with small inexpensive devices such as digital thermometers and weather instruments. A network of 1-Wire devices with an associated master device is called a MicroLAN. The protocol is also used in small electronic keys known as a Dallas key or iButton.

One distinctive feature of the bus is the possibility of using only two wires — data and ground. To accomplish this, 1-Wire devices include an 800pF capacitor to store charge and power the device during periods when the data line is active.

Usage example

1-Wire devices are available in different packages: integrated circuits, a TO-92-style transistor, and a portable form called an iButton or Dallas key which is a small stainless-steel package that resembles a Button cell. Manufacturers also produce devices more complex than a single component that use the 1-Wire bus to communicate.

1-Wire devices can fit in different places in a system. It might be one of many components on a circuit board within a product. It also might be a single component within a device such as a temperature probe. It could be attached to a device being monitored. Some laboratory systems connect to 1-Wire devices using cables with modular connectors or CAT-5 cable. In such systems, RJ11 (6P2C or 6P4C modular connector/plugs) commonly used for telephones) are popular.

Systems of sensors and actuators can be built by wiring together many 1-Wire components. Each 1-Wire component contains all of the logic needed to operate on the 1-Wire bus. Examples include temperature loggers, timers, voltage and current sensors, battery monitors, and memory. These can be connected to a PC using a bus converter. USB, RS-232 serial, and parallel port interfaces are popular solutions for connecting a MicroLan to the host PC. 1-Wire devices can also be interfaced directly to microcontrollers from various vendors.

iButtons are connected to 1-Wire bus systems by means of sockets with contacts that touch the "lid" and "base" of the canister. Alternatively, the connection can be semi-permanent with a socket into which the iButton clips, but from which it is easily removed.

The Java Ring is a ring-mounted iButton with a Java virtual machine that is compatible with the Java Card 2.0 specification. These were given to attendees of the 1998 JavaOne conference.[24] Each 1-Wire chip has a unique identifier code. This feature makes the chips, especially iButtons, suitable electronic keys. Some uses include locks, burglar alarms, computer systems, manufacturer-approved accessories and time clocks. iButtons have been used as Akbil (smart ticket)s for the public transport in Istanbul.

Power supplies

Apple MagSafe and MagSafe 2 connector-equipped power supplies, displays, and Mac laptops use the 1-Wire protocol to send and receive data to and from the connected Mac laptop, via the middle pin of the connector. Data include power supply model, wattage, and serial number; and laptop commands to send full power, and illuminate the red or green light-emitting diodes in the connector.[25]

Genuine Dell laptop power supplies use the 1-Wire protocol to send data via the third wire to the laptopcomputer about power, current and voltage ratings. The laptop will then refuse charging if the adapter does not meet requirements.[26]

Communication protocol

In any MicroLan, there is always one Master in overall charge, which may be a personal computer or a microcontroller. The master initiates activity on the bus, simplifying the avoidance of collisions on the bus. Protocols are built into the master's software to detect collisions. After a collision, the master retries the required communication.

A 1-Wire network is a single open drain wire with a single pull-up resistor. The pull-up resistor pulls the wire up to 3 or 5 volts. The master device and all the slaves each have a single open-drain connection to drive the wire, and a way to sense the state of the wire. Despite the "1-Wire" name, all devices must also have a second wire, a ground connection to permit a return current to flow through the data wire.[27][28] Communication occurs when a master or slave briefly pulls the bus low, i.e., connects the pull-up resistor to ground through its output MOSFET. The data wire is high when idle, and so it can also power a limited number of slave devices. Data rates of 16.3 kbit/s can be achieved. There is also an overdrive mode that speeds up the communication by a factor of 10.

A short 1-Wire bus can be driven from a single digital I/O pin on a microcontroller. A universal asynchronous receiver-transmitter (UART) can also be used.[29] Specific 1-Wire driver and bridge chips are available. USB "bridge" chips are also available. Bridge chips are particularly useful to drive cables longer than 100 m. Up to 300-meter twisted pairs, i.e., telephone cables, have been tested by the manufacturer. These extreme lengths require adjustments to the pull-up resistances from 5 to 1 kΩ.

The master starts a transmission with a reset pulse, which pulls the wire to 0 volts for at least 480 |µs. This resets every slave device on the bus. After that, any slave device, if present, shows that it exists with a "presence" pulse: it holds the bus low for at least 60 µs after the master releases the bus.

To send a binary number "1", the bus master sends a very brief (1–15 µs) low pulse. To send a binary number "0", the master sends a 60 µs low pulse. The falling (negative) edge of the pulse is used to start a monostable multivibrator in the slave device. The multivibrator in the slave reads the data line about 30 µs after the falling edge. The slave's internal timer is an inexpensive analog timer. It has analog tolerances that affect its timing accuracy. Therefore, the pulses are calculated to be within margins. Therefore, the "0" pulses have to be 60 µs long, and the "1" pulses can't be longer than 15 µs.

When receiving data, the master sends a 1–15-µs 0-volt pulse to start each bit. If the transmitting slave unit wants to send a "1", it does nothing, and the bus goes to the pulled-up voltage. If the transmitting slave wants to send a "0", it pulls the data line to ground for 60 µs.

The basic sequence is a reset pulse followed by an 8-bit command, and then data are sent or received in groups of 8 bits.

When a sequence of data is being transferred, errors can be detected with an 8-bit CRC (weak data protection).

Many devices can share the same bus. Each device on the bus has a 64-bit serial number, of which 8 bits are used as a checksum, thus allowing a "universe" of 256 (over 7.2 × 1016) unique device identities. The Least significant byte of the serial number is an 8-bit number that tells the type of the device. The most significant byte is a standard (for the 1-Wire bus) 8-bit CRC.[30]

There are several standard broadcast commands, as well as commands used to address a particular device. The master can send a selection command, then the address of a particular device. The next command is executed only by the addressed device.

The 1-Wire bus enumeration protocol, like other singulation protocols, is an algorithm the master uses to read the address of every device on the bus. Since the address includes the device type and a CRC, recovering the roster of addresses also produces a reliable inventory of the devices on the bus. To find the devices, the master broadcasts an enumeration command, and then an address, "listening" after each bit of an address. If a slave's address matches all the address bits sent so far, it returns a 0. The master uses this simple behavior to search systematically for valid sequences of address bits. The process is much faster than a brute force search of all possible 56-bit numbers, because as soon as an invalid bit is detected, all subsequent address bits are known to be invalid. The 56-bit address space is searched as a binary tree, allowing up to 75 devices to be found per second. The order in which device addresses are discovered by this enumeration protocol is deterministic and depends only on the device type and serial number. Bit-reversing these 56 bits yields the order of discovery for devices using Maxim's published algorithm (algorithm defined in Application Note 187[31]). The search algorithm can be implemented in an alternative form, initially searching paths with address bits equal to 1, rather than 0. In this case, inverting the 56 address bits and then reversing them yields the order of discovery.

The location of devices on the bus is sometimes significant. For these situations, a microcontroller can use several pins, or the manufacturer has a 1-Wire device that can switch the bus off or pass it on. Software can therefore explore sequential bus domains.[30]

Serial Bus

Serial Bus signal capabilities:

[32]

Example communication with a device

The following signals were generated by an FPGA, which was the master for the communication with a DS2432 (EEPROM) chip, and measured with a logic analyzer. A logic high on the 1-Wire output, means the output of the FPGA is in tri-state mode and the 1-Wire device can pull the bus low. A low means the FPGA pulls down the bus. The 1-Wire input is the measured bus signal. On input sample time high, the FPGA samples the input for detecting the device response and receiving bits.

The raspberry pi has an intrinsic 1-wire interface that can be enabled on GPIO4 [33]

RS-232

The Recommended Standard 232 (RS-232) is for an asynchronous serial protocol with separate TX and RX data lines that may operate half-duplex or full-duplex and some control signals for signalling, and some legacy signals such as Carrier Detect and Ring Detect that apply to telephone/modem signalling systems.

Signal Direction Connector pin
Name V.24 circuit Abbreviation Data terminal equipment
DTE
Data circuit-terminating equipment
DCE
DB-25 DE-9 TIA-574 Modified Modular Jack
MMJ
8P8C
RJ45
10P10C
RJ50
EIA
TIA-561
Cisco DCE Yost (DTE) Yost (DCE) Cyclades Digi International(ALTPIN option) National Instruments Cyclades Digi
Transmitted Data 103 TxD Out In 2 3 2 6 3 6 3 3 4 8 4 5
Received Data 104 RxD In Out 3 2 5 5 6 3 6 6 5 9 7 6
Data Terminal Ready 108/2 DTR Out In 20 4 1 3 2 7 2 2 8 7 3 9
Data Carrier Detect 109 DCD In Out 8 1 N/A 2 5 2 7 7 1 10 8 10
Data Set Ready 107 DSR In Out 6 6 6 1 7 2 N/A 8 N/A 5 9 2
Ring Indicator 125 RI In Out 22 9 N/A N/A N/A N/A N/A N/A 2 10 1
Request To Send 105 RTS Out In 4 7 N/A 8 1 8 1 1 2 4 2 3
Clear To Send 106 CTS In Out 5 8 N/A 7 8 1 8 5 7 3 6 8
Signal Ground 102 G Common 7 5 3, 4 4 4 4, 5 4, 5 4 6 6 5 7
Protective Ground 101 PG Common 1 N/A N/A N/A N/A N/A N/A N/A 3 N/A 1 4

The RS-232 standard defines the voltage levels that correspond to logical one and logical zero levels for the data transmission and the control signal lines. Valid signals are either in the range of +3 to +15 volts or the range −3 to −15 volts with respect to the "Common Ground" (GND) pin; consequently, the range between −3 to +3 volts is not a valid RS-232 level. For data transmission lines (TxD, RxD, and their secondary channel equivalents), logic one is represented as a negative voltage and the signal condition is called "mark". Logic zero is signaled with a positive voltage and the signal condition is termed "space". Control signals have the opposite polarity: the asserted or active state is positive voltage and the de-asserted or inactive state is negative voltage. Examples of control lines include request to send (RTS), clear to send (CTS), data terminal ready (DTR), and data set ready (DSR).

RS-232 logic and voltage levels
Data circuits Control circuits Voltage
0 (space) Asserted +3 to +15 V
1 (mark) Deasserted −15 to −3 V

Polarity:

  • RS-232 level signals are inverted by the line-driver ICs, so line polarity is TxD-, RxD-, CTS+, RTS+

Note that RS-232 default state is the mark and the start bit is asserted to positive > 3 volts, where data 1 is high and data 0 is negative, whereas the CTS, RTS are positive when asserted.

RS-232 line signal when a K-character
(0x4B or binary 0100 1011) is sent

You can tap into a half-duplex RS-232 circuit to monitor both ends, or use one connection and ground to tap into either end with a similar circuit referring to the tap circuit below. Please be aware this will only work on half-duplex circuits, full duplex will result in gobble-gook, in which case you can only use the resistor and must remove the diode. The resistor may be connected to either the TxD or RxD circuit depending on which half of the conversation you wish to intercept. When the DCE is working in echo mode (fairly normal for a modem and terminal connection), you only need to monitor the DCE TxD with one resistor and the GND connected. Note that the female DB9 on the left plugs into the DCE (modem) and that the resistor will then be connected to the DCE TxD, Normally DCE have male connectors, and so too does the DTE, requiring a rollover cable or null modem to interconnect them.

Cisco console serial cable wiring [34]


See also USB serial adapters.

RS-422

RS-422, also known as TIA/EIA-422, is a technical standard originated by the Electronic Industries Alliance that specifies electrical characteristics of a digital signaling circuit. It was intended to replace the older RS-232C standard with a standard that offered much higher speed, better immunity from noise, and longer cable lengths. RS-422 systems can transmit data at rates as high as 10 Mbit/s, or may be sent on cables as long as 1,200 meters (3,900 ft) at lower rates. It is closely related to RS-423, which uses the same signaling systems but on a different wiring arrangement.

SENT

SENT one-wire protocol for sensors using a mark/space transition to synchronize reception of data based on a clock tick that can range between 3uS to 90 uS, and with data transfer based on 4-bit (nibbles) variable length pulse that ascribes the bit value.

Data are encoded by the length of mark between space edge transitions.

SENT protocol includes:

  • 12 bit data comprised of four nibbles, with counter and 4-bit CRC - secure format
  • 12 bit data comprised of four nibbles and CRC - High Speed format
  • 8 bit slow channel formats
    • serial 8-bit data with 4-bit CRC
    • sequenced 8-bit serial with 4-bit CRC
  • 12-bit slow serial formats
    • serial data
    • 6-bit CRC and 12-bit data

Research and document these:

legacy serial GPS head

I found this GPS head and USB dongle in my father's spare parts supply.

Many USB serial dongles emulate the old RTL 16654 UART so I plugged it in to see what I got. Well the GPS has a flashing LED in it so power is getting to the GPS module I can see through the clear plastic. (If I could open it to discover what it was I might be able to find a 1-PPS output.)

When I plugged the USB dongle in it appeared at /dev/ttyUSB0:

[22105.219156] pl2303 ttyUSB0: error sending break = -19
[22105.219384] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[22105.219418] pl2303 1-1:1.0: device disconnected
[22106.492378] usb 1-1: new full-speed USB device number 19 using xhci_hcd
[22106.640970] usb 1-1: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 2.02
[22106.640976] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[22106.642851] pl2303 1-1:1.0: pl2303 converter detected
[22106.643822] usb 1-1: pl2303 converter now attached to ttyUSB0

This contained a PL2303 Serial port:

Bus 001 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port [35]

According to setserial -g /dev/ttypUSB0 it contains an RTL 16654 UART.

/dev/ttyUSB0, UART: 16654, Port: 0x0000, IRQ: 0

After mucking around with minicom and setserial trying to change the baud rate and failing each time, I used the original stty command. After some trial and error I discovered that the dongle's UART was running at 4800 baud, having set the serial port via this command:

stty -F /dev/ttyUSB0 4800

Then I was able to see the messages from the GPS unit:

$GPGGA,004805.000,3323.6549,S,15121.2257,E,0,00,,,M,,M,,*5C
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPGSV,1,1,01,05,74,216,*4B
$GPRMC,004805.000,V,3323.6549,S,15121.2257,E,,,290402,,*06
$GPGGA,004806.000,3323.6549,S,15121.2257,E,0,00,,,M,,M,,*5F
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
  • Now is is outputting 3 GPHSV records - which means it can see 3 satellites but the reported position has not changed yet
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPGSV,3,1,12,07,43,300,,05,62,314,,03,25,113,,09,52,294,*7A
$GPGSV,3,2,12,29,05,224,37,02,30,130,,30,61,138,,16,52,135,*7F
$GPGSV,3,3,12,15,20,119,,19,10,133,,18,55,154,,28,17,319,*73
$GPRMC,023610.999,V,3323.6549,S,15121.2257,E,,,290402,,*00
$GPGGA,023611.999,3323.6549,S,15121.2257,E,0,00,,,M,,M,,*5B
$GPGSA,A,1,,,,,,,,,,,,,,,*1E

Analysing the GPSA message the unit is reporting a location near Kulnura Gosford!

Since the unit has probably been turned off for years I will leave it running to see if it updates the Almanac and eventually moves to Canberra. Obviously my father got this dongle off someone who lived near the Gosford radio club.

It certainly is a very slow and insensitive GPS module - so it should probably be thrown into the bin. The USB to serial converter, on the other hand is probably OK to keep. The remote head contains a tiny patch antenna so I am not sure of its efficacy. It has been running for more than 10 minutes and is still stuck in Gosford.

Well I pulled the rubber bottom off and noticed it used torque screw heads and it contains a button magnet.

There is also a rechargable Li Battery MS321E https://www.farnell.com/datasheets/321180.pdf https://www.sii.co.jp/en/me/datasheets/ms-rechargeable/ms621fe/ which as measuring 1.4 Volts on charge and 0.57 off charge, so I removed it to identify and charge. It turns out that the battery is not accepting a charge, so I am doing a test run with it disconnected. It means the clock will be gone each time I start the board, but the board is still reporting the old position thus the battery might not be of much use.

(13 Dec 2021) Because I can I purchased one from ebay China for U$2.89 - free shipping. So now I have another project. I might be able to use it as a GPRS unit or something- lol. Now to put it back together so I don't lose the parts, and to place it in my project container.

The replacement battery arrived 05-Jan-22 and I have installed it and took the unit outside to operate on a USB battery bank because it was still reporting an address near Kulnura Gosford and had only acquired one satellite from my work-bench:

$GPRMC,225824.000,V,3323.6549,S,15121.2257,E,,,280402,,*05␍␊
$GPGSV,1,1,03,06,15,159,,22,18,046,,28,46,299,*44␍␊

I am going to leave the unit outside for about an hour to see if it can acquire enough satellites to obtain a new almanac, time and position.

GM-R700

This looks similar to the Evermore GM-R700 media:GM-R700.pdf [36]

futures

  • Note: there is currently NO raspberry pi board with a 10Base-T1S or 10Base-T1L interface.
    • 10Base-T1S and 10Base-T1L, multidrop ethernet, is en emergent technology that is promising to replace modbus/RS-485.

references

  1. Avionics Buses http://www.interfacebus.com/Design_Connector_Avionics.html
  2. GDL 59 HSDB http://static.garmin.com/pumac/GDL59DataLink_InstallationManual.pdf
  3. ECU
  4. MQTT https://mqtt.org/
  5. 5.0 5.1 5.2 mqtt bring it all together https://blog.opto22.com/optoblog/mqtt-bringing-it-all-together
  6. mqtt-bench https://github.com/takanorig/mqtt-bench
  7. mqtt benchmark https://muetsch.io/basic-benchmarks-of-5-different-mqtt-brokers.html
  8. nginx reverse proxy with failover https://askubuntu.com/questions/1114452/nginx-as-reverse-proxy-with-failover
  9. artemis migration guide https://activemq.apache.org/components/artemis/migration
  10. activemq interoperability https://activemq.apache.org/components/artemis/documentation/latest/protocols-interoperability.html
  11. artemis documentation https://activemq.apache.org/components/artemis/documentation/latest/mqtt.html
  12. groov-epic https://www.opto22.com/products/groov-epic-system
  13. modbus wikipedia https://en.wikipedia.org/wiki/Modbus
  14. modbus specification https://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf
  15. aduino modules and raspberry pi https://cooking-hacks.com/documentation/tutorials/modbus-module-shield-tutorial-for-arduino-raspberry-pi-intel-galileo/index.html
  16. modbus https://www.csimn.com/CSI_pages/Modbus101.html#mb101_40001
  17. MB-TCP https://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf
  18. modbus security protocol https://www.modbus.org/docs/MB-TCP-Security-v21_2018-07-24.pdf
  19. Johnson Controls modbus gateway https://cgproducts.johnsoncontrols.com/MET_PDF/54015.pdf
  20. JCI N2 https://docs.johnsoncontrols.com/bas/r/N2-Controller/11.0/Modernization-Guide-for-N2-Controllers-Metasys/Scenario-2-small-expansion
  21. JCI MetaSys http://www.chipkin.com/articles/wp-content/uploads/2013/07/FST_DFS_Metasys_N2.p
  22. CM4
  23. one wire https://www.maximintegrated.com/en/app-notes/index.mvp/id/74
  24. JavaRing http://www.javaworld.com/javaworld/jw-04-1998/jw-04-javadev.html?page=1 An introduction to the Java Ring, by Stephen M. Curry, JavaWorld.com, April 1st, 1998.
  25. eardown and exploration of Apple's Magsafe connector http://www.righto.com/2013/06/teardown-and-exploration-of-magsafe.html
  26. Hacking Dell Laptop Charger Identification http://hackaday.com/2014/03/03/hacking-dell-laptop-charger-identification/
  27. 1-Wire online tutorial. Thttp://www.maxim-ic.com/products/1-wire/flash/overview/index.cfm
  28. https://web.archive.org/web/20090502224036/http://www.maxim-ic.com/products/1-wire/flash/overview/index.cfm
  29. Using a UART to Implement a 1-Wire Bus Master http://www.maximintegrated.com/en/app-notes/index.mvp/id/214
  30. 30.0 30.1 iButton Overview http://www.maxim-ic.com/products/ibutton/ibuttons/standard.pdf
  31. Wire Search Algorithm (Application Note 187) https://www.maximintegrated.com/en/design/technical-documents/app-notes/1/187.html
  32. Serial Signal levels https://www.rs485.com/rs485spec.html
  33. raspberry pi 1-wire I/F https://www.raspberrypi-spy.co.uk/2018/02/enable-1-wire-interface-raspberry-pi/
  34. Cisco console serial port https://www.cisco.com/c/en/us/td/docs/security/asa/hw/maintenance/5585guide/5585Xhw/pinouts.pdf
  35. PL2303 https://components101.com/modules/pl2303-usb-to-ttl-serial-converter-module
  36. https://prodocs24.com/download-manual/680551/evermore-gm-r900-gps-23/

categories