Communication of information

Abstract

Procedure which includes: Communicating between a first device (12, 24) and a second device (11, 22) based on an edge-based pulse width modulation protocol, Inclusion of information in a checksum calculation by the first device (12, 24), wherein the information is not associated with the checksum (45, 56) and is communicated to the second device (11, 22), Using the information and data to be communicated to the second device (11, 22) for the checksum calculation in the first device (12, 24); Communicating the data and the checksum to the second device (11, 22); Receiving the data and the checksum (45, 56) in the second device (11, 22); and Determining in the second device (11, 22) whether the checksum is correct based on the received data and further information not communicated by the first device (12, 24) to the second device (11, 22), wherein the information comprises at least one of the following elements: an identification of the first device; a counter value generated at the first device; a measuring range used by the first device for a measurement or a configuration of the first device.

Description

BACKGROUND

[0001] Various protocols are used for communication between devices, for example, in automotive applications. One commonly used protocol is the SENT (Single Edge Nibble Transmission) protocol. This protocol can be used, for example, in applications where high-resolution data is transmitted, for example, from a sensor device to an electronic control unit (ECU).

[0002] The SPC protocol (short: PWM Code; where PWM stands for "pulse width modulation") is an extension of the SENT protocol and aims to increase the performance of a communication link while reducing system costs. To a certain extent, SPC allows bidirectional communication and is an example of an edge-based PWM protocol (edge-based pulse width modulation protocol). SPC can, for example, initiate synchronous half-duplex communication. A receiver (e.g., master) generates a master trigger pulse on a transmission line by pulling it low for a defined duration. The pulse width (which corresponds to the defined period of time) is measured by a transmitter (e.g., slave), such as a sensor, and a transmission, e.g., a SENT transmission, is only initiated if the pulse width is within defined limits.The SPC protocol allows a choice between different protocol modes. For example, a synchronous mode, a synchronous mode with range selection, or a synchronous transmission with identity selection, in which up to four sensors can be connected in parallel to an ECU, can be used. In the latter case, the pulse width of the trigger pulse mentioned above can define which sensor or other unit initiates a transmission. The length of the trigger pulse can, for example, specify the identity of a sensor or other slave device selected for transmission. The sensor or other unit can initiate the transmission with its own synchronization, which can overlap with the data pulses.

[0003] Traditionally, the SPC protocol does not provide feedback after a master query. If a master (e.g., an ECU) triggers a slave (e.g., a sensor) with an identity (e.g., via pulse width), the master may not be certain, based on a response alone, that the correct slave responded. Similar considerations apply to point-to-point transmission using area switching or other switching between sectors, zones, areas, or regions based on a master query. In some implementations, bits in a data frame have been used as feedback, using bandwidth that could otherwise be used for data transmission.

[0004] Under other circumstances, a master cannot be sure that the data being transmitted is up-to-date or that the same information is always being transmitted (which, apart from unsolicited transmission, is another possible failure mode of this general problem, also known as "babbling idiot").

[0005] EP 1 258 123 B1 concerns header compression in packet-based communication protocols such as IPv4 or IPv6. This involves using an error code that captures both a transport-layer header and payload data, and transmits it in the compressed header. A similar approach can be found in JONSSON, Lars-Erik [et al.]: Robust checksum-based header compression (ROCCO). June 15, 2000. URL: https: / / www.ietf.org / proceedings / 48 / ID / rohc-rtp-rocco-01.txt

[0006] CN 1 01 841 388 B discloses a transmission method which sends a CRC (cyclic redundancy check) as a checksum encapsulated in a security message.

[0007] US 2008 / 0 183 928 A discloses a communication protocol for an SPI bus using addressing.

[0008] US 5 646 996 A discloses a communication protocol in which, in the event of a synchronization loss, a checksum of an authentication code is generated and compared with a previously stored checksum.

[0009] US 2009 / 0 100 189 A1 discloses a communication system with time synchronization and mechanisms for regaining synchronization in case of loss.

[0010] US 2007 / 0 236 328 A1 discloses a method for generating a trinary code.

