Friday, September 4, 2026

TENTANG LAPAK INI

Multimedia, terdiri dari kata "Multi" dan "Media". Maksud multimedia adalah banyak media. Media yang dimaksud disini adalah khususnya Audio Visual.  

 Seorang engineer yang bekerja di perusahaan Media (bisa media online, media broadcast) akan berhadapan dengan beberapa perangkat teknis. Perangkat itu khususnya terkait dengan produksi Video, Audio, dan sistem pendukungnya. Sistem pendukung yang dimaksud meliputi jaringan telekomunikasi baik fiber optic, maupun Radio, jaringan TCP/IP, maupun sistem untuk delivery Content spt CDN (Content Distribution Network). 

 Berbicara tentang Video, kunci dari prosesing video adalah pada pemahaman tentang MPEG dan JPEG. Blog ini akan in-depth menjelaskan baik secara teoritis maupun prakteknya menggunakan tools freeware yaitu FFMPEG.

 Terkait dengan sistem pendukung multimedia, blog ini juga hadir untuk membahas sistem pendukug tersebut. Sistem pendukung yang dimaksud adalah sistem jaringan telekomunikasi, jaringan TCP/IP, maupun tentang pengamanan content spt teknologi Enkripsi (karena content Digital sekarang juga memerlukan enkripsi untuk menjaga kerahasiaan data). 

 Delivery content saat ini juga melibatkan Jaringan TCP/IP (seperti konsep Layer 2, Konsep Routing, maupun Konsep Jaringan BGP), hal-hal ini akan juga dibahas. Untuk Jaringan prakteknya nanti menggunakan tools freeware GNS3 (disertakan dengan Youtube video tutorialnya).

 Intinya blog ini isinya gado-gado untuk engineers yang bekerja di dunia multimedia.

 Selamat menikmati. 

 (c) Rafdian Rasyid | Apabila blog ini disalin, dikutip, sebagian atau seluruhnya, mohon menyebutkan sumber pengambilannya yaitu dari blog ini. 

INDEX TOPICS

 Topik Video/Audio/Image
1. HTML 5 Video dan HLS
2. Script FFMPEG untuk HLS
3. Encoding dan Parameter Transcoding yang Optimal
4. HTML5 Video Progressive Download
5. FFMPEG Sebagai UDP Streamer
6. FFMPEG Sebagai SRT Streamer
7. DAFTAR COMMAND FFMPEG UNTUK VIDEO EDITING
8. Apa itu Transcoding - How FFMPEG Works?
9. Pengertian -MAP di FFMPEG
10. Menambahkan Watermark di Video
11. Interleave dan Interlace di Video
12. How JPEG Works - Part 1
13. How JPEG Works - Part 2
14. How JEPG Works - Part 3
15. How JEPG Works - Part 4
16. Introduction to MPEG
17. How MPEG Works
18. FFPROBE untuk tools Analisis
19. MPEG Transport Stream
20. Stuffing BIT pada MPEG TS (VBR/CBR)
21. DVB Inspector for MPEG TS Analysis (1)
22. DVB Inspector PCR/DTS/PTS (2)
23. DVB Inspector + FFPROBE Analisis GOP (3)
24. Berapa Bandwidth 4K di Youtube
Topik Web, Security dan CDN
1. Cryptograph Part 1 : MD5
2. Cryptograph Part 2 : Salt
3. Cara Kerja Web SSL
4. Cara Kerja Public Key Infrastructure (RSA)
5. Conditional Access System (CAS)
6. NGINX Reverse Proxy (CDN)
7. Multimedia QoS
8. CORS Error

Topik Jaringan
1. Membongkar Rahasia ISP Anda
2. Berkenalan dengan GNS3 dan Langkah Instalasi
3. Layer 2 sebagai Fondasi Komunikasi dalam LAN
4. Layer 3 Pembentuk Internetworking
5. Bermain-main dengan RIPv2
6. Introduction to BGP
7. Setting Awal Router BGP
8. BGP Tingkat Lanjut Part 1
9. BGP Tingkat Lanjut Part 2
10. BGP Low Level Part 1
11. BGP Low Level Part 2
12. BGP Simetric Swing & Hold Timer
13. Bermain dengan REGEX BGP & Community
14. BGP Community Sebagai Pengganti Prepend

Multicast Lanjutan

 Topik GNS-3 dan VMWare
1. Instalasi GNS3 + VMWARE
2. DHCP NAT & WebTerm
3. Cisco IOSv15
4. Cisco Authentication Local (1)
5. Cisco Authentication TACACS (2)
6. TACACS Access List
7. TACACS How It Works
8. Mikrotik GNS3
9. Mikrotik Q-in-Q
10. Mikrotik Bridge VLAN Tagging
11. Mikrotik Q-in-Q-in-Q-in-Q
12. L2 Service Provider: Q-inQ vs L2TP vs MPLS
13. MPLS over Static Routes
14. dot1q via MPLS (RIPv2)
15. VPLS over MPLS (Martini, Kampella)

Topik Telekomunikasi
1. Rumus Erlang dan Bandwidth VoIP
2. MHz, Mbps Pada Komunikasi Satellite dan Terestrial
3. Introduction to dBm dan dBW
6. SIP 1: Asterisk SIP Trunk
7. SIP 2: SDP Service Description Protocol
8. SIP 3: B2BUA, SIP Proxy
Topik UHF DVB-T2

