TinyLiDAR untuk IoT: 3 Langkah

2024 Pengarang: John Day | [email protected]. Terakhir diubah: 2024-01-30 09:57

Jika Anda melihat-lihat, Anda akan melihat banyak perangkat kecil pintar yang digunakan dalam kehidupan sehari-hari. Mereka biasanya bertenaga baterai dan biasanya terhubung ke Internet (alias 'cloud') entah bagaimana. Ini semua adalah apa yang kami sebut perangkat 'IoT' dan mereka dengan cepat menjadi tempat umum di dunia saat ini.

Untuk Insinyur Sistem IoT, banyak upaya desain dihabiskan untuk mengoptimalkan konsumsi daya. Alasan untuk ini tentu saja karena terbatasnya kapasitas yang tersedia pada baterai. Mengganti baterai dalam jumlah besar di daerah terpencil bisa menjadi proposisi yang sangat mahal.

Jadi instruksi ini adalah tentang mengoptimalkan daya di tinyLiDAR.

TL; DR ringkasan

Kami memiliki mode pengukuran "Real Time" baru (mulai firmware 1.4.0) untuk membantu memaksimalkan runtime baterai di perangkat IoT.

Memeras Lebih Banyak Jus dari Baterai

Secara intuitif, kita dapat meningkatkan runtime hanya dengan mengurangi konsumsi daya perangkat IoT. Oke jadi itu sudah jelas! Tapi bagaimana Anda bisa melakukan ini secara efektif dan benar menghitung runtime yang diharapkan? Mari kita cari tahu…

Langkah 1: Energi Murni

Ada banyak cara untuk melakukan ini, tetapi kami lebih suka memecahnya ke dasar-dasarnya dan mengubah semuanya menjadi energi. Energi listrik diukur dalam Joule (simbol J) dan menurut definisi:

Joule adalah energi yang hilang sebagai panas ketika arus listrik satu amp melewati hambatan satu ohm selama satu detik.

Karena energi (E) juga merupakan tegangan (V) x muatan (Q), kita peroleh:

E = V x Q

Q adalah Arus (I) x waktu (T):

Q = I x T

Jadi energi dalam Joule dapat dinyatakan sebagai:

E = V x I x T

di mana V adalah tegangan, I adalah arus dalam Amps dan T adalah waktu dalam detik.

Mari kita asumsikan kita memiliki baterai yang terdiri dari empat baterai AA alkaline (LR6) yang dihubungkan secara seri. Ini akan memberi kita tegangan awal total 4*1.5v = 6v. Akhir masa pakai baterai AA alkaline adalah sekitar 1.0v sehingga tegangan rata-rata akan menjadi sekitar 1.25v. Menurut lembar data mfr "Kapasitas terkirim tergantung pada beban yang diterapkan, suhu pengoperasian, dan tegangan pemutusan." Jadi kita dapat mengasumsikan sekitar 2000mAhr atau lebih baik untuk aplikasi menguras rendah seperti perangkat IoT.

Oleh karena itu kita dapat menghitung bahwa kita memiliki 4 sel x 1,25V per sel x 2000mAhr * 3600sec = 36000 J energi yang tersedia dari baterai ini sebelum harus diganti.

Demi perhitungan yang lebih sederhana, kami juga dapat mengasumsikan efisiensi konversi adalah 100% untuk regulator sistem kami dan mengabaikan konsumsi daya pengontrol host.

Sepatah Kata Tentang Bersepeda

Tidak, bukan tipe yang Anda tunggangi! Ada beberapa konsep teknis yang dikenal sebagai "Power Cycling" dan "Sleep Cycling". Keduanya dapat digunakan untuk menurunkan konsumsi daya tetapi ada perbedaan di antara keduanya. Yang pertama melibatkan mematikan perangkat Anda sampai diperlukan dan kemudian menyalakannya hanya untuk waktu yang singkat untuk melakukan pengukuran, dll. Meskipun metode ini menggoda untuk digunakan karena arus nolnya, ada kekurangannya di mana itu akan memakan waktu. jumlah waktu yang tidak sepele untuk mem-boot kembali dan membakar energi saat melakukannya.

Konsep kedua melibatkan hanya menjaga perangkat dalam mode tidur dengan harapan akan bangun lebih cepat tetapi Anda akan membakar sejumlah arus saat sedang tidur. Jadi mana yang terbaik untuk digunakan?

Itu tergantung pada seberapa sering Anda perlu bangun.

Langkah 2: Jalankan Angka

Kami ingin mencari energi total (E) yang dinormalisasi menjadi 1 detik untuk setiap pemandangan yang tercantum di bawah ini.

Kasus A: Tc = 1 detik; lakukan pengukuran jarak setiap detik Kasus B: Tc = 60sec; melakukan pengukuran jarak setiap menit. Kasus C: Tc = 3600 detik; melakukan pengukuran jarak setiap jam.