[0011] It is therefore a task to provide opportunities for feedback, if possible without the need for additional bandwidth. SHORT SUMMARY

[0012] A method according to claim 1, a system according to claim 10, and an apparatus according to claim 11 are provided. The subclaims define further embodiments of the method, apparatus, and system. The apparatus and system may be configured to perform the method, and / or the system may comprise the apparatus. Brief description of the drawings Fig. 1 is a simplified block diagram of a communication system according to some embodiments. Fig. 2 is a block diagram of a communication system according to one embodiment. Fig. 3 is a flowchart illustrating a method according to one embodiment. Fig. 4 is a flowchart illustrating signals and methods according to some embodiments. Fig. 5 is a diagram illustrating signals and methods according to some embodiments. Fig. 6 is a flowchart illustrating a method according to one embodiment. Fig. 7A and Fig. 7B illustrate signals and methods applicable in some embodiments. Fig. 8 shows signals and methods applicable in some embodiments. Detailed description

[0013] Various embodiments are described in detail below with reference to the accompanying drawings. The embodiments are to be understood as illustrative examples only and are not to be construed as limiting. Although embodiments may be described with a variety of features or elements, in other embodiments these features or elements may, for example, be omitted and / or replaced with alternative features or elements. In further embodiments, additional features or elements may be provided.

[0014] Any connections or couplings illustrated in the drawings or described herein may be implemented as direct connections or couplings, i.e., connections or couplings without intervening elements, or as indirect connections or couplings, i.e., connections or couplings with one or more intervening elements, as long as the general purpose of the connection or coupling, such as the transmission of a particular type of signal and / or the transmission of a particular type of information, is substantially ensured. Unless otherwise stated, connections or couplings may be wired connections or couplings or wireless connections or couplings.

[0015] Furthermore, features of different embodiments can be combined to form further embodiments.

[0016] In embodiments, an extension of the SPC protocol is proposed. However, these extensions can also be applied to other communication protocols, such as bidirectional edge-based PWM (pulse width modulation) communication protocols.

[0017] In some embodiments, bits conventionally used to transmit information such as feedback to a communication device such as a master may be used to transmit payload data, and information / feedback to the master or another communication device in some embodiments may, for example, be encoded in a checksum, i.e., used to calculate the checksum. A checksum, as used herein, may refer to information, e.g., redundant information, calculated based on other data, including the data to be transmitted. At a receiver, it may be possible to detect transmission errors based on the received data and the received checksum.An example of a checksum in this sense is a CRC (cyclic redundancy check) or any other redundant information that can be used to verify data integrity. Furthermore, in some embodiments, information can be transmitted to keep time setting information (also referred to as the date) up to date.

[0018] In some embodiments, encrypting feedback or other information in a checksum eliminates the need for separate transmission of feedback, such as an acknowledgment, to a communication device, such as a master.

[0019] In some embodiments, a method may be provided comprising: the communication between a slave and a master and the inclusion of a response from a slave to a master in a checksum.

[0020] In some embodiments, the feedback may include an identification of the slave.

[0021] In some embodiments, the feedback may include a counter value.

[0022] In some embodiments, the counter value may be a rolling counter value.

[0023] In some embodiments, the method may further comprise setting the counter value to a defined value after a transmission error is detected.

[0024] In some embodiments, setting the counter value to a defined value may include sending a dedicated trigger pulse from a master to at least one slave and setting the counter value in response to the trigger pulse.

[0025] In some embodiments, the dedicated trigger pulse may correspond to an unused identification.

[0026] In some embodiments, setting the counter value to a defined value may include the absence of a trigger signal from the master to at least one slave and setting the counter in response to detecting the absence of the trigger pulse.

[0027] In some embodiments, the method may further include, after a transmission error, trying different counter values ​​to determine a current counter value.

[0028] In some embodiments, the master may comprise a control unit.

[0029] In some embodiments, the slave may comprise a sensor.

[0030] In some embodiments, master and slave can communicate based on an SPC protocol.

[0031] In some embodiments, an apparatus may be provided that is suitable for carrying out at least one of the methods described above.

