Strategi modul nirkabel berdaya rendah


8

Saya merancang modul sensor berdaya rendah yang akan tersebar di area yang cukup kecil. Semua modul bertenaga baterai dan harus beroperasi untuk waktu yang cukup lama tanpa harus mengisi ulang / mengganti baterai (semakin lama semakin baik, pikirkan setidaknya beberapa minggu jika tidak berbulan-bulan atau bertahun-tahun). Idenya adalah bahwa setiap setengah jam atau jam modul akan bangun dari mode daya rendah, mengambil beberapa sampel, dan mengirimkan data ke pencatat data pusat. Logger data pusat kemungkinan akan bertenaga dinding sehingga konsumsi daya rendah tidak diperlukan. Saya tidak berharap ada modul lebih dari 100m dari logger pusat, kemungkinan jauh lebih sedikit.

Saya telah mengidentifikasi beberapa modul transceiver yang mungkin dapat bekerja:

  1. ALPHA-TRX433S, 433 MHz
  2. ALPHA-TRX915S, 915 MHz
  3. Microchip MRF89XAM8A, 868 MHz
  4. Microchip MRF89XAM9A, 915 MHz

Dari apa yang saya baca, semua modul ini beroperasi di FCC band yang tidak diatur dan harus aman digunakan. Modul-modul Alpha mengiklankan kisaran 300m, tapi saya tidak tahu berapa kisaran maksimum yang diharapkan dari modul Microchip. Bagaimana saya menghitung tentang ini?

Juga, karena saya punya pilihan band, mana yang harus saya pilih dan mengapa (yaitu apa yang saya dapatkan dari 915 MHz lebih dari 433 MHz dan apa yang saya kehilangan)? Dalam urutan parameter apa yang saya anggap paling penting:

  1. Daya rendah
  2. Jangkauan transmisi (lebih banyak lebih baik, masuk akal)
  3. Kekebalan terhadap faktor lingkungan lainnya (mis. Jaringan wifi / sel, menjalankan oven microwave, dinding / hambatan fisik, suhu, dll.). Penggunaan target adalah di lingkungan perumahan dan kemungkinan akan ada variasi suhu yang signifikan (misalnya -20C hingga 50C).
  4. Kecepatan data. Ini tidak terlalu penting karena saya mengharapkan data yang sangat sedikit per sampel (paling sedikit byte).

Pertanyaan lain yang saya miliki adalah bagaimana menangani beberapa modul yang mencoba mengirim data pada saat yang sama. Saya memiliki beberapa pemikiran tentang bagaimana mengurangi ini, tetapi saya tidak yakin solusi mana yang harus saya jalani:

  1. Gunakan offset waktu acak untuk saat data dikirimkan. Harapannya adalah bahwa tabrakan akan dihindari. Ini mungkin akan menjadi yang paling sederhana untuk diterapkan dan berpotensi akan menggunakan daya paling sedikit. Namun, ini tidak menjamin bahwa tidak akan ada tabrakan. Juga, mendapatkan sumber keacakan yang baik atau seed pseudo-random unik dapat menyebabkan masalah, meskipun tidak dapat dipecahkan.

  2. Saat bangun dan berusaha mengirim, periksa untuk melihat apakah ada transmisi yang sedang berlangsung. Tunggu saja akhir transmisi sebelum mengirim data. Masalahnya kemudian menjadi bagaimana cara menangani beberapa sensor dalam keadaan menunggu, karena keduanya berpotensi memutuskan bahwa transmisi terakhir telah berakhir dan keduanya mulai mentransmisikan pada saat yang sama.

  3. Beberapa solusi lain.


Perhatikan bahwa rentang 300m adalah untuk komunikasi 'Clear Line of Sight', dan biasanya dapat turun hingga 50 atau 100m (atau bahkan kurang) di dalam ruangan, tergantung pada no. dan jenis dinding antara Tx / Rx. Saya telah menggunakan pasangan ASK / OOK Tx / Rx 433MHz dalam sebuah proyek, dengan profil penggunaan yang agak mirip, mematikan 4x1.5VDC AA (bebas merkuri standar), selama lebih dari 6 bulan.
icarus74

Sedangkan untuk menangani beberapa transmisi simultan, solusi pertama Anda dekat dengan apa yang saya gunakan. Dalam kasus saya, pemancar saya menggunakan input sensor temp yang tidak dikalibrasi sebagai seed PRNG untuk dikonversi ke offset hingga 3000ms, dan kemudian saya juga menggunakan transmisi ulang.
icarus74

Jawaban:


9

Saya memiliki sensor perangkat keras open source dan terbuka yang akan memberi Anda titik awal yang berfungsi: ini terhubung ke internet dan mentransmisikan suhu, kelembaban, dan tegangan baterai setiap dua menit dan akan berlangsung selama 3-5 tahun pada baterai 2xAA. Ini didasarkan pada modul M12 6LoWPAN .