Topik Artificial Intelligence
1. AI: Expert System

Topik Information System & Management
1. Strategic Alignment of VSAT System in Corporate IT
 
Topik ME
1. Batteray C Rating


 Indeks akan bertambah seiring dengan bertambahnya jumlah artikel.


Posted by at 1 comment:

Pengaruh Ketinggian Tempat Pengukuran DVB-T2

ANALISIS PENGARUH HEIGHT LOSS (Lh) PADA LINK BUDGET DVB-T2

Kajian Berdasarkan Standar ITU-R BT.2254-5

 

1. PENDAHULUAN: KESENJANGAN REFERENSI KETINGGIAN ANTENA

Dalam perencanaan jaringan televisi terestrial digital DVB-T2, perencana frekuensi sering menghadapi kesenjangan antara hasil prediksi peta komputer dan penerimaan riil di lapangan. Secara konvensional, model komputer memprediksi kekuatan sinyal menggunakan ketinggian antena referensi standar sebesar 10 meter di atas permukaan tanah (a.g.l.), yang merepresentasikan antena penerima luar ruangan (rooftop) dengan gain tinggi.

Namun, bagi skenario penerimaan portabel (portable outdoor/indoor) dan bergerak (mobile), di mana pengguna menggunakan antena terintegrasi pada genggaman atau kendaraan mereka, referensi tinggi 10 meter sama sekali tidak representatif. Pada kenyataannya, perangkat penerima tersebut beroperasi pada ketinggian fisik yang jauh lebih rendah, yaitu sekitar 1,5 meter dari permukaan tanah. Kesenjangan ketinggian inilah yang mendasari pentingnya parameter Height Loss (Lh) sebagai faktor koreksi kritis.

2. KOREKSI TINGGI ANTENA DALAM STANDAR ITU-R BT.2254-5

Dokumen standar internasional ITU-R BT.2254-5 Annex 1 Bagian A1.3.4 (Halaman 95-96) merumuskan parameter Height Loss secara ketat untuk menjamin keandalan pemodelan link budget. Di bawah ini disajikan kutipan langsung (verbatim) dari dokumen tersebut, terjemahan resmi, serta pemaknaan teknis komprehensif:

Verbatim (Annex 1.3.4, Page 95):
"For portable (Classes A, B, H-A and H-B) and mobile reception (Classes H-C and H-D), the antenna height of 10 m above ground level, generally used for planning purposes, is not representative and a correction factor needs to be introduced based on a receiving antenna near ground floor level. For this reason a receiving antenna height of 1.5 m above ground level (outdoor) or above floor level (indoor) has been assumed."

Terjemahan:
"Untuk penerimaan portabel (Kelas A, B, H-A, dan H-B) dan bergerak (Kelas H-C dan H-D), ketinggian antena 10 m di atas permukaan tanah, yang umumnya digunakan untuk tujuan perencanaan, tidaklah representatif dan faktor koreksi perlu diperkenalkan berdasarkan antena penerima yang berada di dekat permukaan tanah. Untuk alasan ini, ketinggian antena penerima sebesar 1,5 m di atas permukaan tanah (luar ruangan) atau di atas permukaan lantai (dalam ruangan) telah diasumsikan."

Pemaknaan Teknis: Pernyataan ini menegaskan bahwa penggunaan standar tinggi 10 meter untuk penerimaan portabel akan menghasilkan estimasi kekuatan sinyal yang terlampau optimis (palsu). Oleh karena itu, ITU menetapkan ketinggian referensi fisik yang realistis sebesar 1,5 meter untuk skenario portable/mobile demi menjaga keandalan kalkulasi.

Verbatim (Annex 1.3.4, Page 95):
"The propagation prediction method of Recommendation ITU-R P.1546 uses a receiving height that corresponds to the height of the surrounding clutter (buildings etc.). To correct the predicted values for a receiving height of 1.5 m above ground level a factor called ‘height loss’ has been introduced."

Terjemahan:
"Metode prediksi propagasi dari Rekomendasi ITU-R P.1546 menggunakan ketinggian penerimaan yang sesuai dengan ketinggian halangan di sekitarnya (bangunan, dll.). Untuk mengoreksi nilai yang diprediksi bagi ketinggian penerimaan 1,5 m di atas permukaan tanah, sebuah faktor yang disebut 'height loss' telah diperkenalkan."

Pemaknaan Teknis: Perangkat lunak simulasi propagasi standar (seperti ITU-R P.1546) menghitung transmisi sinyal pada ketinggian puncak rintangan sekitar (clutter height), seperti atap gedung atau pohon. Karena gelombang diprediksi berada di ketinggian atap, maka sinyal tersebut akan mengalami pelemahan masif akibat bayangan dan rintangan fisik saat turun ke bawah (1,5 meter dari tanah) di mana pengguna berada. Redaman turunnya sinyal ini didefinisikan sebagai Height Loss.

