Quy luật nhồi bit (Bit Stuffing)

Một phần của tài liệu Nghiên cứu và thử nghiệm máy chẩn đoán cơ bản (Trang 52)

Hình 4.23. Phương pháp nhồi bit

Phương pháp mã hóa NRZ là tín hiệu không có giới hạn trong sự tái đồng bộ. Vì vậy, phương pháp nhồi bit được dùng để đảm bảo sự đồng bộ tất cả các nút trên Bus.

Nhồi bit quy ước rằng mỗi khung dữ liệu hoặc khung yêu cầu từ xa có tối đa 5 bit liên tiếp có trạng thái giống nhau tin nhắn. Khi năm bit có trạng thái giống nhau được truyền kế tiếp thì thiết bị gửi sẽ kèm theo một bit có trạng thái ngược lại. Thiết bị nhận sẽ xóa những bit được chèn sau khi nhận. Phương pháp này cho phép phát hiện các lỗi như: ngắn mạch, nhiễu sóng,… giúp cho bộ nhận không nhầm lẫn khi đọc dữ liệu.

Phương pháp nhồi bit được áp dụng cho khung dữ liệu hoặc khung yêu cầu từ xa trong vùng bắt đầu (SOF), vùng phân xử (Arbitration fields), vùng điều khiển (Control fields), vùng dữ liệu (Data fields), vùng kiểm tra vòng lặp thường (CRC fields).

Chương 5. XÂY DỰNG MÔ HÌNH MÁY CHẨN ĐOÁN CƠ BẢN 5.1. Thông tin phần cứng

5.1.1. Arduino Nano ATmega328p

Arduino Uno là một board mạch vi điều khiển được phát triển bởi Arduino.cc, một nền tảng điện tử mã nguồn mở chủ yếu dựa trên vi điều khiển AVR Atmega328P. Với Arduino chúng ta có thể xây dựng các ứng dụng điện tử tương tác với nhau thông qua phần mềm và phần cứng hỗ trợ.

Như các Arduino khác, Arduino Nano cũng hỗ trợ các chuẩn giao tiếp SPI, I2C, UART,… Hỗ trợ phần lớn cho việc kết nối các module khác trong quá trình xây dựng và phát triển mô hình trực quan.

Hình 5.1. Module Arduino Nano

Trong quá trình thử nghiệm và lập trình trên Arduino Uno thì yêu cầu đề tài cần thu gọn kích thước phần cứng để phù hợp với một máy chẩn đoán nên Arduino Nano là lựa chọn phù hợp vì các chức năng và thông số cơ bản gần như giống hoàn toàn với Arduino Uno nhưng kích thước nhỏ gọn, tiện dụng.

Vi điều khiển ATmega328 (họ 8bit)

Điện áp hoạt động 5V – DC

Tần số hoạt động 16 MHz

Dòng tiêu thụ 30mA

Điện áp vào khuyên dùng 7-12V – DC

Điện áp vào giới hạn 6-20V – DC

Số chân Digital I/O 14 (6 chân PWM)

Số chân Analog 8 (độ phân giải 10bit)

Dòng tối đa trên mỗi chân I/O 40 mA

Dòng ra tối đa (5V) 500 mA

Dòng ra tối đa (3.3V) 50 mA

Bộ nhớ flash 32 KB với 2KB bootloader

SRAM 2 KB (ATmega328)

EEPROM 1 KB (ATmega328)

Kích thước 1.85cm x 4.3cm

Bảng 5.1. Các thông số cơ bản của Arduino Nano

5.1.2. Module CAN Bus MCP2515

Hình 5.4. Các chân chức năng và Chip xử lí của module MCP2515

Module CAN Bus MCP2515 dùng chip CAN Controller MCP2515 và CAN Transceiver TJA1040 là module mở rộng ngoại vi CAN cho vi điều khiển không tích hợp chuẩn giao tiếp hiện đại này. MCP2515 sử dụng giao tiếp SPI nên bất kỳ một loại vi điều khiển nào cũng có thể giao tiếp với nó thông qua ngoại vi SPI có sẵn hoặc thậm chí là dùng các chân IO thông thường.

