FT8 เรียกไม่ติด ทั้งที่ Band เปิด? ก่อนโทษเสา เช็ก DT และเวลาให้ดีก่อน

เห็นสถานี FT8 เต็ม Waterfall แต่เรียกเท่าไรก็ไม่มีใครตอบ ปัญหาอาจไม่ได้อยู่ที่เสาอากาศหรือกำลังส่งเสมอไป บางครั้งเราตกม้าตายกับเรื่องง่ายที่สุดอย่าง “เวลาในคอมพิวเตอร์” บทความนี้จะพาไล่เช็กตั้งแต่ DT, Time Sync, mhz.band/live, PSKReporter ไปจนถึงระบบ TX อย่างเป็นขั้นตอน


เปิด WSJT-X ขึ้นมา บน 20 เมตรมีทั้ง JA, BY, VK หรือบางจังหวะเห็นยุโรปขึ้นเต็ม Band Activity บางสถานีแรง -10 dB บางสถานี -15 dB บางสถานีแรงกว่านั้นอีก

ดูแล้ว Band ก็น่าจะเปิด ลองเรียก…เงียบ

เรียกใหม่… ก็ยังเงียบ

จากเดิมใช้ 20 วัตต์ เริ่มขยับเป็น 40 วัตต์ 50 วัตต์ บางคนไปถึง 80 หรือ 100 วัตต์ แล้วเริ่มมองขึ้นไปที่เสาอากาศ “หรือเสาเรามันไม่ดี?”

ช้าก่อนครับ ก่อนปีนเสา ก่อนเปลี่ยน Coax และก่อนเพิ่มกำลังส่ง มีของง่าย ๆ อย่างหนึ่งที่คนเล่น FT8 พลาดกันได้เสมอ

เวลาในคอมพิวเตอร์ตรงหรือยัง? และตัวเลขเล็ก ๆ ในคอลัมน์ DT กำลังบอกอะไรเราอยู่หรือเปล่า?


รับเขาได้ ไม่ได้แปลว่าเขารับเราได้

นี่เป็นจุดที่ทำให้ FT8 หลอกเราได้ง่ายมาก

เมื่อหน้าจอ WSJT-X Decode สถานีต่าง ๆ ได้เต็มไปหมด เรามักคิดทันทีว่า

  • วิทยุรับได้
  • เสาใช้ได้
  • Band เปิด
  • งั้นถ้าเรียกไป เขาก็น่าจะได้ยินเรา

สามข้อแรกอาจถูก แต่ข้อสุดท้ายยังสรุปไม่ได้ เพราะเส้นทาง

สถานีอื่น → เรา

กับ

เรา → สถานีอื่น

ไม่ได้จำเป็นต้องมีเงื่อนไขเหมือนกันทั้งหมด

นอกจาก Propagation, กำลังส่ง, ประสิทธิภาพเสา, Feedline และ Noise แล้ว Digital Mode อย่าง FT8 ยังมีอีกตัวแปรที่สำคัญมากคือ

Timing


FT8 เป็นโหมดที่ “เวลา” เป็นส่วนหนึ่งของระบบ

FT8 ใช้รอบรับ-ส่งแบบ 15 วินาทีต่อ T/R sequence กล่าวคือสถานีหนึ่งส่งในช่วงเวลาที่กำหนด และอีกสถานีรับในช่วงเวลาที่สอดคล้องกัน ไม่ได้เริ่มส่งเมื่อไรก็ได้แบบ SSB

ด้วยเหตุนี้ นาฬิกาของคอมพิวเตอร์ที่ใช้ WSJT-X จึงต้องอ้างอิงเวลา UTC ได้แม่นพอ

คู่มือ WSJT-X ระบุใน System Requirements และ Pre-QSO Checklist ว่าควรมีวิธี Synchronize นาฬิกาคอมพิวเตอร์กับ UTC ภายในประมาณ ±1 วินาที

นี่คือสาเหตุที่บางครั้ง

Waterfall มีสัญญาณ
WSJT-X ยัง Decode ได้
แต่การ QSO กลับติด ๆ ขัด ๆ หรือเรียกแล้วไม่มีการตอบกลับ