Verbatim (Annex 1.3.4, Page 96):
"The height loss may also depend on the distance between the transmitter and the receiver, which makes it variable with the size of the coverage area. Therefore, in this document the Figures of minimum median equivalent field strength for portable (Classes A, B, H-A and H-B) and mobile reception (Classes H-C and H-D) are calculated at 1.5 m a.g.l. The values of height loss given in this section could be used to derive the minimum median equivalent field strength corresponding to the height of the surrounding clutter (buildings etc.)."

Terjemahan:
"Height loss juga dapat bergantung pada jarak antara pemancar dan penerima, yang membuatnya bervariasi sesuai dengan ukuran area cakupan. Oleh karena itu, dalam dokumen ini, angka-angka kuat medan ekuivalen median minimum untuk penerimaan portabel (Kelas A, B, H-A, dan H-B) dihitung pada ketinggian 1,5 m di atas permukaan tanah. Nilai height loss yang diberikan dalam bagian ini dapat digunakan untuk menurunkan kuat medan ekuivalen median minimum yang sesuai dengan ketinggian halangan di sekitarnya (bangunan, dll.)."

Pemaknaan Teknis: ITU memperjelas bahwa nilai kuat medan target median (Emed) yang tercantum di dokumen ITU (misal: 60,1 dBµV/m pada Case 2) adalah target riil yang harus diterima alat ukur langsung pada ketinggian 1,5 meter. Namun, jika perencana menggunakan simulasi komputer yang menghitung sinyal di ketinggian clutter (10 meter), maka perencana harus mengonversi target tersebut dengan menambahkan nilai Lh.

3. KUANTIFIKASI HEIGHT LOSS SESUAI LINGKUNGAN CLUTTER

Besarnya nilai Height Loss sangat dipengaruhi oleh kerapatan rintangan (clutter) di sekitar penerima. Tabel di bawah ini menampilkan nilai Lh (dB) resmi dari Table A1.5 (Halaman 96) untuk pita frekuensi UHF (Bands IV/V):

Kelas Lingkungan Clutter Height Loss (Band III - 200 MHz) Height Loss (Bands IV/V - 650 MHz)
Perkotaan (Urban) 19.0 dB 23.5 dB
Sub-perkotaan (Suburban) 12.0 dB 17.0 dB
Pedesaan (Rural) 12.0 dB 16.5 dB

4. JUSTIFIKASI MATEMATIS DAN TEKNIS FORMULA TARGET PETA

Berdasarkan kajian ilmiah di atas, maka formula perencanaan jaringan:

Target di Peta (10m) = Target di Penerima (1,5m) + Height Loss (Lh)

adalah asumsi yang sepenuhnya dapat dipertanggungjawabkan secara ilmiah dan fungsional karena:

  1. Hukum Fisika Difraksi Gelombang: Gelombang UHF merambat secara garis lurus (LOS) di atas atap gedung (10 meter). Ketika merambat turun ke jalan raya (1,5 meter), gelombang mengalami difraksi di tepi-tepi bangunan yang menyebabkan penurunan drastis daya sinyal secara logaritmik.
  2. Mencegah Efek Tebing (Cliff Effect): Jika target pada peta simulasi (10m) di-set sama dengan target di penerima (1,5m) sebesar 60,1 dBµV/m tanpa Lh, maka sinyal riil di lapangan akan jatuh menjadi 36,6 dBµV/m (akibat redaman 23,5 dB). Daya ini berada jauh di bawah sensitivitas minimum tuner STB (Emin = 50,1 dBµV/m), sehingga gambar siaran akan langsung hilang total (cliff-effect). Agar sinyal di genggaman pelanggan tetap terjaga minimal 60,1 dBµV/m, maka pada peta simulasi harus di-set target minimal sebesar 83,6 dBµV/m.

5. ADAPTASI TINGGI ANTENA PENERIMA PADA KONTEKS RIIL INDONESIA

5.1 Konteks Lapangan di Indonesia: Ketinggian Antena 5 Meter

Dalam standar perencanaan frekuensi jaringan DVB-T2 internasional yang dirumuskan oleh dokumen ITU-R BT.2254-5, tinggi antena penerima untuk mode portabel didefinisikan secara kaku pada ketinggian 1.5 meter di atas permukaan tanah (above ground level - a.g.l.). Tinggi ini merepresentasikan perangkat portabel yang diletakkan di atas meja atau dipegang oleh tangan manusia.

Namun, kondisi riil di lapangan Indonesia menunjukkan karakteristik yang sangat berbeda. Sebagian besar masyarakat urban dan suburban di Indonesia tidak menggunakan antena portabel dalam ruangan (indoor), melainkan memasang antena luar ruangan (outdoor) ukuran medium yang ditopang oleh tiang besi mandiri atau bambu sederhana di area pekarangan atau dinding luar rumah. Ketinggian pemasangan antena jenis ini umumnya berkisar pada rata-rata 5 meter dari permukaan tanah.

Ketinggian 5 meter ini berada di posisi pertengahan: jauh lebih tinggi dari standar portabel ITU (1.5 m) namun belum mencapai tinggi referensi bebas halangan (rooftop standard Eropa) setinggi 10 meter. Oleh karena itu, menerapkan nilai Height Loss ($L_h$) standar 1.5 meter sebesar 23.5 dB untuk area urban secara langsung akan menghasilkan estimasi redaman yang terlalu konservatif (terlalu besar), yang berujung pada pemborosan daya pancar transmiter (ERP) saat merancang peta cakupan siaran digital.

