Saturday, October 31, 2026

Kisah Aku Membangunkan Aplikasi Tempahan Dewan dan Bilik Mesyuarat

 

Bermula dengan urusan harian di sekolah

Aku nak kongsikan cerita di sebalik aplikasi tempahan dewan dan bilik mesyuarat SMK Bandar Putra. Idea untuk membangunkannya datang daripada keperluan mengurus kemudahan sekolah dengan lebih tersusun. Aku mahu urusan tempahan lebih mudah dirujuk dan sesuai dengan cara kerja warga sekolah.

Dewan dan bilik mesyuarat digunakan untuk pelbagai aktiviti. Ada mesyuarat, taklimat, program murid dan urusan sekolah yang lain. Apabila kemudahan dikongsi ramai, maklumat penggunaannya perlu jelas supaya perancangan program dapat dibuat dengan lebih baik.

Daripada keperluan itu, aku mula merancang sebuah aplikasi yang memberi tumpuan kepada tempahan dua kemudahan ini. Aku fikirkan tujuan pengguna membukanya, maklumat yang perlu mereka faham dan bagaimana urusan itu patut disusun. Aku mahu hasilnya dekat dengan keperluan sebenar di sekolah.

Aku tentukan apa yang aplikasi ini perlu buat

Bagi aku, perkara pertama ialah menentukan masalah yang hendak diselesaikan. Sebelum memikirkan kod, aku perlu jelas tentang tujuan aplikasi dan bagaimana ia boleh membantu pengguna. Keperluan itulah yang menjadi panduan sepanjang pembangunan projek ini.

Aku menentukan hala tuju aplikasi, memberi arahan tentang hasil yang diperlukan dan menyemak sama ada hasilnya menepati kehendak aku. Apabila ada bahagian yang kurang sesuai, aku beri maklum balas dan tentukan perubahan yang perlu dibuat.

Dalam urusan penulisan kod, aku menggunakan bantuan ChatGPT. Aku terangkan keperluan yang telah aku fikirkan, kemudian mendapatkan bantuan untuk menterjemahkannya kepada kod. Dengan cara itu, aku boleh meneruskan pembangunan sambil memberi perhatian kepada susunan aplikasi dan kegunaannya di sekolah.


Bantuan koding dalam proses pembangunan

Peranan ChatGPT dalam projek ini tertumpu pada bantuan koding. Berdasarkan arahan dan keperluan yang aku berikan, ia membantu menyediakan serta mengubah kod. Aku kemudian menyemak hasil perubahan itu dari sudut penggunaan dan kesesuaiannya dengan aplikasi yang aku rancang.

Prosesnya melibatkan beberapa pusingan semakan. Aku melihat hasil yang dibina, mengenal pasti bahagian yang perlu diperbaiki dan memberi arahan seterusnya. Ada perkara yang lebih mudah dinilai apabila sudah muncul pada skrin berbanding ketika masih dalam bentuk idea.

Bantuan ini memudahkan aku melaksanakan bahagian teknikal. Namun, keputusan tentang apa yang perlu dipaparkan, perkara yang patut diutamakan dan perubahan yang sesuai tetap berpandukan keperluan yang aku tetapkan untuk sekolah.

Semak dari sudut orang yang akan menggunakannya

Apabila menilai aplikasi, aku cuba melihatnya dari sudut guru yang hendak membuat urusan tempahan. Mereka perlu memahami maklumat dan tindakan yang perlu dibuat dengan mudah. Sebab itu, aku memberi perhatian kepada kejelasan susunan dan arahan pada paparan.

Bagi aku, banyak fungsi belum tentu menjadikan aplikasi lebih membantu. Aku lebih berminat pada fungsi yang ada tujuan jelas. Kalau sesuatu bahagian menyukarkan pengguna memahami urusan tempahan, bahagian itu perlu dinilai dan dikemaskan.

Dalam proses ini, aku belajar memberikan arahan perubahan yang lebih khusus. Aku perlu jelaskan bahagian yang kurang sesuai, hasil yang aku mahu dan sebab perubahan itu diperlukan. Arahan yang jelas membantu kerja pembaikan kod berjalan dengan lebih terarah.