[0032] In some embodiments, the device may be a master device or a slave device.

[0033] In some embodiments, the methods described above may be implemented in a communication system.

[0034] In Fig. 1, a communication system 10 is shown according to one embodiment, including a receiver 11 and a transmitter 12. The receiver 11 is communicatively coupled to the transmitter 12 via one or more communication paths 13. In one embodiment, the receiver 11 is part of one integrated circuit chip, and the transmitter 12 is part of a different integrated circuit chip. In other embodiments, the receiver 11 and transmitter 12 may be part of the same integrated circuit chip. In one embodiment, the receiver 11 may be a control device, such as an ECU. In some embodiments, the transmitter 12 may be a sensor or other device. In some embodiments, the receiver 11 and the transmitter 12 may communicate using an SPC protocol or other edge-based bidirectional PWM protocol with the additions described below.An edge-based PWM protocol is a protocol in which the edges of signals modulated with respect to their pulse width are detected and information such as data to be transmitted is encoded, e.g., in pulse lengths of the signal with modulated pulse width. In other embodiments, other communication techniques can be used. In some embodiments, information to be sent, such as feedback from transmitter to receiver, is not sent in a data field, but only encrypted in a checksum, e.g., by a checksum calculation unit 14. According to the invention, such information comprises an identification (ID) of the transmitter, a counter value, measurement range settings, or a configuration of the transmitter, or any combination thereof, such as a counter value and an identification.To generate the checksum, the information is used as one of the input values ​​for an algorithm that generates the checksum. In addition to the information, further input values ​​for the algorithm include the data transmitted in a data field. In a checksum checking unit 15 of the receiver 11, the checksum can then, in some embodiments, be checked, for example, based on the data transmitted in the data field and further information present in the receiver 11. In some embodiments, the information used to calculate the checksum and the further information can be consistent information during error-free operation.

[0035] In other embodiments, as in Fig. 2, a receiver or other control device 22 (e.g., master) can communicate with a plurality of transmitters, such as sensors 24 and 26 in a system 20. The control device 22 in the illustrated embodiment is electrically coupled to each of the sensors 24 and 26 via a three-wire connection. In other embodiments, two-wire connections or any other connections may be used. The control device 22 can communicate with the sensors 24 and 26, for example, via an SPC protocol or another bidirectional edge-based PWM protocol, with the additions noted below. In the Fig. 2, the three-wire electrical coupling of the controller 22 to the first sensor 24 and the second sensor 26 includes a VDD voltage supply line 28, a data line 25, and a reference line, such as a ground line 27. In one embodiment, the system 20 may be part of the electrical system of a vehicle. In other embodiments, a different number of sensors or other components may be used. In one embodiment, the controller 22 communicates with the first sensor 24 and the second sensor 26 via open-drain / open-collector interfaces that include one or more pull-up resistors.For example, the system 20 includes a pull-up resistor 23 having a first end electrically coupled to a voltage supply line 28 and a second end electrically coupled to a data line 25, and the controller 22 includes an open-drain transistor 21 having one end of its drain-source path electrically coupled to the data line 25 and the other end electrically coupled to the ground line 27. The sensors 24 and 26 may include similar open-drain transistors or current sinks (not shown). The controller 22 and the first and second sensors 24 and 26 each share a single communication path that communicates via voltage signals on the data line 25, e.g., PWM signals.

[0036] For example, if communication occurs according to an SPC protocol, the controller 22 may transmit a request signal that is received by the first and second sensors 24 and 26 via the data line 25. The request signal may include a trigger signal and / or a sensor identification signal that selects one of the first and second sensors 24 and 26. In addition, the remainder of the request signal may include any other commands and / or data to be transmitted to the selected sensor. The trigger signal may, for example, be a pulse in which the controller 22 pulls the data line 25 to ground via the transistor 21, wherein the pulse duration indicates the sensor ID. In other embodiments, current pulses or other electrical quantities may be used to achieve the same function.