5.2 Landasan Teoretis dan Formula Interpolasi Logaritmik

Berdasarkan panduan teknis pada Annex 1.3.4, nilai-nilai Height Loss standar yang diterbitkan dalam laporan ITU didasarkan pada algoritma prediksi propagasi Recommendation ITU-R P.1546. Di dalam model propagasi gelombang elektromagnetik tersebut, pelemahan kuat medan akibat halangan lingkungan (clutter) di bawah ketinggian referensi 10 meter tidak menurun secara linier, melainkan mengikuti kurva logaritmik.

Mengapa menggunakan pendekatan logaritmik dan bukan linier?

Secara fisika, pelemahan daya gelombang radio pita UHF tidak terjadi secara konstan (garis lurus). Ketika sinyal turun dari ruang bebas hambatan dan masuk ke area bayangan rintangan (seperti di sela-sela atap rumah atau pohon), gelombang mengalami difraksi. Penurunan kekuatan sinyal akibat difraksi ini membesar secara eksponensial. Selain itu, dalam ilmu telekomunikasi, redaman (loss) selalu dihitung menggunakan satuan desibel (dB) yang pada dasarnya adalah fungsi matematika logaritma (basis 10). Jika menggunakan metode linier biasa, perhitungannya tidak akan mencerminkan tingkat redaman yang sebenarnya terjadi di dunia nyata.

Oleh karena itu, untuk mengakomodasi variasi tinggi antena penerima di lapangan (khususnya untuk tinggi $h$ antara 1.5 meter hingga 10 meter) secara lebih realistis, kita dapat menggunakan formula interpolasi logaritmik berikut:

$$L_h(h) = L_h(1.5\text{m}) \times \frac{\log_{10}\left(\frac{10}{h}\right)}{\log_{10}\left(\frac{10}{1.5}\right)}$$

Di mana:

  • $h$ adalah ketinggian antena penerima aktual yang ingin dihitung di lapangan (dalam meter).
  • $L_h(h)$ adalah nilai Height Loss pada ketinggian $h$ (dalam dB).
  • $L_h(1.5\text{m})$ adalah nilai Height Loss referensi pada ketinggian 1.5 meter sesuai standar Tabel A1.5 ITU-R (yaitu: Urban = 23.5 dB, Suburban = 17 dB, Rural = 16.5 dB).
  • $10$ adalah tinggi referensi standar perencanaan bebas hambatan ($L_h = 0\text{ dB}$).
  • $\log_{10}$ adalah fungsi logaritma basis 10 yang merepresentasikan karakteristik atenuasi medan elektromagnetik pada zona clutter sesuai standar ITU-R P.1546.

Melalui formula ini, rasio logaritma $\frac{\log_{10}(10/h)}{\log_{10}(10/1.5)}$ bertindak sebagai skala pengali non-linier. Sebagai contoh, untuk menghitung redaman pada ketinggian 5 meter yang umum digunakan di Indonesia, faktor pengali logaritmik yang diperoleh adalah:

$$\text{Faktor Pengali} = \frac{\log_{10}(10/5)}{\log_{10}(10/1.5)} = \frac{\log_{10}(2)}{\log_{10}(6.6667)} \approx \frac{0.30103}{0.82391} \approx \mathbf{0.3653}$$

Dengan mengalikan faktor 0.3653 ini ke nilai Height Loss dasar di masing-masing area, kita mendapatkan estimasi redaman yang jauh lebih akurat untuk tinggi 5 meter di Indonesia, yaitu 8.59 dB untuk area Urban (turun drastis dari asumsi awal 23.5 dB), 6.21 dB untuk Suburban, dan 6.03 dB untuk Rural.

5.3 Tabel Perbandingan Nilai Height Loss ($L_h$) Berdasarkan Ketinggian

Berikut adalah tabel komparasi nilai Height Loss ($L_h$) dalam satuan dB untuk pita frekuensi UHF (Bands IV/V, 650 MHz) dari ketinggian standar referensi 10 meter hingga ketinggian portabel 1.5 meter yang dihitung secara presisi menggunakan formula interpolasi logaritmik ITU-R P.1546:

Ketinggian Antena ($h$) Faktor Pengali Logaritmik Area Perkotaan (Urban) Area Pinggiran (Suburban) Area Pedesaan (Rural)
10.0 Meter (Referensi) 0.0000 0.00 dB 0.00 dB 0.00 dB
9.0 Meter 0.0555 1.31 dB 0.94 dB 0.92 dB
8.0 Meter 0.1176 2.76 dB 2.00 dB 1.94 dB
7.0 Meter 0.1880 4.42 dB 3.20 dB 3.10 dB
6.0 Meter 0.2693 6.33 dB 4.58 dB 4.44 dB
5.0 Meter (Std. Indonesia) 0.3653 8.59 dB 6.21 dB 6.03 dB
4.0 Meter 0.4829 11.35 dB 8.21 dB 7.97 dB
3.0 Meter 0.6343 14.91 dB 10.79 dB 10.47 dB
2.0 Meter 0.8484 19.94 dB 14.42 dB 14.00 dB
1.5 Meter (Std. Portabel ITU) 1.0000 23.50 dB 17.00 dB 16.50 dB

