ช่วงเริ่มเฟรมและการปรับเวลาใน LIN

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

Break สร้างเครื่องหมายเริ่มที่ต่างจากไบต์ทั่วไป

ช่วง break ใช้ระดับ dominant ยาวกว่ารูปแบบข้อมูลปกติ เพื่อให้ผู้รับรู้ว่ามีจุดเริ่มเฟรมตามมา ในข้อกำหนดการส่งที่อธิบายโดย Microchip ช่วง dominant นี้ยาวอย่างน้อยสิบสามคาบบิต และตามด้วยช่วงปล่อยระดับก่อน sync การตรวจความยาวต้องใช้คาบที่เหมาะกับเครือข่าย ไม่เปรียบเทียบไมโครวินาทีจากบัสที่ตั้งความเร็วคนละค่า

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

1. 1
   แยกจุดเริ่ม

   break ฝั่งส่งมี dominant อย่างน้อย 13 คาบบิตตามข้อกำหนดที่อ้าง

2. 2
   มีช่วงปล่อย

   delimiter แยก break จาก sync ต้องไม่นับรวมเป็นเวลา dominant

3. 3
   วัดจังหวะที่ทราบ

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

เกณฑ์ตรวจของผู้รับไม่แทนข้อกำหนดที่ผู้ส่งต้องทำ

Sync ให้รูปแบบขอบสำหรับเรียนรู้คาบ

ไบต์ sync มีรูปแบบที่รู้ล่วงหน้า ทำให้ผู้รับบางแบบวัดช่วงขอบเพื่อปรับอัตรารับให้ตรงผู้ควบคุมได้ การมี sync ไม่ได้ทำให้นาฬิกาภายในไม่ต้องมีข้อกำหนดใดเลย เพราะยังมีขอบเขตการตรวจและความคลาดระหว่างเฟรมที่ฮาร์ดแวร์รองรับ การวิเคราะห์จึงควรดูว่ารูปแบบต้นเฟรมถูกต้องและเครื่องมือใช้อัตราที่สอดคล้อง ไม่สรุปว่าถ้ามี auto-baud แล้วความเร็วผิดไม่เป็นปัญหา

ตัวอย่างสมมติของคาบ 100 ไมโครวินาที

สมมติจากช่วง sync ที่รู้รูปแบบแล้วพบว่าระยะขอบชนิดที่เลือกครอบคลุมสองคาบบิตและวัดได้ 200 ไมโครวินาที คาบหนึ่งบิตจึงเป็น 100 ไมโครวินาที อัตราบิตคือหนึ่งหาร 0.0001 วินาที เท่ากับ 10000 บิตต่อวินาที หาก break ฝั่งส่งตามตัวอย่างมี dominant สิบสามคาบ จะเท่ากับ 1300 ไมโครวินาทีหรือ 1.3 มิลลิวินาที โดยยังไม่รวม delimiter

หากผู้วิเคราะห์เอาระยะขอบ 200 ไมโครวินาทีไปถือเป็นหนึ่งบิต จะได้ 5000 บิตต่อวินาทีซึ่งผิดครึ่งหนึ่ง ดังนั้นต้องรู้ว่าระยะที่เลือกกินกี่บิตจากรูปแบบ sync จริง ไม่ใช้ระยะขอบใดก็ได้กลับค่าเพื่อหา baud การวางคำอธิบายบนรูปควรระบุจำนวนคาบที่ครอบคลุม ไม่ใส่เพียงลูกศรกับหน่วยเวลาโดยไม่มีบริบท

1. 1
   วัดได้ 200

   คู่ขอบที่เลือกห่าง 200 ไมโครวินาทีและครอบคลุม 2 บิต

2. 2
   คาบละ 100

   200 / 2 = 100 ไมโครวินาที หรือ 0.0001 วินาทีต่อบิต

3. 3
   อัตรา 10000

   1 / 0.0001 = 10000 บิตต่อวินาที ไม่ใช่ 5000

4. 4
   ช่วงเริ่ม 1.3 มิลลิวินาที

   13 × 100 = 1300 ไมโครวินาที เฉพาะ dominant ไม่รวม delimiter

ตัวอย่างสมมติต้องหารสองก่อนกลับเป็นอัตราบิต

นำไปใช้ตรวจว่าหลุดตั้งแต่ต้นเฟรมหรือไม่

1. ระบุชนิด LIN และอัตราที่คาดจากเอกสาร ไม่เริ่มด้วยการเดาจากค่ามิเตอร์
2. ตรวจรูปคลื่นว่าเห็นช่วง break ช่วงปล่อย และ sync ตามลำดับหรือเครื่องมือเริ่มจับกลางเฟรม
3. เลือกช่วงขอบใน sync ที่ทราบจำนวนคาบ แล้วคำนวณอัตราบิตด้วยหน่วยวินาทีให้ถูก
4. เปรียบเทียบการตั้งตัวถอดรหัสกับคาบที่มีหลักฐาน โดยรักษาไฟล์ดิบเดิม
5. หากส่วนต้นถูกแต่ข้อมูลต่อมายังผิด ให้ตรวจ PID ความยาวและ checksum ต่อ ไม่อธิบายทุกอย่างด้วย sync

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

ข้อผิดพลาดของการวัดขอบที่เครื่องมือสร้าง

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

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

ตรวจสอบผลจากเฟรมเต็มหลังแก้การอ่านต้นทาง

หลังเลือกจังหวะถอดรหัสที่เอกสารรองรับ ให้ตรวจว่าทั้ง header และ response สอดคล้อง ไม่ยืนยันจาก sync เพียงไบต์เดียว ในตัวอย่างคาบ 100 ไมโครวินาทีควรใช้ตรวจความยาว break ตามขอบเขตที่กล่าว และตรวจการเรียงไบต์ต่อเนื่อง หากยังผิดในส่วนคำตอบต้องเก็บเป็นข้อค้นพบแยก ไม่ปรับอัตราไปเรื่อย ๆ ให้คำเตือนหาย

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