Vi điều khiển MCP2515

Chip chuyển đổi CAN TJA1040

Điện áp hoạt động 2.7V – 5.5V DC

Tần số hoạt động 8 MHz

Dòng làm việc 5mA

Giao thức CAN hỗ trợ V2.0B

Chuẩn giao tiếp SPI

Tốc độ truyền dữ liệu 1 Mbps

Vùng dữ liệu 8 Byte

Kích thước 2.8cm x 4.4cm

5.1.3. Màn hình LCD TFT 2.4 inch

Hình 5.5. Màn hình LCD TFT 2.4 inch

Màn hình cảm ứng Arduino TFT Shield 2.4 inch là màn hình cảm ứng điện trở được thiết kế dạng shield để có thể gắn trực tiếp lên Arduino Uno, Mega2560 một cách dễ dàng thực hiện chức năng hiển thị và điều khiển qua cảm ứng điện trở trên màn hình, màn hình có kích thước nhỏ gọn, tiện lắp đặt, bộ thư viện và code mẫu đi kèm màn hình đầy đủ, dễ lập trình, màn hình có chất lượng hiển thị tốt, cảm ứng có độ nhạy cao, phù hợp cho các ứng dụng hiển thị và điều khiển qua màn hình cảm ứng chuyên nghiệp.

Vi điều khiển ILI9341

Chip chuyển đổi CAN TJA1040

Điện áp hoạt động 3.3V – 5.5V DC

Độ phân giải 240x320 px

Màu sắc 18 bit, lên đến 262,000 màu

Đèn nền LED trắng

Chuẩn giao tiếp SPI

Loại cảm ứng Điện trở

Kích thước 71 x 52 x 7 mm

5.1.4. Module hạ áp LM2596

Hình 5.6. Module giảm áp

Do thiết bị chẩn đoán hoạt động dựa trên nguồn điện trực tiếp từ xe nhận qua cổng OBD-II là 12V, vượt quá điện áp hoạt động của các module điện tử trên được kết nối nên yêu cầu cần giảm điện áp về mức 5V để đảm bảo thiết bị chẩn đoán hoạt động tốt nhất, hạn chế hư hỏng trong quá trình sử dụng và nâng cao tuổi thọ thiết bị.

Vi điều khiển LM2596S DC-DC

Điện áp vào 3.2V~40V

Điện áp ra 1.25V~35V

Dòng ra 3A

Hiệu suất chuyển đổi 92%

Tần số xung 65 kHz

Nhiệt độ hoạt động -45℃ ~ +85℃

Loại cảm ứng Điện trở

Kích thước 71 x 52 x 7 mm

Bảng 5.4. Các thông số cơ bản của Module hạ áp LM2596

5.1.5. Dây cáp DB9 - OBD-II

Dây cáp này một đầu là giắc cái 9 chân DB9 nối tiếp RS232 kết nối với giắc DB9 của CAN Bus Shield, đầu còn lại là giắc đực OBD-II 16 chân theo tiêu chuẩn SAE J1962 kết nối với đầu kết nối OBD-II trên xe.

Hình 5.7. Dây cáp DB9 – OBD-II

Hình 5.8. Kết nối giữa 2 đầu cáp DB9 – OBD-II

5.2. Phần mềm

5.2.1. Phần mềm lập trình – Arduino IDE

Arduino IDE được viết tắt (Arduino Integrated Development Environment) là một trình soạn thảo văn bản, giúp bạn viết code để nạp vào bo mạch Arduino.

Hình 5.9. Giao diện của Arduino IDE

Để sử dụng được Arduino IDE, ta tiến hành cài đặt Java Runtime Environment (JRE) vì ngôn ngữ lập trình của Arduino được viết theo ngôn ngữ lập trình JAVA, sau đó

tải về và cài đặt Arduino IDE. Và để máy tính giao tiếp với Board Arduino Uno R3 thì ta cài thêm Driver tương thích. Quá trình và các bước cài đặt phần mền được trình bày chi

tiết trên trang web Arduino.vn.

Đường link tải: http://arduino.vn/bai-viet/68-cai-dat-driver-va-arduino-ide