Catatan: Pembulatan nilai akhir desimal pada tabel di atas disesuaikan dengan standar akurasi pemodelan link budget digital selaras dengan kalkulator spreadsheet perencanaan frekuensi lapangan.

BAB VI: KESIMPULAN

  • Height Loss ($L_h$) Bukan Hambatan Statis: Faktor kehilangan daya akibat ketinggian antena ($L_h$) adalah variabel dinamis non-linier yang dipengaruhi secara ketat oleh geometri ketinggian terhadap puncak halangan lokal (clutter height). Mengabaikan sifat logaritmik ini akan membuat estimasi perencanaan menjadi tidak akurat.
  • Validitas Ilmiah Rumus Konstanta: Pendekatan formula interpolasi logaritmik berbasis ITU-R P.1546 terbukti secara matematis sangat solid dan dapat dipertanggungjawabkan sepenuhnya secara ilmiah. Rumus ini berhasil memetakan transisi redaman secara halus di bawah zona interferensi pekarangan tanpa memerlukan pengukuran lapangan yang berbiaya mahal untuk setiap variasi meter ketinggian tiang antena.
  • Implikasi Penting bagi Link Budget Indonesia: Penyesuaian ketinggian antena ke rata-rata lokal 5 meter di Indonesia memberikan optimasi perencanaan yang sangat signifikan. Dengan nilai $L_h$ sebesar 8.59 dB (Urban 5m) dibandingkan dengan standar kaku 1.5m sebesar 23.5 dB, perencana jaringan dapat menghemat alokasi daya pancar pemancar sebesar 14.91 dB pada link budget mereka untuk cakupan area yang sama.
  • Menjamin Keandalan dan Mencegah Cliff Effect: Penerapan nilai target di peta simulasi perencanaan ($E_{med\_10m}$) yang disesuaikan secara logaritmik memastikan bahwa sinyal siaran digital yang diterima oleh masyarakat di ketinggian pemasangan riil mereka tidak akan merosot melewati ambang batas tegangan minimum tuner ($U_{min}$). Transparansi kalkulasi parameter fisik ini menjadi kunci utama dalam menghindari fenomena siaran mati mendadak (cliff-effect) yang menjadi musuh utama penonton TV digital di Indonesia.
Posted by at No comments:

Thursday, September 3, 2026

Panduan Link Budget DVB-T2

Posted by at No comments:

Monday, August 31, 2026

Aplikasi Sun Outage

Jika Anda mengelola jaringan satelit, Anda pasti akan berhadapan dengan fenomena Sun Outage—momen ketika posisi Matahari berada tepat di belakang satelit geostasioner, sehingga radiasi termalnya menenggelamkan sinyal dari satelit ke antena stasiun bumi Anda.

Aplikasi Sun Outage https://sun-outage-calc.vercel.app/

Mari kita pelajari logika algoritma di baliknya!

1. Menemukan Posisi Satelit (Toposentrik 3D)

Sebelum mencari Matahari, antena harus tahu di mana satelit berada. Di dalam math_engine.js, fungsi calculatePointing bertugas untuk ini.

  • Fungsi ini tidak menggunakan rumus bumi bulat sempurna, melainkan memperhitungkan faktor kegepengan bumi (Earth Flattening Factor = 1 / 298.26).
  • Dengan trigonometri 3D, koordinat stasiun bumi dan satelit dikonversi menjadi sudut Azimuth dan Elevation yang presisi.

2. Melacak Pergerakan Matahari (Algoritma NOAA)

Ini adalah bagian paling kompleks. Fungsi getSunPosition adalah rumus raksasa yang mengadaptasi algoritma Julian Century dari NOAA.

  • Mesin mengonversi waktu UTC menjadi fraksi abad Julian (Julian Century).
  • Dari sini, kita menghitung anomali orbit bumi, deklinasi matahari, dan persamaan waktu (Equation of Time).
  • Hasil akhirnya adalah posisi Matahari saat itu juga, yang diproyeksikan ke dalam sudut Azimuth dan Elevasi relatif terhadap pengamat di stasiun bumi.

3. Menghitung Toleransi & Separasi Sudut

Kapan gangguan sinyal benar-benar terjadi? Tergantung pada seberapa besar antena Anda dan frekuensi yang digunakan.

  • Toleransi Antena: Fungsi getOutageAngle menentukan lebar sorotan (beamwidth) antena. Antena C-Band (~3.95 GHz) dan Ku-Band (~11.95 GHz) memiliki ambang batas sudut gangguan yang berbeda berdasarkan ukuran diameternya.
  • Separasi Sudut: Fungsi getAngularSeparation menggunakan trigonometri bola (Spherical Trigonometry) untuk mengukur jarak sudut antara titik arah antena (ke satelit) dan posisi Matahari saat itu. Jika jarak sudut ini lebih kecil atau sama dengan toleransi antena, maka outage terjadi!

4. Algoritma "Smart Scanning" (Rahasia Kecepatan)

