Faktor-faktor apa yang perlu dipertimbangkan ketika memilih wifi MCU terintegrasi untuk perangkat tepi berdaya rendah?

17

Motivasi untuk pertanyaan ini berasal dari kenyataan bahwa beberapa waktu yang lalu saya membuat perangkat bukti ujung konsep sederhana (PoC) IoT menggunakan mikrokontroler dan prosesor jaringan CC3100 Wifi . Salah satu masalah dengan prototipe ini adalah bahwa konfigurasi membutuhkan daya yang cukup besar. Dengan demikian, itu tidak dapat mengatasi manfaat dari perangkat berdaya rendah yang ada yang dapat bertahan selama lebih dari 2 hingga 10 tahun tergantung pada pilihan baterai dan frekuensi penggunaan.

Tergantung pada aplikasinya, produk saat ini menggunakan baterai 6V DC dengan kapasitas antara 1400 mAh dan 2400 mAh. Perangkat ini memiliki elemen pengindera daya rendah dan mekanisme penggerak. Payload kemungkinan besar akan sekitar 100 byte. Frekuensi komunikasi akan sekitar setiap dua menit selama aktivitas puncak. Dengan kemajuan dalam IOT dan permintaan pasar, PoC ini telah mendapatkan perhatian.

Per saran dari beberapa penyedia platform IOT Saya melihat CC3200 MCU nirkabel dari Texas Instrument terutama karena merupakan penerus CC3100. Pada tingkat sistem saat tidak digunakan daya CC3100 dapat sepenuhnya dimatikan. Ini adalah keuntungan yang signifikan untuk daya rendah di level sistem. Ketika aktivitas terdeteksi, elemen penginderaan membangunkan mikrokontroler melalui interupsi. Ada wifi MCU terintegrasi lainnya seperti ESP8266 , BCM43362 , ATWINC1500B , 88MC200 dan banyak lagi. Saya menggunakan Skor ULPBench untuk melakukan analisis urutan pertama dari mikrokontroler daya rendah diikuti oleh analisis seperti yang dijelaskan dalamBagaimana cara memilih pengontrol mikro untuk aplikasi berdaya rendah? untuk membantu memilih mikrokontroler daya rendah. Saya telah menggunakan parameter seperti draw mode aktif saat ini per frekuensi, dan draw current mode daya rendah yang berbeda untuk membuat pilihan yang diinformasikan. Jadi untuk mempertahankan opsi daya rendah dan menambah kemampuan IoT, apa parameter penting (yang mungkin terkait dengan komunikasi nirkabel) yang harus saya perhatikan ketika memilih MCU wifi terintegrasi?

Referensi:

Mahendra Gunawardena
sumber
3
Saya tidak yakin jika saya mengerti benar, komponen apa yang Anda maksudkan (mengingat bahwa CC3200 terdiri dari Aplikasi Mikrokontroler, Prosesor Jaringan Wi-Fi, dan Subsistem Manajemen Daya - sepertinya sudah termasuk sebagian besar yang Anda butuhkan).
Ghanima
1
@ Ganima, Tektronix memiliki Bagaimana Memilih Modul Wi-Fi Anda? panduan. Apakah ada cara memilih panduan modul Wifi Terpadu. Saya dapat menemukannya. Vendor lain memiliki modul wifi terintegrasi, pada saat penulisan saya belum meneliti CC3200. Manfaat menjadi bagian dari komunitas ini adalah memantulkan pertanyaan dan belajar dari pengalaman satu sama lain. Jadi singkatnya, Apa yang membuat A lebih baik daripada B untuk aplikasi IOT untuk aplikasi IOT daya rendah. Apakah ada sesuatu yang lebih baik daripada wifi, contohnya sigfox atau lora?
Mahendra Gunawardena
3
Ini sepertinya terlalu umum bagi saya. Sebagai ujian, bagaimana kita mengidentifikasi jawaban yang baik dari cara yang mungkin untuk menjawab pertanyaan ini?
Sean Houlihane
2
Saya telah membaca pertanyaan Anda beberapa kali dan saya masih tidak mengerti apa yang Anda tanyakan. Kisah pengguna Anda baik-baik saja, tetapi bagian mana dari pengaturan yang Anda tanyakan? Semua yang Anda bicarakan dalam pertanyaan Anda adalah konsumsi daya rendah, jadi "parameter penting" apa yang Anda cari selain konsumsi daya rendah? Saya yakin ada pertanyaan bagus yang mengintai di sini, tetapi setengahnya masih ada di kepala Anda.
Gilles 'SANGAT berhenti menjadi jahat'
2
Apakah energi per instruksi relevan untuk use case Anda? Dengan informasi dalam pertanyaan Anda, itu tidak jelas sama sekali. Jika Anda tidak melakukan banyak perhitungan maka itu dapat dikerdilkan dengan daya siaga dan terutama oleh radio.
Gilles 'SANGAT berhenti menjadi jahat'

