Sensor methods, systems, and devices for use in material based characterizations

Abstract

Devices and apparatuses are provided for improved sensor implementation. An example sensor device includes a housing defining a top portion, a bottom portion opposite the top portion, and an interior therebetween. The interior of the housing supports various sensor circuitry. The sensor device further includes an anti-rotation element attached to the housing, such as to and end of the top portion of the housing. The anti-rotation element is configured to prevent rotation of the housing relative to a support structure, such as a rebar mesh when the sensing device is embedded in a cementitious mixture.

Description

SENSOR METHODS, SYSTEMS, AND DEVICES FOR USE IN MATERIAL BASEDCHARACTERIZATIONSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present international application claims priority to U.S. Provisional Patent Application No. 63 / 670,047, Tiled July 11, 2024, the entire contents of which application is incorporated by reference in its entirety.TECHNOLOGICAL FIELD

[0002] Example embodiments of the present disclosure relate generally to sensor devices and, more particularly, to sensor methods, systems, and devices for use in material based characterizations.BACKGROUND

[0003] Sensors, sensing devices, and / or the like are implemented in a variety of industries to generate data indicative of the physical phenomenon associated with the particular implementation. In building material related implementations, such as the construction of structures (e.g., foundations, substructures, superstructures, tunneling, etc.), sensor devices may be used to generate data that is associated with the progression of the structure’s completion, such as data associated with the curing process of a cementitious mixture that forms the structure. Applicant has identified a number of deficiencies and problems associated with sensor devices. Through applied effort, ingenuity, and innovation, many of these identified problems have been solved by developing solutions that are included in embodiments of the present disclosure, many examples of which are described in detail herein.BRIEF SUMMARY

[0004] Apparatuses, systems, and methods are provided for sensor devices with improved housings. With reference to a sensor device, the sensor device may include a housing defining a top portion a bottom portion opposite the top portion and an interior therebetween. The sensor device may further include an anti-rotation element attached to the housing and configured to prevent rotation of the housing relative to a support structure.

[0005] In some embodiments, the anti-rotation element may be attached to the top portion of the housing.

[0006] In some embodiments, the anti-rotation element may be attached to a first end of the housing.

[0007] In some further embodiments, a second end of the housing opposite the first end of the housing may define an opening configured to receive a sensing element disposed therein.

[0008] In some embodiments, the anti-rotation element may define a pair of extensions that extend from the housing and configured to engage at least a portion of the support structure.

[0009] In some further embodiments, the anti-rotation element may be configured to prevent rotation of the housing about a longitudinal axis extending along a length of the housing.

[0010] In some embodiments, the anti-rotation element may define a proximal portion attached to the housing and substantially perpendicular to a length of the housing and a distal portion attached to the proximal portion and substantially parallel to the length of the housing.

[0011] In some embodiment, the anti-rotation element may be configured to be disposed proximate an intersection between a pair of support members forming the support structure.

[0012] In some embodiments, the bottom portion of the housing may define a channel configured to receive a portion of the support structure therein.

[0013] In some further embodiments, the channel may be disposed along a length of the bottom support member.

[0014] In some embodiments, the anti-rotation element may define one or more openings.

[0015] In some further embodiments, the one or more openings are configured to receive strapping elements therein.

[0016] In some embodiments, the sensor device may further include sensor circuitry positioned in the interior of the housing.

[0017] In some further embodiments, the sensor circuitry may include a printed circuit board F(PCB), a processor supported by the PCB; and one or more antennas supported by the PCB and communicably coupled with the processor.

[0018] In some further embodiments, the one or more antennas may be positioned closer to the top portion of the housing than the bottom portion of the housing.

[0019] In some further embodiments, the one or more antennas may include a first antenna configured to transmit data via a first communication protocol and a second antenna configured to transmit data via a second communication protocol.

[0020] In some embodiments, the top portion of the housing may be removably attached to the bottom portion of the housing.

[0021] In some embodiments, the housing may be watertight.

[0022] In any embodiment, the sensor device may be configured to be disposed in cementitious mixture.

[0023] In any embodiment, the support structure may include a rebar mesh.

[0024] Apparatuses, systems, and methods are provided for sensor devices with pluralities of antennas and associate communication interfaces. An example sensor device may include a printed circuit board (PCB), a processor supported by the PCB, a first antenna supported by the PCB and communicably coupled with the processor, and a second antenna supported by the PCB and communicably coupled with the processor

[0025] In some embodiments, the first antenna may be configured to transmit data via a first communication protocol and the second antenna may be configured to transmit data via a second communication protocol.

[0026] In some further embodiments, the first communication protocol may be different from the second communication protocol.

[0027] In some embodiments, the sensor device may include a battery supported by the PCB and configured to supply power to the processor, the first antenna, and the second antenna.

[0028] In such an embodiment, a positioning of the first antenna and / or a positioning of the second antenna may be configured to minimize interference between the battery and the first antenna and / or between the battery and the second antenna.

[0029] In some embodiments, a positioning of the first antenna and / or a positioning of the second antenna may be configured to minimize interference between the first antenna and the second antenna.

[0030] In some embodiments, an emission direction of the first antenna may be parallel with respect to an emission direction of the second antenna.

[0031] In other embodiments, an emission direction of the first antenna may be perpendicular with respect to an emission direction of the second antenna.

[0032] In some embodiments, in operation in which the sensor device is disposed proximate a support structure, a positioning of the first antenna and / or a positioning of the second antenna may be configured to minimize interference between the support structure and the first antenna and / or between the support structure and the second antenna.

[0033] In some embodiments, the first antenna may be disposed along a lateral edge of the PCB

[0034] In some embodiments, the second antenna may be disposed along a longitudinal edge of the PCB.

[0035] In some embodiments, the sensor device further includes a housing supporting the PCB. the processor, the first antenna, and the second antenna therein.

[0036] In some further embodiments, the housing may define a top portion, a bottom portion opposite the top portion and an interior therebetween.

[0037] In some further embodiments, the first antenna and the second antenna may be positioned closer to the top portion of the housing than the bottom portion of the housing.

[0038] In some embodiments, the housing may be configured to be disposed proximate an intersection betw een a pair of support members forming the support structure

[0039] In some embodiments, the first antenna and / or the second antenna may be disposed distal to an end of the housing proximate the intersection of the pair of support members.

[0040] In some embodiments, the sensor device may further include a platform / spacer supporting at least one of the first antenna or the second antenna on the PCB.

[0041] In some embodiments, at least one of the first antenna or the second antenna may be disposed substantially perpendicular with respect to a top surface of the PCB.

[0042] Apparatuses, systems, and methods are provided for selective operation of sensor devices with pluralities of antennas and associate communication interfaces. An example method for sensor device operation may initializing a sensor device. The sensor device may include a printed circuit board (PCB), a processor supported by the PCB, a power supply (e.g., battery) coupled with the processor, a sensing element coupled with the power supply and the processor and configured to generate first data associated with a material, and a plurality of communication interfaces communicably coupled with at least the sensing element. The method may further include selectively operating the plurality7of communication interfaces, such that one or more signals are transmitted and / or receive via the plurality of communication interfaces.

[0043] In some embodiments, the plurality of communication interfaces may include a first communication interface configured to transmit data via a first communication protocol and a second communication interface configured to transmit data via a second

[0044] In some further embodiments, the first communication protocol may be different from the second communication protocol.

[0045] In some embodiments, operations of the second communication interface may be responsive to operation of the first communication interface

[0046] In some embodiments, initialization of the second communication interface may be responsive to an instruction associated with the first communication interface

[0047] In some embodiments, operation of the second communication interface may be responsive to connection status associated with the first communication interface.

[0048] In some embodiments, operation of the second communication interface may be responsive to connection status associated with the second communication interface.

[0049] In some embodiments, operation of the first communication interface may be responsive to connection status associated with the second communication interface.

[0050] In some embodiments, the first wireless communication interface may include a first antenna supported by the PCB and the second wireless communication interface may include a second antenna supported by the PCB.

[0051] In some embodiments, the first wireless communication interface and the second wireless communication interface may be communicably coupled to a first antenna, which is tuned to support both the first and the second communication protocol.

[0052] In some embodiments, the sensor device may include a third communication interface. In some further embodiments, the third communication interface may be a wired connection to one or more sensor elements.

[0053] The above summary is provided merely for purposes of summarizing some example embodiments to provide a basic understanding of some aspects of the present disclosure. Accordingly, it will be appreciated that the above-described embodiments are merely examples and should not be construed to narrow the scope or spirit of the disclosure in any way. It will be appreciated that the scope of the present disclosure encompasses many potential embodiments in addition to those here summanzed, some of which will be further described below.BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Having described certain example embodiments of the present disclosure in general terms above, reference will now be made to the accompanying drawings. The components illustrated in the figures may or may not be present in certain embodiments described herein. Some embodiments may include few er (or more) components than those shown in the figures.

[0055] FIGS. 1A-1E illustrate an example sensor device implementation in accordance with some embodiments described herein;

[0056] FIGS. 2A-2C illustrate the example sensor device of FIG. 1 with an example sensing element in accordance with some embodiments described herein;

[0057] FIGS. 3A-3E illustrate the example sensor device of FIGS. 1-2C in accordance with some embodiments described herein;

[0058] FIGS. 4A-4E illustrate an example top portion of the example sensor device of FIGS. 1-3E in accordance with some embodiments described herein;

[0059] FIGS. 5A-5D illustrate an example bottom portion of the example sensor device of FIGS. 1-3E in accordance with some embodiments described herein;

[0060] FIG. 6 illustrates an exploded view of the example sensor device of FIGS. 1-3E in accordance with some embodiments described herein;

[0061] FIGS. 7A-7D illustrate example sensing element(s) in accordance with some embodiments described herein:

[0062] FIGS. 8A-8D illustrate example anti-rotation element configurations in accordance with some embodiments described herein;

[0063] FIGS. 9A-9B illustrate example sensor circuitry in accordance with some embodiments described herein;

[0064] FIGS. 10A-10E illustrate various communication interface and antenna configurations in accordance with some embodiments described herein;

[0065] FIGS. 11A-11B illustrate attachment configurations in accordance with some embodiments described herein;

[0066] FIGS. 12A-12D illustrate example visualizations that are based at least in part of example data generated by the sensor devices described herein;

[0067] FIG. 13 illustrates an example system for implementing the sensor devices descnbed herein in accordance with an example embodiment of the present disclosure;

[0068] FIG. 14 illustrates a schematic block diagram of an example sensor circuitry that may perform various operations, in accordance with some example embodiments described herein;

[0069] FIGS. 15A-15B illustrate an example initialization operation of an example sensor device in accordance with an example embodiment of the present disclosure;

[0070] FIGS. 16A-16C illustrate another set of example initialization operations of an example sensor device in accordance with an example embodiment of the present disclosure;

[0071] FIGS. 17A-17C illustrate various sensor device ty pes for use with one or more of the embodiments of the present disclosure;

[0072] FIGS 18A-21B illustrate various example visualizations of antenna tuning and performance as related to one or more of the embodiments of the present disclosure;

[0073] FIGS. 22-27 illustrate various sensor circuitry' component configurations with associated wave interactions in accordance with an example embodiment of the present disclosure;

[0074] FIGS. 28-31 illustrate various example radiation patterns as related to one or more of the embodiments of the present disclosure; and

[0075] FIG. 32 illustrates a flowchart of an example method sensor device and communication interface operation in accordance with some embodiments of the present disclosure.DETAILED DESCRIPTIONOverview

[0076] Embodiments of the present disclosure now will be described more fully hereinafter with reference to the accompanying drawings in which some but not all embodiments are shown. Indeed, the present disclosure may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like numbers refer to like elements throughout. As used herein, terms such as “front,” “rear,” “top,” etc. are used for explanatory purposes in the examples provided below to describe the relative position of certain components or portions of components. Furthermore, as would be evident to one of ordinary skill in the art in light of the present disclosure, the terms “substantially” and “approximately” indicate that the referenced element or associated description is accurate to within applicable engineering tolerances.

[0077] As described above, sensors, sensing devices, and / or the like are implemented in a vanety of industries to generate data indicative of the physical phenomenon associated with the particular implementation. In building material related implementations, such as the construction of structures (e.g., foundations, substructures, superstructures, tunneling, etc.), sensor devices may be used to generate data that is associated with the progression of the structure’s completion, such as data associated with the curing process of a cementitious mixture that forms the structure. By way of example, sensors may be used in the construction of structures that are formed of concrete (e.g., cured cementitious mixtures) in which one or more sensors are disposed in (e.g., at least partially embedded in) the cementitious mixture during curing. The sensors, for example, may be placed in the cementitious mixture prior to curing, such as instances in which at least a portion of the cementitious mixture is poured on the sensor. Said differently, the sensors described herein may be, during and / or following curing of a material, at least partially disposed in this material (e g., an example cementitious mixture)

[0078] During operation, the sensor devices may generate data indicative of or otherwise associated with, for example, the temperature of the cementitious mixture, such as for determining the maturity (e.g., a curing state) of the cementitious mixture in time. The data generated by these example sensor devices may be transmitted from the embedded sensor device (e.g., via communication circuitry, antennas, etc.) to one or more centralized computing devices (e.g., physically separated or otherwise distinct from the cementitious mixture). Given the nature of these implementations (e.g.. a sensor embedded in a material), effectively transmitting data generated by the sensor from the sensor to the centralized computing devices is complex. For example, the cementitious material and / or any support structure (e g , a rebar mesh) may interfere with or otherwise degrade the signals transmitted by the sensor device.

[0079] Additionally, the orientation of the sensor device within the building material (e.g., the cementitious mixture) may further impact effective signal transmission by the sensor device. For example, the sensor device may be configured to emit signals in a particular direction, such as in the direction of the one or more centralized computing devices with which the sensor device communicates. In instances in which the sensor device is displaced, tilted, or otherwise moved, signal transmission by the sensor device may also be impacted. As noted above, the sensor devices may be placed in the cementitious mixture prior to curing such that a portion of the cementitious mixture is poured on the sensor. The contact between the poured mixture and the sensor device may, in some instances, move or otherwise change the orientation of the sensor device.

[0080] Further complicating the placement of sensor devices in building materials is the use of support structures, such as rebar meshes, around which the cementitious mixture may be disposed. For example, in forming a particular segment of a building structure at least partially formed on concrete (e.g., a pour), a frame may bound at least a portion of the three- dimensional area that the completed segment will occupy. Within this frame, a plurality of connected, intersected, and / or the like rebar elements may be placed, and a cementitious mixture may be poured therein. In conventional solutions, the sensor device may be strapped, wrapped, tied, and / or the like to one of the rebar elements. For example, a cable tie may be placed centrally along the sensor device to attempt to secure the sensor device to a particular rebar element In these conventional implementations, however, the cable tie is ineffective in preventing rotation of the sensor device about the rebar element. By way of continued example, a conventional sensor device may be affixed to a cylindrical rebar element by a cable tie. When a cementitious mixture is poured on the conventional sensor device, the sensor device mayrotate about the cylindrical rebar element such that the direction that the signals transmitted by the sensor device are negatively impacted.

[0081] As described above, effective signal transmission by the sensors described herein I s complex due to the nature of the implementation (e.g. at least partially embedding the sensor in a material). Additionally, these implementations may be associated with various elements, components, etc. that at least partially obstruct or interfere with the signals generated by the sensor devices. For example, a power source (e.g.. battery or the like) of the sensor device may, in some instances, at least partially interfere with the signal transmission by example antennas (e.g., associated with communication interfaces) of the sensor device. Furthermore, as descnbed herein, the sensor devices of the present disclosure may leverage multiple antennas so as to effectuate signal transmission via multiple communication protocols (e.g., different frequencies or the like). As such, the operation of a plurality of communication interfaces, such as associated with a plurality of antennas, may also result in interference between the signals transmitted and / or received by the example antennas.

[0082] In order to solve these problems and others, the embodiments of the present disclosure provide a sensor device housing that includes an anti-rotation element attached to the housing that is configured to prevent rotation of the housing relative to a support structure. For example, the sensor devices described herein may define one or more extensions that extend from the housing and are configured to engage at least a portion of the support structure, such as an intersection of two rebar elements. Furthermore, the sensor devices of the present disclosure may further arrange communications circuitry (e.g., antennas or the like) within the housing of the sensor device proximate a top surface / portion of the sensor device housing so as to mitigate any impact on the direction of the communications circuitry of the sensor device. In doing so, the embodiments of the present disclosure significantly increase the reliability and effectiveness of sensor devices that are embedded in materials.

[0083] The devices described herein may further operate to minimize the impact of interference associated with operation of the device (e.g., interference associated with the material or support structure, interference between sensor circuity, etc.). For example, the configuration (e.g., relative positioning, tuning, and / or the like) of the antennas used by the device to transmit and / or receive data, such as via various communication protocols, may be configured to eliminate or minimize the impact of any interference associated with these components. As described above and hereinafter, the sensor devices of the present disclosure may further employ a plurality of communication interfaces and / or antennas to as to transmit and / or receive data over a plurality of communication channels, protocols, and / or the like. Theselective operation of these communication interfaces may further operate to improve data transmission, memory storage / management, power consumption, and / or the like associated with the sensor device. In doing so, the embodiments of the present disclosure provide novel sensor circuitry configurations and operations, particularly for sensor devices disposed in materials, which were historically unavailable.Example Sensor Device

[0084] With reference to FIGS 1 A-1E, an example sensor device implementation 100 (e g., implementation 100) of the present disclosure is illustrated. As shown, implementation 100 may include a sensor device 200 and a support structure formed of a plurality of support members 101, 103. The support structure may include any number of support members 101, 103 in any configuration based on the intended application of the support structure. Additionally, the relative positioning, orientation, and / or the like of the support members 101, 103 forming the support structure may vary. In some embodiments, the support structure may include a first support member 101 that intersects or crosses a second support member 103. As shown, in some embodiments, intersection between the example first support member 1 1 and the example second support member 103 may be such that the support members 101, 103 are substantially perpendicular with respect to one another. Although described herein with reference to intersecting members 101, 103 of the support structure, the present disclosure contemplates that the sensor devices 200 of the present disclosure may be configured to engage any connection, contact, comer, etc. between two support members 101, 103.

[0085] As shown in FIG. 1 A, the sensor device 200 may operate to transmit and / or receive signals, such as related to the data generating by one or more components of the sensor circuitry described hereinafter. As shown, for example, a signal 109 that is generated by the sensor device 200 (e.g., via selective operation of a communication interface, associated antenna, etc.) may reflect off of the support members 101, 103 so as to interfere (e.g., destructive interference or the like) with the signal(s) transmitted by the sensor device 200. As described hereinafter, the sensor device 200 configurations of the present application may operate to eliminate and / or minimize the impact of interference, such as a reflected signal 109), on performance of the sensor device 200

[0086] Additionally, the present disclosure contemplates that the sensor devices 200 described herein may engage support members 101, 103 of any size and / or cross-sectional shape. Although illustrated with two support members 101, 103 of substantially the same size and cross-sectional shape, the present disclosure contemplates that sensor devices 200described herein may be implemented with support members 101. 103 that vary in these characteristics. For example, the first support member 101 may have a different size (e.g., diameter) and / or cross-sectional shape than a size (e.g., diameter) and / or cross-sectional shape of the second support member 103. Furthermore, although described herein w ith reference to an example implementation 100 with a single sensor device 200 engaging a support structure of two support members 101, 103, the present disclosure contemplates that the features described herein may be applicable to any number of sensor devices engaging the same or different support structures without limitation A building material (e g , a cementitious mixture) may be poured over the implementation 100 and at least partially embed the sensor device 200. Although described herein with reference to sensor devices 200 configured to generate data associated with building materials, such as cementitious mixtures, the present disclosure contemplates that the sensor devices 200 may be applicable to any material without limitation.

[0087] With reference to FIGS. 1C-1E, an example sensor device 200 of the present disclosure illustrated at least partially disposed or embedded in a material 107 (e.g., concrete, a cementitious mixture, etc.). As shown in FIG. 1C and IE, for example, the sensor devices 200 of the present disclosure may, in some embodiments, be entirely disposed within or fully embedded in a material 107. As shown in FIG. ID, for example, the sensor device 200 may be partially disposed within or partially embedded in the material 107. For example, a sensing element 300 associated with the sensor device 200 (e.g , coupled with the sensor device 200) as described hereinafter may be disposed within the matenal 107 while at least a portion of the housing 201 of the sensor device 200 is physically separate from the material 107. The present disclosure contemplates that any portion of the sensor device 200 and / or components coupled with the sensor device 200 may be, in whole or in part, disposed within the material 107. Furthermore, although described herein with reference to an example building material 107, such as concrete, the present disclosure contemplates that the material 107 may be any material of any ty pe, shape, etc. w ithout limitation.

[0088] As shown in FIG. IE, the sensor device(s) 200 of the present disclosure may be disposed at least partially within a material 107 and configured to generate data associated with the material 107 As described hereinafter, the sensor device 200 may generate data, via various sensor circuitry' components, sensing elements, etc., that is indicative of various characteristics, attributes, properties, etc. associated with the material 107, the environment of the material 107, and / or the like. By way of a non-limiting example, the sensing element 300 that is coupled with the sensor device 200 may be configured to generate data that is indicative of thetemperature of the material 107, such as used to determine the maturity (e.g., compressive strength, curing state, etc.) of the material 107. Although described herein with reference to temperature data, the present disclosure contemplates that the sensor device 200 may be configured to generate data indicative of or associated with any characteristics of the material 107. As shown in FIG. IE, the systems described herein may generate a visualization 800 associated with the data generated by the sensor device 200. For example, as shown in FIGS. 12A-12D, the sensor device 200 may be associated with various visualizations generated based on the data of the sensor device For example, FIG 12A illustrates an example visualization of impedance data 802, FIG. 12B illustrates an example visualization of material temperature relative curing time 804, FIG 12C illustrates an example visualization of material strength relative curing time 806, and FIG. 12D illustrates an example visualization of material strength relative curing time for a plurality of elements 808.

[0089] With reference to FIGS. 2A-2C, the sensor device 200 of FIG. 1 is illustrated with an example sensing element 300. With reference to FIGS. 3A-3E, various views of the sensor device 200 without the example sensing element 300 are illustrated. As shown, the sensor device 200 may include a sensor housing 201 (e.g., housing 201) that defines at least a top portion 202 and a bottom portion 204 As would be evident to one of ordinary skill in the art in light of the present disclosure, the top portion 202 and the bottom portion 204 may define an interior therebetween, such as to house sensing components, circuitry, elements, etc. as descnbed hereinafter. In some embodiments, the top portion 202 may be removably attached with the bottom portion 204. In such an embodiment, for example, the sensor circuitry and elements described herein may be placed on, supported by, and / or affixed to one of the top portion 202 or the bottom portion 204 and the other of the top portion 202 or the bottom portion 204 may be attached to form the combined sensor housing 201. In such an embodiment, a sealing member (e.g., O-ring 500 or the like) may be positioned between the top portion 202 and the bottom portion 204, such as along a peripheral edge of the sensor housing 201. The present disclosure contemplates that any mechanism or technique (e.g., screws, adhesives, etc.) may be used to removably attach the top portion 202 with the bottom portion 204. Furthermore, as would be evident based on the implementation 100 of the sensor device 200, the housing 201 may be watertight so as to prevent the ingress of the building materials into the interior of the housing 201.

[0090] Although described hereinafter with reference to removable attachment between the top portion 202 and the bottom portion 204. the present disclosure contemplates that, in other embodiment, the top portion 202 and the bottom portion 204 may be formed integral to oneanother (e.g., as a uniform or single piece of material). In such an embodiment, the top portion 202 and the bottom portion 204 may refer to different areas, locations, etc. of the integral body forming the sensor housing 201. Furthermore, although the sensor housing 201 is illustrated as a rectangular box or any other configuration having a substantially rectangular cross-sectional shape, the present disclosure contemplates that the housing 102 may be dimensioned (e.g., sized and shaped) based upon the intended application of the sensor device 200. As shown, in some embodiments, housing 201 may be associated with a longitudinal axis (L) that extends along the length of the housing 201 Although described herein with reference to a substantially rectangular housing 201, the present disclosure contemplates that the housing 201 may define any number of edges, ends, surfaces, etc. located at any position, orientation, and / or the like.

[0091] For example, the housing 201 (e g., the combined top portion 202 and bottom portion 204) may define various surface features, attachment features, etc. In some embodiments, a centrally located section of the housing 201 may be beveled, chamfered, sloped, or otherwise angled differently from the remainder of the housing 201. In such an embodiment, the centrally located section may be configured to receive strapping to attach the housing 201 to a support structure as described herein (e.g.. an engagement between the housing 201 and the support structure other than the engagement provided by the anti-rotation element).

[0092] With continued reference to FIGS. 2A-2C, the sensor device 200 may include a sensor element 300 attached thereto. As described more fully hereinafter with reference to FIGS. 8A-8B, the sensor element 300 may, at one end, be communicably coupled with the sensor circuitry' disposed within the housing 201. At another, opposing end, the sensor element 300 may define various components for generating data indicative of various properties, attributes, features, characteristics, etc. of the building material (e.g.. a cementitious mixture) surrounding the sensory device 200. As shown in FIGS. 3B and 3E and described further with reference to FIGS. 5A-5C, the housing 201 may define a channel 210 configured to engage at least a portion of the support structure (e.g., an element of the rebar mesh). As described herein after with reference to FIGS.4A-4E, the sensor device 200 may further define an anti-rotation element attached to the housing 201 and configured to prevent rotation of the housing 201 relative to a support structure (e g , support members 101, 103 in FIG 1)

[0093] With reference to FIGS. 4A-4E, various view's of the top portion 202 of the sensor housing 201 are illustrated. As shown, in some embodiments, the anti-rotation element 206 may be attached to the top portion 202 of the housing 201. In such an embodiment, the top portion 202 may define a first end 212 (e.g., a first end 212 of the housing 201) and a secondend 214 (e.g. a second end 214 of the housing 201). As shown, the first end 212 may be opposite the second end 214. Although described herein with reference to opposing ends 212, 214, the present disclosure contemplates that the housing 201 (e.g., the combined top portion 202 and bottom portion 204) may include any number of ends based on the intended application of the sensor device 201. In some embodiments, the first end 212 may define the anti -rotation element 206 so that the end of the housing 201 that engages the support structure is opposite the end of the housing that receives the sensing element 300. Said differently, the sensing element 300 may be disposed opposite the intersection of support members so as to prevent the support members impeding the sensing element 300.

[0094] The anti-rotation element 206 may refer to the structural components of the housing 201, such as defined by or attached to the top portion 202, that prevents the rotation of the housing relative to a support structure. By way of continued example, the sensor device 200 of the present disclosure may be attached, via strapping or the like) to a support member (e.g. support member 101) that is positioned substantially along the length of the housing 201 In other words, the sensor device 200 may be attached to the first support member 101 along the longitudinal axis (L) along the length of the housing 201. Unlike conventional solutions, however, the sensor devices 200 described herein further define the anti-rotation element(s) 206 that further engage another support member (e.g., the support member 103) that intersects the first support member 101. As described hereinafter, the anti -rotation element 206 may refer to any structure, mechanism, feature, and / or the like of the housing 201 that may prevent rotation of the sensor device 200. Therefore, engagement as described herein may refer to any contact between any portion of the sensor housing 201 and the support structure 101, 103 without limitation.

[0095] In some embodiments, the anti-rotation element 206 may define one or more extensions from the housing 201 and engage at least a portion of the support structure 101, 103. In some embodiments, the one or more extensions may define a pair of extensions that engage at least a portion of the second support member 103 and prevent rotation of the housing 201 with respect to. for example, the first support member 101. Although illustrated and described herein with reference to a pair of extensions 216, the present disclosure contemplates that the anti-rotation element 206 may define any number of extensions based on the intended application of the sensor device 200. In some embodiments, the one or more extensions may be moveable relative to the top portion 202 so as, for example, to increase the contact (e.g., engagement) between the anti-rotation elements 206 and the example second support member 103.