Jika kita menghitung pergerakan matahari setiap detik dalam sebulan penuh, browser Anda akan crash karena kelebihan beban komputasi. Di sinilah fungsi calculateOutageTable bersinar dengan strategi Pemindaian Kasar ke Halus (Coarse to Fine):

  • Pindai Kasar: Mesin melompat setiap 30 detik untuk mencari kapan Matahari mendekati area toleransi antena.
  • Pindai Halus: Begitu Matahari terdeteksi masuk (atau keluar) dari zona antena, mesin mundur 30 detik, lalu memindai pelan-pelan per 1 detik untuk menemukan waktu (pintu masuk/keluar) yang paling presisi.

5. Studi Kasus: Simulasi Perhitungan Stasiun Bumi Jakarta

Agar tidak hanya membayangkan teori, mari kita simulasikan bagaimana mesin memproses perhitungan di lapangan. Bayangkan Anda ditugaskan menjaga link VSAT di Jakarta yang mengarah ke satelit Telkom-4.

Parameter Input:

  • Lokasi: JAKARTA (Lat: -6.17, Lon: -106.8)
  • Satelit: Telkom-4 / Merah Putih (108.0E)
  • Antena: 1.8 Meter
  • Frekuensi: C-Band
  • Tahun Prediksi: 2026

Langkah 1: Mengunci Target (Pointing)

Mesin mengkalkulasi koordinat stasiun bumi terhadap garis bujur satelit (108.0E). Hasil dari fungsi calculatePointing mencetak angka:

  • Azimuth: 11.039°
  • Elevation: 82.605°

Ini adalah titik diam antena Anda.

Langkah 2: Menghitung Zona Bahaya (3dB Beamwidth & Geometric Outage Threshold)

Mesin kemudian menjalankan fungsi getOutageAngle untuk menghitung metrik krusial: 3dB Beamwidth dan ambang batas gangguan geometrisnya.

Bayangkan antena parabola Anda memancarkan zona tangkapan berbentuk kerucut. Lebar kerucut inilah yang direpresentasikan oleh Beamwidth.

  • Beamwidth Coefficient: Lebar sorotan sinyal dipengaruhi oleh bagaimana energi didistribusikan pada reflektor (illumination taper). Aplikasi ini menggunakan pendekatan koefisien empiris 73.3 yang menjadi standar umum industri. Saat dimasukkan ke dalam persamaan panjang gelombang, koefisien ini disederhanakan menjadi angka pembilang 11 untuk menghitung jari-jari (setengah bukaan) sorotan sinyal antena.
  • Rumus Radius Beam: Dihitung dengan formula 11 / (Frekuensi × Diameter Antena).
  • Jari-jari Matahari: Dilihat dari bumi, matahari memiliki diameter visual rata-rata sekitar 0.53°. Untuk perhitungan gelombang radio, jari-jari matahari (setengah diameter) ditetapkan pada angka 0.267°.

Lalu, kapan gangguan terjadi? Sun outage sejatinya disebabkan oleh radiasi termal matahari yang masuk ke dalam sorotan antena. Radiasi ini mendongkrak suhu noise ($T_{sys}$) sistem secara drastis, sehingga kualitas sinyal ($C/N$) merosot tajam.

Karena menghitung fluktuasi noise secara persis membutuhkan data perangkat keras yang spesifik, para engineer menggunakan model geometri untuk memprediksi kapan gangguan tersebut mulai berisiko menenggelamkan link margin:

Geometric Threshold = Jari-jari Beamwidth + Jari-jari Matahari (0.267°)

Mari kita masukkan angkanya! Menggunakan frekuensi C-Band rata-rata (3.95 GHz) dan antena 1.8 meter, mesin mendapatkan radius beam sebesar 1.547°. Ditambah jari-jari matahari 0.267°, maka didapatkan Geometric Threshold sebesar 1.814°.

Artinya, jika jarak sudut antara titik pusat Matahari dan arah boresight antena menyempit hingga melewati ambang batas 1.814° ini, VSAT Anda diperkirakan telah memasuki periode sun outage dan sangat berisiko mengalami gangguan koneksi!

Langkah 3: Pemindaian (Scanning)

Mesin memindai pergerakan Matahari di bulan Maret dan September 2026. Sebagai contoh, pada tanggal 23 Maret 2026, algoritma pemindaian mendeteksi momen kritis:

  • Pada pukul 04:46:34 GMT, jarak Matahari ke antena menyentuh batas 1.797°. Status: Outage dimulai!
  • Matahari terus bergeser melewati titik buta antena.
  • Pada pukul 05:00:55 GMT, jarak Matahari kembali menjauh lebih dari 1.797°. Status: Outage selesai!

Mesin mencatat durasi gangguan hari itu berlangsung selama 14 menit 21 detik. Siklus ini diulangi untuk hari-hari sebelum dan sesudahnya hingga mesin menyusun laporan final.

Hasil Akhir (Predicted Outage Report)

Berikut adalah output murni yang dihasilkan oleh aplikasi setelah merangkum seluruh hasil pemindaian matematis di atas:

PREDICTED OUTAGE REPORT
========================================================================
Ground Station : JAKARTA (Lat: -6.17, Lon: -106.8)
Satellite      : Telkom-4 / Merah Putih (108.0E)
Antenna Point  : Azimuth 11.039°, Elevation 82.605°
3dB Beamwidth  : 3.094°, Outage threshold: 1.814°
Parameters     : 1.8m C-Band (3.95 GHz), k-Factor: 73.3, Year: 2026
========================================================================

