ภาพรวม GNSS Satellite Globe 3D

ดาวเทียมที่เครื่องรับ NEO-M8N ตรวจพบ • แสดงทิศทางจากเครื่องรับ ไม่ใช่ตำแหน่งวงโคจรหรือระยะจริง

เปิดหน้านี้เพื่อโหลดข้อมูล

📍 GNSS Receiver • ทิศเหนือ / ตะวันออกอ้างอิงตำแหน่งเครื่องรับ • เส้นทางย้อนหลัง 30 นาที

● ≥40 ดีมาก● 30–<40 ดี● 20–<30 ปานกลาง● <20 อ่อน● ไม่ทราบ C/N0

2D Skyplot

ประวัติมุมเงย 30 นาที

Live Satellite Table

Satellite IDSystemAzimuthElevationC/N0 (dB-Hz)Status

Satellite globe (3D animation)

กำลังโหลดข้อมูลดาวเทียม…
📍 GNSS Receiver · —
แสดงทิศทางดาวเทียมจากเครื่องรับ ไม่ใช่วงโคจรหรือระยะจริง · เส้นทางย้อนหลัง 30 นาที
● ≥40 ดีมาก● 30–<40 ดี● 20–<30 ปานกลาง● <20 อ่อน● ไม่ทราบ C/N0
คลิกดาวเทียมเพื่อดูรายละเอียด

System status

Latest measurement

Satellite skyplot (latest) — 2D + 3D

2D Skyplot (Azimuth–Elevation)
3D Sky Hemisphere
Azimuth 0°=N · 90°=E · 180°=S · 270°=W · radius = 90 − elevation (2D) · x=cos(el)·sin(az), y=cos(el)·cos(az), z=sin(el), North=+Y, East=+X, Zenith=+Z (3D) — snapshot เดียวจาก measurement ล่าสุด

การวิเคราะห์ดาวเทียม (Satellite analysis) — X–Y

Elevation vs Signal Quality X=Elevation (°) · Y=Signal (…)
Azimuth vs Signal Quality X=Azimuth (°) 0–360 · Y=Signal
Satellite Elevation Over Time Y=Elevation (°)
Satellite Azimuth Over Time Y=Azimuth (°) · unwrap 359°→1°
Satellite Signal Quality Over Time Y=Signal (…)
Satellite Movement X–Y r=90−el · N=+Y · E=+X · equal aspect
X–Y ใช้ projection ร่วมกับ 2D Skyplot (r = 90 − elevation) แต่ต่างกัน: Skyplot = ตำแหน่งดาวหลายดวงใน snapshot ส่วน Movement X–Y = trajectory ตามเวลา ของดาวที่เลือก แกน X–Y นี้ไม่ใช่วงโคจรจริงของดาวเทียม · เส้นจะ break เมื่อ missing interval (>1.5× interval) ห้ามตีความว่า วัดต่อเนื่อง · Correlation ≠ Causation

Constellation summary

Statistics summary

Temperature (last 24h)

Data completeness

Device health

Recent measurements

API activity

GNSS คืออะไร?

GNSS ผ่านดาวเทียม GNSS และ GPS

ในโลกยุคปัจจุบัน การนำทางและการระบุตำแหน่งไม่ได้จำกัดอยู่แค่ในรถยนต์หรือสมาร์ทโฟนอีกต่อไป แต่กลายเป็นหัวใจสำคัญของเศรษฐกิจและความมั่นคงระดับโลก โลกทุกวันนี้การเดินทาง การสื่อสาร และเศรษฐกิจดิจิทัลต่างพึ่งพาความแม่นยำของ “ตำแหน่ง” ที่กลายเป็นรากฐานของการใช้ชีวิตประจำวัน เทคโนโลยีดาวเทียมจึงมีบทบาทสำคัญอย่างยิ่ง ท่ามกลางโลกที่ซับซ้อนและแข่งขันกันสูง ความเข้าใจความแตกต่างของ GNSS และ GPS ไม่ได้เป็นเพียงเรื่องของเทคนิค แต่ยังสะท้อนถึงความมั่นคงทางเทคโนโลยี การพัฒนาเศรษฐกิจ และอำนาจทางภูมิรัฐศาสตร์ในศตวรรษที่ 21 อีกด้วย เทคโนโลยีดาวเทียมสองคำที่มักถูกใช้แทนกันบ่อยคือ GNSS และ GPS แม้จะมีความใกล้เคียงกัน แต่ทั้งสองมีความหมายและศักยภาพที่ต่างกันมาก

GNSS (Global Navigation Satellite System)

GNSS คือคำรวมที่หมายถึง “ระบบนำทางผ่านดาวเทียมทั่วโลก” มีระบบดาวเทียมหลายระบบจากทั่วโลก จึงครอบคลุมพื้นที่ทั่วโลกอย่างแท้จริง แม้กระทั่งในพื้นที่ห่างไกล GNSS ให้การครอบคลุมที่ครอบคลุมและเชื่อถือได้มากขึ้นในภูมิภาคและสภาพแวดล้อมที่หลากหลาย ด้วยกลุ่มดาวเทียมที่รวมกันโดยผนวกรวมกลุ่มดาวเทียมจากหลายประเทศ เช่น GPS (สหรัฐฯ), GLONASS (รัสเซีย), Galileo (สหภาพยุโรป) และ BeiDou (จีน) รวมกันมากกว่า 120 ดวง การทำงานแบบบูรณาการนี้ทำให้ GNSS มีความแม่นยำสูงกว่า (ใกล้เคียง 1–2 เมตร) และครอบคลุมมากกว่า โดยเฉพาะในสภาพแวดล้อมที่ท้าทาย เช่น เมืองที่มีตึกสูงหรือป่าทึบ

GPS (Global Positioning System)

ในอีกมุมหนึ่ง GPS คือระบบดาวเทียมนำทางที่พัฒนาโดยสหรัฐอเมริกาและใช้งานมานานหลายทศวรรษ ปัจจุบันมีดาวเทียมปฏิบัติการราว 31 ดวง เรียงตัวกันในระนาบวงโคจร 6 ระนาบ แต่ละระนาบมีดาวเทียม 4-5 ดวง การจัดวางแบบนี้ทำให้มั่นใจได้ว่าจะสามารถมองเห็นดาวเทียมอย่างน้อย 4 ดวงได้จากทุกตำแหน่งบนโลกตลอดเวลา ครอบคลุมพื้นที่ทั่วโลก และถูกใช้แพร่หลายในโทรศัพท์มือถือ การเดินเรือ การบิน และการทหาร

ระบบนำทางดาวเทียมเฉพาะภูมิภาคอื่น ๆ

นอกจากนี้แล้วยังมีระบบนำทางดาวเทียมอื่นๆ เช่น Quasi-Zenith Satellite System (QZSS) ของญี่ปุ่น เป็นระบบดาวเทียมนำทางแบบเฉพาะภูมิภาคที่เน้นพื้นที่ในแถบเอเชียตะวันออกและโอเชียเนีย เพื่อช่วยเพิ่มความแม่นยำของ GPS ในพื้นที่ที่มีตึกสูงหรือภูเขา และ Navigation with Indian Constellation (NavIC) ของอินเดีย เป็นระบบดาวเทียมนำทางแบบเฉพาะภูมิภาคเช่นกัน มีเป้าหมายเพื่อให้บริการนำทางที่แม่นยำในประเทศอินเดียและพื้นที่โดยรอบประมาณ 1,500 กิโลเมตร

ความแตกต่างสำคัญระหว่าง GNSS และ GPS

ความแตกต่างสำคัญ คือ GNSS เป็นร่มใหญ่ที่เป็นการรวมพลังของหลายประเทศเข้าด้วยกัน การมีหลายระบบช่วยลดความเสี่ยงจากการสูญเสียสัญญาณ และเพิ่มเสถียรภาพในการใช้งานในทุกภูมิภาคของโลก ส่วน GPS นั่นเป็นเพียงหนึ่งในระบบที่อยู่ภายใต้ GNSS เท่านั้น

ในปัจจุบัน การพึ่งพา GNSS ไม่ได้จำกัดอยู่แค่การนำทางเท่านั้น แต่ยังขยายไปสู่ เศรษฐกิจดิจิทัล การเกษตรแม่นยำสูง การสำรวจภูมิศาสตร์ การขนส่งโลจิสติกส์ การบิน และแม้กระทั่งการรับมือภัยพิบัติ ตัวอย่างเช่น การใช้โดรนติดตั้ง GPS/GNSS สำหรับการทำแผนที่พื้นที่น้ำท่วม หรือการวางแผนช่วยเหลือผู้ประสบภัยได้อย่างอย่างรวดเร็ว

ในระดับภูมิรัฐศาสตร์ GNSS ยังสะท้อนการแข่งขันด้านเทคโนโลยีระหว่างมหาอำนาจโลก สหรัฐฯ รักษาความเป็นผู้นำผ่าน GPS ขณะที่จีนขยายอิทธิพลด้วยระบบ BeiDou และยุโรปพัฒนา Galileo เพื่อไม่พึ่งพาระบบใดระบบหนึ่ง การมี GNSS ที่หลากหลายจึงไม่ใช่เพียงเรื่องเทคโนโลยี แต่ยังเป็นเรื่องของ ความมั่นคงทางดิจิทัลและอธิปไตยทางเทคโนโลยีอีกด้วย

แม้ GPS จะยังคงมีบทบาทสำคัญ แต่ GNSS คือวิวัฒนาการขั้นต่อไปของการระบุตำแหน่งที่แม่นยำ เชื่อถือได้ และเป็นสากล ท่ามกลางโลกที่เชื่อมโยงกันมากขึ้น เทคโนโลยีนี้ไม่เพียงช่วยให้เราเดินทางได้สะดวกขึ้น แต่ยังกลายเป็นรากฐานของเศรษฐกิจ ความมั่นคง และการพัฒนาที่ยั่งยืนในศตวรรษที่ 21

อ้างอิง: GISTDA — ข่าวสาร GISTDA (n_id=8782)

อ้างอิง: GISTDA — ข่าวสาร GISTDA (n_id=5708)

กราฟวิเคราะห์ (Graph Analysis)

รวมกราฟทุกรูปแบบไว้หน้าเดียว — สีสันสดใสทันสมัย · แสดงครบทุกค่าจากฐานข้อมูลจริง (all-time ถ้าไม่ได้เลือกช่วงในแถบกรอง)

สรุปภาพรวม (overview)