และเราก็เสียเวลาไปตรวจเสา ทั้งที่ต้นเหตุอาจอยู่ที่นาฬิกามุมขวาล่างของ Windows


DT คืออะไร?

ในหน้าต่าง Band Activity ของ WSJT-X เราจะเห็นข้อมูลประมาณนี้

ตัวอย่าง

UTC dB DT Freq Message
120315 -12 +0.1 1050 CQ JA1XYZ PM95

ค่าที่เราสนใจคือ DT

คู่มือ WSJT-X อธิบาย DT ว่าเป็น Timing Offset หน่วยเป็นวินาที และใช้เพื่อวัตถุประสงค์ด้านการวิเคราะห์หรือวินิจฉัย Timing ของสัญญาณที่ Decode ได้

พูดแบบบ้าน ๆ คือ สัญญาณที่เรารับมา เริ่มคลาดจากช่วงเวลาที่โปรแกรมคาดไว้เท่าไร

ตัวอย่าง

DT +0.1

คือ Timing ของสัญญาณนั้นคลาดจาก Reference ที่ WSJT-X ใช้ประมาณ 0.1 วินาที

ถ้าเห็น

+0.8
+0.9
+1.0

ก็แปลว่ามี Timing Offset มากขึ้น แต่มีข้อสำคัญมาก:

อย่าดู DT ของสถานีเดียวแล้วสรุปว่านาฬิกาเราผิด

DT ไม่ใช่มิเตอร์วัด Clock Error ของเครื่องเราโดยตรงแบบ 100%

ถ้าสถานีหนึ่งขึ้น

DT +0.9

แต่สถานีอื่นทั้ง Band อยู่ประมาณ

0.0
+0.1
-0.2

ปัญหาอาจอยู่ที่สถานีแรก ไม่ใช่เรา

ในทางกลับกัน ถ้าเรา Decode หลายสิบสถานีแล้วพบว่าแทบทั้งหมดเอียงไปทางเดียวกัน เช่น

+0.8
+0.9
+1.0
+0.8
+1.1

แบบนี้ควรเริ่มสงสัย Clock ของฝั่งเรา

หลักง่าย ๆ คือ

อย่ามอง DT จุดเดียว ให้มอง Pattern ของหลายสถานี

ถ้ากลุ่มใหญ่กระจุกอยู่ใกล้ 0 ก็ถือเป็นสัญญาณที่ดี

ถ้าทั้งกลุ่มถูกเลื่อนไปด้านเดียวกันอย่างชัดเจน ค่อยไปตรวจ Time Synchronization ของเครื่องเรา


จุดตกม้าตาย: “แต่ผมยัง Decode ได้นี่?”

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

จึงเกิดความรู้สึกว่า “ในเมื่อรับได้ เวลาไม่น่าจะมีปัญหา” แต่ QSO ต้องมีสองทาง

เขา → เรา

และ

เรา → เขา

เมื่อเราส่งออกไป สถานีปลายทางก็ต้อง Synchronize และ Decode Signal ของเรากลับเช่นกัน

เพราะฉะนั้นสถานการณ์แบบนี้

รับได้เยอะ
เรียกหลายสถานี
ไม่มีใครตอบ
DT หลายสถานีเอียงไปทางเดียวกัน

ควรทำให้ Time Sync ขึ้นมาอยู่ในรายชื่อผู้ต้องสงสัยอันดับต้น ๆ ก่อนจะเพิ่มกำลังส่ง


ขั้นที่ 1 — เช็กเวลาคอมพิวเตอร์ก่อน

บน Windows เริ่มจาก

Settings → Time & language → Date & time

ตรวจว่าเปิด Set time automatically

และ Time Zone ถูกต้อง จากนั้น Synchronize เวลาใหม่ก่อนเริ่มใช้งาน FT8

อีกวิธีหนึ่ง เปิด Command Prompt แล้วตรวจสถานะ Windows Time ได้ด้วย

w32tm /query /status

