Sensor tersedia secara internal atau eksternal. Bagian dalam dipasang di dalam ban roda tubeless, bagian luar disekrup ke pemasangan roda. Roda dengan sensor internal terlihat sama persis dengan roda tanpa sensor. Roda seperti itu mudah dipompa. Sensor eksternal terlihat, dapat dicuri dan harus dibuka terlebih dahulu saat menggembungkan roda. Itu juga dipengaruhi oleh fenomena atmosfer.
Untuk menyelidiki protokol sistem TPMS, saya diminta oleh ide untuk memasang sistem seperti itu pada kereta dorong untuk memantau tekanan ban dengan cepat.
Gambar 1. Penampilan sistem TPMS
Gambar 2. Board pengontrol sistem TPMS
Tidak mungkin memasang unit penerima standar begitu saja, karena nilai tekanan minimum yang diizinkan adalah 1,1 Bar, dan pada kereta dorong bayi nilainya lebih kecil. Oleh karena itu, modul terus berbunyi bip, menginformasikan tentang tekanan ban rendah. Anda dapat membaca tentang pengembangan pengontrol untuk kereta dorong bayi "Smart" "Maksimka" , di mana hasil penelitian diterapkan, di artikel saya [1].
Pengumpulan informasi tentang pengoperasian TPMS dimulai dengan mencari artikel di Internet. Namun sayangnya hanya ada sedikit informasi. Dan itu juga berlaku untuk sistem mobil yang biasanya standar, yang sedikit lebih rumit dan jauh lebih mahal. Dan saya membutuhkan informasi tentang sistem murah Cina yang sederhana. Saya memiliki sedikit pemahaman, sekarang saya harus mulai bereksperimen.
Jadi, kami mempersenjatai diri dengan peluit USB tuner DVB, meluncurkan RTL-SDR dan menonton siarannya. Sensor beroperasi pada 433,92 MHz dalam modulasi FSK. Awalnya, saya merekam siarannya dan kemudian menganalisis protokolnya secara manual. Di sinilah kesulitan dimulai. Sebelumnya, hanya dijumpai modulasi OOK. Semuanya sederhana di sana. Sedikit lebih rumit di sini. Informasi tersebut dikodekan dengan dua frekuensi. Oleh karena itu, saya mempelajari contoh-contoh, teori modulasi. Kemudian saya melihat bagaimana program URH-Universal Radio Hacker digunakan [2, 3]. Saya mencoba menginstalnya, tetapi tidak berfungsi pada WinXP 32bit saya. Saya harus mencari komputer dengan win8 64bit dan kemudian program diinstal. Anda dapat membaca lebih lanjut tentang karyanya di situs web pengembang. URH membuat prosesnya sedikit lebih mudah bagi saya, karena itu menangkap sinyal dari udara, menampilkannya dengan osilogram dan segera menerjemahkannya ke dalam bentuk digital mentah dalam bentuk biner dan hex.
Gambar 3. Tangkapan layar program dengan bingkai yang ditangkap dari pengiriman TPMS.
Sensor mengirim beberapa pesan satu demi satu dalam satu sesi. Jangka waktu antar sesi bisa sampai satu menit atau lebih. Jika situasi alarm terjadi, sensor segera mulai mengirim paket data. File suara pesan dari sensor [8]. Contoh salah satu pesan dari sensor yang diambil dari program URH:
010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101011001100110100110101001011001011010011010100110101001100101010101011010010101010101010110101001011001101010010101100101101001010101011001011001100110101001Dalam bentuk heksadesimal, premis ini akan berbentuk:
5555555555555555555555555555555555555555555555555555555555555555555556669a965a6a6a6555a5555a966a565a556599a9Terbukti bahwa keempat paket dalam satu sesi memiliki data yang sama, artinya paket tersebut diterima dengan benar dan Anda dapat mulai menganalisisnya.
Pada contoh di atas, Anda dapat melihat pembukaan (urutan 01010101….), Diikuti oleh data. Setelah membaca Internet, kami memahami bahwa kami memiliki paket yang dikodekan dengan pengkodean Manchester (GE Thomas). Setiap bit dikodekan dengan dua bit 01 atau 10. Saya awalnya dikodekan dengan tangan, sehingga memperkuat teori encoding / decoding. Tapi kemudian saya memutuskan untuk beralih ke dekoder online [4,5,6], yang sangat mempercepat prosesnya.
Jadi, decoding pesan asli dari sensor dengan kode Manchester, kita dapatkan
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010101101110010011011101110100000011000000001110010111000100110000010010101110136 angka nol pertama adalah pembukaan dan dapat dibuang. Kami hanya tertarik pada data.
Menerjemahkannya ke dalam bentuk heksadesimal, kita dapatkan: 0x15B937740C03971304AE
Ini sudah memiliki data awal yang bagus, di mana pengenal, tekanan ban, dan suhu disembunyikan di suatu tempat.
Untuk penelitian selanjutnya perlu dilakukan pengumpulan data statistik. Untuk melakukan ini, saya melilitkan satu sensor ke roda dan menangkap udara, sambil merekam apa yang ditunjukkan oleh papan sistem asli. Dia melepaskan tekanan, memompanya, meletakkan roda di freezer untuk suhu negatif, memanaskannya. Kemudian ia mencari kondisi yang sama untuk sensor lain untuk mengetahui suhu dan tekanan byte.
Seluruh paket membutuhkan 10 byte. Jika Anda berbaris menerima data yang didekodekan dalam kolom, Anda bisa melihat data konstan dan data berubah.
15B937740C03971304AE
15B937740C03A1FC00A4
15B937740C03A700087BAda stiker di sensor di bodi. Setiap sensor berbeda: 0A, 1B, 2C, 3D.
Pemikiran stereotip di sini tidak berhasil dengan baik. Saya pikir ini adalah ID-sensor.
Saya ragu mengapa ID hanya membutuhkan 1 byte, tetapi kemudian saya melupakannya dan mencoba mencari pengenal ini di aliran. Kemudian, di menu penerima asli sistem, saya melihat bahwa sensor lain dapat diikat ke penerima ini, dan penerima itu sendiri menunjukkan ID sensor di setiap roda. Dan, lihatlah, saya menemukan bahwa sensor roda keempat memiliki ID = 3774.
15B937740C03971304AEJadi byte ke-3 dan ke-4 dari paket tersebut adalah ID roda. Dibandingkan dengan sensor lain dan juga pengenalnya bertepatan dengan yang ditampilkan oleh panel standar.
Saya menghitung byte pertama sebagai awalan awal data, dan byte kedua sebagai pengenal subsistem TPMS.
Di bawah ini adalah perbandingan bidang dari berbagai sensor.
15B9F3FA2300BE1B007BSensor 0A ID = 0xF3FA
15B91AA43201B71B002ASensor 1B ID = 0x1AA4
15B9ABFF32027B1B029BSensor 2C ID = 0xABFF
15B937740C03971304AESensor 3D ID = 0x3774
Dan saya menyadari bahwa tulisan pada sensor (0A, 1B, 2C, 3D) hanyalah nomor roda dalam bentuk digital dan dalam abjad, bukan heksadesimal. roda id. Namun, bagaimanapun, byte ke-6 dalam paket tersebut sangat mirip dengan nomor seri sensor. Bagi saya sendiri, saya menyimpulkan bahwa ini adalah pengenal roda. Jadi, satu byte lagi didekodekan.
Byte terakhir kemungkinan besar adalah checksum, yang saya belum tahu cara membacanya. Ini tetap menjadi misteri bagi saya sampai akhir.
Byte yang diterjemahkan berikutnya adalah suhu roda. Beruntung disini. Temperatur membutuhkan 1 byte dan disajikan dalam derajat penuh. Temperatur negatif di dua komplemen. Artinya suhu -127 ... 128 derajat Celcius akan muat dalam satu byte.
Dalam paket kami, suhunya adalah byte ke-8
15B9F3FA2300BE1B007B0x1B sesuai dengan +27 derajat
15B937740C03A1FC00A40xFC sesuai dengan -4 derajat
Ada tiga byte yang tidak dikenal ke-5, ke-7, ke-9. Dilihat dari dinamika perubahannya, tekanan ban tersembunyi dalam 7 byte, dan dalam byte ke-9, kemungkinan besar, bit status sensor. Menurut berbagai sumber informasi di Internet, serta fungsionalitas sistem TPMS saya, seharusnya ada sedikit baterai yang habis, sedikit kehilangan tekanan yang cepat dan beberapa bit lagi yang tidak jelas untuk apa.
Jadi, kami akan menganalisis byte ke-7, sejak maksud kami tekanan itu bersembunyi di dalamnya.
Setelah mengetik statistik pada sensor berbeda dengan tekanan berbeda, saya tidak dapat dengan jelas mendefinisikan rumus yang menghitung ulang tekanan. Dan tidak jelas di unit default mana sensor mentransmisikan tekanan (Bar, PSI). Akibatnya, tabel yang dibangun di Excel tidak memberikan hasil yang sama persis dengan papan skor TPMS standar. Seseorang dapat mengabaikan perbedaan 0,1 Bar ini, tetapi saya menginginkan konsep protokol hingga bagian terakhir. Kegembiraan menang.
Jika Anda tidak dapat memahami bagaimana byte tekanan terbentuk, maka Anda perlu membuat emulator sensor tekanan dan, mengubah nilai tekanan, lihat apa yang ditampilkan panel standar.
Tetap mencari tahu tujuan byte ke-5 dan ke-9 dari paket, tetapi mereka jarang berubah, sehingga Anda dapat menerima nilainya seperti dalam paket asli, hanya mengubah byte tekanan. Sekarang pertanyaannya hanya dalam menghitung checksum. Tanpanya, panel standar akan mengabaikan paket saya dan tidak menampilkan apa pun.
Untuk meniru sensor, Anda harus mengirim paket. Untuk ini saya memiliki transceiver SI4432 yang terhubung ke PIC16F88, yang pernah digunakan untuk tujuan lain.
Gambar 4. Foto papan tes
Menggunakan praktik transfer data lama, saya membuat sketsa program untuk PIC yang mentransmisikan salah satu paket yang saya terima dengan program URH. Beberapa saat setelah menyalakan pemancar, panel menampilkan data yang ditransfer ke pemancar itu! Tapi ini adalah paket yang sudah jadi dengan CRC yang sudah jadi, dan untuk mengubah byte tekanan, saya juga perlu menghitung ulang CRC.
Saya mulai membaca, mencari informasi tentang CRC mana yang digunakan, mencoba Xor yang berbeda, dan seterusnya, tetapi tidak ada yang berhasil. Saya sudah berpikir bahwa tidak ada yang akan berhasil dan harus puas dengan tekanan yang saya terima menurut tabel saya, tetapi sedikit berbeda dari papan skor asli. Tapi di Internet saya melihat artikel tentang pemilihan CRC. Ada sebuah program yang Anda berikan beberapa paket, dan ia mencoba menemukan checksum dan, jika berhasil, mengeluarkan nilai polinomial dan nilai inisialisasi CRC. [7] Kami
memberikan program beberapa paket:
reveng -w 8 -s 15B9ABFF3202AA1B0017 15B9ABFF3202AA1B0249 15B9F3FA2300D01A00D8 15B937740C037B130089 15B937740C03BD18025E 15B9ABFF32028F150834Masalah program:
width=8 poly=0x2f init=0x43 refin=false refout=false xorout=0x00 check=0x0c residue=0x00 name=(none)Saya menulis program untuk menghitung CRC dengan mempertimbangkan data ini dan menjalankannya melalui paket-paket, yang saya terima sebelumnya - semuanya datang bersama-sama!
// CRC
crc=0x43; //
for(j=0;j<9;j++)
{
crc ^= tmp[j];
for(i=0;i<8;i++)
crc=crc&0x80 ? (crc<<1)^0x2F : crc<<1; // 0x2F CRC
}Tangan gatal untuk mengirimkan data tekanan. Setelah menyelesaikan program tes dengan perhitungan CRC, saya mengirimkan paket pertama. Panel OEM menerima sinyal dan menampilkan tekanan dan suhu. Masalah kecil adalah bahwa panel standar memiliki satu tempat desimal dan, saat mentransmisikan nilainya ke udara, layar selalu menampilkan tekanan yang sama, karena sisa pembuangan tidak terlihat. Nilai byte lulus 0..255. Tapi sekali lagi entah bagaimana tidak jelas. Ternyata tekanan 0,00 Bar dimulai ketika byte ke-7 berisi nilai 97. Tidak jelas mengapa demikian. Tapi kemudian semuanya jelas dengan resolusi 0,01 Bar.
Byte P Pressure, Bar
255 1.58
254 1.57
... ...
107 0.10
106 0.09
105 0.08
104 0.07
103 0.06
102 0.05
101 0.04
100 0,03
99 0,02
98 0,01
97 0,00
Dilihat dari tabel, tekanan maksimum yang sesuai dalam satu byte hanya 1,58 Bar, tetapi sistem memungkinkan Anda mengukur tekanan hingga 4 Atm. Ini berarti bahwa 1 bit dari bit paling signifikan disembunyikan di tempat lain. Tidak ada keinginan untuk memeriksa semua byte dan mengubah bit di dalamnya. Sebuah roda dari mobil ditemukan, sensor terluka di atasnya, sinyal ditangkap. Keingintahuan menang, dan dalam pikiran saya, saya bertaruh di mana ketukan akan muncul. Dan itu akan menjadi tepat satu bit, dan bukan skema pengkodean lainnya.
Setelah decoding paket, saya melihat bit ini. Ini adalah bit ke-7 dari byte ke-6. Artinya, byte ke-6 tidak hanya berisi nomor roda, tetapi juga tekanan ban yang paling signifikan.
15B937740C833C18025C
Bit paling signifikan dari 0x83 dan 0x3C menghasilkan 0x13C = 219 yang sesuai dengan tekanan 2,19 Bar
Rumus konversi tekanan ke Bar: P = (ADC-97) / 100,
Dimana ADC = (B7 >> 7) * 0x100 + B6, dimana B6 dan B7 adalah nilai byte 6 dan byte 7.
Dengan nilai 511 kita memiliki tekanan maksimum 4 , 14 Bar. Juga tidak jelas mengapa batangnya 4,14 Bar, tapi saya rasa ini sama dengan 4 atm - tekanan maksimum yang diizinkan untuk sensor.
Itu tetap untuk memahami apa bit status bertanggung jawab. Bit diperoleh dengan mengeluarkan tekanan, menghubungkan sensor ke catu daya yang diatur dan mengurangi tegangan. 2 bit tetap tidak jelas. Mungkin ada lebih banyak, tetapi mereka tidak pernah menerima nilai satu nilai selama keseluruhan percobaan.
Untuk menyederhanakan analisis, sebuah program ditulis [8]
Gbr.5. Munculnya antarmuka program untuk memeriksa paket TPMS
Anda dapat mengatur paket mentah dari program URH ke dalam program dalam bentuk heksadesimal dan program menerjemahkan paket, membaca checksum dan menampilkan data dalam suhu normal dan unit tekanan.
Entah bagaimana saya kembali ke menu panel standar dan melihat bahwa pengenal sensor bukanlah dua byte, tetapi empat. Panel memiliki indikator besar dan kecil dan saya tidak segera menyadari bahwa byte ke-2 dan ke-5 juga termasuk dalam ID sensor.
15B937740C833C18025C
Jadi, hanya byte pertama yang tetap tidak dikenali, tetapi selalu 0x15 (0b010101), dan ini terlihat seperti pembukaan tertentu dari sebuah paket atau pengenal awalnya.
Juga, bit status tidak dikenali dengan tepat, tetapi bit status yang hilang.
Keingintahuan untuk mencari tahu apa yang ada di dalam sensor dan saya membongkar salah satunya (Gbr . 6) Gbr. 6
. Sensor TPMS
Ini didasarkan pada sirkuit mikro Infineon SP372 dengan pengikat kecil. Pencarian untuk dokumentasi sirkuit mikro khusus ini tidak menghasilkan apa-apa. Yang saya temukan adalah survei atau iklan. Jadi tidak mungkin untuk mencari tahu tentang protokolnya. Tetapi artikel menyebutkan bahwa ini adalah pengontrol yang dapat diprogram, jadi programnya bisa apa saja. Karena itu, saya tidak berani membeli sirkuit mikro secara terpisah.
Protokol
Sekarang tentang menerima data dari sensor ke transceiver SI4432. Awalnya direncanakan untuk menerima data mentah dari SI4432 sehingga pengontrol memecahkan kode Manchester dan mengumpulkan byte. Tetapi transceiver ini memiliki fungsi pemrosesan paket. Artinya, untuk transmisi, Anda dapat mengkonfigurasi pemancar ke frekuensi yang diinginkan, modulasi, deviasi, mengatur panjang pembukaan, pengkodean, kata sinkronisasi, kecepatan bit, panjang data. Kemudian tulis paket data asli ke dalam buffer pemancar (misalnya, 15B937740C833C18025C kami) dan mulai transmisi. Transceiver itu sendiri akan membentuk sebuah paket dan menyiarkannya, mengamati semua parameter yang ditentukan, sedangkan pengontrol saat ini bebas untuk memproses informasi lain.
Idealnya, saya ingin menerima pemrosesan data batch dari SI4432 selama penerimaan. Bagi penerima untuk menerima paket dan menghasilkan interupsi bahwa paket telah diterima. Kemudian pengontrol hanya membaca buffer penerima, yang telah menyimpan data dalam bentuk murni, sehingga membebaskan waktu prosesor untuk fungsi lainnya.
Saya mulai mempelajari pengaturan register untuk pengoperasian transceiver untuk penerimaan. Ini ternyata jauh lebih sulit daripada mentransfer paket. Di sini Anda perlu mengetahui dengan baik teori penerimaan radio, yang tidak saya miliki. Ada tabel untuk menghitung register di Excel untuk transceiver ini, tetapi tabel tersebut tidak berfungsi karena fakta bahwa Excel adalah bahasa Rusia, atau terpotong. Ada juga aplikasi dari pengembangnya, tetapi semuanya juga tidak terlalu transparan. Setelah melalui banyak contoh dan melihat tabel perhitungan, saya membaca nilai register secara manual sesuai dengan dokumentasi.
Saya menghubungkan logger ke output penerima dan menangkap udara, tergantung pada apa yang diberikan oleh penerima. Hasilnya, saya berhasil mengkonfigurasi filter penerima sehingga paket saya bisa lewat. Dia memanipulasi laju aliran, mengalahkan rebana. Teorinya, sayangnya, masih belum jelas bagi saya.
Agar penerima dapat menerima paket data, penerima harus menentukan panjang pembukaan, kata sinkronisasi yang harus ada, dan panjang data. Penerima juga dapat membaca checksum itu sendiri, tetapi dalam SI4432 algoritme kalkulasi tidak sesuai dengan algoritme CRC sensor tekanan.
Kehadiran kata sinkronisasi dua-byte yang wajib dapat menutupi gagasan untuk menerima paket, tetapi di sini beruntung bahwa pengiriman dari sensor dimulai pada 0x15B9 (15B937740C833C18025C) dan sama untuk semua sensor. Ini berarti 0x15B9 telah ditentukan untuk kata sinkronisasi. Panjang paket data adalah 8 byte, analisis checksum dinonaktifkan. Kami mengatur pembuatan interupsi saat menerima paket dan memulai prosedur penerimaan.
Ketika penerima menerima pembukaan, sinkronisasi kata 0x15B9 dan 8 byte data, itu akan mengeluarkan interupsi ke pengontrol utama, yang hanya membaca 8 byte data dari buffer penerima. Selanjutnya, pengontrol utama akan menghitung checksum, membandingkannya, dan memecahkan kode data yang diterima. Untungnya, semuanya berjalan sesuai rencana!
Gambar 7. Foto indikator TPMS standar dan tampilan kereta dorong "pintar"
Berikut adalah contoh inisialisasi transceiver SI4432 untuk menerima:
WriteSI4432(0x06, 0x05); // interrupt all disable
WriteSI4432(0x07, 0x01); // to ready mode
WriteSI4432(0x09, 0x7f); // cap = 12.5pf
WriteSI4432(0x0A, 0x06); // uC CLK: 1 MHz
WriteSI4432(0x73, 0x00); // no frequency offset
WriteSI4432(0x74, 0x00); // no frequency offset
WriteSI4432(0x75, 0x53); // 430-440MHz range
WriteSI4432(0x76, 0x62); // 0x621A-433.924
WriteSI4432(0x77, 0x1A); //
WriteSI4432(0x79, 0x00); // no frequency hopping
WriteSI4432(0x7a, 0x00); // no frequency hopping
// 9090/2
WriteSI4432(0x1C, 0x81); // 01 IF Filter Bandwidth
WriteSI4432(0x1D, 0x44); // 44 AFC Loop Gearshift Override
WriteSI4432(0x1E, 0x0A); // 0A AFC Timing Control
WriteSI4432(0x1F, 0x05); // 00 Clock Recovery Gearshift Override
WriteSI4432(0x20, 0x28); // 64 Clock Recovery Oversampling Ratio
WriteSI4432(0x21, 0xA0); // 01 Clock Recovery Offset 2
WriteSI4432(0x22, 0x18); // 47 Clock Recovery Offset 1
WriteSI4432(0x23, 0xD2); // AE Clock Recovery Offset 0
WriteSI4432(0x24, 0x08); // 12 Clock Recovery Timing Loop Gain 1
WriteSI4432(0x25, 0x19); // 8F Clock Recovery Timing Loop Gain 0
WriteSI4432(0x2A, 0x00); // 00 AFC Limiter
WriteSI4432(0x69, 0x60); // 60 AGC Override 1
WriteSI4432(0x70, 0x26); // Manchester,
WriteSI4432(0x71, 0x22); // FSK, FIFO
WriteSI4432(0x72, 31); // 31*625=19375 ( )
WriteSI4432(0x34,10); // 10 - 4-
WriteSI4432(0x35,0x1A); // preambula threshold
WriteSI4432(0x36,0x15); // 3 0x15
WriteSI4432(0x37,0xB9); // 2 0xB9
WriteSI4432(0x27,0x2C); // RSSI
//
WriteSI4432(0x33, 0x0A); // fixpklen=1, Synchronization Word 3 and 2
WriteSI4432(0x32, 0x00); //
WriteSI4432(0x30, 0x80); // Skip2ph, Enable Packet RX Handling=0 ( Skip2ph...)
WriteSI4432(0x3E, 0x08); // 8
WriteSI4432(0x0B, 0x12); // GPIO0 TX
WriteSI4432(0x0C, 0x15); // GPIO1 RX
// FIFO TX
WriteSI4432(0x08, 0x01);// 0x01 Operating Function Control 2
WriteSI4432(0x08, 0x00);// 0x00 Operating Function Control 2
// FIFO RX
WriteSI4432(0x08, 0x02);// 0x02 Operating Function Control 2
WriteSI4432(0x08, 0x00);// 0x00 Operating Function Control 2
// : , ,
WriteSI4432(0x05, 0x02); //
WriteSI4432(0x06, 0x00);
// , NIRQ . 1
SI4432_stat[0] = ReadSI4432(0x03);
SI4432_stat[1] = ReadSI4432(0x04);
WriteSI4432(0x07, 0x05); //
Penerimaan datanya sendiri akan terlihat seperti ini:
if (si_int) // SI4432
{
//
SI4432_stat[0] = ReadSI4432(0x03);
SI4432_stat[1] = ReadSI4432(0x04);
SI4432_RSSI = ReadSI4432(0x26);
if (SI4432_stat[0]&0x02)
{
WriteSI4432(0x07, 0x01); // . . ,
SI4432_ReadFIFO(); // FIFO 8
TPMS_Parsing(); // CRC
// FIFO
WriteSI4432(0x08, 0x02); // 0x02 Operating Function Control 2
WriteSI4432(0x08, 0x00); // 0x00 Operating Function Control 2
//WriteSI4432(0x07, 0x05); //
}
else
{
// FIFO TX
WriteSI4432(0x08, 0x01);// 0x01 Operating Function Control 2
WriteSI4432(0x08, 0x00);// 0x00 Operating Function Control 2
// FIFO RX
WriteSI4432(0x08, 0x02);// 0x02 Operating Function Control 2
WriteSI4432(0x08, 0x00);// 0x00 Operating Function Control 2
}
if (SI4432_stat[0]&0x80)
{
// FIFO RX
WriteSI4432(0x08, 0x02);// 0x02 Operating Function Control 2
WriteSI4432(0x08, 0x00);// 0x00 Operating Function Control 2
}
WriteSI4432(0x07, 0x05); //
si_int=0;
}Fungsi SI4432_ReadFIFO () hanya membaca 8 byte dari buffer penerima, yang berisi data dari sensor.
Fungsi TPMS_Parsing () menganalisis checksum dan menerjemahkan informasi menjadi unit tekanan dan suhu akhir, serta informasi status.
Masalah
- Saat membaca informasi tentang sensor, disebutkan sinkronisasi sensor satu sama lain. Untuk beberapa alasan perlu memasangkan sensor, ada sesuatu tentang kecepatan lebih dari 20 km / jam selama 30 menit. Tidak jelas mengapa ini perlu. Mungkin ini karena momen transfer informasi, tapi ini tebakan saya.
- Tidak menemukan sampai akhir fungsi bit status sensor tekanan.
- Tidak jelas tentang pengaturan transceiver SI4432 untuk penerimaan, tentang baud rate yang menggunakan pengkodean Manchester. Ini berhasil untuk saya, tetapi belum ada kesadaran akan prinsipnya.
Hasil pekerjaan
Penelitian yang dibahas dalam artikel ini membutuhkan waktu luang sekitar satu bulan.
Sebagai hasil dari studi protokol sistem pemantauan tekanan ban, masalah transmisi dan penerimaan data melalui udara diangkat, pengkodean sinyal dipertimbangkan secara singkat, transceiver SI4432 diuji untuk transmisi dan penerimaan. Tugas ini memungkinkan TPMS diintegrasikan ke dalam proyek utama kereta dorong bayi pintar. Mengetahui protokol pertukaran, Anda dapat menghubungkan lebih banyak sensor dan mengintegrasikannya ke dalam pengembangan Anda. Selain itu, tekanan yang dikendalikan dapat berada dalam batas lebar, dan tidak seperti pada sistem standar 1.1-3.2 Bar, karena tekanan di luar kisaran ini disertai dengan derit yang mengkhawatirkan dari sistem unit pusat standar. Selain itu, TPMS kini dapat digunakan untuk memantau tekanan ban sepeda motor, sepeda atau, misalnya, kasur udara. Yang tersisa hanyalah memasang sensor secara fisik dan menulis program tingkat atas.
Tautan
- Kereta bayi "Cerdas" "Maksimka"
- github.com/jopohl/urh
- habr.com/ru/company/neuronspace/blog/434634
- www.rapidtables.com/convert/number/hex-to-binary.html
- www.rapidtables.com/convert/number/binary-to-hex.html
- eleif.net/manchester.html
- hackaday.com/2019/06/27/reverse-engineering-cyclic-redundancy-codes
- Utilitas saya, paket sampel, pemilihan CRC. Arsipkan sandi "tPmSutiLity" dropmefiles.com/MtS9W "
- i56578-swl.blogspot.com/2017/08/eavesdropping-wheels-close-look-at-tpms.html
- www.rtl-sdr.com/tag/tpms