[0037] The first and second sensors 24 and 26 receive the request signal, including the trigger signal and the sensor identification signal. One of the first and second sensors 24 and 26 is selected via the sensor identification signal, which is encoded, for example, in a pulse width, pulse height, or otherwise, and the selected sensor transmits a response signal via the data line 28.

[0038] In Fig. 3 is a flowchart illustrating a method according to one embodiment. The method of Fig. 3 may be used in devices and systems such as those referred to in Fig. 1 and Fig. 2, but can also be carried out independently. The procedure from Fig. 3 can be achieved, for example, by appropriately designing or programming a transceiver of the transmitter 12 from Fig. 1 or the sensor 24 and / or 26 Fig. 2 be implemented.

[0039] At reference number 30, the method comprises Fig. 3 receiving a trigger pulse, e.g., according to an SPC communication protocol or another edge-based PWM communication protocol. The length of the trigger pulse can specify an ID of a slave in a master-slave system, e.g., an ID of slaves such as sensors 24, 26.

[0040] After receiving the trigger pulse, data is sent together with a checksum as in a cyclic redundancy check. At reference numeral 31, the method comprises Fig. 3 the inclusion of information, e.g., a response such as the ID mentioned above or a counter such as a running counter, in the calculation of the checksum. At reference numeral 32, data is transmitted together with the checksum, e.g., in a data frame. In embodiments, however, the information mentioned above is not included in the data frame but is used only for the checksum calculation. In general, in some embodiments, the information may be sent at some point in time, e.g., during initialization, but is not associated with the checksum; thus, for example, it is not sent in a data frame or other data unit relating to the checksum.

[0041] Concepts for enclosing information in a checksum as mentioned above will now be further discussed with reference to Fig. 4 and Fig. 5 explained. Fig. 4 and Fig. 5 show example signals along with elements illustrating the methods disclosed herein. The illustrated signals are merely non-limiting examples and may take other forms depending on the implementation signals in other embodiments. Signals from Fig. 4 show signals that may occur in an SPC system operating in a bus mode, for example, when a master device communicates with a plurality of slave devices, as described using Fig. 2 is illustrated as an example.

[0042] In Fig. 4 illustrates a trigger pulse 40 that can be sent from a master device to slave devices to indicate a slave device that should respond to the trigger pulse. A length of the trigger pulse can, for example, indicate an ID of the slave device that should respond. Fig. In Figure 4, a solid line illustrates an example of a relatively short trigger pulse 40, and dashed lines illustrate possible signal curves for longer trigger pulses. In embodiments, the ID may be a 2-bit number with the possible values ​​00, 01, 10, or 11, as shown in field 41 in Fig. 4. Each trigger pulse length can then be assigned to one of the possible IDs. In other embodiments, where the system is not operating in a bus mode but in a range mode, the pulse length of the trigger pulse can specify a range.

[0043] As indicated at reference numeral 43, the 2-bit ID value of the receiving slave device can be combined with two 0s (see 43 in Fig. 4) to form a 4-bit value.

[0044] After the trigger pulse, the slave device responds, as indicated by a curve section 44, with a synchronization pulse and various values ​​SCN, D1 to D3, and a rolling counter value (RC value), which are examples of transmitted data values, followed by a cyclic redundancy check CRC 45 as an example of a checksum. In an SPC system, the data values ​​and the CRC may be 4-bit values. In other embodiments, other bit widths may be used. The transmission by the slave device is terminated by a pause pulse, as in Fig. 4. A calculation of the cyclic redundancy check includes, as shown at reference numeral 46 in Fig. 4, not only the actually sent data values, ie SCN, D1, D2, D3 and the running counter RC, but also the ID written as a 4-bit value (43 from Fig. 4). In this way, the identity is not sent explicitly, but is part of the checksum.

[0045] The continuous counter RC can be a 4-bit value that is incremented by one bit each time the corresponding slave device sends data ending with a pause pulse. In the example from Fig. 4, the continuous counter can be a 2-bit value or a 4-bit value, for example. With a 2-bit value, after reaching a value of 11, the counting starts again at 00 on the next transmission, which is why the counter is called "continuous."