Mengenali bahagian teknikal aplikasi

Projek ini turut memberi aku peluang mengenali peranan Vercel dan Supabase. Dalam aplikasi ini, Vercel digunakan untuk pengehosan, manakala Supabase digunakan bagi pangkalan data. Kedua-duanya menjadi sebahagian daripada susunan teknikal yang menyokong aplikasi.

Aku memahami perkara ini sedikit demi sedikit sepanjang mengurus projek. Apabila ada makluman perubahan perkhidmatan, aku mula menilai kesannya kepada aplikasi, termasuk urusan penambahbaikan dan kemungkinan kos. Pengetahuan itu penting untuk aku merancang penjagaannya selepas siap.


Aplikasi perlu terus dijaga

Bila aplikasi sudah boleh digunakan, masih ada perkara yang perlu diberi perhatian. Aku perlu memikirkan pengurusan data, akses kepada projek dan kemampuan untuk membuat perubahan apabila diperlukan. Semua ini ada kaitan dengan kesinambungan penggunaan aplikasi di sekolah.

Untuk projek seperti ini, aku mahu pendekatan yang mampu diurus. Jika ada cadangan fungsi baharu, aku perlu menilai manfaatnya terlebih dahulu. Aku juga perlu memahami sama ada perubahan itu melibatkan susunan data atau bahagian lain dalam aplikasi.

Antara perkara yang boleh dipertimbangkan pada masa hadapan ialah penambahbaikan paparan jadual, makluman kepada pengguna dan ringkasan penggunaan kemudahan. Ini ialah cadangan yang masih perlu dinilai mengikut keperluan serta kemampuan pengurusan.

Apa yang aku belajar daripada projek ini

Pengalaman ini mengajar aku bahawa memahami keperluan pengguna ialah bahagian penting dalam membangunkan aplikasi. Sebagai orang yang berada di sekolah, aku membawa pengetahuan tentang konteks penggunaan dewan dan bilik mesyuarat. Pengetahuan itu membantu aku merancang dan menilai hasil projek.

Aku juga semakin faham bahawa pembangunan aplikasi memerlukan keputusan yang dibuat secara berterusan. Kita perlu menentukan keutamaan, menyemak hasil dan memilih perubahan yang benar-benar berguna. Kerja ini memerlukan perhatian walaupun bantuan penulisan kod tersedia.

Dalam projek ini, ChatGPT menjadi pembantu aku untuk koding. Aku pula mengurus idea, keperluan, hala tuju dan semakan hasil aplikasi. Pembahagian peranan ini membolehkan aku mengusahakan penyelesaian yang aku mahu untuk kegunaan sekolah.

Bagi aku, kepuasan projek ini datang apabila idea yang dirancang dapat diterjemahkan menjadi sebuah aplikasi yang boleh dirujuk dan diperbaiki. Masih ada ruang untuk belajar, tetapi pengalaman membangunkan aplikasi tempahan dewan dan bilik mesyuarat ini sudah memberi aku asas untuk meneruskan usaha yang seterusnya.

Friday, October 30, 2026

Auto RX Hidup Tapi KA9Q bermasalah

 


Cerita troubleshoot radiosonde pada 30 Oktober 2026 | 9M2ZAK

Malam ini sistem radiosonde saya buat hal sikit. Buka paparan Auto-RX, penuh log merah. Scanner asyik cuba berjalan, kemudian gagal, kemudian cuba lagi.

Antara mesej yang berulang:

KA9Q (sonde.local) - tune call failed ... with a timeout.
Task Manager - Ongoing issue with KA9Q server connection.

Web boleh buka macam biasa, tetapi bahagian penerimaan tak berjalan seperti sepatutnya. Jadi saya mula periksa satu demi satu.

Servis hidup tapi kenapa timeout

Mula-mula saya semak servis KA9Q:

systemctl list-units --all 'radiod*'

Hasilnya, radiod@airspymini-autorx.service ditunjukkan sebagai active running. Nampak elok. Tapi status itu cuma beritahu proses masih hidup. Sama ada Auto-RX boleh berkomunikasi dengannya, itu kena semak lagi.