[ MARCH EQUINOX ]
Date             | GMT      | GMT      | Duration | WIB      | WIB
dd/MMM/yyyy      | Start    | End      | mm:ss    | Start    | End
-----------------|----------|----------|----------|----------|----------
19/Mar/2026      | 04:52:02 | 04:57:49 | 05:47    | 11:52:02 | 11:57:49
20/Mar/2026      | 04:49:29 | 04:59:48 | 10:19    | 11:49:29 | 11:59:48
21/Mar/2026      | 04:48:01 | 05:00:39 | 12:38    | 11:48:01 | 12:00:39
22/Mar/2026      | 04:47:06 | 05:00:59 | 13:53    | 11:47:06 | 12:00:59
23/Mar/2026      | 04:46:34 | 05:00:55 | 14:21    | 11:46:34 | 12:00:55
24/Mar/2026      | 04:46:23 | 05:00:30 | 14:07    | 11:46:23 | 12:00:30
25/Mar/2026      | 04:46:34 | 04:59:43 | 13:09    | 11:46:34 | 11:59:43
26/Mar/2026      | 04:47:13 | 04:58:28 | 11:15    | 11:47:13 | 11:58:28
27/Mar/2026      | 04:48:38 | 04:56:27 | 07:49    | 11:48:38 | 11:56:27

[ SEPTEMBER EQUINOX ]
Date             | GMT      | GMT      | Duration | WIB      | WIB
dd/MMM/yyyy      | Start    | End      | mm:ss    | Start    | End
-----------------|----------|----------|----------|----------|----------
16/Sep/2026      | 04:38:29 | 04:45:43 | 07:14    | 11:38:29 | 11:45:43
17/Sep/2026      | 04:36:16 | 04:47:12 | 10:56    | 11:36:16 | 11:47:12
18/Sep/2026      | 04:34:55 | 04:47:51 | 12:56    | 11:34:55 | 11:47:51
19/Sep/2026      | 04:34:01 | 04:48:02 | 14:01    | 11:34:01 | 11:48:02
20/Sep/2026      | 04:33:29 | 04:47:51 | 14:22    | 11:33:29 | 11:47:51
21/Sep/2026      | 04:33:18 | 04:47:20 | 14:02    | 11:33:18 | 11:47:20
22/Sep/2026      | 04:33:29 | 04:46:26 | 12:57    | 11:33:29 | 11:46:26
23/Sep/2026      | 04:34:08 | 04:45:05 | 10:57    | 11:34:08 | 11:45:05
24/Sep/2026      | 04:35:38 | 04:42:53 | 07:15    | 11:35:38 | 11:42:53

6. Di Balik Layar: Rumus Sin Cos dan Logika Looping

Bagi Anda yang penasaran melihat langsung bentuk kodenya, mari kita bedah dua fungsi krusial yang membuat aplikasi ini berjalan sangat akurat dan efisien tanpa membuat komputer melambat.

A. Trigonometri Bola (Menghitung Jarak Matahari & Antena)

Anda benar sekali jika menebak ada banyak rumus Sin dan Cos di sini! Karena Bumi dan kubah langit berbentuk bola, kita tidak bisa mengukur jarak antara titik arah antena dan titik posisi matahari menggunakan rumus Pythagoras biasa. Kita harus menggunakan Trigonometri Bola (Spherical Trigonometry).

Di dalam math_engine.js, tugas ini ditangani oleh fungsi getAngularSeparation. Secara matematis, kita menggunakan Spherical Law of Cosines:

cos(θ) = sin(El1) × sin(El2) + cos(El1) × cos(El2) × cos(Az1 - Az2)

Berikut adalah makna dari masing-masing variabel di atas:

  • θ (Theta): Jarak Sudut (Angular Separation) absolut antara titik tengah sorotan antena dan titik pusat Matahari di kubah langit.
  • El1: Sudut Elevasi Antena (tingkat kemiringan/dongakan parabola Anda menuju satelit).
  • El2: Sudut Elevasi Matahari (ketinggian Matahari diukur dari batas ufuk/cakrawala pengamat pada detik tersebut).
  • Az1: Sudut Azimuth Antena (arah derajat kompas ke mana antena parabola Anda menghadap).
  • Az2: Sudut Azimuth Matahari (arah derajat kompas letak Matahari pada detik tersebut).

Singkatnya, karena kita berhadapan dengan objek di langit (3D), kita tidak bisa sekadar mengurang-kurangkan angkanya. Rumus ini menggabungkan perbedaan arah kompas (Azimuth) dan ketinggian (Elevation) untuk mendapatkan satu jarak sudut melengkung yang akurat!

Lalu, Apa Kaitan θ (Theta) dengan Waktu Start dan End Outage?

Ini adalah kunci utama dari seluruh perhitungan kita! Untuk memahami kapan gangguan dimulai dan berakhir, bayangkan antena VSAT Anda memiliki sebuah "zona bahaya" atau area tangkapan berbentuk kerucut (kita sebut saja Sudut Toleransi atau Beamwidth). Besar lingkaran zona bahaya ini sudah kita hitung sebelumnya berdasarkan ukuran antena dan jenis frekuensi.

