> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/expert-center/id/vehicle-telematics-technology/vehicle-sensors/wireless-telematics-sensors.md).
# Sensor telematika nirkabel
Sensor BLE dan UHF mengirimkan TPMS, suhu, dan data lingkungan ke perangkat GPS menggunakan protokol GATT/ATT untuk pemantauan armada nirkabel.
Teknologi nirkabel memungkinkan transmisi nilai dari berbagai sensor ke unit pelacakan GPS tanpa kabel. Ada 2 jenis teknologi nirkabel yang menggunakan frekuensinya sendiri:
* Bluetooth Energi Rendah – 2,4 GHz
* Frekuensi ultra tinggi – 315/433 MHz
## Apa itu BLE
Bluetooth Energi Rendah (BLE) adalah teknologi komunikasi nirkabel berdaya rendah yang dapat digunakan dalam jarak pendek untuk [memungkinkan perangkat pintar saling berkomunikasi](https://www.centare.com/blog/what_is_bluetooth_low_energy/). Teknologi BLE diintegrasikan ke dalam Bluetooth 4,0 pada Desember 2009.
Dibandingkan dengan Bluetooth klasik, Bluetooth Energi Rendah menawarkan pengurangan yang signifikan dalam konsumsi daya dan biaya sambil mempertahankan jangkauan yang serupa. Hal ini memungkinkan produsen perangkat menambahkan antarmuka komunikasi berdaya rendah ke solusi yang sudah ada. Teknologi ini juga telah digunakan untuk membuat perangkat berdaya rendah baru, seperti [suar](https://www.navixy.com/blog/teltonika-ble-beacons/), yang dapat beroperasi dengan baterai kecil selama berbulan-bulan atau bahkan bertahun-tahun.
## Cara kerja BLE
Bluetooth Energi Rendah menggunakan banyak protokol untuk mengirimkan data, berinteraksi dengan semua bagian perangkat, dan mengatur kerja semua lapisan. Di bawah ini, kami akan mencantumkan yang paling penting dan menempatkannya dalam hierarki umum.
**Antarmuka pengendali host (HCI)** adalah protokol pertukaran antarlapis atau antarchip BLE yang menyediakan akses ke pengaturan konfigurasi perangkat Bluetooth.
**Protokol kendali tautan logis dan adaptasi (L2CAP)** bertanggung jawab atas pembuatan paket, pemecahan frame, kontrol galat, dan penyusunan paket.
**Protokol pengelola keamanan (SMP) –** melakukan enkripsi paket.
**Profil akses umum (GAP)** menyediakan pertukaran data awal antara perangkat untuk menentukan «siapa yang mana».
Secara terpisah, perlu dicatat protokol GATT dan ATT:
**GATT** adalah akronim dari Generic Attribute Profile, yang mendefinisikan cara data ditransfer antara dua perangkat Bluetooth berdaya rendah menggunakan konsep yang disebut layanan dan karakteristik.
Protokol ini menggunakan protokol data umum yang disebut **protokol atribut (ATT)**, yang digunakan untuk menyimpan layanan, karakteristik, dan data terkait dalam tabel pencarian sederhana menggunakan pengenal 16-bit untuk setiap catatan dalam tabel.
Struktur profil
* Handle atribut – indeks tabel yang sesuai dengan atribut;
* Tipe atribut – UUID yang mendeskripsikan jenisnya;
* Nilai atribut – data itu sendiri;
* Hak akses atribut – bagian dari atribut, izin yang tidak dapat dibaca atau ditulis menggunakan ATT.
Profil GATT berisi layanan. Layanan digunakan untuk memecah data menjadi entitas logis, dan berisi potongan data tertentu yang disebut karakteristik. Satu layanan dapat memiliki satu atau lebih karakteristik, dan setiap layanan dibedakan dari layanan lain melalui ID numerik unik yang disebut UUID, yang dapat berupa 16-bit (untuk layanan BLE yang diadopsi secara resmi) atau 128-bit (untuk layanan kustom).
Hal terpenting yang perlu diingat terkait GATT dan koneksi adalah bahwa koneksi bersifat eksklusif. Maksudnya, periferal BLE hanya dapat terhubung ke satu perangkat pusat (ponsel, perangkat GPS, dll.) pada satu waktu.
Segera setelah periferal terhubung ke perangkat pusat, perangkat tersebut akan berhenti menyiarkan keberadaannya dan perangkat lain tidak lagi dapat melihat atau terhubung dengannya hingga [koneksi yang ada terputus](https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gatt).
Bayangkan bahwa profil adalah rak buku. Setiap rak adalah layanan, sedangkan buku adalah karakteristik. Setiap karakteristik (buku) memiliki atribut (halaman). Beberapa atribut wajib, beberapa tidak.
### Klien dan server
Untuk memahami perbedaan antara server GATT dan klien GATT, bayangkan bahwa Anda memiliki perangkat GPS dan sensor bahan bakar yang merupakan perangkat BLE. Perangkat GPS mendukung peran pusat; sensor mendukung peran periferal (untuk membangun koneksi BLE *Anda memerlukan satu dari masing-masing*—dua perangkat yang hanya mendukung periferal tidak dapat saling berkomunikasi, begitu pula dua perangkat yang hanya mendukung pusat).
Setelah perangkat dan sensor membangun koneksi, keduanya mulai saling mentransfer metadata GATT. Jika sensor ingin melaporkan data sensor ke perangkat GPS, mungkin masuk akal bagi sensor untuk [berperan sebagai server.](https://developer.android.com/guide/topics/connectivity/bluetooth-le)
Klien GATT mengirim permintaan ke server dan menerima respons (serta pembaruan yang diinisiasi server) darinya. Klien GATT tidak mengetahui apa pun sebelumnya tentang atribut server, sehingga terlebih dahulu harus menanyakan keberadaan dan sifat atribut tersebut dengan melakukan penemuan layanan. Setelah penemuan layanan selesai, klien kemudian dapat mulai membaca atribut yang ditemukan di server.
Server GATT menerima permintaan dari klien dan mengirim respons kembali. Server juga mengirim pembaruan yang diinisiasi server ketika dikonfigurasi untuk melakukannya, dan merupakan peran yang bertanggung jawab untuk menyimpan serta menyediakan data kepada klien, yang disusun dalam atribut.
## Nirkabel vs. kabel
Bukan rahasia lagi bahwa saat ini semua teknologi beralih ke komunikasi nirkabel. Di bawah ini kami catat keunggulan utama sensor nirkabel:
* Bebas dari kabel. Dapat dikonfigurasi menggunakan koneksi fisik apa pun.
* Mudah diatur. Mudah diperluas dan dikonfigurasi.
* Fleksibilitas. Koneksi tanpa kabel lebih fleksibel dan mudah beradaptasi.
* Efisiensi biaya. Karena koneksi nirkabel tidak memerlukan kabel, jaringan seperti itu relatif lebih murah.
* Mudah dibawa dan dipindahkan ke tempat lain.
Seperti yang Anda lihat, koneksi nirkabel memiliki banyak keunggulan. Semua hal ini membuat pemasangan dan pengoperasian sensor menjadi lebih mudah dan nyaman.
Pada saat yang sama, perlu dicatat bahwa sensor berkabel memiliki ketahanan terhadap gangguan yang lebih tinggi. Ini berarti bahwa di tempat dengan tingkat gangguan tinggi, sensor ini akan bekerja lebih stabil.
## Sistem pemantauan tekanan ban (TPMS)
Secara terpisah, perlu dipertimbangkan [Sistem pemantauan tekanan ban](https://en.wikipedia.org/wiki/Tire-pressure_monitoring_system) (TPMS). Sebagian besar instalasi TPMS mengirimkan data mereka melalui radio UHF (frekuensi ultra tinggi). Data TPMS biasanya dikirimkan dalam salah satu dari dua rentang frekuensi, yang bergantung pada lokasi geografis TPMS. Sinyal TPMS dikirim pada sekitar 433 MHz di Eropa, dan pada 315 MHz di sebagian besar wilayah lain di dunia.
Sensor TPMS ini disebut sistem “Direct TPMS”. Sistem ini memberikan nilai tekanan ban yang lebih akurat dibandingkan “Indirect TPMS” yang tidak menggunakan sensor tekanan fisik, tetapi mengukur tekanan udara dengan sistem berbasis perangkat lunak yang, melalui evaluasi dan penggabungan sinyal sensor yang ada seperti kecepatan roda, akselerometer, data sistem penggerak, dll., memperkirakan dan memantau tekanan ban tanpa sensor tekanan fisik di roda.
Setiap sensor TPMS harus dipasang di dalam ban. Sensor ini membangun koneksi dengan antena yang terhubung ke penerima. Sistem ini menyediakan pemantauan tekanan ban yang stabil.
## Jenis sensor BLE
Platform Navixy mendukung banyak jenis sensor nirkabel yang digunakan untuk memudahkan pengguna memperoleh data telematika yang aktual dan akurat. Di bawah ini Anda dapat menemukan daftar yang didukung:
* Bahan bakar
* Suhu
* Kelembapan
* Identifikasi Supir
* Sensor magnetik
* Sensor tekanan ban
Sensor juga dapat mengirim parameter tambahan "BLE: Level baterai", yang menunjukkan seberapa besar daya baterai sensor BLE tersisa. Parameter ini sangat berguna untuk memahami sisa masa pakai baterai.
## Cara menggunakan sensor BLE di Navixy
[Membuat sensor BLE](/docs/user/id/guide/devices-and-settings/vehicle-sensors/measurement-sensors.md) tidak berbeda dengan membuat sensor biasa.
1. Konfigurasikan sensor sesuai petunjuk pengguna
2. Pilih sensor yang diperlukan dari daftar. Biasanya sensor BLE memiliki "BLE" pada label, misalnya BLE: Suhu #, BLE: Bahan bakar, dll.
1. Kemudian tentukan pengaturan lain sesuai kebutuhan Anda.
2. Selesai! Sekarang platform akan menampilkan data dari sensor BLE segera setelah data diterima di server.
Jika Anda ingin terus mengikuti pembaruan Navixy, jangan ragu untuk mengikuti kami di [LinkedIn](https://www.linkedin.com/company/navixy/) dan bagikan komentar, pertanyaan, dan ide artikel mendatang Anda.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://navixy.com/docs/expert-center/id/vehicle-telematics-technology/vehicle-sensors/wireless-telematics-sensors.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.