กราฟดาวเทียม (รายชั่วโมง) — จำนวนดาว + คุณภาพสัญญาณ

Visible / Used เฉลี่ยรายชั่วโมง ดาวที่มองเห็น / ที่ใช้งาน
HDOP เฉลี่ยรายชั่วโมง P = √(H²+V²) · ค่าต่ำ = แม่นยำ
จำนวนข้อมูลรายชั่วโมง ความถี่การบันทึก

กราฟรายวัน (daily aggregates)

Visible / Used เฉลี่ยรายวัน ตามเวลาท้องถิ่น (เวลาบนกราฟ = ตามที่เลือก TZ)
HDOP เฉลี่ยรายวัน
จำนวนข้อมูลรายวัน bar = จำนวน measurement
อุณหภูมิรายวัน min–avg–max (°C)

กราฟอุณหภูมิ (ทุกจุดข้อมูล) — internal / external / delta

อุณหภูมิ (°C) Internal = สีโดดเด่น · External = สีฟ้าอมเขียว
Delta (internal − external) ความต่างอุณหภูมิ (°C)

กราฟกลุ่มดาวเทียม (constellations)

สัดส่วนการมองเห็น (visible)
ความแรงสัญญาณรายกลุ่มดาว (dB-Hz)

กราฟสุขภาพระบบ (system health) — all-time series

Free heap + min free heap (KB)
WiFi RSSI (dBm) + uptime (min)
Reboot / disconnect / HTTP fail สะสมตามวัน

Data completeness (ความครบถ้วนข้อมูล)

ความเป็นมาในการตรวจวัดสัญญาณดาวเทียม GNSS

ระบบบันทึกและวิเคราะห์คุณภาพสัญญาณและการเคลื่อนที่ของดาวเทียม GNSS ด้วย ESP32-S3 CAM เเละวัดอุณหภูมิสภาพเเวดล้อม

การตรวจวัดสัญญาณดาวเทียม GNSS

1. บทนำและความเป็นมาของโครงการ

ระบบดาวเทียมนำทางมีบทบาทสำคัญต่อการระบุตำแหน่ง การเดินทาง การสำรวจ การติดตามอุปกรณ์ และการอ้างอิงเวลา โดยเครื่องรับบนพื้นโลกสามารถรับสัญญาณจากดาวเทียมหลายดวง เพื่อนำข้อมูลมาคำนวณตำแหน่งและเวลาได้ อย่างไรก็ตาม ความสามารถในการรับสัญญาณและคุณภาพของผลตำแหน่งไม่ได้คงที่ตลอดเวลา แม้จะติดตั้งเครื่องรับไว้ที่เดิมก็ตาม

ความเปลี่ยนแปลงดังกล่าวเกี่ยวข้องกับหลายปัจจัย เช่น จำนวนดาวเทียมที่รับได้ การกระจายตัวของดาวเทียมบนท้องฟ้า ระดับสัญญาณ ตำแหน่งและทิศทางของเสาอากาศ สิ่งกีดขวาง และการสะท้อนของสัญญาณจากอาคารหรือพื้นผิวโดยรอบ การตรวจสอบเพียงว่ามีพิกัดแสดงขึ้นมาหรือไม่ จึงยังไม่เพียงพอสำหรับอธิบายสภาพการรับสัญญาณในแต่ละช่วงเวลา

โครงการ “ระบบบันทึกและวิเคราะห์คุณภาพสัญญาณและการเคลื่อนที่ของดาวเทียม GNSS ด้วย ESP32-S3 CAM เเละวัดอุณหภูมิสภาพเเวดล้อม” จึงพัฒนาขึ้นเพื่อรวบรวมข้อมูลการรับสัญญาณ GNSS อย่างต่อเนื่อง ติดตามการเปลี่ยนแปลงตำแหน่งเชิงมุมของดาวเทียม และตรวจวัดอุณหภูมิบริเวณภายในและภายนอกกล่องอุปกรณ์ควบคู่กัน

ระบบใช้เครื่องรับ GNSS จำนวน 1 ตัว เซ็นเซอร์อุณหภูมิ DS18B20 จำนวน 2 ตัว และบอร์ด ESP32-S3 CAM จำนวน 1 บอร์ด โดยบอร์ดทำหน้าที่ควบคุมการอ่านข้อมูล ตรวจสอบข้อมูล ประมวลผลสถิติ และส่งข้อมูลผ่าน Wi-Fi ไปยังเว็บเซิร์ฟเวอร์ ข้อมูลถูกจัดเก็บในฐานข้อมูลและแสดงผลผ่าน Dashboard เพื่อให้ผู้ใช้งานตรวจสอบสถานะปัจจุบัน วิเคราะห์ข้อมูลย้อนหลัง และเปรียบเทียบผลระหว่างช่วงเวลาได้

แม้บอร์ดที่เลือกใช้จะเป็น ESP32-S3 CAM แต่โครงการนี้ ไม่ได้เชื่อมต่อหรือใช้งานกล้อง การทำงานทั้งหมดมุ่งเน้นการรับข้อมูลจากเครื่องรับ GNSS และเซ็นเซอร์อุณหภูมิ รวมถึงการสื่อสารข้อมูลกับระบบเว็บไซต์

2. วัตถุประสงค์ของโครงการ

  1. พัฒนาระบบบันทึกข้อมูล GNSS และอุณหภูมิที่ทำงานต่อเนื่องโดยอัตโนมัติ
  2. ติดตามจำนวนดาวเทียมที่ตรวจพบและจำนวนดาวเทียมที่เครื่องรับใช้คำนวณตำแหน่ง
  3. วิเคราะห์ระดับสัญญาณและความเปลี่ยนแปลงของสัญญาณดาวเทียมแต่ละดวง
  4. ติดตามมุมทิศและมุมเงยของดาวเทียม เพื่อศึกษาการเปลี่ยนแปลงตำแหน่งที่สังเกตได้จากจุดติดตั้งเครื่องรับ
  5. ตรวจวัดอุณหภูมิภายในกล่องอุปกรณ์และสภาพแวดล้อมภายนอก เพื่อเปรียบเทียบความแตกต่างระหว่างสองบริเวณ
  6. ศึกษาความสัมพันธ์ตามเวลาระหว่างข้อมูลการรับสัญญาณ GNSS และข้อมูลอุณหภูมิ
  7. แสดงผลผ่านเว็บไซต์ในรูปแบบที่เข้าใจง่าย พร้อมรองรับการตรวจสอบย้อนหลังและส่งออกข้อมูลเพื่อวิเคราะห์เพิ่มเติม
  8. ตรวจสอบความต่อเนื่องของข้อมูลและสถานะการทำงานของอุปกรณ์ตลอดช่วงทดลอง

3. GNSS คืออะไร และทำงานอย่างไร

GNSS หรือ Global Navigation Satellite System หมายถึงระบบดาวเทียมนำทางที่ใช้สำหรับระบุตำแหน่งและอ้างอิงเวลา โดยครอบคลุมระบบดาวเทียมหลายระบบ เช่น GPS, GLONASS, BeiDou และ Galileo

GPS จึงเป็นส่วนหนึ่งของ GNSS ไม่ใช่ชื่อเรียกแทนทุกระบบดาวเทียมนำทาง

ดาวเทียมส่งสัญญาณที่มีข้อมูลเวลาและข้อมูลวงโคจรมายังเครื่องรับ เครื่องรับใช้เวลาการเดินทางของสัญญาณร่วมกับข้อมูลตำแหน่งดาวเทียมในการคำนวณตำแหน่งของตนเอง โดยการหาตำแหน่งสามมิติพร้อมแก้ความคลาดเคลื่อนนาฬิกาของเครื่องรับโดยทั่วไปต้องอาศัยข้อมูลดาวเทียมอย่างน้อย 4 ดวง และต้องมีคุณภาพข้อมูลที่เหมาะสมด้วย

ในโครงการนี้ เครื่องรับ GNSS เป็นอุปกรณ์ที่ประมวลผลสัญญาณดาวเทียมโดยตรง ส่วน ESP32-S3 รับข้อมูลที่เครื่องรับประมวลผลแล้ว เพื่อนำมาตรวจสอบ จัดเก็บ และสรุปผลต่อไป

ระบบดาวเทียมที่ปรากฏในข้อมูลขึ้นอยู่กับความสามารถของเครื่องรับ เฟิร์มแวร์ การตั้งค่า และสัญญาณที่รับได้จริง จึงไม่ได้หมายความว่าเครื่องรับจะรับทุกระบบพร้อมกันได้ตลอดเวลา

ความหมายของการตรวจจับดาวเทียม

คำว่า “ตรวจจับดาวเทียม” ในโครงการนี้ หมายถึงการรับสัญญาณและอ่านข้อมูลดาวเทียมที่เครื่องรับรายงาน เช่น รหัสดาวเทียม ระดับสัญญาณ มุมทิศ และมุมเงย

อุปกรณ์ไม่ได้ส่งสัญญาณไปค้นหา ควบคุม หรือสื่อสารกลับไปยังดาวเทียม

ความหมายของการเคลื่อนที่ของดาวเทียม

การติดตามการเคลื่อนที่ในโครงการนี้หมายถึง การเปลี่ยนแปลงมุมทิศและมุมเงยของดาวเทียมตามเวลา เมื่อสังเกตจากจุดติดตั้งเครื่องรับ

ข้อมูลดังกล่าวช่วยอธิบายว่าดาวเทียมปรากฏอยู่ทางทิศใด สูงจากขอบฟ้าเท่าใด และเปลี่ยนตำแหน่งบนท้องฟ้าอย่างไร โดยไม่ได้เป็นการคำนวณวงโคจร ความเร็ว หรือระยะทางจริงของดาวเทียมโดยตรง

4. อุปกรณ์ที่ใช้ในระบบ

อุปกรณ์จำนวนหน้าที่หลัก
เครื่องรับ GNSS u-blox NEO-M8N พร้อมเสาอากาศ1 ชุดรับและประมวลผลสัญญาณดาวเทียม รายงานตำแหน่ง เวลา และข้อมูลดาวเทียม
DS18B20 ภายในกล่อง1 ตัววัดอุณหภูมิบริเวณภายในกล่องที่ติดตั้งอุปกรณ์
DS18B20 ภายนอกกล่อง1 ตัววัดอุณหภูมิสภาพแวดล้อมบริเวณภายนอกกล่อง
ESP32-S3 CAM1 บอร์ดควบคุมการอ่านข้อมูล คำนวณสถิติ จัดเก็บข้อมูลชั่วคราว และส่งข้อมูลผ่าน Wi-Fi
เครือข่าย Wi-Fi ที่เชื่อมต่ออินเทอร์เน็ต1 ช่องทางเชื่อมต่ออุปกรณ์กับเว็บเซิร์ฟเวอร์
เว็บเซิร์ฟเวอร์และ API1 ระบบรับ ตรวจสอบ และจัดการข้อมูลจากอุปกรณ์
ฐานข้อมูล MySQL/MariaDB1 ระบบจัดเก็บข้อมูลการตรวจวัดและข้อมูลดาวเทียมย้อนหลัง
Dashboard บนเว็บไซต์1 ระบบแสดงสถานะ กราฟ ตาราง และข้อมูลสำหรับการวิเคราะห์

