วิธีทำให้ Starlink Mini ทำงานโดยไม่ใช้เราเตอร์ WiFi ในตัว

 (olegkutkov.me)
1 คะแนน โดย GN⁺ 2025-06-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Starlink Mini 1 สามารถถอด เราเตอร์ Wi-Fi ในตัวออกเพื่อใช้งานเป็นเทอร์มินัลแบบ Ethernet ล้วนได้ ทำให้มีตัวเลือกมากขึ้นสำหรับการจัดเครือข่ายแบบกำหนดเองหรือการติดตั้งแบบฝังตัว
  • การดัดแปลงนี้จำกัดเฉพาะ Starlink Mini 1 ณ วันที่ 14 มิถุนายน 2025 และขั้นตอนอาจไม่ตรงกับฮาร์ดแวร์รุ่นหลังอย่าง Mini 2
  • ระหว่างการถอดแยก แผ่นโลหะบน PCB ของ Starlink ทำหน้าที่เป็นทั้ง ฮีตซิงก์และฉนวนกัน EMI หากถอดออกจะเพิ่มความเสี่ยงต่อการ throttling หรือการรบกวนทางแม่เหล็กไฟฟ้า
  • ตัวเครื่องหลักกับเราเตอร์เชื่อมต่อกันด้วยลิงก์ 1Gbps Ethernet และบัสไฟ 12VDC โดยในการออกแบบของผู้ใช้เองจำเป็นต้องมี Ethernet transformer ต่างจากการเชื่อมต่อภายในระยะสั้นโดยตรง
  • หลังถอดเราเตอร์ออก เทอร์มินัลจะให้บริการ DHCP และอินเทอร์เฟซสถานะ gRPC บน 192.168.100.0/24 แต่หากต้องใช้อุปกรณ์หลายเครื่องหลังเชื่อมต่อดาวเทียม จำเป็นต้องมีเราเตอร์ต้นทาง

ขอบเขตการดัดแปลงและข้อควรระวังในการถอดแยก

  • Starlink Mini เป็นเทอร์มินัลแบบ all-in-one ที่มี เราเตอร์ Wi-Fi ในตัว แต่หากถอดบอร์ดเราเตอร์ภายในออกทางกายภาพ ก็สามารถใช้งานเป็นแบบ Ethernet ล้วนได้
  • รุ่นที่ใช้ได้คือ Starlink Mini 1 ณ วันที่ 14 มิถุนายน 2025 และการเปลี่ยนแปลงฮาร์ดแวร์ของรุ่นในอนาคต เช่น Mini 2 อาจทำให้ขั้นตอนนี้ใช้ไม่ได้
  • การถอดแยกต้องใช้ความอดทนและความแม่นยำ แนะนำให้ใช้ spudger โลหะและเครื่องมือแงะพลาสติก
  • เมื่อต้องถอด PCB ของเราเตอร์ จำเป็นต้องใช้มีดบางที่ยืดหยุ่นได้หรือเส้นลวดโลหะบาง
  • หลังถอด PCB ของเราเตอร์แล้ว สามารถหยุดการถอดแยกได้ และ ไม่แนะนำอย่างยิ่งให้ถอดแผ่นโลหะของ PCB Starlink
    • แผ่นโลหะทำหน้าที่ทั้งเป็น ฮีตซิงก์ และฉนวนกัน EMI
    • CPU ของ Starlink มีความร้อนสูง และหากระบายความร้อนไม่พอ CPU หรือชุดเสาอากาศอาจถูก throttling
    • ขอบของแผ่นโลหะยึดด้วยกาวนำไฟฟ้าเพื่อช่วยป้องกันคลื่นแม่เหล็กไฟฟ้า และหากถอดออกอาจทำให้การแผ่สัญญาณเพิ่มขึ้นและรบกวนอุปกรณ์อิเล็กทรอนิกส์รอบข้าง