Saya akan mencoba yang terbaik untuk menyentuh semua pertanyaan Anda:

Mengenai band tradeoff:

433MHz, 915MHz, 2.4GHz

Rentang vs ukuran antena adalah tradeoff yang jelas di sini. Kehilangan jalur ruang-bebas adalah fungsi dari panjang gelombang sehingga frekuensi yang lebih rendah bergerak lebih jauh untuk pelemahan yang sama. TETAPI, untuk memanfaatkan ini Anda juga akan membutuhkan antena yang cocok yang juga skala dengan panjang gelombang. Antena 2.4Ghz pada M12 membutuhkan sekitar 2 cm2 cm area PCB.

Faktor kedua adalah perizinan. 2.4GHz dapat memiliki stasiun tanpa izin di seluruh dunia. 915MHz hanya tidak berlisensi di AS (ini adalah band GSM di mana pun). Saya tidak yakin pembatasan 433MHz.

Kecepatan data juga dipengaruhi oleh pilihan frekuensi menurut teorema Shannon-Hartley ; Anda dapat menjejalkan lebih banyak data ke pita frekuensi yang lebih tinggi. Ini tidak selalu digunakan untuk data rate yang lebih final sekalipun. 802.15.4, misalnya, memiliki 4 bit redundansi untuk setiap bit nyata yang terlihat di lapisan data. 32 simbol pseudo-ortogonal sehingga Anda harus merusak beberapa bit level rendah untuk menyebabkan kesalahan. Ini memungkinkan 802.15.4 untuk beroperasi di bawah lantai kebisingan (penelitian menunjukkan pada -5dB SNR) dan membuatnya relatif kuat untuk gangguan.

Sekarang ke topik sulit berikutnya,

operasi radio berdaya rendah :

Dibandingkan dengan sumber baterai rumah tangga (misalnya alkali AA), bahkan SoC "daya rendah" seperti mc13224v bukan daya yang sangat rendah. Pemancar sekitar 30mA pada 2-3.5V dan penerima adalah 25mA atau lebih. Tanpa mematikan radio dan mematikan CPU, beban ini akan menghabiskan 2 AA dalam beberapa hari. Konsumsi daya yang tinggi dari penerima sering mengejutkan orang dan mungkin rasa sakit terbesar dalam mengembangkan sistem radio berdaya rendah. Implikasinya adalah berjalan selama bertahun-tahun, Anda hampir tidak pernah bisa mengirim atau mendengarkan.

Tujuan untuk mendapatkan operasi "selama setahun" dari alkali 2xAA adalah untuk mendapatkan arus rata-rata sistem menjadi <50uA. Dengan melakukan hal itu, Anda akan terhindar dari efek sekunder dari baterai seperti self-discharge dan masa pakai 7 tahun untuk baterai rumah tangga.

Cara terbaik untuk mendapatkan di bawah rata-rata <50uA adalah jika transceiver Anda tidak perlu menerima. Jika ini benar, maka Anda dapat "berkicau" data secepat mungkin dan menempatkan sistem ke mode daya rendah (katakan kira-kira 10uA) untuk sebagian besar waktu. The TH12 , misalnya, mentransmisikan sekitar 10 ms, tapi ada overhead lain dalam sistem mengenai waktu proses dan waktu setup untuk sensor yang terlibat. Detailnya dapat dikerjakan dengan probe dan spreadsheet saat ini:

Dari jenis analisis tersebut, Anda dapat mengetahui seperti apa masa pakai (dengan asumsi Anda memiliki kurva debit yang akurat untuk baterai Anda).

Jika Anda perlu menerima data di sisi daya rendah (misalnya untuk membuat router yang mengantuk di jaringan mesh) maka keadaan saat ini berfokus pada teknik pembagian waktu. Beberapa menyinkronkan jaringan dengan ketat, seperti suar 802.15.4, dan yang lain menggunakan sistem "longgar" seperti ContikiMAC (yang dapat lebih mudah diterapkan terutama jika perangkat keras Anda tidak memiliki timebase stabil).

Apapun, pengalaman saya menunjukkan bahwa metode ini adalah sekitar 400uA rata-rata yang menempatkan Anda dalam "-bulan untuk mungkin setahun" run-time dengan 2xAAs.

Tabrakan :