4.1 เครื่องรับ GNSS

เครื่องรับ GNSS รับสัญญาณผ่านเสาอากาศและประมวลผลข้อมูลภายในโมดูล จากนั้นส่งผลให้ ESP32-S3 ผ่าน UART ซึ่งเป็นการสื่อสารข้อมูลแบบอนุกรม

ข้อมูลสำคัญที่ส่งออกมาประกอบด้วยเวลา ตำแหน่ง สถานะการระบุตำแหน่ง จำนวนดาวเทียม ค่าทางเรขาคณิตของดาวเทียม และรายละเอียดดาวเทียมแต่ละดวง

เสาอากาศเป็นส่วนสำคัญของระบบ เพราะตำแหน่งติดตั้งและสภาพแวดล้อมรอบเสาอากาศมีผลต่อการรับสัญญาณ การติดตั้งใกล้อาคาร ต้นไม้ หรือพื้นผิวที่สะท้อนสัญญาณ อาจทำให้ผลการรับสัญญาณแตกต่างจากพื้นที่เปิดโล่ง

4.2 เซ็นเซอร์ DS18B20 ภายในกล่อง

เซ็นเซอร์ตัวแรกติดตั้งภายในกล่อง เพื่อวัดอุณหภูมิบริเวณที่บอร์ดและอุปกรณ์ทำงาน ใช้ติดตามความร้อนภายในกล่องและเปรียบเทียบกับอุณหภูมิภายนอก

ค่าที่วัดเป็นอุณหภูมิบริเวณหัววัด ไม่ใช่อุณหภูมิภายในชิปประมวลผลโดยตรง และอาจแตกต่างกันได้ตามระยะห่างจากบอร์ด การไหลเวียนของอากาศ และตำแหน่งที่ติดตั้ง

4.3 เซ็นเซอร์ DS18B20 ภายนอกกล่อง

เซ็นเซอร์ตัวที่สองติดตั้งภายนอกกล่อง เพื่อวัดอุณหภูมิบริเวณสภาพแวดล้อมของจุดทดลอง

การตีความค่าเป็นอุณหภูมิอากาศควรพิจารณาวิธีติดตั้งด้วย หากหัววัดได้รับแสงแดดโดยตรงหรือสัมผัสพื้นผิวร้อน ค่าที่อ่านอาจสะท้อนความร้อนจากแสงแดดหรือพื้นผิวนั้นร่วมด้วย

เซ็นเซอร์ทั้งสองใช้การสื่อสารแบบดิจิทัล 1-Wire และแยกช่องอ่านข้อมูล เพื่อให้ระบุได้ชัดเจนว่าค่าใดเป็นอุณหภูมิภายในและค่าใดเป็นอุณหภูมิภายนอก

4.4 บอร์ด ESP32-S3 CAM

ESP32-S3 CAM เป็นศูนย์กลางการควบคุมของระบบ ทำงานด้วยโปรแกรมภาษา C++ บน Arduino framework โดยรับข้อมูลจากเครื่องรับ GNSS และเซ็นเซอร์ทั้งสองตัว แล้วจัดเตรียมข้อมูลสำหรับส่งไปยังเว็บไซต์

หน้าที่ของบอร์ดประกอบด้วยการอ่านข้อมูล ตรวจสอบความถูกต้อง คำนวณสถิติ จัดการเวลา จัดเก็บรายการที่รอส่ง และสื่อสารผ่าน Wi-Fi โดยไม่ได้ใช้งานกล้องหรือประมวลผลภาพ

5. การแบ่งหน้าที่ประมวลผล

เครื่องรับ GNSS: ประมวลผลสัญญาณดาวเทียม

เครื่องรับทำหน้าที่คำนวณตำแหน่งและเวลา รวมถึงรายงานสถานะและตัวแปรที่เกี่ยวข้องกับการรับสัญญาณ

เฟิร์มแวร์อ่านข้อมูล UBX หลัก ได้แก่

ชุดข้อมูลข้อมูลที่นำมาใช้
NAV-PVTตำแหน่ง เวลา สถานะ Fix และจำนวนดาวเทียมที่ใช้
NAV-DOPค่าที่เกี่ยวข้องกับเรขาคณิตของดาวเทียม
NAV-SATระบบและรหัสดาวเทียม ระดับสัญญาณ มุมทิศ และมุมเงย

ESP32-S3: ตรวจสอบและสรุปข้อมูล

บอร์ดนำข้อมูลที่อ่านได้มาตรวจสอบก่อนใช้งาน เช่น ความสมบูรณ์ของข้อความ GNSS ความใหม่ของข้อมูล และความถูกต้องของค่าที่ได้จากเซ็นเซอร์

จากนั้นรวบรวมตัวอย่างภายในช่วงตรวจวัดเดียวกัน แล้วคำนวณค่าสถิติที่เหมาะสมกับแต่ละตัวแปร โดยข้อมูลทุกชนิดไม่ได้ถูกเฉลี่ยเหมือนกันทั้งหมด เช่น อุณหภูมิและระดับสัญญาณมีค่าสถิติภายในช่วง ส่วนตำแหน่งใช้ข้อมูลล่าสุดที่ผ่านเงื่อนไขของระบบ

เว็บเซิร์ฟเวอร์: รับและจัดเก็บข้อมูล

บอร์ดส่งข้อมูลรูปแบบ JSON ผ่าน HTTPS ไปยัง API เว็บเซิร์ฟเวอร์ตรวจสอบสิทธิ์และรูปแบบข้อมูล ก่อนบันทึกลงฐานข้อมูล

ESP32 จึงส่งข้อมูลผ่าน Web API และไม่ได้เชื่อมต่อฐานข้อมูล MySQL โดยตรง

Dashboard: แสดงผลและช่วยวิเคราะห์

Dashboard เรียกข้อมูลจากระบบมาแสดงเป็นสถานะ ตาราง และกราฟ เพื่อให้ตรวจสอบได้ทั้งผลล่าสุดและแนวโน้มย้อนหลัง

เส้นทางข้อมูลโดยรวม

สัญญาณดาวเทียม → เครื่องรับ GNSS → ESP32-S3 CAM ← เซ็นเซอร์อุณหภูมิ 2 ตัว

ESP32-S3 CAM → Wi-Fi → HTTPS API → ฐานข้อมูล → Dashboard

6. ความถี่และช่วงเวลาการบันทึก

รายการการทำงานที่กำหนด
ข้อมูล GNSSประมาณ 1 ครั้งต่อวินาที
อุณหภูมิภายในทุก 10 วินาที
อุณหภูมิภายนอกทุก 10 วินาที
สรุปและส่งข้อมูลทุก 5 นาที หรือ 300 วินาที
เวลาอ้างอิงจัดเก็บUTC
เวลาแสดงผลสำหรับประเทศไทยBangkok หรือ UTC+7

เมื่อทำงานต่อเนื่องครบช่วง 5 นาที จะมีตัวอย่างอุณหภูมิประมาณ 30 ตัวอย่างต่อเซ็นเซอร์ ส่วนจำนวนตัวอย่าง GNSS ที่ใช้ได้จริงขึ้นอยู่กับข้อความที่เครื่องรับส่งมาและเงื่อนไขการตรวจสอบข้อมูล

การเริ่มทำงานของอุปกรณ์อาจไม่ตรงกับขอบช่วง 5 นาที ระบบจึงเริ่มเก็บช่วงเต็มตามขอบเวลาที่กำหนด เพื่อให้เปรียบเทียบข้อมูลระหว่างช่วงได้สม่ำเสมอ

Dashboard แสดงข้อมูลตามรอบที่อุปกรณ์ส่งและรอบการรีเฟรชของหน้าเว็บ จึงไม่ใช่การถ่ายทอดค่าตรวจวัดทุกวินาที แม้เครื่องรับจะส่งข้อมูลให้บอร์ดทุกวินาทีก็ตาม

ระบบจัดเก็บข้อมูลทุกช่วง 5 นาที และเก็บต่อเนื่องแบบไม่จำกัดระยะเวลา (ไม่จำกัดจำนวนวัน)

ในแต่ละวัน (24 ชั่วโมง) มีช่วงข้อมูลตามแผน = 24 × 12 = 288 ช่วง

จำนวนนี้เป็นเป้าหมายตามเวลา ไม่ใช่การยืนยันว่าข้อมูลจริงครบถ้วนแล้ว ต้องตรวจสอบรายการที่ได้รับและช่วงที่ขาดหายเพิ่มเติม

7. ตัวแปร GNSS และความหมาย

7.1 สถานะการระบุตำแหน่ง หรือ Fix

สถานะ Fix ใช้บอกว่าเครื่องรับมีผลตำแหน่งที่ใช้งานได้หรือไม่ การได้รับสัญญาณจากดาวเทียมบางดวงไม่ได้หมายความว่าจะคำนวณตำแหน่งได้ทันที เพราะยังต้องมีข้อมูลที่เพียงพอและผ่านเงื่อนไขของเครื่องรับ

หากไม่มีตำแหน่งที่ใช้ได้ ระบบจะไม่ใช้พิกัดดังกล่าวเป็นผลตำแหน่งที่ถูกต้อง

7.2 จำนวนดาวเทียมที่ตรวจพบและจำนวนที่ใช้คำนวณ

สองค่านี้มีความหมายต่างกัน

  • ดาวเทียมที่ตรวจพบสัญญาณ: ดาวเทียมที่เครื่องรับรายงานและผ่านเกณฑ์การนับของระบบ
  • ดาวเทียมที่ใช้คำนวณตำแหน่ง: ดาวเทียมที่เครื่องรับเลือกนำมาใช้ในผลตำแหน่ง

เครื่องรับอาจตรวจพบดาวเทียมได้มากกว่าจำนวนที่ใช้จริง เนื่องจากคุณภาพหรือความพร้อมของข้อมูลแต่ละดวงแตกต่างกัน