สิ่งที่เราต้องการไม่ใช่แค่ว่า Taskbar แสดง “21:30” เหมือนโทรศัพท์มือถือ แต่ต้องการให้เวลาระดับวินาทีสอดคล้องกับ UTC ด้วย

หมายเหตุสำหรับ WSJT-X รุ่นใหม่

คู่มือ WSJT-X 3.x มีข้อสังเกตสำคัญว่าไม่แนะนำเครื่องมือ SNTP ที่คอยแก้เวลาด้วยการ “กระโดด” Clock เป็นช่วง ๆ ขณะโปรแกรมกำลังทำงาน เพราะ WSJT-X ต้องการเวลาที่เดินต่อเนื่องและสม่ำเสมอ หากต้องแก้ Drift ควรใช้ระบบ Time Synchronization ที่ปรับ Clock อย่างราบรื่นมากกว่า

สำหรับการใช้งานทั่วไป อย่างน้อยควร Sync เวลาให้เรียบร้อย ก่อนเริ่มออกอากาศ กรณีนี้ สามารถหาแอพ time sync มาใช้ด้วยได้นะครับ


ขั้นที่ 2 — ดู DT ของหลายสถานี

กลับมาที่ WSJT-X ไม่ต้องรีบเรียกใคร ปล่อย Monitor สักพักหนึ่ง แล้วดูค่า DT ของหลายสถานี

ตัวอย่างที่ดูปกติ:

-0.1
0.0
+0.2
-0.2
+0.1

ไม่จำเป็นต้องเป็น 0.0 ทุกสถานี สิ่งที่เรากำลังดูคือ แนวโน้มโดยรวม

แต่ถ้าเห็นประมาณ

+0.8
+1.0
+0.9
+1.1
+0.8

กระจายอยู่แทบทุกสถานี ให้กลับไปตรวจ Clock อีกครั้ง และไม่ควรมีความเชื่อแบบตายตัวว่า

“DT เกิน +0.5 ห้ามเล่น”

เพราะ DT เป็นค่า Diagnostic ไม่ใช่ไฟเขียว/ไฟแดงที่มีเส้นแบ่งเดียวสำหรับทุกสถานการณ์

เป้าหมายของเราคือ Clock ถูกต้อง และกลุ่ม DT โดยรวมอยู่ใกล้ศูนย์


ขั้นที่ 3 — Band เปิดจริงไหม? เปิด mhz.band/live

เมื่อเรื่องเวลาน่าจะผ่านแล้ว คำถามต่อไปคือ

Propagation ตอนนี้เป็นอย่างไร?

แทนที่จะตัดสินจาก Waterfall ของสถานีเราเพียงเครื่องเดียว ลองเปิด

https://mhz.band/live

แล้วดูว่าช่วงเวลานั้นมี Activity จริงบน Band ไหนบ้าง แนวคิดของหน้า Live คือใช้ข้อมูลจากเครือข่ายภายนอกเป็น Evidence

ไม่ใช่ถามแค่ว่า

“ผมได้ยินไหม?”

แต่ถามว่า

“ตอนนี้โลก HF ข้างนอกกำลังเกิดอะไรขึ้น?”

ตัวอย่างเช่น

เราอยู่ 15 เมตรและเรียกญี่ปุ่นไม่ติด

เปิด mhz.band/live แล้วพบว่ามี Activity ระหว่างเอเชียตะวันออกเฉียงใต้กับญี่ปุ่นจำนวนมาก

อย่างน้อยเราก็รู้ว่า

Band ไม่ได้ปิดสนิท

จากนั้นจึงค่อยหันกลับมาวิเคราะห์สถานีตัวเอง


อย่าเดาจากค่า Solar อย่างเดียว ให้ดูสิ่งที่เกิดขึ้นจริง

ค่า Solar Flux, K-index หรือข้อมูล Space Weather มีประโยชน์ แต่สุดท้ายสิ่งที่นักวิทยุอยากรู้คือ

“ตอนนี้มีใครคุยกับใครได้จริง?” นี่เป็นเหตุผลที่ข้อมูลจากสถานีรับจริงมีประโยชน์มาก