[0046] As described in more detail below, upon receiving data, the receiving entity, such as a master device, includes the expected identity (corresponding to the ID specified by the transmitted trigger pulse) in its own checksum calculation, e.g., a CRC calculation. If the checksum calculation does not match the received data (including the expected ID), the master device knows that the data was either not received correctly, the CRC was received incorrectly, or the ID is incorrect, which can happen, for example, if a "wrong" slave device responds to the trigger pulse (e.g., due to incorrect decoding of the trigger pulse, for example, assuming the trigger pulse indicates an ID of 01 when it should indicate an identity of 00, etc.).

[0047] In the example from Fig. 4, the ID is encrypted as feedback in the CRC calculation while the rolling counter is sent. In other embodiments, only the rolling counter can be sent without including the ID in the checksum. In further embodiments, the rolling counter can also be included in the checksum calculation. This is shown in Fig. 5.

[0048] A trigger pulse 50 from Fig. 5 and a field in which possible IDs 51 in Fig. 5 correspond to elements 40 and 41 respectively from Fig. 4 and will not be described in detail here. Furthermore, the signal sent by the slave, which begins with a synchronization pulse, corresponds to Fig. 5 the signal 44 from Fig. 4, except that no counting counter is explicitly sent and the CRC 56 is calculated taking into account a counting counter, as explained below. In Fig. 5, a 2-bit ID of the slave is combined with a rolling counter value 54 to form a combined rolling counter and ID value 53. As mentioned in some embodiments, the rolling counter may, for example, be a 2-bit value that counts 00, 01, 10, 11 and then starts again with 00, to give an example. Such a 2-bit value may be combined with an ID to form a 4-bit value, such as at reference numeral 53 in Fig. 5 (where, for example, the first two bits of the 4-bit value correspond to the counting counter and the last two bits to the ID, or vice versa). This combined counting counter and ID value is included in the cyclic redundancy check (CRC) calculation 55, which is then sent as indicated at reference numeral 56. In the example from Fig. 5, both the running counter and the ID are sent implicitly by encryption as part of the checksum, but not explicitly, while in the example from Fig. 4 only the ID is encrypted in the checksum and the running counter value is sent explicitly.

[0049] In general, the method of encrypting information or feedback in the checksum can be used for any type of information that is usually kept consistent between sender and receiver, i.e., where the receiver knows the expected value. The information can, for example, be determined independently at the sender and receiver according to a predefined scheme. An example of such a predetermined scheme would be a counter, such as a rolling counter (e.g., as mentioned above), which is incremented, for example, at regular intervals or upon certain events, such as sending or receiving data. In this case, in embodiments, it may not be necessary to send such information explicitly, but it may be sufficient to simply include the information in the checksum in order to detect cases where the information is no longer consistent.

[0050] It should be noted that in Fig. 4 and Fig. 5 the synchronization pulse of the receiver follows the trigger pulse. In other embodiments, the synchronization pulse of the slave device's response signal may overlap with the trigger pulse, which in Fig. 4 and Fig. 5 is not explicitly shown, but can be applied in some embodiments.

[0051] As already mentioned, on a receiving side, such as a master side, such as the receiver 11 Fig. 1 or the control device 22 from Fig. 2 When checking the checksum, such as the CRC, the receiver side uses the expected information (such as the expected ID and / or the expected running counter) in the received data to calculate its own checksum and evaluate whether the checksum is correct. A method according to a corresponding embodiment is described in Fig. 6. The embodiment of Fig. 6 can be used in the systems from Fig. 1 or Fig. 2, such as in the receiver 11 or the control device 22 of these systems.