นอกจากนี้ รายชื่อดาวเทียมที่สะสมตลอดช่วง 5 นาทีอาจมีจำนวนมากกว่าจำนวนที่รับได้ในวินาทีสุดท้ายของช่วง เพราะดาวเทียมบางดวงอาจปรากฏเพียงบางเวลา

7.3 ระดับสัญญาณ C/N₀

C/N₀ คืออัตราส่วนกำลังคลื่นพาหะต่อความหนาแน่นกำลังสัญญาณรบกวน มีหน่วยเป็น dB-Hz ใช้ประกอบการพิจารณาการรับสัญญาณของดาวเทียมแต่ละดวง

โดยทั่วไป ค่าที่สูงขึ้นหมายถึงคลื่นพาหะเด่นขึ้นเมื่อเทียบกับสัญญาณรบกวน แต่ไม่ได้รับประกันว่าตำแหน่งจะถูกต้องเสมอไป เพราะยังมีปัจจัยอื่น เช่น การสะท้อนของสัญญาณและเรขาคณิตดาวเทียม

ระบบสรุป C/N₀ เป็นค่าเฉลี่ย ค่าต่ำสุด ค่าสูงสุด และส่วนเบี่ยงเบนมาตรฐาน เพื่อให้เห็นทั้งระดับโดยรวมและความผันผวนของสัญญาณ

7.4 มุมเงย หรือ Elevation

มุมเงยบอกว่าดาวเทียมอยู่สูงจากขอบฟ้าเท่าใดเมื่อมองจากเครื่องรับ

มุมเงยความหมาย
0°อยู่บริเวณขอบฟ้า
45°อยู่ระหว่างขอบฟ้ากับเหนือศีรษะ
90°อยู่เหนือศีรษะ

มุมเงยช่วยให้พิจารณาระดับสัญญาณร่วมกับตำแหน่งบนท้องฟ้า และศึกษาว่าบริเวณใดอาจได้รับผลจากสิ่งกีดขวาง

7.5 มุมทิศ หรือ Azimuth

มุมทิศแสดงทิศทางของดาวเทียมรอบจุดติดตั้ง โดยวัดจากทิศเหนือวนตามเข็มนาฬิกา

มุมทิศทิศทาง
0° หรือ 360°เหนือ
90°ตะวันออก
180°ใต้
270°ตะวันตก

เมื่อติดตามมุมทิศและมุมเงยของดาวเทียมดวงเดิมหลายช่วงเวลา จะเห็นการเปลี่ยนตำแหน่งเชิงมุมของดาวเทียมจากมุมมองของเครื่องรับ

7.6 ค่า HDOP, VDOP และ PDOP

DOP เป็นตัวชี้วัดผลของเรขาคณิตหรือการกระจายตัวของดาวเทียมต่อการหาตำแหน่ง

  • HDOP: เกี่ยวข้องกับตำแหน่งแนวราบ
  • VDOP: เกี่ยวข้องกับตำแหน่งแนวดิ่ง
  • PDOP: เกี่ยวข้องกับตำแหน่งสามมิติ

โดยทั่วไปค่าที่ต่ำลงหมายถึงเรขาคณิตที่เอื้อต่อการคำนวณตำแหน่งมากขึ้น แต่ DOP ไม่มีหน่วย และไม่ใช่ค่าความคลาดเคลื่อนเป็นเมตร

7.7 ตำแหน่งและความสูง

ละติจูดและลองจิจูดเป็นผลตำแหน่งที่เครื่องรับรายงาน ส่วนความสูงเป็นค่าความสูงเหนือระดับน้ำทะเลที่ใช้เมื่อสถานะตำแหน่งรองรับ

ตำแหน่งในรายการสรุปเป็นข้อมูลล่าสุดที่ผ่านเงื่อนไข ไม่ใช่ตำแหน่งเฉลี่ยของทุกตัวอย่างตลอด 5 นาที และไม่ใช่เส้นทางการเคลื่อนที่ของตัวเครื่องรับ

8. การวัดและวิเคราะห์อุณหภูมิ

ข้อมูลอุณหภูมิช่วยอธิบายสภาพที่อุปกรณ์ทำงานจริง โดยอุณหภูมิภายในกล่องอาจแตกต่างจากภายนอกเนื่องจากความร้อนของวงจร แสงแดด วัสดุกล่อง และการระบายอากาศ

ระบบเก็บข้อมูลของเซ็นเซอร์แต่ละตัวแยกกัน พร้อมจำนวนตัวอย่างที่ผ่านการตรวจสอบ เพื่อให้ทราบว่าค่าสถิติได้มาจากข้อมูลมากน้อยเพียงใด

ค่าสถิติประโยชน์
ค่าล่าสุดดูอุณหภูมิที่อ่านได้ล่าสุด
ค่าเฉลี่ยดูระดับอุณหภูมิโดยรวมของช่วง
ค่าต่ำสุดดูอุณหภูมิต่ำสุดที่ตรวจวัดได้ในช่วง
ค่าสูงสุดดูอุณหภูมิสูงสุดที่ตรวจวัดได้ในช่วง
จำนวนตัวอย่างที่ใช้ได้ตรวจสอบความครบถ้วนของข้อมูล
จำนวนข้อผิดพลาดประกอบการตรวจสอบเซ็นเซอร์หรือการอ่านข้อมูล

ผลต่างอุณหภูมิคำนวณจาก

ΔT = อุณหภูมิภายในกล่อง − อุณหภูมิภายนอกกล่อง

ตัวอย่างเชิงอธิบาย หากค่าเฉลี่ยภายในเท่ากับ 35 °C และภายนอกเท่ากับ 32 °C จะได้ ΔT เท่ากับ 3 °C หมายถึงภายในกล่องอุ่นกว่าภายนอก 3 °C ตัวเลขนี้เป็นเพียงตัวอย่าง ไม่ใช่ผลตรวจวัดของโครงการ

การเปรียบเทียบต้องใช้ช่วงเวลาเดียวกันและชนิดสถิติเดียวกัน เช่น ค่าเฉลี่ยเทียบค่าเฉลี่ย เพื่อให้ความหมายสอดคล้องกัน

9. เหตุผลที่ศึกษาดาวเทียมร่วมกับอุณหภูมิ

การบันทึกข้อมูลทั้งสองส่วนในเวลาเดียวกันช่วยให้ตรวจสอบได้ว่า เมื่อสภาพอุณหภูมิเปลี่ยน การรับสัญญาณและสถานะของเครื่องรับเปลี่ยนตามหรือไม่

คำถามที่สามารถนำข้อมูลไปศึกษาได้ เช่น

  • ภายในกล่องร้อนกว่าภายนอกมากที่สุดในช่วงใด?
  • ช่วงที่อุณหภูมิภายในเพิ่มขึ้น การรับสัญญาณยังต่อเนื่องหรือไม่?
  • จำนวนดาวเทียมและระดับสัญญาณมีรูปแบบแตกต่างกันระหว่างช่วงเวลาหรือไม่?
  • ช่วงที่ข้อมูลขาดหายสัมพันธ์กับการเชื่อมต่อเครือข่าย การรีสตาร์ต หรือสภาพอุณหภูมิหรือไม่?
  • ดาวเทียมในทิศทางใดมีระดับสัญญาณลดลงซ้ำ ๆ และสัมพันธ์กับสภาพรอบจุดติดตั้งหรือไม่?

อย่างไรก็ตาม โครงการนี้ไม่ได้ควบคุมทุกปัจจัยแวดล้อม การพบแนวโน้มร่วมกันจึงเป็นข้อมูลสำหรับตั้งข้อสังเกตและวิเคราะห์ต่อ ไม่ใช่หลักฐานยืนยันว่าอุณหภูมิเป็นสาเหตุโดยตรงของการเปลี่ยนแปลงสัญญาณ

10. การอ่านค่าสถิติอย่างเหมาะสม

ค่าเฉลี่ยช่วยสรุปภาพรวม แต่สามารถซ่อนเหตุการณ์ระยะสั้นได้ จึงควรดูร่วมกับค่าต่ำสุด ค่าสูงสุด และจำนวนตัวอย่าง

สำหรับระดับสัญญาณ ส่วนเบี่ยงเบนมาตรฐานใช้บอกการกระจายของค่าภายในช่วงตรวจวัด

  • ค่าต่ำแสดงว่าตัวอย่างในช่วงนั้นอยู่ใกล้ค่าเฉลี่ยมากกว่า
  • ค่าสูงแสดงว่าระดับสัญญาณในช่วงนั้นเปลี่ยนแปลงมากกว่า

ส่วนเบี่ยงเบนมาตรฐานต่ำไม่ได้แปลว่าสัญญาณดีเสมอไป เพราะสัญญาณอ่อนที่คงที่ก็อาจมีค่านี้ต่ำได้ จึงต้องดูระดับเฉลี่ยประกอบด้วย

ช่วงที่มีตัวอย่างน้อยควรตีความอย่างระมัดระวัง เนื่องจากอาจเป็นตัวแทนของช่วงเวลาได้ไม่ครบเท่ากับช่วงที่มีข้อมูลต่อเนื่อง

11. การแสดงผลบน Dashboard

ภาพรวมระบบ

แสดงอุปกรณ์ที่เลือก สถานะออนไลน์ เวลารับข้อมูลล่าสุด และผลตรวจวัดล่าสุด เพื่อให้ตรวจสอบการทำงานได้รวดเร็ว

สถานะออนไลน์และสถานะ Fix เป็นคนละเรื่องกัน อุปกรณ์อาจเชื่อมต่ออินเทอร์เน็ตได้ตามปกติ แต่ยังไม่มีตำแหน่ง GNSS ที่ใช้ได้

กราฟตามเวลา

ใช้ดูแนวโน้มอุณหภูมิและข้อมูล GNSS รวมถึงเปรียบเทียบช่วงเวลาที่เกิดการเปลี่ยนแปลง โดยควรตรวจสอบช่วงข้อมูลขาดหายก่อนตีความกราฟ

แผนภาพดาวเทียม 2 มิติและ 3 มิติ

Skyplot แสดงการกระจายตัวของดาวเทียมตามมุมทิศและมุมเงยจากจุดรับสัญญาณ ช่วยให้เห็นว่าดาวเทียมอยู่บริเวณใดของท้องฟ้า

ภาพนี้ไม่ได้แสดงระยะห่างจริง ความสูงวงโคจร หรือขนาดดาวเทียมตามมาตราส่วน