Untuk melakukan ini, kita dapat mengatakan Tc adalah waktu siklus untuk pengukuran kita, ton waktu aktif dan mati waktu tidak aktif dan atur ulang rumus energi kita seperti yang ditunjukkan di sini:

Untuk tinyLiDAR, waktu start up adalah sekitar 300ms atau kurang dan selama waktu ini akan memakan waktu rata-rata 12.25mA saat beroperasi dari suplai 2.8v yang diatur. Oleh karena itu akan mengkonsumsi sekitar 10,3mJ energi untuk setiap startup.

Arus tidur/diam untuk tinyLiDAR adalah 3uA yang sangat rendah. Ini jauh lebih rendah daripada tingkat self-discharge bulanan 0,3% dari baterai alkaline jadi kami akan menyelidiki hanya menggunakan metode "bersepeda tidur" di sini.

Mengapa tidak membuang mikro dan langsung ke sensor VL53?

Jawaban untuk ini tidak begitu jelas. Pada hari-hari awal pengembangan smartphone, kami belajar bahwa menjaga agar prosesor berkecepatan tinggi yang haus daya tetap hidup untuk memutar mp3 adalah metode yang pasti untuk mengurangi masa pakai baterai. Bahkan saat itu kami berusaha semaksimal mungkin untuk menggunakan "prosesor aplikasi" berdaya rendah untuk tugas periferal seperti memutar musik. Ini tidak jauh berbeda hari ini dan bahkan, Anda bisa mengatakan itu bahkan lebih penting karena kami mengecilkan semua perangkat IoT ini dengan setiap penurunan kapasitas baterai. Jadi, menggunakan prosesor aplikasi berdaya sangat rendah untuk satu-satunya tugas mengendalikan sensor VL53 dan menyediakan data yang siap untuk diproses lebih lanjut adalah aset yang pasti untuk aplikasi bertenaga baterai apa pun.

Mode Pengukuran tinyLiDAR

Ini mungkin tidak jelas dalam manual pengguna saat ini [tetapi akan di beberapa titik karena kami selalu memperbarui panduan pengguna kami:)] -- sebenarnya ada 3 mode pengukuran yang berbeda di tinyLiDAR.

Modus MC

Sejak awal tinyLiDAR, kami terobsesi untuk mencoba mendapatkan pengukuran yang lebih cepat dari sensor VL53 ToF. Jadi kami mengoptimalkan firmware kami untuk mendapatkan data streaming tercepat dan paling konsisten darinya. Ini melibatkan memperkenalkan buffering. Sedikit buffering adalah hal yang baik karena memungkinkan pengontrol host (yaitu Arduino) untuk mendapatkan data pengukurannya dalam sekejap dan beralih ke hal-hal yang lebih penting. Oleh karena itu buffering mutlak diperlukan dan karena ini kami dapat mencapai kecepatan streaming lebih dari 900Hz bahkan pada Arduino UNO yang relatif lambat. Oleh karena itu, waktu respons tercepat adalah dengan menggunakan MC tinyLiDAR atau mode "berkelanjutan".

BTW, jika Anda pernah mendapatkan kesempatan, Anda harus menghubungkan kabel serial ke pin output TTY di tinyLiDAR dan Anda akan melihat apa yang dilakukan mode MC ini. Ini benar-benar membutuhkan pengukuran secepat mungkin dan dengan melakukan itu, itu mengisi buffer I2C dengan data terbaru yang mutlak. Sayangnya, karena berjalan dengan kecepatan penuh, ia juga membakar jumlah daya maksimum. Lihat di bawah untuk grafik saat ini vs waktu dari mode MC ini.

Modus SS

Mode berikutnya adalah apa yang kita sebut "SS" untuk mode "satu langkah". Ini pada dasarnya adalah mode kinerja tinggi yang sama di atas tetapi dalam satu putaran loncatan saja. Jadi Anda bisa mendapatkan respons cepat dari tinyLiDAR tetapi data akan berasal dari sampel sebelumnya sehingga Anda harus melakukan dua pengukuran untuk mendapatkan data terbaru. Lihat di bawah untuk grafik saat ini vs waktu dari mode SS ini.

Kedua mode di atas cocok untuk sebagian besar pengguna karena cepat dan mudah digunakan - cukup keluarkan perintah "D" dan baca hasilnya. Namun …

Bergerak maju ke dunia IoT di mana setiap mili-Joule penting, kami memiliki paradigma baru.

Dan ini kebalikan dari kode yang kami buat di tinyLiDAR! Untuk dunia IoT, kami membutuhkan pengukuran tunggal pada interval yang jarang untuk menghemat daya dan memperpanjang waktu proses.

Modus RT

