Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
52
datasets available to search
ShareScore release 0.9.0
Dataset results
52 results for “IEEE”
Synchronous transmissions on Bluetooth 5 and IEEE 802.15.4 - A replication study
<p>Archive of the following GitHub repository: <a href="https://github.com/romain-jacob/ST_data_and_viz">https://github.com/romain-jacob/ST_data_and_viz</a></p> <p>This repository contains the raw data and analysis scripts of a replication study of synchronous transmissions using the <a href="https://www.nordicsemi.com/en/Software%20and%20tools/Development%20Kits/nRF52840%20Dongle">nRF52840 Dongle</a> where we compare the success rate of synchronous transmission attempts using two transmitters while varying a number of parameters. The repository also contains the source code of a data visualization application, which you can either</p> <ul> <li>run locally or</li> <li><a href="https://github.com/romain-jacob/ST_data_and_viz/blob/master/URL">online in your web browser</a> at <a href="http://explore-st-data.ethz.ch/">http://explore-st-data.ethz.ch/</a></li> </ul> <p>The study is described in more details in the following publication.</p> <blockquote> <p><strong>Synchronous transmissions on Bluetooth 5 and IEEE 802.15.4 - A replication study</strong><br> Romain Jacob, Anna-Brit Schaper, Andreas Biri, Reto da Forno, Lothar Thiele<br> <a href="https://cpsbench20.ethz.ch/">CPS-IoTBench'20</a><br> [ <a href="https://openreview.net/forum?id=BSZPNEUHiS2">Direct link</a> ]</p> </blockquote> <p>The dataset has been collected during the <a href="https://doi.org/10.3929/ethz-b-000375332">Master thesis of Anna-Brit Schaper.</a></p>
[ITU AI/ML Challenge 2021] Dataset IEEE 802.11ax Spatial Reuse
<p>This dataset has been created for the problem statement ITU-ML5G-PS-004 of the ITU AI/ML Challenge (2021 edition). More information can be found here: <a href="https://challenge.aiforgood.itu.int/">https://challenge.aiforgood.itu.int/</a> and <a href="https://www.upf.edu/web/wnrg/2021-edition">https://www.upf.edu/web/wnrg/2021-edition</a>. </p> <p>The dataset contains the information of 3.000 IEEE 802.11ax deployments (divided into two different scenarios) at which the Basic Service Set (BSS) of interest applies different possible OBSS/PD thresholds in the context of the Spatial Reuse (SR) operation. In total, 21 OBSS/PD values are considered for each deployment, and some of the deployments include data from different STA locations. The provided files are expected to be used for training Machine Learning (ML) and Federated Learning (FL) algorithms.</p> <p>More specifically, the dataset is divided as follows:</p> <ul> <li><strong>Scenario 1:</strong> 1,000 different deployments with 2-6 APs and 1 STA per AP. A minimum distance limitation is applied, so that each AP different from AP_A is located at a minimum distance of 10 meters from that one. Each deployment is simulated for each of the 21 possible OBSS/PD thresholds in 11ax. Two files are considered: <ol> <li><a href="https://zenodo.org/api/files/a153e748-7ff5-419d-a7a0-ab7d962d9ccb/output_11ax_sr_simulations_sce1.txt">output_11ax_sr_simulations_sce1.txt</a>: contains the output generated by the simulator for the deployments in Scenario 1.</li> <li><a href="https://zenodo.org/api/files/a153e748-7ff5-419d-a7a0-ab7d962d9ccb/simulator_input_files_sce1.zip">simulator_input_files_sce1.zip</a>: contains the input files used by the simulator to simulate the deployments in Scenario 1.</li> </ol> </li> <li><strong>Scenario 2: </strong>1,000 different deployments with 2-6 APs and 1-4 STAs per AP. No distance limitation is applied. Each deployment is simulated for each of the 21 possible OBSS/PD thresholds in 11ax. Two files are considered: <ol> <li><a href="https://zenodo.org/api/files/a153e748-7ff5-419d-a7a0-ab7d962d9ccb/output_11ax_sr_simulations_sce2.txt">output_11ax_sr_simulations_sce2.txt</a>: contains the output generated by the simulator for the deployments in Scenario 2.</li> <li><a href="https://zenodo.org/api/files/a153e748-7ff5-419d-a7a0-ab7d962d9ccb/simulator_input_files_sce2.zip">simulator_input_files_sce2.zip</a>: contains the input files used by the simulator to simulate the deployments in Scenario 2.</li> </ol> </li> <li><strong>Scenario 3: </strong>1,000 different deployments with 2-6 APs and 1-4 STAs per AP. No distance limitation is applied. Each deployment is simulated for each of the 21 possible OBSS/PD thresholds in 11ax, and for up to 20 different locations of different STAs of the BSS of interest ("BSS_A"). Two files are considered: <ol> <li><a href="https://zenodo.org/api/files/8057ea42-dd8c-4a02-9fe2-0e3bde8b3db0/output_11ax_sr_simulations_sce3.txt">output_11ax_sr_simulations_sce3.txt</a>: contains the output generated by the simulator for the deployments in Scenario 3.</li> <li><a href="https://zenodo.org/api/files/8057ea42-dd8c-4a02-9fe2-0e3bde8b3db0/simulator_input_files_sce3.zip">simulator_input_files_sce3.zip</a>: contains the input files used by the simulator to simulate the deployments in Scenario 3.</li> </ol> </li> <li><strong>Test:</strong> 1,000 different deployments with 2-6 APs and 1-4 STAs per AP. No distance limitation is applied. A random OBSS/PD threshold is applied. Two files are considered: <ol> <li><a href="https://zenodo.org/api/files/22d1265c-0dea-4bf8-a223-e61c45deb076/output_11ax_sr_simulations_test.txt?versionId=91ccbe70-a821-4601-8db7-1763883dc984">output_11ax_sr_simulations_test.txt</a>: contains the output generated by the simulator for the evaluation deployments. The label (throughput) has been replaced with "0s".</li> <li><a href="https://zenodo.org/api/files/8057ea42-dd8c-4a02-9fe2-0e3bde8b3db0/simulator_input_files_test.zip?versionId=b1581c0b-419c-422b-bb2d-4dbf77f05dd2">simulator_input_files_test.zip</a>: contains the input files used by the simulator to simulate the evaluation deployments.</li> </ol> </li> </ul>
Metrics and Methods used in IEEE/ACM HRI and IEEE RoMan Conference Proceedings from 2015 to 2021 Data
<p>This work analyzes a total of 1464 papers through examination of seven years of HRI Conference proceedings(2015 through 2021) and six years of Ro-Man Conference proceedings (2015 through 2020) to present a holistic snapshot of the state of methods and metrics in HRI research. Workshop proposals, late-breaking results, keynote talk abstracts, and demo presentations were omitted from this study due to varying methodologies and shorter study timeframes.</p>
SMART - Self-adaptive Machine Learning Approach for Real-time Tuning of IEEE 802.11 PHY and MAC layers
<p><strong>Introduction</strong></p> <p>Worldwide the demand for wireless access networks providing very high throughputs has been increasing exponentially, namely due to bandwidth-hungry applications such as high definition video streaming and augmented reality. In order to fulfil these requirements, the Wi-Fi standard was enriched with new amendments, such as IEEE 802.11n, IEEE 802.11ac, and recently IEEE 802.11ax (Wi-Fi 6). New parameters have been proposed for both physical (PHY) and media access control (MAC) layers, including channel bonding, short guard interval (SGI), and advanced modulation and coding schemes (MCS).</p> <p>However, the high variability of the signal strength in the wireless radio channel, allied to the channel asymmetry, makes the selection of optimal configurations for these parameters a challenge. Typically, these parameters are configured with a default value. For runtime optimization, some algorithms have already been proposed. Still, they were designed considering legacy IEEE 802.11 releases and static scenarios. Besides, these parameters have their trade-offs that need to be properly managed. To help dealing with this, machine learning has been recently introduced in wireless networks, providing the intelligence that networks need in order to be smart and self-adaptive.</p> <p>SWOP (Smart Wireless Optimization) is a cross-layer optimization approach for Wi-Fi networks extending the current Rate Adaptation (RA) approach, for instance, followed by the well-known Minstrel algorithm widely used in practice. Our approach takes advantage of Deep Reinforcement Learning (DRL) in order to learn the optimal Wi-Fi link configuration. By considering the wireless channel as the environment, the transmitter node (the agent) chooses the best link parameters (the action) in order to maximize the throughput (the reward) based on the channel metrics captured from the environment (the state). In this work we propose a simple DRL-based Wi-Fi Rate Adaptation (RA) algorithm, named Data-driven Algorithm for Rate Adaptation (DARA), which is one of the modules of Smart Wireless Optimization (SWOP)</p> <p>SMART aimed to run a set of wireless experiments on top of w-iLab.t testbeds provided by the Fed4FIRE+ project to directly validate our DRL model and learn a policy from the wireless experiments executed in a controlled environment. However, after facing difficulties with the scenarios we could achieve on the real testbed, we decided to train and test DARA using a trace-based simulation approach. In simulation, we could train our model in scenarios that are more complex and diverse whilst easy to configure, when compared to real testbeds. The w-iLab.t testbeds were still used to capture data traces (e.g. Signal-to-Noise Ratio, position of nodes, transmission power and link distance) that were then injected in ns-3 for validating DARA.</p> <p>With this work, we concluded that DARA performance is impacted when operating in scenarios with asymmetric links, which is common in the highly dynamic and unpredictable wireless environments. Furthermore, the asymmetry offset varies between scenarios and it may also change for the same scenario, as time progresses. This randomness is not addressed when solely considering the SNR as the link metric, posing a challenge in the learning phase of DARA. Despite these limitations, the results obtained show that DARA still achieves up to 14.9% higher throughput higher than Minstrel [1] and slightly lower than Ideal [2] for most of the scenarios. The results obtained will serve as a basis to support our ongoing and future research.</p> <p> </p> <p><strong>Folder Organization</strong></p> <p>The following dataset presents the results of the SMART project, organized in different folders for each Rate Adaptation Algorithm, as well as the traces that were used to obtain such results:</p> <ul> <li><strong>DARA: </strong>Results obtained using our solution <strong>(Naming Convention #1, Folder Content #1)</strong></li> <li><strong>MIN: </strong>Results obtained using Minstrel-HT <strong>(Naming Convention #1, Folder Content #2)</strong></li> <li><strong>ID: </strong>Results obtained using Ideal <strong>(Naming Convention #1, Folder Content #2)</strong></li> <li><strong>TRACES: </strong>Trace files used to obtain the results present in this dataset <strong>(Naming Convention #2, Folder Content #3)</strong></li> </ul> <p><strong>Naming Convention #1 – RAA TID TP TO:</strong></p> <ul> <li>Rate Adaptation Algorithm<strong> (RAA) </strong> <ul> <li><strong>drl </strong>– Data Driven Algorithm for Rate Adaptation</li> <li><strong>min </strong>– MinstrelHTWifiManager</li> <li><strong>id </strong>– IdealWifiManager</li> </ul> </li> <li>Trace ID<strong> (TID)</strong> <ul> <li><strong>3 </strong>up to<strong> 8</strong></li> </ul> </li> <li>Transport Protocol<strong> (TP)</strong> <ul> <li><strong>udp </strong>– User Datagram Protocol</li> </ul> </li> <li>Traffic Orientation<strong> (TO)</strong> <ul> <li><strong>normal </strong>– A<strong>-></strong>B</li> <li><strong>reversed </strong>– B<strong>-></strong>A</li> </ul> </li> </ul> <p><strong>Naming Convention #2 – TID_TXP:</strong></p> <ul> <li>Trace ID<strong> (TID) </strong> <ul> <li><strong>3 </strong>up to<strong> 8</strong></li> </ul> </li> <li>Transmitting Power in dBm <strong>(TXP) </strong> <ul> <li><strong>3, 5, 7, 9, 12 dBm </strong></li> </ul> </li> </ul> <p><strong>Folder Content #1: </strong></p> <ul> <li><em>checkpoint_ RAA TID TP TO</em><strong> (Folder)</strong> <ul> <li><strong>Policy Checkpoint</strong> with which the results were obtained</li> </ul> </li> <li> <ul> <li><strong>Flowmonitor </strong>output for the configured scenario</li> </ul> </li> <li> <ul> <li>Column 1 – <strong>Step Counter</strong></li> <li>Column 2 – <strong>Reward Value</strong></li> <li>Column 3 – <strong>Observation Value</strong></li> <li>Column 4 – <strong>Action Value</strong></li> </ul> </li> <li> <ul> <li>Column 1 – <strong>Simulation Time </strong>(seconds)</li> <li>Column 2 – <strong>Throughput </strong>(Mbit/100ms)</li> </ul> </li> </ul> <p><strong>Folder Content #2: </strong></p> <ul> <li> <ul> <li><strong>Flowmonitor </strong>output for the configured scenario</li> </ul> </li> <li> <ul> <li>Column 1 – <strong>Simulation Time </strong>(seconds)</li> <li>Column 2 – <strong>Throughput </strong>(Mbit/100ms)</li> </ul> </li> </ul> <p><strong>Folder Content #3 - </strong>Source: <a href="https://zenodo.org/record/3713271#.YjjBVDXLdhE">https://zenodo.org/record/3713271#.YjjBVDXLdhE</a><strong>: </strong></p> <p>· <em>date_time</em><strong>.cfg </strong>configuration details of the experiment</p> <p>· <em>date_time_NodeID</em><a href="https://zenodo.org/record/3713271#_ftn1"><strong><em><sup>[1]</sup></em></strong></a><em>_SenderID</em><a href="https://zenodo.org/record/3713271#_ftn2"><strong><em><sup>[2]</sup></em></strong></a><em>_ReceiverID</em><a href="https://zenodo.org/record/3713271#_ftn3"><strong><em><sup>[3]</sup></em></strong></a><em>_FlowType</em><a href="https://zenodo.org/record/3713271#_ftn4"><strong><em><sup>[4]</sup></em></strong></a><em>_Params</em><a href="https://zenodo.org/record/3713271#_ftn5"><strong><em><sup>[5]</sup></em></strong></a><strong>.snr </strong>– logs of the Signal/Noise ratio (1 file per node/flow) </p> <p>· <em>date_time_NodeID_SenderID_ReceiverID_FlowType_Params</em><strong>.stats</strong> – logs of the packets received (1 file per node/flow) </p> <p><a href="https://zenodo.org/record/3713271#_ftnref1"><sub>[1]</sub></a><sub> ID of the node Logging node</sub></p> <p><a href="https://zenodo.org/record/3713271#_ftnref2"><sub>[2]</sub></a><sub> ID of the Sender node</sub></p> <p><a href="https://zenodo.org/record/3713271#_ftnref3"><sub>[3]</sub></a><sub> ID of the Receiver node</sub></p> <p><a href="https://zenodo.org/record/3713271#_ftnref4"><sub>[4]</sub></a><sub> Flow type: Unidirectional, Bidirectional or Unidirectional with Multiple Access</sub></p> <p><a href="https://zenodo.org/record/3713271#_ftnref5"><sub>[5]</sub></a><sub> Configurable parameters: Sender/Receiver Transmission Power and Data Rate (when applicable)</sub></p> <p> </p> <p><strong>References</strong></p> <p>1. F. FietKau, “Minstrel_HT: New rate control module for 802.11n [LWN.net]”. Mrt-2010.</p> <p>2. “ns-3: ns3::IdealWifiManager Class Reference,” Jan 2021, [Online; accessed 23. Jun. 2021]. Available: <a href="https://www.nsnam.org/docs/release/3.33/doxygen/classns3_1_1_ideal_wifi%20manager.html">https://www.nsnam.org/docs/release/3.33/doxygen/classns3_1_1_ideal_wifi manager.html</a></p>
IEEE New England 39-bus test case: Dataset for the Transient Stability Assessment
<p>The <strong>dataset</strong> contains <strong>350</strong> <strong>features</strong> engineered from the phasor measurements (PMU-type) signals from the <strong>IEEE New England 39-bus power system</strong> test case network, which are generated from the 9360 systematic MATLAB®/Simulink electro-mechanical transients simulations. It was prepared to serve as a convenient and open database for experimenting with different types of <strong>machine learning</strong> techniques for <strong>transient stability assessment</strong> (TSA) of electrical power systems.</p> <p>Different load and generation levels of the New England 39-bus benchmark power system were systematically covered, as well as all three major types of short-circuit events (three-phase, two-phase and single-phase faults) in all parts of the network. The consumed power of the network was set to 80%, 90%, 100%, 110% and 120% of the basic system load levels. The short-circuits were located on the busbar or on the transmission line (TL). When they were located on a TL, it was assumed that they can occur at 20%, 40%, 60%, and 80% of the line length. Features were obtained directly from the time-domain signals at the pickup time (pre-fault value) and at the trip time (post-fault value) of the associated distance protection relays.</p> <p>This is a <strong>stochastic dataset</strong> of 3120 cases, created from the population of 9360 systematic simulations, which features a statistical distribution of different fault types, as follows: single-phase (70%), double-phase (20%) and three-phase faults (10%). It also features a <strong>class imbalance</strong>, with less than 20% of cases belonging to the unstable class. Dataset is a compressed CSV file.</p> <p><strong>List of feature names in the dataset:</strong></p> <ul> <li><em>WmGx</em> - rotor speed for each generator Gx, from G1 to G10,</li> <li><em>DThetaGx</em> - rotor angle deviation for each generator Gx, from G1 to G10,</li> <li><em>ThetaGx</em> - rotor mechanical angle for each generator Gx, from G1 to G10,</li> <li><em>VtGx</em> - stator voltage for each generator Gx, from G1 to G10,</li> <li><em>IdGx</em> - stator d-component current for each generator Gx, from G1 to G10,</li> <li><em>IqGx</em> - stator q-component current for each generator Gx, from G1 to G10,</li> <li><em>LAfvGx</em> - pre-fault power load angle for each generator Gx, from G1 to G10,</li> <li><em>LAlvGx</em> - post-fault power load angle for each generator Gx, from G1 to G10,</li> <li><em>PfvGx</em> - pre-falut value of the generator active power for each generator Gx, from G1 to G10,</li> <li><em>PlvGx</em> - post-falut value of the generator active power for each generator Gx, from G1 to G10,</li> <li><em>QfvGx</em> - pre-falut value of the generator reactive power for each generator Gx, from G1 to G10,</li> <li><em>QlvGx</em> - post-falut value of the generator reactive power for each generator Gx, from G1 to G10,</li> <li><em>VAfvBx</em> - pre-fault bus voltage magnitude in phase A for each bus Bx, from B1 to B39,</li> <li><em>VBfvBx</em> - pre-fault bus voltage magnitude in phase B for each bus Bx, from B1 to B39,</li> <li><em>VCfvBx</em> - pre-fault bus voltage magnitude in phase C for each bus Bx, from B1 to B39,</li> <li><em>VAlvBx</em> - post-fault bus voltage magnitude in phase A for each bus Bx, from B1 to B39,</li> <li><em>VBlvBx</em> - post-fault bus voltage magnitude in phase B for each bus Bx, from B1 to B39,</li> <li><em>VClvBx</em> - post-fault bus voltage magnitude in phase C for each bus Bx, from B1 to B39,</li> <li><em>Stability</em> - binary indicator (0/1) that determines if the power system was stable or unstable (0 - stable, 1 - unstable); this is the label variable.</li> </ul> <p><strong>License</strong>:<strong> </strong>Creative Commons CC-BY.</p> <p><strong>Disclaimer</strong>: This dataset is provided "as is", without any warranties of any kind.</p>
Labeled dataset of IEEE 802.11 probe requests
<p><strong>Introduction</strong> <br> <br> The 802.11 standard includes several management features and corresponding frame types. One of them are probe requests (PR). They are sent by mobile devices in the unassociated state to search the nearby area for existing wireless networks. The frame part of PRs consists of variable length fields called information elements (IE). IE fields represent the capabilities of a mobile device, such as data rates. <br> The dataset includes PRs collected in a controlled rural environment and in a semi-controlled indoor environment under different measurement scenarios. <br> It can be used for various use cases, e.g., analysing MAC randomization, determining the number of people in a given location at a given time or in different time periods, analysing trends in population movement (streets, shopping malls, etc.) in different time periods, etc.</p> <p> <br> <strong>Measurement setup</strong> <br> <br> The system for collecting PRs consists of a Raspberry Pi 4 (RPi) with an additional WiFi dongle to capture Wi-Fi signal traffic in monitoring mode. Passive PR monitoring is performed by listening to 802.11 traffic and filtering out PR packets on a single WiFi channel.<br> The following information about each PR received is collected: MAC address, Supported data rates, extended supported rates, HT capabilities, extended capabilities, data under extended tag and vendor specific tag, interworking, VHT capabilities, RSSI, SSID and timestamp when PR was received.<br> The collected data was forwarded to a remote database via a secure VPN connection. A Python script was written using the Pyshark package for data collection, preprocessing and transmission.</p> <p><br> <strong>Data preprocessing</strong></p> <p>The gateway collects PRs for each consecutive predefined scan interval (10 seconds). During this time interval, the data are preprocessed before being transmitted to the database.<br> For each detected PR in the scan interval, IEs fields are saved in the following JSON structure:<br> PR_IE_data =<br> {<br> 'DATA_RTS': {'SUPP': DATA_supp , 'EXT': DATA_ext},<br> 'HT_CAP': DATA_htcap,<br> 'EXT_CAP': {'length': DATA_len, 'data': DATA_extcap},<br> 'VHT_CAP': DATA_vhtcap,<br> 'INTERWORKING': DATA_inter,<br> 'EXT_TAG': {'ID_1': DATA_1_ext, 'ID_2': DATA_2_ext ...},<br> 'VENDOR_SPEC': {VENDOR_1:{<br> 'ID_1': DATA_1_vendor1,<br> 'ID_2': DATA_2_vendor1<br> ...},<br> VENDOR_2:{<br> 'ID_1': DATA_1_vendor2,<br> 'ID_2': DATA_2_vendor2<br> ...}<br> ...}<br> }</p> <p> <br> Supported data rates and extended supported rates are represented as arrays of values that encode information about the rates supported by a mobile device. The rest of the IEs data is represented in hexadecimal format. Vendor Specific Tag is structured differently than the other IEs. This field can contain multiple vendor IDs with multiple data IDs with corresponding data. Similarly, the extended tag can contain multiple data IDs with corresponding data. <br> Missing IE fields in the captured PR are not included in <em>PR_IE_DATA</em>.</p> <p>When a new MAC address is detected in the current scan time interval, the data from PR is stored in the following structure:</p> <p>{'MAC': MAC_address, 'SSIDs': [ SSID ], 'PROBE_REQs': [PR_data] },</p> <p>where <em>PR_data</em> is structured as follows:<br> {<br> 'TIME': [ DATA_time ],<br> 'RSSI': [ DATA_rssi ],<br> 'DATA': PR_IE_data<br> }.</p> <p>This data structure allows storing only <em>TOA</em> and <em>RSSI</em> for all PRs originating from the same MAC address and containing the same <em>PR_IE_data</em>. All SSIDs from the same MAC address are also stored. <br> The data of the newly detected PR is compared with the already stored data of the same MAC in the current scan time interval. <br> If identical PR's IE data from the same MAC address is already stored, then only data for the keys <em>TIME</em> and <em>RSSI</em> are appended.<br> If no identical PR's IE data has yet been received from the same MAC address, then PR_data structure of the new PR for that MAC address is appended to <em>PROBE_REQs</em> key. <br> The preprocessing procedure is shown in Figure ./Figures/Preprocessing_procedure.png <br> At the end of each scan time interval, all processed data is sent to the database along with additional metadata about the collected data e.g. wireless gateway serial number and scan start and end timestamps. For an example of a single PR captured, see the ./Single_PR_capture_example.json file.</p> <p><br> <strong>Environments description</strong> <br> <br> We performed measurements in a controlled rural outdoor environment and in a semi-controlled indoor environment of the Jozef Stefan Institute.<br> See the Excel spreadsheet Measurement_informations.xlsx for a list of mobile devices tested. <br> <br> <strong>Indoor environment </strong><br> <br> We used 3 RPi's for the acquisition of PRs in the Jozef Stefan Institute. They were placed indoors in the hallways as shown in the ./Figures/RPi_locations_JSI.png. Measurements were performed on weekend to minimize additional uncontrolled traffic from users' mobile devices. While there is some overlap in WiFi coverage between the devices at the location 2 and 3, the device at location 1 has no overlap with the other two devices.</p> <p> <strong>Rural environment outdoors</strong> <br> <br> The three RPi's used to collect PRs were placed at three different locations with non-overlapping WiFi coverage, as shown in ./Figures/RPi_locations_rural_env.png. Before starting the measurement campaign, all measured devices were turned off and the environment was checked for active WiFi devices. We did not detect any unknown active devices sending WiFi packets in the RPi's coverage area, so the deployment can be considered fully controlled.<br> All known WiFi enabled devices that were used to collect and send data to the database used a global MAC address, so they can be easily excluded in the preprocessing phase. MAC addresses of these devices can be found in the ./Measurement_informations.xlsx spreadsheet.<br> Note: The Huawei P20 device with ID 4.3 was not included in the test in this environment.</p> <p><br> <strong>Scenarios description</strong> <br> <br> We performed three different scenarios of measurements. <br> <br> <strong>Individual device measurements</strong><br> <br> For each device, we collected PRs for one minute with the screen on, followed by PRs collected for one minute with the screen off. In the indoor environment the WiFi interfaces of the other devices not being tested were disabled. In rural environment other devices were turned off. Start and end timestamps of the recorded data for each device can be found in the ./Measurement_informations.xlsx spreadsheet under the <em>Indoor environment of Jozef Stefan Institute</em> sheet and the <em>Rural environment</em> sheet.</p> <p> <strong>Three groups test</strong></p> <p>In this measurement scenario, the devices were divided into three groups. The first group contained devices from different manufacturers. The second group contained devices from only one manufacturer (Samsung). Half of the third group consisted of devices from the same manufacturer (Huawei), and the other half of devices from different manufacturers. The distribution of devices among the groups can be found in the ./Measurement_informations.xlsx spreadsheet. <br> <br> The same data collection procedure was used for all three groups. Data for each group were collected in both environments at three different RPis locations, as shown in ./Figures/RPi_locations_JSI.png and ./Figures/RPi_locations_rural_env.png. <br> At each location, PRs were collected from each group for 10 minutes with the screen on. Then all three groups switched locations and the process was repeated. Thus, the dataset contains measurements from all three RPi locations of all three groups of devices in both measurement environments. The group movements and the timestamps for the start and end of the collection of PRs at each loacation can be found in spreadsheet ./Measurement_informations.xlsx.</p> <p> <strong>One group test</strong> <br> <br> In the last measurement scenario, all devices were grouped together. In rural evironement we first collected PRs for 10 minutes while the screen was on, and then for another 10 minutes while the screen was off. In indoor environment data were collected at first location with screens on for 10 minutes. Then all devices were moved to the location of the next RPi and PRs were collected for 5 minutes with the screen on and then for another 5 minutes with the screen off.</p> <p><strong>Folder structure</strong> <br> <br> The root directory contains two files in JSON format for each of the environments where the measurements took place (Data_indoor_environment.json and Data_rural_environment.json). Both files contain collected PRs for the entire day that the measurements were taken (12:00 AM to 12:00 PM) to get a sense of the behaviour of the unknown devices in each environment. The spreadsheet ./Measurement_informations.xlsx. contains three sheets. <em>Devices description</em> contains general information about the tested devices, RPis, and the assigned group for each device. The sheets <em>Indoor environment of Jozef Stefan Institute</em> and <em>Rural environment</em> contain the corresponding timestamps for the start and end of each measurement scenario. For the scenario where the devices were divided into groups, additional information about the movements between locations is included. The location names are based on the RPi gateway ID and may differ from those on the figures showing the locations of the RPIs for each environment.<br> The ./Figures folder contains the figures already mentioned above.</p>
Dataset of IEEE 802.11 probe requests from an uncontrolled urban environment
<p><strong>Introduction</strong></p> <p>The 802.11 standard includes several management features and corresponding frame types. One of them are Probe Requests (PR), which are sent by mobile devices in an unassociated state to scan the nearby area for existing wireless networks. The frame part of PRs consists of variable-length fields, called Information Elements (IE), which represent the capabilities of a mobile device, such as supported data rates.</p> <p>This dataset contains PRs collected over a seven-day period by four gateway devices in an uncontrolled urban environment in the city of Catania.</p> <p>It can be used for various use cases, e.g., analyzing MAC randomization, determining the number of people in a given location at a given time or in different time periods, analyzing trends in population movement (streets, shopping malls, etc.) in different time periods, etc.</p> <p><strong> Related dataset</strong></p> <p>Same authors also produced the <a href="https://zenodo.org/record/7503594">Labeled dataset of IEEE 802.11 probe requests</a> with same data layout and recording equipment.</p> <p><br> <strong>Measurement setup</strong> </p> <p>The system for collecting PRs consists of a Raspberry Pi 4 (RPi) with an additional WiFi dongle to capture WiFi signal traffic in monitoring mode (gateway device).<br> Passive PR monitoring is performed by listening to 802.11 traffic and filtering out PR packets on a single WiFi channel.</p> <p>The following information about each received PR is collected:<br> - MAC address<br> - Supported data rates<br> - extended supported rates<br> - HT capabilities<br> - extended capabilities<br> - data under extended tag and vendor specific tag<br> - interworking<br> - VHT capabilities<br> - RSSI<br> - SSID<br> - timestamp when PR was received.</p> <p>The collected data was forwarded to a remote database via a secure VPN connection.<br> A Python script was written using the Pyshark package to collect, preprocess, and transmit the data.</p> <p><br> <strong>Data preprocessing</strong></p> <p><br> The gateway collects PRs for each successive predefined scan interval (10 seconds). During this interval, the data is preprocessed before being transmitted to the database.<br> For each detected PR in the scan interval, the IEs fields are saved in the following JSON structure:</p> <pre><code class="language-json">PR_IE_data = { 'DATA_RTS': {'SUPP': DATA_supp , 'EXT': DATA_ext}, 'HT_CAP': DATA_htcap, 'EXT_CAP': {'length': DATA_len, 'data': DATA_extcap}, 'VHT_CAP': DATA_vhtcap, 'INTERWORKING': DATA_inter, 'EXT_TAG': {'ID_1': DATA_1_ext, 'ID_2': DATA_2_ext ...}, 'VENDOR_SPEC': {VENDOR_1:{ 'ID_1': DATA_1_vendor1, 'ID_2': DATA_2_vendor1 ...}, VENDOR_2:{ 'ID_1': DATA_1_vendor2, 'ID_2': DATA_2_vendor2 ...} ...} }</code></pre> <p><br> Supported data rates and extended supported rates are represented as arrays of values that encode information about the rates supported by a mobile device. The rest of the IEs data is represented in hexadecimal format. Vendor Specific Tag is structured differently than the other IEs. This field can contain multiple vendor IDs with multiple data IDs with corresponding data. Similarly, the extended tag can contain multiple data IDs with corresponding data. <br> Missing IE fields in the captured PR are not included in <em>PR_IE_DATA</em>.</p> <p>When a new MAC address is detected in the current scan time interval, the data from PR is stored in the following structure:</p> <pre><code class="language-json">{'MAC': MAC_address, 'SSIDs': [ SSID ], 'PROBE_REQs': [PR_data] },</code></pre> <p>where <em>PR_data</em> is structured as follows:</p> <pre><code class="language-json">{ 'TIME': [ DATA_time ], 'RSSI': [ DATA_rssi ], 'DATA': PR_IE_data }.</code></pre> <p> </p> <p>This data structure allows to store only 'TOA' and 'RSSI' for all PRs originating from the same MAC address and containing the same 'PR_IE_data'. All SSIDs from the same MAC address are also stored.<br> The data of the newly detected PR is compared with the already stored data of the same MAC in the current scan time interval.<br> If identical PR's IE data from the same MAC address is already stored, only data for the keys 'TIME' and 'RSSI' are appended.<br> If identical PR's IE data from the same MAC address has not yet been received, then the PR_data structure of the new PR for that MAC address is appended to the 'PROBE_REQs' key.<br> The preprocessing procedure is shown in Figure ./Figures/Preprocessing_procedure.png</p> <p>At the end of each scan time interval, all processed data is sent to the database along with additional metadata about the collected data, such as the serial number of the wireless gateway and the timestamps for the start and end of the scan. For an example of a single PR capture, see the <em>Single_PR_capture_example.json</em> file.</p> <p><br> <strong>Folder structure</strong></p> <p>For ease of processing of the data, the dataset is divided into 7 folders, each containing a 24-hour period.<br> Each folder contains four files, each containing samples from that device.</p> <p>The folders are named after the start and end time (in UTC).<br> For example, the folder [2022-09-22T22-00-00_2022-09-23T22-00-00](2022-09-22T22-00-00_2022-09-23T22-00-00) contains samples collected between <em>23th of September 2022 00:00 local time</em>, until <em>24th of September 2022 00:00</em> local time.</p> <p>Files representing their location via mapping:<br> - 1.json -> location 1<br> - 2.json -> location 2<br> - 3.json -> location 3<br> - 4.json -> location 4</p> <p><strong>Environments description</strong> </p> <p>The measurements were carried out in the city of Catania, in Piazza Università and Piazza del Duomo<br> The gateway devices (rPIs with WiFi dongle) were set up and gathering data before the start time of this dataset.<br> As of September 23, 2022, the devices were placed in their final configuration and personally checked for correctness of installation and data status of the entire data collection system.<br> Devices were connected either to a nearby Ethernet outlet or via WiFi to the access point provided.</p> <p>Four Raspbery Pi-s were used:<br> - location 1 -> Piazza del Duomo - Chierici building (balcony near Fontana dell’Amenano)<br> - location 2 -> southernmost window in the building of Via Etnea near Piazza del Duomo<br> - location 3 -> nothernmost window in the building of Via Etnea near Piazza Università<br> - location 4 -> first window top the right of the entrance of the University of Catania</p> <p>Locations were suggested by the authors and adjusted during deployment based on physical constraints (locations of electrical outlets or internet access)<br> Under ideal circumstances, the locations of the devices and their coverage area would cover both squares and the part of Via Etna between them, with a partial overlap of signal detection. The locations of the gateways are shown in Figure ./Figures/catania.png.</p> <p> <strong>Known dataset shortcomings</strong></p> <p>Due to technical and physical limitations, the dataset contains some identified deficiencies.</p> <p>PRs are collected and transmitted in 10-second chunks.<br> Due to the limited capabilites of the recording devices, some time (in the range of seconds) may not be accounted for between chunks if the transmission of the previous packet took too long or an unexpected error occurred.</p> <p>Every 20 minutes the service is restarted on the recording device.<br> This is a workaround for undefined behavior of the USB WiFi dongle, which can no longer respond.<br> For this reason, up to 20 seconds of data will not be recorded in each 20-minute period.</p> <p>The devices had a scheduled reboot at 4:00 each day which is shown as missing data of up to a few minutes.</p> <p> <strong> Location 1 - Piazza del Duomo - Chierici</strong></p> <p> The gateway device (rPi) is located on the second floor balcony and is hardwired to the Ethernet port. This device appears to function stably throughout the data collection period.<br> Its location is constant and is not disturbed, dataset seems to have complete coverage.</p> <p> <strong>Location 2 - Via Etnea - Piazza del Duomo</strong></p> <p> The device is located inside the building.<br> During working hours (approximately 9:00-17:00), the device was placed on the windowsill. However, the movement of the device cannot be confirmed.<br> As the device was moved back and forth, power outages and internet connection issues occurred.<br> The last three days in the record contain no PRs from this location.</p> <p> <strong> Location 3 - Via Etnea - Piazza Università</strong></p> <p> Similar to Location 2, the device is placed on the windowsill and moved around by people working in the building.<br> Similar behavior is also observed, e.g., it is placed on the windowsill and moved inside a thick wall when no people are present.<br> This device appears to have been collecting data throughout the whole dataset period.<br> <br> <strong> Location 4 - Piazza Università</strong></p> <p> This location is wirelessly connected to the access point.<br> The device was placed statically on a windowsill overlooking the square.<br> Due to physical limitations, the device had lost power several times during the deployment.<br> The internet connection was also interrupted sporadically.</p> <p><strong>Recognitions</strong></p> <p>The data was collected within the scope of <a href="https://www.resilocproject.eu/">Resiloc project</a> with the help of City of Catania and project partners.</p>
efantnu/drep-2021-collab-MINESParisTech-NTNU: Pre-print version IEEE Access
<p>This repository contains the data sets of the paper "Allocation of spinning reserves in autonomous grids considering frequency stability constraints and short-term solar power variations" authored by Erick F. Alves, Louis Polleux, Gilles Guerassimoff, Magnus Korpås, Elisabetta Tedeschi. With these files, it is possible to reproduce most simulations and results obtained in the paper.</p> <p>Folder organization</p> <ul> <li>Results: final results and values of intermediate steps of the optimization model implemented in Gurobi 9.1 and described in section III-A and III-B of the paper.</li> <li>Validation: test system implemented in OpenModelica for validation of the results and described in section III-C of paper.</li> <li>Solar convex hulls: hourly convex hulls obtained using the procedure detailed in Appendix A.</li> <li>Solar irradiance profiles: high-resolution irradiance timeseries from NREL used to identify the worst-case solar PV ramp scenarios.</li> </ul>
Modified pool system based on the IEEE RTS-96 system incl. 39 wind power producers
<p>This is the data-set associated with the numerical simulations in the paper "A. Papakonstantinou, P. Pinson, <em>Population Dynamics for Renewables in Electricity Markets: A Minority Game View</em>". The paper will be presented in 2016 International Conference on Probabilistic Methods Applied to Power Systems (PMAPS) in Oct. 16-20, 2016 in Beijing, China.</p> <p>We modify the original data-set [1] by adding the marginal costs for conventional generation introduced by [2] and flexible generators capable of providing up and down regulation following [3]. The cost of up-regulation is assumed to be 10% higher than the day-ahead cost and the cost of down-regulation 9% less than the day-ahead ahead costs.</p> <p>Furthermore, regarding stochastic generation, we assume zero marginal and cost free spilling action, while load shedding induces a cost of 1000 EUR/MWh. Finally, we assume that the total demand is at 80% of the conventional generation [3], while the total capacity of the 39 stochastic producers is at 30% of the demand.</p> <p>Within the data file the specific data used for the analysis in the paper are under pes_input().</p> <p>[1] IEEE RTS Task Force of APM Subcommittee, “The ieee reliability test system-1996.” IEEE Transactions on Power Systems, vol. 14, no. 3, pp. 1010–1020, 1999.</p> <p>[2] D. Kirschen. Unit commitment data for modernized ieee rts-96. Accessed: 10-03-2016. [Online]. Available: http://www.ee.washington.edu/research/real/library.html</p> <p>[3] A. J. Conejo, M. Carri ́on, and J. M. Morales, Decision Making Under Uncertainty in Electricity Markets. Springer, 2010.</p> <p> </p> <p> </p> <p> </p> <p> </p>
Data set published in the IEEE TCAD article "Custom Multi-Cache Architectures for Heap-Manipulating Programs"
<p>This data set contains the results presented in the paper "Custom Multi-Cache Architectures for Heap-Manipulating Programs", published in the IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (TCAD) in 2016.</p> <p>The data set consists of two parts, a Microsoft Excel file ('FPGA_implementation_results.xlsx') and a Matlab script ('plot_cache_performance.m', in combination with measurement results in an ascii file).</p> <p>The Excel file contains<br /> - the FPGA resource utilisation,<br /> - execution time measurements,<br /> - hit rate measurement of the multi-cache system,<br /> - and power measurements</p> <p>of different FPGA designs with different on-chip cache configurations. The resource utilisation is split into FPGA slices, LUTs, FlipFlops, DSP slices and block RAMs. Results in this file can be found in Table I-IV in the paper. Please refer to the paper for more information or email f.winterstein12@imperial.ac.uk.</p> <p>The Matlab script loads a data file ('cache_performance_N16384_L1') containing the hit rate measurements for different cache sizes of two direct-mapped cache with 64bit line width. The script produces a 3D 'skyscraper' plot, i.e. a grid of coloured bars. Each bar corresponds to the hit rate measured at the particular cache size configuration. The plot is saved in the file 'surf.pdf'. The script was used to produce Figure 4 of the paper. Please refer to the paper for more information or email f.winterstein12@imperial.ac.uk.</p> <p>In addition to this description, we include an author copy of the paper. Note that this is not the official version of the paper. Please cite the original IEEE TCAD article if you use the data.</p>
IEEE ICME 2024 Grand Challenge: Semi-supervised Acoustic Scene Classification under Domain Shift Evaluation Dataset
<p>The Chinese Acoustic Scene (CAS) 2023 dataset is a large-scale dataset that serves as a foundation for research related to environmental acoustic scenes. The dataset includes 10 common acoustic scenes, with a total duration of over 130 hours. Each audio clip is 10 seconds long with metadata about the recording location and timestamp. The dataset was collected by members of the <em>Joint Laboratory of Environmental Sound Sensing at the School of Marine Science and Technology, Northwestern Polytechnical University</em>. The data collection period spanned from April 2023 to September 2023, covering 22 different cities across China. The CAS 2023 dataset was collected using the XS-SN-2BE1 manufactured by <em>Xi'an Lianfeng Acoustic Technologies Co., Ltd</em> (https://www.lfxstek.com/). </p> <p>The ICME 2024 <em>Semi-supervised Acoustic Scene Classification under Domain Shift</em> challenge (https://2024.ieeeicme.org/grand-challenge-proposals/, https://ascchallenge.xshengyun.com/) dataset consists of development (https://zenodo.org/records/10616533) and evaluation datasets, all derived from the CAS 2023 dataset. The evaluation dataset includes 1,100 recordings, where data are selected from 12 cities, with 5 unseen cities specifically chosen to provide a more comprehensive evaluation of submissions under domain shift.</p> <p>Baseline: https://github.com/JishengBai/ICME2024ASC</p> <p>Acoustic scenes (10): Bus, Airport, Metro, Restaurant, Shopping mall, Public square, Urban park, Traffic street, Construction site, Bar</p>
Local optima network metrics from the IEEE CEC 2024 paper "Information flow and Laplacian dynamics on local optima networks"
<p>Local optima network metrics from the IEEE CEC 2024 paper "Information flow and Laplacian dynamics on local optima networks". </p> <p>There are two CSV files: one for each of the two iterated local search confgurations used to construct the networks (low or high). In each file, a row contains information about one QAPLIB instance. Easch row contains all the metrics computed for the associated LON and also algorithm performance data on the instance. </p>
Model weights for a Weather4cast 2021 Challenge IEEE Big Data Cup Stage solution
<p>This repository contains the pre-trained model weights for the TensorFlow/Keras models used in the <a href="https://www.iarai.ac.at/weather4cast/2021-competition/challenge/">Weather4cast 2021 Challenge IEEE Big Data Cup Stage</a> by the team "antfugue". The model code can be found in <a href="https://github.com/jleinonen/weather4cast-bigdata">https://github.com/jleinonen/weather4cast-bigdata</a> along with instructions on where to extract the weights.</p>
REMODEL. WP5. Cable Manipulation Planning, Execution and Interactive Perception. T5-2. Cable grasping. Data related to a paper published in IEEE Access 2021
<p>The datasets contain images for the training and testing of algorithms presented in the publication:</p> <p>Cirillo, P., Laudante, G., Pirozzi, S. “Vision-Based Robotic Solution for Wire Insertion with an Assigned Label Orientation” (2021) IEEE Access, 9, art. no. 9490630, pp. 102278-102289. DOI: 10.1109/ACCESS.2021.3098472</p>
The P2P-IEEE 14 bus system data set
<p>This data set models the IEEE 14-bus system for studies on P2P electricity markets, including real data of consumption, solar and wind power from Australia. This data set is characterized by 30 minutes time-step over one year, i.e. from July 2012 to June 2013.</p> <p>The transmission system comprises 14 buses and 20 lines, and its characteristics are based on [1]. The original number of generators was increased to 8 generators, i.e. 1 coal-based generator, 2 gas-based generators, 3 wind turbines and 2 PV plants. The data set uses the original number of 11 loads.</p> <p>The bus 1 represents the upstream connection to the main grid, where the generator assumes an infinite power. The market price from the Australian Energy Market Operator is used in this generator. It is assumed the same period from July 2012 to June 2013 [4]. This data set supposes a tariff of 10$/MWh for using the main grid. The energy imported and exported in bus 1 has to account this extra cost. Thus, the exportation price is equal to the market price minus this grid tariff. On the other hand, the importation price is equal to the market price plus this grid tariff.</p> <p>The wind production has been based on the data set from [2]. The time resolution has been converted from 5 minutes to 30 minutes. The authors would like to acknowledge that the data set in [2] was processed by Stefanos Delikaraoglou and Jethro Dowell. The solar production and load consumption are taken from [3]. The load consumption is split into fixed and flexible consumption per time-step. Since there is no access to the total capacity of the flexible consumption, we split the daily flexible consumption over each time-step. In this way, the maximum consumption is equal to the fixed consumption plus twice this flexible consumption per time-step. The minimum consumption is equal to the fixed consumption in each time-step.</p> <p>The wind, solar and load data sets have been normalized, i.e. values relative to rated power. Then, these normalized sequences were multiplied by the capacity of each element. The data is intended for use in studies related to consumer-centric electricity markets, e.g.:</p> <ul> <li>Validate new market designs or business models;</li> <li>Assess the impact of new grid operation strategies;</li> <li>Test the effect of strategic behavior by producers or consumers.</li> </ul>
IEEE ISTAS'13 Symposium - Investigating Transparency
<p>In the leadup to the 2013 IEEE International Symposium on Technology and Society (ISTAS): Social Implications of Wearable Computing and Augmediated Reality in Everyday Life which had a theme of 'smartworld' the concept of identity awareness of research data, principally tracking research data and attributing digital object identifiers was a hot topic. Alexander Hayes in this video engages and explores with a range of interested researchers in how to make 'real' this concept, calling on these participants in a live streamed event to respond given the social and ethical implications or 'long tail' effect of these technologies. This livestream session was originally published at https://youtu.be/3AXjxIeSUZI</p>
Bug Injector Benchmarks for IEEE SCAM 2019
<p>We present the benchmark data-set accompanying our paper "Automated Customized Bug-Benchmark Generation", published in the 19th IEEE International Working Conference on Source Code Analysis and Manipulation. </p>
REMODEL. WP4. Vision-Based Perception. T4-2. Dynamic environment reconstruction. Data related to a paper published on IEEE Access (2022)
<p>Dataset with evaluation results of the paper "Point Cloud Registration With Object-Centric Alignment"; DOI: 10.1109/access.2022.3191352</p>
Graphs for indoor building scenarios for IEEE 802.11 Networks
<p>Graph files and the corresponding EPS figures for the IEEE 802.11 indoor building scenarios used in the experiments for the following publications:</p> <p>* Tejedor-Romero, M., Gimenez-Guzman, J. M., Cruz-Piris, L., Herranz-Oliveros, D., & Marsa-Maestre, I. (2024). Optimal channel assignment on dense Wi-Fi networks using Thermodynamic Threshold Accepting. <em>Engineering Science and Technology, an International Journal</em>, <em>57</em>, 101797, https://doi.org/10.1016/j.jestch.2024.101797</p> <p>* J.M. Gimenez-Guzman, I. Marsa-Maestre, L. Cruz-Piris, D. Orden, M. Tejedor-Romero, "IEEE 802.11 graph models", Alexandria Engineering Journal, https://doi.org/10.1016/j.aej.2022.12.016</p>
IEEE 802.15.4 TSCH dataset for phase-based distance estimation
<p><strong>Introduction</strong></p> <p>This data set contains two collections of phase angle measurements created in two indoor and one outdoor environment that can be used for phase-based distance estimates. The measurements include phase samples created on two different frequency sets:</p> <ul> <li> <strong>TSCH standard frequencies</strong>: measurements are performed on default 16 channel frequencies {2405.0, 2410.0, 2415.0, 2420.0, 2425.0, 2430.0, 2435.0, 2440.0, 2445.0, 2450.0, 2455.0, 2460.0, 2465.0, 2470.0, 2474.0, 2480.0}MHz.</li> <li> <strong>Golomb ruler frequencies</strong>: the measurements are performed on 15 custom selected frequencies according to the Golomb ruler technique {2400.5, 2406.0, 2407.5, 2408.0, 2412.5, 2423.0, 2431.0, 2442.5, 2452.0, 2460.5, 2463.0, 2466.5, 2476.5, 2479.5, 2480.5}MHz.</li> </ul> <p><br> <strong>Measurement setup</strong></p> <p>Measurements were performed using AT86RF233 transceivers connected to the in-house <a href="https://log-a-tec.eu/hw-vesna.html">VESNA</a> platform. Two nodes were placed on a stand 1.6 m above the ground in three separate environments:</p> <ul> <li>in a 5x5m square office with no furniture</li> <li>in an indoor hallway with dimensions of 4x40m</li> <li>in a park without any nearby obstacles</li> </ul> <p>The actual distance between nodes was measured with a laser ranger with an accuracy of ±1.5 mm. There was no obstacle between the devices. Indoors, 17 WiFi access points were in operation during the measurement campaign.</p> <p><br> <strong>Phase measurement process</strong></p> <p>The devices involved first establish an IEEE 802.15.4 TSCH network. In it, they measure the phase difference on pre-selected frequencies. The phase measurement has been seamlessly integrated into a communication so that the devices obtain phase measurement with every packet sent.</p> <p><em>Why two collections?</em></p> <p>The set labelled "TSCH standard channels" contains phase measurements created at frequencies defined in the IEEE.802.15.4 standard for the 2.4 GHz band. The frequency step (<span class="math-tex">\(\Delta freq = freq_{i+1} - freq_{i}\)</span>) between two phase samples is equal to 5MHz, which results in a maximum distinguishable range of 30m for the distance estimation.</p> <p>To increase the range up to 300m, the frequency step must be reduced to 0.5 MHz. This requires 160 phase samples in the 2.4 GHz band used with a bandwidth of 80 MHz. However, measuring 160 phase samples on 160 frequencies would take a lot of time and therefore interfere with TSCH communications. One way to shorten the procedure is to use the Golomb ruler technique. This allows a large set of phase differences to be created from a small number of measured phases. This method was used in the creation of the set named "Golomb ruler frequencies". The data set also contains a Python example script that expands the set of 15 measured frequencies to a set of 160 samples.</p> <p><br> <strong>Folder structure</strong></p> <p>Each record collection is stored in a corresponding folder. Each folder contains .json files representing different environments. In addition to the data sets, the folders also contain figures and a sample Python script. The measurements are stored in JSON format. Each measured distance contains the number of measurements and the actual data. With each packet sent (identified by its Absolute Slot Number (ASN)), the phase difference between the devices is measured. The phase value is stored as an 8-bit value representing the range from 0 to 2 pi.</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.