ตารางและสถิติย้อนหลัง

ใช้ตรวจสอบรายละเอียดรายช่วง สรุปรายวัน และเปรียบเทียบระหว่างวัน เพื่อดูแนวโน้มและความต่อเนื่องของข้อมูล

การส่งออกข้อมูล

ข้อมูลสามารถนำไปใช้ต่อในรูปแบบ CSV หรือ Excel สำหรับสร้างกราฟเพิ่มเติม คำนวณสถิติ และจัดทำรายงานการทดลอง

12. สถานะเครือข่ายและสุขภาพอุปกรณ์

ข้อมูลสถานะช่วยแยกปัญหาที่เกิดจากการรับสัญญาณออกจากปัญหาของบอร์ดหรือเครือข่าย เช่น

ข้อมูลใช้ตรวจสอบ
เวลารับข้อมูลล่าสุดความต่อเนื่องของการส่งข้อมูล
Wi-Fi RSSIระดับสัญญาณเครือข่าย Wi-Fi
Uptimeระยะเวลาที่บอร์ดทำงานนับจากการเริ่มระบบ
หน่วยความจำที่เหลือสภาพทรัพยากรของอุปกรณ์
จำนวนรายการรอส่งข้อมูลที่ยังไม่ได้รับการยืนยันจากเซิร์ฟเวอร์
ข้อผิดพลาดในการส่งปัญหาระหว่างอุปกรณ์ เครือข่าย และ API

Wi-Fi RSSI มีหน่วย dBm ส่วน C/N₀ ของ GNSS มีหน่วย dB-Hz ทั้งสองค่าอธิบายคนละระบบและไม่ควรนำตัวเลขมาเปรียบเทียบกันโดยตรง

13. การจัดเก็บและการรับมือเมื่อเครือข่ายขัดข้อง

เมื่อสรุปช่วงตรวจวัดเสร็จ ระบบบันทึกข้อมูลลงพื้นที่จัดเก็บภายในบอร์ดก่อนส่ง หากเครือข่ายไม่พร้อมสามารถเก็บรายการไว้รอส่งใหม่ได้ตามพื้นที่ที่เหลือ

ระบบใช้รหัสรายการเพื่อช่วยป้องกันข้อมูลซ้ำเมื่อส่งรายการเดิมอีกครั้ง และแยกงานส่งข้อมูลออกจากงานอ่านเซ็นเซอร์ เพื่อลดผลกระทบจากการรอเครือข่ายต่อการเก็บข้อมูล

อย่างไรก็ตาม พื้นที่จัดเก็บมีขนาดจำกัด จึงไม่ได้รับประกันว่าจะรองรับการขาดการเชื่อมต่อได้ไม่จำกัดเวลา และหากไฟดับกลางช่วง ข้อมูลช่วงที่ยังสรุปไม่เสร็จอาจสูญหายได้

ค่าที่อ่านไม่ได้หรือไม่ผ่านการตรวจสอบจะระบุว่าไม่มีข้อมูล แทนการใช้ศูนย์เป็นค่าตรวจวัด เพื่อไม่ให้เข้าใจผิดว่าอุณหภูมิเท่ากับ 0 °C หรือพิกัดอยู่ที่ละติจูด 0 และลองจิจูด 0

14. แนวทางตรวจสอบผลการทดลอง

การตรวจสอบผลควรเริ่มจากความครบถ้วนของข้อมูล ก่อนวิเคราะห์ความสัมพันธ์ระหว่างตัวแปร

  1. ตรวจสอบช่วงเริ่มต้นและสิ้นสุดการทดลอง รวมถึงเขตเวลาที่ใช้แสดงผล
  2. เปรียบเทียบจำนวนช่วงข้อมูลที่ได้รับกับจำนวนช่วงตามแผน
  3. ตรวจสอบจำนวนตัวอย่างอุณหภูมิและ GNSS ที่ใช้ได้ในแต่ละช่วง
  4. ตรวจสอบช่วงที่ไม่มี Fix หรือไม่มีข้อมูลเซ็นเซอร์
  5. พิจารณาจำนวนดาวเทียม C/N₀ และ DOP ร่วมกัน
  6. เปรียบเทียบอุณหภูมิภายในและภายนอกในช่วงเดียวกัน
  7. ตรวจสอบว่าการเปลี่ยนแปลงอาจเกี่ยวข้องกับการรีสตาร์ต เครือข่าย หรือสภาพจุดติดตั้งหรือไม่

หากรายงานความครบถ้วนของช่วงข้อมูล สามารถคำนวณได้จาก

ความครบถ้วน (%) = จำนวนช่วงข้อมูลที่ได้รับจริง ÷ จำนวนช่วงตามแผน × 100

ทั้งนี้ การมีรายการครบทุกช่วงไม่ได้แปลว่าทุกเซ็นเซอร์มีข้อมูลสมบูรณ์ในทุกรายการ จึงต้องตรวจสอบคุณภาพข้อมูลภายในช่วงด้วย

15. ขอบเขตและข้อจำกัดในการตีความ

ระบบนี้ออกแบบสำหรับศึกษาสภาพการรับสัญญาณและการทำงาน ณ จุดติดตั้ง โดยมีขอบเขตสำคัญดังนี้

  • การติดตามดาวเทียมเป็นการติดตามมุมทิศและมุมเงย ไม่ใช่การวัดวงโคจรจริง
  • จำนวนดาวเทียมมากไม่ได้รับประกันว่าตำแหน่งจะแม่นยำ หากสัญญาณหรือเรขาคณิตไม่เหมาะสม
  • ค่า C/N₀ และ DOP เป็นข้อมูลประกอบการประเมิน ไม่ใช่ผลวัดความคลาดเคลื่อนตำแหน่งโดยตรง
  • การหาความคลาดเคลื่อนเป็นเมตรต้องเปรียบเทียบกับตำแหน่งอ้างอิงที่ทราบแน่นอน
  • อุณหภูมิสะท้อนสภาพบริเวณหัววัด และขึ้นอยู่กับวิธีติดตั้ง
  • ความสัมพันธ์ระหว่างอุณหภูมิกับสัญญาณยังไม่ยืนยันเหตุและผล
  • ผลจากเครื่องรับหนึ่งตัวและจุดติดตั้งหนึ่งแห่งไม่ควรใช้แทนสภาพการรับสัญญาณของทุกพื้นที่
  • ข้อมูลสรุปทุก 5 นาทีอาจไม่แสดงรายละเอียดของเหตุการณ์สั้น ๆ ได้ทั้งหมด

16. ประโยชน์ที่คาดว่าจะได้รับ

โครงการช่วยให้มีข้อมูลการรับสัญญาณ GNSS และอุณหภูมิที่จัดเก็บอย่างเป็นระบบ สามารถตรวจสอบย้อนกลับและเปรียบเทียบตามเวลาได้ แทนการอาศัยการสังเกตค่าขณะใดขณะหนึ่งเพียงอย่างเดียว

ผู้ใช้งานสามารถนำข้อมูลไปประกอบการประเมินตำแหน่งติดตั้งเสาอากาศ สังเกตทิศทางที่อาจมีสิ่งกีดขวาง ตรวจสอบความร้อนภายในกล่อง และติดตามความต่อเนื่องของระบบ รวมถึงใช้เป็นข้อมูลสำหรับการเรียนรู้ด้าน GNSS เซ็นเซอร์ ระบบสมองกลฝังตัว เครือข่าย ฐานข้อมูล และการแสดงผลบนเว็บไซต์

Dashboard จึงทำหน้าที่เป็นพื้นที่รวบรวมทั้งผลตรวจวัดและบริบทการทำงาน เพื่อให้การวิเคราะห์ตั้งอยู่บนข้อมูลที่ได้รับจริง พร้อมเห็นข้อจำกัดของข้อมูลแต่ละช่วงอย่างชัดเจน

ค่า Data สถิติรายวัน — เลือกวันที่จากแถบกรองด้านบน แล้วกด Apply

ข้อมูลแบบหน้าภาพรวม (เปรียบเทียบวัน A/B — แสดงหลังกด เปรียบเทียบ)

Latest measurement

Constellation summary (วัน A vs B)

Temperature อุณหภูมิรายวัน (วัน A vs B)

Data completeness (วัน A vs B)

Device health

Recent measurements

API activity

ค่า Data เปรียบเทียบ 2 วัน

เลือกวัน A กับ B แล้วกด เปรียบเทียบ เพื่อดูสรุปและกราฟรายชั่วโมง (% fix = ตำแหน่งสำเร็จ/ทั้งหมด)

ค่า Data เริ่มต้นจนถึงปัจจุบัน

ข้อมูลตรวจวัดทั้งหมดของเครื่อง … ตั้งแต่ช่วงแรกสุดจนถึงข้อมูลล่าสุด — ค่าต่าง ๆ คำนวนจากฐานข้อมูลจริงทั้งช่วง (ไม่จำกัดแค่ 24 ชั่วโมงล่าสุด)

ตารางข้อมูลดิบ (ค่าทีละรายการอย่างละเอียด)

เรียงจากช่วงแรกสุด → ปัจจุบัน

สรุปภาพรวมทั้งช่วง (all-time)

กราฟแสดงค่าทั้งหมด (all-time charts)

ค่าเฉลี่ยรายชั่วโมงคำนวณจากข้อมูลจริงทั้งช่วง (เริ่มต้น → ปัจจุบัน); internal = เส้นทึบ · external = เส้นประ
ดาวเทียมเฉลี่ยรายชั่วโมง visible (ทึบ) · used (ประ)
HDOP เฉลี่ยรายชั่วโมง ค่าต่ำ = สัญญาณดี
อุณหภูมิภายใน–ภายนอก (°C) ทุก measurement · ประ = external
จำนวนข้อมูลต่อวัน daily

รายละเอียดตามวัน (daily breakdown)

Satellite skyplot (ล่าสุด) — 2D + ตารางดาวเทียม

snapshot เดียวจาก measurement ล่าสุด (ดูแบบ 3D/แอนิเมชันได้ในหัวข้อ ภาพรวม)
2D Skyplot (Azimuth–Elevation)
Azimuth 0°=N · 90°=E · 180°=S · 270°=W · radius = 90 − elevation

3D Sky Hemisphere + Satellite Globe (3D animation)