Untungnya, sekarang kami dapat mengatakan bahwa kami memiliki solusi untuk skenario ini pada firmware 1.4.0. Ini disebut mode "RT" untuk pengukuran "waktu nyata". Dan pada dasarnya menerapkan metode pemicu, tunggu, dan baca. Untuk menggunakannya, Anda masih bisa mengeluarkan perintah "D" untuk memulai pengukuran, tetapi untuk mode RT ini Anda harus menunggu waktu yang sesuai hingga pengukuran selesai dan kemudian membaca hasilnya. tinyLiDAR secara otomatis beralih ke keadaan diam terendah dari sub 3uA di antara sampel. Ini sebenarnya masih mudah digunakan dan bahkan lebih hemat energi sekarang karena Anda hanya perlu melakukan satu pengukuran, bukan dua untuk mendapatkan data terbaru, yaitu nol buffering.

Lihat di bawah untuk grafik saat ini vs waktu dari mode RT baru ini.

Langkah 3: Pengukuran Sebenarnya

Menggunakan mode kontinu MC untuk pengukuran IoT yang jarang tidak masuk akal karena kita hanya membutuhkan pengukuran tunggal. Oleh karena itu, kita dapat memfokuskan perhatian kita pada mode SS dan RT. Mengoperasikan tinyLiDAR dari pasokan teregulasi +2.8v memberi kami disipasi daya terendah. Jadi dalam menggunakan preset Akurasi Tinggi (200ms), kami mengukur konsumsi energi berikut di tinyLiDAR:

SS/mode satu langkah: 31,2 mJ rata-rata selama 2 pengukuran

RT/mode real-time: 15.5mJ rata-rata lebih dari 1 pengukuran

Memasukkan nilai-nilai di atas ke dalam rumus energi kami dan menormalkan ke satu detik, kami dapat menemukan harapan runtime dengan asumsi energi dari paket baterai kami adalah 36000 J.

Kasus A: membaca setiap detik (mengambil 2 pembacaan untuk mendapatkan data terbaru)Tc = 1secTon = 210ms per pembacaan x 2 pembacaan Toff = Tc - Ton = 580msIon(avg) = 26,5mA per pembacaan Ioff(avg) = 3uA arus diam Vcc = Tegangan suplai 2.8V Energi aktif yang dikonsumsi oleh beban dalam Joule adalah Eon = Vcc x Ion x Ton = 2.8V x 26.5mA * 420ms = 31.164mJ Energi tidak aktif yang dikonsumsi oleh beban dalam Joule adalah Eoff = Vcc x Ioff x Toff = 2.8V x 3uA x 580ms = 4.872uJ Normalisasi ke TcE = (Eon + Eoff)/Tc = (31.164mJ + 4.872uJ)/1 = 31.169mJ atau 31.2mJ per detik Runtime dalam detik Oleh karena itu, total energi sumber/energi yang dikonsumsi adalah 36000J / 31.2mJ = 1155000 detik = 320 jam = 13,3 hari

Mengulangi perhitungan ini, kita dapat menemukan runtime untuk skenario lain:

Modus SS

Kasus A: 2 Pembacaan per detik. Energi yang dinormalisasi adalah 31.2mJ. Oleh karena itu runtime adalah 13,3 hari.

Kasus B: 2 Pembacaan per menit. Energi yang dinormalisasi adalah 528uJ. Oleh karena itu runtime adalah 2,1 tahun.

Kasus C: 2 Bacaan per jam. Energi yang dinormalisasi adalah 17uJ. Waktu proses dihitung pada >>10 tahun, sehingga pemuatan karena tinyLiDAR dapat diabaikan. Oleh karena itu, paket baterai hanya akan dibatasi oleh umur simpannya (yaitu sekitar 5 tahun)

Modus RT

Kasus A: 1 Membaca per detik. Energi yang dinormalisasi adalah 15,5mJ. Oleh karena itu runtime adalah 26,8 hari.

Kasus B: 1 Membaca per menit. Energi yang dinormalisasi adalah 267uJ. Oleh karena itu runtime adalah 4,3 tahun.

Kasus C: 1 Membaca per jam. Energi yang dinormalisasi adalah 12,7uJ. Waktu proses dihitung pada >>10 tahun, sehingga pemuatan karena tinyLiDAR dapat diabaikan. Oleh karena itu, paket baterai hanya akan dibatasi oleh umur simpannya (yaitu sekitar 5 tahun)

Oleh karena itu, mode Waktu Nyata baru yang menggunakan siklus tidur adalah manfaat di sini untuk memperpanjang waktu kerja selama 4 tahun terakhir jika satu pengukuran dilakukan setiap menit seperti yang ditunjukkan pada Kasus B.

Perhatikan bahwa konsumsi energi pengontrol host tidak diperhitungkan untuk analisis ini dan spesifikasi paket baterai berada di sisi yang konservatif. Anda dapat menemukan baterai yang jauh lebih kuat sesuai keinginan Anda.

Terima kasih telah membaca dan tetap disini karena kami akan memberikan contoh IoT yang berfungsi menggunakan tinyLiDAR untuk instruksi kami berikutnya. Bersulang!