CAN FD มีสองอัตราบิตแล้วต้องตีความเวลาอย่างไร

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

BRS กำหนดการสลับเวลาในเฟรม

CAN FD มีการตั้งเวลาแบบ nominal สำหรับช่วงที่ต้องรักษากลไกการใช้บัสร่วมกัน และแบบ data สำหรับช่วงข้อมูลที่อนุญาตให้ใช้บิตสั้นลง การเลือกสลับใช้บิต BRS ประกอบกับรูปแบบเฟรมที่เป็น FD หากไม่เปิดการสลับอัตราบิต เฟรม FD ก็สามารถส่งโดยไม่เร่งช่วงข้อมูลได้ ดังนั้นการพบเฟรม FD ไม่เพียงพอที่จะสรุปว่าช่วงข้อมูลมีความเร็วสูงกว่า ต้องดูธงและการตั้งค่าที่เกี่ยวข้อง

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

1. 1
   ช่วงอัตราบิตปกติ

   เริ่มเฟรมและตัดสินสิทธิ์ส่งด้วยการตั้งเวลาช่วงปกติ

2. 2
   จุด BRS

   เมื่อเฟรมเลือกสลับอัตราบิต ตัวควบคุมเปลี่ยนจังหวะที่ตำแหน่งกำหนดในบิต BRS

3. 3
   ช่วงข้อมูล

   ข้อมูลใช้คาบบิตของช่วง data ซึ่งอาจสั้นกว่าช่วงปกติ

4. 4
   กลับก่อน ACK

   กลับสู่เวลาปกติในช่วง CRC delimiter ก่อนการตอบรับ

การเร่งช่วงข้อมูลไม่ได้เร่งทุกส่วนของเฟรมด้วยอัตราเดียวกัน

ตัวอย่างสมมติของคาบบิตและเวลาส่วนข้อมูล

สมมติชุดฝึกตั้ง nominal ที่ 500 กิโลบิตต่อวินาที และ data ที่ 2 เมกะบิตต่อวินาที คาบบิตภายในช่วงแรกเท่ากับ 1 หาร 500000 วินาที หรือ 2 ไมโครวินาที ส่วนช่วงข้อมูลเท่ากับ 1 หาร 2000000 วินาที หรือ 0.5 ไมโครวินาที จึงสั้นลงสี่เท่า ตัวเลขนี้มีไว้แสดงการคำนวณ ไม่ใช่การระบุว่ารถทุกคันใช้ค่าคู่นี้ และไม่ใช่คำแนะนำให้ตั้งเครื่องมือโดยไม่มีข้อมูลเครือข่าย

ถ้าพิจารณาเฉพาะข้อมูล 32 ไบต์ จะมีบิตข้อมูล 32 คูณ 8 เท่ากับ 256 บิต เวลาของบิตเหล่านี้ที่ 2 เมกะบิตต่อวินาทีคือ 128 ไมโครวินาที แต่ที่ 500 กิโลบิตต่อวินาทีคือ 512 ไมโครวินาที ผลต่าง 384 ไมโครวินาทีนี้เป็นผลคำนวณเฉพาะบิตข้อมูล ไม่ใช่เวลาที่ประหยัดของเฟรมสมบูรณ์ เพราะยังมีส่วนควบคุม CRC บิตแทรก และช่วงที่ไม่ได้ใช้ความเร็วสูงรวมอยู่

นำไปใช้ตั้งคำถามเมื่อถอดรหัสได้เพียงบางช่วง

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

1. ตรวจเอกสารของเครือข่ายและเครื่องมือว่ารองรับ CAN FD รูปแบบเดียวกัน รวมถึงอัตราบิตที่ใช้งาน
2. บันทึกค่า nominal และ data แยกช่อง ไม่จดเพียงว่าใช้ความเร็วเท่าใดค่าเดียว
3. ตรวจธง FD และ BRS ในบันทึก เพื่อแยกเฟรม FD ที่เปิดและไม่เปิดการสลับ
4. ประเมินความกว้างบิตในช่วงคงที่กับค่าที่คาดจากสูตรหนึ่งหารอัตราบิต โดยระวังว่าระยะระหว่างขอบอาจกินหลายบิต
5. หากยังผิดพลาด ให้เก็บเวลาที่เริ่มผิดและสภาพการต่อเครื่องมือ เพื่อแยกสมมติฐานการตั้งเวลาจากคุณภาพสัญญาณ

1. 1
   32 ไบต์

   32 คูณ 8 เท่ากับ 256 บิตข้อมูล

2. 2
   500 กิโลบิต/วินาที

   คาบบิต 2 ไมโครวินาที ข้อมูลส่วนนี้จึงใช้ 512 ไมโครวินาที

3. 3
   2 เมกะบิต/วินาที

   คาบบิต 0.5 ไมโครวินาที ข้อมูลส่วนนี้ใช้ 128 ไมโครวินาที

4. 4
   ต่าง 384 ไมโครวินาที

   512 ลบ 128 ได้ 384 ไมโครวินาทีสำหรับบิตข้อมูลที่พิจารณาเท่านั้น

ไม่รวมส่วนควบคุม CRC บิตแทรก หรือช่วงเว้น จึงไม่ใช่เวลาเฟรมเต็ม

ข้อจำกัดของคำว่าเร็วขึ้นสี่เท่า

การเพิ่มอัตราบิตช่วงข้อมูลสี่เท่าไม่ทำให้เวลาทั้งเฟรมเหลือหนึ่งในสี่ เนื่องจากบางส่วนยังใช้ nominal และยังมีภาระอื่น ในการประเมินแบบย่อ ถ้าช่วงที่คงความเร็วเดิมกินเวลา 100 หน่วยและช่วงที่เร่งได้กินเวลา 100 หน่วย รวมเดิม 200 หน่วย เมื่อเร่งเฉพาะช่วงหลังสี่เท่าจะเหลือ 100 บวก 25 เท่ากับ 125 หน่วย จึงเร็วขึ้นในแง่เวลารวมเพียง 200 หาร 125 เท่ากับ 1.6 เท่า ตัวเลขหน่วยเวลานี้เป็นแบบจำลองเพื่ออธิบายสัดส่วน ไม่ใช่การนับฟิลด์ของเฟรมจริง

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

ตรวจสอบผลด้วยเวลาและความถูกต้องพร้อมกัน

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

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