Saya ambil log menggunakan arahan ini. Pilihan --no-pager memaparkan output terus tanpa masuk ke paparan less:

sudo journalctl -u radiod@airspymini-autorx -n 60 --no-pager

Airspy Mini berjaya dikesan. Frekuensi tuner ditetapkan pada 405.6 MHz, dan fail FFTW wisdom utama pun berjaya dibaca. Ada mesej fail wisdom tambahan tidak dijumpai, tetapi KA9Q terus berjalan selepas itu. Jadi saya tak terus usik bahagian tersebut.

Saya cuba pula:

timeout 15s control sonde.local

Yang keluar cuma “0 channels”. Belum ada jawapan yang meyakinkan. Paparan itu sahaja belum membuktikan pelayan memberi respons, jadi pemeriksaan diteruskan ke bahagian rangkaian.

Petunjuk muncul pada interface

Dalam fail /etc/radio/radiod@airspymini-autorx.conf, tetapan saya ialah:

[global]
hardware = airspy
mode = fm
status = sonde.local
iface = lo
ttl = 0
data = sonde-pcm.local

KA9Q menggunakan interface loopback, iaitu lo. Kemudian saya semak alamat sonde.local:

getent hosts sonde.local

Pada sistem saya ketika itu, alamatnya ialah 239.189.26.13. Ini alamat multicast. Bila saya semak laluan ke alamat tersebut:

ip route get 239.189.26.13

Output menunjukkan dev wlan0. Haa, sini ada petunjuk. KA9Q dikonfigurasi menggunakan lo, tetapi laluan multicast yang dipilih sistem menuju wlan0.

Saya semak juga Docker:

docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Networks}}'

Container radiosonde_auto_rx memang menggunakan rangkaian host. Maknanya Auto-RX berkongsi rangkaian komputer yang sama.

Cuba betulkan laluan dahulu

Saya tambah satu laluan sementara, khusus untuk alamat kawalan KA9Q tadi:

sudo ip route add 239.189.26.13/32 dev lo

Kemudian semak semula:

ip route get 239.189.26.13

Kali ini sudah menunjukkan dev lo. Saya restart Auto-RX, tetapi percubaan awal masih menghasilkan timeout:

tune call (closing channel) failed with return code 124.
Could not contact KA9Q Server sonde.local:5006.

Jadi pembetulan laluan sahaja belum terus memulihkan sistem pada ketika itu. Langkah seterusnya, saya restart KA9Q dahulu:

sudo systemctl restart radiod@airspymini-autorx

Beri masa sekitar 15 saat untuk ia bermula, kemudian restart Auto-RX:

docker restart radiosonde_auto_rx

Selepas menunggu sekitar 30 saat, saya semak log:

docker logs --since 1m --tail 80 radiosonde_auto_rx

Akhirnya keluar mesej yang ditunggu:

Detected peaks on 12 frequencies
Async scan starting: 12 frequencies with max_concurrent=4
Async scan completed: 0 detections from 12 frequencies in 19.9s
Running frequency scan.

Lega. Scanner sudah kembali bekerja, dan selepas dipantau, sistem kembali normal.

“0 detections” dalam satu pusingan itu bermaksud belum ada radiosonde dikenal pasti. Ia bukan mesej kegagalan sambungan. Puncak isyarat yang dikesan boleh datang daripada pelbagai sumber.

Apa yang saya belajar kali ini

Bila nampak timeout, jangan terus anggap Airspy rosak atau perlu pasang semula semuanya. Dalam kes ini, ada ketidakpadanan antara interface dalam konfigurasi KA9Q dengan laluan multicast sistem. Selepas laluan dibetulkan dan kedua-dua servis dimulakan semula mengikut urutan, penerimaan kembali normal.

Saya tak boleh asingkan sepenuhnya kesan pembetulan laluan daripada kesan restart berdasarkan ujian ini sahaja. Tetapi gabungan langkah tersebut berjaya memulihkan setup saya malam ini.

Satu catatan penting untuk rujukan sendiri: laluan yang ditambah menggunakan ip route add tadi masih sementara dan belum dibuat kekal. Ia tidak kekal selepas reboot.