แสดงค่าตามสถานะระบบ GNSS: GNSS (…) — ONLINE=ใช้ข้อมูลล่าสุด · WARNING/OFFLINE=แสดงข้อมูลสมบูรณ์ล่าสุดพร้อมข้อความเตือน
3D Sky Hemisphere
Satellite Globe (3D animation)
กำลังโหลดข้อมูลดาวเทียม…
📍 GNSS Receiver · —
แสดงทิศทางดาวเทียมจากเครื่องรับ ไม่ใช่วงโคจรหรือระยะจริง · เส้นทางย้อนหลัง 30 นาที
● ≥40 ดีมาก● 30–<40 ดี● 20–<30 ปานกลาง● <20 อ่อน● ไม่ทราบ C/N0
คลิกดาวเทียมเพื่อดูรายละเอียด
3D Hemisphere: ลากหมุน (orbit) · scroll ซูม · hover/คลิกดูค่าดาวเทียม · N=+Y E=+X Zenith=+Z · Globe: ลูกโลกเดียวกับหัวข้อภาพรวม ลากเพื่อหมุน ล้อเมาส์หรือสองนิ้วเพื่อซูม · เส้นทางย้อนหลัง 30 นาที · ข้อมูลตามสถานะระบบ GNSS เช่นเดียวกับ skyplot

การวิเคราะห์ดาวเทียม (Satellite analysis) — X–Y

ใช้ช่วงวันที่เดียวกับแถบกรองด้านบน (สถิติรายวัน) — กด วิเคราะห์ เพื่อโหลด/กรองใหม่
Elevation vs Signal Quality X=Elevation (°) · Y=Signal (…)
Azimuth vs Signal Quality X=Azimuth (°) 0–360 · Y=Signal
Satellite Elevation Over Time Y=Elevation (°)
Satellite Azimuth Over Time Y=Azimuth (°) · unwrap 359°→1°
Satellite Signal Quality Over Time Y=Signal (…)
Satellite Movement X–Y r=90−el · N=+Y · E=+X · equal aspect
X–Y ใช้ projection ร่วมกับ 2D Skyplot (r = 90 − elevation) · เส้นจะ break เมื่อ missing interval (>1.5× interval) ห้ามตีความว่า วัดต่อเนื่อง · Correlation ≠ Causation

ข้อมูลแบบหน้าภาพรวม (สถานะและค่าล่าสุด)

Latest measurement

Constellation summary

Temperature (last 24h)

Data completeness

Device health

Recent measurements

API activity

ข้อมูล Credentials (API — Arduino/ESP32)

API_KEYe312439187c981d517487bb6cd40ed3b0eeb6d7e18155dce48a10d666b36d4ff
API_URLhttps://project12569.theeeiot.com/EE67172310228/api/v1/gnss.php

Setting and Tester การแจ้งเตือนอัตโนมัติ LINE & Telegram

ตั้งค่าช่องทางแจ้งเตือนการทำงานของระบบ (LINE / Telegram) และทดสอบการเชื่อมต่อ — ค่า credential เก็บฝั่ง server เท่านั้น

การตั้งค่าแจ้งเตือน (LINE & Telegram)

ติ๊กเลือกช่องทางที่ต้องการเปิดใช้งานจริงแล้วกดบันทึก — ใช้แจ้งเตือนจริงทันที (ไม่ต้องอัปโหลด credential)
สถานะแยก Enabled (เปิดใช้) กับ Configured (มี credential) — 🟢 เปิดใช้งาน · ⚪ ปิดใช้งาน

กรอกค่า LINE / Telegram ที่ใช้งานจริง (อัปโหลดสู่ server)

กรอกครบ 4 ช่องแล้วกด อัปโหลด credentials + บันทึกการตั้งค่า — ระบบเก็บค่าล่าสุดไว้ใน server (DB) เพื่อใช้แบบอัตโนมัติถาวร; ช่องที่เว้นว่าง = เก็บค่าเดิมไว้; ปุ่ม ล้าง = คืนค่าไปใช้ config/notifications.php — ค่าเป็น secret ฝั่ง server ไม่แสดงค่าเต็มกลับมา

ขั้นตอนการตั้งค่าทั้งหมด (ละเอียด)

ตัวอย่างการแจ้งเตือน LINE & Telegram

ตัวอย่างการเชื่อมต่อแจ้งเตือน LINE — ภาพที่ 1
ตัวอย่างการเชื่อมต่อแจ้งเตือน LINE — ภาพที่ 1
ตัวอย่างการเชื่อมต่อแจ้งเตือน Telegram — ภาพที่ 2
ตัวอย่างการเชื่อมต่อแจ้งเตือน Telegram — ภาพที่ 2
ตัวอย่างการแจ้งเตือน LINE สถานะ GNSS01 (OFFLINE) — ภาพที่ 3
ตัวอย่างการแจ้งเตือน LINE สถานะ GNSS01 (OFFLINE) — ภาพที่ 3
ตัวอย่างการแจ้งเตือน Telegram สถานะ GNSS01 (OFFLINE) — ภาพที่ 4
ตัวอย่างการแจ้งเตือน Telegram สถานะ GNSS01 (OFFLINE) — ภาพที่ 4
ตัวอย่างการแจ้งเตือน LINE สถานะ GNSS01 (ONLINE) — ภาพที่ 5
ตัวอย่างการแจ้งเตือน LINE สถานะ GNSS01 (ONLINE) — ภาพที่ 5
ตัวอย่างการแจ้งเตือน Telegram สถานะ GNSS01 (ONLINE) — ภาพที่ 6
ตัวอย่างการแจ้งเตือน Telegram สถานะ GNSS01 (ONLINE) — ภาพที่ 6

ระบบสั่ง Run การตรวจสอบสถานะระบบและแจ้งเตือนอัตโนมัติ LINE & Telegram — cron-job.org + Windows Task Scheduler + CLI

ระบบสั่งรันการตรวจสถานะและ แจ้งเตือนอัตโนมัติ LINE & Telegram (ส่วน 6b. Setting and Tester การแจ้งเตือนอัตโนมัติ LINE & Telegram) ให้ทำงานตลอด 24 ชั่วโมงโดยไม่ต้องเปิดหน้านี้ทิ้งไว้ — ใช้ตัวกระตุ้น 3 ชั้นที่ทำงานร่วมกันแต่ ไม่ส่งซ้ำ เพราะทุกชั้นเรียก engine ตรวจสถานะตัวเดียวกัน

การตั้งค่า (cron-job.org — ฟรี ไม่ต้องเปิดหน้า Dashboard ค้างไว้ตลอดบนคอมพิวเตอร์)

บริการจ็อบตามเวลาแบบ free tier — เรียก endpoint ชั้น C ของระบบจาก cloud ทุก 5 นาที
Job nameGNSS-AlertCheck
Method / ทุกGET · 5 นาที (300 วินาที)
URL ที่เรียก (พร้อม key)https://project12569.theeeiot.com/EE6717…ert-cron.php(ใช้ค่าเริ่มต้นอัตโนมัติ)
แก้ URL ที่ใช้จริง (กรอกค่าใหม่ หรือกรอกเปล่า = ใช้ค่าเริ่มต้น)
Login เพื่อจัดการcron-job.org (บัญชีที่ตั้งไว้ตอนสมัคร) → Jobs → Dashboard
Key ที่ใช้ไม่ต้องใช้ key อีกต่อไป (X-Admin-Key ถูกถอดออก) — ดึง URL เต็มจากช่องบนสุด (ถ้า URL เดิมมี ?key=… ให้ลบส่วนนั้นทิ้งได้เลย)

ขั้นตอนการตั้งค่าทั้งหมด (ละเอียด)

สถานะการทำงานของระบบสั่ง Run (ข้อมูลล่าสุด)

อ่านจาก api/v1/scheduler-status.php — อัปเดตเมื่อเปิดหน้านี้หรือกดปุ่มรีเฟรช
กำลังอ่านข้อมูล…

โครงสร้างการทำงานของระบบสั่ง Run (3 ระดับ)

ชั้นตัวรันวิธีทำงานส่งซ้ำ?
AWeb autopilot (หน้าเว็บที่เปิดอยู่)ทุกครั้งที่หน้านี้โหลดข้อมูล จะเรียก alert-check.php อัตโนมัติ (ไม่ต้องใช้ key — เปิดหน้าไว้ก็แจ้งเตือน)ไม่ — กันด้วย __AUTOPILOT__ + cooldown
BWindows Task Scheduler + CLIเครื่อง PC ที่เปิดตลอด ใช้ php alert-check-cli.php ทุก 5 นาที (Task GNSS-AlertCheck)ไม่ — ใช้ marker ตัวเดียวกับชั้น A
Ccron-job.org (cloud ฟรี)เรียก api/v1/alert-cron.php จาก cloud ทุก 5 นาที (ไม่ต้องใช้ key)ไม่ — ใช้ engine ตัวเดียวกัน + GET_LOCK 60s
การส่งจริงทั้งหมดเกิดขึ้นใน includes/alert-engine.php เดียวกัน — ส่งเฉพาะเมื่อ สถานะเปลี่ยน (ONLINE/WARNING/OFFLINE/NO FIX/temp error) อยู่ภายใต้ cooldown 900 วินาที จึงไม่มีทางแจ้งซ้ำแม้มีหลายตัวกระตุ้น

ผลลัพธ์ที่ส่งถึง LINE & Telegram (ตัวอย่างจริง)

  • 05:00 UTC cron-job.org ตรวจพบบอร์ด ONLINE แต่ไม่มีสัญญาณดาวเทียม → ระบบส่ง STATUS:ONLINE + GNSS_NO_FIX ไป LINE & Telegram อัตโนมัติ (ไม่มีคน)
  • 05:01 UTC ตัวกระตุ้นชั้น A (web autopilot) พบบอร์ด OFFLINE หลังขาดข้อมูล >10 นาที → ส่ง STATUS:OFFLINE + DEVICE_OFFLINE ไป LINE & Telegram ทันที
  • อัปโหลด ESP32 ที่เข้ามาในช่วงเวลานั้นถูก throttle 60s → ไม่ส่งซ้ำ
  • FIX_RECOVERED / TEMP_INTERNAL_ERROR ก็ถูกส่งด้วยวิธีเดียวกัน (ทดสอบเรียบร้อยทุกกรณี)

การตรวจสอบด้วยตัวเอง (SQL — terminal)

คิวรีทั้ง 3 ด้านล่าง ต้องมีผลลัพธ์แถวล่าสุดใกล้เคียงเวลาปัจจุบัน (รอบทุก ~5 นาที)
-- 1) รอบล่าสุดที่ cron-job.org เรียก (ทุก ~5 นาที, HTTP 200)
SELECT id, http_status, source_ip, user_agent, created_at
FROM api_request_logs
WHERE endpoint = '/api/v1/alert-cron'
ORDER BY id DESC LIMIT 8;