5.2.2. Cài đặt thư viện trên Arduino IDE

5.2.2.1. Thư viện cho CAN Bus Shield – MCP2515

Để CAN Bus Shield hoạt động, chúng ta cần cài đặt thư viện thích hợp và giúp cho CAN Bus Shield giao tiếp với cổng OBD-II trên xe. Thư viện chứa các lệnh chuyên dụng được thiết lập sẳn để CAN Bus Shield hoạt động đúng theo tiêu chuẩn. Ta tải thư viện CAN Bus Shield từ GitHub.com – một trang chuyên về các phần mềm lập trình và

thư viện hoạt động. Sau khi thay thế bằng Module CAN Bus MCP2515 để phù hợp kích thước của thiết bị chẩn đoán thì thư viện của CAN Bus Shield vẫn hoạt động tốt trên Module MCP2515. Nhưng trước khi sử dụng, cần điều chỉnh tần số thạch anh (Clockset)

từ 16MHz thành 8MHz vì thư viện của CAN Bus Shield được viết theo tần số thạch anh 16MHz.

Đường link tải: https://github.com/Seeed-Studio/CAN_BUS_Shield

5.2.2.2. Thư viện cho LCD TFT 2.4 inch

Đầu tiên là thư viện đồ họa cho các màn hình LCD – Adafruit GFX Library, cung cấp các tài nguyên liên quan đến đồ họa (nền, điểm, đường, vòng tròn,…) và cần kết hợp với thư viện của từng loại màn hình để điều khiển màn hình hiển thị, ở đây là thư viên

MCUFRIEND_kbv cho màn hình LCD TFT 2.4 inch. Ngoài ra còn có thư viện cảm ứng

cho màn hình khi thiết lập thêm chức năng cảm ứng. Link tải thư viện Adafruit GFX Library:

https://github.com/adafruit/Adafruit-GFX-Library

Link tải thư viện MCUFRIEND_kbv:

https://github.com/prenticedavid/MCUFRIEND_kbv

Linh tải thư viên Adafruit_TouchScreen

https://github.com/adafruit/Adafruit_TouchScreen

5.2.3. Xây dựng giao diện hiển thị trên LCD

Giao diện hiển thị trên LCD được xây dựng dựa trên các chức năng của một máy chấn đoán cơ bản với một vài chức năng tối thiểu như đọc dữ liệu hiện tại, đọc mã lỗi chẩn đoán, xóa mã lỗi. Để nâng cao sự tiện dụng của thiết bị chẩn đoán, tính năng cảm ứng cũng được tích hợp vào thiết bị.

Hình 5.11. Giao diện màn đọc mã lỗi chẩn đoán và màn hình xóa lỗi

5.2.4. Xây dựng thuật toán gửi và nhận tín hiệu CAN

Thuật toán tín hiệu CAN cũng được xây dựng đi kèm với các chế độ hiển thị. 5.2.3.1. ID và vùng dữ liệu trong tin nhắn CAN

Thư viện CAN đã cài đặt có ví dụ về cách gửi và nhận tin nhắn trong mạng CAN. Do mạng CAN được phổ biến khá rộng rãi trên ô tô nên thư viên CAN đi kèm một ví dụ có liên quan đến OBD-II, đọc các thông số của động cơ thông qua giao thức CAN trên ECU động cơ. Trước khi chạy thử code mẫu, chúng ta phải biết rằng chúng ta chỉ can thiệp vào tin nhắn CAN ở vùng điều khiển (ID) và vùng dữ liệu của tin nhắn ở cả tin nhắn gửi đi và nhận về với các yêu cầu theo tiêu chuẩn OBD-II.

Hình 5.12. Cấu trúc ID vùng dữ liệu trong tin nhắn CAN theo tiêu chuẩn OBD-II

Để hiểu rõ hơn về từng byte trong vùng dữ liệu, chúng ta có ví dụ sau về việc yêu cầu và nhân thông tin về Tốc độ xe qua mạng CAN.

Identifier (ID): Đối với các thông báo OBD-II, mã ID theo chuẩn 11-bit và được