[0096] With continued reference to FIG. 4D, in some embodiments, the anti-rotation element(s) 206 may define a proximal portion 218 attached to the housing and a distal portion 202 attached to the proximal portion 218. As shown, the distal portion 220 may extend from the top portion 202 of the housing 201. Furthermore, as shown, an angle (0) may be defined between the proximal portion 218 and the distal portion 220. In some embodiments, the proximal portion 218 may be substantially perpendicular to a length (L) of the housing 201 and the distal portion 220 may be substantially parallel to the length (L) of the housing 201. Said differently, the distal portion 220 and the proximal portion 218 may be substantially perpendicular such that 0 is approximately 90 degrees Although illustrated and described herein with reference to substantially perpendicular distal and proximal portions 220, 218, the present disclosure contemplate that the angle (0) defined between the distal portion 220 and the proximal portion 218 of the anti-rotation element 216 may vary based on the intended application of the sensor housing 201. Furthermore, although the proximal portion 218 and the distal portion 220 are illustrated herein with substantially the same shape and / or dimensions, the present disclosure contemplates that, in some embodiments, the relative size, shape, orientation, etc. between the proximal portion 218 and the distal portion 220 may vary.

[0097] In some embodiments, the anti-rotation elements 206 may farther define one or more openings 216. In such an embodiment, the one or more openings 216 (e.g., through-holes, apertures, etc.) may be configured to receive strapping (e.g., ties, flexible securing members, etc.) therein. As would be evident to one of ordinary skill in the art in light of the present disclosure, the strapping received via the openings 216 may be distinct from any strapping, ties, etc. configured to attach the sensor housing 201 to the first support member 101. Said differently, the openings 216 in the anti-rotation element 206 may be configured to receive strappings that further increase the engagement (e.g., contact) between the anti-rotation element(s) 206 and the second support member 103. In some embodiments, the anti-rotation element 206 may include various surface features (e.g., channels, grooves, etc.), shapes (e.g., increased curvature), and / or materials (e.g., a relatively higher friction material) to increase the engagement between the anti-rotation element(s) 206 and the example second support member 103. Although illustrated in FIGS. 8B and 8C

[0098] As described above and as shown in FIGS 8A-8D, the present disclosure contemplates that the anti-rotation element 206 may vary in configuration. For example, as shown in FIG. 8A, in some embodiments, the anti-rotation element 206 may be formed as a U- shaped element that is configured to at least partially encircle the second support member 103. As shown, the anti-rotation element 206 of FIG. 8A may encircle greater than 90 degrees ofthe second support member 103. The present disclosure contemplates that the curvature of the anti-rotation element 206 and / or the amount (e.g.. in degrees or radians) that the anti-rotation element encircles the second support member 103 may vary. In some embodiments, the antirotation element 206 may encircle the entire second support member 103. As shown in FIG. 8D, in some embodiments, the anti-rotation element 206 may be supported by the bottom portion 204 of the housing 201.

[0099] With reference to FIGS. 8B-8C. the anti-rotation element 206 may, in some embodiments, be movable with respect to the housing 201 For example, FIG 8B illustrates a first position of the anti-rotation element 206 with respect to the housing 201, and FIG. 8C illustrates a second position of the anti-rotation element 206 with respect to the housing 201. As shown, the first position may be higher in vertical height (e.g., closer to the top surface of the top portion 202) than the second position. In such an embodiment, the anti-rotation element 206 may be configured to accommodate various sizes of support member 101, 103 and be adjustable to promote engagement between the anti-rotation element 206 and the support members 101, 103. Although illustrated and described herein with reference to vertical movement of the anti-rotation element 206. the present disclosure contemplates that in some embodiments, the anti-rotation element 206 may be movable, adjustable, etc. in any direction. As shown, in some embodiments, positioning the anti-rotation element 206 on the top portion 202 may prevent breakage of the housing 201, such as due to a supplied impact. Instead, positioning the anti-rotation element 206 on the top portion 202 may operate to improve engagement between the top portion 202 and the bottom portion in response to such an impact.

[0100] With reference to FIGS. 5A-5D, the bottom portion 204 of the sensor housing 201 is illustrated. As described above, the bottom portion 204 may define a first end 212 (e.g., a first end 212 of the housing 201) and a second end 214 (e.g. a second end 214 of the housing 201). The first end 212 and the second end 214 may be complementary to the first end 212 and the second end 214 of the top portion 202. The bottom portion 204 may defines a channel 210 (e.g., any concave surface) configured to receive a portion of the support structure therein. Said differently, the bottom portion 204 may define a channel that is disposed along a length of the bottom support member 204 (e.g., along the longitudinal axis L). As described above, the sensor device 200 of the present disclosure may be configured to be implemented proximate (e g., engage) support structures (e g , elements of a rebar mesh) of any dimension (e.g., size or shape). As such, the present disclosure contemplates that the channel 210 may similarly be dimensioned (e.g.. sized and shaped) to receive support members (e g., the example first support member 101) therein.

[0101] In some embodiments, the bottom portion 204 may further define an opening 208 configured to receive a sensing element (e.g.. sensing element 300) disposed therein. As described above, the second end 214 of the bottom portion 204 (e.g., the second end 214 of the housing 201) may define the opening 208. As described hereinafter with reference to FIGS. 7A-7D, the sensing element 300 may define a cable, tubing, or other elongate structure that is at least partially received within the opening 208, so as to enable communicable coupling between the sensing element 300 and the one or more sensor circuitry elements, components, etc disposed in the interior of the housing 201

[0102] In some embodiments, as illustrated in FIG 5D, the bottom portion 204 of the sensor housing 201 may define a channel 210 that is removably attached to the bottom portion 204. By way of example, the bottom portion 204 may define a recess, channel, slot. etc. within which a component that defines the channel 210 may be positioned. In this way, the bottom portion 204 of the housing 201 may be configured to accommodate support members 101, 103 of various sizes (e.g., diameters or the like). For example, the channel 210 of the bottom portion may be sized to complement the size of the support members 101, 103, such as be selecting a component supporting a channel 210 with dimensions that are complementary to the dimensions of the support members 101, 103. Although described herein with reference to a channel 210, the present disclosure contemplates that in some embodiments, the bottom portion 204 may operate in the absence of a channel 210 (e.g., a substantially flat bottom surface of the bottom portion 204).

[0103] With reference to FIG. 6, an exploded view of the sensor device 200 of the present disclosure is illustrated. As shown, the sensor device 200 may include a sensing element 300 that includes a connection element 306, the top portion 202, the bottom portion 204, and sensor circuitry 400 In some embodiments, as described above, the sensor device 200 may include a sealing member 500 (e.g., an O-ring or the like) may be positioned between the top portion 202 and the bottom portion 204, such as along a peripheral edge of the housing 201. Additionally or alternatively, in some embodiments, the sensor device 200 may include an exterior data feature 600 (e.g., a sticker or the like). In such an embodiment, the exterior data feature 600 may include scannable indicia (e.g., a barcode, a quick-response (QR) code, or the like), that, when scanned, initiates or otherwise actives at least a portion of the sensor circuitry 400 described herein.

[0104] In some embodiments, as shown in FIGS. 11A-11B, the support structure formed of support members 101, 103 may be such that the dimensions of the housing 201 preclude direct engagement (e.g., physical contact) between the anti-rotation element 206 and at leastone of the support members. By way of example, the distance between the support members forming the support structure may be less than the lateral and / or longitudinal dimensions of the housing 201. In such an embodiment, however, the anti -rotation element 206 may operate as an additional attachment location between the housing 201 and the support structure. As shown, for example, the anti-rotation element 206 may be configured to receive strapping (e.g., ties, flexible securing members, etc.) to attach the sensor housing 201 to the first support member 101 and / or the second support member 103. The present disclosure contemplates that the arrangement of strapping in such an alternative implementation may vary based on the configuration of the support structure, dimensions of the housing 201, and / or the like.Example Sensing Elements

[0105] With reference to FIGS. 7A-7D, an example sensing element 300 is illustrated. As shown, the sensing element 300 may define a first end 302 and a second end 304 opposite the first end 302 The second end 304 may be configured to be communicably coupled with the sensor circuitry 400 disposed within the housing 201. As such, in some embodiments described hereinafter, the second end 204 may operate a s a wired communication interface (e.g.. an example third communication interface) that communicable couples the sensing element 300 to one or more components of the sensor device 200. The first end 302 may define any number of circuitry components based on the particular sensing operations associated w ith the sensing device 200. By way of example, in some embodiments, the sensing device 200 may be configured to generate data indicative of the temperature of the building material within which the sensor device 200 is embedded. For example, the data generated by the sensor device 200 may be used as part of maturity related determinations for the example building material. Although described herein with reference to example temperature-related data generation, the present disclosure contemplates that the sensing element 300 may include any components for generating data indicative of any properties, attributes, features, characteristics, etc. of the building material (e.g., a cementitious mixture) surrounding the sensory device 200. The sensing element 300 may, as described above, include a connection element 306 that is disposed in the opening 208 of the bottom portion 204.

[0106] In some embodiments, as shown in FIG 7D, the sensing element 300 may include a plurality of first ends 302 that each define any number of circuitry components based on the particular sensing operations associated with the sensing device 200. By way of continued example, in some embodiments, the sensing device 200 may be configured to generate data indicative of the temperature of the building material (e.g., material 107) within which thesensor device 200 is embedded. For example, the data generated by the sensor device 200, such as data entries generated by a plurality for sensing elements, probes, or other devices disposed at the first ends 302 of the sensing element 300, may be used as part of maturity related determinations for the example building material. Although illustrated in FIG. 7D with two (2) first ends 302 that are configured to, for example, generate data indicative of the temperature of the material (e.g., a multi-probe temperate based sensing element 300), the present disclosure contemplates that the sensing element 300 may include any number of circuitry components (e g , of the same or different type) disposed at any number of ends (e g , plurality of first ends 302) without limitation.

[0107] With reference to FIGDS. 17A-17C, other example sensor types are shown. Although described herein with reference to temperature based sensing techniques and components, the present disclosure contemplates that the sensing element 300 may leverage any type of sensing technique based on the intended application of the sensor device 200. As shown in FIG. 17A, the sensing element 300 may include an Ultrasonic Pulse Velocity (UPV) based sensing component 1100. As shown in FIG. 17B, the sensing element 300 may include Electro-Magnetic Interference (EMI) based sensing component 1102. As shown in FIG. 17C, the sensing element 300 may include an embedded corrosion instrument (ECI) based sensing component 1104. Each of these example sensing components 1100, 1102, and 1104 may be configured to generate data indicative of one or more characteristics, properties, attributes, etc. of the material 107 associated with the sensor device 200.

[0108] With reference to FIGS. 7B-7C, the interface or connection between the sensing element 300 and the housing 201 of the sensor device 200 may be configured to prevent the ingress of a material, water, etc. into the interior of the housing 201. As described above, the sensing element 300 may include a connection element 306 that is disposed in the opening 208 of the bottom portion 204. This connection may further include various sealing elements 308 (e g., O-rings or the like) that hermetically seal the sensing element 300 within the opening 310 of the housing 201. For example, the connection element 306 may define a bayonet connection in which the sensing element 300 is disposed in the opening 310 and the connection element is disposed about the sensing element (e.g., the wired connection) and rotated so as to engage the bottom portion 204 of the housing 201 The present disclose contemplates that any attachment mechanism may be used by the sensor device 200 and / or the connection element 306 so as to provide a watertight seal or otherwise prevent the ingress of material into the interior of the housing 201.Example Sensor Circuity Configurations