คอนเนกเตอร์ PCB และการจัดขา

  • ยังไม่ทราบชนิดคอนเนกเตอร์ของ PCB Starlink Mini อย่างแน่ชัด และอาจเป็นชิ้นส่วนสั่งทำเฉพาะ
  • ระยะ pitch ของคอนเนกเตอร์คือ 2mm ดังนั้น 2mm header มาตรฐานอาจใช้ได้
  • คอนเนกเตอร์ถูกยึดด้วยกาวนำไฟฟ้าและพื้นที่กราวด์ขนาดใหญ่ และมีชิลด์อยู่เหนือคอนเนกเตอร์ฝั่ง PCB ของเราเตอร์
    • โครงสร้างนี้มีไว้เพื่อ ลด EMI
  • ระหว่างตัวเครื่องหลักกับเราเตอร์ใช้ลิงก์ 1Gbps Ethernet
  • การเชื่อมต่อภายในเป็นการต่อโดยตรงแบบ PHY-to-PHY พร้อมการ decoupling เล็กน้อย โดยไม่มี Ethernet transformer
    • ระยะสั้นสามารถยอมรับได้ แต่ในการติดตั้งที่ออกแบบเองโดยผู้ใช้จำเป็นต้องมี Ethernet transformer
  • บัสไฟหลักคือ 12VDC
  • ขา 11, 14, 16, 17, 18 ไม่ได้ใช้ในการดัดแปลงปัจจุบัน และส่วนใหญ่เป็นสำหรับการมอนิเตอร์ Starlink-Router
  • เพื่อให้จ่ายไฟได้เสถียร แนะนำให้ใช้ทุกเส้นของ 12VDC และ GND

การออกแบบการเชื่อมต่อ Ethernet โดยตรง

  • ตัวอย่างการเชื่อมต่อ Ethernet โดยตรงใช้วงจรที่ให้ฉนวน Ethernet ที่จำเป็นและการกรองไฟขั้นต่ำสำหรับคอนเนกเตอร์ PCB ของ Starlink Mini 1
  • แนะนำให้มี guard ground รอบคอนเนกเตอร์ U1
  • การออกแบบที่เหมาะสมที่สุดควรรวมกาวนำไฟฟ้าและชิลด์ไว้ด้วย
  • ควรรักษาระยะสายระหว่างคอนเนกเตอร์กับ Ethernet transformer ให้สั้นที่สุดเท่าที่ทำได้
  • กระแสทำงานปกติที่ 12V อยู่ที่ประมาณ 3A และสไปก์สั้น ๆ อาจขึ้นไปถึง 5A
    • ควรเลือก L1 ที่มีพิกัดกระแสเหมาะสมเพื่อหลีกเลี่ยงความร้อนเกิน
  • ใน proof of concept ใช้อะแดปเตอร์ Ethermod ที่มีอยู่

การทำงานของเครือข่ายและวิธีเข้าถึง

  • เมื่อยังไม่ได้เชื่อมต่อกับดาวเทียม Starlink เทอร์มินัลจะให้ที่อยู่ IP ผ่าน DHCP บนเครือข่าย 192.168.100.0/24
  • ตัวเทอร์มินัลเข้าถึงได้ที่ 192.168.100.1 และรันเว็บ UI แบบง่ายกับเซิร์ฟเวอร์มอนิเตอร์/ควบคุม gRPC
  • สามารถตรวจสอบข้อมูล debug ของ Starlink ได้ด้วย grpcurl