Saran saya: jangan khawatir tentang mereka untuk saat ini. Dengan kata lain lakukan "aloha" (opsi Anda # 1) di mana jika Anda memiliki data, kirimkan saja. Jika itu bertabrakan maka mungkin mengirim ulang. (ini tergantung pada tujuan Anda). Jika Anda tidak perlu memastikan bahwa setiap sampel diterima maka coba saja dan langsung tidur.

Anda akan menemukan bahwa masalah konsumsi daya sangat sulit sehingga satu-satunya solusi adalah jaringan yang tidak mentransmisikan sama sekali. Jika Anda hanya mencoba, itu mungkin akan berhasil. Jika tidak, Anda selalu dapat mencoba lagi nanti.

Jika Anda tidak perlu memastikan setiap datagram akan melalui maka Anda akan harus melakukan beberapa jenis skema ACK. Di dunia 6LoWPAN, Anda dapat menggunakan TCP yang akan mencoba lagi sampai baterai Anda mati. Ada juga CoAP yang menggunakan UDP dan memiliki mekanisme coba lagi (tetapi tidak menjanjikan pengiriman). Tetapi setiap pilihan di sini akan memengaruhi run-time. Jika Anda beroperasi selama bertahun-tahun, dampaknya akan dalam beberapa bulan.

Pilihan Anda # 2 dibangun ke perangkat keras 802.15.4 sebagai CCA. Idenya adalah bahwa penerima dihidupkan untuk 8 simbol dan mengembalikan benar atau salah. Kemudian Anda dapat membuat keputusan tentang apa yang harus dilakukan selanjutnya. Anda dapat bermain dengan skema ini sepanjang hari / minggu. Tetapi setiap kali Anda melakukan sesuatu seperti ini, Anda mencukur lebih banyak minggu dari waktu berjalan. Itu sebabnya saya menyarankan untuk mulai sederhana untuk saat ini. Ini akan bekerja dengan baik jika Anda mencoba untuk jangka waktu yang lama.


Tautan Anda tidak berfungsi!
Ryan Griggs

Saya ingin menambahkan Pengukur XLP Microchip ini , yang akan menunjukkan kepada Anda waktu berjalan yang diharapkan untuk berbagai konfigurasi baterai dan menjalankan status / periode. Juga, jika semua sensor adalah transcievers, Anda dapat menerapkan skema 'round-robin' atau 'token-ring' di mana master berulang kali meminta perangkat 0 untukn"Ada sesuatu untukku?" Sensor menunggu giliran (katakanlah 10 ms), mentransmisikan, lalu mati. Saya akan merekomendasikan menggunakan beberapa jenis CRC checksum, untuk menghindari menerima data yang kacau.
rdtsc

1

Anda mungkin tertarik pada JeeNodes, yang pada dasarnya adalah Arduino Uno yang dipasangkan dengan modul radio RFM-12B dari HopeRF. Jika Anda menulis kode tepat di "node" jarak jauh, Anda dapat dengan mudah mengeluarkan baterai selama berbulan-bulan, tergantung pada sensor Anda, dll.

Lihat situs webnya, konsumsi daya adalah sesuatu yang didokumentasikan dengan baik. Satu hal yang ideal tentang ini adalah bahwa Anda dapat menggunakan perpustakaan arduino standar untuk sensor Anda, atau menggunakan sensor di toko jeelab dan menggunakan perpustakaan JeeLib yang membuat semuanya memang sangat mudah.

Saya membuat remote control kecil untuk lampu dari JeeNode v6, dan mematikan baterai Nokia lama (sekitar 1 Ah tapi mungkin kurang sekarang), sudah berjalan selama 3 bulan dan tegangan baterai masih lebih dari 3,9 v (yaitu masih cukup penuh). Itu hanya duduk di sana dalam tidur daya rendah, bangun setiap beberapa ms untuk memeriksa apakah tombol ditekan.

Saya membeli PCB dari toko JeeLabs, tetapi mendapatkan semua komponen dari tempat-tempat seperti ebay, element14 dll, itu berakhir sedikit lebih murah seperti itu.

Dengan sedikit perhatian pada desain antena, Anda bisa mendapatkan beberapa ratus meter darinya, saling berhadapan. Saya dengan mudah mendapatkan cakupan seluruh rumah dengan kabel vertikal sederhana.


0

DATA RATE "Kecepatan data juga dipengaruhi oleh pilihan frekuensi menurut teorema Shannon-Hartley; Anda dapat menjejalkan lebih banyak data ke dalam pita frekuensi yang lebih tinggi." Salah!!!

Laju data berkaitan dengan bandwidth, bukan frekuensi operator. Anda dapat memiliki frekuensi operator yang rendah, namun memiliki bandwidth yang tinggi dan kecepatan data yang tinggi.

FREKUENSI CARRIER Frekuensi pembawa yang lebih rendah baik untuk jangkauan. Jika frekuensi dibelah dua kisaran akan meningkat empat kali lipat. Tetapi ukuran antena juga akan meningkat. Biasanya antena adalah lamba / 2 atau lambda / 4 (lambda adalah panjang gelombang dalam meter).

KONTENSI SALURAN Tampaknya ini cukup jelas pada pandangan pertama tetapi bisa menjadi rumit. Seperti yang telah ditunjukkan orang lain, strategi paling sederhana adalah bangun dan mengirimkan sekali dan kemudian tidur. Jika jumlah pemancar tidak terlalu besar dan durasi tidur jauh lebih besar daripada durasi transmisi daripada ini akan berhasil. Tetapi Anda harus siap kehilangan beberapa data dalam kasus yang jarang terjadi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.