sử dụng để phân biệt giữa “Request Massages” (ID 7DF) và “Response Massages” (ID 7E8 đến 7EF). Với ID 7E8 thường sẽ là nơi động cơ chính hoặc ECU phản hồi.

Length: Byte đầu tiên của Vùng dữ liệu phản ánh độ dài theo số byte của dữ liệu

còn lại (03 - 06). Đối với ví dụ về Tốc độ Xe, nó là 02 cho yêu cầu (vì chỉ có 01 và 0D theo sau), trong khi đối với phản hồi là 03 vì cả 41, 0D và 32.

Mode: Đối với các yêu cầu, điều này sẽ nằm trong khoảng 01-0A. Đối với các tin

nhắn phản hồi, số 0 được thay thế bằng 4 (tức là 41, 42,…, 4A). Có 10 chế độ như được mô tả trong tiêu chuẩn SAE J1979 OBD2.

Mode (HEX) Mô tả

01 Hiển thị dữ liệu hiện tại

02 Hiển thị dữ liệu khung đóng băng

03 Hiển thị mã lỗi đã lưu trữ

04 Xóa mã lỗi và giá trị đã lưu

05 Các kết quả kiểm tra, giám sát cảm biến oxy

06 Các kết quả kiểm tra, giám sát các thành phần/hệ thống khác

07 Hiển thị mã lỗi đang chờ xử lý trong chu kì lái xe cuối cùng

08 Kiểm tra hoạt động của các thành phần/hệ thống trên xe

09 Yêu cầu thông tin xe

0A Hiển thị các mã lỗi đã xuất hiện (đã xóa)

Bảng 5.5. Các chế độ chẩn đoán của OBD-II

PID: Đối với mỗi chế độ, chúng ta có một danh sách các PID OBD-II tiêu chuẩn

đầy đủ được tổng hợp trên Wikipedia OBD-II PIDs và mỗi PID có một mô tả và một số có công thức chuyển đổi và tối thiểu/tối đa được chỉ định. Ví dụ: trong Chế độ 01, PID 0D là Tốc độ Xe với công thức tính là A.

Công thức cho tốc độ: A, có nghĩa là byte dữ liệu A (ở dạng HEX) được chuyển

đổi thành số thập phân để nhận giá trị được chuyển đổi km/h (32 trở thành 50 km/h).

A, B, C, D: Đây là các byte dữ liệu trong HEX, cần được chuyển đổi sang dạng

thập phân trước khi chúng được sử dụng trong tính toán công thức PID. Lưu ý rằng byte dữ liệu cuối cùng (sau byte D) không được sử dụng.

5.2.3.2. Code mẫu chế độ “Đọc dữ liệu hiện tại”

Hình 5.15. Đường dẫn Code OBD-II mẫu theo thư viện CAN

Hình 5.16. Cấu trúc vùng dữ liệu trong tin nhắn CAN yêu cầu

Hình 5.17. Vùng dữ liệu trong tin nhắn CAN phẩn hồi tốc độ xe

Như vậy, cấu trúc tin nhắn CAN yêu cầu và phản hồi luôn tuân theo tiêu chuẩn OBD-II cho Vùng điều khiển (ID) và Vùng dữ liệu. Từ một thông số đơn giản có thể phát triển thành nhiều thông số yêu cầu khác như RPM, Nhiệt độ nước làm mát động cơ,… để đáp ứng yêu cầu đọc dữ liệu hiện tại của thiết bị chẩn đoán. Dưới đây là một vài thông số khác đọc được từ ECU động cơ theo cách tương tự. Mọi thử nghiệm đều được tiến hành trên Mô hình mô phỏng ECU động cơ Kia Morning 2011.

Hình 5.18. Một vài thông số từ ECU trong chế độ đọc dữ liệu hiện tại chuẩn OBD-II 5.2.3.3. Chế độ đọc mã lỗi lưu trữ

Hình 5.19. Chương trình gửi tin nhắn CAN cho các chế độ của OBD-II

Hình 5.20. Vùng dữ liệu tin nhắn CAN phản hồi