Jawaban:

8

Karena kendala terpenting Anda adalah memiliki konsumsi daya yang rendah, saya pikir Anda sudah memperhatikan 2 parameter terpenting: penarikan arus mode aktif per frekuensi, dan penarikan arus pada berbagai mode daya rendah.

Memegang komunikasi sebagai sebuah konstanta (yaitu protokol komunikasi dan frekuensi EM yang sama), lalu memilih MCU terbaik hanyalah masalah menggabungkan kedua parameter dengan benar. Dan inilah cara saya membuat nilai numerik tunggal yang dapat saya bandingkan di semua opsi:

  1. Buat profil aktivitas yang diproyeksikan untuk perangkat (seberapa sering berkomunikasi dan untuk berapa lama) selama periode - katakan selama seminggu.
  2. Hitung penarikan saat ini pada frekuensi EM yang digunakan untuk waktu selama periode yang dipilih saat komunikasi aktif - yaitu penarikan 10 uA (frekuensi @ 900 MHz) untuk durasi 2 detik pada 1000 x aktivitas dalam seminggu akan berarti 20.000 uA-s / minggu.
  3. Hitung penarikan saat ini untuk waktu selama periode yang dipilih ketika perangkat berada pada mode daya rendah default - yaitu undian 10 nA pada [7 hari x 24 jam x 60 menit x 60 s - aktivitas 1000 x 2] berarti 6,028 uA -s / minggu.
  4. Menambahkan 2 hasil imbang saat ini 26.028 uA-s / minggu untuk MCU hipotetis ini.
  5. Undian saat ini mingguan yang dihitung kemudian dapat dibandingkan untuk semua MCU.

Saya tahu ini adalah cara yang sangat sederhana untuk melihat aktivitas MCU - yaitu hanya dianggap 2 negara: menganggur dan berkomunikasi ... tapi saya percaya negara-negara lain akan memiliki kontribusi proporsional dan kecil untuk salah satu dari ini 2. Misalnya, daya digunakan untuk perhitungan (siklus instruksi) dapat digabungkan bersama dengan keadaan komunikasi dan kemungkinan besar akan memiliki kontribusi yang sangat kecil dalam hal kekuatan dibandingkan dengan sub-sistem komunikasi. Intinya adalah, melihat 2 status ini sudah cukup untuk proses seleksi.

leon.valencia
sumber
5

Tidak ada peluru ajaib, jadi saya pikir sarannya akan sangat jelas. Mulailah memilah-milah konsumen dengan daya terbesar.

Apakah Anda benar-benar mematikan semua chip dan sirkuit saat idle? Saya tahu beberapa papan hobi dan perisai tidak selalu sepenuhnya mematikan semua yang Anda harapkan.

Jika itu aktuator, dapatkah Anda menggunakan motor bertenaga lebih ringan, atau mengurangi gesekan pada drive train? Gambaran yang lebih besar, dapatkah Anda merekayasa ulang beban yang digerakkan agar memiliki massa yang lebih sedikit, atau agar lebih seimbang?