Alamat multicast juga perlu disemak pada sistem masing-masing. Jangan terus salin 239.189.26.13 tanpa menjalankan getent hosts sonde.local terlebih dahulu. Langkah ini merujuk setup KA9Q dan Auto-RX saya yang berjalan pada komputer sama dengan Docker dalam mod host.

Kalau mahu membuang laluan ujian tadi:

sudo ip route del 239.189.26.13/32 dev lo

Begitulah cerita malam ini. Ingatkan kena buka cerita panjang pasal driver dan USB, rupanya pemeriksaan laluan rangkaian yang membawa kita kepada jalan penyelesaian.

Sekarang scanner dah jalan semula. Bolehlah sambung tunggu belon lalu kawasan Johor.

73 de 9M2ZAK

Thursday, September 24, 2026

Bila KA9Q Tiba-Tiba “Hang” Walaupun Service Masih Active — Cara Saya Buat Auto-Recovery Untuk Radiosonde Auto-RX

 Cara saya buat auto-recovery untuk Radiosonde Auto-RX + KA9Q + Airspy Mini

Beberapa hari selepas setup Radiosonde Auto-RX 1.9.0 + KA9Q + Airspy Mini berjalan elok, tiba-tiba scanner saya mula buat perangai. Web UI masih boleh buka. Auto-RX masih hidup. Tapi dekat bahagian log, mula keluar error timeout berulang-ulang.

KA9Q (sonde.local) - tune call failed ... with a timeout.
Is the server running?

Task Manager - Ongoing issue with KA9Q server connection.
Please check the logs.

Mula-mula memang saya ingat mungkin Auto-RX rosak, atau Airspy Mini ada masalah. Rupanya tidak. Masalah yang lebih menarik ialah KA9Q radiod masih ditunjukkan sebagai active (running) oleh systemd, tetapi bahagian control/tune dia dah tak memberi respons dengan betul.

Simptom Yang Saya Nampak

CRITICAL: KA9Q (sonde.local) - tune call failed ... with a timeout.
ERROR: Task Manager - Ongoing issue with KA9Q server connection.

Tapi bila saya check:

sudo systemctl status radiod@airspymini-autorx --no-pager

Status masih:

Active: active (running)

Malah proses radiod, avahi-publish-service dan alamat sonde.local masih ada. Jadi ini bukan service crash biasa.

Test KA9Q

Saya cuba:

control sonde.local

KA9Q masih memberi respons, tetapi keluar channel pelik seperti:

SSRC        preset   samprate   freq, Hz       SNR   output
40277503                0       402775000      nan   (null)

samprate = 0, nan, dan (null) itu memang nampak macam channel yang tak terbentuk dengan sempurna atau stale. Jadi saya cuba restart KA9Q:

sudo systemctl restart radiod@airspymini-autorx

Tunggu beberapa saat:

sleep 8

Kemudian restart Auto-RX:

docker restart radiosonde_auto_rx

Selepas itu scanner mula hidup semula:

Scanner (KA9Q sonde.local) - Starting Scanner Thread
Scanner (KA9Q sonde.local) - Running frequency scan.

Auto-RX saya kembali normal.

Jadi Apa Sebenarnya Berlaku?

Dalam kes saya, masalah nampaknya bukan:

Airspy rosak
Docker rosak
Auto-RX rosak
station.cfg rosak

Sebaliknya KA9Q nampak macam masuk keadaan “service masih hidup tetapi tune/control path dah tersangkut”. Masalah macam ini tak akan dikesan oleh systemd biasa sebab dari sudut Linux, process masih hidup.

process masih hidup = systemd anggap service sihat

Padahal Auto-RX sudah tak boleh buka channel baru. Sebab itu saya fikir: daripada tunggu saya sedar sendiri beberapa jam kemudian, lebih baik Raspberry Pi repair dirinya sendiri.

Penyelesaian Saya: KA9Q Watchdog

Saya buat satu watchdog mudah. Idea dia:

Setiap 5 minit
      ↓
Check log Auto-RX
      ↓