[0052] At reference numeral 60, the method comprises Fig. 6 receiving data together with an associated checksum, such as a cyclic redundancy check (CRC). At reference numeral 61, the method of Fig. 6 determining whether the received checksum is correct, i.e., whether the received checksum matches a checksum calculated based on the received data in conjunction with expected information, such as an ID and / or a counter value, such as a rolling counter value. If the checksum is correct (YES at reference numeral 61), the method comprises processing the received data at reference numeral 63. If the received checksum is incorrect (NO at reference numeral 61), in one embodiment, a reset of one or more consistent values ​​may be indicated at reference numeral 62. One reason for an incorrect checksum may be that a rolling counter value is inconsistent between sender and receiver. In this case, if the checksum is incorrect, a reset of the rolling counter value may be performed.In this regard, it should be noted that in some embodiments, the master may not know the exact reason for the incorrect checksum, but only possible reasons (e.g., incorrect data transmission, inconsistent scrolling counters, incorrect ID, i.e., sending to the wrong receiver, etc.). If one of these possible reasons is a data inconsistency between sender and receiver, such as an inconsistency regarding the scrolling counters, a reset can be initiated.

[0053] In some embodiments, at reference numeral 62, the resetting noted may also indicate to the slave device(s) that the last transmitted data should be retransmitted because the transmission may have been erroneous.

[0054] It should be noted that in further embodiments, resetting the counter may not be necessary, e.g., in embodiments where the slave and master share a common time base and the counter is based on the time base.

[0055] Below are some possibilities for indicating a reset in an SPC system or other bidirectional edge-based PWM system with reference to Fig. 7 and Fig. 8 explained.

[0056] In some embodiments, to indicate a reset, a specific trigger pulse, such as a trigger pulse with a specific length, can be defined as a reset for all participants (e.g., slaves), such as all sensors coupled to a control device. Upon receipt of such a reset trigger pulse, information to be kept consistent can be set to a predefined value. A counter, such as a rolling counter, can be reset to a defined initial value, such as 00 for a 2-bit counter or 0000 for a 4-bit counter, although other values ​​can also be used. A specific trigger pulse length with an ID that is not used by any slave, for example, can be used as a type of reset ID. In other embodiments, a trigger pulse with a length greater than the lengths associated with an ID can be used.In some embodiments, using an ID as a reset ID may imply that one less participant can be used (because the ID is occupied by a reset ID), and / or in a range mode, one less range may be available. The use of a specific trigger pulse as a reset pulse is described in [1]. Fig. 7A and Fig. 7B illustrates.

[0057] Fig. Figure 7A shows a case where a length of a trigger pulse 70 is in a “timeout range”, ie, has a greater length than any length associated with an ID, as shown in a field 73 in Fig. 7A. As indicated by a field 72, the detection of such a trigger pulse causes a reset of a running counter 71 to a predefined value, such as a value of 00. For this reason, in Fig. 7A a trigger pulse that is longer than all IDs (four possible IDs in the case of field 73) is used to initiate a reset.

[0058] In the example from Fig. 7B, a trigger pulse 74 corresponding to a "reset ID," as indicated by a field 75, is used to trigger a reset. In this case, a length otherwise associated with an ID is used as a reset. A trigger pulse such as the trigger pulse 74 then causes, as indicated by field 76, a reset of the rolling counter 77, such as a reset to a predefined value. In the case of the embodiment of Fig. 7, an ID used as a reset ID cannot be used to identify a bus participant, which is why only one bus participant less can be used (only the IDs 00, 01, 10 are available in the example from field 75). In contrast, in the embodiment in Fig. 7A ensures that trigger pulses that are longer than all IDs (within the timeout range in field 73) can be reliably detected.

[0059] In another embodiment, a trigger pulse may be missing, which the slaves can recognize as a timeout, indicating a counter reset. This is in Fig. 8. In Fig. 8, the trigger pulses 80, 81 and 82 are shown. At reference numeral 83, a trigger pulse is missing, ie, no trigger pulse is sent within an expected window of a trigger pulse. As indicated by field 85, this can be interpreted as a reset, causing, for example, the resetting of a running counter 84 to a predefined value, such as a value of 0. It should be noted that in a system such as the system of Fig. 2 as in Fig. 7 and Fig. 8 shown reset can apply to all slave devices, such as both sensors 24, 26 in Fig. 2. In other words, the trigger pulse (or lack of the trigger pulse) indicating a reset is received by all slave devices, causing a global counter reset.