-- 2) สถานะล่าสุดที่ระบบส่งไป LINE/Telegram จริง (status='SENT')
SELECT id, alert_type, status, channel, created_at
FROM alert_events
WHERE status = 'SENT'
ORDER BY id DESC LIMIT 6;

-- 3) รอบล่าสุดของ web autopilot (ชั้น A และ B)
SELECT id, alert_type, created_at
FROM alert_events
WHERE alert_type = '__AUTOPILOT__'
ORDER BY id DESC LIMIT 5;
ถ้ายัง ไม่ได้สมัคร cron-job.org: ตั้ง Task Scheduler + CLI ตาม web/alert-cron/ (ใช้งานบน Windows ได้ทันที) — ส่วนหัวข้อทั้งหมดอยู่ในเอกสาร ส่วนที่ 5.9

การตั้งค่าทั่วไป

ชื่อที่ใช้ในแถบ Site (filterbar) — เก็บใน localStorage ต่อเบราว์เซอร์นี้
เฉพาะการแสดงผล — server เก็บ timestamp เป็น UTC เสมอ (ISO8601 …Z)
ยิ่งถี่ ยิ่งใช้โควตา GET rate limit (120/นาที/IP) — 15s ≈ 4 requests/นาที/แท็บ

ข้อมูลทั่วไป (api-health)

ค่าที่บันทึกในเครื่อง (localStorage: gnss_prefs)

device · tz · theme · interval · site · date · gs (graph settings)

ปุ่ม Clear local prefs ลบ key นี้ทั้งหมดแล้วโหลดหน้าใหม่กลับค่าเริ่มต้น (GNSS01, Bangkok +07, 30s, site-1)

ข้อมูลระบบและคู่มือใช้งาน

หน้านี้คือคู่มือกลางอัปเดตล่าสุดของทั้งระบบ — รวมทุกอย่างที่แก้ไขบน Dashboard: ไม่ต้องใช้คีย์ Admin (X-Admin-Key) อีกต่อไป, ตั้งค่า LINE/Telegram และ URL cron-job.org ได้จากหน้าเว็บ (DB override), ระบบสั่ง Run 3 ชั้นทำงาน 24 ชม. — พร้อมวิธีอ่านค่าต่าง ๆ, เรียก API แบบ GET/POST และส่ง/ทดสอบการแจ้งเตือนจริง
ระบบหลักทั้งหมด (ESP32 + LINE/Telegram + cron-job.org + web autopilot + Task Scheduler) ทำงานอยู่แล้วโดยไม่ต้องแก้โค้ด — หน้านี้เป็นเพียงคู่มือและสารบบกลางของระบบ

คู่มือข้อมูลระบบและคู่มือใช้งาน

คุณค่าที่ Dashboard แสดง + หน่วยการวัด

ตัวชี้วัดหน่วยจาก
อุณหภูมิภายใน (Internal)°C (avg / min / max ต่อรอบ)DS18B20 ตัวที่ 1
อุณหภูมิภายนอก (External)°C (avg / min / max ต่อรอบ)DS18B20 ตัวที่ 2
Delta อุณหภูมิ (int − ext)°Cคำนวณจากทั้งคู่
สถานะตำแหน่ง (GPS fix)Fixed / No fixGNSS module
ดาวเทียมที่รับได้ / ใช้คำนวณดวง (visible / used)GNSS module
ความแรงสัญญาณ C/N₀dB-HzGNSS module ต่อดาวเทียม
HDOP / VDOP / PDOPไม่มีหน่วย (เป็นอัตราส่วน)GNSS module
ละติจูด / ลองจิจูดองศาทศนิยม (°)GNSS module
ระดับความสูงเมตร (m)GNSS module
มุม elevation / azimuth ดาวเทียม° / ° (0–360)GNSS module
ความแรง Wi-Fi RSSIdBmESP32 Wi-Fi
หน่วยความจำ heap อิสระkBESP32
Uptime ต่อเนื่องนาทีESP32
ความครบถ้วนข้อมูล (completeness)% / จำนวนรอบคำนวณจากตารางรอบ 5 นาที
ค่าที่อ่านไม่ได้จะแสดงเป็น “–” (ไม่มีข้อมูล) ไม่ใช่ 0 เพื่อไม่ให้เข้าใจผิดว่าอุณหภูมิ 0 °C หรือพิกัด 0,0

ความถี่การวัดและส่งข้อมูล

