บทเรียน 4.1 — WiFi และเครือข่าย: dBm DHCP IP และ DNS

ดูของจริงก่อน — เมนู Wi-Fi Setting ที่มากับเครื่อง

เมนูนี้อยู่บนบอร์ดมาตั้งแต่บทเรียน 1.1–1.3 แล้ว วันนี้เราจะ สร้างมันขึ้นมาเองด้วย Python และทำให้มันบอกได้มากกว่าที่หน้าจอเดิมบอก

สามขั้นบนจอนี้คือสามบรรทัดในโค้ดของเรา — wifi.scan() · wifi.connect() · wifi.ip()

ทำไม · คืออะไร · ทำยังไง — แผนที่ของชุดบทเรียนนี้

ปลายทางที่จับต้องได้ — หน้าสถานะเครือข่ายสองแผงบนจอเดิมของบทเรียน 3.7–3.9: ตาราง สี่คอลัมน์ (SSID · dBm · ช่อง · รหัส) เรียงจากแรงไปอ่อน และแผงขวาที่มี ไฟสถานะลิงก์สองดวง · SSID · IP · ping สองปลายทาง · มาตรวัด dBm พร้อมพิสัย ที่อัปเดตตัวเองทุก 3 วินาที พร้อมปุ่ม สแกนใหม่ ให้สั่งได้เอง

บทเรียน 3.7–3.9 จอของเรารายงานสิ่งที่อยู่บนบอร์ด · ชุดบทเรียนนี้จอเริ่มรายงานสิ่งที่อยู่นอกบอร์ด

เป้าหมายของชุดบทเรียนนี้ — ต่อยอดแดชบอร์ดบทเรียน 3.7–3.9

1. อ่านค่า RSSI เป็น dBm ได้ และบอกได้ว่า −45 กับ −85 ต่างกันแค่ไหน (ไม่ใช่ "ต่างกันนิดหน่อย")
2. เรียก wifi.scan() แล้ว แกะข้อมูลจาก tuple ได้ถูกช่อง
3. รู้ว่า wifi.connect() ที่บทเรียน 1.4–1.6 เคยเรียกไปแล้ว ข้างในมันทำอะไรอยู่ ตอนที่มันเงียบไปเป็นนาที
4. วินิจฉัยการเชื่อมต่อด้วย wifi.ping() — แยกให้ออกว่าปัญหาอยู่ในห้องเราหรืออยู่นอกห้อง
5. ประกอบทั้งหมดเป็น การ์ดสถานะเครือข่ายบนหน้าจอเดิมจากบทเรียน 3.7–3.9
6. เรียกได้ครบทั้ง แปดชื่อ ของโมดูล wifi และบอกได้ว่าแต่ละตัวมีไว้ทำอะไร

บทเรียน 1.4–1.6 ผู้เรียนต่อเน็ตติดไปแล้ว และเห็น wifi.connect() wifi.ip() wifi.is_connected() wifi.scan() wifi.status() ผ่านตามาครบ — แต่บทเรียนนั้นคือการพาทัวร์ทั้งเส้น ไม่ได้ลงลึกทีละตัว วันนี้จึงเป็นการ เปิดฝากล่องเดิมออกดู: บรรทัดที่เคยรันผ่านนั้นวิ่งผ่านอะไรบ้างกว่าจะได้เลข IP ทำไมบางครั้งช้าจนน่าตกใจ ตัวเลขที่คืนมาแปลว่าอะไร และมันโกหกเราตรงไหนได้บ้าง

ปลายทางของชุดบทเรียนนี้ — หน้าสถานะเครือข่ายของทีม

โครงของหน้าจอ อ่านจากซ้ายไปขวา

• ซ้าย ตาราง สี่คอลัมน์ SSID · dBm · ช่อง · รหัส เรียงจากแรงไปอ่อน — หัวตารางบวกสามแถวพอดีความสูง 288
• ขวา ไฟสถานะสองดวง (ต่ออยู่ / ยังไม่ต่อ) แล้วต่อด้วย ping สองปลายทาง · SSID กับ IP อยู่แถบบน
• ล่างขวา มาตรวัด dBm ของวงที่ทีมต่ออยู่ — แถบที่ขยับวางทับไม้บรรทัดที่บอกพิสัย -90 ถึง -40
• บนขวาคือปุ่ม สแกนใหม่ — หน้าสถานะที่แตะสั่งอะไรไม่ได้เลย คือจอ ไม่ใช่แผงควบคุม

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