[0060] The above-mentioned reset approaches in embodiments have the property that incorrect timing results in a "safe fault"; if the reset is not detected, further faults are detected, and when the reset is detected (via timeout or a reset trigger pulse), the counter is reset to a defined value.

[0061] In an alternative approach, instead of sending a reset, a master device can test all counter values ​​(e.g., 00, 01, 10, 11 for a 2-bit counter) to find the correct counter value (which can be detected by a correct checksum), which can be used as the basis for the following transmission. In such an embodiment, handling an error on the master side can take more processing time (to test the counter values), while at the same time, no additional transmissions such as reset pulses or timeouts are required.

[0062] The embodiments described above are for illustrative purposes only and are not to be construed as limiting.

Claims

[1] Procedure comprising: Communicating between a first device (12, 24) and a second device (11, 22) based on an edge-based pulse width modulation protocol, Inclusion of information in a checksum calculation by the first device (12, 24), wherein the information is not associated with the checksum (45, 56) and is communicated to the second device (11, 22), Using the information and data to be communicated to the second device (11, 22) for the checksum calculation in the first device (12, 24); Communicating the data and the checksum to the second device (11, 22); Receiving the data and the checksum (45, 56) in the second device (11, 22); and Determining in the second device (11, 22) whether the checksum is correct based on the received data and further information not communicated by the first device (12, 24) to the second device (11, 22), wherein the information comprises at least one of the following elements: an identification of the first device; a counter value generated at the first device; a measuring range used by the first device for a measurement or a configuration of the first device. [2] The method of claim 1, further comprising at least one of the following steps: independently determining at least part of the information at the first device (12, 24) and at least part of the further information at the second device (11, 22) based on a predefined scheme applied by the first device (12, 24) and the second device (11, 22) to a data communication between the first device (12, 24) and the second device (11, 22); or Selecting at least a portion of the further information at the second device (11, 22) and communicating the at least a portion of the further information to the first device (12, 24), wherein at least a portion of the information corresponds to the at least a portion of the further information received at the first device (12, 24). [3] The method of claim 1 or 2, further comprising setting the counter value to a predefined value if the checksum received at the second device (11, 22) is determined by the second device to be invalid. [4] The method of claim 3, wherein setting the counter value to a defined value comprises sending a specific trigger pulse (40, 50) from the second device (11, 22) to the first device and setting the predefined counter value in response to receiving the specific trigger pulse (40, 50). [5] The method of claim 4, wherein the particular trigger pulse (40, 50) corresponds to an unused identification or a trigger pulse (40, 50) that is different from all used identification pulses or data pulses. [6] The method of claim 3, wherein setting the counter value to a defined value comprises omitting a particular trigger signal from the second device to the first device and setting the counter value to the predefined value in response to detecting the omission of the trigger pulse (40, 50). [7] The method of claim 1 or 2, further comprising trying different counter values ​​when the checksum received at the second device (11, 22) is determined by the second device (11, 22) to be invalid to determine a current counter value. [8] Method according to one of claims 1-7, wherein the second device (11, 22) comprises at least one master device or a control unit. [9] A method according to any one of claims 1-8, wherein the first device (12, 24) comprises a sensor. [10] System (10, 20) comprising: a first device (12, 24); a second device (11, 22); a communication path (13) between the first device (12, 24) and the second device (11, 22), wherein the system (10, 20) is arranged to carry out the method according to one of claims 1 to 9. [11] Device (11, 22) comprising: a checksum checking unit (15) for checking a checksum (45, 56) which is received together with data from a further device (12, 24) on the basis of an edge-based pulse width modulation protocol, wherein the checksum checking unit (15) is configured to check the checksum (45, 56) using the received data and to use information that the device (11, 22) has received via the data communication that is not associated with the checksum, wherein the checksum (45, 56) was calculated in the further device on the basis of at least one of the following elements: an identification of the further device (12, 24); a counter value generated by the further device; a measuring range used by the further device for a measurement or a configuration of the further device (12, 24), wherein the at least one of the elements is not received by the further device. [12] The apparatus of claim 11, wherein the information associated with the checksum comprises information contained in a data frame associated with the checksum.

Images