[0109] With reference to FIGS. 9A-9B, example sensor circuitry 400 is illustrated. As described above, the sensor device 200 of the present disclosure may support various sensor circuitry components within the housing 201. As shown in FIGS. 9A-9B, the sensor device 200 may include at least a printed circuit board (PCB) 402 (e.g., a substrate) that supports a processor 404, and or more antennas 406. 408. For example, The one or more antennas may include a first antenna 406 and a second antenna 408. The one or more antennas may, in some embodiments, be positioned closer to the top portion 202 of the housing 201 than the bottom portion 204 of the housing 201. Additionally, in some embodiments, the one or more antennas may include a first antenna configured to transmit data via a first communication protocol (e. g. , Bluetooth Low Energy (BLE). and a second antenna configured to transmit data via a second communication protocol (LoRa) as described hereinafter.

[0110] As shown in FIG. 9B and described more fully hereinafter with reference to operations of the sensor device 200, the sensor circuitry 400 may further include a plurality of communication interfaces, such as a first communication interface 412 and a second communication interface 410.

[0111] As described hereafter with reference to the communications circuitry 1008 of FIG. 14, the communication interfaces described herein may be any means such as a device or circuitry embodied in either hardware or a combination of hardware and software that is configured to receive and / or transmit data associated with the sensor device 200. In some embodiments, the plurality of communication interfaces, such as first communication interface 412 and second communication interface 410, may be wireless communication interfaces that leverage various wireless communication protocols. For example, the first communication interface 412 may be associated with a first antenna 406, and the second communication interface 410 may be associated with a second antenna 408. Although described herein with reference to example antenna hardware, the present disclosure contemplates that the communication interfaces described herein may encompass network cards, antennae, buses, switches, and supporting hardware and / or software, or any other device suitable for enabling communications. As described above with reference to sensing element 300, the present disclosure further contemplates that the plurality of communication interfaces may include wired communication interfaces (e g., an example third communication interface). In other words, the communication interfaces of the present disclosure may include any of the components or protocols described with reference to communications circuity 1008.

[0112] In some embodiments, as shown in FIG. 9B, the sensor device 200 may include one or more ground shielding elements 409. The ground shielding element 409 may be implemented as a grounded copper pour, shield trace, or a discrete metallic plate or foil, and may be electrically connected to a reference potential, such as PCB ground. The ground shielding element 409 may be positioned adjacent to, or between, sensitive components such as the antenna 410 and a battery 401. For example, where the battery' is located on the opposite side of the ground shielding element 409 relative to the antenna 410, the ground shielding element 409 may sen e to reduce electromagnetic interference (EMI) from the battery and minimize any detuning or degradation of antenna performance due to the proximity' of the battery or other electronic components. In this way, the ground shielding element 409 may act as an effective shield, maintaining a predictable antenna radiation pattern and preserving wireless communication performance.

[0113] Additionally or alternatively, the ground shielding element 409 may be disposed beneath the antenna 410, such that it acts as a ground plane to control the antenna’s directionality or to reduce unwanted electromagnetic transmission towards underlying conductive structures, such as steel reinforcement (rebar) within concrete. In such embodiments, the ground shielding element 409 may preferentially direct RF energy away from the rebar and into the surrounding environment, thereby enhancing communication reliability' and reducing RF signal absorption by the reinforcing steel.

[0114] In further embodiments, the sensor device 200 may include a plurality of ground shielding elements 409 disposed at different locations or onentations with respect to the antenna 410 and other device components. Each shielding element may be electrically connected to ground and strategically positioned so as to prevent or attenuate unwanted radiation in one or more specific directions. For example, a first ground shielding element may be positioned laterally between the antenna and the battery to block EMI from the battery, while a second ground shielding element may be disposed underneath the antenna to act as a ground plane and reduce downward radiation towards rebar. A third shielding element may be positioned at another orientation to further attenuate multipath reflections, for instance, from nearby metallic structures or enclosures. By using a plurality of such grounded shielding elements in various orientations, the device may reduce multipath interference arising from reflections and scattered signals within the deployment environment, thereby maintaining a cleaner RF environment and improving signal integrity' and overall communication performance.

[0115] In some embodiments, each ground shielding element 409 may be realized in a variety of geometric forms, including but not limited to planar rectangles, irregular polygons, or custom contours tailored to the spatial requirements of the device. The dimensions and outline of the shielding element 409 may be selected to match or exceed the footprint of the antenna 410. The dimensions and outline of the shielding element 409 may be selected to match or exceed the footprint of the antenna 410 or may be specifically shaped to provide optimal coverage between the antenna and particular sources of electromagnetic interference, such as batteries or microcontroller units In embodiments where the shield serves as a ground plane, its length and width may extend beyond the boundaries of the antenna by a margin (for example, at least 0.1 to 0.5 wavelengths at the antenna’s operating frequency) to optimize antenna gain and reduce back-lobe radiation.

[0116] Additionally or alternatively, ground shielding elements 409 may be implemented as non-planar, multi-faceted, or angled features within the device. For example, a shield may be folded or bent into an “L” or “U” shape to wrap partially around the antenna or sensitive circuitry or may be integrated into a multilayer PCB stack-up with ground stitching vias forming a perimeter "fence” around the antenna region. In some cases, the shielding element 409 may incorporate apertures, slots, or mesh patterns to permit routing of signal traces, reduce weight, or tailor frequency -dependent behavior. The material composition of the shielding element 409 may include high-conductivity copper, aluminum, or suitable conductive alloys, and the surface may be plated or coated (for example, with tin, nickel, or gold) to prevent oxidation and maintain electrical integrity.

[0117] In some embodiments, a conformal conductive coating may be applied to a portion of the sensor device and electncally connected to ground, for example, to the low er portion of the enclosure, thereby providing an integrated shielding surface that attenuates electromagnetic transmission toward selected directions, such as toward underlying rebar or other conductive structures.

[0118] In embodiments comprising a plurality of ground shielding elements 409, the elements may be oriented in different planes or angles to one another, with each shield strategically aligned to intercept or reflect electromagnetic energy propagating along distinct vectors

[0119] In some embodiments, as described more fully herein with reference to the operations associate with the sensor devices 200 of the present disclosure, the first antenna 406 and associated first communication interface 412 may be configured to operate (e.g., transmit and receive data) via a first communication protocol (e.g., Bluetooth Low Energy (BLE) or thelike). Similarly, the second antenna 408 and associated second communication interface 410 may be configured to operate (e.g., transmit and receive data) via a second communication protocol (e.g , LoRa or the like) that may be different from the first communication protocol. As described hereinafter, the communication protocols may refer to the various characteristics of signals transmitted and received, such as via the antenna associated with the particular communication interface. For example, a particular communication protocol may define a set of frequencies, bandwidths, resonances, etc. for communicating via the protocol. By way of nonlimiting example, the communication protocols described herein may include wireless protocols, such as Bluetooth (including Bluetooth Classic and Bluetooth Low Energy), LoRa (chirp spread spectrum or FSK). cellular technologies (such as GSM, GPRS, EDGE, UMTS, LTE. LTE-M, NB-IoT, or 5G), Wi-Fi (IEEE 802.11), Zigbee (IEEE 802.15.4), Z-Wave, Sigfox, Ultra-Wideband (UWB), RFID, NFC, satellite or non-terrestrial network (NTN) communication, or any other wireless communication protocol. By way of nonlimiting example, the communication protocols described herein may include wired protocols, such as FC, 1-Wire, SPI, UART, RS-232, RS-485, MODBUS, CAN bus, SDI-12, 4-20 mA current loop, analog voltage, GPIO, PWM, SMBus, or any other wired or physical layer sensor interface.

[0120] In an example embodiment, one or more communication interfaces (e.g., the first communication interface 412) may be configured to transmit and / or receive data over Bluetooth (e.g., an example first communication protocol). Such Bluetooth communication interfaces may be operated in different modes, such as Bluetooth Classic (BR / EDR), Bluetooth Low Energy (BLE 4.0, 4.1, 4.2), BLE 5.x (including 5.0, 5.1, 5.2, and 5.3), Bluetooth Long Range (LE Coded PHY, S=2 / S=8), Bluetooth High Speed (HS), as well as specialized modes like LE Audio and Mesh Networking. The example first communication interface 412 may be configured to operate across frequencies in the 2.400 GHz to 2.4835 GHz ISM band, utilizing any of the 79 channels spaced 1 MHz apart (channels 0-78) for Bluetooth Classic, or any of the 40 channels spaced 2 MHz apart (channels 0-39) for Bluetooth Low Energy, with BLE advertising conducted specifically on channels 37, 38, and 39. The processor 404 may select advertising or data channels automatically, or based on local channel occupancy, interference, or regulatory' constraints The first communication interface may transmit at output power levels configurable from approximately -20 dBm (0.01 mW) up to +27 dBm (500 mW), depending on device class and regulatory requirements, and may dynamically adjust transmit power to balance communication range and power consumption. The receiver sensitivity may also be configurable, for example supporting sensitivities as low as -95 dBm or lowerdepending on chipset and antenna design. Additional Bluetooth parameters, such as advertising interval (which may be configured, for example, between 20 ms and 10.24 s), data rate (which may range from 125 kbps up to 2 Mbps depending on mode), connection interval, slave latency, and supervision timeout, may be selected to optimize performance for specific application requirements. All such transmit and receive settings may be automatically managed by the device processor, configured locally or remotely, or dynamically adapted in response to environmental or operational conditions.

[0121] In another embodiment, one or more communication interfaces (e.g., the second communication interface 410) may transmit and / or receive data over LoRa. The example second communication interface 410 may be operated in different modes, such as standard LoRa modulation (chirp spread spectrum), LoRaWAN (for wide-area networking with star topology), LoRa Point-to-Point (peer-to-peer or device-to-device), and FSK (frequency-shift keying) mode. Additionally, such LoRa communication interfaces may be configured to transmit data in a number of different modes (including but not limited to Class A, Class B or Class C), regional frequency plans, and various spreading factors (e.g. SF7-SF12) to balance range and data rate. In one embodiment, the example second communication interface 410 may be configured to operate across standard the 902-928 MHz, 863-870 MHz, and 779-787 MHz, or any subset thereof. The output power may be configurable from approximately -20 dBm (0.01 mW) up to +27 dBm (500 mW) or higher, as permitted by applicable regulations. Additional parameters, including but nothmitedto channel bandwidth (e.g., 7.8 kHz, 10.4 kHz, 15.6 kHz, 20.8 kHz, 31.25 kHz, 41.7 kHz, 62.5 kHz, 125 kHz, 250 kHz, or 500 kHz), coding rate (e.g., 4 / 5, 4 / 6, 4 / 7, 4 / 8), preamble length (e.g., 6 to 65535 symbols), spreading factor (e.g., SF5 to SF12), and channelization (including frequency and time slot selection), may also be selectable or dynamically adjusted to optimize for range, data rate, interference resilience, energy efficiency, or regulatory' compliance, and such selectability' or adjustment may be performed automatically in response to data received from another communication interface.

[0122] Additional parameters, including but not limited to channel bandwidth (for example, 7.8 kHz, 10.4 kHz, 15.6 kHz, 20.8 kHz, 31.25 kHz, 41.7 kHz, 62.5 kHz, 125 kHz, 250 kHz. or 500 kHz), coding rate (such as 4 / 5, 4 / 6, 4 / 7, or 4 / 8), preamble length (e.g., 6 to 65535 symbols), and spreading factor (e g , SF5 to SF12), may also be selectable or dynamically adjusted. Data rate may be varied from below 300 bps up to approximately 27 kbps by selecting appropriate combinations of bandwidth, spreading factor, and coding rate. The example second communication interface 410 may further support dynamic or scheduled channelization (including frequency hopping or time slot selection), automatic or adaptive datarate (ADR) control, receiver sensitivity settings, duty cycle or dwell time management, and synchronization word or device / network identifier selection. All such parameters may be set manually, configured remotely, or automatically adjusted by the sensor device in response to application requirements, regulatory constraints, environmental conditions, or feedback received over another communication interface.

[0123] In some embodiments, the plurality of communication interfaces described herein may include two (2) communication interfaces. In such an embodiment, the sensor device may include a wired communication interface in conjunction with a wireless communication interface. For example, the wired communication interface may include a I2C or One Wire interface and the wireless communication interface may include a BLE, LoRA, Cellular (e.g., NB loT). or NTN (non-terrestrial) communication interface. In other embodiments, the two communication interfaces may include two wireless communication interfaces for different transmission ranges. For example, the pair of wireless communication interfaces may include a LoRa and Bluetooth interface, a cellular (e.g., NB-IoT) and Bluetooth interface, a cellular and LoRa interface, and / or an NTN (non-terrestrial) and cellular interface. Although described herein with reference to specific combinations of two communication interfaces, the present disclosure contemplates that any number of communication interfaces in any combination may be used without limitation.

[0124] In one embodiment, one or more front-end modules (FEMs) or RF amplifiers may be incorporated with the communication interfaces 412, 410 to increase transmit power or to enhance receive sensitivity, thereby improving overall wireless communication range and reliability'. Such FEMs or RF amplifiers may be communicably coupled to the communication interface 412, 410 and / or the antenna(s) 406, 408 for such communication interface 412. 410. Additionally or alternatively, the output power of the communication interface 412, 410 may be dynamically reconfigured in response to data received from another communication interface 412, 410 or based on detected environmental conditions. For example, the transmit power may be automatically increased when the device is determined to be located within a high-attenuation environment, such as within concrete or other signal-obstructing materials 107, in order to maintain reliable communication.

[0125] In another embodiment, one or more communication interfaces 412, 410 may transmit and / or receive data over cellular networks, including but not limited to NB-IoT, LTE- M (Cat-Mi), LTE (Cat-1, Cat-4), 5GNR (New' Radio), or emerging 6G protocols, as supported by the communication hardware and network. The cellular communication interface may be operated in different modes, such as NB-IoT standalone, NB-IoT in-band or guard-band withinLTE carriers, LTE-M with extended Discontinuous Reception (eDRX) or Power Saving Mode (PSM). standard LTE FDD or TDD, or 5G / 6G with ultra-reliable low-latency communications (URLLC), massive machine-type communications (mMTC), or enhanced mobile broadband (eMBB) features. In some embodiments, the interface may be configured to operate over any of the globally standardized cellular frequency bands, for example, 699-960 MHz, 1710-2200 MHz, 2300-2700 MHz, 3300-4200 MHz. or other assigned sub-GHz, mid-band, or mmWave spectrum, including but not limited to NB-IoT and LTE-M bands such as Band 3 (1800 MHz), Band 5 (850 MHz), Band 8 (900 MHz), Band 12 (700 MHz), Band 13 (700 MHz), Band 20 (800 MHz), Band 28 (700 MHz), Band 71 (600 MHz), and 5G NR bands such as n78 (3500 MHz) or n41 (2500 MHz), or any subset thereof, as permitted by regional regulation and operator support.

[0126] The output power of the cellular communication interface may be configurable from approximately -20 dBm up to +23 dBm, +26 dBm, or higher, depending on the device class (for example, 3GPP Power Class 3 for NB-IoT or Class 5 for LTE-M) and regional limits. Additionally or alternatively, the communication interface may support selection or dynamic adjustment of channel bandwidth (for example. 180 kHz for NB-IoT, 1.4 MHz or 5 MHz for LTE-M, up to 100 MHz or higher for 5GNR), uplink and downlink channelization, modulation schemes (such as BPSK, QPSK, 16QAM, 64QAM), duplexing methods (FDD, TDD), and adaptive scheduling to optimize for data rate, coverage, and latency.

[0127] Data rates may be selectable or dynamically adjusted, for example, from below 100 bps (NB-IoT deep coverage) up to 375 kbps for LTE-M Cat-Mi, several megabits per second for LTE Cat-l / Cat-4, and up to gigabit rates for 5G or future 6G protocols, as permitted by hardware and network conditions. Additional parameters, such as eDRX cycle, PSM timer, network reselection thresholds, device attach mode, APN configuration, signal quality reporting, and antenna selection, may also be selectable or dynamically managed. The processor may adjust, select, or negotiate these parameters automatically in response to application requirements, energy7constraints, feedback from the cellular network, or based on information received from other communication interfaces. In some embodiments, the interface may further support secure authentication (for example, SIM, eSIM, or iSIM provisioning), end-to-end encryption, integrity protection, network-initiated or device-initiated wakeup, and remote configuration or firmware updates. All such configuration parameters may be set manually, by remote command, or may be adaptively managed by the device in real time to optimize operational efficiency, energy consumption, coverage, and regulatory compliance.

[0128] In some embodiments, one or more communication interfaces may support nonterrestrial networks (NTN), including direct-to-satellite and satellite relay communication, using protocols such as 3GPP NTN, satellite NB-IoT, or proprietary links. The sensor device may transmit and / or receive data via low Earth orbit (LEO), medium Earth orbit (MEO), or geostationary (GEO) satellite constellations, including, but not limited to, those operated by Iridium, Globalstar, Inmarsat, Starlink, or similar providers. Communication parameters such as output power, frequency band (e.g., L-band, S-band. Ku-band, Ka-band), modulation scheme, and duty cycle may be selected or dynamically adjusted in accordance with operator requirements, regional regulations, or connectivity status.

[0129] In some embodiments, each of the communication interfaces 412, 410 and associated antennas 406. 408 may be associated with a plurality of communication protocols. For example the first antenna 406 and associated first communication interface 412 may be associated with a plurality of communication protocols and the second antenna 408 and associated second communication interface 410 may also be associated with a plurality of communication protocols that may be the same of different from the first antenna 406 and first communication interface 412. Furthermore, the polarization of the antennas 406, 048, the gain profiles (e.g., omnidirectional, directional, etc.) may be configured to maximize performance of the sensor device 200. Still further, each of the embodiments described herein may be used in conjunction with the anti-rotation element(s) 206 so as to direct the signals transmitted and received by the communication interfaces 412, 410 and associated antennas 406, 408. For example, the anti -rotational elements 206 of the present disclosure may be configured to ensure that the signals (e.g., radiation generated by the antennas 406, 408) is directed out of the material 107 within which the sensor device 200 is a least partially embedded.

[0130] As would be evident to one of ordinary skill in the art in light of the present disclosure, the power supply 401 (e.g., a battery) and processor 404 (e.g., a microcontroller or the like) may be communicably coupled with the plurality of communication interfaces 412, 410 and associated antennas 406, 408. The power supply 401 may be configured to supply power (e.g., electrical volage / current) to the sensor circuitry as described herein. The processor 404 (e.g.. a microcontroller or the like) may operate to at least partially control operation of the plurality of communication interfaces described herein Although described herein with reference to an example battery as the power supply 401, the present disclosure contemplates that any mechanism, techniques, components, etc. may be used to supply power to the sensor circuitry components described herein.

[0131] As described herein, the relative positioning of the sensor circuitry components may operate to improve the performance of the sensor device 200. For example, the plurality of communication interfaces 412, 410 and associated antennas 406, 408 may be positioned and tuned such that they have optimized performance in various specific materials including but not limited to impedance matching, frequency filtering, and voltage regulation. The configuration of the sensor circuitry components may also be configured such that they adapt to the changing properties of a material over its lifetime in order to maximize performance of the sensor device 200 For example, the communication interfaces 412, 410 and associated antennas 406, 408 that may, for example, communicate based on differing different protocols may be arranged on the PCB 402 to maximize performance and minimize interference with each other and also from other RF influencing components of the sensor device 200 (e.g. the battery 401). Antennas 406, 408 may also be individually tuned for different communication protocols, materials, and geographies using techniques including but not limited to impedance matching, frequency filtering, and voltage regulation applied to the antenna 406, 408 itself and / or other components on the PCB 402.

[0132] Although described and illustrated herein with reference to example wire antennas (e g., dipole antennas, monopole antennas, loop antennas, and / or helical antennas), the present disclosure contemplates that the antennas 406, 408 described herein may further include reflector antennas (e.g., parabolic antennas, hom antennas, etc.), array antennas (e.g., Yagi- Uda antennas, Log-periodic antennas, etc.), microstrip (e.g., patch) antennas, ceramic chip antennas and / or aperture antennas, without limitation. Furthermore, although descnbed herein with reference an example emission directions for the communication interfaces 412, 410 and associated antennas 406, 408, these components are configured to communication in either direction (e.g., the transmission of signals and receipt of signals). Furthermore, the present disclosure contemplates that the size and / or modes of the antennas 406, 408 may vary, such as varying antenna size based on dielectric constants, based on the intended application of the sensor device. Furthermore, the geometry' of the antennas 406, 408 described here may vary' (e g., ring antennas or the like) based on the intended application of the sensor device 200.

[0133] With continued reference to FIGS. 9A-10E. various example component configurations are provided that operate to minimize the interface between the communication interfaces 412, 410, the antenna 406, 408, the support structure, the power source 401, and / or the like. As described herein, the positioning of the first antenna 406 and / or the positioning of the second antenna 408 may be configured to minimize interference between the battery 401 and the first antenna 406 and / or between the battery 401 and the second antenna 408. Similarly,the positioning of the first antenna 406 and / or a positioning of the second antenna 408 may be configured to minimize interference between the first antenna 406 and the second antenna 408. Still further, in operation in which the sensor device 200 is disposed proximate a support structure 103, 103, the positioning of the first antenna 406 and / or the positioning of the second antenna 408 is configured to minimize interference between the support structure 101, 103 and the first antenna 406 and / or between the support structure 101, 103 and the second antenna 408. Said differently, in some embodiments, the sensor device 200 may operate to maximize the distance between the first antenna 406, the second antenna, 408, the battery 401 , and / or the support structure 101, 103.

[0134] As shown in FIG. 10A, for example, the first antenna 406 may be located along a lateral edge of the PCB 402, and the second antenna 408 may be disposed along the longitudinal direction of the PCB 402. As shown in FIG. 10B, the first antenna may be located along a lateral edge of the PCB 402, and the second antenna 408 may be located proximate the support structure 101, 103 (e.g., along the longitudinal end of the PCB 402 at an opposing end). As shown in FIG. 10C, the first and the second antennas 406, 408 may be positioned along opposing longitudinal edges of the PCB 402 and the battery 401 may be positioned along a lateral edge of the PCB. With reference to FIG. 10D, the second antenna 408 is posited vertically (e.g., substantially perpendicular with respect to a top surface of the PCB 402) and the first antenna 406 is disposed substantially perpendicular with respect to the first antenna 408. FIG. 10D further illustrates an embodiment with a third antenna 407 that may, for example, operate with the first communication protocol associated with the first antenna 406. As shown in FIG. 10E, in some embodiments, the battery 401 may be formed of a plurality of components and may be located on a bottom surface of the PCB 402. As w ould be evident to one of ordinary' skill in the art in light of the present disclosure, the arrangement, orientation, relative positioning, etc. of the components supported by the PCB 402 may vary to modify the performance characteristics of these components. Furthermore, the direction at which signals are transmitted (e.g., an emission direction) and received for the antenna 406, 408 may be configured to improved performance. In some embodiments, an emission direction of the first antenna 406 may be parallel with respect to an emission direction of the second antenna 408. In other embodiments, an emission direction of the first antenna 406 may be perpendicular with respect to an emission direction of the second antenna 408.Example Tuning and Antenna Radiation

[0135] With reference to FIGS. 18-21B, various antenna gain, tuning performance, etc. are illustrated. As shown in FIG. 18, for example, the antenna 406. 408 of the sensor device may be tuned for communication 1200 (e.g., transmission and receipt of data) in concrete (e.g., an example material 107). The S parameters and efficiency of such a tuning is illustrated in the left plots while the S parameters and efficiency of a tuning that is based only on air is illustrated in the right plots. As shown, the tuning for concrete exhibits improved performance. As shown in FIG. 19. an example tuning of S parameters 1300 is illustrated for wideband applications relative to narrowband applications As shown in FIG 20, example antenna gain relative impedance mismatch for broadband and narrowband applications 1400 is illustrated. With reference to FIG. 21A, an example plot of antenna gain relative the permittivity of the surrounding material 1500 is illustrated. With reference to FIG. 2 IB, an example plot of antenna gain relative Si l values 1500 is illustrated. As would be evident to one of ordinary skill in the art, the plots and charts illustrated in FIGS. 18.12B are merely example of the operation and tuning of some antennas (e.g., a broadband and narrow band antenna) that may be used by the sensor device 200 described herein. As such, the present disclosure contemplates that, regardless of the antenna, communication interface, etc. selected, the tuning of the particular components for concrete exhibits improved performance.

[0136] As illustrated in FIGS. 19-21B, the performance of an antenna within the sensor device 200, for example, may depend on whether the antenna is designed as a narrowband or broadband type, and on the electromagnetic properties of the environment in which it is deployed. In some embodiments, a narrowband antenna may be selected, tuned, or configured to achieve optimal impedance matching and low S parameter values at a specific frequency or within a narrow frequency band, such as for operation in hardened concrete, resulting in improved gain and efficiency within that environment. However, as the permittivity or impedance of the surrounding material changes (for example, in fresh or wet concrete, or in free space prior to installation), the narrowband antenna may become detuned, leading to higher S parameter values and reduced gain or efficiency, as exemplified in the plotted data of FIGS. 19 and 20.

[0137] Additionally or alternatively, in some embodiments, a broadband antenna may be provided, wherein the antenna is designed to maintain acceptable matching and gain across a wider range of frequencies or material permittivity. This may provide for more consistent performance as the concrete or host material evolves over time, or in deployments where the device transitions between air. fresh concrete, and hardened concrete. The broadband antennamay exhibit higher S parameter values in certain environments relative to a narrowband antenna but may provide more robust operation as the impedance of the environment varies.

[0138] Accordingly, in some embodiments, the selection of narrowband or broadband antenna type, and the associated tuning approach, may be determined based on the expected material conditions and performance priorities of a given deployment scenario. For example, where high-efficiency communication is critical during the initial pour or early curing phase, a broadband antenna may be preferred. Where maximum range or efficiency is desired in fully cured concrete, a narrowband antenna optimized for that environment may be selected These embodiments may be further combined with adaptive tuning, switching between antennas, or other matching network architectures as described elsewhere herein, to ensure robust and reliable wireless communication throughout all stages of material evolution.

[0139] With reference to FIGS. 22-25 and 27, various sensor circuitry configurations are illustrated with associated parameters. As shown, E may refer to the permittivity associated with the particular component and t may refer to thickness (e.g., physical dimension) of the component. As would be evident to one of ordinary skill in the art in light of the present disclosure, these interference and boundary illustrations may be for non-magnetic materials so that the permittivity (s) is directly related to the impedance Z. The intensity I of the example RF wave is also illustrated. In FIGS 22-23, the sensor device is configured such that the antenna 406 is positioned on an opposing surface of the PCB 402 relative the battery 401. In FIG. 24, the antenna 406 is positioned at least partially within the PCB 402. In FIG. 25 A, the PCB 402 further includes a spacer 411 (e.g., platform or the like) that is configured to add vertical distance between the surface of the PCB 402 and the antenna 406. FIG. 46 illustrates a graphical representation 1600 of the RF wave interaction at example boundary between the internal medium (e.g.. air within the housing 201) and the second medium (e.g., example material 107). In FIG. 25B, the PCB 402 further includes a spacer 411 (e.g., platform or the like) that is configured to add vertical distance between the surface of the PCB 402, a ground shielding element 409 as described herein, and the antenna 406. FIG. 46 illustrates a graphical representation 1600 of the RF wave interaction at example boundary between the internal medium (e g., air within the housing 201) and the second medium (e.g., example material 107). FIG 27 illustrate the intensity of the RF wave transmitted by the antenna 406 that account for these various characteristics of the materials (e.g., layers) that form the sensor device 200. Although described herein with reference to the air within the sensor device housing 201, the present disclosure contemplates that any internal medium may be present. Although illustrated in FIGS . 22-25 and 27 with the example antenna 406 proximate the support structure 101, 103,the present disclosure, as described above, contemplates that the components associated or supported by the PCB 402 may be located at any location within the housing 201 without limitation.

[0140] In some embodiments, as illustrated in FIGS. 22-27, the physical arrangement and electromagnetic properties of the sensor device 200 may be specifically configured to minimize RF multipath interference, enhance signal transmission, and optimize wireless performance in challenging environments such as concrete with embedded steel rebar. As shown in FIG. 27, when the antenna 406 is positioned in close proximity to rebar 101, uncontrolled RF reflections may occur, leading to multipath interference. This interference can manifest as inconsistent or reduced emitted RF wave intensity I E and transmitted intensity I T, which may degrade communication performance and data integrity In some embodiments, the device may lack sufficient shielding, or the antenna 406 may be too close to the rebar 101 or to the perpendicular rebar 103, resulting in increased susceptibility to multipath effects. It will be appreciated that rebar 101 and 103 may be provided in different radii or diameters, and in some example embodiments, rebar 103 may span less than the height of the device housing, whereas in other embodiments it may span equal to or greater than the height of the device housing, potentially making RF interference more or less pronounced depending on geometry.

[0141] To address this, in some embodiments, one or more ground shielding elements 409 (see, e.g., FIG. 9B, 25B) may be positioned within the device housing to serve as electromagnetic shields between the antenna 406 and the rebar 101, as well as between the antenna and other internal components such as the battery 401 and PCB 402. Such shielding elements 409 may be implemented as grounded copper pours, metallic plates, or conformal coatings, and may be electrically connected to device ground. In an example shown in FIG. 25B, a shielding layer is disposed above the PCB 402 and battery 401 but below the antenna 406, thus reducing the impact of rebar 101. The use of such shielding may reduce unwanted downward or lateral radiation, promote a more controlled and preferably hemispherical radiation pattern (e.g., as targeted in element 2000 of FIG. 31), and thus minimize multipath interference and signal loss caused by reflections from rebar or other conductive structures.

[0142] Additionally or alternatively, in some embodiments, the antenna 406 may be spaced from the interior surface of the housing 202 (e g , FIG 22-24), such that there is a sufficient air gap or internal medium between the antenna and the housing. This spacing may be at least 5 mm in one example, but may be optimized according to application, so as to reduce fringing effects, avoid near-field coupling with the housing, and ensure that the emitted RF wave is substantially in its far field at the boundary with the housing. This improves the efficiency ofwave transmission into the external material, particularly in applications where the housing is embedded in lossy or conductive media such as concrete.

[0143] In further embodiments, the dielectric properties (permittivity s, impedance Z) and physical thickness t of each device layer, which may include battery 401 (layer 0), PCB 402 (layer 1), antenna 406 (layer 2), the internal medium (layer 3), housing 204 (layer 4), and external material 202 (layer 5) as set out in FIT.22 may be selected or engineered to minimize signal loss from impedance mismatch and boundary reflections. As illustrated in the right-hand side of FIG 22 and the interaction diagram of FIG 26, reflections may arise at each material boundary, with the degree of reflection governed by the difference in impedance Z or permittivity s between layers. In some embodiments, variable-permittivity or gradient dielectric layers may be employed (for example, via a gradient in the filler content or polymer composition across the housing thickness), or a dedicated impedance matching layer may be introduced as a coating on the inside and / or outside of the enclosure. In one example, this may take the form of a quarter- wavelength (X / 4) thick or any odd integer multiple thereof of a high- dielectric layer, chosen such that the physical thickness is compatible with device constraints while still providing an effective impedance transformer to reduce standing waves and enhance transmission into the external material. For example, using a high-dielectric layer enables the required X / 4 or odd multiple thickness to be reduced to just a few millimeters at frequencies such as 800 to 1000 MHz or 2.4 GHz, thereby making practical integration into compact sensor devices feasible.

[0144] In yet further embodiments, the geometric arrangement of these elements may be dynamically adapted or pre-configured for the intended deployment environment. For example, the shielding element 409 may be extended or shaped to cover only those regions most susceptible to rebar-induced reflection (such as the lower or lateral surfaces adjacent to rebar 101 or the end of the device adjacent to rebar 103). In another example, the position of the antenna 406 along the PCB 402 may be offset from the battery 401 or other large conductors, maximizing vertical or lateral distance to minimize coupling and further mitigate detuning or interference. In yet another embodiment, and as an alternative to adding shielding on the side adjacent rebar 103, the antenna 406 may be mounted (in any of the configurations discussed herein) on the end of the device housing furthest away from the rebar 103, while the battery 401 may be mounted on the end closest to the rebar 103. This physical separation may further reduce the susceptibility of the antenna 406 to interference caused by nearby rebar or other conductive structures, including those that do not span the full height of the device housing.

[0145] All of the above configurations may be determined or tuned in light of applicationspecific requirements, such as the type and spacing of rebar, the dielectric properties of the concrete, and the frequency of operation of the antenna, and may be empirically or computationally optimized to achieve target performance.

[0146] It will be understood by those skilled in the art that these embodiments may be practiced individually or in any combination, and that they are not limited to the specific examples shown in the figures, but rather may be adapted to any wireless sensor device deployed within or adjacent to conductive or lossy materials

[0147] In some embodiments, the sensor device 200 may comprise two antennas disposed on PCB 402: a first antenna 408 which may be optimized for LoRa or sub-GHz wireless (operating around 800 to 950 MHz or similar, and may be larger, as illustrated) and a second antenna 406 optimized for BLE communication (operating at or around 2.4-2.5 GHz, and therefore may be smaller). The physical layout of PCB 402 and the overall device geometry may be specifically configured such that each antenna is positioned to maximize its spatial separation from sources of multipath interference and absorption, including rebar 101 or 103 (which may vary in radius and extent relative to the sensor housing, as described elsewhere), as well as from other conductive components such as the battery 401 and / or from each other. For example, the LoRa antenna 408 may be positioned at one distal end of PCB 402, furthest from the battery 401 and rebar 103, while the BLE antenna 406 may be positioned nearer the center of the perpendicular edge of the PCB. maximizing its distance from rebar 103 while maintaining adequate separation from antenna 408.

[0148] In other embodiments, where device geometry' or deployment constraints limit available separation, the two antennas 408 and 406 may be disposed adjacent to one another, either parallel or perpendicular to each other, and positioned either on the same level (coplanar) or stacked vertically (with one antenna positioned above or below the other, for example using a dielectric spacer or support). In such configurations, careful tuning of each antenna may be employed so that their resonant frequencies are well separated, and the design may ensure that the resonant frequencies (including any harmonics) of one antenna do not coincide with the resonant frequency (including any harmonics) of the other. This may be achieved through optimization of antenna length, geometry, ground plane design, and the use of discrete matching networks or frequency-selective filters incorporated into the PCB layout for each antenna. Furthermore, the use of orthogonal polarization between the two antennas may further minimize coupling and mutual interference, enabling robust simultaneous operation even in close proximity. In one embodiment, the spacer between the two antennas may be comprisedof air, such that the antennas are surrounded by a medium with a relative permittivity closely matched to its free-space tuning, thereby minimizing detuning and maximizing transmission efficiency into the external environment

[0149] In embodiments where the geometry of the installation or application constrains the ability to maintain sufficient separation between one or both antennas and the rebar, one or more ground shielding elements 409 may be selectively disposed between each antenna and the anticipated rebar position. These ground shielding elements may be individually dimensioned and positioned for each antenna, and may be extended, for example, laterally along the PCB edge or vertically as a grounded metallic plate, to provide targeted shielding for either or both antennas. In cases where both antennas are near a common rebar axis (for example, rebar 101 running along the bottom of the housing), a single continuous groundplane or shielding plate may be disposed beneath both antennas, or discrete elements may be located beneath each antenna. Additionally or alternatively, shielding may be employed to minimize interference or detuning from proximity to the battery 401, such that each antenna has an optimal local electromagnetic environment.

[0150] In further embodiments, the device architecture may be optimized to ensure that both LoRa and BLE antennas are in the far field with respect to the housing’s internal surface (i.e., the distance between the antenna element and the housing surface is sufficient which in some examples may require at least several millimeters (e g. 5mm) to avoid fringing fields and to ensure that the radiated RF wave transitions cleanly through the housing into the external medium. This reduces the nsk of near-field coupling, improves transmission efficiency, and minimizes the impact of impedance mismatch at the housing boundary' for both frequency bands. The thickness and permittivity' of internal dielectric spacers or layers between each antenna and the housing may be individually selected to account for the respective antenna’s frequency, maximizing radiation efficiency for both bands.

[0151] Because impedance-matching conditions and standing wave minimization are frequency-dependent, embodiments with two antennas operating at very’ different frequencies may incorporate frequency-selective or adaptive impedance-matching layers. In one embodiment, the portion of the housing or an internal coating adj acent to the BLE antenna may be formed from a material or composite optimized for 2.4 GHz operation (e g , with a specific thickness and dielectric constant to serve as an effective k / 4 transformer at 2.4 GHz), while the portion adjacent to the LoRa antenna may use a distinct material or coating optimized for the LoRa frequency. Additionally or alternatively, adaptive or tunable materials (such as variablepermittivity polymers or switchable composite coatings) may be employed to dynamicallymatch the impedance for each antenna, further reducing reflection and maximizing transmission efficiency for both communication links. These layers may also be physically separated or may transition in permittivity or thickness across the housing, so that each antenna is provided with a locally optimized impedance-matching environment.

[0152] Although the primary goal is to maximize distance from rebar and battery' and to provide optimal shielding and impedance matching for both antennas, the design may further support minimal inter-antenna coupling by using dedicated grounded partitions between the two antennas, or by taking advantage of frequency diversity and orthogonal polarization In embodiments where space constraints require the antennas to be placed adjacent, careful PCB layout and the selective use of frequency-optimized ground shielding elements may still ensure robust dual-band operation without substantial mutual interference.

[0153] In some embodiments, the enclosure of the sensor device may be constructed with a substantially constant thickness, for example 2-5 mm, from a material of sufficiently high dielectric constant such that, at the operating frequency of the relevant antenna, this enclosure thickness above each antenna acts as a quarter-wavelength (X / 4) impedance transformer into the external material (e.g., concrete). Additionally or alternatively, disposed immediately above each antenna (inside the enclosure and extending up to the inner surface of the housing), there may be provided a volume of one or more dielectric materials, wherein each is selected or engineered to provide an optimized impedance transition between the antenna and the external environment. For example, above the LoRa antenna 408. a first dielectric insert or layer may have a permittivity and thickness tuned for efficient RF coupling at LoRa frequencies, while above the BLE antenna 406, a different insert may be used, optimized for BLE frequencies. In some embodiments, this dielectric volume may comprise one or more materials stacked or graded in permittivity, and the antenna structure and associated tuning network may be specifically matched to the impedance profile thus presented. This arrangement allows the enclosure and internal dielectric structures to act together as an integrated impedance transformer, minimizing reflection losses at both the antenna-to- enclosure and enclosure-to-material boundaries, and ensuring efficient operation in both air and concrete environments.

[0154] In further embodiments, antenna matching may be achieved or refined using a pi network or other RF matching circuitry' implemented on PCB 402, comprising one or more variable capacitors, varactors, fixed or chip inductors, or other tunable components, allowing each antenna to be tuned for the specific impedance of its associated dielectric stack and for the expected transition into concrete. The matching network may be static, or dynamicallyadjustable in response to deployment conditions, so as to maximize transmission efficiency and minimize return loss across the relevant frequency bands.

[0155] Taken together, these embodiments enable robust, dual-band wireless communication from embedded sensor devices, with both LoRa and BLE antennas shielded from rebar, battery', and housing effects, and provided with optimal far-field and impedancematching conditions, even when co-located in a compact enclosure deployed in challenging environments such as reinforced concrete.

[0156] With reference to FIGS 28-31, various radiation patterns are illustrated As shown in FIG. 28, an example free space radiation pattern 1700 is illustrated in which the maximum gain is directed upwards. As shown in FIG. 29, an example radiation pattern 1800 is illustrated with relatively poorer performance with the maximum gain provided in a less than ideal direction. As shown in FIG. 30, an example radiation pattern 1900 is illustrated with improved performance with the maximum gain provided out of the material 107 (e.g., concrete) and away from the support structure 101, 103 (e g., rebar mesh). As shown in FIG. 31, an example radiation pattern 2000 is illustrated in which the maximum gain is aimed away from the material 107. The present disclosure contemplates that the gam profile, parameters, characteristics, etc. of the communication interfaces and antennas described herein may' be tuned to account for any sensor device 200 implementation.Example Sensor Environment and Circuitry

[0157] As descnbed above, the sensor device 200 may include circuitry', networked processors, or the like configured to perform some or all of the apparatus-based (e.g., building material sensing-based) processes described herein and may be any' suitable controller, network card, graphical processing unit (GPU), microcontroller, computing device, network server, and / or other type of processing device. Example embodiments contemplated herein may have various form factors and designs but will nevertheless include at least the components illustrated in FIGS 9A-9B, 13, and 14 and described in connection therewith. Despite the many arrangements contemplated herein, the sensor device 200 is shown and described herein as a single computing device for ease of explanation and to avoid unnecessarily overcomplicating the disclosure

[0158] FIG. 13 illustrates an example system for implementing the sensor devices 200 described herein (e.g., system 900). It will be appreciated that the system 900 is provided as an example of an embodiment(s) and should not be construed to narrow the scope or spirit of the disclosure. The depicted system 900 of FIG. 13 may include a server 902 communicablycoupled with one or more sensor devices 200 via a network 904. The server 902 may be configured to control or otherwise influence operations of the one or more sensors device 200 and as described hereafter and may be configured to receive from the one or more sensor devices 200 datasets comprising data entries associated with various measurements (e.g., measurement types) of a material. Still further, the server 902 may comprise or be communicably coupled with one or more databases 108. In some embodiments, the system 900 may further include various user devices 906 (e.g.. mobile phones, laptop computers and / or the like) by which a user associated with the system 900 may interact with the system 900, such as via a user interface of the user device 906.

[0159] Although described hereinafter with reference to a server 902, the present disclosure contemplates that the operations described hereafter with reference to the server 902 may be performed by any computing device, system orchestrator, central processing unit (CPU), and / or the like. Furthermore, although illustrated as a single device (e.g., server 902), the present disclosure contemplates that any number of distributed components may collectively be used to form the server 902 and / or to perform the operations associated with the server 902. In some embodiments, the server 902 may comprise, in whole or in part, one or more of the sensor devices 200 and / or the user device(s) 906. In any embodiment, the server 902 may be configured to, based upon the data received from the various sensor devices 200 and / or databases 108, generate a material identifier associated with a material, generate sensor context awareness data, generate and / or modify a structural progress flow, generate a first dataset, generate a second dataset, generate an attnbution dataset, and / or the like as described herein.

[0160] To facilitate or otherwise enable this connectivity between devices, the communication network 904 may be any means including hardware, software, devices, or circuitry that is configured to support the transmission of traffic (e g., data, signals, and / or the like) between components of the system 900. For example, the communication network 904 may be formed of components supporting wired transmission protocols, such as, digital subscriber line (DSL), Ethernet, fiber distributed data interface (FDDI), or any other wired transmission protocol obvious to a person of ordinary skill in the art. The communication network 904 may also be comprised of components supporting wireless transmission protocols, such as Bluetooth, IEEE 802 11 (Wi-Fi), or other wireless protocols obvious to a person of ordinary skill in the art. In addition, the communication network 904 may be formed of components supporting a standard communication bus, such as, a Peripheral Component Interconnect (PCI), PCI Express (PCIe or PCI-e), PCI extended (PCI-X), Accelerated Graphics Port (AGP), or other similar high-speed communication connection. Further, thecommunication network 904 may be comprised of any combination of the above-mentioned protocols. In some embodiments, such as when one or more sensor devices 200 and the server 902 are formed as part of the same physical device, the communication network 904 may include the on-board wiring providing the physical connection between the component devices. In some embodiments, one or more intermediate networking devices, such as a hub 910 may be used. The hub 910 may operate to transmit and / or receive data over network 904 and / or directly with the sensor device 200.

[0161] In some embodiments, the system 900 may include one or more databases 108 configured to store data generated by the server 902, the one or more sensor devices 200, or the like. The database(s) 108 may be accessible by the server 902, such as to retrieve data for comparison with data generated by the one or more sensor devices 200. In some embodiments, the database(s) may operate as a repository for datasets associated with properties of materials (e g., cementitious mixtures), environments associated with materials, and / or any other context associated with materials as described herein. Furthermore, the database(s) 108 may be configured to store data associated with performance of the machine learning models and / or artificial intelligence algorithms described herein. The present disclosure contemplates that the database(s) 108 described herein may be configured to store any of the data entries generated by the sensor devices 200 of the present disclosure, data associated with operations performed on the data entries generated by the sensor device 200, and / or the like without limitation.

[0162] Although illustrated in FIG. 13 as separate entities, the present disclosure contemplates that the server 902 and the one or more sensor device 200 may, in some embodiments, include common components and / or functionality. By way of example, the embodiments of the present disclosure are described hereinafter with reference to the server 902 performing the various material related operations and analyses based on data entries generated by the sensor devices 200. The present disclosure, however, contemplates that, in some embodiments, the sensor devices 200 may be configured to, in whole or in part, perform the material operations described herein. Said differently, the present disclosure contemplates that each of the devices described herein may include the components necessary to perform one or more of the operations described hereinafter. Furthermore, although illustrated in FIG. 13 with one or more sensors devices 200 communicably coupled with the server 902 via the network 904, the present disclosure contemplates that the system 900 may include any number of intermediary devices communicably coupled within the system 900 (e g., hubs 910 or the like). By way of a non-limiting example, the system 900 may include various host devices,gateway devices, hubs 910, etc. that receive data generated by the sensor devices 200 and provide this data to the server 902.Non-Terrestrial Networks

[0163] In some embodiments, the sensor device 200 may comprise one or more communication interfaces configured for operation with non-terrestrial networks (NTN), terrestrial networks, or both (e.g., network 912). A non-terrestrial communication interface may include a radio module and antenna capable of direct communication with satellite networks 912, such as Low Earth Orbit (LEO) constellations (e.g., Starlink, Iridium, Swarm), Medium Earth Orbit (MEO) satellites, Geostationary Earth Orbit (GEO) satellites, or High Altitude Pseudo Satellites (HAPS). The antenna subsystem may be adapted for single-band, multi-band, or beam-steering operation to support NTN-specific radio frequencies (e.g., S- band, L-band, Ku-band), with the processor or radio module configured to perform satellite beam acquisition, Doppler compensation, and time-of-flight management. The communication interface may also support satellite-specific physical layer adaptations, such as extended timing advance. HARQ, or adapted synchronization sequences, in accordance with satellite loT protocols or 3GPP NTN releases (for example, 3GPP Release 17 or later).

[0164] Additionally or alternatively, in some embodiments, the sensor device 200 may include a cellular communication interface, wherein the hardware and firmware are provisioned for both terrestrial and non-terrestrial network operation. For example, the communication interface may support LTE-M, NB-IoT, 5GNR, and subsequent 6G protocols, and may dynamically switch between ground-based cellular networks and satellite cellular connectivity using a shared or multi-band antenna and additionally or alternatively using a single SIM or eSIM. The processor 404 may periodically scan for available networks, analyze system information broadcast by terrestrial base stations or satellite beams, and selectively register or attach to the optimal network based on criteria such as signal strength, network identifiers, configuration settings, power availability, or cost. Network selection, authentication, and handover may be managed by the device firmware in accordance with 3GPP NTN protocol stacks, allowing seamless roaming or handover between terrestrial and non-terrestrial domains as network conditions evolve

[0165] Additionally or alternatively, the communication interface may execute network attach and link acquisition, synchronizing to terrestrial towers or satellite reference signals, and handling beam steering or beam tracking (either electronically or mechanically) to maximize link reliability. The sensor device 200 may compensate for Doppler effects, variablepropagation delay, and elevated link budgets associated with NTN, employing adaptive modulation, coding schemes, and timing controls as dictated by network type and real-time measurements.

[0166] In one embodiment, the sensor device 200 may comprise a single communication interface capable of dynamically selecting between terrestrial and non-terrestrial operation. The processor may scan for both network types, evaluate signal metrics and network broadcasts, and attach to the preferred network automatically or under remote control. Alternatively, in some embodiments, the device may include two or more communication interfaces 412, 410 — wherein a first interface is dedicated for terrestrial operation (for example, cellular, Wi-Fi, BLE, or LoRa), and a second interface is dedicated for non-terrestrial (satellite) communication. The processor 404 may select which interface to use for any given transmission based on real-time coverage, operational policy, message criticality, latency requirements, energy considerations, or device configuration. In further embodiments, both interfaces may operate concurrently to provide redundant, load-balanced, or failover communication paths.

[0167] In another embodiment, the sensor device 200 may comprise a first communication interface configured for short-range wireless connectivity (for example, Bluetooth Low Energy), and a second communication interface comprising a cellular radio module capable of selectively connecting to either terrestrial or non-terrestrial cellular networks using a single shared SIM or eSIM and a multi-band or switchable antenna. In this configuration, the processor may use the first (Bluetooth) interface for local operations such as device registration, commissioning, or configuration in proximity' to an external device (such as a mobile phone or commissioning tool). The second (cellular) interface may be selectively activated to transmit sensor measurement records, status updates, or command messages over terrestrial or satellite cellular networks based on dynamic assessment of network availability, user or remote configuration, or operational policy. This enables seamless, context-driven adaptation of communication strategy' for global or infrastructure-free deployment scenarios. This configuration is merely illustrative and may be generalized to any embodiment in which at least one communication interface is configured for non-terrestrial network operation, and any other communication interface may comprise a terrestrial (short-range or long-range), satellite, or other network interface, such that combinations of terrestrial and non-terrestrial, or multiple non-terrestrial, interfaces may' be employed for selective communication.

[0168] During normal operation, the sensor device 200 may periodically sample one or more sensor elements (for example, temperature, humidity, impedance, strain, or otherparameters) and associate each measurement with a timestamp. The timestamp may be generated using an internal real-time clock or synchronized using external sources, such as GNSS (e g., GPS time) received via the satellite modem, or network time received via terrestrial or NTN protocols. The processor may generate measurement records with metadata, including device identifier, measurement sequence number, sensing element ID, and data quality flags, and may store or queue these records in local memory pending transmission. These may use any of the queue or buffering embodiments described elsewhere in this disclosure as applicable Data packets may be transmitted individually, or batched and compressed for efficiency, with the transmission policy considering factors such as predicted satellite pass windows, network availability, power constraints, and data latency requirements.

[0169] When operating over NTN 912, the processor 404 may schedule data transmission according to predicted satellite visibility, utilizing stored ephemeris or broadcast almanac data. If the NTN is unavailable (for example, satellite not currently overhead), the device may buffer data locally in the queue until the next transmission opportunity, using deep sleep or low-power modes to minimize energy draw. Each measurement record or message may include an acknowledgement status indicator, updated upon receipt of an acknowledgement message from the remote server or platform via NTN or terrestrial link. In some embodiments, where acknowledgements are received in order, the processor may maintain a pointer or cursor in memory that indicates the position of the most recently acknowledged measurement record within the local queue, such that all records preceding the pointer are considered successfully transmitted and acknowledged. If no acknowledgement is received after a defined number of retries, the processor may implement an adaptive backoff and retry policy and may trigger user alerts or switch communication strategy as needed.

[0170] In some embodiments, the sensor device 200 may support dynamic switching between satellite operators or network types based on coverage, reliability, or cost, and may report its operational status, location (via GNSS), and network selection to the remote platform. Derived measurements, such as material maturity or compressive strength, may be determined and transmitted alongside raw sensor data, with timestamps and / or geolocation metadata included for accurate remote analysis. In some embodiments, the sensor device 200 or associated platform may also ingest external data, such as satellite imagery or site geometry, to support advanced analytics or contextual analysis.

[0171] In some embodiments, configuration updates, remote commands, or firmware update packages may be received over either terrestrial or non-terrestrial communicationinterfaces, and may trigger reconfiguration of device policies, update communication schedules, or modify operational parameters in response to remote instruction.

[0172] In some embodiments, the queue or buffer may also accommodate status messages, logs, or event notifications, enabling the device to manage diverse types of data transmission in accordance with network and operational requirements. Additionally or alternatively, the power source for the sensor device or for a hub communicably coupled to it may include energy harvesting circuitry such as solar panels. These embodiments enable robust, reliable data extraction, storage, and remote communication from sensor devices deployed in remote, embedded, or infrastructure-challenged environments.

[0173] As illustrated in FIG. 14, the sensor device 200 may include sensor circuity 1000 including a processor 1002, a memory 1004, communications circuitry 1008. and input / output circuitry 1006. Although components 1002-1008 are described in some cases using functional language, it should be understood that the particular implementations necessarily include the use of particular hardware. It should also be understood that certain of these components 1002- 1008 may include similar or common hardware. For example, tw o sets of circuitry may both leverage use of the same processor 1002. memory 1 04. communications circuitry 1008, or the like to perform their associated functions, such that duplicate hardw are is not required for each set of circuitry’. The use of the term “circuitry” as used herein includes particular hardware configured to perform the functions associated with respective circuitry described herein. As descnbed in the example above, in some embodiments, vanous elements or components of the circuitry may be housed within the sensor device 200. It will be understood in this regard that some of the components described in connection with the sensor device 200 may be housed within one of these devices, w hile other components may' be housed within another of these devices, or by yet another device not expressly illustrated (e g., one or more centralize computing devices).

[0174] Of course, while the term “circuitry” should be understood broadly to include hardware, in some embodiments, the term “circuitry” may also include software for configuring the hardware. For example, although “circuitry” may include processing circuitry', storage media, network interfaces, input / output devices, and the like, other elements of the sensor device 200 may provide or supplement the functionality of particular circuitry /

[0175] In some embodiments, the processor 1002 (and / or co-processor or any other processing circuitry assisting or otherwise associated with the processor) (e g., the processor 404 of FIGS. 9A-10D) may be in communication with the memory 1004 via a bus for passing information among components of the sensor device 200. The memory 1004 may be non-transitory and may include, for example, one or more volatile and / or non-volatile memories. For example, the memory may be an electronic storage device (e.g.. anon-transitory computer readable storage medium). The memory' 1004 may be configured to store information, data, content, applications, instructions, or the like, for enabling the sensor device 200 to carry out various functions in accordance with example embodiments of the present disclosure.

[0176] The processor 1002 (e.g., the processor 404 of FIGS. 9A-10D) may be embodied in a number of different ways and may. for example, include one or more processing devices configured to perform independently Additionally, or alternatively, the processor may include one or more processors configured in tandem via a bus to enable independent execution of instructions, pipelining, and / or multithreading. The use of the term ‘‘processing circuitry "’ may be understood to include a single core processor, a multi-core processor, multiple processors internal to the security circuitiy, and / or remote or ‘‘cloud” processors.

[0177] In an example embodiment, the processor 1002 (e.g., the processor 404 of FIGS. 9A-10D) may be configured to execute instructions stored in the memory 1004 or otherwise accessible to the processor 1002. Alternatively, or additionally, the processor 1002 may be configured to execute hard-coded functionality. As such, whether configured by hardware or by a combination of hardware with software, the processor 1002 may represent an entity (e.g., physically embodied in circuitry') capable of performing operations according to an embodiment of the present disclosure while configured accordingly. Alternatively, as another example, when the processor 1002 (e.g., the processor 404 of FIGS. 9A-10D) is embodied as an executor of software instructions, the instructions may specifically configure the processor 1002 (e.g., the processor 404 of FIGS. 9A-10D) to perform the algorithms and / or operations descnbed herein when the instructions are executed.

[0178] The sensor device 200 may further include input / output circuitry’ 1006 that may, in turn, be in communication with the processor 1002 to provide output to a user and to receive input from a user, user device, or another source In this regard, the input / output circuitry 1006 may comprise a display that may be manipulated by an application. In some embodiments, the input / output circuitry' 1006 may also include additional functionality such as a keyboard, a mouse, a joystick, a touch screen, touch areas, soft keys, a microphone, a speaker, or other input / output mechanisms The sensor device 200 comprising the processor 1002 may be configured to control one or more functions of a display through computer program instructions (e g., software and / or firmware) stored on a memory accessible to the processor (e.g., the memory 1004 and / or the like).

[0179] The communications circuitry 1008 may be any means such as a device or circuitry embodied in either hardware or a combination of hardware and software that is configured to receive and / or transmit data from / to a network and / or any other device, circuitry, or module in communication with the sensor device 200. In this regard, the communications circuitry 1008 may include, for example, a network interface for enabling communications with a wired or wireless communication network. For example, the communications circuitry 1008 may include one or more network interface cards, antennae, buses, switches, routers, modems, and supporting hardware and / or software, or any other device suitable for enabling communications via a network. Additionally, or alternatively, the communication interface may include the circuitry for interacting with the antenna(s) to cause transmission of signals via the antenna(s) or to handle receipt of signals received via the antenna(s). These signals may be transmitted by the sensor device 200 using any of a number of wireless personal area network (PAN) technologies, such as Bluetooth® vl.O through v3.0, Bluetooth Low Energy (BLE), infrared wireless (e g., IrDA), ultra-wideband (UWB), induction wireless transmission, LoRA, or the like. In addition, it should be understood that these signals may be transmitted using Wi-Fi, Near Field Communications (NFC), Worldwide Interoperability for Microwave Access (WiMAX) or other proximity-based communications protocols. For example, the communication circuitry71008 may include the antennas 406, 408 of FIGS. 9A-10D.

[0180] As used herein, the term “computer-readable medium” refers to non-transitory storage hardware, non-transitory7storage device or non-transitory computer system memory that may be accessed by a controller, a microcontroller, a computational system or a module of a computational system to encode thereon computer-executable instructions or software programs. A non-transitory “computer-readable medium” may7be accessed by a computational system or a module of a computational system to retrieve and / or execute the computerexecutable instructions or software programs encoded on the medium. Exemplary non- transitory7computer-readable media may include, but are not limited to, one or more types of hardw are memory7, non-transitory7tangible media (for example, one or more magnetic storage disks, one or more optical disks, one or more USB flash drives), computer system memory7or random-access memory (such as, DRAM, SRAM, EDO RAM), and the like.Example Sensor Device Operations

[0181] FIG. 32 illustrates a flow chart containing a series of operations for operating the sensor device(s) described herein (e.g., method 2100). The operations illustrated in FIG. 32 may, for example, be performed by, with the assistance of, and / or under the control of anapparatus (e.g.. system 900, server 902, mobile devices 906, etc.), as described above. In this regard, performance of the operations may invoke one or more of the components described above with reference to FIGS. 9A-9B, 13, and 14 (e.g., processor 404, processor 1002, etc.).Initialization

[0182] As shown in operation 2102, the system 900 may initialize (e.g., perform one or more initialization operations) the sensor device 200. As would be evident to one of ordinary skill in the art, the sensor device 200 of the present disclosure may, when implemented, require initialization before operating. Although described herein with reference to initialization operations, the present disclosure contemplates that these operations may include activation, registration, software updating, etc. for the sensor device 200. For example, in some embodiments, a user may scan a QR code on the surface of the housing 201 and an example first communication interface 412 and first antenna 406 may scan until detecting the device (e.g., the scanning device of the QR code). In such an embodiment, the first communication interface 412 may be associated with a BLE based communication protocol. An application, such as associated with a mobile device 106 of the user, may connect to the sensor device 200 via the first communication interface 412, reads the firmware version of the sensor device 200, retrieves, if applicable, an updated firmware version, and causes updating of the sensor device 200. Thereafter, the initiation operation of 2102 may activate (e.g., or shift power state) of the first communication interface 412 and / or the second communication interface 410. In some embodiments, the initialization operations may further include receiving data by the sensor device 200 to configure example sensing elements 300 (e.g., tails or the like).

[0183] As shown in FIGS 15A-16C, for example, a mobile device 906 may perform an image capturing operation, via a camera of the mobile device 906 or the like, of the sensor device 200 that captures a QR code on the surface of the housing 201. The image capture operation illustrated in FIGS 15A-15B may, in some embodiments, begin the initiation operation(s) 2102. As shown in FIGS. 16A-16C, the communication interfaces 412, 410 of the sensor device may be initialized, activated, etc. via this process. As described above, the image capture operation of FIG. 16A may establish a communication link (e.g., communicably couple) the mobile device 906 and the sensor device 200, such as via the first communication interface 412 and associated first antenna 406 (e g., via an example BLE protocol). As shown in FIG. 16B, the mobile device 906 and sensor device 200 may be communicably coupled via the first communication interface 412 and, as shown in FIG. 16C. the first and / or second communication interfaces 412, 410 may then be activated. As such, operation of the firstcommunication interface 412 may at least partially impact, control, etc. operation of the second communication interface 410.

[0184] In one embodiment, the sensor device 200 may initially operate in a low power or pre-activation state, in which only a first communication interface (for example, Bluetooth Low Energy) is periodically enabled (e.g. for brief advertisements) to permit device discovery', pairing, or activation by an external device such as a mobile phone, hub, or commissioning tool. During this pre-activation state, the processor 404 may maintain all other communication interfaces (for example, LoRa, cellular, or Wi-Fi) in a powered-down or sleep mode to minimize energy consumption. Upon receipt of a valid activation command, registration packet, or credential exchange via the first communication interface, the processor may transition the device into an activated operational mode. In this activated mode, the device 200 may enable one or more additional communication interfaces (such as LoRa, cellular, or WiFi) and may increase the output power, advertising frequency, or connection interval of the first communication interface 412, thereby enabling regular or scheduled measurement transmission, configuration updates, or two-way communication with external infrastructure. The transition from low to high power mode and the selective activation of one or more communication interfaces 412, 410 may be managed according to a policy stored on the device or received via remote instruction.Registration

[0185] In another embodiment, such as illustrated in FIGS. 15A-16C, a registration or initialization process for the sensor device may be executed over a first communication interface (for example, Bluetooth Low Energy) or over a plurality of communication interfaces 412, 410. During registration, a unique name, identifier, or descriptive label may be associated with the device, which may be indicative of the device’s 200 installation location, application, or user-defined designation. This association may be performed locally via a commissioning mobile application or tool, or remotely by a server or cloud platform. The assigned name or identifier may be stored directly on the sensor device in non-volatile memory, in a remote database accessible over one or more communication interfaces, or both. As part of the registration or initialization workflow, the processor 404 may initiate or schedule the collection of sensor element 300 measurements and configure the measurement transmission policy for one or a plurality' of communication interfaces. For example, the processor 404 may automatically begin sampling the sensor elements and queuing measurement records for transmission, with the transmission logic determined by application requirements, detectednetwork conditions, or remote configuration received during registration. Registration may also include time synchronization, device configuration, firmware updates, or association with a project or structure in a remote platform, with each of these operations executed over the selected communication interface(s) 412, 410.

[0186] In one embodiment , the sensor device 200 may include a machine-readable code, such as a QR code or barcode, affixed to its housing or packaging. The QR code may encode a unique device identifier (device ID), which may be read or scanned by an external device, such as a smartphone, hub, or tablet, during installation or commissioning Upon scanning the QR code, the external device 902 may extract the device ID and utilize it to discover or connect to the corresponding sensor device via a first communication interface, such as Bluetooth Low Energy (BLE) or Wi-Fi Direct. The device ID may then be transmitted to the sensor device 200 during the connection handshake and may also be relayed to a remote server, cloud platform, or project management system to facilitate registration, record-keeping, or device inventory.

[0187] In some embodiments, the QR code or registration payload may additionally encode or reference further properties of the sensor device, such as the type and configuration of communication interfaces (e.g., BLE, LoRa. cellular, satellite), the number and types of sensor elements present, or a configuration pointer to a file describing tail layouts, sensor types, or factory7calibration data. These properties may be transmitted from the external device to the server as part of the registration payload or may be read from the sensor device over the communication interface upon successful connection and subsequently relayed to the server or platform.

[0188] As part of the registration or commissioning process, the external device 906 or serv er 902 may query the sensor device 200 to enumerate all attached or detected sensor elements. For example, the processor 404 may perform a bus scan, address discovery, or other interrogation method over one or more internal buses or communication interfaces (e.g., I2C, 1-Wire, UART) to retrieve the unique sensing element identifiers (e.g., serial numbers or factory-programmed IDs) associated with each sensor element or probe (including sensor elements disposed along one or more tails). The resulting list of sensor element IDs may be displayed to the user, and the user or platform may assign logical or user-defined names to each element (for example, ‘‘Top”, ‘‘Middle”, “Bottom”, “Ambient”, or by pour zone or structural location). The association between each sensor element ID and its assigned name may be written to the device’s non-volatile memory7, to a remote configuration database, or to both, allowing subsequent measurements to be unambiguously mapped to their physical context.

[0189] Additionally or alternatively, during or after registration, a name or label may also be associated with the device 200 as a whole, such as a site name, pour number, or zone, and this name may be stored in the device memory, in a remote database, or as metadata associated with the device ID in the cloud platform. In some embodiments, the assigned names, identifiers, and configuration data for the device and its sensor elements may be sent as a batch payload over the first communication interface, then propagated to all relevant servers, project databases, or user interfaces.

[0190] In further embodiments, registration may include the initialization of measurement collection and / or transmission policies. For example, the processor 404 may, upon completion of the registration process, automatically initiate the sampling of sensor elements, configuration of the transmission queue, scheduling of measurement messages, and selection of one or more communication interfaces for routine or event-driven data transmission. Registration may further include device time synchronization, retrieval of updated firmware or configuration files, validation of device credentials, or assignment to a specific project, pour, or structure in the server platform. All such data exchanges and configuration actions may be performed over the first communication interface, or over a plurality of communication interfaces as permitted by device capabilities

[0191] During or after completion of the registration process, the sensor device 200 may be configured to activate a second communication interface, such as a long-range interface (for example. LoRa, cellular, or satellite), that is distinct from the first communication interface used for registration (for example, BLE). This activation may be triggered by a specific registration command received over the first communication interface 412, by a successful acknowledgement of device registration from the server, or according to a predefined registration or activation policy. The second communication interface 410 may be initialized for ongoing or scheduled transmission of sensor measurement records, and may be configured with communication parameters, such as frequency plan, output power, data rate, or spreading factor, as appropriate for the deployment context.

[0192] In some embodiments, the sensor device 200may be actively sampling and storing sensor measurement data into memory or an internal queue prior to registration or prior to full activation of the second communication interface This pre-activation or pre-registration measurement data may be transmitted after activation, either as a batch payload or as individual measurement records, over the first or second communication interface 412, 410. Alternatively, the device may be configured to transmit only those measurements collected after a successfulregistration event, wherein the processor may mark the registration time and only transmit data sampled after that timestamp, based on application requirements or user selection.

[0193] In addition, during the registration workflow, the sensor device 200 may synchronize its internal clock with the external device or server to ensure accurate timekeeping and timestamping of measurement records. The external device may obtain an authoritative timestamp from a remote server or from network time protocol (NTP) sources and relay this time reference to the sensor device 200 over the communication interface 412, 410. In some embodiments, the sensor device 200 may periodically repeat this synchronization process to compensate for clock drift or to maintain high precision time alignment, either according to a fixed schedule or in response to drift detection, time-critical events, or command received over any communication interface. In one embodiment, a method is executed by the sensor device 200 to facilitate automated registration and configuration of the device and any attached tails or sensor elements. The method may comprise the following steps, executed by the processor 404 of the sensor device 202. Upon power-up or initialization, the processor 404 may begin broadcasting advertising packets over a first communication interface 412 (such as Bluetooth Low Energy, BLE), with the advertising packets including a unique device identifier (DevicelD) encoded therein. The processor 404 may also continuously monitor the state of its hardware connectors to detect the attachment of a tail, and upon detecting an attached tail, may poll the tail using a wired communication interface to identify any sensor elements 300 present.

[0194] If the tail includes a memory module or configuration file, the processor 404 may read from this memory to retrieve one or more of: a unique tail identifier (TaillD), a configuration data set (such as number, type, and arrangement of sensor elements), and the unique sensor element 300 identifiers. If no configuration memory' is present on the tail, the processor may enumerate the attached sensor elements by polling over the wired interface and dynamically generate a configuration set describing the tail assembly. The processor 404 may store the discovered configuration data in local memory' and / or prepare it for transmission.

[0195] The processor 404 may remain in a state of awaiting registration requests from external commissioning devices, which may be detected by the receipt of a connection request over the BLE communication interface. Upon receiving a valid connection request from an external device (which may have acquired the DevicelD by scanning a QR code affixed to the sensor device or tail), the processor may establish a BLE connection and respond to any configuration queries from the external device by transmitting the current configuration through a configuration message, including DevicelD, TaillD (if present), sensor element count, and sensor element identifiers, for example:

[0196] ConfigurationMessage { device id: "ABC123", sensor elements: [ { sensing element id: "BODY TEMP", position: 0, sensor type: "Temperature" }, { sensing element id: "TAIL PROBE 1", position: 1, sensor type: "Temperature" }, { sensing element id: "TAIL PROBE 2", position: 2, sensor type: "Temperature" } ], communication_interfaces: [ { interface type: "BLE", version: "5.2" }, { interface type: "LoRa", region: "EU868", max_tx_power: 14 } ] }

[0197] Upon transmitting the configuration message, the device may await a registration command over the first communication interface Upon receipt, the processor may parse the registration command, which may specify7sampling parameters and communication settings, for example:

[0198] Registrationcommand { sampling rate: 900, communication interface settings: [ { interface type: "LoRa", tx_power: 14, spreading factor: 9, region: "EU868" }, { interface type: "BLE", advertising_interval: 200, tx_power: 4 } ], tail_parameters: { calibration data: expected_element_count: 2 } }

[0199] Upon receipt of a registration or activation command from the external commissioning device over the BLE interface, the processor 404 may, in accordance with the received command and configuration parameters, initiate sampling of one or more sensor elements, activate a second communication interface 410 (such as LoRa), and / or adjust operational settings such as transmission power, spreading factor, or measurement scheduling. The processor 404 may record in memory the association between DevicelD and TaillD (if applicable), and may optionally transmit this association data to a remote server if such connectivity is available.

[0200] In an embodiment where the tail is modular and may or may not have a QR code, the processor 404 may execute logic to determine the tail identity and configuration using one or more of: reading a tail QR code transmitted to the device 200 by the external device, interrogating an onboard tail memory module, or dynamically polling for connected sensor elements 300. The method may ensure that any discovered tail identifier or configuration data is associated with the current DevicelD and, if necessary, stored locally or transmitted to a remote server for inventory or configuration management.

[0201] Upon completion of registration and configuration, the processor 404 may commence regular or event-driven sampling and transmission of sensor measurement records over the first or second communication interface, as defined by the operational parameters established during registration. The processor 404 may support further reconfiguration or commissioning actions over either communication interface, enabling dynamic adaptation todifferent tail configurations or operational environments throughout the lifecycle of the device 200.

[0202] In some embodiments, during or prior to registration, the sensor device 200 may authenticate an external device or user by requiring a secure challenge-response procedure, password entry, or presentation of a cryptographic credential over a first communication interface 412. The device 200 may generate, exchange, or store encryption keys, authentication tokens, or digital certificates as part of the registration process, which may subsequently be used to secure communication sessions conducted over one or more communication interfaces In certain embodiments, the registration workflow may comprise multiple steps or stages, such as initial discovery and pairing over a first communication interface 412 (e.g., BLE), followed by additional provisioning, credential exchange, or operational activation over a second communication interface 410 (e.g., LoRa or cellular), with confirmation from a remote server or cloud platform as a prerequisite for completion. The sensor device 200 may log all registration attempts and outcomes, including timestamps, device identifiers, and results, in local or remote memory, and may periodically transmit these logs to an external device or server for audit or troubleshooting purposes.

[0203] Additionally or alternatively, the sensor device 200 may implement dynamic configuration detection during the registration or commissioning process. For example, if the device comprises a modular housing with a connector allowing for connection of a pl urali ty of different tails or sensor element 300 assemblies, the device 200 may detect and enumerate all connected sensor elements 300 by polling each potential interface or address during registration. Where a tail lacks a unique QR code or explicit configuration file, the sensor device 200 may automatically infer the configuration by detecting sensor element presence, identifier, and position metadata via a communication protocol 412, 410 (such as one- wire, I2C, or SPI). In the case where the tail includes a QR code, the sensor device or an external device may scan the code, retrieve the associated tail ID, and use it to pull or validate configuration data (such as number and type of sensor elements) from a remote server. The device 200 may support hot-plug or hot-swap detection such that any addition, removal, or replacement of tails or sensor elements 300 may trigger a re-registration process or configuration update Upon detecting any discrepancy between the expected and actual configuration, the device may notify the user or transmit an error status over one or more communication interfaces.

[0204] In some embodiments, the sensor device 200 may perform time synchronization during registration by acquiring time data from the external device or a remote server and maystore one or more received clocks or timestamps for later reference. The device may perform validity checks on the acquired time, such as ensuring it is monotonically increasing or consistent with previously stored values, and may store time acquisition events in a log for audit purposes. The device may present or broadcast detected configuration information, which may include device ID, tail ID (if present), and all sensor element IDs and their inferred positions, to an external device or user application for confirmation prior to completing registration. Registration may further include, if necessary, firmware updates or mode selection (such as selection of an initial operational mode, activation of additional communication interfaces, or enabling / disabling of certain features), with such updates or mode changes performed automatically or in response to user input, configuration data, or remote commands received during the registration process.

[0205] In one embodiment, during registration, the sensor device 200 may transmit its device identifier and related credentials to a remote network management service (such as a LoRaWAN Network Server) via a communication interface 412, 410. Upon successful transmission, the device may be authenticated and provisioned or whitelisted for access to the network, enabling authorized participation in uplink and downlink communications. The network server 902 may store the device entry, associate it with an application or user account, and manage communication rights, security keys, and network parameters for ongoing device operation.Updating Operations

[0206] In some embodiments, the sensor device 200 may update firmware or other systems using a plurality of wired or wireless communication protocols. In some embodiments, the sensor device 200 may transmit, receive, and verify firmware over a plurality of communication protocols independently or in combination. For example, the sensor device 200 may receive a firmware update via a first wireless protocol and then authenticate the firmware via a second wireless protocol with the same device and / or other devices. In some embodiments, the device may dynamically select the wireless protocol based on a plurality of factors including but not limited to: signal strength, protocol frequency, device battery, size of update, and available devices in the surrounding wireless environment In some embodiments combinations of wireless protocols and different devices may be used. For example, the device 200 may use LoRa communication with a first device to retrieve a list of available firmware, then submit a request for an update and receive and update via Bluetooth from the first deviceor a second device. In some embodiments the device may avoid and / or delay updating if the communication protocol appears unsuitable.

[0207] In some embodiments, the sensor device 200 may transmit a request to check for available updates and / or retrieve a specific update. In some embodiments, the sensor device 200 may receive a command from the system to update. Updates may happen in a method comprising of a wireless protocol receiving or retrieving a firmware image, verifying the authenticity, authority, and integrity of the firmware image and then installing the firmware image in a fail-safe manner and rebooting once the installation has been verified as successful Methods for fail-safe architecture may include but are not limited to dual-bank memory' and / or hash signatures, the device may partition its memory and have multiple firmware during and / or after a firmware update. In some embodiments, the sensor device 200 may also implement methods for rolling back to previous firmware automatically if an update fails. In some embodiments, firmware updates may affect the behavior of any components or protocols on the device including but not limited to other wireless protocols from the one that was used to initiate the update. In some embodiments, a wired protocol could also be used to transmit information and updates including but not limited to firmware.

[0208] In some embodiments, the sensor device 200 may adapt the timing installation and / or updating of fir w are based on context and / or environment. Examples include but are not limited to: (i) scheduling firmware retrieval for periods of less busy wireless communication; (ii) scheduling or deferring installation to take place during periods of low and / or non-critical activity7; (lii) Scheduling firmware retrieval and / or installation for periods when the device is already awake for other tasks.

[0209] In some embodiments, the sensor device 200 may employ methods to reduce errors and / or minimize overhead for firmware updates. Methods may comprise of techniques including but not limited to: (i) partial firmware delivery via smaller chunks which may include individual validation; (ii) checkpointing packets in order to reduce re-transmission; (iii) using rolling hash validation and / or full signature check at the end for secure and efficient validation; (iv) the device may use spare bandwidth from normal transmissions to send partial and / or complete firmware updates.Device Modes

[0210] As described herein, the terms "mode," "operation mode," or "mode of operation" refer to a predefined or dynamically adjustable set of settings, parameters, and behaviors that govern the functional state of the sensor device 200. The processor 404 of the device 200 mayselect or transition betw een various modes in response to internal triggers, such as battery level or elapsed time, external commands, for example via a commissioning device or server, or environmental conditions, such as network availability- or detected events. Each mode may define which communication interfaces are enabled, the sampling frequency of one or more sensor elements, the power consumption profile, data transmission policies, and user interaction options, among other settings.

[0211] Example modes include, but are not limited to. a "shelf mode." in which the device 200 operates in an ultra-low-power state suitable for storage or transport (for example, drawing less than 10 microamps of current by disabling all non-essential circuitry, placing the processor and communication interfaces into deep sleep or standby states, and employing aggressive duty cycling, such as waking only periodically, for instance every several seconds or minutes, to briefly advertise over a first communication interface at minimal output power); a "preactivation" or "discover}- mode," in which only a first communication interface, such as BLE, is periodically enabled for pairing or registration; an "active operation mode," in which sensor measurements are collected, processed, and transmitted according to routine policies; and a "low power mode" or "energy-saving mode," which may be triggered by low battery or absence of network connectivity, and may reduce measurement or transmission rates and limit active communication interfaces. Additional operation modes may be defined for diagnostic, firmware update, bulk data upload, event-driven alerting, or emergency communication. The mode of operation may be automatically selected by the device, set by remote instruction, or manually configured by the user, and may transition dynamically as operational requirements change. Some modes may include hybrid communication strategies, where data is selectively routed over different communication interfaces, or context-driven modes such as "covered mode," in which user feedback is routed through a wireless communi cation rather than visually through an LED, for example after embedding in concrete.Illumination Patterns

[0212] In one embodiment, a method may be executed by the processor 404 of a sensor device 200 to provide communication interface status indication using one or more lightemitting diodes (LEDs). The method may include monitoring the operational state of a plurality of communication interfaces (including, but not limited to, Bluetooth, LoRa, cellular, or WiFi); selecting, for each interface, a distinct LED pattern (such as a specific color, blink sequence, power, or frequency) representative of that interface’s current state (for example, advertising, active connection, data transfer, error, or low-power). The processor 404 may control a single LED to display different patterns for different states and interfaces, or maycontrol a plurality of LEDs, each dedicated to a specific communication interface and independently operated according to the status of its associated interface.

[0213] Additionally or alternatively, the processor 404 may implement a method in which one or more LEDs are coupled with a user interface button. The method may include detecting a button press event (such as a short press, long press, or a specific press sequence); in response, triggering a diagnostic or identification pattern on one or more LEDs (for example, a rapid blink or interface-specific sequence), or executing device actions such as entering pairing mode, performing a device reset, or toggling interface states The processor 404 may vary the LED pattern or device response according to the detected duration or sequence of button activations.

[0214] Additionally or alternatively, the processor 404 may execute a method for communicating status information electronically. The method may include assembling a status message reflecting the current state or most recent indication of one or more LEDs and / or the operational status of each communication interface; transmitting this status message via at least one available communication interface (for example, Bluetooth, LoRa, cellular, or Wi-Fi) to an external device such as a mobile application, gateway, or server. This method may be particularly invoked after installation or encapsulation of the sensor device (for example, after embedding in concrete), when visual access to the LED(s) is obstructed.

[0215] In further embodiments, the processor 404 may encode status information related to, but not limited to, successful connection or pairing, active transmission, interface error or fault conditions, power or batten status, firmware update progress, or acknowledgment of data receipt. LED patterns, button functions, and communication of status messages may be user- configurable, updatable via firmware, or modifiable in response to remote commands or detected changes in device context.Recording Logs

[0216] In one embodiment, a method executed by the sensor device 200 may include generating log entries in response to events such as measurement record transmission, queue operations, sensor element sampling, time synchronization, configuration changes, or detected errors The processor may store these log entries in local memory and additionally or alternatively may enqueue log records for transmission over one or more communication interfaces. The method may include prioritizing log transmission either by feeding log entries into the primary data transmission queue, or by maintaining a separate, lower-priority queue for logs to allow for interleaved or deferred delivery. The logging and transmission behaviormay be determined according to the device’s operational mode, user configuration, or remote instruction.

[0217] In some embodiments, the device 200 may be configured such that a greater proportion of logs are transmitted over a first communication interface (e g. a higher bandwidth short range interface such as Bluetooth) compared to a second communication interface (e.g. a lower bandwidth longer range interface such as LoRa), whereas the throughput of the second communication interface may be preserved (e.g. for transmission of sensor element measurement data) In other embodiments, the device 200 may be configured such that all logs are transmitted exclusively over a first communication interface (for example, BLE), while other data ty pes, such as sensor element measurements, may be transmitted over any available communication interface 412, 410.Security and Permissions

[0218] In one embodiment, the sensor device 200 may be configured such that all data access, including reading of measurement records, device configuration, command execution, and firmware update operations, is restricted to only those external devices, users, or applications that have been authorized during the registration or commissioning process. The processor 404 may, upon initial registration, store a user, device, or organization credential (such as a public key, device certificate, or unique identifier) in secure memory, and thereafter reject all data access attempts from non-authorized sources. In this embodiment, no data including sensor measurements or device status may be retrieved, transmitted, or modified except by authorized parties.

[0219] Additionally or alternatively, the sensor device 200 may implement selective data access restrictions, wherein certain functions (such as remote configuration updates, command execution, or over-the-air firmware updates) are restricted to authorized devices or applications, while allowing open or unauthenticated access to a subset of data (such as readonly sensor measurements or status logs) for interoperability or integration purposes. Access control policies may be defined in device firmware, provisioned over-the-air. or received during registration, and may be updated dynamically or in response to user commands or remote instructions

[0220] In some embodiments, individual data transmissions such as commands, configuration updates, or firmware update packages may be cryptographically signed rather than fully encrypted. The sensor device 200 may be configured to verify the signature of any received command or data packet and will only accept and execute those transmissions that arevalidly signed using an authorized key. This ensures the authenticity' and integrity' of critical updates and commands, even if the underlying communication channel is not fully encrypted.

[0221] In some embodiments, the device 200 may incorporate built-in security measures established during production or initial provisioning. For example, the sensor device may be loaded with a factory -issued certificate, secret, or cry ptographic key that is uniquely associated with the device batch or production line, and which enables secure communication only with an authorized application (for example, the manufacturer’s proprietary app or server). The device may refuse to advertise, pair, or accept any substantive command from generic, unauthorized, or non-whitelisted apps or tools, thereby preventing unauthorized commissioning or configuration in the field.

[0222] Additionally or alternatively, during the registration or commissioning process, the device 200 may further ‘‘lock down" its access permissions by associating itself to a specific user account, organization, or project. For instance, upon successful registration, the processor may write a unique organization or project identifier to secure memory and reject subsequent registration, re-pairing, or configuration requests from any external device that does not match the stored credentials. This binding may be permanent, revocable, or time-limited according to deployment requirements and may' be managed locally or remotely by the platform operator.

[0223] In some embodiments, cryptographic keys, certificates, and other security credentials may be stored in a secure hardware element or encrypted partition within the device to prevent unauthorized extraction or tampering. Access control and authentication methods may be implemented in hardware, firm are, or a combination thereof, and may support secure challenge-response protocols, rolling codes, or mutual authentication schemes. All such secunty and permissions schemes may be implemented individually or in combination, configured by default, updated remotely, or adapted dynamically based on the operational context, the registration workflow, or the requirements of the authorized user or organization.Sensing & Data Generation

[0224] Turning back to FIG. 32, as shown in operation 2104 and 2106, the system 900 (e g., the sensor device 200) may generate first data by a sensing element of the sensor device 200 associated with the material 107 and may sample and / or timestamp the generate first data, respectively.

[0225] In some embodiments, the sensor device 200 may' be operably coupled to one or more sensor elements or sensing elements 300, the configuration of which may take multiple forms. The sensor elements 300 may be physically disposed within the housing 201 of thesensor device 200, for example, surface-mounted directly on the printed circuit board (PCB) 402. Additionally or alternatively, one or more sensor elements 300 may be connected to the main housing via a "tail," wherein the tail may be defined as a length of cable or wire containing and communicably coupling one or a plurality of sensor elements 300 to the sensor device 200, such as through a wired communication interface.

[0226] Sensor elements 300 (e.g., sensing elements 300) may be factory calibrated and may include calibration data for correction during measurement. The sensor elements 300 may take a variety of forms and measurement modalities, including but not limited to: digital temperature sensors, analog thermocouples, thermistors, electrodes for electrochemical impedance measurements, piezoelectric elements for electromechanical impedance, antennas or other RF interfaces for electromagnetic spectrum analysis, and ultrasonic transducers for measurement of pulse velocity or waveform properties. Sensor elements 300 may also be capable of measurements across a plurality of frequencies (e g., for impedance spectroscopy), and outputs may comprise real numbers (e.g., temperature) or complex numbers (e g., impedance). The configuration may allow for multiple sensor modalities (e.g., temperature and impedance) within a single tail. Sampling may be performed at one or more timepoints t, allowing the sensor device to monitor the evolution of the measured property (such as temperature or impedance) over time, which may be indicative of material properties (such as concrete curing or strength gain). The sensor elements 300 may be configured to output, store, and transmit measurement data, identifier, and configuration information through one or more communication interfaces in accordance with the operational state of the sensor device 200.

[0227] Sensor elements 300 may further include one or more elements configured specifically to measure electromagnetic wave impedance, in addition to the aforementioned RF interfaces. For ultrasonic measurements, sensor elements may be configured not only to transmit and receive ultrasonic pulses but also to process pulse characteristics, such as pulse velocity or to perform Fourier decomposition or other spectral analysis of the received ultrasonic signal. In any configuration, sensor elements 300 may operate at one or a plurality of frequencies to enable applications such as in impedance spectroscopy. The output from any sampling event may comprise a real number (for example, a temperature value) or a complex number (for example, an impedance measurement) In certain embodiments, a plurality’ of sensor elements 300 of differing modalities may be disposed along a tail or within the housing, such as multiple forms of impedance sensors together with temperature sensors to allow for cross-normalization and richer material characterization.

[0228] In some embodiments, tails may include a single sensor element 300 (also referred to as “probe" or sensing element) located at a predetermined distance along the tail from the housing 201, such as shown in FIG. 7 A. In other embodiments, tails may include a plurality of sensor elements (or “probes”), each of which may be located at different positions along the tail (sometimes referred to as a “multi-probe tail”), such as show in FIG. 7D. The tail may be permanently integrated (hardwired) with the sensor device 200 or may be coupled to the main body (e.g., housing 201) of the sensor device 200 through a connector 306, enabling modular connection of tails with various lengths, numbers, and types of sensor elements 300 Sampling of sensor elements along a tail may be performed simultaneously or sequentially and may include one or more verification operations, such as taking multiple readings and comparing results for consistency, applying an averaging function, or applying other data processing algonthms to the sensor element measurement.

[0229] Single probe tails, or multi-probe tails may be arranged in various configurations, including but not limited to: linear or "daisy-chain" configurations, where sensor elements 300 are disposed sequentially along a single cable, or branched configurations using one or more splitters to create two or more branches of cable, each with one or more sensor elements 300. Splitters may be configured to produce branches of equal or differing lengths, and each branch may itself include further splitters, allowing for flexible and scalable placement of sensor elements 300 along the tail. Each sensor element 300 may be housed in an enclosure (for example, a "metal bullet") which may serve to protect the sensing element 300 from environmental factors such as moisture or chemical exposure. The enclosure (which may be referred to as the “probe enclosure”, “probe housing”, “sensor element housing” or “sensor element enclosure”) may be formed from metal or other materials, may be cylindrical, conical, spherical, rectangular, or any suitable shape, and may be sealed or potted with resin.

[0230] In some embodiments, the sensor element housing may include anti-rotation features, similar to anti-rotation element 206, such as a pair of extensions at one end, to secure the element w ithin the material 107 or prevent undesired movement, and it will be appreciated that such anti-rotation features may be implemented in the sensor element housing using the same or similar structures as. those described elsewhere herein with respect to the sensor device housing 201 The sensor element housing may also allow for "inline" mounting, where the cable passes through the housing and the sensor element is disposed within, with the cable continuing from the opposite end. At the end of a cable on a tail, a connector may be provided to enable further extensibility, such that a male and female connector, each coupled with a cable or wire, may be used either to connect an extension tail (composed of a male connectoron one end, a cable, and a female connector on the other end) or to plug in an additional tail or assembly of sensor elements 300.

[0231] The electrical wiring within the tail may be configured for various bus topologies. For example, sensor elements 300 may be arranged on a shared bus (such as a one-wire interface), allowing for addressing of individual elements through unique identifiers. The bus protocol may support time-delayed responses to facilitate sequential communication with multiple sensors. Each sensor element 300 may further be coupled with a memory module for local data storage, allowing for redundant data retention within the tail assembly, which may be addressed by the sensor device processor 404. The wiring may include multiple channels, for example, a dedicated channel per sensor or group of sensors, and may incorporate one or more ground connections. Some implementations may allow each sensor element to act as a repeater, forwarding communications from downstream sensors to the sensor device processor 404. Electrical connectivity may use two, three, four, or more conductors depending on the required protocol and isolation between sensor elements 300.

[0232] Sensor elements 300 may be uniquely addressable and may include preprogrammed or factoiy-assigned unique identifiers. The physical disposition of each sensor element 300 along the tail may be determined during manufacturing and stored in a configuration file, which may include the identifier, relative or absolute position (such as "position 1, 2, 3..."), tail length, number of probes, and / or type of each sensor element 300. This configuration file may be stored in non-volatile memory 1004 on the sensor device 200, in memory located on the tail itself, or on a remote server, and may be provided to the device via one of the communication interfaces during registration or activation. In some embodiments, a QR code affixed to the tail or sensor device 200 may encode the configuration data directly or include a unique identifier linking to the configuration file stored in a database 908 accessible over the network 904. During registration or activation, the sensor device 200 may retrieve the configuration file, decode it, and use it to query each sensor element 300, validating its unique identifier and confirming correspondence w ith the configuration file. If a discrepancy is detected — such as a mismatch in the number of detected sensor elements, or a mismatch in identifiers — the sensor device 200 may output an error or status report through an appropriate interface

[0233] In some embodiments, each sensor element 300 associated with the sensor device 200 (whether disposed within the main body or along one or more tails) may be assigned a position identifier, representing the order of the sensor in the measurement chain, rather than its physical location in space. For example, position 0 may correspond to the sensor element300 integrated within the device housing 201, position 1 to the first sensor element on a tail, position 2 to the second sensor element, and so forth. The processor 404 may automatically assign, determine and / or record the position identifier as part of the sampling operation which occurs over the sensor communication interface, and each measurement record may include this position metadata to facilitate sequential data gathering and analysis. The device firmware or software may represent each sensor element as an object or item in code, ith each new tail or sensor element 300 added to the system dynamically instantiated as a corresponding object with a unique identifier and associated position Data may be gathered sequentially by traversing sensor elements 300 in order of position metadata, independent of whether the sensor is physically located on the sensor housing 201 or along a tail. Sampling operations may also include, by default, the measurement of other device parameters, such as battery voltage, at each sampling event. In certain embodiments, this entire process may be performed automatically through addressing on the communication channel, such that sensor elements are discovered, addressed, and sampled based on their position in the chain, with no manual intervention required.

[0234] In some embodiments, the sensor device 200 may obtain measurement data, such as at operations 2104 and 2106, from either digital or analogue sensor elements 300 using a variety of electronic acquisition techniques. For digital sensor elements, such as digital temperature sensor elements), the processor 404 may initiate a measurement by sending a command or request signal along the appropriate communication interface (such as a 1-Wire, I2C, or SPI bus). The sensor element 300 may then acquire the requested measurement (such as temperature) and return a digital value to the processor over the same bus or interface. The processor 404 may employ address-based selection, CRC validation, and, in some embodiments, time-delayed polling to minimize bus collisions and noise, particularly when acquiring measurements from multiple sensor elements 300 along an extended cable (tail). The digital interface may further include techniques such as shielding, use of twisted-pair cabling, or error-correcting codes to mitigate capacitive coupling, inductive interference, or other sources of electrical noise, thereby enabling reliable operation even over long cable runs.

[0235] For analog sensor elements, such as thermocouple or thermistor sensor elements, the sensor device 200 may include an analogue front end (AFE) comprising circuitry for signal amplification, filtering, and analogue-to-digital conversion (ADC). The processor may initiate sampling by activating the AFE and, in some embodiments, by enabling power to the sensor element 300 only during acquisition to reduce self-heating or noise. For thermocouple sensor elements, the AFE may employ cold-junction compensation, low-noise amplifiers, differentialinputs, and filtering (e.g., low-pass or band-pass) to reject common-mode noise and minimize interference from external sources. The system 900 may further comprise hardware elements such as capacitors, inductors, or resistor networks (LCR filters) to suppress transient or high- frequency noise, especially for long tail installations. In some embodiments, shielding (e.g., grounded shield braiding), physical cable routing, or signal modulation techniques may be used to increase immunity to electromagnetic interference. The processor 404 may sample the conditioned analogue signal through an ADC, optionally averaging multiple samples or applying digital filtering before recording the final measurement value as a measurement record

[0236] In both digital and analogue acquisition embodiments, the processor 404 may coordinate the timing of measurement initiation, acquisition, and retrieval with the storage of an externally synchronized timestamp as described above. When sequentially sampling multiple sensor elements along a tail, the sensor device 200 may use a round-robin or address- prioritized approach, optionally repeating measurements to detect or reject spurious noise events. These approaches may be used in embodiments where tails are long and subject to increased susceptibility to capacitive or shot noise, as the described electronic design measures can maximize reliable signal integrity and measurement accuracy.

[0237] In one embodiment, the sensor device 200 may include one or more sensing elements 300, each identified by a unique sensing element identifier as described herein. The sensor device 200 may acquire accurate time or clock information by receiving a time synchronization packet or timestamp message from another device, such as a server, gateway, or paired mobile device, via one of its plurality of communication interfaces 412, 412 (for example, through a first short range communication interface, or a second long range communication interface). Upon receiving such clock or time data, the processor 404 may update the device’s internal clock to match the received time, may store the externally provided clock or time value together with a reference to the current value of the internal clock, or may utilize a relative timekeeping approach wherein measurement data are time-stamped relative to either the acquisition of the external clock, an internal event, or another reference point. In this manner, the sensor device 200 may associate each measurement of each sensor element with an absolute, relative, or hybrid time reference as needed for accurate correlation and analysis, regardless of whether the internal clock is directly updated.

[0238] This clock synchronization procedure may then be used to generate externally synchronized timestamps for all subsequent sensor measurement records. Additionally oralternatively, timestamps may be represented as relative times (e.g., offsets or intervals) but referenced to, and stored with respect to, an externally obtained clock.

[0239] In some embodiments, the processor 404 may implement one or more measurement initiation and sampling policies, which may be scheduled at fixed intervals, triggered on- demand by commands received over any of the available communication interfaces 412, 410, or initiated automatically in response to events or conditions detected by the device or communicated from a remote system. Error detection and handling routines may be performed in conjunction with data received via the communication interfaces; for example, the processor 404 may retry measurement acquisition, log a fault, or flag a measurement as invalid in response to error notifications or failed communication with a sensor element. In embodiments supporting multiplexed or multi-channel acquisition, the processor may select or address each sensor element by controlling switches, multiplexers, or digital bus logic, and may coordinate this selection with configuration commands received from a remote device or server over one or a plurality of communication interfaces. Additionally or alternatively, the processor 404 may receive or retrieve calibration coefficients, compensation parameters, or updated measurement algorithms via any communication interface, and may apply such corrections or transformations to acquired measurement data prior to storage or transmission.Timekeeping & Clock Operations

[0240] In some embodiments, operations 2104 and 2106 may further include a method of timekeeping and clock management may be executed by the sensor device processor 404 to ensure accurate association of measurement records with timestamps. The processor 404 may receive clock or time data over one or more communication interfaces, such as a first (short- range) or second (long-range) interface, for example via time synchronization packets, NTP messages, or timestamps from a remote server, gateway, or paired device. The processor 404 may update the internal clock (such as a real-time clock, microcontroller timer, or software counter), store an externally provided clock as a reference, or maintain a mapping between the internal timebase and the externally synchronized clock.

[0241] In one embodiment, the processor 404 may reconcile a plurality of clock sources received over different communication interfaces by comparing timestamps, determining offset or drift, and applying a drift correction algorithm. The method 2100 may include updating the internal clock, selecting a most recent or most trusted clock source, maintaining a weighted average, or otherwise determining an operative timebase for timestamping sensor measurementrecords. Upon detection of drift or offset exceeding a defined threshold, the processor 404 may initiate re-synchronization over one or more communication interfaces 412, 410.

[0242] Additionally or alternatively, if an external clock source is unavailable, the processor 404 may rely on the internal clock, logging the time of last synchronization and applying local drift correction as needed. Upon subsequent receipt of an external clock, the processor 404 may reconcile with the new timebase and, optionally, retroactively adjust stored measurement records. The processor 404 may time-stamp measurement records using an absolute time (for example, UTC, GPS, or NTP-derived timestamps), a relative time (such as a counter value, elapsed interval, or time since last sync), or both. Metadata indicating the source, synchronization status, and quality of each timestamp may be stored with each record. In embodiments where a fixed sampling interval is used, the processor 404 may employ a counter-based method to reconstruct time series data.

[0243] Additionally or alternatively, the processor 404 may periodically initiate time synchronization requests over one or more communication interfaces, recording the timing and source of each synchronization event in device memory. The processor 404 may further associate a synchronization status or quality flag with each measurement record, indicating whether the record was obtained using an absolute, relative, or corrected timestamp. These methods of time synchronization, timestamping, and drift correction may be executed autonomously by the device, configured by the user, or performed in response to remote commands, and are applicable to any operational context in which accurate timekeeping is required.

[0244] In some embodiments, the processor 404 may further compensate for network 904 or communication interface 412, 410 latency by measuring round-trip delay during synchronization procedures, and may adjust the received clock or timestamp accordingly. Additionally or alternatively, the processor 404 may participate in distributed or peer-to-peer synchronization protocols with other sensor devices, maintaining clock alignment within a sensor netw ork. The device may persistently store clock state and synchronization metadata in non-volatile memory to ensure continuity across power cycles. Synchronization events may be initiated on a periodic, scheduled, event-driven, or on-demand basis, with the specific policy configurable locally or remotely The processor 404 may authenticate external time sources before applying updates and may log or alert in cases of synchronization failure, excessive drift, or conflicting clock data from multiple sources. All such synchronization policies and error handling routines may be autonomously executed, user-configurable, or remotely managed via one or more communication interfaces.Processing Measurements

[0245] In some embodiments the sensor device 200 may do processing of data from sensor elements 300 and / or data about the sensor device 200. In some embodiments, the device 200 may calculate physical properties of a material based on data sampled from sensor elements 300. The device may do this based on individual datum and / or a set of data. Methods of processing data may include but are not limited to: filtering and smoothing, averaging, on- device thresholding and event detection such as only collecting specific data in situations where other data meets relevant conditions, and computing key features.

[0246] In some embodiments the system 900 may dynamically adjust its behavior based on these calculations. For example, the sensor device 200 may detect temperature changing rapidly exceeding a given threshold for rate of change and determine that it requires a faster sampling rate. Another example would be that the device calculates a physical property but determines the resolution to be too low and so increases sampling rate and / or resamples specific points. In some embodiments the device may change the method of processing the data based on outcomes of processed data. One embodiment may include a device altering the processing method of a dataset based on processing of sensor data. For example, in the case of concrete sensing, the sensor device 200 (or a remote device) may apply a maturity method, which is a calculation that combines temperature and time data to estimate the development of strength, such as the Nurse-Saul method described in ASTM Cl 074, to its temperature measurements. The device(s) may select among different maturity methods, or may modify specific processing parameters, such as the datum temperature in the Nurse-Saul maturity calculation, based on observed characteristics of the material, including measured temperature sensitivity.

[0247] In another example, the sensor device(s) 200 may process impedance spectroscopy data to identify and track spectral peaks or minima, translating these to estimates of compressive strength or other evolving properties. The sensor device may adapt its behavior in response to such calculations, for example by increasing sampling rate if a measured value changes rapidly or if resolution is insufficient, or by resampling at specific points.

[0248] In some embodiments a device may process data using calculations based on data taken from different sensors For example a device may calculate thermal differentials based on multiple sensors arranged in a plurality of ways. In some embodiments devices may process data based on other devices in their network. For example a device may calculate physical topography and or network topology based on sensor and / or system data from devices it can communicate with. In some embodiments this could include calculating data or changingvalues based on differences between devices. For example, a device may communicate with a local neighbor (where local may be defined as within a maximum distance as defined by GPS, signal strength on a communication interface, or other property of one or more communication interfaces) and calculate properties of materials and / or surrounding environments based on the data taken from both devices and / or the differences therein. Examples include but are not limited to, calculating when a sensor has been placed in a new material based on the difference in the rate of change of temperature between devices.

[0249] In some embodiments device(s) may process data in ways to reduce the size of the memoiy or transmission required. Methods may include but are not limited to data aggregation and / or compression including but not limited to delta encoding, run-length encoding, bitpacking, predictive coding, and / or lightweight compression libraries. In some embodiments, the sensor device 200 may use methods to classify, detect, and / or make decisions on patterns in data using methods including but not limited to running machine learning models, neural networks, and / or decision trees locally.Error Correction

[0250] In one embodiment, the sensor device 200 may implement error correction as part of the method for transmission and receipt of measurement records or other data entities over one or more communication interfaces. Pnor to transmission, the processor may apply a forward error correction (FEC) scheme, such as Reed-Solomon coding or convolutional coding, to each measurement record or batch of measurement records, appending error correction and / or detection codes (such as CRCs or checksums) to each outgoing data packet. Upon receipt of a data packet, the processor or receiving system may verify integnty using the appended codes, perform error correction if needed, and accept or rej ect the packet accordingly . If a corrupted packet is detected that cannot be corrected, the processor may log the failure and, where ARQ or HARQ protocols are supported, initiate a request for retransmission of only the specific affected measurement record or records.

[0251] In another embodiment, the processor 404 may dynamically select or adapt the error correction parameters based on measured link quality, error statistics, or feedback received from the network or external devices For example, if a high rate of errors is detected over a particular communication interface, the processor 404 may increase the coding rate or interleaving depth for subsequent transmissions, or switch to a more robust error correction scheme, and may update this configuration on a per-interface or per-message basis. The sensordevice 200 may further monitor acknowledgements and error notifications returned from the server or gateway, updating its error correction or retransmission strategy in real time.

[0252] In a further embodiment, error correction may be integrated with the device’s retry and backoff and queue management logic. Each measurement record or measurement message queued for transmission may be tagged with its error correction status, and the queue traversal logic may prioritize retransmission of those records for which prior transmission attempts failed error checking at the receiver. The processor 404 may also maintain a log of error rates, correction attempts, and retransmissions for each communication interface 412, 410 and each type of data entity, storing this log in local memory or periodically offloading it to an external system for audit, analytics, or troubleshooting purposes.

[0253] In yet another embodiment, the processor 404 may support multiple, communication interface-specific error correction policies. For example, data transmitted over a high-bandwidth, low-latency interface such as BLE may employ minimal error correction and rely on frequent ARQ, while transmissions over long-range, high-latency interfaces such as LoRa may use stronger FEC and deeper interleaving to compensate for higher expected error rates and reduced acknowledgement frequency. The processor may automatically select the error correction policy based on the datatype, operational context, or regulatory requirements.

[0254] Additionally or alternatively, in cases where measurement records are transmitted redundantly over multiple communication interfaces, the processor may reconcile multiple copies of a record at the receiver, selecting the highest-integrity version based on error correction and detection outcomes, and ensuring only validated and deduplicated data are stored or further processed. These method embodiments may be implemented individually or in combination and may be configured or adapted in response to operational feedback, remote configuration commands, or changing environmental or regulatory conditions.Selective Operation

[0255] As shown in operation 2108, the system 900 (e.g., the sensor device 200) may selectively operate a plurality of communication interfaces 412, 410 of the sensor device 200. As described herein, the communication interfaces 412. 410 of the present disclosure may operate to selectively transmit and / or receive data associated with operation of the sensor device 200. By way of nonlimiting example, the communication interfaces 412, 410 may be configured to selectively transmit and / or receive: information received directly from sensing elements 300, information calculated based on information received from sensing elements 300, information about a device (e.g., device communicably coupled with the sensor 200), dataand logs about the device and / or component status and performance, data and logs calculated based on data and logs about device and / or component status, information about the status, behavior, and wireless environment of its own network 904, information about status, behavior, and environment of other networks (which may be communicably coupled through a second communication interface 410), configuration information / updates, firmware updates, commands to activate and / or deactivate components of hardware, commands to use other wireless protocols in specific ways (e g. through another communication interface), commands to interact with sensors or other devices in specific ways, and / or commands to change device behavior of the sensor device 200. The various techniques and operations described hereinafter may be collectively referred to as selective operation of the plurality of communication interfaces at operation 2108.

[0256] The one or more communication interfaces may be configured for secure cryptography and permissions systems for authentication and to control access rights and authority for device interactions. In one embodiment, a first communication interface 412 may be configured to transmit and / or receive device configuration information, commands (including activation, deactivation, and protocol selection commands), and firmware updates, while a second communication interface 410 may be configured primarily for the transmission and / or reception of sensor measurements, sensor-derived data, device status data, and associated logs. For example, commands or firmware updates may be received via a high- bandwidth or short-range wireless protocol (e.g., a first communication protocol based on Bluetooth), while periodic or event-based sensor data is transmitted via a long-range, low- power interface (e.g., a second communication protocol such as a sub-GHz spread spectrum protocol).

[0257] In another embodiment, one communication interface may be configured for secure transmission of sensitive operations, including cryptographically authenticated commands, configuration information, and firmware updates, while the other communication interface is dedicated to transmitting operational data such as sensor measurements, device performance logs, and wireless environment status. In this embodiment, the processor 404 may selectively activate or prioritize the first communication interface 412 for command and control functions, ensuring robust authentication and permissions enforcement, while the second communication interface 410 is optimized for efficient and resilient transmission of high-volume measurement data.

[0258] In another embodiment of the system 900, multiple communication interfaces 412, 410 may be configured to dynamically adjust between states that optimize for transmission ofsensitive operations and transmission of operational data. The system 900 may include methods to interpret factors about the device and / or its environment then dynamically alter the configuration of the communication interfaces. For example, if the system 900 detects a noisy environment in one communication interface’s channels of operation, the system 900may optimize using a different communication interface and / or alter the configuration of the protocols used over such communication interfaces 412, 410.Example Duty Cycling

[0259] In various embodiments, one or more communication interfaces may be configured to operate in a duty-cycled manner, wherein the interface is periodically activated and deactivated according to a defined schedule or in response to specific triggers. Duty cycling may be employed to reduce average power consumption, extend battery life, or minimize radio frequency interference, and may be based on parameters such as communication protocol requirements, data transmission intervals, environmental conditions, or detected device activity. The timing, frequency, and duration of duty cycling may be adjustable or dynamically configurable by the processor or system logic.

[0260] In some embodiments, a first communication interface 412 may be configured to operate with a relatively low duty cycle, activating only intermittently (e.g., once per hour) to transmit long-range data using a low-power wide-area protocol, while a second communication interface 410 is configured to operate with a higher duty cycle, for frequent or real-time communication over a short-range protocol. In another embodiment, a first communication interface 412 is configured to operate in a duty -cycled manner, and a second communication interface 410 is configured for continuous operation. In another embodiment, the duty7cycling schedule for a first communication interface 412 may be dynamically increased or decreased over time (e.g. in response to critical sensor events, enabling prompt data transmission), while a second communication interface 410 continues to operate on a fixed, periodic duty cycle for routine device status updates or maintenance communications.

[0261] In duty-cycling mode, the timing, frequency, and duration of activation and deactivation of each communication interface 412, 410 may be configured based on predetermined schedules, external commands, detected environmental or sensor events, user interaction, or in response to signals or data received from other devices or communication interfaces. Duty7cycling may7be coordinated between interfaces, such that activation of one interface may trigger changes in the operational state of another or may be managed independently for each communication interface 412, 410. In another embodiment, duty'-cycling schedules may be coordinated so as to ensure that signals from a first communication interface 412 and a second communication interface 410 are offset in time and do not overlap. In another embodiment, the sensor device 200 may employ event-driven duty cycling (e.g., activating an interface upon detection of a threshold sensor value), time-driven duty cycling (e.g., based on a fixed interval or synchronized clock), or a combination thereof. Furthermore, duty cycling parameters may be adaptively adjusted by the processor using learning algorithms or historical data to match usage patterns, data transmission needs, or changing environmental conditions

[0262] In another embodiment, a first communication interface 412 may be used by the sensor device 200 to acquire clock information or achieve time synchronization with another device, such as a server 902 or gateway 910. The acquired clock data or synchronization information may then be used to update or adjust the duty cycling schedule of a second communication interface 410, enabling precise timing of activation and deactivation intervals based on synchronized schedules. The sensor device 200 may also be configured to receive duty cycling parameters or scheduling information from the other device.

[0263] In certain embodiments, if the sensor device 200 detects that it has fallen out of synchronization with an external clock or schedule - such as through missed communication windows, excessive clock drift, or failure to receive expected synchronization signals - the processor 404 may initiate a recovery procedure. This recovery procedure may include activating a first communication interface 412 to reacquire clock or schedule information from an external device (such as a sen' er 902 or gateway 910), temporarily increasing the duty cycle of one or more communication interfaces 412, 41 Oto facilitate re-synchronization, reverting to a locally generated backup clock source, or applying estimation algorithms to predict and correct for clock drift until synchronization can be re-established.

[0264] In some embodiments, the power output or other operational parameters of one or more communication interfaces 412, 410 may be dynamically varied during different phases of a duty' cycle or across one or more duty' cycles. For example, transmit power, modulation scheme, coding rate, or receive sensitivity may be increased during duty' cycles, or across duty cycle In certain embodiments, the transmit power or other communication parameters of one or more communication interfaces 412, 410 may be automatically increased (stepped up) if an expected acknowledgement is not received within a specified interval, thereby improving the likelihood of successful communication. Conversely, if acknowledgements are consistently received, the system 900 may reduce (step down) transmit power or other parameters in subsequent duty cycles to conserve energy' while maintaining reliable operation.Advertising. Handshaking, and Acknowledgements

[0265] In some embodiments, at least one of the plurality of communication interfaces 412, 410 may be configured to broadcast advertising packets at predefined time intervals. For example, an advertising packet may be transmitted every two seconds. Each advertising packet may include a device identifier and may further include additional properties or attributes associated with the sensor device 200, such as device status, operational parameters, or configuration data Optionally, the advertising packet may also contain one or more measurements acquired from one or more sensor elements 300. In such embodiments, a second device such as a gateway / hub 910 or mobile phone 906 comprising its own communication interface(s) may detect the advertising packet and initiate a handshake procedure with the advertising sensor device 200, thereby establishing a communication session. This handshake enables two-way communication, allowing for bidirectional exchange of data and control information, as well as the use of acknowledgements to confirm successful data transmission and receipt over the communication interface 412, 410.

[0266] In other embodiments, at least one communication interface 412. 410 may be configured not to advertise but instead to initiate outbound communication at predefined time intervals, for example, every’ twenty’ minutes. Upon initiating a transmission - such as sending sensor data or status updates - the communication interface 412, 410 may then be activated to listen and or receive signals for a response. Activation of listening or receive mode may be immediate or after a predetermined delay and may serve to await acknowledgements or other responses from another device (e.g. mobile phone 960 or hub 910). The listening period may be defined by' one or more predetermined windows of time. For example, after transmission, the sensor device 200 may listen for a response during an initial window, and if no acknowledgement or response is received, may optionally initiate a subsequent, longer listening window after an additional delay. If a valid response is received during any listening window, the interface may cease listening unless otherwise instructed by the response. If no response is received after the defined windows, the interface may terminate listening mode and revert to a low-power or idle state. This logic may ensure reliable two-way communication with acknowledgements, while efficiently managing device energy consumption and communication channel utilizationCommunication Interface Selection Logic

[0267] The communication interface selection logic may be executed autonomously by the processor 404, in response to user input, or as directed by remote software or firmware updates received over any available communication interface 412, 410. The logic may consider one or more criteria, either independently or in combination, and may be dynamically reconfigured during operation.

[0268] In one embodiment, the communication interface selection logic may be based on the type of sensor element 300 or the data characteristics associated with the measurement records For example, the processor 404 may select a low bandwidth, low power communication interface 410 such as ToRa for the transmission of data from low data rate sensor elements 300 (such as temperature or humidity), while selecting a higher bandwidth interface 412 (such as cellular or BLE) for the transmission of data from higher data rate sensor elements 300 (such as imaging or broadband spectral sensors). In some embodiments, the processor 404 may transmit a subset or on-device analysis of the high data rate sensor data via the low bandwidth interface 410, while reserving the full data transmission for the high bandwidth interface 412.

[0269] For instance, in one embodiment the sensor device 200 may comprise at least two long-range communication interfaces, wherein a first communication interface 412 is configured for low bandwidth and low power consumption (such as LoRa), and a second communication interface 410 is configured for higher bandwidth and higher power consumption (such as cellular, e.g., LTE orNB-IoT). The sensor device 200 may implement a selective operational policy such that measurements from low data rate sensing elements 300 (for example, temperature or humidity sensor elements) are transmitted primarily via the low bandwidth, low' power communication interface to maximize energy efficiency and prolong battery life. In addition, for high data rate sensor elements 300 (such as imaging systems or broadband impedance spectroscopy), the sensor device 200 may generate a subset, summary, or on-device analysis of the collected data, and transmit only these reduced data products or key metrics over the low bandwidth interface to provide remote users with timely information while minimizing data transmission costs. The full, uncompressed, or high-resolution data sets from the high data rate sensor elements 300 may be transmitted less frequently (for example, once per day or upon request) viathe higher bandwidth, higher power communication interface, in order to balance the need for detailed analysis with energy and data usage constraints. This selective approach allows for efficient management of both sensor data delivery and sensor device 200 power consumption, while leveraging the complementary strengths of multiple long-range communication interfaces.

[0270] Additionally or alternatively, the selection logic may be driven by the type of data or operational function to be performed. For instance, configuration settings, firmware updates, and device instructions may be communicated via a short-range communication interface (such as BLE) to ensure secure and reliable delivery, whereas routine measurement records or sensor data may be communicated via a long-range, low-power interface (such as LoRa or NB-IoT). Critical logs or status updates may be prioritized for immediate transmission over any available communication interface 412, 410.

[0271] Additionally or alternatively, the sensor device 200 may adapt the communication interface selection logic in response to environmental or RF conditions. For example, the sensor device 200 may detect temperature, humidity, or electromagnetic interference through sensor elements or may assess radio quality metrics such as RSSI or SNR through the communication interface 412, 410 itself. The processor 404 may then switch to a communication interface 412, 410 or configuration known to be more robust in the detected conditions or adjust transmission scheduling in response to adverse environmental factors.

[0272] Additionally or alternatively, in some embodiments, the selection logic may be responsive to network or infrastructure availability, such as the presence or absence of gateways / hubs 910, cell towers, or satellite 912 visibility. The sensor device 200 may receive information regarding connectivity from one communication interface and may schedule or defer transmissions based on anticipated infrastructure availability. For instance, upcoming satellite 912 flybys may trigger the scheduling of higher bandwidth transmissions, or the presence of a BLE hub may prompt the processor to offload queued data via BLE.

[0273] Additionally or alternatively, the selection logic may be informed by the geographical location of the sensor device 200, which may be determined via GPS, Wi-Fibased location, or the location of a nearby device communicated over one of the communication interfaces 412, 410. The processor 404 may enable, disable, or reprioritize certain communication interfaces 412, 410 or select specific regional frequency plans or operators based on the device’s detected location.

[0274] Additionally or alternatively, the processor 404 may select a communication interface 412, 410 based on the current and predicted battery or power status, and on the measured or known power consumption of different communication interfaces 412, 410 In one embodiment, when battery 401 levels are low or forecasted to be depleted, the sensor device 200 may prioritize low power, low bandwidth interfaces and defer high bandwidth transmissions until sufficient power is available, or dynamically adjust the sampling rate or duty cycle to conserve energy.

[0275] Additionally or alternatively, the communication interface selection logic may- further take into account real-time or historical performance data, such as prior success or failure rates, acknowledgement latency, or communication error rates for each available communication interface 412, 410. The sensor device 200 may perform sweeps across different interface configurations or settings, empirically determine the most effective operational mode, and adapt its policy accordingly to maximize successful data delivery or minimize energy usage.

[0276] In one embodiment , the communication interface selection logic may be determined by the operational purpose or mode of the sensor device 200. For example, prior to activation or registration, the sensor device 200 may remain in a low power, pre-activated state in which only a first communication interface 412 (such as BLE) is periodically enabled for brief intervals to allow for discovery and pairing with a mobile device 906. The processor 404 may implement a policy in which this BLE interface 412 is used exclusively for device activation, registration, initial configuration, and secure credential exchange. Upon successful registration or upon receiving a specific activation command over the BLE interface, the selection logic may trigger a transition to an activated operational mode, in which the processor 404 enables a second communication interface 410 (such as LoRa), and / or increases the BLE power output, and / or commences regular or scheduled transmission of measurement data over the LoRa interface. In this embodiment, the sensor device 200 may conditionally select the active communication interface(s) based on current mode, ensuring that pre-activation communication is limited to low power BLE operation, while post-activation measurement transmission leverages the long-range capabilities of the LoRa interface and / or increased BLE power output as required. This approach may- optimize battery 401 life during dormant periods and robust data delivery during active operation and illustrates how the communication interface selection logic may dynamically adapt based on sensor device 200 mode, purpose of communication, and power constraints.

[0277] Additionally or alternatively, the communication interface selection logic may be informed by local regulatory- requirements (such as transmission frequency, power, or duty cycle limitations), the security or encryption needs of particular data types, the compatibility or firmware / protocol version of external devices, or by user-defined rules, event-based triggers, or scheduled tasks received over any communication interface 412, 410.

[0278] In one embodiment, the communication interface selection logic may- be configured such that key measurement records are transmitted over both a first and a second communication interface 412, 410, either simultaneously or with a time delay betweentransmissions or receptions on each interface. For example, the processor 404 may transmit the same measurement record over a short-range, high-bandwidth interface (such as BLE) and over a long-range, low-bandwidth interface (such as LoRa, NB-IoT, or cellular), either at the same time or by interleaving transmissions or receptions between the two interfaces. The processor 404 may monitor acknowledgements received over either interface and may mark a measurement record as delivered once an acknowledgement is received from at least one communication interface 412, 410.

[0279] In another embodiment, the communication interface selection logic may be adaptive, such that upon detection of repeated transmission failures or lack of acknowledgement over a first communication interface 412, the processor may automatically switch, handover, or queue the pending measurement records for retransmission over a second communication interface 410. For example, if LoRa transmission attempts repeatedly fail, the sensor device 200 may hold data for later transmission via BLE upon detection of a nearby receiver, or vice versa This dynamic selection logic ensures continuity of data flow despite changing network 904 conditions.

[0280] Additionally or alternatively, the processor 404 may implement a store-and-forward selection logic, accumulating measurement records in persistent memory during periods when only the long-range interface is available, and then opportunistically selecting the short-range, high-bandw idth interface for bulk data upload or historical data offload when such connectivity becomes available (e.g., when a user is in proximity with a mobile device 906).

[0281] In another embodiment, the communication interface selection logic may employ one communication interface 412 primarily for device discovery, activation, synchronization, or configuration (such as BLE), and subsequently switch or enable a second communication interface 410 (such as LoRa) for ongoing telemetry, measurement transmission, and remote monitoring. The selection logic may determine which interface to activate or prioritize based on operational mode, purpose of communication, or user command.

[0282] Additionally or alternatively, the communication interface selection logic may be configured such that a measurement record or message is transmitted over only one selected communication interface, but acknowledgements, commands, or configuration updates pertaining to that record may be received and processed over any available communication interface. For example, if a measurement record is transmitted over LoRa, the processor may still accept and process an acknowledgement for that record received over BLE, or vice versa.

[0283] Additionally or alternatively, such communication interface selection logics maybe implemented individually or in combination, may be set by default, configured by the user, updated remotely, or autonomously adapted during sensor device 200 operation.Communication Settings

[0284] In some embodiments, the Bluetooth communication interface (e.g., an example first communication interface 412) may support configurable advertising intervals, wherein the processor may adjust the interval between consecutive advertising events to optimize power consumption, connection latency, or device discoverability. For example, the advertising interval may be set to any value from a minimum of 20 milliseconds up to 10.24 seconds or may be dynamically adapted in response to environmental or operational factors. Additionally, the Bluetooth communication interface may support variable data rates depending on the selected mode, protocol version, and configuration, with supported data rates including, for example, 125 kbps, 500 kbps, 1 Mbps, or 2 Mbps for BLE, and up to 3 Mbps for Bluetooth Classic (BR / EDR). The device may select or adjust the data rate automatically or by command, based on application requirements, desired communication range, signal quality, or energy constraints.

[0285] In some embodiments, the LoRa communication interface (e.g., an example second communication interface 410) may support configurable transmission intervals or periodicity , wherein the processor may adjust the interval between consecutive uplink transmissions or receive windows to optimize power consumption, data latency, or compliance with regulatory duty cycle limitations. For example, the transmission interval may be set to any value ranging from several seconds up to multiple hours or may be dynamically adapted in response to operational factors, event triggers, or environmental conditions. The LoRa communication interface may further support variable data rates, which may be selected or adjusted automatically or by command through the configuration of spreading factor, bandwidth, and coding rate. Supported physical layer data rates may range from below 300 bps up to approximately 27 kbps, depending on region and parameter selection. In one embodiment, the device may adjust the transmission interval, data rate, or receive window scheduling to balance tradeoffs between communication reliability, energy consumption, latency, and regulatory compliance.

[0286] In various embodiments, a communication interface of the sensor device 200 may support a plurality of configurable settings, which may be selected, adjusted, or dynamically adapted by the processor, by user command, configuration file, or remote update, either priorto or during operation. Such configurable parameters may include, but are not limited to: bandwidth (for example, selectable from 7.8 kHz to 500 kHz for LoRa or up to 160 MHz for Wi-Fi), data rate (for example, 0.3 kbps to 27 kbps for LoRa, 125 kbps to 2 Mbps for BLE, or higher for Wi-Fi and cellular), spreading factor (such as SF5 to SF12 for LoRa), coding rate or forward error correction settings (such as 4 / 5 to 4 / 8 for LoRa), transmit and receive output power (for example. -20 dBm to +27 dBm or higher), receive sensitivity or gain settings, advertising interval (for example, 20 ms to 10.24 s for BLE), connection or synchronization interval (including BLE connection intervals or LoRaWAN Class B / C receive windows), channel or frequency selection (including adaptive hopping or fixed assignment), preamble length (for example, 6 to 65535 symbols for LoRa), antenna selection or switching, duty cycle, retransmission or retry policy' (including maximum retries and backoff timing), packet or frame size, acknowledgement mode (automatic, manual, or batch), encryption and security settings (including protocol version and key refresh), network join mode or association (for example, OTAA or ABP for LoRaWAN, pairing for BLE, or SIM / APN selection for cellular), device address or identifier assignment (static or dynamic), wake-up or receive window scheduling, region or frequency plan selection, antenna tuning or matching, modulation scheme (such as FSK, GFSK, DSSS, OFDM, QAM, chirp spread spectrum, or others), network topology (including star, mesh, or point-to-point), polling interval (for example, for I2C or 1-Wire interfaces), timeout settings, quality of service parameters, channel hopping or frequency agility settings, whitelisting or address filtering, firmware or protocol version selection, time synchronization protocol and interval, as well as any other hardware- or protocol-specific configuration. These settings may be independently or jointly selected for each communication interface in response to environmental conditions, regulatory' requirements, application requirements, detected network conditions, or other operational considerations, and may be automatically updated during runtime based on internal logic or data received over any available communication interface 412, 410.Error Correction. Coding, and Spreading Factors

[0287] In some embodiments, communication interfaces 412, 410 may use error correction and bit coding to send data with lower data rates but higher reliability, to increase communication range In one embodiment, before transmitting data, such data bits are encoded using a coding scheme (e.g. where each bit is represented by multiple bits, with S=2 meaning 1 bit becomes 2 bits, and S=8 meaning 1 bit becomes 8 bits). This adds redundancy for errorcorrection. The additional redundant bits allow for the receiver to detect and fix certain errors caused by noise or weak signals, allowing longer range over the interface.

[0288] Additionally or alternatively, in redundant coding schemes, such as forward error correction schemes described above, when a receiver within a communication interface 412, 410 receives data, the receiving device, which has knowledge of the coding scheme used, is able to detect if a bit flip or other data corruption may have occurred over the channel. The receiving device may then correct small errors caused by unreliable communication over the channel, by applying an algorithm to determine the most likely form of the original bit One example of this would be to code a bit ‘1’ with S=8, into ‘11111111’ and transmit that data over the communication interface. When a communication interface receives the data, one or more bits may have flipped (e.g. ‘11101111’ may have been received). By applying an algonthm (e.g. determining the mode across each redundant bit) the receiving device is able to determine that the communicated bit was ‘1’. This reduces bandwidth but increases resilience and as a result range.

[0289] In some embodiments, communication interfaces 412, 410 may use a number of different coding schemes to encode input data. In one embodiment, they may utilize convolutional coding, where each coded bit depends on the current and previous input bit. This spreads information out, allowing for improved error correction over repetition coding. Under this coding scheme, the receiver device may employ a Viterbi algorithm to reconstruct the most likely original message.

[0290] In some embodiments, communication interfaces 412, 410may use one or more communication protocols. A communication interface may act as a transmitter or as a receiver. When transmitting, data may be encoded, and / or modulated (turned into radio waves) and transmitted over the air at one or more frequencies (e g. 2.4GHz. or between 868MHz and 920MHz). When receiving, data may be demodulated back into a stream of coded bits and may then be stored or further transmitted to another component (e.g. the processor 404 or a sensor element 300).

[0291] In some embodiments, one or more communication interfaces 412, 410 may be configured for spread spectrum modulation. For example, using chirp spread spectrum (CSS). Data may be spread over a wider frequency band Each transmitted or received bit or groups of bits may be encoded as a unique chirp (a radio signal that sweeps through a range of frequencies). A spreading factor (SF) may be configured to control how much the signal spreads across the frequency domain. In a higher SF (e.g. SF12) each symbol of the input data is spread over a longer time and wider frequency band, to make it easier for the receiver deviceto detect in a noisy environment. In a lower SF (e.g., SF7), each symbol of the input data is spread over faster, shorter chirps which increases the data rate but decreases range and resilience.

[0292] Additionally or alternatively, the communication interface 412, 410 may implement spreading by encoding each symbol into a chirp signal, which linearly increases (up-chirp) or decreases (down-chirp) in frequency over the symbol duration. For example, with a spreading factor (SF) of 3 and a bandwidth of 125 kHz, each symbol can represent 8 distinct values (0 to 7) The available bandwidth may be divided into 8 frequency steps of approximately 15 625 kHz each (125 kHz I 8). To transmit the value ‘3’, the communication interface initiates the chirp at a frequency offset of 46.875 kHz above the base frequency' (i.e., 3 x 15.625 kHz), relative to the channel’s start frequency (for instance, 915.000 MHz). Thus, for symbol ‘3’, the chirp would start at 915.046875 MHz and sweep linearly across the 125 kHz channel during the symbol period. The unique starting frequency corresponding to each symbol enables the receiver to distinguish the transmitted symbol by identifying the initial frequency and subsequent chirp pattern within the given bandwidth, thereby increasing robustness against noise and interference. In another embodiment, the communication interface 412, 410 may implement non-linear chirp modulation, wherein the frequency of the chirp varies according to a non-linear function over the symbol duration, potentially offering advantages such as enhanced interference rejection or improved security’.

[0293] In some embodiments, one or more measurements from one or more sensor elements 300 may be encoded into one or more bits, optionally using a coding scheme (such as the forward error correction scheme described above). The coded measurement data (which would form a group of bits) may be converted into a chirp signal. The chirp signal may then be sent by one communication interface Another receiving device may then receive the chirp signal and decode it back into one or more measurements.

[0294] In some embodiments, one or more communication interfaces 412, 410 may’ be configured to operate using spread spectrum modulation. Additionally or alternatively, a first communication interface 412 may be configured with a higher spreading factor (SF) relative to a second communication interface 410. Further, one or more communication interfaces may be configured to apply a redundant coding scheme (such as forward error correction) to transmitted data, and / or to decode such schemes for received data. For example, a first communication interface 412 may be configured for long-range, low-bandwidth communication utilizing both a high spreading factor and redundant coding, while a second communication interface 410 may employ only redundant coding without spread spectrummodulation. In such an embodiment, the first communication interface 412 may provide increased range and resilience to interference, but at a lower data rate, whereas the second communication interface 410 may provide a higher data rate with reduced range and resilience. It will be appreciated by those skilled in the art that numerous other embodiments and configurations are possible across a plurality of communication interfaces, including variations in modulation schemes, coding techniques, channel selection, operating frequencies, or any combination thereof, all of which may be implemented without departing from the scope of the present disclosure

[0295] In some embodiments, the communication interface 412, 410 may be configurable to adjust the spreading factor or the symbol rate, such that increasing the spreading factor increases the duration and frequency span of each symbol, thereby improving link margin and range, at the expense of reduced data rate. The communication interface 412, 410 may further support configuration of the occupied bandwidth or the granularity of frequency steps.

[0296] In some embodiments, selection, configuration, or dynamic reconfiguration of communication interface 412, 410 parameters (such as spreading factor, coding scheme, modulation type, frequency band, or transmission power) may be performed automatically or in response to measured channel conditions or environmental factors. In further embodiments, two or more communication interfaces 412, 410 may operate concurrently, either to transmit redundant copies of the same data or to divide and multiplex different data streams, thereby enhancing overall reliability, range, or throughput. Moreover, each communication interface 412, 410 may employ distinct wireless protocols, physical layer waveforms, or channel access methods.

[0297] In some embodiments, one or more communication interfaces 412, 410 may be configured to perform error correction on transmitted and / or received data. This may include the use of forward error correction (FEC) schemes such as block codes (e.g., Hamming codes, Reed-Solomon codes), convolutional codes (e.g., Viterbi decoding), cyclic redundancy checks (CRC) for error detection, or interleaving to mitigate burst errors. The processor 404 may dy namically select or configure the error correction scheme for each communication interface based on factors such as measured signal quality, environmental conditions, regulatory requirements, or information exchanged between different communication interfaces In some embodiments, automatic repeat request (ARQ) or hybrid ARQ (HARQ) may be employed by one or more communication interfaces 412, 410, enabling retransmission of corrupted packets as needed. The error correction coding rate, interleaving depth, and related parameters mayalso be adjusted in real time to optimize communication reliability , range, and bandwidth utilization for each communication interface 412, 410 independently.Measurement Storage and Memory

[0298] When a sensing element 300 is sampled to generate a measurement, the processor 404 may transmit or store such measurement in memory, such as memory 1004. In some embodiments, each measurement may be structured as a record (‘MeasurementRecord’ or ‘Measurement Record’) containing one or more data fields, such as a sensor device 200 identifier, sensing element 300 identifier, unique sequence number, timestamp, measurement value, measurement type, and / or optional metadata. The timestamp may be generated from an internally maintained clock or synchronized using an external source, such as GPS or a network-based time service over the one or more sensor device communication interfaces 412, 410. Additional fields may include status flags, quality indicators, or data tags used for processing, retrieval, and transmission. Measurements may be grouped, batched, or tagged with collection intervals to facilitate efficient processing and transmission. In some embodiments, each MeasurementRecord may include acknowledgement data, such as one or more status fields that may indicate, for each communication interface, whether transmission was attempted and whether it succeeded or failed; the delivery status flag may be set to true if at least one positive acknowledgement is received over any communication interface 412, 410 and may remain or be set to false if no positive acknowledgements are present. An example memory record may include:

[0299] MeasurementRecord(

[0300] device id,

[0301] sensing element id,

[0302] sequence number,

[0303] timestamp,

[0304] measurement type,

[0305] measured value,

[0306] ack status, # e.g.. {"BLE": True. "LoRa": False. "Cellular": False}

[0307] delivered)

[0308] In some embodiments, each MeasurementRecord may include an ack status field that may be implemented as a mapping or dictionary, wherein each key corresponds to a communication interface identifier and each value indicates the acknowledgement status forthat interface. This structure allows the sensor device 200 to efficiently support any plurality of communication interfaces 412, 410 in an extensible and interface-agnostic manner.

[0309] Measurement Records may be stored in a queue, list, array, or database located in local memory on the sensor device. Storage may be implemented in volatile memory (RAM) for temporary buffering, or in non-volatile memory7(such as flash or EEPROM) for persistent retention of data. Measurement records may be stored sequentially or indexed by time, identifier, or other key, allowing for efficient retrieval, batch processing, retransmission, or selective data offload according to operational needs or external data requests For example:

[0310] [MeasurementRecord(l: "TEMPI", "2025-07-10T08:00:00Z", ...),

[0311] MeasurementRecord(2: "TEMP2", "2025-07-10T08:00:05Z", ...),

[0312] MeasurementRecord(3: "TEMP3", "2025-07-10T08:00:10Z", ...),

[0313]

[0314] MeasurementRecord(n: "TEMP2", "2025-07-10T09:00:05Z", ...)]

[0315] In some embodiments, when the sensor device includes or is coupled to a tail (for example, a cable or extension containing a plurality of sensor elements), each measurement record may further include a tail identifier Ctail id ) to indicate the source tail assembly associated with the measurement. The tail identifier may be obtained from a unique memory or configuration within the tail, from a QR code scanned during installation, or inferred by the processor during tail enumeration. In such embodiments, measurement records corresponding to multiple sensor elements on the same tail may be grouped or batched together in a data structure or message (for example, a TailMeasurementBatch), which may include the tail id and an array of measurement records for all sensor elements on that tail sampled during the same acquisition cy cle.

[0316] Example TailMeasurementBatch data structure:

[0317] TailMeasurementBatch(

[0318] tail id,

[0319] acquisition timestamp,

[0320] measurements: [

[0321] MeasurementRecord(sensing element id="TAILl PROBE1", ...),

[0322] MeasurementRecord(sensing_element_id="TAILl_PROBE2", ...),

[0323] MeasurementRecord(sensing_element_id="TAILl_PROBE3", ...),

[0324] II ... additional records

[0325] ]

[0326] )Queuing, Acknowledgements & Transmitting Measurements

[0327] In some embodiments, the sensor device 200 may implement a transmission queue in memory' or persistent storage. The queue may store sensor measurement records to be transmitted over one or more communication interfaces 412, 410, track the acknowledgement status of each measurement record, and support policies for batching, sequencing, and retransmission.

[0328] In another embodiment, the sensor device 200 may maintain a plurality of transmission queues, with each queue associated with a specific communication interface 412, 410, a specific sensor element 300, or a group of sensor elements, or any combination thereof. For example, the system may implement multiple queues such that each communication interface has its own dedicated queue, and within each communication interface-specific queue, separate sub-queues may be maintained for each sensor element or logical grouping of sensor elements. Each queue or sub-queue may independently manage the batching, formatting, sequencing, prioritization, and retransmission of measurement records corresponding to its assigned sensor element(s) and communication interface. Coupling logic may be implemented such that, upon successful acknowledgement of a measurement record through any queue or sub-queue, the corresponding measurement record is removed from or updated in all relevant queues and sub-queues, thereby ensuring consistency of measurement record management and preventing redundant transmission across all communication interfaces and sensor element groupings. This architecture may facilitate communication interface-specific and sensor element-specific data handling considerations.

[0329] To improve transmission efficiency', the processor may' batch multiple sensor measurement records into a single data packet (referred to as a measurement message). Each measurement message may include a device identifier, a message identifier, a list of one or more measurement records (each with at least one of its sensing element identifier, sequence number, timestamp, sensor type, and value), and an optional batch timestamp or payload summary. For example, a measurement message could be structured as:

[0330] {

[0331] "DevicelD": "ABC123",

[0332] "MsgID": "MSG045",

[0333] MeasurementRecords": [

[0334] {"SensingElementID": "TEMPI", "SeqNum": "SEQ120", "Timestamp": "2025-07- 10T18:00:00Z", "SensorType": "Temperature", "Value": "22.3", "ack_status": {"BLE": false, "LoRa": true}, "delivered": true},

[0335] {"SensingElementID": "HUM1", "SeqNum": "SEQ121", "Timestamp": "2025-07- 10T18:00:05Z", "SensorType": "Humidity", "Value": "38.0", "ack status": {"BLE": false, "LoRa": false}, "delivered": false}

[0336] ],

[0337] "BatchTimestamp": "2025-07-10T18:00: 10Z"

[0338] }

[0339] The sensor device 200 may transmit this measurement message via either or both of a first and a second communication interface 412, 410. When an acknowledgement is received from a remote device (such as a server 902) via either communication interface 412, 410, the acknowledgement message may include the device identifier, the message identifier (MsgID), and an acknowledgement status (e.g., "Received", "Failed"). For example:

[0340] {

[0341] "DevicelD": "ABC123".

[0342] "AckMsgID": "MSG045",

[0343] "Status": "Received"

[0344] }

[0345] Upon receiving the acknowledgement, the sensor device may parse the message and mark all sensor measurement records within the acknowledged measurement message as successfully delivered, updating their status in the queue or removing them from the queue. If the measurement message was transmitted over both communication interfaces 412, 410, receipt of the acknowledgement on either communication interface 412, 410 may prompt the device to suppress or cancel further transmission attempts of that same measurement message (or its constituent sensor measurement records) over the other communication interface. If no acknowledgement is received within a defined time window, the processor 404 may initiate retransmission of the unacknowledged message according to a retry policy, which may involve attempting delivery’ via the same or a different communi cation interface.

[0346] In one embodiment, the queue may be implemented as either an in-memory structure or as a logical queue over persistent storage such as non-volatile memory. Each measurement record in the queue may include a device identifier, sensing element identifier, sequence number, externally synchronized timestamp, sensor type, measured value, and transmission -acknowledgement status. In configurations where persistent storage is used, allhistorical measurements may be retained indefinitely, allowing the queue to reference and manage records over the entire measurement history without data loss, with each record being uniquely addressable by sequence number, timestamp, or sensing element identifier. In other configurations, the queue may operate as a transient buffer, removing records once they are successfully transmitted and acknowledged.

[0347] Records may be selected for automatic transmission via one or more communication interfaces 412, 410 based on their acknowledgement status, with the device transmitting those records that have not yet been acknowledged by a remote device The queue may be traversed and records selected for transmission according to a variety of policies, such as first-in-first-out (FIFO), last-in-first-out (LIFO), priority -based, or in response to explicit queries for specific time periods or sensing elements received over one or more communication interfaces 412, 410. This approach enables efficient bundling and reliable tracking of multiple sensor measurements, ensuring all measurement data are transmitted, acknowledged, and tracked with minimal redundancy across multiple communication interfaces 412, 410. It also allows for flexible management and addressing of measurement data.

[0348] In one embodiment, the queue may implement an acknowledgement-driven sequencing mechanism, allowing each measurement record to be individually tracked and marked as acknowledged regardless of its position in the queue or the order of transmission. Each record may maintain a status field indicating whether it has been acknowledged, and by which communication interface(s). When an acknowledgement is received for a particular measurement record, the sensor device 200 may immediately mark that record as delivered, without requiring earlier records in the queue to be acknowledged first. This permits continued transmission and acknowledgement of subsequent records, even if one or more earlier records remain unacknowledged, thus preventing the queue from stalling due to out-of-order delivery or varying latencies across multiple communication interfaces 412, 410. The queue traversal logic may periodically scan for unacknowledged records, regardless of order, and retransmit only those records which have not yet been marked as acknowledged. When a batch acknowledgement is received (e.g., referencing multiple sequence numbers), the status of all corresponding records may be updated at once.

[0349] For example, in an embodiment where a first communication interface 412 is BLE- based and a second communication interface 410 is LoRa-based, the queue of measurement records may be implemented as a list or database of MeasurementRecords, each including one or more of the following fields: device identifier, sensing element identifier, unique sequence number, externally synchronized timestamp, sensor type, measured value, anacknowledgement status map for each communication interface (such as BLE and LoRa), and a delivered flag. Upon creation of a new MeasurementRecord, the acknowledgement status for each communication interface and the delivered flag may be initially set to false. For instance, a MeasurementRecord may take the form:

[0350] MeasurementRecord(

[0351] device_id="ABC123",

[0352] sensing_element_id="TEMP 1 ",

[0353] sequence_number=101,

[0354] timestamp="2025 -07- 1 OT 19: 00 :00Z" ,

[0355] sensor type- 'Temperature".

[0356] measured_value=22.3.

[0357] ack_status={"BLE": False, "LoRa": False},

[0358] delivered=True

[0359] )

[0360] For each new measurement sampled from a sensing element 300. a corresponding MeasurementRecord may be generated and stored in a queue or persistent memory. The sensor device 200 may, during operation, review each MeasurementRecord not yet marked as delivered and, for both the BLE communication interface (e.g., an example first communication interface 412) and the LoRa communication interface (e.g., an example second communication interface 410). if the acknowledgement status for that communication interface remains false and transmission policy permits, may transmit the MeasurementRecord over the respective communication interface. Upon receiving an acknowledgement over either the BLE communication interface or the LoRa communication interface, the sensor device 200 mayparse the acknowledgement to identify at least one of: a device identifier, a sequence number, or a communication interface, may locate the corresponding MeasurementRecord, and may update the acknowledgement status for the relevant communication interface to true. If the acknowledgement status is true for either the BLE or LoRa communication interface, the delivered flag may be set to true.

[0361] If a transient queue is used, delivered records may be removed: for persistent memory, only the status may be updated When a batch acknowledgement referencing multiple sequence numbers is received over either interface, the process may be repeated for each record referenced. Retransmission may occur periodically or according to a retry policy for records where the delivered flag remains false, on either the BLE or LoRa communication interface where acknowledgement is missing. Upon receiving a data request via either the BLE or LoRacommunication interface specifying a time range, sensing element, or sequence number, the device may retrieve all matching MeasurementRecords and transmit them over the requesting communication interface, regardless of acknowledgement or delivered status. This approach enables robust, efficient, and timely data transmission and acknowledgement, supporting out- of-order and communication interface-specific delivery for BLE and LoRa.

[0362] In certain embodiments, a data request specifying a time range may define the range as being between two dates or timestamps, from a specified date or timestamp to the present moment, up to a specified date or timestamp, or from the date of device registration or activation up to a specified date or to the present day. Alternatively, the request may specify' a range based on measurement record identifiers, such as requesting all measurement records with sequence numbers or record IDs falling between a first specified ID and a second specified ID. The device may use these criteria to identify and retrieve all relevant MeasurementRecords from storage for transmission over the requested communication interface. In some embodiments, the data request may further specify that only unacknowledged measurement records within the defined date or record ID range are to be retrieved and transmitted.

[0363] In some embodiments, the sensor device 200 may transmit identical or redundant copies of critical measurement records via two or more communication interfaces simultaneously or in parallel, with the queue logic configured to suppress further retransmission over any interface upon receipt of an ackno ledgement from at least one interface, thereby maximizing probability of timely delivery under uncertain or varying connectivity conditions. In further embodiments, acknowledgement messages may include custom status indicators, such as partial success, batch receipt confirmation, negative acknowledgment, or error codes, and the queue logic may be configured to interpret and act upon such messages in accordance with pre-defined or dynamically updated rules. In certain embodiments, measurement records and acknowledgements may be encrypted or cryptographically signed prior to transmission, and the queue management logic may include verification of message integrity' or authentication status as a prerequisite for updating acknowledgement status or removing records from the queue.

[0364] In certain embodiments , the sensor device 200 may implement a transmission policy The transmission policy may define the conditions under which the sensor device 200 is permitted to transmit a MeasurementRecord over a given communication interface 412, 410, but need not be an explicit set of rules; rather, it may simply reflect the practical availability or operational status of the interface. For example, the policy may be enforced by conditions such as successful connection attempts, presence or absence of a suitable external device, measuredsignal strength or RS SI, or repeated failures to transmit or receive acknowledgements on that interface. Thus, if the BLE communication interface either detects a low signal strength, no suitable BLE receiver in range, or fails to establish a connection or transmit data after multiple attempts, the transmission policy may implicitly or explicitly prevent further transmissions over BLE until the condition is resolved. During such periods, the device may continue to attempt transmission of MeasurementRecords over the LoRa communication interface if it remains operational, thereby ensuring that data offload proceeds even if one interface is temporarily unavailable

[0365] In some embodiments, the sensor device 200 may adapt the frequency and timing of queue traversal, batching, and transmission attempts based on available power, device duty cycle, or energy' harvesting status, optimizing for minimum energy consumption while ensuring reliability of data offload. Additionally or alternatively, in the event that the queue or persistent storage approaches capacity, the device may implement policies such as overwriting the oldest measurement records, halting further sampling until space becomes available, or issuing an alert or notification via any available communication interface 412, 410.

[0366] In some embodiments , the sensor device 200 may implement a retry and backoff policy, which refers to a set of rules or algorithms that determine how and when the sensor device 200 retransmits unacknowledged measurement records over one or more communication interfaces. This policy may control the timing, frequency, prioritization, and selection of retransmission attempts for any MeasurementRecord in the queue or persistent memory that has not been acknowledged by' a remote endpoint. The retry and backoff policy may include fixed interval retransmission, in which unacknowledged records are retransmitted at regular, predefined intervals, or may incorporate exponential or otherwise variable backoff, wherein the interval between retransmissions increases (for example, doubling after each failure) up to a maximum delay. The sensor device 200 may also apply an adaptive retry policy, wherein the interval and frequency of retransmissions are dynamically adjusted based on environmental feedback such as recent acknowledgement rates, observed signal strength, or duty cycling constraints.

[0367] For example, if multiple consecutive transmission attempts fail, the sensor device 200 may further increase the backoff interval or temporarily suspend transmission attempts until a change in environmental conditions is detected, such as an increase in RSSI or the presence of anew gateway or network connection. In a sophisticated scheme, the sensor device 200 may prioritize retransmission of measurement records to maximize coverage and minimize data redundancy under limited bandwidth or connectivity. For instance, the sensor device 200may first select at least one unacknowledged measurement from each day (“daily fill’'), ensuring that a representative sample from each day is delivered, and upon successful acknowledgement, may progressively refine coverage by retransmitting one measurement from each hour (“hourly fill”), then every 10-minute interval, and so on. This progressive “temporal filling” approach ensures that, even in adverse or changing network conditions, the receiving system can reconstruct a coarse record of measurements before finer-grained data are transmitted.

[0368] The sensor device 200may maintain an index or tracker at each temporal resolution to avoid redundant transmission and optimize data flow. Additionally, to further reduce transmission volume and adapt to bandwidth or power constraints, the device may perform on- device data reduction by computing and transmitting aggregate values (e.g.. averages, minima, maxima, or medians) over specified intervals instead of all raw samples. For example, if the measurement sampling rate is high but bandwidth is constrained, the device may average all samples w ithin each hour and only transmit the hourly mean values when complete data offload is not feasible. These retry, backoff, and data reduction policies may be implemented individually or in combination, and may be dynamically selected by the device based on operational context, current network conditions, power availability, or application requirements, thereby providing robust, flexible, and power-efficient strategies for data delivery across any plurality of communication interfaces 412, 410, including but not limited to BLE, LoRa, cellular, satellite, or other terrestrial and non-terrestrial links.

[0369] In embodiments in which the sensor device 200 includes two or more communication interfaces, such as a BLE communication interface (e.g., an example first communication interface 412) and a LoRa communication interface (e.g., an example second communication interface 410), the retry’ and backoff policy may be further adapted to take advantage of the availability, performance, or contextual information of each interface to optimize data transmission. The sensor device 200 may maintain independent or coordinated retry and backoff schedules for each interface, dynamically adjusting retransmission timing or priority based on real-time or historical connectivity metrics collected from both interfaces 412, 410. For example, the sensor device 200 may detect through the BLE communication interface that a receiver is in close proximity and that acknowledgements are being promptly received, and in response may temporarily deprioritize or suspend retransmissions over the LoRa communication interface to conserve power and bandwidth. Conversely, if data transmission via BLE repeatedly fails due to lack of a nearby device or poor signal quality, the policy may prioritize LoRa for retransmission of pending MeasurementRecords.

[0370] Furthermore, environmental or connectivity status information collected via one communication interface may be used to inform or update the transmission policy for the other interface; for instance, if the device receives a configuration message over BLE indicating expected LoRa gateway downtime or changes in network topology, it may delay or batch LoRa transmissions accordingly. The retry7and backoff policy may also enable fallback or opportunistic data offload, such that unacknowledged records persistently queued for one interface may be automatically selected for transmission over the alternate interface if it becomes available In this manner, the system may leverage the complementary strengths and coverage patterns of multiple communication interfaces, adaptively coordinating their operation to maximize delivery success, minimize energy consumption, and ensure robust, low-latency, and reliable extraction of sensor data from the device under varying and dynamic environmental conditions.

[0371] In one example embodiment, the sensor device 200 may be connected to three temperature-sensing elements 300 and may periodically sample each sensing element in rapid succession, forming batches of three MeasurementRecords at 15-minute intervals. Each MeasurementRecord may include several properties, but for illustration purposes only a subset of the key attributes is shown here: the sensing element identifier, timestamp, and delivered status (indicating whether the measurement has been acknowledged via at least one communication interface). The queue of MeasurementRecords for five consecutive batches is visualized below, where each tuple represents (sensing element id, timestamp, delivered), and ‘T’ and ‘F’ denote true and false, respectively, for the delivered status:

[0372] {("TEMPI", ”08:00", F), ("TEMP2", "08:00:05", F), ("TEMP3", "08:00:10", T),

[0373] ("TEMPI", "08: 15", T), ("TEMP2", "08:15:05", T), ("TEMP3", "08: 15: 10", F),

[0374] ("TEMPI", "08:30", F), ("TEMP2", "08:30:05", T). ("TEMP3", "08:30: 10", F),

[0375] ("TEMPI", "08:45", T), ("TEMP2", "08:45:05", F), ("TEMP3", "08:45: 10", F),

[0376] ("TEMPI", "09:00", T), ("TEMP2", "09:00:05", F), ("TEMP3", "09:00: 10", F)}

[0377] In one embodiment, the BLE communication interface (e.g., n example first communication interface 412) may be in an advertising mode, periodically broadcasting presence and device information but not establishing a connection with any nearby BLE receiver device During this period, the LoRa communication interface (e g , an example second communication interface 410) may have signal and may be able to communicate with a remote gateway 910. Accordingly, the device may offload queued measurement records through the LoRa communication interface, transmitting measurement data and receiving acknowledgements over LoRa while retaining unacknowledged data in the queue.

[0378] In another embodiment, the BLE communication interface (e.g., an example first communication interface 412) may establish a connection with a nearby BLE receiver device, enabling the device to begin offloading measurement records through the BLE communication interface. During this period, the LoRa communication interface (e.g., an example second communication interface 410) may not receive any communication acknowledgements, which may be indicative of a lack of LoRa signal or connectivity. The sensor device 200 may therefore suspend or deprioritize transmission attempts over the LoRa communication interface and continue to offload measurement data primarily via the BLE communication interface, updating the acknowledgement status for each record accordingly.

[0379] In yet another embodiment, both the BLE communication interface and the LoRa communication interface may lack connectivity, resulting in an accumulation of unsent measurement records in the queue or persistent storage. The device may continue to store new measurement records as they are generated. Once a BLE receiver device comes within proximity and a BLE connection is established, the device may then offload the accumulated measurement records through the BLE communication interface, transmitting the backlog of data and updating the acknowledgement and delivery status for each record as acknowledgements are received.

[0380] In a further embodiment, the LoRa communication interface (e.g., an example second communication interface 410) may experience intermittent connectivity, such that some measurement records are successfully transmitted and acknowledged over LoRa. while others are not. The device may track which records have not received acknowledgements and may continue to retransmit those unacknowledged records over the LoRa communication interface, follow ing a retry and backoff policy, until acknowledgements are received for all records.

[0381] In another embodiment, if the LoRa communication interface experiences intermittent signal and a predefined number of messages fail to receive acknowledgements, the device 200 may automatically increase the transmit power output or adjust the spreading factor of the LoRa communication interface to enhance signal robustness and maximize the probability of successful transmission, repeating this adjustment until acknowledgements are received or regulatory and / or device limits are reached.

[0382] In a further embodiment, where the LoRa communication interface (e.g., an example second communication interface 410) has intermittent connectivity resulting in most but not all measurement records being successfully transmitted and acknowledged, the device may detect that certain measurement records remain unacknowledged in the queue. If a BLE connection is subsequently established, the device may offload these remainingunacknowledged measurement records through the BLE communication interface (e.g., an example first communication interface 412), updating their acknowledgement status once delivery is confirmed.

[0383] It will be appreciated that the embodiments described above are exemplary only, and that similar approaches may be applied to any plurality of communication interfaces, including but not limited to wireless, wired, optical, cellular (e.g., LTE, NB-IoT, 5G), nonterrestrial networks (e.g., satellite), or hybrid communication protocols and technologies. Various permutations are possible wherein any combination of communication interfaces may be used for data transmission, acknowledgement, retransmission, adaptive configuration, or on-demand retrieval, and where connectivity , availability, and operational modes of individual communication interfaces may vary over time. The system may dynamically select, combine, prioritize, or switch among communication interfaces for offloading, retransmitting, or acknowledging measurement data, with all such variations falling within the scope of the present disclosure. While certain embodiments are described in the context of use within materials such as concrete or RF-challenging environments, the systems and methods disclosed herein are applicable to any sensor device operating in environments where data transmission may be intermittent, delayed, or otherwise unreliable.Thermal Differential Monitoring

[0384] In one embodiment, the sensor device 200 may be coupled with one or more temperature sensor elements 300 configured as descnbed herein, including but not limited to temperature sensor elements disposed within a tail (a cable assembly comprising multiple sensor elements spaced at predetermined intervals). During registration or initialization, each sensing element 300 may be assigned a logical or user-defined name, which may be indicative of its physical position within a structure, such as "top," "middle," or "bottom" to denote depths within a concrete slab, or any other positional designation relevant to the application. This naming convention may be stored in the device memory, in a configuration file, or in a remote server accessible via one or more communication interfaces 412, 410.

[0385] In some embodiments, temperature data may be sampled from each sensing element 300 at one or more timepoints Additionally or alternatively, the sensor device 200 may compute thermal differentials by determining the difference between the temperature readings of at least two sensor elements 300 located along the same tail. The position and separation of the sensor elements 300 may be defined in the configuration data as described above. In further embodiments, thermal differentials may be computed between sensor elements 300 on separatetails, between sensor elements connected to separate sensor devices, or across a plurality of devices. The system may support the designation of one or more sensor elements as "ambient", which means that is located outside the material under consideration by the sensor device 200 (e g., outside the concrete pour). This may allow for the computation of the thermal differential between embedded and ambient conditions for quality control or safety7analysis. The sampling interval for each sensor element 300 may be user-configurable or dynamically adjusted by the device or server in response to operational priorities, detected events, thermal peaks, or energy constraints, and may differ across sensor elements 300 or over time

[0386] Computation of thermal differentials may occur in real time on the sensor device 200 itself (for example, by executing a difference or delta calculation in firmware or on the device processor 404), or remotely on a server, web platform, mobile device 906 or other device after data transmission. In one embodiment, data collected from multiple sensor devices may be aggregated and analyzed on a centralized platform to compute inter-device differentials, enabling analysis across multiple pours or locations within a construction site.

[0387] In one embodiment, the sensor device 200 or platform may generate a report (e.g., a downloadable or viewable report on a web platform), which may include tabular, graphical, or statistical representations of temperature values and differentials over time. In another embodiment, if the computed thermal differential exceeds a predetermined threshold (which may be configurable by the user or set according to regulatory or engineering standards), the system may generate a notification. Such notification may take the form of an alert delivered to a registered user via email, SMS, push notification to a mobile device, or other electronic means. The notification may specify which sensors and locations triggered the threshold event, the magnitude of the differential, the relevant time of occurrence, and may optionally include recent trends or predictions.

[0388] In further embodiments, predictions of thermal differentials or anticipated threshold crossings may be generated by a model. Such a model may include a machine learning algorithm trained on historical temperature data, thermal differentials, and optionally mix design or environmental data. The prediction may be used to proactively warn users or to adjust curing strategies in advance of problematic thermal conditions.

[0389] In the context of a sensor device 200 having at least two communication interfaces 412, 410, such as a lower bandwidth, long-range interface (for example, LoRa) and a higher bandwidth, shorter-range interface (for example, BLE), the system may allocate or schedule data transmissions according to operational priority. For instance, routine temperature data and computed differentials may be transmitted over the long-range interface for generalmonitoring, while the higher bandwidth interface may be selectively activated, for example, in response to a query from a user or a threshold event, to enable bulk download or rapid retrieval of high-frequency data around events of interest, such as during thermal peaks. This dualinterface strategy' enables efficient power management and robust coverage, while ensuring that high-resolution or urgent data are available in a timely manner.

[0390] Additionally or alternatively, the data flow may be further optimized such that, under normal operating conditions, the lower bandwidth interface is used for regular data offload and threshold monitoring, whereas the higher bandwidth interface is reserved for on- demand data retrieval, configuration updates, or detailed event investigation. In one embodiment, the system 900 may automatically switch or recommend switching to the high bandwidth interface when near a thermal event, or upon detection of a mobile device or hub in close proximity' capable of supporting such a connection.

[0391] In some embodiments, small differences in measurement timestamps arising from sequential sampling may be ignored if timing offsets are insignificant. Alternatively, the system may interpolate measurement values across timestamps to standardize readings to common timepoints, enabling precise calculation of differentials or other derived data.

[0392] Each of these embodiments may be combined with any of the sensor element, tail, configuration, storage, and communication schemes described in the present disclosure. While the foregoing embodiments are described with reference to thermal differential monitoring for clarity, it will be understood by those skilled in the art that the described systems, methods, and configurations may be equivalently applied to the monitoring and analysis of differentials in other sensor modalities, such as humidity, impedance, or other physical or chemical properties, using the plurality' of sensor elements and architectures disclosed herein.

[0393] In some embodiments, a simpler, pointer-based queuing scheme may be implemented, wherein each transmitted measurement record, batch, or message is assigned a monotonically increasing sequence number or index. The sensor device 200 may maintain a single pointer (or index variable) representing the highest sequence number or measurement record for which an acknowledgement has been received from a remote device over any communication interface 412, 410. Rather than storing a full acknowledgement status for each record, the device may assume in-order delivery is guaranteed and may only retain records up to (and including) the acknowledged pointer in memory or storage; upon receiving an acknowledgement for a specific sequence number, the pointer is advanced and all records up to that sequence number are considered delivered and eligible for deletion or archival. This approach reduces memory and processing overhead, as the device does not need to track per-record acknowledgement flags and may be efficient when batching and in-order transmission is assured by the underlying protocol or link. Additionally or alternatively, acknowledgements may be included as explicit fields within the data messages exchanged between the sensor device 200 and the remote system, such as a highest-seen or up-to-sequence-number field, but may also be managed and stored independently (e.g., in a separate data structure, log, or flag) to achieve the same effect, allowing flexible separation of message payloads and acknowledgement metadata while maintaining reliable record management and transmission guarantees This pointer-based acknowledgement mechanism may be implemented alongside, or as an alternative to, more granular per-record or per-message acknowledgement strategies depending on the requirements for reliability, memory', and processing resources in the target application.Dynamic Power Management

[0394] In some embodiments, the sensor device 200 may selectively enable or disable different components of its system or adapt their behavior patterns for a plurality of reasons including but not limited to managing the consumption of power in the system and managing wear on components. In some embodiments the different states of the system may be grouped into modes of operation. In some embodiments adjustments to device behaviors may be based on instructions transmitted via a one or more communication interfaces (which may be wired or wireless). Transitions between power states (modes) may be governed by a plurality of sources including but not limited to wake-up routines from wireless protocols or timed operation from logic unit components. Power states for different components may include but are not limited to reduced operation windows, reduced operation frequency', reduced communication frequency, and reduced component power. In one embodiment, a sensor device may receive instructions to shift modes to a higher or lower power mode over a first communication interface. Additionally or alternatively, the sensor device may subsequently receive instructions to shift modes to a higher or lower power mode over a second communication interface. For example, shifting to a higher power mode may enable the operation of a long-range, higher-power communication interface (such as cellular or satellite), while transitioning to a lower power mode may restrict operation to lower power interfaces (such as BLE or LoRa) to conserve energy. The modes of operation may, in some embodiments, be explicit with clearly defined parameter sets, or alternatively may be dynamically determined or implicit, arising from the particular combination of configurationsettings, operational policies, or real-time adaptations applied by the device processor or its communication interfaces in response to system conditions or external commands.

[0395] The sensor device 200 may use a plurality of power modes, which may be employed in sequence. These include but are not limited to an ‘active mode’ wherein full system resources are used, an ‘idle mode’ in which a reduced subset of components and peripherals are active, and a ‘deep sleep mode’ in which minimal circuitry remains active including but not limited to the required components of a wake-up routine. In some embodiments the behavior of individual components may also be managed granularly (e g component by component)

[0396] In some embodiments, the device 200 dynamically adjusts the components in its system. In some embodiments the device has hardcoded patterns of behavior to switch modes or component states. In some embodiments the device may receive commands to change modes and / or instructions on durations of operations for different modes over one or more communication interfaces 412, 410.

[0397] In some embodiments where the sensor 200 has a continuous power source including but not limited to solar or mains power, the system may adjust component behavior to optimize power. Components may be switched on or off to maximize the input into the battery based on the throughput from the power source. For example, a device may operate in a higher power mode during periods where the solar panel has throughput beyond a certain threshold. In some embodiments where the device is powered by constrained energy sources, the system may apply adaptive scaling techniques to adjust system behavior. For example, the sensor 200 may switch to a lower power wireless protocol for transmission based on conditions such as lower power availability7. In some embodiments other environmental or context conditions may be used to inform dynamic adjustment of the power system or related to the power source. Examples include but are not limited to: (i) a device may only sample data and not transmit until prompted: (ii) a device may stop powering LEDs once it detects that it has been embedded in a material; and / or (iii) a device may adapt the power provided to LEDs based on the light in its surroundings.

[0398] In some embodiments, the device may adapt the protocols it uses to adjust power consumption Examples include but are not limited to: (i) a device may switch to an unacknowledged communication protocol in situations where it has lower power in order to reduce power consumption in broadcast and in listening; (ii) a device may reduce and / or stop collecting or transmitting diagnostic data in order to reduce power consumption in writing to memory and / or transmission; (iii) a device may stop processing data onboard in order to save power; (iv) a device may refuse an automatic firmware update based on battery conditionsand / or the wireless environment requiring high levels of power consumption. In some embodiments a device may transmit a warning including but not limited to indicating its power status and / or expected behavior before completing transmitted instructions. In some embodiments a device may dynamically switch back and forth between adaptive behaviors. In some embodiments, data may be buffered in local memory in order to reduce the wake cycles and / or number of components needing to be active.Electronics for Power Management

[0399] In some embodiments, the device 200 may include a variety of hardware-level electronic components or layouts to achieve minimal power usage and maximize sensor device energy efficiency. The device architecture may include low-power components (e.g. microcontrollers and wireless with support for ultra-low quiescent cunent and efficient sleep mode support). Power distribution throughout the PCB may comprise integrated power management ICs, such as step-down (buck) or step-up (boost) converters, linear low-dropout regulators (LDOs), or digitally controlled power switches, which allow for dynamic or selective enabling and disabling of voltage rails to various sub-systems and peripherals.

[0400] Decoupling capacitors may be strategically placed near sensitive ICs and across power rails to reduce voltage ripple and transient spikes, ensuring stable operation during wake-up or transmission events. The PCB layout may be optimized for minimal parasitic loss, including optimized routing of high-current traces. This may be achieved by minimizing trace lengths and widths for high-current paths, using thick copper layers and direct routes between power sources and loads, and ensuring low-resistance, low-inductance connections to reduce IR drops and heat generation across the PCB. Additionally or alternatively, the PCB layout may include ground planes for noise immunity, and isolation of high-frequency RF circuits from low-level analog or digital lines. In some embodiments, power gating techniques may be employed, where MOSFET-based load switches are used to fully disconnect inactive components or sensor modules, effectively reducing leakage currents and preventing unnecessary drain on the battery or energy storage.

[0401] To further minimize standby and active current, the design may include clock gating or dynamic frequency scaling in the microcontroller or processor, enabling peripheral clocks or increasing CPU frequency only when computationally necessary'. Sleep wake-up sources may be optimized by utilizing ultra-low-power real-time clocks (RTC), hardware timers, or external event interrupts (such as wake-on-radio), which keep only essential circuitry powered during deep sleep intervals. Additionally or alternatively, the device may comprise pull-upand / or pull-down resistors, which may be selectively enabled to minimize static current in unused digital I / O states.

[0402] The device 200 may further comprise ESD diodes, reverse polarity protection, and overvoltage or undervoltage cutoffs, to guard sensitive electronics and maintain long-term reliability in harsh or variable environments.Battery

[0403] In some embodiments, the device 200may be powered by a non-rechargeable primary' battery 401 selected to supply both the average operating current and the peak current requirements of one or more communication interfaces. For instance, the battery chemistry may include lithium-thionyl chloride, lithium-manganese dioxide, or other primary cell chemistries capable of supporting sustained or pulsed high current draw, as may be required by wireless communication modules such as LoRa, NB-IoT, LTE-M, or satellite interfaces. The battery 401 may provide a nominal voltage in the range of approximately 3.0 to 3.7 volts and may be sized to provide sufficient capacity for the intended deployment duration and anticipated operating conditions. In some embodiments, the device 200 may further incorporate one or more capacitors or supercapacitors in parallel with the battery 401 to support short-term peak current demands of the communication interface.

[0404] Additionally or alternatively, the device may comprise a rechargeable battery, such as a lithium-ion, lithium-polymer, or nickel-metal hydride cell, configured for repeated charge and discharge cycles. In such embodiments, the device may include charge management and protection circuitry, including but not limited to overcharge, over-discharge, and thermal protection, as well as integrated logic to control charging from external power sources or energy harvesting elements. The rechargeable battery may be sized to supply both average and peak cunent as needed for routine or event-driven operation of one or more communication interfaces and may be operated individually or in combination with other power storage elements or harvesting subsystems as described elsewhere in this disclosure.

[0405] In some embodiments, the device 200 may comprise a plurality of batteries 401, each configured to supply power to one or more specific subsystems or communication interfaces The processor may implement a power selection logic that dynamically selects which battery or combination of batteries to use based on the current operational mode, detected battery status, or anticipated power requirements. For example, in one embodiment, a first battery may be reserved for supplying a lower power communication interface (such as BLE or 1-Wire), while a second, higher capacity or higher current battery may be allocated foruse with a higher power communication interface (such as LoRa, NB-IoT, LTE. or satellite). The communication interface selection logic may take into account the available battery capacity, battery health, or predicted energy budget when determining which communication interface to enable, prioritize, or schedule for data transmission. Additionally or alternatively, the processor 404 may select or disable certain communication interfaces, adjust transmission schedules, or enter a power-saving mode in response to low battery levels or anticipated depletion of a particular battery, thereby optimizing device uptime and ensuring reliable operation under varying energy constraintsEnergy Harvesting

[0406] In some embodiments, the device 200 may feature energy harvesting subsystems, with solar panel or piezoelectric harvester circuits including maximum power point tracking (MPPT) ICs, supercapacitor buffers, or charge pumps, designed to efficiently capture and store intermittent energy'. The power management controller may monitor harvester and battery levels in real time and dynamically allocate available energy to critical loads while shedding or throttling non-essential functions.

[0407] In some embodiments, the device (such as a sensor device 200) may comprise one or more energy’ harvesting elements configured to supplement or recharge the primary’ power source. The energy harvesting subsystem may be electrically coupled to the processor and / or battery and / or sensor element(s) and may be dynamically enabled or disabled in accordance with operational mode, environmental conditions, or charging state. In one embodiment, the device 200 may include a solar energy harvesting element (such as a photovoltaic cell or array) disposed on the exterior housing or a portion of the device exposed to ambient light. The processor may monitor the incident light level using an integrated light sensor and selectively enable solar charging circuitry when light intensity' exceeds a threshold, thereby recharging the internal battery’ or directly powering the device. The solar energy harvester may be used in deployments where the device is located outside, partially embedded, or otherwise exposed to sunlight for at least part of its operating life.

[0408] Additionally or alternatively, the device 200 may be equipped with other types of energy harvesting elements suitable for use in embedded or enclosed environments In one embodiment, a piezoelectric energy' harvester may be mechanically coupled to the device housing or to a portion of the device in contact with the surrounding material (such as concrete). The piezoelectric element may generate electrical energy’ in response to ambient vibrations, mechanical strain, or micro-cracking events in the material. The device 200 may monitor theharvested energy and regulate charging to the power source or supplement operation during periods of high vibration or activity. In a further embodiment, the device may incorporate a thermoelectric (Seebeck effect) generator, configured to harvest energy from a temperature gradient between different regions of the device or between the device and the surrounding material, such as between the core and surface of a concrete structure. The processor 404 may measure temperature differential across the thermoelectric element and modulate energy harvesting parameters to optimize conversion efficiency. Additionally or alternatively, the device may support wireless recharging, for example, via an inductive charging coil or resonant wireless power receiver, enabling power transfer from an external source or charging pad prior to installation, during maintenance, or via periodic energization in the field.

[0409] All such energy harvesting methods may be used individually or in combination. The device may dynamically manage energy sources to optimize battery longevity, minimize downtime, or enable extended deployments in remote or infrastructure-free locations. The processor may adjust device operational modes, sampling rates, or communication schedules in response to real-time or predicted energy harv esting levels.Sensing Modalities and Data Types

[0410] In some embodiments, a device (such as a sensor device 200) may comprise one or more sensor elements capable of measuring a diverse range of physical, chemical, or environmental parameters. Sensor elements 300 may include, but are not limited to: digital or analogue temperature sensors (such as thermistors, RTDs, thermocouples), humidity sensors, strain gauges, piezoelectric transducers, electrochemical probes, photonic or optical sensors, imaging arrays (e.g., RGB, hyperspectral, or thermal cameras), ultrasonic transducers, accelerometers, magnetometers, electromagnetic field sensors, electromagnetic wave impedance or other RF sensors and / or antennas (such as radar or the like). The sensor device may support modularity or configurability’, enabling a single device to incorporate a plurality of sensor elements, either fixed or interchangeable, to capture one or more measurement signals from the environment or material of interest.

[0411] In one embodiment, simple sensor elements 300 such as temperature or humidity sensors may generate scalar measurement signals, typically sampled at regular intervals to produce time series data. For each sample, the processor may generate a measurement record including at least a measured value, and may also include one or more of a timestamp, sensing element identifier, optional calibration or quality data, and / or relevant metadata such as measurement type or units, uncertainty or error bounds, precision or accuracy indicators.Measurement records may be stored in a local buffer or memory, and may be queued for transmission over one or more communication interfaces (such as BLE. LoRa, cellular, satellite, or Wi-Fi), or batched and compressed for efficient handling depending on the operational mode and available communication bandwidth (e.g. through the data queuing embodiments already described elsewhere in this invention).

[0412] In other embodiments, more complex sensor elements 300 may require the processor 404 or device electronics to actively generate excitation signals, such as in the case of electrochemical impedance spectroscopy or electromechanical impedance (EMI) measurement. For example, an electrochemical or piezoelectric sensor element may be excited using a programmable waveform (sinusoidal, multi-frequency, chirp, or pulse), and the corresponding response measured across a spectrum of frequencies. The resulting multidimensional data (magnitude, phase, frequency response) may be encoded into a structured measurement record that captures one or more of the measurement type, excitation parameters, sensing element identifier, timestamp, the measured value, any associated frequencies at which those value were measured, and / or any derived features (such as resonance peaks or impedance minima). These measurement records may be processed locally to extract summary features, compressed for transmission, or transmitted in full over a selected communication interface 412, 410.

[0413] In further embodiments, sensor elements 300 may include imaging sensors or arrays — such as digital cameras, thermal imagers, or hyperspectral sensors — capable of producing high-dimensional measurement data such as images or multi-spectral cubes. The processor 404 may store, compress, or downsample image or spectral data as measurement records, optionally associating each with time, location, sensor orientation, or environmental metadata. Where transmission bandwidth is limited, the device may selectively transmit lower- resolution images, statistical summaries, or features (e.g., mean pixel values, spectral peaks) over a long-range interface, while transmitting higher-fidelity data over higher-bandwidth or short-range interfaces.

[0414] Measurement records may also capture spatial or geometric context. For example, devices with multiple sensor elements 300 distributed along a tail or within a spatial array may associate each measurement with a spatial identifier (e g , tail ID, position index, or 3D coordinates). This enables the generation of spatially resolved data products, such as thermal or impedance profiles, and supports downstream analyses (including tomographic or volumetric reconstructions).

[0415] The sensor device 200 may dynamically manage measurement data and records, including sampling frequency, excitation parameters, and pre-processing pipelines, in response to internal logic, configuration received over a communication interface, available power, or operational mode. For example, in low-power mode, only scalar temperature readings may be collected at sparse intervals, whereas in diagnostic or event-driven modes, full-spectrum impedance or imaging data may be collected and prioritized for transmission.

[0416] Measurement records, regardless of data type, may be tagged with communication interface metadata indicating which interface(s) were used for transmission or acknowledgment, supporting flexible data routing, prioritization, and redundancy In some embodiments, data from sensor elements may be processed locally to generate summary statistics, engineered features (such as maturity index, compressive strength estimates, or principal components), or anomaly scores, with these derived records optionally queued alongside or instead of raw measurements.

[0417] The system 900 may also support diverse data types, including scalar values, time series, frequency spectra, images, and structured metadata, each managed through flexible measurement record schemas. These schemas may support extensibility for new sensor element 300 types and data structures, and facilitate efficient transmission, storage, and retrieval across a variety of network topologies.

[0418] In further embodiments, the sensor device 200 may select which measurement records to transmit, summarize, or store based on available communication interface bandwidth, power availability, or priority rules. For example, large or high-frequency data (such as full impedance spectra or images) may be transmitted over high-bandwidth short- range interfaces when available, while summary features or event notifications may be prioritized for low-bandwidth or long-range interfaces. Additionally, the processor may apply adaptive sampling or compression in response to external commands received via any communication interface, allowing for remote reconfiguration or responsive data management. All such embodiments may be used individually or in combination, and measurement records from a plurality of sensor elements may be managed, processed, and transmitted flexibly to enable rich, multi-modal data collection and robust operation across a wide range of deployment scenarios

[0419] In some embodiments, measurement records generated from sensor elements 300, including but not limited to time series temperature data, impedance spectra, or strain measurements, may be provided as input to one or more machine learning models, either on the device or on a remote system, for matenal property determination. For example, an onboardor remote processor may use a trained Al model to estimate or predict one or more properties of the material (such as compressive strength, workability, shrinkage, porosity’, maturity’ index, or curing state) based on the raw or pre-processed sensor data. Such models may ingest measurement records directly, or utilize derived features (for example, principal components from impedance spectra or statistical summaries of temperature time series), and the results may be stored in memory, associated with measurement records, or transmitted via one or more communication interfaces as required by the operational context.Further Sensing Element Embodiments

[0420] In one embodiment, the sensor device 200 may be communicably coupled to one or a plurality of sensor elements for comprehensive characterization of concrete, cementitious, or other host materials at one or more of its lifecycle stages (e.g. its batching, transport, or pouring). In some embodiments the sensor device is able to carry out multi-modal impedance measurements based on one or more of: maturity or advanced maturity methods, RF and electromagnetic wave-based sensing, spectroscopic, hyperspectral imaging. Additionally or alternatively, the multi-modal characterization device may further comprise anti-rotation elements and / or communication interfaces (such as those that have been disclosed herein).

[0421] In some embodiments, sensor elements 300 are configured for electromechanical impedance sensing, wherein at least one piezoelectric device (or other electromechanically coupled transducer, such as capacitive micromachined ultrasonic transducers, or CMUTs) is embedded, surface-mounted, or otherwise coupled to the host material and excited by a programmable time-varying voltage or current, generating mechanical oscillations. Additionally or alternatively, the sensor elements may then measure the reflected, transmitted, or resonant responses; the measured electromechanical impedance spectrum, including shifts in resonance peaks, band widths, and phase, may be used as a direct in-situ indicator of evolving mechanical properties (e.g. in the context of concrete, of curing progress).

[0422] Additionally or alternatively, sensor elements 300 may be configured for electrochemical impedance sensing, wherein a plurality of electrodes are disposed within or on the surface of the host material. Additionally or alternatively, the sensor element may be further configured to excite the host material via AC or DC signals, and the resulting current or potential response is measured by the one or more sensor elements, at one or more frequencies. Additionally or alternatively, the sensor device may then determine an electrochemical impedance spectra, made up of resonance peaks and other features, which in the context ofcementitious mixes, may enable determination of ionic mobility, hydration, pore structure, and other electrochemically-relevant properties.

[0423] Additionally or alternatively, the sensor device 200 and / or sensor elements may be configured for electromagnetic wave impedance sensing, and may be composed by at least one antenna or a plurality of antennas 406, 408, configured for excitation (e.g., RF pulse transmission) and / or sensing (e.g., reflection or scattering) within the material, thereby allowing S-parameter or transmission / reflection property measurements. Additionally or alternatively, such parameters may be determined at a plurality of frequencies, with frequency dependence of impedance enabling the probing of dielectric, conductive, or magnetic properties of the material and their evolution over time; in some embodiments, antenna geometry, polarization, and orientation may be specifically selected or controlled for optimal material coupling, including parallel, perpendicular, or oblique arrangements relative to one or more device planes or the material’s surface or to each other.

[0424] Impedance, as used herein, refers to the generalized opposition that a material, system, or interface presents to the flow of a constant or alternating or time-varying signal or energy, and may comprise, in various embodiments, electrical impedance (opposition to electrical current, comprising resistance and reactance), electrochemical impedance (complex response of an ionic or electrochemical system to an applied AC potential, ty pically frequencydependent and reflective of diffusion, charge transfer, double layer, or other phenomena), electromechanical impedance (frequency-dependent complex ratio between mechanical excitation force / displacement and electrical excitation / response in a piezoelectric or similar transducer, sensitive to surrounding material stiffness, damping, and coupling), and electromagnetic wave impedance (the ratio of electric to magnetic fields in an electromagnetic wave as it propagates through or interacts with a medium, wherein the frequency dependence of this impedance may be leveraged to probe dielectric, conductive, or magnetic response and to infer bulk or interfacial material properties); in all cases, impedance may be measured across a range of frequencies, with the resultant spectra or derived parameters (including but not limited to resonance, phase shift, magnitude, and quality' factor) serving as sensitive indicators of material composition and / or material evolution (and in the case of cementitious mixes, this may be indicative of rate or progress of curing and / or hydration, or of porosity, or microstructural change)

[0425] Additionally or alternatively, in some embodiments, the sensor device 200 may be configured such that the strength or mechanical property of the host material (e.g. compressive strength in concrete) is determined by analyzing the impedance spectra, by tracking shifts inthe frequency, amplitude, bandwidth, or other features of resonance peaks or other characteristic markers within the measured impedance response overtime. For example, as the concrete cures and its microstructure develops, the resonance peaks within the electromechanical, electrochemical, or electromagnetic impedance spectra may systematically shift in frequency, broaden, narrow, or change in magnitude, reflecting underlying changes in stiffness, modulus, ionic mobility, or dielectric properties. The sensor device 200 may employ algorithms, either implemented locally or remotely, to automatically detect and quantify these peak shifts and associated spectral changes; these parameters may be directly mapped or correlated (through empirical, physics-based, or machine learning models) to strength development, allowing for continuous, non-destructive, in-situ estimation of evolving material strength and related contextual properties without the need for destructive testing or external calibration, and enabling the precise determination of readiness for load-bearing or further construction operations.

[0426] In some embodiments related to cementitious mixtures, sensor elements 300 may include or be integrated with temperature sensors (e g., thermistors, RTDs. or thermocouples, or digital temperature sensors) to enable maturity method determination, or advanced maturity methods, wherein temperature may be continuously or periodically measured and integrated over time to calculate a maturity' index (such as via the Nurse-Saul method), and wherein advanced maturity methods may further incorporate real-time impedance or wave-based property data (from electromechanical, electrochemical, or electromagnetic sensors) to improve accuracy of predicted setting, strength gain, or other contextual properties, optionally via embedded or remote algorithmic models. Additionally or alternatively, sensor elements may' comprise RF transceivers and antennas, configured for active (pulse-echo, GPR, radar tomography) or passive (ambient or backscatter) electromagnetic measurement modes, optionally at multiple frequency bands, with support for spatial mapping, multi-axis interrogation, or tomography. In some embodiments, the sensor elements comprise optical or photonic sensing capabilities, including but not limited to: lasers, LEDs, broadband lamps, photodetectors, spectrometers, hyperspectral imagers, camera sensors, or fiber optic bundles, configured to excite the material and measure reflected, transmitted, scattered, or emitted spectra, supporting methods such as LIBS, FTIR, Raman, XRD, DRS, and hyperspectral or microscopic imaging for material identification, compositional analysis, water-to-cement ratio measurement, spatial inhomogeneity detection, and crack or defect imaging; in some embodiments, machine learning or advanced signal processing may be implemented locally or remotely for feature extraction and predictive modeling

[0427] Sensor device housings 201 may incorporate anti-rotation elements 206 (as described herein), which in the context of some embodiments, may be designed to maintain a defined orientation of one or more sensor elements 300 relative to the material surface (e.g. concrete, or rebar) or if it has been poured, relative to its mould (e.g. formwork), thereby ensuring that excitation and sensing elements may be held parallel, perpendicular, or at any desired angle to each other and / or to the material surface, in accordance with measurement goals.

[0428] In vario...

Claims

CLAIMS:

1. A sensor device comprising: a housing defining: a top portion; a bottom portion opposite the top portion; and an interior therebetween; and an anti-rotation element attached to the housing and configured to prevent rotation of the housing relative to a support structure.

2. The sensor device according to Claim 1. wherein the anti-rotation element is attached to the top portion of the housing.

3. The sensor device according to Claim 1, wherein the anti-rotation element is attached to a first end of the housing.

4. The sensor device according to Claim 3, wherein a second end of the housing opposite the first end of the housing defines an opening configured to receive a sensing element disposed therein.

5. The sensor device according to Claim 1, wherein the anti-rotation element defines a pair of extensions that extend from the housing and configured to engage at least a portion of the support structure.

6. The sensor device according to Claim 5, wherein the anti-rotation element is configured to prevent rotation of the housing about a longitudinal axis extending along a length of the housing.

7. The sensor device according to Claim 1. wherein the anti-rotation element defines: a proximal portion attached to the housing and substantially perpendicular to a length of the housing; and a distal portion attached to the proximal portion and substantially parallel to the length of the housing.

8. The sensor device according to Claim 1, wherein the anti-rotation element is configured to be disposed proximate an intersection between a pair of support members forming the support structure.

9. The sensor device according to Claim 1, wherein the bottom portion of the housing defines a channel configured to receive a portion of the support structure therein.10 The sensor device according to Claim 9, wherein the channel is disposed along a length of the bottom support member.

11. The sensor device according to Claim 1. wherein the anti-rotation element defines one or more openings.

12. The sensor device according to Claim 11, wherein the one or more openings are configured to receive strapping elements therein.

13. The sensor device according to Claim 1, further comprising sensor circuitry positioned in the interior of the housing.

14. The sensor device according to Claim 13, wherein the sensor circuitry comprises: a printed circuit board (PCB); a processor supported by the PCB; and one or more antennas supported by the PCB and commumcably coupled with the processor.

15. The sensor device according to Claim 14, wherein the one or more antennas are positioned closer to the top portion of the housing than the bottom portion of the housing.

16. The sensor device according to Claim 14, wherein the one or more antennas comprise: a first antenna configured to transmit data via a first communication protocol; and a second antenna configured to transmit data via a second communication protocol.

17. The sensor device according to Claim 1, wherein the top portion of the housing is removably attached to the bottom portion of the housing.

18. The sensor device according to Claim 17, wherein the housing is watertight.

19. The sensor device according to Claim 1, wherein the sensor device is configured to be disposed in cementitious mixture.

20. The sensor device according to Claim 1. wherein the support structure comprises a rebar mesh

Images