grpcurl -plaintext -d {\"get_status\":{}} 192.168.100.1:9200
SpaceX.API.Device.Device/Handle
  • หลังเชื่อมต่อกับเครือข่าย Starlink แล้ว อินเทอร์เฟซ Ethernet จะให้บริการ DHCP แบบ tunneling
    • ไคลเอนต์จะได้รับ IP จากพูลของ Starlink
    • โดยทั่วไปจะได้รับที่อยู่ IPv4 แบบ CGNAT และที่อยู่ IPv6 แบบ link-global
    • โครงสร้างนี้ทำให้เข้าถึงอินเทอร์เน็ตได้
  • เซิร์ฟเวอร์ DHCP ของ Starlink ให้ ที่อยู่ IP เพียงรายการเดียว
    • อุปกรณ์ที่เชื่อมต่อโดยตรงได้คือโฮสต์ 1 เครื่อง หรือเราเตอร์ต้นทาง 1 ตัวที่จะแชร์การเชื่อมต่อให้หลายอุปกรณ์
  • หลังได้รับ IP ภายนอกแล้ว ไคลเอนต์จะสูญเสียการเข้าถึง 192.168.100.1 ตามธรรมชาติ
  • หากต้องการคงการเข้าถึงเทอร์มินัลไว้ สามารถเพิ่ม static route ได้
sudo ip route add 192.168.100.1 dev ethX
  • ต้องเปลี่ยน ethX เป็นชื่ออินเทอร์เฟซ Ethernet ที่เชื่อมต่อกับ Starlink
  • เมื่อโฮสต์ได้รับที่อยู่ IP หลังเชื่อมต่อเครือข่าย Starlink แล้ว จะเข้าถึงอินเทอร์เน็ตได้โดยไม่ต้องตั้งค่าเพิ่มเติม
  • ต้องมอนิเตอร์สถานะบัญชีและสถานะการเชื่อมต่อผ่านเอาต์พุต gRPC

รหัสสถานะ gRPC

  • เอาต์พุต gRPC get_status มีข้อมูลที่ช่วยวินิจฉัยปัญหาการเชื่อมต่อ
  • เมื่อมีปัญหาการเชื่อมต่อ อาจปรากฏส่วน outage ในเอาต์พุต gRPC
"outage": {
  "cause": "NO_SCHEDULE",
  "startTimestampNs": "1815683934050410150",
  "durationNs": "4320001119",
  "didSwitch": true
}
  • ค่าที่เป็นไปได้ของ outage.cause:
    • BOOTING: เทอร์มินัลกำลังเริ่มทำงาน และรอการเริ่มต้นโมดูลกับการล็อก GPS
    • THERMAL_SHUTDOWN: เทอร์มินัลปิดตัวลงเพื่อปกป้องชิ้นส่วนเนื่องจากความร้อนเกิน
    • NO_SCHEDULE: ไม่สามารถสื่อสารกับดาวเทียมได้ อาจเกิดจากสัญญาณอ่อน ข้อมูล GPS ไม่ถูกต้อง หรือปัญหาอื่น ๆ
    • NO_SATS: ตรวจไม่พบดาวเทียมบนท้องฟ้า
    • OBSTRUCTED: ตรวจพบสิ่งกีดขวางในเส้นทางลำคลื่นวิทยุ
    • NO_DOWNLINK: ไม่สามารถรับข้อมูลจากดาวเทียมได้
    • NO_PINGS: การเชื่อมต่อระหว่างเทอร์มินัลกับดาวเทียมยังคงอยู่ แต่ดาวเทียมสูญเสียการเชื่อมต่อกับ ภาคพื้นดิน

รหัสข้อจำกัดของบัญชี

  • ตรวจสอบสถานะบัญชี Starlink ได้จากส่วน disablementCode
  • disablement code ที่เป็นไปได้:
    • UNKNOWN_STATE: เทอร์มินัลรายงานสถานะที่ไม่ได้กำหนดหรือไม่รู้จัก
    • OKAY: บัญชีอยู่ในสถานะใช้งาน และควรเข้าถึงอินเทอร์เน็ตได้
    • NO_ACTIVE_ACCOUNT: บัญชี Starlink ถูกลบหรือบริการถูกระงับชั่วคราว
    • TOO_FAR_FROM_SERVICE_ADDRESS: กำลังใช้งานอยู่นอกพื้นที่ที่อยู่บริการที่ลงทะเบียนไว้
    • IN_OCEAN: อยู่ในเขตทะเลที่แผนบริการปัจจุบันไม่ครอบคลุม
    • BLOCKED_COUNTRY: อยู่ในประเทศที่ไม่อนุญาตให้ใช้บริการ Starlink
    • DATA_OVERAGE_SANDBOX_POLICY: ใช้ข้อมูลเกินขีดจำกัด และต้องเปลี่ยนแผนบริการเพื่อใช้ข้อมูลเพิ่มเติม
    • CELL_IS_DISABLED: เซลล์บริการในพื้นที่ถูกปิดใช้งานในระบบ Starlink
    • ROAM_RESTRICTED: บัญชีหรือแผนปัจจุบันไม่อนุญาตให้โรมมิง
    • UNKNOWN_LOCATION: ดาวเทียม Starlink ไม่สามารถยืนยันตำแหน่งของเทอร์มินัลได้
    • ACCOUNT_DISABLED: บัญชี Starlink ถูกระงับหรือถูกปิดใช้งานถาวร
    • UNSUPPORTED_VERSION: เฟิร์มแวร์ของเทอร์มินัลไม่เข้ากันหรือล้าสมัย
    • MOVING_TOO_FAST_FOR_POLICY: เคลื่อนที่เร็วเกินไป เช่น ในรถหรืออากาศยาน จนละเมิดข้อจำกัดตามนโยบาย
    • UNDER_AVIATION_FLYOVER_LIMITS: อยู่ใต้เขตการบินผ่านของอากาศยาน จึงถูกจำกัดบริการ
    • INVALID_COUNTRY: อยู่ในประเทศที่ Starlink ไม่รองรับ
    • UNLICENSED_COUNTRY: อยู่ในประเทศที่ Starlink ยังไม่ได้รับการอนุมัติด้านกฎระเบียบ
  • disablementCode ควรใช้งานได้เสมอหลังจากเชื่อมต่อดาวเทียมสำเร็จ
  • เทอร์มินัลผู้ใช้ไม่รู้แผนบริการ ประเทศ พื้นที่ หรือข้อจำกัดความเร็วด้วยตัวเอง แต่จะปฏิบัติตามคำสั่งที่ได้รับจากดาวเทียม Starlink

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-06-16
ความคิดเห็นบน Hacker News

  • ช่วงท้ายทำให้สับสนอยู่บ้าง เหมือนมีนัยว่า “โค้ดการปิดใช้งาน” (การบล็อกตามภูมิภาค, การฝ่าฝืนข้อจำกัดความเร็ว ฯลฯ) ถูกบังคับใช้ที่ เทอร์มินัลผู้ใช้ ถ้าอย่างนั้นแปลว่ามันเลี่ยงได้หรือเปล่า
    เขาบอกว่า “ตัวเทอร์มินัลผู้ใช้เองไม่รู้เรื่องแพ็กเกจบริการ ประเทศ ภูมิภาค หรือการจำกัดความเร็ว และทำตามคำสั่งที่ได้รับจากดาวเทียม Starlink เท่านั้น” แต่ผมนึกว่ามันต้องถูกบังคับตั้งแต่ขั้น DHCP อยู่แล้ว หรือไม่ก็อาจไม่ใช่ เพราะหลังจากได้ IP แล้วมันอาจเคลื่อนที่เร็วเกินไปได้ สงสัยว่าบทความนี้จริง ๆ แล้วเป็นไกด์แบบ “รู้กันเองนะ” สำหรับเลี่ยงข้อจำกัดตามนโยบายของ Starlink หรือเปล่า

    • ฟังดูเหมือนเป็น โค้ดผลลัพธ์ ที่แชร์ไปยังเทอร์มินัล เช่น “ACCOUNT_DISABLED - บัญชี Starlink ถูกระงับหรือปิดใช้งานถาวร” หรือ “UNLICENSED_COUNTRY – เทอร์มินัลอยู่ในประเทศที่ Starlink ยังไม่ได้รับอนุมัติด้านกฎระเบียบ” อะไรทำนองนั้น
      ดูไม่น่าเป็นไปได้ที่โครงสร้างจะให้เทอร์มินัลเป็นฝ่ายตัดสิน แทนที่จะเป็นเครือข่าย Starlink
    • ผมมองว่าเหตุผลที่ดาวเทียมส่งโค้ดไปยังเทอร์มินัล คือเพราะตัวเทอร์มินัลเองไม่รู้ด้วยซ้ำว่าตัวเองถูกบล็อกอยู่หรือไม่ จุดประสงค์คือให้ผู้ใช้ดูได้ว่าทำไมอินเทอร์เน็ตถึงใช้ไม่ได้
    • ไม่ได้รู้จัก Starlink ลึกนัก แต่โดยทั่วไปดูเหมือนโฟลว์ที่แอปอ่าน โค้ดข้อผิดพลาด/วินิจฉัย จากเทอร์มินัล ถ้าเลี่ยงเราเตอร์ในตัวแล้วใช้เทอร์มินัลเป็นแค่โมเด็มที่ต่อกับ SBC ก็จะดูข้อผิดพลาดพวกนี้จากสมาร์ตโฟนไม่ได้
      ดังนั้นจึงสร้างสคริปต์เพื่อตรวจดูโค้ดข้อผิดพลาดแล้วตอบสนองตามนั้นได้ เช่น ถ้าติดเทอร์มินัล Starlink ไว้กับโดรน เมื่อบริการหลุดก็สั่งเปลี่ยนตำแหน่งอัตโนมัติได้ หรือถ้าตรวจพบสิ่งกีดขวาง UAV ก็อาจบินสูงขึ้นได้ ถ้าข้าม geofence โดยไม่ตั้งใจจนบริการหลุด ก็ปิดเทอร์มินัล Starlink แล้วเปิดระบบสื่อสารสำรองได้ พูดได้ว่าจริง ๆ แล้วใช้โค้ดการปิดใช้งานนี้เป็น เหมือนเซนเซอร์ ได้
    • ถ้าหาคำตอบได้จริงว่าสามารถหลอกหรือเลี่ยง โค้ดการปิดใช้งาน แบบไหนได้บ้าง ก็คงไม่เอามาแชร์อยู่แล้ว สุดท้ายขึ้นอยู่กับว่า Starlink ตรวจสอบและบังคับใช้การใช้งานที่ไม่ได้รับอนุญาตเข้มงวดแค่ไหน
      สำหรับบริษัทอเมริกันที่ดำเนินงานในสเกลนี้ เป็นไปได้ตั้งแต่เข้มงวดมาก ไปจนถึงตรวจสอบพื้นฐานหรือค่อยตอบสนองเมื่อมีคำขอ มีคนในนี้บอกว่า Starlink ใช้ได้แม้ในรัสเซียที่ตามปกติไม่น่าจะใช้ได้ แต่ก็อาจเป็นได้ว่าอุปกรณ์บางส่วนที่ส่งให้ยูเครนสามารถถูกใช้ในรัสเซียได้ด้วย
    • ไม่ได้ให้ความรู้สึกแบบนั้นเลย ถ้าเทอร์มินัลไม่ได้เก็บข้อมูลแพ็กเกจบริการหรือข้อจำกัด แปลว่าข้อมูลนั้นถูกจัดการในระดับที่สูงกว่า จากบทความนี้อย่างเดียวบอกไม่ได้ว่าสามารถตั้งค่าเทอร์มินัลให้มองข้ามข้อจำกัดได้หรือไม่ แต่แค่เพิกเฉยต่อ disablementCode อย่างเดียวน่าจะยังไม่พอ

  • น่าสนใจที่เลือกใช้ อีเทอร์เน็ตระหว่างบอร์ดแบบดัดแปลง แทนที่จะต่อ RGMII ระหว่าง MAC โดยตรง

    • อีเทอร์เน็ตดูทำต้นแบบได้ง่ายกว่ามาก ถ้าจะสื่อสารด้วย RGMII แทบไม่มีสินค้าสำเร็จรูปที่หยิบมาใช้ได้ทันที แต่อีเทอร์เน็ตเวลาทดสอบก็แค่เสียบเข้ากับแล็ปท็อปได้เลย
      ถ้ามีสองทีมต่างคนต่างทำ การตกลงใช้อีเทอร์เน็ตเป็นอินเทอร์เฟซจะง่ายกว่ามาก และอาจเลื่อนการทดสอบรวมระบบออกไปได้ หรือปล่อยผลิตภัณฑ์ได้เร็วขึ้น
    • RGMII ไม่ได้ออกแบบมาสำหรับการเชื่อมต่อระหว่างบอร์ด อัตราข้อมูลค่อนข้างสูง และตามอุดมคติควรต้องปรับดีเลย์ของทุกสัญญาณให้ตรงกัน
      ถ้าแบ่งเป็นสองบอร์ดก็ยิ่งยุ่งยากขึ้น และน่าจะมีปัญหา EMI/EMC ด้วย เคยเห็นชุด evaluation kit ทำแบบนั้นอยู่ แต่สำหรับผลิตภัณฑ์ผลิตจำนวนมาก ดูไม่ใช่ไอเดียที่ดี
    • โดยรวมให้ความรู้สึกเหมือน proof of concept ค่อนข้างแรง จริงอยู่ที่ดิจิทัล→แอนะล็อก→แอนะล็อก→ดิจิทัลนั้นไม่มีประสิทธิภาพ และในเชิงนามธรรม การเชื่อมต่อ MAC-PHY ด้วย RGMII น่าจะดีกว่า
      แต่เดาแบบฉับพลันว่าอินเทอร์เฟซที่บทความพูดถึงน่าจะเข้าถึงง่ายกว่า หรือไม่ต้องขุดลงไปในโครงสร้างภายในมากนักก็ได้ ไม่รู้ด้วยซ้ำว่าไลน์ RGMII อยู่ตรงไหน และขึ้นกับการออกแบบของ Starlink Mini เอง มันอาจถูกฝังลึกกว่าและเข้าถึงยากกว่าก็ได้
    • ยังไม่เข้าใจเป้าหมายของงานนี้ทั้งหมด Mini มี แจ็ก RJ45 อยู่แล้ว จึงไม่จำเป็นต้องแฮ็กอุปกรณ์เพื่อเข้าถึง Ethernet PHY และในหน้าตั้งค่าก็ปิดเราเตอร์ WiFi ได้ด้วย
      หรือว่า Mini ที่ให้ใช้ในยูเครนถูกตัดการรองรับแจ็กอีเทอร์เน็ตออกไป? จากรูป ดูเหมือนมันยังอยู่บนบอร์ด WiFi ข้างแจ็กไฟเหมือนเดิม
    • คอนเน็กเตอร์นั้นถูกกว่าคอนเน็กเตอร์ที่สามารถส่ง สัญญาณ RGMII ได้โดยไม่เกิดการสะท้อนมาก ๆ อยู่มาก สุดท้ายการใส่ซิลิคอนเพิ่มอาจถูกกว่าการใช้คอนเน็กเตอร์ที่ดีกว่า และถ้าไม่ต้องการฉนวนแยก ก็น่าจะไม่ต้องใช้ชิ้นส่วนแม่เหล็กด้วย

  • เข้าใจชัดเลยว่ามีการใช้งานแบบไหนที่มีข้อจำกัดด้านพลังงานอยู่ในใจ และชอบนะ

    • อยากรู้ว่าคิดถึง use case แบบไหนโดยเฉพาะ
    • Starlink ถูกใช้กับเครื่องบินทิ้งระเบิดกลางคืน Nemesis และโดรนทะเล Magura อยู่แล้ว
    • เอาไปติดบนโดรนใช่ไหม?

  • เวอร์ชันอาร์ไคฟ์: https://archive.ph/UTFTK

  • Starlink ใช้ SoC อะไร? Broadcom เหรอ?

    • MediaTek

  • ดีมากเลย อยากให้ Starlink ให้บริการแบบ เสาอากาศ+โมเด็ม แบบนี้จริง ๆ และให้ IPv4 จริง ๆ ที่ไม่ใช่ CGNAT ด้วย ดูเหมือนจะมีในแพ็กเกจธุรกิจที่แพงกว่ามากอยู่แล้ว

    • สามารถสร้าง tunnel ผ่าน Starlink เพื่อรับ IP สาธารณะ ได้ แม้จะไม่ได้มีประสิทธิภาพ 100% เพราะ MTU ลดลงและมี hop เพิ่มไปยังปลายทาง tunnel แต่ใช้งานได้
    • สำหรับ ISP รายใหม่ นี่เป็นโฟลว์ปกติแล้ว ถ้าไม่มีแผนใช้ที่อยู่ที่ดี ก็ยากที่จะได้รับอนุมัติให้ซื้อบล็อก IPv4
      การให้ IP สาธารณะแก่ลูกค้าบ้านทุกคน ตอนนี้ถือว่ายากจะมองว่าเป็นการใช้พื้นที่ IPv4 อย่างคุ้มค่า

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