Cấu trúc gửi và nhận tương tự bằng cách thay đổi byte thứ nhất (Length) thành 0x01 và byte thứ hai (Mode) thành 0x03 và gửi yêu cầu.

Với tin nhắn phản hồi, ta có các Byte dữ liệu 1 và 2 như ở chế độ “Đọc dữ liệu hiện tại”. Byte dữ liệu thứ 3 là số mã lỗi trong 1 tin nhắn CAN, có từ 0 đến 2 mã lỗi cho 1 tin nhắn (0x00 – 0x02) với hai byte dữ liệu 4 và 5 cho một mã lỗi, 6 và 7 cho một mã lỗi. Khi có được các byte dữ liệu, chúng ta cần chuyển đổi các byte đấy thành các Mã lỗi chẩn đoán OBD-II theo cấu trúc sau:

Hình 5.21. Chuyển đổi hai kí tự đầu trong mã lỗi chẩn đoán OBD-II

Với 4 bit theo hệ Nhị phân, tức số đầu tiên trong byte dữ liệu thứ 4 đã nhận được, chúng ta chuyển đổi thành 2 kí tự đầu trong một mã lỗi “P0,P1,…,U3,U4”.

Với các kí tự còn lại trong mã lỗi chẩn đoán OBD-II tương ứng với số còn lại trong byte dữ liệu thứ 4 và 2 số trong byte dữ liệu thứ 5 theo hệ Thập lục phân. Với byte dữ liệu thứ 6 và 7 cũng chuyển đổi tương tự. Trường hợp không có mã lỗi thì byte dữ liệu thứ 3 là 0x00 và các byte dữ liệu sau đó đều 0x00. Trường hợp có 1 mã lỗi, byte dữ liệu thứ 3 là 0x01 và chỉ có dữ liệu ở byte dữ liệu thứ 4 và 5, byte dữ liệu 6 và 7 đều là 0x00. Trường hợp có nhiều hơn 2 mã lỗi thì ECU sẽ gửi nhiều khung tương tự liên tiếp nhau để thể hiện toàn bộ mã lỗi hiện tại.

5.2.3.4. Chế độ xóa mã lỗi

Tương tự các chế độ trên, chế độ xóa mã lỗi cũng tương tự với byte dữ liệu thứ 2 trong tin nhắn CAN yêu cầu là 0x04 và không có tin nhắn CAN phản hồi từ ECU.

5.2.6. Kết nối các thuật toán

Từ các thuật toán đơn lẽ theo các chế độ gửi – nhận tin nhắn CAN và giải mã, màn hình hiển thị các chế, cảm ứng và nút bấm,…. Chúng ta kết hợp lại để có thuât toán, mô hình tổng quan nhầm đảm bảo các yêu cầu ban đầu là đọc được, giải mã được, hiển thị được.

Hình 5.23. Sơ đồ khối tổng quát thuật toán của thiết bị chẩn đoán

5.3. Thử nghiệm Module Arduino Uno – CAN Bus Shield – LCD trên xe Vios

Ta kết hợp các module như hình để tiến hành thử nghiệm trên xe.

5.3.1. Thu thập dữ liệu trên xe Vios qua Arduino IDE

Hình 5.25. Dữ liệu thu thập được từ arduino khi khi thử nghiệm module trên xe

Khi mới khởi động xe và để xe ở tốc độ cầm chừng, các số liệu thu thập được tương đối chính xác như tốc độ xe, tua máy, độ mở bướm ga,… Từ đó xác định được phần code thu thập dữ liệu xe chính xác so với ví dụ mẫu.

5.3.2. Thu thập dữ liệu qua hiển thị LCD

5.3.2.1. Đọc dữ liệu hiện tại

Hình 5.27. Dữ liệu đọc được từ xe

5.3.2.2. Đọc mã lỗi chẩn đoán

Trước khi tiến hành đọc lỗi, ta kiểm tra lỗi của xe và hoàn toàn không có lỗi. Sau đó tiến hành tạo Ban tại cảm biến lưu lượng khí nạp.

Một phần của tài liệu Nghiên cứu và thử nghiệm máy chẩn đoán cơ bản (Trang 52)

Tải bản đầy đủ (PDF)

(74 trang)