Jika itu komunikasi, mulailah dengan melihat frekuensi komunikasi. Faktor-faktor apa yang mendorong keputusan "dua menit" yang ada? Bisakah Anda berkorban untuk berkomunikasi lebih jarang? Bisakah Anda beralih ke model sub-pub, dan merespons dengan byte lebih sedikit ketika kondisi mengizinkan?

Evaluasi kembali protokolnya. Setiap byte yang Anda cukur mewakili penghematan 1% dari anggaran daya RF Anda saat ini. Mengirim nilai Boolean? Gunakan bendera bit, bukan ASCII 'Y' atau 'N'. Pastikan Anda menggunakan wadah sekecil mungkin - jangan mengirimkan bilangan bulat 16-bit jika nomor tersebut hanya memiliki rentang yang diizinkan hanya 0-99. Kebanyakan protokol bertenaga baterai mencoba menekannya sejauh mungkin; mis. jika Anda melaporkan array elemen 5x5, alamat hanya perlu bidang 5-bit, bukan byte 8-bit. Menggunakan siklus CPU untuk logika yang terkait dengan kompresi menghasilkan penarikan daya keseluruhan yang jauh lebih rendah daripada mentransmisikan bit yang tidak dibutuhkan.

Jika daya yang besar adalah CPU (ragu-ragu, tetapi mungkin) dapatkah Anda melakukan trik seperti tabel pencarian yang dikomputasi, atau bahkan melepas sebagian pekerjaan ke layanan jarak jauh?

John Deters
sumber
4

Tidak ada satu pun set parameter definitif yang dapat Anda gunakan untuk memilih perangkat terintegrasi seperti ini, tetapi saya pikir sebagai perkiraan pertama, perangkat yang baru dirancang mungkin jauh lebih baik daripada sesuatu dari beberapa tahun yang lalu. Meskipun konsepnya tidak baru, tingkat integrasi ini, dan target kekuatan agresif menjadikannya pasar yang berkembang.

Perhatikan baik-baik kondisi daya yang ditawarkan, dilihat dari perspektif seluruh sistem Anda (regulator, osilator, pengkondisian sinyal sensor). Mungkin (tidak mungkin) bahwa keadaan aktif 2 menit Anda akan mendapat manfaat dari tidur yang kurang nyenyak daripada keadaan operasi normal.

Keadaan bermanfaat daya terendah harus memperhitungkan mayoritas konsumsi energi Anda. Persisnya bagaimana hal ini tergantung pada hal-hal seperti jika Anda dapat beroperasi langsung dari daya tanpa regulator, tegangan operasi minimum, dll.

Untuk keadaan aktif, pertimbangkan sebagian besar RAM Anda atau hitung operasi intensif dan lakukan benchmark menggunakan bagian terdekat yang setara yang dapat Anda temukan (berdasarkan pada CPU, kecepatan, dan arsitektur memori). Dalam aplikasi Anda tampaknya mempersiapkan muatan dan enkripsi mungkin cukup sepele, tetapi secara umum ini bukan asumsi yang jelas. Status retensi mungkin mengizinkan integrasi sensor tanpa status save / restore misalnya.

Sesuaikan kecepatan jam dan arsitektur dengan tuntutan aplikasi Anda. Dalam kondisi tidur, Anda menghemat daya kebocoran. Kecepatan clock target yang lebih rendah untuk suatu perangkat dapat berarti ia harus tetap dalam keadaan aktif lebih lama, tetapi juga menghasilkan desain yang mencapai kinerja kebocoran yang lebih baik (dan mungkin juga tegangan operasi yang lebih rendah).

Anda tidak akan tahu desain terbaik mutlak sampai Anda mengulangi lebih dari satu desain - hanya ada terlalu banyak parameter (dan saat ini, produk Anda akan mulai menjadi tua), sehingga aspek tingkat yang lebih tinggi dari aliran desain masih penting. Jika Anda dapat mengoptimalkan arsitektur Anda untuk mengurangi acara bangun sebesar 5%, ini harus terlihat dalam masa pakai baterai.

Sean Houlihane
sumber