เข้าใจฮาร์ดแวร์ · ทำไมความแรงสัญญาณถึงเป็นเลขติดลบ

เลขติดลบไม่ได้แปลว่าผิดปกติ — มันคือธรรมชาติของหน่วยที่วัดของเล็ก ๆ เทียบกับของใหญ่

สเกล dBm — ทุก 10 dB คือสิบเท่า ไม่ใช่สิบหน่วย

เกณฑ์ห้าขีดข้างบนไม่ได้คิดขึ้นเอง — เป็น เกณฑ์ชุดเดียวกับที่หน้าจอ Wi-Fi Setting ของบอร์ดใช้จริง (−50 / −60 / −70 / −80 / −90)

ตัวเลขที่ช่างเครือข่ายใช้กันหน้างาน: ดีกว่า −60 คือสบายทุกงาน · −67 คือขีดจำกัดของงานที่ต้องต่อเนื่องอย่างวิดีโอ/เสียง · ต่ำกว่า −80 อย่าไว้ใจ ต่อติดวันนี้พรุ่งนี้อาจหลุด

ทุก 3 dB คือประมาณ 2 เท่า และทุก 10 dB คือ 10 เท่า — จำสองข้อนี้แล้วอ่านเลข dBm ได้ทันทีโดยไม่ต้องกดเครื่องคิดเลข

เวลาทีมรายงานว่า "สัญญาณอ่อนไปนิดเดียว" ให้ถามกลับว่ากี่ dBm — ต่างกัน 20 dB คือต่างกันร้อยเท่า

2.4 GHz กับ 5 GHz — เร็วกว่าแต่ไปได้ใกล้กว่า

5 GHz ไม่ได้ "ดีกว่า" — มันแลกระยะทางกับความเร็ว เลือกให้ตรงกับงาน ไม่ใช่เลือกเลขที่มากกว่า

เกร็ด: ทำไมบางครั้งสแกนแล้วรอนานผิดปกติ

การสแกนหนึ่งครั้งคือการ ไล่ฟังทีละช่อง ช่องละไม่กี่สิบมิลลิวินาที ยิ่งมีช่องเยอะ ยิ่งใช้เวลานาน นี่คือเหตุผลที่บอร์ดหยุดนิ่งระหว่างสแกน ไม่ใช่เพราะมันค้าง

เชื่อมกับวันนี้: wifi.scan() ของเรา บล็อกได้ถึง 10 วินาที — โค้ดบรรทัดถัดไปจะไม่ทำงานเลยจนกว่าสแกนจบ ดังนั้นในท่าที่ 2 เราจะขึ้นข้อความ กำลังสแกน บนจอ ก่อน เรียกมัน ไม่ใช่หลัง ไม่งั้นผู้ใช้จะเห็นจอว่างเปล่าแล้วนึกว่าโปรแกรมพัง

การเข้าร่วมเครือข่าย — สามจังหวะก่อนจะได้คุยกัน

ตรงจุดที่ภาพเขียนว่า Data Transfer บอร์ดยัง ยังไม่มีเลข IP — ยังคุยกับใครนอกห้องไม่ได้

กลไกเต็ม — จากคลื่นในอากาศ ถึงเลข IP บนจอ

wifi.connect() คืน True เมื่อผ่านครบทั้งห้าขั้น ถ้าติดขั้นไหนก็ตาม เราได้ False เหมือนกันหมด — จึงต้องมี ping ไว้แยกแยะ

DHCP — บอร์ดไม่ได้ตั้งเลข IP ให้ตัวเอง

เลขที่ได้มาเป็นการ ยืมมาชั่วคราว (lease) ไม่ใช่ของเราถาวร — ปิดบอร์ดแล้วเปิดใหม่ อาจได้เลขคนละตัว นี่คือเหตุผลที่โค้ดของเราต้องอ่าน wifi.ip() ทุกครั้งหลังต่อ ห้ามจำเลขเก่าไว้ใช้