หาก Band มี Spot เกิดขึ้นต่อเนื่องใน Region ที่เราสนใจ นั่นคือหลักฐานว่ามี Propagation เกิดขึ้นจริงในช่วงเวลานั้น

จากนั้นเราสามารถใช้ PSKReporter เจาะลงไปอีกระดับหนึ่งว่า แล้ว Signal ของเราเองล่ะ ไปถึงไหน?


ขั้นที่ 4 — ถาม PSKReporter ว่า “มีใครได้ยินเราไหม?”

PSKReporter มีหน้าที่เก็บ Reception Reports จากสถานีที่ใช้ซอฟต์แวร์ Digital Mode ต่าง ๆ ทำให้เราสามารถตรวจสอบได้ว่าสัญญาณจาก Callsign ของเราไปถูก Decode ที่ไหนบ้าง

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

วิธีทดสอบง่ายที่สุดคือ

  1. เลือก Band ที่ต้องการ
  2. เช็กเวลาและ DT ให้เรียบร้อย
  3. CQ ด้วย FT8 สัก 2–3 นาที
  4. เปิด PSKReporter
  5. ค้น Callsign ของตัวเอง

แล้วดูว่ามี Reporter อยู่ที่ไหนบ้าง


กรณีที่ 1 — มีคนรับเราเต็มไปหมด แต่ไม่มีใครตอบ

ถ้า PSKReporter แสดงว่า Signal เราไปถึง

JA
VK
BY
EU

ตามที่คาดไว้

แปลว่า

TX + Antenna + Propagation อย่างน้อยทำงานในระดับหนึ่ง ตอนนี้ไม่ควรรีบไปปีนเสาแล้ว

สิ่งที่ควรดูต่อคือ

  • เราเรียกสถานีที่กำลัง QSO กับคนอื่นหรือไม่
  • Frequency ที่ใช้มี QRM หรือไม่
  • Tx frequency ชนสถานีอื่นหรือเปล่า
  • Signal เราอ่อนกว่าคู่แข่งมากหรือไม่
  • สถานีนั้นกำลังเรียกเฉพาะบาง Region หรือ DX หรือไม่

กรณีที่ 2 — mhz.band/live บอกว่า Band เปิด แต่ PSKReporter ไม่เห็นเราเลย

อันนี้น่าสนใจมากกว่า

ถ้า Network ภายนอกแสดงว่ามี Activity จริง

แต่ CQ ของเราออกไปหลายรอบแล้วยังไม่มี Reporter ใด Decode ได้

ถึงเวลาหันกลับมาตรวจฝั่งสถานีเรา

เริ่มจาก

Time → DT → Audio → TX → Feedline → Antenna

ไม่ใช่เริ่มด้วยการทำเสาใหม่


ขั้นที่ 5 — ตรวจ Audio และ ALC

FT8 เป็น Digital Mode

การเพิ่ม Audio จากคอมพิวเตอร์จนแรงสุดไม่ได้ทำให้ Signal ดีที่สุดเสมอไป

หาก Drive Audio มากเกินไปจนเครื่องเกิด ALC หรือ Compression มาก อาจทำให้สัญญาณกว้างและเกิด Distortion

ตรวจว่า

  • Radio อยู่ใน Data/USB Mode ที่เหมาะสม
  • Audio Level ไม่เบาจน Power ไม่ออก
  • Audio ไม่แรงเกินจน ALC ทำงานหนัก
  • ไม่มี Speech Processor หรือ EQ แปลก ๆ เข้ามาเกี่ยวข้อง
  • TX Power ออกตามค่าที่ตั้งไว้

หลักการคือ

Clean signal ก่อน High power


ขั้นที่ 6 — ค่อยไปดู Coax และเสา

ถ้า

  • เวลาโอเค
  • DT ดูปกติ
  • Band มี Activity
  • PSKReporter ไม่เห็นเรา
  • TX Power ออกจริง
  • Audio ปกติ

ตอนนี้ถึงเวลาตรวจระบบ RF แล้ว ไล่ตั้งแต่

Radio
↓
Coax jumper
↓
Antenna switch
↓
Common-mode choke
↓
Main coax
↓
Connector
↓
Matching unit / Balun / Unun
↓
Antenna