ข้อมูลอัตรา
GNSS (ตำแหน่ง/ดาวเทียม) อ่านล่วงหน้าสะสมประมาณ 1 ครั้งต่อวินาที
อุณหภูมิภายใน (DS18B20 #1)ทุก 10 วินาที
อุณหภูมิภายนอก (DS18B20 #2)ทุก 10 วินาที
สรุปและยิงขึ้น server (measurement)ทุก 300 วินาที (5 นาที)
Dashboard รีเฟรชหน้าจอทุก 30 วินาที (ค่าเริ่มต้น; เลือก 15s/30s/60s/5m)
cron-job.org / Windows Task Scheduler ตรวจสถานะ + แจ้งเตือนทุก 5 นาที — ส่งจริงเฉพาะเมื่อสถานะเปลี่ยน (กันซ้ำ cooldown 900s)
Web autopilot (หน้า Dashboard ที่เปิดอยู่)ทุกครั้งที่หน้ารีเฟรช (ใช้ marker __AUTOPILOT__ กันซ้ำ)
Dashboard ไม่ถ่ายทอดค่าทุกวินาที — แสดงผลตามรอบสรุป 5 นาทีที่อุปกรณ์ส่งและรอบรีเฟรชของหน้าเว็บ ลองเปลี่ยนช่วงรีเฟรชได้ที่ปุ่มมุมซ้ายล่างหรือหน้า ตั้งค่าระบบ

รูปร่างกราฟแต่ละรูปแบบ (อ่านอย่างไร)

กราฟลักษณะ / ข้อมูลที่วาดอยู่หน้า
Skyplotกราฟขั้ว (polar) ตำแหน่งดาวเทียมบนท้องฟ้า — มุม elevation ใช้รัศมี (กลาง = เหนือศีรษะ), มุม azimuth ใช้ตำแหน่งรอบวง, ขนาดจุด/สี = ความแรงสัญญาณ, มี 2D + 3Dภาพรวม
Globe 3Dทรงกลมหมุน 3 มิติ ตำแหน่งดาวเทียมและเส้นขอบฟ้าภาพรวม
จำนวนข้อมูลรายชั่วโมงกราฟแท่ง (bar) นับจำนวนรอบต่อชั่วโมงกราฟวิเคราะห์
อุณหภูมิรายวันเส้น (line) min–avg–max °C รายวัน (3 เส้น = 3 ค่าคงที่)กราฟวิเคราะห์ / ค่า Data สถิติรายวัน
อุณหภูมิภายใน–ภายนอกเส้น 2 เส้น — ภายในทึบ・ภายนอกประ, แกน Y = °C, เวลาตาม Xกราฟวิเคราะห์ / ค่า Data เต็ม
Delta อุณหภูมิเส้นค่าต่าง (internal − external) °Cกราฟวิเคราะห์
ความแรงสัญญาณรายกลุ่มดาวเส้น/จุด (line/scatter) C/N₀ (dB-Hz) แยกด้วยสีต่อกลุ่มดาว GPS/GLONASS/GALILEO/BEIDOUกราฟวิเคราะห์
heap / WiFiเส้น — heap (kB) และ RSSI (dBm) + uptime (นาที)กราฟวิเคราะห์
เปรียบเทียบ 2 วันเส้นซ้อน 2 ชุด (วันที่ ก vs ข) สำหรับอุณหภูมิ ความครบถ้วน กลุ่มดาวค่า Data เปรียบเทียบ 2 วัน
ความครบถ้วน (completeness)แท่ง/เส้น % ข้อมูลครบตามรอบ 5 นาที + ช่องว่าง (gap) เฉพาะช่วงกราฟวิเคราะห์ / เปรียบเทียบ
ปุ่ม ⚙ (Graph Settings) มุมซ้ายล่างปรับเส้นหนา/พื้นที่ใต้เส้น/แสดงจุด/สีของทุกกราฟได้ทันที โดยไม่ต้องแก้โค้ด

รูปแบบการเรียก API — GET (อ่านข้อมูล)

Base URL: https://project12569.theeeiot.com/EE67172310228/api/v1
endpoint (GET)พารามิเตอร์ที่ใช้
latest.php— (ค่าล่าสุดของ device)
measurements.phplimit, page, start_time, end_time
temperature.phpstart_time, end_time
satellites.phpstart_time, end_time, constellation, prn, points
skyplot.phptimestamp, constellation
satellite-track.phpconstellation, prn, start_time, end_time
statistics.phpstart_time, end_time
constellations.phpstart_time, end_time
system-health.phpstart_time, end_time
data-completeness.phpstart_time, end_time, interval (≥30s)
devices.phpinclude
api-health.php— (สถานะระบบ)
api-logs.phpmethod, http_status, endpoint, limit, page
notifications.php— (การตั้งค่าแจ้งเตือน + ที่มา credential แบบ mask)
scheduler-status.php— (สถานะระบบสั่ง Run: last run / healthy / รอบล่าสุด / ผลส่ง / URL ที่ใช้)
scheduler-config.php— (URL cron ที่ใช้จริง + ต้นทาง db/default)
alert-check.phpdevice — รันตรวจสถานะ + ส่งแจ้งเตือนทันที (ไม่มี key)
export-csv.php / export-excel.phptype, start_time, end_time, constellation, prn
ทุก GET ใช้ ?device=GNSS01 ต่อท้าย URL เสมอ และพารามิเตอร์เวลาใช้ ISO8601 UTC เช่น 2026-09-11T05:15:00Z — endpoints ส่วนแจ้งเตือน/สั่ง Run (notifications / scheduler-status / scheduler-config / alert-check) ไม่ต้องใช้ key

รูปแบบการเรียก API — POST (ส่งข้อมูลจากอุปกรณ์ + แจ้งเตือน)

endpointวิธีใช้
gnss.phpอัปโหลด measurement จาก ESP32 — ต้องมี header Content-Type: application/json + X-API-Key: <device key>
notifications.phpบันทึกการเปิด/ปิดช่องทาง + อัปโหลด/ล้าง credential — alerts_enabled, line_enabled, telegram_enabled + 4 ช่องค่า (ส่ง "" = ล้าง)
notify-test.php?channel=line|telegram|allส่งข้อความทดสอบจริงไปยังช่องทาง (ไม่ต้อง key)
status-send.php?device=GNSS01ส่งสถานะปัจจุบันไป LINE + Telegram ทันที (ไม่ต้อง key)

ตัวอย่าง body ของ gnss.php

{
  "uuid": "a1b2c3d4-…-9f10",
  "device": "GNSS01",
  "timestamp": "2026-09-15T04:00:00Z",
  "fix": true,
  "lat": 13.750000, "lon": 100.500000, "alt": 5.2,
  "hdop": 0.8, "vdop": 1.1, "pdop": 1.4,
  "satellites_visible": 12, "satellites_used": 9,
  "satellite_summary": [{ "constellation": "GPS", "prn": 3, "signal_db_hz": 42.5 }],
  "temperature": { "internal_c": 34.2, "external_c": 31.8 },
  "system": { "wifi_rssi_dbm": -52, "free_heap_bytes": 180224,
              "minimum_free_heap_bytes": 150000, "uptime_s": 5400,
              "reboot_count": 1, "wifi_disconnect_count": 0,
              "http_fail_count": 0 },
  "fw_version": "v1.0.3"
}
Response ของ gnss.php: 201 สร้างใหม่ · 200 (duplicate uuid) · 400/401/405/415/422/429 · ตัวกระตุ้นแจ้งเตือนอื่น (notifications / notify-test / status-send / alert-check / alert-cron / scheduler-config) ไม่ต้องใช้ key — Rate limit: POST 60 ครั้ง/นาที/device · GET 120 ครั้ง/นาที/IP (ใน config/security.php)

ทดสอบ GET/POST ด้วยมือ — ใช้ API Tester

เปิดหน้า “API Tester Arduino IDE” (?sec=tester) แล้วทำตามนี้:
  1. Device: GNSS01
  2. API Key: กรอก X-API-Key ของ device (ดูการ์ด “ข้อมูล Credentials (API — Arduino/ESP32)”) — ใช้เฉพาะ POST gnss.php; endpoint อื่นไม่ต้อง key
  3. Tab GET API: เลือก endpoint → กรอกพารามิเตอร์ → กด Send GET request
  4. Tab POST API: วาง JSON ตัวอย่าง → กด Send POST Measurement
  5. อ่านผลในช่อง Response + Request history (ทุกครั้งอัตโนมัติ)
Key ของระบบนี้:
X-API-Key (device)e312439187c981d517487bb6cd40ed3b0eeb6d7e18155dce48a10d666b36d4ff
device key = key ตัวเดียวกับที่ ESP32 ใช้จาก config/device_api_key.txt (สำหรับทดสอบ POST จำลอง) — หน้านี้เปิดออนไลน์ ห้ามแชร์ URL นี้กับใคร · ไม่มีคีย์ X-Admin-Key อีกต่อไป

การจำลองการแจ้งเตือน (alert) ต่าง ๆ

ใช้หน้า “Setting and Tester การแจ้งเตือนอัตโนมัติ LINE & Telegram” (?sec=notify) — ไม่ต้องแก้โค้ดและไม่ต้องใช้ key:
  • ทดสอบช่องทาง: ปุ่ม ทดสอบ LINE / ทดสอบ Telegram / ทดสอบช่องทางที่เปิด ส่งข้อความจริงไปยัง LINE/Telegram
  • แจ้งเตือนสถานะทันที: ปุ่ม แจ้งเตือนสถานะปัจจุบัน ส่งสถานะ GNU (ONLINE/WARNING/OFFLINE) ในขณะนั้น
  • จำลองผ่าน web autopilot: ทุกครั้งที่หน้ารีเฟรช ระบบจะรัน autopilot — สถานะเปลี่ยน OFFLINE / WARNING / ONLINE / NO FIX / temp error จะส่ง LINE+Telegram อัตโนมัติ (กันซ้ำ cooldown 900s)
  • เช็คประวัติจริง: ส่วน “การตรวจสอบด้วยตัวเอง” (?sec=scheduler) มีคำสั่ง SQL ดูตาราง alert_events (status=SENT / __AUTOPILOT__)
ระบบแจ้งเตือน LINE/Telegram + cron-job.org + ตัวตั้งเวลา เป็นของเดิมที่ทำงานอยู่ — การตั้งค่าทั้งหมดย้ายมาอยู่บน Dashboard แล้ว (ดูหัวข้อถัดไป)

การตั้งค่าแจ้งเตือน (LINE & Telegram) — วิธีใช้ (หัวข้อ “การตั้งค่าแจ้งเตือน”)

เดิมเคยต้องพิมพ์คีย์ Admin เพื่อสั่งระบบ — ตอนนี้จัดการทุกอย่างจากหน้าเว็บ โดยไม่มีคีย์ใด ๆ:
รายการวิธีใช้
เปิด/ปิดช่องทางติ๊ก LINE Notification / Telegram Notification แล้วกด บันทึกการเปิดใช้งานการแจ้งเตือน — บันทึกจริงลง DB (notification_settings) ใช้แจ้งเตือนทันที
อัปโหลด credentialกรอกครบ 4 ช่อง (LINE_CHANNEL_ACCESS_TOKEN · LINE_TARGET_ID · TELEGRAM_BOT_TOKEN · TELEGRAM_CHAT_ID) → กด อัปโหลด credentials + บันทึกการตั้งค่า — เก็บลงตาราง notification_credentials (DB override)
ช่องที่เว้นว่างเก็บค่าที่มีอยู่เดิมไว้ (ไม่อัปโหลด/ไม่ล้าง)
ล้างกลับค่า configกด ล้างค่า LINE / ล้างค่า Telegram — ช่องนั้นกลับไปใช้ค่าเริ่มต้นใน config/notifications.php (ส่ง "")
ทดสอบ / ส่งสถานะปุ่ม ทดสอบ LINE / ทดสอบ Telegram / ทดสอบช่องทางที่เปิด / แจ้งเตือนสถานะปัจจุบัน
สถานะที่แสดง🟢 เปิดใช้งาน · ⚪ ปิดใช้งาน — แยก Enabled (เปิดใช้) กับ Configured (มี credential) · ค่าเป็น secret แสดงแบบ mask (หัว…ท้าย) เท่านั้น
ลำดับการใช้ค่า: ค่าที่อัปโหลดจาก Dashboard (DB) ใช้ก่อนเสมอ — ถ้าค่าใน DB ว่าง → ระบบใช้ค่าใน config/notifications.php โดยอัตโนมัติ

ระบบสั่ง Run การตรวจสอบสถานะระบบและแจ้งเตือนอัตโนมัติ — การตั้งค่า & สถานะ (?sec=scheduler)

หน้า “ระบบสั่ง Run” (cron-job.org + Windows Task Scheduler + CLI) — ตั้งค่า URL ที่ cloud เรียกได้จากหน้าเว็บ (DB override) และดูสถานะการทำงานจริงได้ทันที:
URL เริ่มต้นอัตโนมัติ (default)<scheme>://<host> + app_base() + /api/v1/alert-cron.php
URL ที่ใช้จริงตอนนี้https://project12569.theeeiot.com/EE6717…ert-cron.php(ใช้ค่าเริ่มต้นอัตโนมัติ) (จาก scheduler-config.php)
  1. แก้ URL: กรอก URL เต็ม (เช่น จากหน้า cron-job.org — ใส่ key ต่อท้ายได้) ในช่อง “แก้ URL ที่ใช้จริง” → กด บันทึกค่าใหม่ (เก็บในตาราง scheduler_settings)
  2. คืนค่าเริ่มต้น: กด เคลียร์ (ใช้ค่าเริ่มต้น) — ค่าที่กรอกถูกลบ ระบบกลับไปใช้ค่า default อัตโนมัติ
  3. เช็คสถานะ: กด รีเฟรชสถานะ — ดู LAST RUN / AGE / HEALTHY (วงรอบ ≤660s), ตาราง 8 รอบล่าสุด ★ cron-job.org และผลที่ส่ง LINE/TG
ชั้นตัวรันวิธีทำงานส่งซ้ำ?
AWeb autopilot (หน้าเว็บที่เปิดอยู่)ทุกครั้งที่หน้านี้โหลดข้อมูล จะเรียก alert-check.php อัตโนมัติ (ไม่ต้องใช้ key)ไม่ — กันด้วย __AUTOPILOT__ + cooldown
BWindows Task Scheduler + CLIเครื่อง PC ที่เปิดตลอด ใช้ php alert-check-cli.php ทุก 5 นาที (Task GNSS-AlertCheck)ไม่ — ใช้ marker ตัวเดียวกับชั้น A
Ccron-job.org (cloud ฟรี)เรียก api/v1/alert-cron.php ตาม URL ที่ตั้งไว้ด้านบน ทุก 5 นาที (ไม่ต้องใช้ key)ไม่ — ใช้ engine ตัวเดียวกัน + GET_LOCK 60s
การส่งจริงทั้งหมดอยู่ใน includes/alert-engine.php เดียวกัน — ส่งเฉพาะเมื่อสถานะเปลี่ยน (ONLINE/WARNING/OFFLINE/NO FIX/temp error) ภายใต้ cooldown 900 วินาที จึงไม่มีทางแจ้งซ้ำแม้มีหลายตัวกระตุ้น · คู่มือครบทั้งระบบอยู่ใน PDF “ขั้นตอนการตั้งค่าทั้งหมด (ละเอียด)” ที่มาต่อจากหัวข้อ “การตั้งค่า” ด้านบน

ตัวหนังสือและตัวอักษร — อ่านง่าย

  • ฟอนต์ Prompt (Google Fonts) ทั้งหน้า + ฟอนต์ mono สำหรับค่าตัวเลข/code เพื่อแยกแยะข้อมูลชัดเจน
  • การ์ด KPI ใหญ่ อ่านค่าจากระยะไกลได้; ตารางมีหัวตารางชัดเจน; “–” แทนข้อมูลขาด (ไม่ปนกับค่า 0)
  • ธีมพื้นหลังสีเข้มตัดกับสีสัญญาณ (เขียว = ปกติ / เหลือง = เตือน / แดง = ผิดปกติ)
  • ปรับเพิ่ม/ลดขนาดกราฟได้ด้วยปุ่ม ⚙ และหน้าปรับงานตามขนาดจอ (responsive)