ถ้า DHCP ของวงเต็มหรือพัง เราจะ "ต่อ WiFi ติด" แต่ "ไม่มีเลข IP" — อาการนี้ผู้เรียนจะเจอจริง และจะดูเหมือนต่อไม่ติดทั้งที่ไม่ใช่

IP · netmask · gateway — สามค่าที่ต้องอ่านให้เป็น

32 บิตแบ่งเป็นสี่ช่อง ช่องละ 8 บิต จึงมีค่าได้ 0–255 ต่อช่อง · ข้อจำกัดที่ต้องรู้วันนี้: MicroPython บนบอร์ดนี้ให้แค่ wifi.ip() — ยังไม่มี netmask และ gateway ให้อ่าน โค้ดของเราจึงต้อง เดา gateway จากเลข IP (เอาสามช่องแรกต่อด้วย .1)

การเดาแบบนี้ถูกในวงแลนส่วนใหญ่ แต่ไม่ใช่ทุกวง — ท่าที่ 5 จะสอนวิธีตรวจว่าเราเดาถูกหรือเปล่า

ping ได้เกตเวย์ แต่ 8.8.8.8 เงียบ — แปลว่าอะไร

wifi.ping(ip, timeout_ms) คืนเวลาไป-กลับเป็นมิลลิวินาที หรือ −1 ถ้าไม่มีคำตอบภายในเวลาที่ตั้งไว้

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

ระบบที่บอกได้ว่า "พังตรงไหน" มีค่ากว่าระบบที่บอกแค่ว่า "พัง"

DNS — ทำไม wifi.ping() ถึงรับแต่ตัวเลข

เครื่องคอมพิมพ์ google.com ได้เพราะมี ตัวแปลชื่อ (resolver) ถามระบบ DNS ต่อเป็นทอด ๆ จนได้เลข IP แล้วค่อยส่งแพ็กเก็ตไปที่เลขนั้น — ชื่อโดเมนไม่เคยเดินทางในเครือข่าย มีแต่เลขที่เดินทาง ส่วน MicroPython บนบอร์ดนี้ยังไม่มีตัวแปลชื่อเปิดให้ Python เรียก

wifi.ping("google.com")     # ValueError รับเฉพาะเลข IP
wifi.ping("8.8.8.8", 1500)  # ถูกต้อง

8.8.8.8 คือเซิร์ฟเวอร์ DNS สาธารณะของ Google เราเลือกมันเพราะจำง่ายและแทบไม่เคยล่ม ไม่ใช่เพราะกำลังใช้บริการ DNS ของมัน

ข้อจำกัดนี้เป็นช่องว่างของโมดูล ไม่ใช่ของฮาร์ดแวร์ — ตัวชิปคุย DNS ได้ แค่ยังไม่มีใครเปิดประตูฝั่ง Python ให้

ข้อมูลของเราถูกห่อกี่ชั้นกว่าจะออกจากบอร์ด

ping หนึ่งครั้งถูกห่อทีละชั้นก่อนกลายเป็นคลื่นวิทยุ: ข้อมูลของเรา → หัว IP (เลขต้นทาง-ปลายทาง) → หัวชั้นลิงก์ (MAC) → บิตที่ส่งออกอากาศ ปลายทางแกะย้อนกลับตามลำดับเดิม

ที่ต้องรู้วันนี้สองข้อ: แต่ละชั้นเพิ่มขนาดข้อมูล (มีค่าใช้จ่ายคงที่ต่อแพ็กเก็ต) และ แต่ละชั้นพังได้เอกเทศ — คลื่นแรงดีแต่ไม่มี IP เกิดขึ้นได้จริง · บทเรียน 4.4–4.6 เราจะเพิ่มชั้น MQTT ทับลงบนกองนี้

wifi.connect() จัดการชั้นล่างให้ · wifi.ping() วัดชั้นกลาง · ชุดบทเรียนถัดไปเราจะเขียนชั้นบนสุดเอง