Nah, nilai θ (Theta) ini tidaklah statis. Ia terus berubah setiap detiknya seiring pergerakan Matahari melintasi langit. Mesin scanner (calculateOutageTable) memantau pergerakan nilai θ ini dengan kronologi sebagai berikut:

  • Menjelang Outage: Matahari di langit perlahan-lahan mendekati posisi satelit. Artinya, jarak sudut atau nilai θ perlahan-lahan mengecil. Sinyal VSAT Anda di titik ini masih aman.
  • Waktu START (Mulai): Tepat pada detik di mana nilai θ lebih kecil atau sama dengan (≤) Sudut Toleransi antena (artinya, piringan Matahari mulai menyentuh tepi "zona bahaya" antena), mesin mencatat detik tersebut sebagai Start UTC. Pada titik ini, radiasi panas Matahari mulai masuk ke LNB, menaikkan noise, dan membuat kualitas sinyal (Eb/No atau SNR) modem Anda merosot tajam.
  • Puncak Outage: Matahari berada persis di belakang satelit. Pada momen ini, nilai θ mencapai angka terkecilnya (mendekati 0°). Interference mencapai titik maksimal dan link VSAT Anda kemungkinan besar putus total (Loss of Lock).
  • Waktu END (Selesai): Matahari terus bergerak menjauhi satelit, sehingga nilai θ perlahan-lahan membesar kembali. Tepat pada detik ketika nilai θ lebih besar (>) dari Sudut Toleransi (piringan Matahari keluar dari "zona bahaya"), mesin mencatat detik tersebut sebagai End UTC. Panas Matahari tak lagi masuk ke antena, noise mereda, dan sinyal VSAT Anda kembali normal!

Singkatnya, math_engine.js bekerja layaknya sensor alarm batas wilayah: "Catat waktu START saat nilai Theta mengecil melewati batas toleransi, dan catat waktu END saat nilai Theta kembali membesar keluar dari batas toleransi tersebut!"

Dan jika kita terjemahkan ke dalam bahasa JavaScript, kodenya akan terlihat rapi seperti ini:

  getAngularSeparation(az1, el1, az2, el2) {
    const el1R = this.toRadians(el1);
    const el2R = this.toRadians(el2);
    const azDiff = this.toRadians(az1 - az2);

    // Rumus Inti Trigonometri Bola
    const cosAngle = Math.sin(el1R) * Math.sin(el2R) + 
                     Math.cos(el1R) * Math.cos(el2R) * Math.cos(azDiff);
                     
    return this.toDegrees(Math.acos(cosAngle));
  }

B. Logika Looping: Coarse to Fine Scanning

Untuk menemukan detik yang presisi kapan outage terjadi, mesin harus melakukan looping (perulangan pencarian waktu). Jika kita mengecek pergerakan matahari satu per satu setiap detik dalam setahun penuh, browser pasti akan hang. Solusinya adalah metode Smart Scanning.

Logikanya sangat elegan dan dibagi menjadi tiga langkah utama:

  1. Pindai Kasar: Mesin melompat setiap 30 detik (s += 30) untuk mencari tahu kapan matahari mulai mendekat ke antena[cite: 3].
  2. Mencari Pintu Masuk: Jika mesin mendeteksi gangguan, ia akan berhenti, mundur 30 detik, lalu memindai pelan-pelan per 1 detik (fineS++) untuk mencari detik pasti kapan sinyal mulai tumbang[cite: 3].
  3. Mencari Pintu Keluar: Hal yang sama dilakukan saat matahari mulai menjauh. Mesin memindai per 1 detik untuk mencari detik pasti kapan sinyal kembali normal, lalu segera melompat (break) memindai hari berikutnya[cite: 3].

Berikut adalah potongan logika utama dari fungsi calculateOutageTable tersebut:

  // 1. Pindai KASAR: Lompat setiap 30 detik (Sangat Cepat!)
  for (let s = 0; s < 86400; s += 30) {
    // ... Hitung posisi matahari dan cek status outage
    
    // 2. Jika status berubah menjadi MASUK (Mencari Pintu Masuk)
    if (isOutage && !currentlyOutage) {
      // Pindai HALUS: Mundur 30 detik, maju pelan-pelan per 1 detik
      for (let fineS = s - 30; fineS <= s; fineS++) {
         // Temukan detik pasti masuknya matahari -> startUTC
      }
    }
    
    // 3. Jika status berubah menjadi KELUAR (Mencari Pintu Keluar)
    else if (!isOutage && currentlyOutage) {
      // Pindai HALUS: Mundur 30 detik, maju pelan-pelan per 1 detik
      for (let fineS = s - 30; fineS <= s; fineS++) {
         // Temukan detik pasti keluarnya matahari -> endUTC
      }
      break; // Waktu keluar sudah ketemu, langsung lompat ke hari besok!
    }
  }

Dengan memahami logika algoritma di baliknya, laporan di atas bukan lagi sekadar tabel waktu, melainkan hasil perhitungan pergerakan tata surya kita.

Posted by at No comments:
Subscribe to: Posts (Atom)