Ada banyak KA9Q tune timeout?
      ↓
TIDAK → biarkan
YA
      ↓
Restart KA9Q
      ↓
Tunggu 8 saat
      ↓
Restart Auto-RX

Saya sengaja tak buat restart KA9Q setiap malam secara paksa. Kalau semuanya sihat, jangan kacau. Watchdog hanya bertindak bila betul-betul nampak simptom masalah.

Langkah 1 — Buat Script Watchdog

Buka:

sudo nano /usr/local/sbin/ka9q-watchdog.sh

Masukkan:

#!/bin/bash

LOCK=/run/ka9q-watchdog.lock
LOG=/var/log/ka9q-watchdog.log

CONTAINER="radiosonde_auto_rx"
SERVICE="radiod@airspymini-autorx"

exec 9>"$LOCK"

flock -n 9 || exit 0

ERRORS=$(docker logs --since 5m "$CONTAINER" 2>&1 | \
grep -cE 'tune call failed.*timeout|Ongoing issue with KA9Q server connection' || true)

if [ "$ERRORS" -ge 3 ]; then

    echo "$(date '+%F %T') - KA9Q unhealthy: $ERRORS errors. Restarting..." >> "$LOG"

    systemctl restart "$SERVICE"

    sleep 8

    docker restart "$CONTAINER" >> "$LOG" 2>&1

    sleep 15

    echo "$(date '+%F %T') - Recovery completed." >> "$LOG"

fi

Simpan:

Ctrl + O
Enter
Ctrl + X

Kemudian jadikan executable:

sudo chmod +x /usr/local/sbin/ka9q-watchdog.sh

Kenapa Saya Letak 3 Error?

Saya tak mahu restart KA9Q hanya kerana satu timeout kecil. Kadang-kadang satu command boleh lambat atau ada transient error. Sebab itu saya gunakan:

if [ "$ERRORS" -ge 3 ]

Maknanya kalau dalam 5 minit terdapat sekurang-kurangnya tiga error berkaitan KA9Q, barulah watchdog anggap sistem bermasalah.

Langkah 2 — Buat systemd Service

Buka:

sudo nano /etc/systemd/system/ka9q-watchdog.service

Isi:

[Unit]
Description=KA9Q Auto-RX Health Watchdog
After=docker.service network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/ka9q-watchdog.sh

Langkah 3 — Buat Timer Setiap 5 Minit

Buka:

sudo nano /etc/systemd/system/ka9q-watchdog.timer

Masukkan:

[Unit]
Description=Check KA9Q health every 5 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=5min
Persistent=true

[Install]
WantedBy=timers.target

Kemudian:

sudo systemctl daemon-reload

Aktifkan:

sudo systemctl enable --now ka9q-watchdog.timer

Check Sama Ada Timer Hidup

Jalankan:

systemctl list-timers | grep ka9q

Kalau semuanya betul, kita akan nampak ka9q-watchdog.timer bersama masa NEXT dan LEFT. Maknanya setiap lima minit systemd akan panggil watchdog tadi.

Test Watchdog Secara Manual

Tak perlu tunggu lima minit. Boleh jalankan:

sudo systemctl start ka9q-watchdog.service

Kemudian:

sudo systemctl status ka9q-watchdog.service --no-pager

Disebabkan service ini Type=oneshot, selepas selesai check status dia boleh kembali kepada inactive (dead). Itu normal. Ia bukan service yang duduk running sepanjang masa. Timer yang akan hidupkan dia setiap lima minit.

Kenapa Log Watchdog Belum Ada?

Masa mula-mula saya cuba:

sudo tail -f /var/log/ka9q-watchdog.log

Saya dapat:

tail: cannot open '/var/log/ka9q-watchdog.log':
No such file or directory

Ini sebenarnya bukan error watchdog. Script hanya menulis log apabila ia benar-benar detect masalah dan melakukan recovery. Kalau KA9Q sihat, script keluar senyap sahaja.

Kalau nak create fail log dari awal:

sudo touch /var/log/ka9q-watchdog.log

sudo chmod 644 /var/log/ka9q-watchdog.log

Selepas itu:

sudo tail -f /var/log/ka9q-watchdog.log

Kalau kosong, itu sebenarnya berita baik. Maknanya watchdog belum perlu repair apa-apa.

Apa Yang Berlaku Bila Watchdog Detect Masalah?

Contohnya Auto-RX mula keluarkan:

tune call failed ... timeout

berulang kali. Watchdog akan kira error lima minit terakhir. Kalau ≥3:

KA9Q unhealthy

Kemudian:

systemctl restart radiod@airspymini-autorx

Tunggu 8 saat, kemudian:

docker restart radiosonde_auto_rx

Dalam log nanti lebih kurang:

2026-09-25 03:15:02 - KA9Q unhealthy: 8 errors. Restarting...
2026-09-25 03:15:26 - Recovery completed.

Jadi kalau masalah berlaku tengah malam pun, sistem boleh cuba pulihkan diri sendiri.

Kenapa Restart KA9Q Dahulu, Baru Auto-RX?

KA9Q restart
     ↓
tunggu
     ↓
Auto-RX restart

Urutan ini penting sebab Auto-RX bergantung kepada sonde.local yang disediakan oleh KA9Q. Kalau Auto-RX hidup dahulu ketika KA9Q masih belum ready, kita boleh dapat semula Could not contact KA9Q atau tune call failed.

Kenapa Saya Tak Restart Raspberry Pi Terus?

Restart seluruh Raspberry Pi terlalu agresif. Masalah saya hanya pada layer KA9Q. Airspy Mini sendiri sebelum ini sudah saya test secara direct dengan airspy_rx dan dia boleh capture IQ dengan normal.

restart komponen paling kecil yang bermasalah dahulu

Baru escalate jika masih gagal.

Setup Saya Sekarang

Radiosonde Auto-RX : 1.9.0
SDR                 : Airspy Mini
Backend             : KA9Q
KA9Q hostname       : sonde.local
Docker              : Ya
OS                  : Raspberry Pi OS 64-bit

KA9Q:

[global]
hardware = airspy
mode = fm
status = sonde.local
iface = lo
ttl = 0
data = sonde-pcm.local

[airspy]
device = airspy
description = "auto_rx"
frequency = 405m6
gainstep = 17

Scan Auto-RX saya:

400.05 MHz – 405.0 MHz

Satu Lagi Perkara Penting

Kalau nampak error:

tune call failed

jangan terus fikir Airspy dah rosak. Dalam kes saya, Airspy langsung tak rosak. Masalah boleh datang daripada:

KA9Q stale channel
radiod stuck
control path timeout
multicast state
Auto-RX ↔ KA9Q communication

Hardware SDR adalah antara benda terakhir yang patut kita tuduh kalau direct SDR test masih OK.

Cara Check Cepat Kalau Masalah Datang Lagi

Saya simpan command ini:

sudo systemctl status radiod@airspymini-autorx --no-pager

control sonde.local

docker logs --since 5m radiosonde_auto_rx

Kalau radiod active tetapi Auto-RX penuh dengan tune call failed ... timeout, saya tahu ia kemungkinan kes sama.

Kesimpulan

Masalah paling susah dalam server bukan semestinya bila process mati. Kadang-kadang service = running, tetapi fungsi utama di dalamnya dah tak memberi respons. Itulah yang berlaku pada setup KA9Q saya.

CHECK
  ↓
KA9Q OK?
  ↓
YES → buat apa-apa pun tak perlu
  ↓
NO
  ↓
restart KA9Q
  ↓
restart Auto-RX

Simple saja. Tapi untuk station radiosonde yang berjalan 24/7, benda kecil macam ini sangat berguna. Sekurang-kurangnya selepas ini kalau KA9Q tersangkut masa saya tidur, saya tak perlu tunggu esok pagi baru sedar spectrum dah kosong berjam-jam.

Kisah Aku Membangunkan Aplikasi Tempahan Dewan dan Bilik Mesyuarat

  Bermula dengan urusan harian di sekolah Aku nak kongsikan cerita di sebalik aplikasi tempahan dewan dan bilik mesyuarat SMK Bandar Putra. ...