ดู SWR ประกอบ แต่จำไว้ว่า

SWR ต่ำไม่ได้แปลว่าเสา Radiation ดีเสมอไป

Dummy Load ก็มี SWR ดีมาก แต่ไม่ได้แปลว่าจะใช้เรียก DX ได้


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


ตัวอย่างสถานการณ์จริง

สมมติว่าเปิด FT8 บน 21 MHz รับ JA และ BY ได้เต็มหน้าจอ

SWR 1.3 กำลังส่ง 50 W

CQ ไป 5 นาที ไม่มี QSO

สิ่งที่ไม่ควรทำทันที

เพิ่มเป็น 100 W

สิ่งที่ควรทำ

ดู DT ของหลายสถานีก่อน ถ้าพบว่าส่วนใหญ่ไปประมาณ

+0.9
+1.0
+0.8

ให้ตรวจ Time Sync หลังแก้เวลาแล้วกลับมาดูใหม่ ถ้ากลุ่ม DT กลับมาใกล้ศูนย์ ก็ลอง CQ ใหม่

จากนั้นเปิด mhz.band/live ถ้าพบว่า 15 เมตรมี Activity ในเอเชียจริง

เปิด PSKReporter ดู Callsign ตัวเอง ถ้ามี JA หลายสถานีรับเราได้แล้ว

คำตอบคือ

เสาไม่ได้เป็นผู้ต้องสงสัยอันดับแรกอีกต่อไป

นี่แหละครับข้อดีของการใช้ Evidence แทนการเดา


สรุป: ก่อนเพิ่ม Power ลองดู DT ก่อน

ครั้งหน้าเมื่อเปิด FT8 แล้วเจอสถานีเต็มหน้าจอ แต่เรียกอย่างไรก็ไม่มีใครตอบ

อย่าเพิ่งสรุปว่า Propagation แย่ อย่าเพิ่งเพิ่ม Power และอย่าเพิ่งโทษเสา

ให้ไล่ตามนี้

เวลา → DT → mhz.band/live → PSKReporter → TX → เสา

FT8 เป็นโหมดที่ทำให้เราสามารถติดต่อกันด้วย Signal ที่อ่อนมากได้

แต่ความแม่นยำเล็ก ๆ อย่างเวลาในคอมพิวเตอร์ก็เป็นส่วนหนึ่งของระบบเช่นเดียวกัน

บางครั้งปัญหาที่เราหาอยู่บนเสาสูงสิบเมตร อาจไม่ได้อยู่บนนั้นเลย

แต่อยู่ที่ Clock มุมขวาล่างของหน้าจอคอมพิวเตอร์นี่เอง

73!


FAQ

DT ใน WSJT-X ควรเป็น 0.0 ทุกสถานีหรือไม่?

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

FT8 ต้องตั้งเวลาตรงแค่ไหน?

คู่มือ WSJT-X ระบุว่าควร Synchronize Clock กับ UTC ภายในประมาณ ±1 วินาที แต่ในทางปฏิบัติควรทำให้ถูกต้องและนิ่งที่สุดเท่าที่ทำได้ โดยเฉพาะไม่ควรปล่อยให้ Clock Drift ไปเรื่อย ๆ

รับ FT8 ได้ แต่ไม่มีใครตอบ แปลว่าเสาไม่ดีหรือไม่?

ยังสรุปไม่ได้ ควรตรวจ Time/DT แล้วดู Activity ภายนอก จากนั้นใช้ PSKReporter ตรวจว่ามีสถานีใดรับ Signal ของเราหรือไม่ ถ้ามี Reporter จำนวนมากได้ยินเรา ระบบ TX และเสาน่าจะทำงานในระดับหนึ่งแล้ว

mhz.band/live ใช้ทำอะไรในกรณีนี้?

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

PSKReporter ต่างจากการดู Waterfall อย่างไร?

Waterfall บอกว่าสถานีของเรา “รับอะไรได้” ส่วน PSKReporter ช่วยตอบอีกด้านว่า “ใครรับเราได้” จึงมีประโยชน์มากในการตรวจสอบภาคส่งและ Propagation