اے این 451
وائرلیس ایم بس سافٹ ویئر کا نفاذ
تعارف
یہ ایپلیکیشن نوٹ سلکان لیبز C8051 MCU اور EZRadioPRO® کا استعمال کرتے ہوئے وائرلیس M-Bus کے Silicon Labs کے نفاذ کی وضاحت کرتا ہے۔ Wireless M-bus 868 MHz فریکوئنسی بینڈ کا استعمال کرتے ہوئے میٹر ریڈنگ ایپلی کیشنز کے لیے ایک یورپی معیار ہے۔
اسٹیک پرتیں۔
وائرلیس ایم-بس 3-پرت IEC ماڈل استعمال کرتا ہے، جو 7-پرت OSI ماڈل کا سب سیٹ ہے (شکل 1 دیکھیں)۔
فزیکل (PHY) پرت کی تعریف EN 13757-4 میں کی گئی ہے۔ فزیکل پرت اس بات کی وضاحت کرتی ہے کہ بٹس کو کس طرح انکوڈ اور ٹرانسمٹ کیا جاتا ہے، RF موڈیم کی خصوصیات (چپ کی شرح، تمہید، اور ہم آہنگی کا لفظ)، اور RF پیرامیٹرز (ماڈیولیشن، سینٹر فریکوئنسی، اور فریکوئنسی انحراف)۔
PHY پرت کو ہارڈ ویئر اور فرم ویئر کے امتزاج کا استعمال کرتے ہوئے لاگو کیا جاتا ہے۔ EZRadioPRO RF اور موڈیم کے تمام افعال انجام دیتا ہے۔ EZRadioPRO پیکٹ ہینڈلر کے ساتھ FIFO موڈ میں استعمال ہوتا ہے۔ MbusPhy.c ماڈیول SPI انٹرفیس، انکوڈنگ/ڈی کوڈنگ، بلاک ریڈ/رائٹ، اور پیکٹ ہینڈلنگ فراہم کرتا ہے اور ٹرانسیور سٹیٹس کا انتظام کرتا ہے۔
M-Bus ڈیٹا لنک لیئر MbusLink.c ماڈیول میں لاگو کیا جاتا ہے۔ M-Bus ایپلیکیشن پروگرامنگ انٹرفیس پبلک فنکشنز پر مشتمل ہوتا ہے جنہیں مین تھریڈ میں ایپلی کیشن لیئر سے بلایا جا سکتا ہے۔ MbusLink ماڈیول ڈیٹا لنک لیئر کو بھی لاگو کرتا ہے۔ ڈیٹا لنک لیئر ایپلیکیشن TX بفر سے ڈیٹا کو MbusPhy TX بفر میں فارمیٹ اور کاپی کرے گی، مطلوبہ ہیڈرز اور CRCs کو شامل کرے گی۔
ایپلی کیشن پرت خود M-bus فرم ویئر کا حصہ نہیں ہے۔ ایپلی کیشن پرت اس بات کی وضاحت کرتی ہے کہ ٹرانسمیشن کے لیے ڈیٹا کی وسیع اقسام کو کس طرح فارمیٹ کیا جانا ہے۔ زیادہ تر میٹر کو صرف ایک یا دو قسم کا ڈیٹا منتقل کرنے کی ضرورت ہوتی ہے۔ میٹر میں کسی بھی قسم کے ڈیٹا کو ایڈجسٹ کرنے کے لیے کوڈ کی ایک بڑی مقدار شامل کرنے سے میٹر میں غیر ضروری کوڈ اور لاگت شامل ہو جائے گی۔ لائبریری یا ہیڈر کو نافذ کرنا ممکن ہو سکتا ہے۔ file ڈیٹا کی اقسام کی ایک مکمل فہرست کے ساتھ۔ تاہم، زیادہ تر میٹرنگ کے صارفین بخوبی جانتے ہیں کہ انہیں کس قسم کا ڈیٹا منتقل کرنے کی ضرورت ہے اور وہ فارمیٹنگ کی تفصیلات کے معیار کا حوالہ دے سکتے ہیں۔ ایک یونیورسل ریڈر یا سنیفر PC GUI پر ایپلیکیشن ڈیٹا کی اقسام کے مکمل سیٹ کو نافذ کر سکتا ہے۔ ان وجوہات کی بناء پر، ایپلی کیشن پرت کو استعمال کرتے ہوئے لاگو کیا جاتا ہے exampمیٹر اور ریڈر کے لیے درخواستیں
مطلوبہ معیارات
- EN 13757-4
EN 13757-4
میٹر کے لیے مواصلاتی نظام اور میٹر کی ریموٹ ریڈنگ
حصہ 4: وائرلیس میٹر ریڈ آؤٹ
868 MHz سے 870 MHz SRD بینڈ میں آپریشن کے لیے ریڈیو میٹر ریڈنگ - EN 13757-3
میٹر کے لیے مواصلاتی نظام اور میٹر کی ریموٹ ریڈنگ
حصہ 3: درخواست کی سرشار پرت - IEC 60870-2-1:1992
ٹیلی کنٹرول کا سامان اور نظام
حصہ 5: ٹرانسمیشن پروٹوکول
سیکشن 1: لنک ٹرانسمیشن کا طریقہ کار - IEC 60870-1-1:1990
ٹیلی کنٹرول کا سامان اور نظام
حصہ 5: ٹرانسمیشن پروٹوکول
سیکشن 1: ٹرانسمیشن فریم فارمیٹس
تعریفیں
- ایم بس-M-Bus یورپ میں میٹر ریڈنگ کے لیے ایک وائرڈ اسٹینڈرڈ ہے۔
- وائرلیس ایم بسیورپ میں میٹر ریڈنگ ایپلی کیشنز کے لیے وائرلیس ایم بس۔
- پی ایچ وائیجسمانی پرت اس بات کی وضاحت کرتی ہے کہ ڈیٹا بٹس اور بائٹس کو کیسے انکوڈ اور منتقل کیا جاتا ہے۔
- API-ایپلیکیشن پروگرامر انٹرفیس۔
- لنک-ڈیٹا لنک لیئر اس بات کی وضاحت کرتی ہے کہ بلاکس اور فریم کیسے منتقل ہوتے ہیں۔
- CRC-سائکلک ریڈنڈنسی چیک۔
- FSK-فریکوئینسی شفٹ کینگ۔
- چپ -منتقل شدہ ڈیٹا کی سب سے چھوٹی اکائی۔ ایک ڈیٹا بٹ کو متعدد چپس کے طور پر انکوڈ کیا جاتا ہے۔
- ماڈیول-AC کوڈ کا ذریعہ .c file.
ایم بس پی ایچ وائی فنکشنل تفصیل
تمہید کی ترتیب
M-bus تصریح کے ذریعہ متعین کردہ تمہید کی ترتیب صفر اور ایک کو تبدیل کرنے والا ایک عدد عدد ہے۔ ایک کو اعلی تعدد کے طور پر بیان کیا گیا ہے، اور ایک صفر کو کم تعدد کے طور پر بیان کیا گیا ہے۔
nx (01)
Si443x کے لیے تمہید کے اختیارات نبلوں کا ایک عدد عدد ہے جس میں متبادل اور زیرو شامل ہیں۔
nx (1010)
ایک اضافی لیڈنگ والی تمہید میں کوئی مسئلہ نہیں ہوگا، لیکن، پھر، مطابقت پذیری کے لفظ اور پے لوڈ کو ایک بٹ کے ذریعے غلط طور پر لکھا جائے گا۔
اس کا حل یہ ہے کہ ماڈیولیشن کنٹرول 2 رجسٹر (0x71) میں انجن بٹ سیٹ کرکے پورے پیکٹ کو الٹ دیا جائے۔ یہ تمہید، مطابقت پذیری لفظ، اور TX/RX ڈیٹا کو الٹ دے گا۔ نتیجے کے طور پر، TX ڈیٹا لکھتے وقت یا RX ڈیٹا کو پڑھتے وقت ڈیٹا کو الٹا ہونا چاہیے۔ نیز، Si443x Synchronization Word کے رجسٹروں پر لکھنے سے پہلے مطابقت پذیری کا لفظ الٹا ہے۔
ہم وقت سازی کا لفظ
EN-13757-4 کے لیے مطلوبہ ہم آہنگی کا لفظ یا تو موڈ S اور Mode R کے لیے 18 چپس ہے یا ماڈل T کے لیے 10 چپس۔ Si443x کے لیے مطابقت پذیری کا لفظ 1 سے 4 بائٹس ہے۔ تاہم، چونکہ ہم آہنگی کا لفظ ہمیشہ تمہید سے پہلے ہوتا ہے، اس لیے تمہید کے آخری چھ بٹس کو ہم آہنگی کے لفظ کا حصہ سمجھا جا سکتا ہے۔ لہذا، پہلے ہم آہنگی والے لفظ کو صفر کی تین تکرار سے پیڈ کیا جاتا ہے اور اس کے بعد ایک۔ ہم وقت سازی کا لفظ Si443x رجسٹروں پر لکھنے سے پہلے مکمل کیا جاتا ہے۔
جدول 1. موڈ S اور موڈ R کے لیے ہم وقت سازی کا لفظ
| EN 13757-4 | 00 | 01110110 | 10010110 | بائنری |
| 00 | 76 | 96 | ہیکس | |
| (01) x 3 کے ساتھ پیڈ | 01010100 | 01110110 | 10010110 | بائنری |
| 54 | 76 | 96 | ہیکس | |
| تکمیل | 10101011 | 10001001 | 01101001 | بائنری |
| AB | 89 | 69 | ہیکس |
ٹیبل 2. موڈ ٹی میٹر کے لیے دوسرے سے ہم آہنگی کا لفظ
| SYNCH | SYNCH | SYNCH |
| لفظ | لفظ | لفظ |
| 3 | 2 | 1 |
تمہید کی لمبائی منتقل کریں۔
کم از کم تمہید چار مختلف آپریٹنگ طریقوں کے لیے بیان کی گئی ہے۔ یہ قابل قبول ہے کہ تمہید بیان کردہ سے زیادہ لمبی ہو۔ تمہید کے لیے چھ چپس کو گھٹانے سے Si443x تمہید کے لیے چپس کی کم از کم تعداد ملتی ہے۔ اس پر عمل درآمد تمام مختصر تمہید کے طریقوں میں تمہید کے دو اضافی نبلز کا اضافہ کرتا ہے تاکہ تمہید کا پتہ لگانے اور انٹرآپریبلٹی کو بہتر بنایا جا سکے۔ موڈ S پر ایک لمبی تمہید کے ساتھ تمہید بہت لمبی ہے۔ لہذا، کم از کم تمہید استعمال کی جاتی ہے۔ نبلوں میں تمہید کی لمبائی تمہید کی لمبائی (0x34) رجسٹر میں لکھی جاتی ہے۔ تمہید کی لمبائی کا رجسٹر صرف ٹرانسمیشن پر تمہید کا تعین کرتا ہے۔ کم از کم تفصیلات اور تمہید کی لمبائی کی ترتیبات کا خلاصہ جدول 3 میں دیا گیا ہے۔
جدول 3. تمہید کی لمبائی منتقل کریں۔
| EN-13757-4 کم از کم |
Si443x تمہید ترتیب دینا |
مطابقت پذیری کلام |
کل | اضافی | |||
| nx (01) | چپس | nibbles | چپس | چپس | چپس | چپس | |
| موڈ S مختصر تمہید | 15 | 30 | 8 | 32 | 6 | 38 | 8 |
| موڈ S لمبی تمہید | 279 | 558 | 138 | 552 | 6 | 558 | 0 |
| موڈ T (میٹر دیگر) | 19 | 38 | 10 | 40 | 6 | 46 | 8 |
| وضع R | 39 | 78 | 20 | 80 | 6 | 86 | 8 |
استقبالیہ کے لیے کم از کم تمہید کا تعین تمہید کا پتہ لگانے کے کنٹرول رجسٹر (0x35) سے ہوتا ہے۔ استقبالیہ پر، قابل استعمال تمہید کا تعین کرنے کے لیے ہم آہنگی والے لفظ میں بٹس کی تعداد کو مخصوص کم از کم تمہید سے منہا کرنا چاہیے۔ وصول کنندہ کا کم از کم سیٹلنگ ٹائم 16-چپس ہے اگر AFC فعال ہے یا 8-چپس ہے اگر AFC غیر فعال ہے۔ پریمبل ڈیٹیکشن کنٹرول رجسٹر کے لیے کم از کم سیٹنگ کا تعین کرنے کے لیے وصول کنندہ کے حل کا وقت بھی قابل استعمال تمہید سے منہا کر دیا جاتا ہے۔
جھوٹی تمہید کا امکان تمہید کا پتہ لگانے کے کنٹرول رجسٹر کی ترتیب پر منحصر ہے۔ 8-چپس کی مختصر ترتیب کے نتیجے میں ہر چند سیکنڈ میں ایک غلط تمہید کا پتہ چل سکتا ہے۔ 20 چپس کی تجویز کردہ ترتیب جھوٹی تمہید کا پتہ لگانے کو ایک غیر متوقع واقعہ بناتی ہے۔ تجویز کردہ ترتیب کے استعمال کے لیے موڈ R اور Mode SL کی تمہید کی لمبائی کافی لمبی ہے۔
تمہید کو 20 چپس سے زیادہ لمبا کرنے کا بہت کم فائدہ ہے۔
AFC کو ماڈل S کے لیے ایک مختصر تمہید اور ماڈل T کے ساتھ غیر فعال کر دیا گیا ہے۔ اس سے وصول کنندہ کے طے ہونے کا وقت کم ہو جاتا ہے اور تمہید کا پتہ لگانے کی طویل ترتیب کی اجازت ملتی ہے۔ AFC کے غیر فعال ہونے کے ساتھ، Mode T 20 چپس کی تجویز کردہ ترتیب استعمال کر سکتا ہے۔ ایک مختصر تمہید کے ساتھ ماڈل S کے لیے 4 نبل یا 20 چپس کی ترتیب استعمال کی جاتی ہے۔ اس سے اس ماڈل کے لیے غلط تمہید کا پتہ لگانے کا امکان قدرے زیادہ ہو جاتا ہے۔
جدول 4. تمہید کا پتہ لگانا
| EN-13757-4 کم از کم |
مطابقت پذیری کلام |
قابل استعمال تمہید |
آر ایکس سیٹلنگ | پتہ لگانا منٹ |
Si443x تمہید پتہ لگانے کی ترتیب |
|||
| nx (01) | چپس | چپس | چپس | چپس | چپس | nibbles | چپس | |
| موڈ S مختصر تمہید | 15 | 30 | 6 | 24 | 8* | 16 | 4 | 16 |
| ماڈل ایس لمبی تمہید | 279 | 558 | 6 | 552 | 16 | 536 | 5 | 20 |
| ماڈل T (میٹر دیگر) | 19 | 38 | 6 | 32 | 8* | 24 | 5 | 20 |
| وضع R | 39 | 78 | 6 | 72 | 16 | 56 | 5 | 20 |
| *نوٹ: AFC غیر فعال | ||||||||
وصول کنندہ کو کم سے کم متعین تمہید کا استعمال کرتے ہوئے ٹرانسمیٹر کے ساتھ انٹرآپریٹ کرنے کے لیے ترتیب دیا گیا ہے۔ یہ یقینی بناتا ہے کہ وصول کنندہ کسی بھی M-بس کے مطابق ٹرانسمیٹر کے ساتھ مداخلت کرے گا۔
وائرلیس ایم-بس کی تفصیلات کے لیے کم از کم 1 چپس کے موڈ S558 کے لیے ایک بہت طویل تمہید کی ضرورت ہے۔ تمہید کو منتقل کرنے میں صرف 17 ایم ایس کا وقت لگے گا۔ Si443x کو اتنی لمبی تمہید کی ضرورت نہیں ہے اور طویل تمہید سے فائدہ نہیں ہوتا ہے۔ اگرچہ طویل تمہید کو موڈ S2 کے لیے اختیاری کے طور پر نوٹ کیا گیا ہے، لیکن Si443x کے ساتھ طویل تمہید استعمال کرنے کی کوئی وجہ نہیں ہے۔ اگر یک طرفہ مواصلت مطلوب ہے تو، موڈ T1 ایک مختصر تمہید، اعلیٰ ڈیٹا ریٹ، اور بیٹری کی طویل زندگی فراہم کرے گا۔ اگر موڈ S2 کا استعمال کرتے ہوئے دو طرفہ مواصلت درکار ہے تو ایک مختصر تمہید تجویز کی جاتی ہے۔
دھیان دیں کہ ایک طویل تمہید کے ساتھ ماڈل S کے لیے پتہ لگانے کی حد ایک مختصر تمہید کے ساتھ ماڈل S کے لیے بھیجے گئے تمہید کے نبلوں کی تعداد سے زیادہ لمبی ہے۔ اس کا مطلب یہ ہے کہ لمبی تمہید موڈ ایس وصول کنندہ مختصر تمہید موڈ ایس ٹرانسمیٹر سے تمہید کا پتہ نہیں لگائے گا۔ یہ ضروری ہے اگر طویل تمہید موڈ S وصول کنندہ کو طویل تمہید سے کوئی فائدہ حاصل کرنا ہے۔
نوٹ کریں کہ مختصر تمہید موڈ ایس ریسیور تمہید کا پتہ لگائے گا اور مختصر تمہید موڈ S دونوں سے پیکٹ وصول کرے گا۔
ٹرانسمیٹر اور ایک طویل پیش کش موڈ ایس ٹرانسمیٹر؛ لہذا، عام طور پر، میٹر ریڈر کو مختصر تمہید موڈ S رسیور کنفیگریشن کا استعمال کرنا چاہیے۔
انکوڈنگ/ڈی کوڈنگ
وائرلیس ایم بس کی تفصیلات کے لیے دو مختلف انکوڈنگ طریقوں کی ضرورت ہے۔ مانچسٹر انکوڈنگ کا استعمال Mode S اور Mode R کے لیے کیا جاتا ہے۔ مانچسٹر انکوڈنگ ماڈل T میں دوسرے سے میٹر کے لنک کے لیے بھی استعمال ہوتی ہے۔ ماڈل T میٹر سے دوسرے لنک 3 میں سے 6 انکوڈنگز کا استعمال کرتا ہے۔
1. مانچسٹر انکوڈ/ڈی کوڈنگ
مانچسٹر انکوڈنگ تاریخی طور پر RF سسٹمز میں عام ہے تاکہ ایک سادہ اور سستے موڈیم کا استعمال کرتے ہوئے مضبوط گھڑی کی بحالی اور ٹریکنگ فراہم کی جا سکے۔ تاہم، Si443x جیسے جدید ہائی پرفارمنس ریڈیو کو مانچسٹر انکوڈنگ کی ضرورت نہیں ہے۔ مانچسٹر انکوڈنگ بنیادی طور پر موجودہ معیارات کے ساتھ مطابقت کے لیے معاون ہے، لیکن مانچسٹر انکوڈنگ کا استعمال نہ کرنے پر Si443x کے لیے ڈیٹا کی شرح کو مؤثر طریقے سے دوگنا کر دیا جاتا ہے۔
Si443x ہارڈ ویئر میں پورے پیکٹ کی مانچسٹر انکوڈنگ اور ڈی کوڈنگ کو سپورٹ کرتا ہے۔ بدقسمتی سے، مطابقت پذیری کا لفظ مانچسٹر انکوڈ نہیں ہے۔ مطابقت پذیری کے لفظ کے لیے ایک غلط مانچسٹر ترتیب جان بوجھ کر چنا گیا تھا۔ یہ مانچسٹر انکوڈنگ کو زیادہ تر موجودہ ریڈیوز کے ساتھ مطابقت نہیں رکھتا، بشمول Si443x۔ نتیجے کے طور پر، مانچسٹر انکوڈنگ اور ضابطہ کشائی کو MCU کے ذریعے انجام دیا جانا چاہیے۔ بغیر انکوڈ شدہ ڈیٹا پر ہر بائٹ آٹھ ڈیٹا بٹس پر مشتمل ہوتا ہے۔ مانچسٹر انکوڈنگ کا استعمال کرتے ہوئے، ہر ڈیٹا بٹ کو دو چپ علامت میں انکوڈ کیا جاتا ہے۔ چونکہ انکوڈ شدہ ڈیٹا کو ایک وقت میں ریڈیو FIFO آٹھ چپس پر لکھا جانا ضروری ہے، اس لیے ڈیٹا کا ایک نبل انکوڈ کیا جاتا ہے اور ایک وقت میں FIFO کو لکھا جاتا ہے۔
ٹیبل 5. مانچسٹر انکوڈنگ
| ڈیٹا | Ox12 | 0x34 | بائٹس | ||
| Ox1 | 0x2 | 0x3 | 0x4 | nibbles | |
| 1 | 10 | 11 | 100 | بائنری | |
| چپ | 10101001 | 10100110 | 10100101 | 10011010 | بائنری |
| FIFO | آکس اے 9 | آکس اے 6 | آکس اے 5 | آکس9 اے | ہیکس |
منتقل ہونے والے ہر بائٹ کو ایک وقت میں ایک بائٹ انکوڈ بائٹ فنکشن میں منتقل کیا جاتا ہے۔ انکوڈ بائٹ فنکشن انکوڈ نبل فنکشن کو دو بار کال کرے گا، پہلے سب سے اہم نبل کے لیے اور پھر کم از کم اہم نبل کے لیے۔
سافٹ ویئر میں مانچسٹر انکوڈنگ مشکل نہیں ہے۔ سب سے اہم بٹ سے شروع کرتے ہوئے، ایک کو "01" چپ ترتیب کے طور پر انکوڈ کیا جاتا ہے۔ ایک صفر کو "10" چپ ترتیب کے طور پر انکوڈ کیا جاتا ہے۔ یہ آسانی سے ایک لوپ کا استعمال کرتے ہوئے اور ہر علامت کے لئے دو بٹس کو منتقل کیا جا سکتا ہے۔ تاہم، ہر نبل کے لیے صرف ایک سادہ 16 اندراج کی تلاش کی میز استعمال کرنا تیز تر ہے۔ انکوڈ مانچسٹر نبل فنکشن ڈیٹا کے ایک نبل کو انکوڈ کرتا ہے پھر اسے FIFO کو لکھتا ہے۔ FIFO کو لکھنے سے پہلے چپس کو الٹا دیا جاتا ہے تاکہ الٹی تمہید کی ضروریات کو پورا کیا جا سکے۔
وصول کرتے وقت، FIFO میں ہر بائٹ آٹھ چپس پر مشتمل ہوتا ہے اور اسے ڈیٹا کے ایک نبل میں ڈی کوڈ کیا جاتا ہے۔ ریڈ بلاک فنکشن FIFO سے ایک وقت میں ایک بائٹ پڑھتا ہے اور ڈی کوڈ بائٹ فنکشن کو کال کرتا ہے۔ الٹی تمہید کی ضروریات کو پورا کرنے کے لیے FIFO سے پڑھنے کے بعد چپس الٹی ہو جاتی ہیں۔ مانچسٹر انکوڈ شدہ چپس کے ہر بائٹ کو ڈیٹا کے ایک نبل میں ڈی کوڈ کیا جاتا ہے۔ ڈی کوڈ شدہ نبل کو رائٹ نبل RX بفر فنکشن کا استعمال کرتے ہوئے RX بفر پر لکھا جاتا ہے۔
نوٹ کریں کہ انکوڈ اور ڈی کوڈنگ دونوں ایک ہی وقت میں ایک ڈیٹا نبل کو فلائی پر انجام دیتے ہیں۔ بفر کو انکوڈنگ کرنے کے لیے بغیر انکوڈ شدہ ڈیٹا کے سائز سے دوگنا اضافی بفر درکار ہوگا۔ انکوڈنگ اور ضابطہ کشائی تیز ترین تعاون یافتہ ڈیٹا ریٹ (100 k چپس فی سیکنڈ) سے کہیں زیادہ تیز ہے۔ چونکہ Si443x FIFO کو ایک سے زیادہ بائٹ ریڈز اور رائٹ کو سپورٹ کرتا ہے، اس لیے صرف سنگل بائٹ ریڈز اور رائٹ استعمال کرنے میں ایک چھوٹا سا اوور ہیڈ ہے۔ 10 انکوڈ شدہ چپس کے لیے اوور ہیڈ تقریباً 100 µs ہے۔ فائدہ 512 بائٹس کی RAM کی بچت ہے۔
2. چھ انکوڈنگ ڈیکوڈنگ میں سے تین
EN-13757-4 میں بیان کردہ تھری آؤٹ آف سکس انکوڈنگ کا طریقہ MCU پر فرم ویئر میں بھی لاگو ہوتا ہے۔ یہ انکوڈنگ میٹر سے دوسرے تک تیز رفتار (100 k چپس فی سیکنڈ) موڈ T کے لیے استعمال ہوتی ہے۔ ماڈل T وائرلیس میٹر کے لیے سب سے کم ترسیل کا وقت اور طویل ترین بیٹری کی زندگی فراہم کرتا ہے۔
منتقل کیے جانے والے ڈیٹا کے ہر بائٹ کو دو نبلوں میں تقسیم کیا گیا ہے۔ سب سے اہم نبل پہلے انکوڈ اور منتقل کیا جاتا ہے۔ ایک بار پھر، یہ ایک انکوڈ بائٹ فنکشن کا استعمال کرتے ہوئے لاگو کیا جاتا ہے جو انکوڈ نبل فنکشن کو دو بار کال کرتا ہے۔
ڈیٹا کے ہر نبل کو چھ چپ علامت میں انکوڈ کیا جاتا ہے۔ چھ چپ علامتوں کی ترتیب 8chip FIFO پر لکھی جانی چاہیے۔
انکوڈنگ کے دوران، ڈیٹا کے دو بائٹس کو چار نبل کے طور پر انکوڈ کیا جاتا ہے۔ ہر نبل ایک 6 چپ علامت ہے۔ چار 6 چپ علامتوں کو تین بائٹس کے طور پر جمع کیا گیا ہے۔
جدول 6۔ چھ انکوڈنگ میں سے تین
| ڈیٹا | 0x12 | 0x34 | بائٹس | ||||
| Ox1 | 0x2 | 0x3 | 0x4 | nibbles | |||
| چپ | 15 | 16 | 13 | 34 | آکٹل | ||
| 1101 | 1110 | 1011 | 11100 | بائنری | |||
| FIFO | 110100 | 11100010 | 11011100 | بائنری | |||
| 0x34 | OxE2 | آکس ڈی سی | ہیکس | ||||
سافٹ ویئر میں، تین میں سے چھ انکوڈنگ کو تین نیسٹڈ فنکشنز کا استعمال کرتے ہوئے لاگو کیا جاتا ہے۔ انکوڈ بائٹ فنکشن انکوڈ نبل فنکشن کو دو بار کال کرے گا۔ انکوڈ نبل فنکشن چھ چپ کی علامت کے لیے ایک لُک اپ ٹیبل کا استعمال کرتا ہے اور علامت کو چھ فنکشنز میں سے شفٹ تھری پر لکھتا ہے۔ یہ فنکشن سافٹ ویئر میں 16-چِپ شفٹ رجسٹر کو لاگو کرتا ہے۔ علامت شفٹ رجسٹر کے کم سے کم اہم بائٹ پر لکھا جاتا ہے۔ رجسٹر کو دو بار بائیں منتقل کیا جاتا ہے۔ یہ تین بار دہرایا جاتا ہے۔ جب ایک مکمل بائٹ شفٹ رجسٹر کے اوپری بائٹ میں موجود ہوتا ہے، تو اسے الٹا کر کے FIFO پر لکھا جاتا ہے۔
چونکہ ڈیٹا کے ہر بائٹ کو ڈیڑھ انکوڈ بائٹس کے طور پر انکوڈ کیا جاتا ہے، اس لیے یہ ضروری ہے کہ شفٹ رجسٹر کو ابتدائی طور پر صاف کیا جائے تاکہ پہلا انکوڈ شدہ بائٹ درست ہو۔ اگر پیکٹ کی لمبائی ایک طاق نمبر ہے، تمام بائٹس کو انکوڈنگ کرنے کے بعد، شفٹ رجسٹر میں اب بھی ایک نبل باقی رہے گا۔ یہ پوسٹ اسمبل کے ساتھ سنبھالا جاتا ہے جیسا کہ اگلے حصے میں بیان کیا گیا ہے۔
انکوڈ شدہ چھ میں سے تین کو ڈی کوڈ کرنا الٹا طریقہ کار ہے۔ ضابطہ کشائی کرتے وقت، تین انکوڈ شدہ بائٹس کو دو ڈیٹا بائٹس میں ڈی کوڈ کیا جاتا ہے۔ سافٹ ویئر شفٹ رجسٹر دوبارہ ڈی کوڈ شدہ ڈیٹا کے بائٹس کو جمع کرنے کے لیے استعمال کیا جاتا ہے۔ ضابطہ کشائی کے لیے ایک 64-انٹری الٹا لُک اپ ٹیبل استعمال کیا جاتا ہے۔ یہ کم سائیکل لیکن زیادہ کوڈ میموری استعمال کرتا ہے۔ متعلقہ علامت کے لیے 16-انٹری لک اپ ٹیبل کو تلاش کرنے میں کافی زیادہ وقت لگتا ہے۔
پوسٹمبل
وائرلیس ایم-بس کی تفصیلات میں پوسٹ اسمبل یا ٹریلر کے لیے مخصوص تقاضے ہیں۔ تمام طریقوں کے لیے، کم از کم دو چپس ہیں، اور زیادہ سے زیادہ آٹھ چپس ہیں۔ چونکہ FIFO کے لیے کم از کم ایٹم اکائی ایک بائٹ ہے، اس لیے موڈ S اور Mode R کے لیے 8-چِپ ٹریلر استعمال کیا جاتا ہے۔ اگر پیکٹ کی لمبائی برابر ہو تو موڈ T پوسٹمبل آٹھ چپس ہے یا اگر پیکٹ کی لمبائی طاق ہو تو چار چپس۔ ایک طاق پیکٹ کی لمبائی کے لیے چار چپس والا پوسٹمبل کم از کم دو متبادل چپس رکھنے کی ضروریات کو پورا کرتا ہے۔
ٹیبل 7. پوسٹمبل کی لمبائی
| پوسٹمبل کی لمبائی (چپس) | |||||
| منٹ | زیادہ سے زیادہ | عمل درآمد | چپ ترتیب | ||
| موڈ ایس | 2 | 8 | 8 | 1010101 | |
| موڈ ٹی | 2 | 8 | 4 | (طاق) | 101 |
| 8 | (یہاں تک کہ) | 1010101 | |||
| وضع R | 2 | 8 | 8 | 1010101 | |
پیکٹ ہینڈلر
Si443x پر پیکٹ ہینڈلر متغیر پیکٹ چوڑائی موڈ یا فکسڈ پیکٹ چوڑائی موڈ میں استعمال کیا جا سکتا ہے۔ متغیر پیکٹ چوڑائی موڈ کو مطابقت پذیری لفظ اور اختیاری ہیڈر بائٹس کے بعد پیکٹ کی لمبائی بائٹ کی ضرورت ہوتی ہے۔ استقبال کرنے پر، ریڈیو ایک درست پیکٹ کے اختتام کا تعین کرنے کے لیے لمبائی بائٹ کا استعمال کرے گا۔ ٹرانسمیشن پر، ریڈیو ہیڈر بائٹس کے بعد لینتھ فیلڈ داخل کرے گا۔
وائرلیس M-بس پروٹوکول کے لیے L فیلڈ کو Si443x لمبائی والے فیلڈ کے لیے استعمال نہیں کیا جا سکتا۔ سب سے پہلے، L فیلڈ اصل پیکٹ کی لمبائی نہیں ہے۔ یہ لنک لیئر پے لوڈ بائٹس کی تعداد ہے جس میں CRC بائٹس یا انکوڈنگ شامل نہیں ہے۔ دوم، L-field خود یا تو مانچسٹر انکوڈنگ کا استعمال کرتے ہوئے انکوڈ کیا جاتا ہے یا موڈ T میٹر کے لیے چھ میں سے تھری انکوڈنگ کا استعمال کرتے ہوئے.
نفاذ پیکٹ ہینڈلر کو ٹرانسمیشن اور استقبال دونوں کے لیے فکسڈ پیکٹ چوڑائی موڈ میں استعمال کرتا ہے۔ ٹرانسمیشن پر، PHY پرت ٹرانسمٹ بفر میں L فیلڈ کو پڑھے گی اور انکوڈ شدہ بائٹس کی تعداد کا حساب لگائے گی، بشمول پوسٹمبل۔ منتقل کیے جانے والے انکوڈ شدہ بائٹس کی کل تعداد پیکٹ لینتھ رجسٹر (0x3E) میں لکھی جاتی ہے۔
استقبالیہ پر، پہلے دو انکوڈ شدہ بائٹس کو ڈی کوڈ کیا جاتا ہے، اور L-فیلڈ وصول کرنے والے بفر پر لکھا جاتا ہے۔ ایل فیلڈ کو موصول ہونے والے انکوڈ شدہ بائٹس کی تعداد کا حساب لگانے کے لیے استعمال کیا جاتا ہے۔ موصول ہونے والے انکوڈ شدہ بائٹس کی تعداد پھر پیکٹ کی لمبائی کے رجسٹر (0x3E) میں لکھی جاتی ہے۔ ڈاک کو ضائع کر دیا گیا ہے۔
MCU کو ایل فیلڈ کو ڈی کوڈ کرنا چاہیے، انکوڈ شدہ بائٹس کی تعداد کا حساب لگانا چاہیے، اور پیکٹ کی لمبائی کے رجسٹر میں قیمت لکھنا چاہیے اس سے پہلے کہ پیکٹ کی کم سے کم لمبائی موصول ہو جائے۔ PHY پرت کے لیے سب سے کم قابل اجازت L-فیلڈ 9 ہے، جو 12 بغیر انکوڈ شدہ بائٹس دیتا ہے۔ یہ ماڈل T کے لیے 18 انکوڈ شدہ بائٹس دیتا ہے۔ پہلے دو بائٹس پہلے ہی ڈی کوڈ ہو چکے ہیں۔ اس طرح، پیکٹ لینتھ رجسٹر کو 16 بائٹ اوقات میں 100 kbps یا 1.28 ملی سیکنڈ میں اپ ڈیٹ کرنا ضروری ہے۔ 8051 MIPS پر چلنے والے 20 کے لیے یہ کوئی مسئلہ نہیں ہے۔
موصول ہونے والے بائٹس کی تعداد میں پوسٹ اسٹیمبل شامل نہیں ہے، سوائے اس کے کہ موڈ ٹی پیکٹوں کے لیے ایک طاق پیکٹ کی لمبائی کے ساتھ چار چپ پوسٹمبل استعمال کیا جاتا ہے۔ اس طرح، وصول کنندہ کو ڈاک کی ضرورت نہیں ہوتی، سوائے ماڈل T طاق لمبائی کے پیکٹوں کے۔ اس پوسٹمبل کی ضرورت صرف انکوڈ شدہ بائٹس کی عددی تعداد دینے کے لیے ہے۔ ڈاک کے مواد کو نظر انداز کر دیا گیا ہے۔ لہذا، اگر پوسٹ اسٹیبل کو منتقل نہیں کیا جاتا ہے، تو شور کے چار چپس موصول ہوں گے اور نظر انداز کیے جائیں گے۔ چونکہ انکوڈ شدہ بائٹس کی کل تعداد 255 (0xFF) تک محدود ہے، اس لیے نفاذ مختلف طریقوں کے لیے زیادہ سے زیادہ L-فیلڈ کو محدود کرتا ہے۔
جدول 8۔ پیکٹ کے سائز کی حد
| انکوڈ شدہ | ڈی کوڈ | ایم بس | ||||
| بائٹس | بائٹس | ایل فیلڈ | ||||
| دسمبر | ہیکس | دسمبر | ہیکس | دسمبر | ہیکس | |
| موڈ ایس | 255 | FF | 127 | 7 F | 110 | 6E |
| موڈ T (میٹر دیگر) | 255 | FF | 169 | A9 | 148 | 94 |
| وضع R | 255 | FF | 127 | 7 F | 110 | 6E |
یہ حدود عام طور پر وائرلیس میٹر کے استعمال کے عام کیس سے کافی اوپر ہوتی ہیں۔ بیٹری کی بہترین زندگی حاصل کرنے کے لیے پیکٹ کی لمبائی چھوٹی رکھی جانی چاہیے۔
اس کے علاوہ، صارف زیادہ سے زیادہ ایل فیلڈ کی وضاحت کر سکتا ہے جسے موصول ہونا چاہیے (USER_RX_MAX_L_FIELD)۔ یہ وصول کرنے والے بفر (USER_RX_BUFFER_SIZE) کے لیے مطلوبہ سائز کا تعین کرتا ہے۔
255 کے زیادہ سے زیادہ L-فیلڈ کو سپورٹ کرنے کے لیے 290 بائٹس کے وصولی بفر اور زیادہ سے زیادہ 581 مانچسٹر انکوڈ شدہ بائٹس کی ضرورت ہوگی۔ پیکٹ ہینڈلر کو غیر فعال کرنے کی ضرورت ہوگی اور اس صورت میں پیکٹ کی لمبائی کا رجسٹر استعمال نہیں کیا جا سکتا۔ یہ ممکن ہے، لیکن اگر ممکن ہو تو پیکٹ ہینڈلر کا استعمال کرنا زیادہ آسان ہے۔
FIFO کا استعمال
Si4431 ترسیل اور وصول کرنے کے لیے 64 بائٹ FIFO فراہم کرتا ہے۔ چونکہ انکوڈ شدہ بائٹس کی تعداد 255 ہے، اس لیے ایک پورا انکوڈ شدہ پیکٹ 64-بائٹ بفر میں فٹ نہیں ہو سکتا۔
منتقلی
ٹرانسمیشن پر، انکوڈ شدہ بائٹس کی کل تعداد کا حساب لگایا جاتا ہے۔ اگر انکوڈ شدہ بائٹس کی کل تعداد، بشمول پوسٹ اسمبل، 64 بائٹس سے کم ہے، تو پورا پیکٹ FIFO کو لکھا جاتا ہے اور صرف پیکٹ بھیجے گئے مداخلت کو فعال کیا جاتا ہے۔ زیادہ تر مختصر پیکٹ ایک FIFO ٹرانسفر میں بھیجے جائیں گے۔
اگر انکوڈ شدہ بائٹس کی تعداد 64 سے زیادہ ہے، تو پیکٹ بھیجنے کے لیے متعدد FIFO ٹرانسفرز کی ضرورت ہوگی۔ پہلے 64 بائٹس FIFO کو لکھے جاتے ہیں۔ پیکٹ بھیجے گئے اور TX FIFO تقریباً خالی رکاوٹیں فعال ہیں۔ TX FIFO تقریباً خالی حد 16 بائٹس (25%) پر سیٹ ہے۔ ہر IRQ ایونٹ پر، اسٹیٹس 2 رجسٹر پڑھا جاتا ہے۔ پہلے پیکٹ بھیجے گئے بٹ کو چیک کیا جاتا ہے، اور، اگر پیکٹ مکمل طور پر نہیں بھیجا گیا ہے، تو اگلے 48 بائٹس انکوڈ شدہ ڈیٹا کو FIFO کو لکھا جاتا ہے۔ یہ اس وقت تک جاری رہتا ہے جب تک کہ تمام انکوڈ شدہ بائٹس لکھے نہ جائیں اور پیکٹ بھیجے جانے میں خلل نہ آجائے۔
1 استقبالیہ
استقبالیہ پر، ابتدائی طور پر، صرف Sync Word interrupt کو فعال کیا جاتا ہے۔ سنک ورڈ موصول ہونے کے بعد، سنک ورڈ انٹرپٹ کو غیر فعال کر دیا جاتا ہے اور FIFO Almost Full interrupt کو فعال کر دیا جاتا ہے۔ FIFO تقریبا مکمل حد کو ابتدائی طور پر 2 بائٹس پر سیٹ کیا گیا ہے۔ پہلا FIFO Almost Full interrupt یہ جاننے کے لیے استعمال کیا جاتا ہے کہ دو لمبائی بائٹس کب موصول ہوئی ہیں۔ لمبائی موصول ہونے کے بعد، لمبائی کو ڈی کوڈ کیا جاتا ہے اور انکوڈ شدہ بائٹس کی تعداد کا حساب لگایا جاتا ہے۔ RX FIFO تقریباً پوری حد کو پھر 48 بائٹس پر سیٹ کیا جاتا ہے۔ RX FIFO تقریباً بھرا ہوا ہے اور Valid Packet interrupts فعال ہیں۔ اگلے IRQ ایونٹ پر، اسٹیٹس 1 رجسٹر پڑھا جاتا ہے۔ پہلے، درست پیکٹ بٹ کو چیک کیا جاتا ہے، اور پھر FIFO تقریباً مکمل بٹ کو چیک کیا جاتا ہے۔ اگر صرف RX FIFO تقریباً مکمل بٹ سیٹ ہے، تو اگلے 48 بائٹس FIFO سے پڑھے جاتے ہیں۔ اگر درست پیکٹ بٹ سیٹ ہے تو، پیکٹ کا بقیہ حصہ FIFO سے پڑھا جاتا ہے۔ MCU ٹریک کرتا ہے کہ کتنے بائٹس پڑھے گئے ہیں اور آخری بائٹ کے بعد پڑھنا بند کر دیتے ہیں۔
ڈیٹا لنک لیئر
ڈیٹا لنک لیئر ماڈیول 13757-4:2005 کے مطابق لنک لیئر کو لاگو کرتا ہے۔ ڈیٹا لنک لیئر (LINK) فزیکل لیئر (PHY) اور ایپلیکیشن لیئر (AL) کے درمیان ایک انٹرفیس فراہم کرتا ہے۔
ڈیٹا لنک لیئر درج ذیل افعال انجام دیتا ہے:
- ایسے فنکشنز فراہم کرتا ہے جو PHY اور AL کے درمیان ڈیٹا منتقل کرتے ہیں۔
- باہر جانے والے پیغامات کے لیے CRCs تیار کرتا ہے۔
- آنے والے پیغامات میں CRC کی خرابیوں کا پتہ لگاتا ہے۔
- جسمانی ایڈریس فراہم کرتا ہے۔
- دو طرفہ مواصلاتی طریقوں کے لیے منتقلی کو تسلیم کرتا ہے۔
- فریم ڈیٹا بٹس
- آنے والے پیغامات میں فریمنگ کی غلطیوں کا پتہ لگاتا ہے۔
لنک لیئر فریم فارمیٹ
EN 13757-4:2005 میں استعمال ہونے والا وائرلیس M-Bus فریم فارمیٹ IEC3-3-60870 سے FT5 (فریم ٹائپ 2) فریم فارمیٹ سے اخذ کیا گیا ہے۔ فریم ڈیٹا کے ایک یا زیادہ بلاکس پر مشتمل ہوتا ہے۔ ہر بلاک میں 16 بٹ CRC فیلڈ شامل ہے۔ پہلا بکس 12 بائٹس کا ایک مقررہ لمبائی والا بلاک ہے جس میں L-field، C-field، M-field، اور A-فیلڈ شامل ہیں۔
- ایل فیلڈ
ایل فیلڈ لنک لیئر ڈیٹا پے لوڈ کی لمبائی ہے۔ اس میں خود L-فیلڈ یا CRC بائٹس میں سے کوئی بھی شامل نہیں ہے۔ اس میں ایل فیلڈ، سی فیلڈ، ایم فیلڈ، اور اے فیلڈ شامل ہیں۔ یہ PHY پے لوڈ کا حصہ ہیں۔
چونکہ انکوڈ شدہ بائٹس کی تعداد 255 بائٹس تک محدود ہے، M-فیلڈ کے لیے زیادہ سے زیادہ تعاون یافتہ قدر مانچسٹر انکوڈ شدہ ڈیٹا کے لیے 110 بائٹس اور موڈ T تھری آؤٹ آف سکس انکوڈ شدہ ڈیٹا کے لیے 148 بائٹس ہے۔
لنک پرت ٹرانسمیشن پر ایل فیلڈ کا حساب لگانے کے لئے ذمہ دار ہے۔ لنک لیئر استقبالیہ پر ایل فیلڈ کا استعمال کرے گی۔
نوٹ کریں کہ ایل فیلڈ PHY پے لوڈ کی لمبائی یا انکوڈ شدہ بائٹس کی تعداد کی نشاندہی نہیں کرتا ہے۔ ٹرانسمیشن پر، PHY PHY پے لوڈ کی لمبائی اور انکوڈ شدہ بائٹس کی تعداد کا حساب لگائے گا۔ استقبال کرنے پر، PHY L-فیلڈ کو ڈی کوڈ کرے گا اور ڈی کوڈ کرنے کے لیے بائٹس کی تعداد کا حساب لگائے گا۔ - سی فیلڈ
سی فیلڈ فریم کنٹرول فیلڈ ہے۔ یہ فیلڈ فریم کی قسم کی شناخت کرتا ہے اور لنک ڈیٹا ایکسچینج سروس پرائمیٹوز کے لیے استعمال ہوتا ہے۔ سی فیلڈ فریم کی قسم کی نشاندہی کرتا ہے - بھیجیں، تصدیق کریں، درخواست کریں، یا جواب دیں۔ SEND اور REQUEST فریموں کی صورت میں، C-فیلڈ اشارہ کرتا ہے کہ آیا تصدیق یا جواب کی توقع ہے۔
بنیادی Link TX فنکشن استعمال کرتے وقت، C کی کوئی بھی قدر استعمال کی جا سکتی ہے۔ Link Service Primitives استعمال کرتے وقت، C فیلڈ EN 13757-4:2005 کے مطابق خود بخود آباد ہو جاتا ہے۔ - ایم فیلڈ
ایم فیلڈ مینوفیکچرر کا کوڈ ہے۔ مینوفیکچررز درج ذیل سے تین حرفی کوڈ کی درخواست کر سکتے ہیں۔ web پتہ: http://www.dlms.com/flag/INDEX.HTM تین حرفی کوڈ کے ہر کردار کو پانچ بٹس کے طور پر انکوڈ کیا گیا ہے۔ 5 بٹ کوڈ ASCII کوڈ لے کر اور 0x40 ("A") کو گھٹا کر حاصل کیا جا سکتا ہے۔ تین 5 بٹ کوڈز 15 بٹس بنانے کے لیے مربوط ہیں۔ سب سے اہم بٹ صفر ہے۔ - A-فیلڈ
ایڈریس فیلڈ ہر ڈیوائس کے لیے ایک منفرد 6 بائٹ ایڈریس ہے۔ منفرد پتہ کارخانہ دار کی طرف سے تفویض کیا جانا چاہئے. یہ یقینی بنانا ہر مینوفیکچرر کی ذمہ داری ہے کہ ہر ڈیوائس کا ایک منفرد 6 بائٹ ایڈریس ہو۔ فریم بھیجنے اور درخواست کرنے کا پتہ میٹر یا دوسرے آلے کا خود پتہ ہے۔ تصدیق اور جوابی ڈیٹا فریم اصل ڈیوائس کے ایڈریس کا استعمال کرتے ہوئے بھیجے جاتے ہیں۔ - سی آئی فیلڈ
CI-فیلڈ ایپلیکیشن ہیڈر ہے اور ایپلیکیشن ڈیٹا پے لوڈ میں ڈیٹا کی قسم کی وضاحت کرتا ہے۔ جبکہ EN13757-4:2005 قدروں کی ایک محدود تعداد کی وضاحت کرتا ہے، لنک سروس پرائمیٹوز کسی بھی قدر کو استعمال کرنے کی اجازت دے گا۔ - سی آر سی
CRC کی وضاحت EN13757-4:2005 میں کی گئی ہے۔
CRC کثیر الثانی ہے:
X16 + x13 + x12 + x11 + x10 + x8 +x6 + x5 +x2 + 1
نوٹ کریں کہ M-Bus CRC کا حساب ہر 16 بائٹ بلاک پر کیا جاتا ہے۔ نتیجہ یہ ہے کہ ہر 16 بائٹس ڈیٹا کو منتقل کرنے کے لیے 18 بائٹس کی ضرورت ہوتی ہے،
اضافی معلومات
لنک لیئر کے نفاذ کے بارے میں اضافی معلومات کے لیے، "AN452: Wireless M-Bus Stack Programmers Guide" دیکھیں۔
پاور مینجمنٹ
شکل 2 ایک میٹر کے لیے پاور مینجمنٹ ٹائم لائن کو ظاہر کرتا ہے۔ampموڈ T1 کا استعمال کرتے ہوئے.
توانائی کو بچانے کے لیے جب بھی ممکن ہو MCU کو سلیپ موڈ میں ہونا چاہیے۔ اس میں سابقampلی، MCU سو رہا ہے جب RTC چل رہا ہے، جب ریڈیو کرسٹل اسٹارٹ اپ کا انتظار کر رہا ہے، اور جب FIFO سے ٹرانسمٹ ہو رہا ہے۔ MCU پورٹ میچ ویک اپ سے منسلک EZRadioPRO IRQ سگنل سے جاگ جائے گا۔
ایک بلاک سے زیادہ طویل پیغامات کی ترسیل کرتے وقت، MCU کو FIFO کو بھرنے کے لیے بیدار ہونا چاہیے (FIFO تقریباً خالی مداخلت کی بنیاد پر) اور پھر سو جانا چاہیے۔
ADC سے پڑھتے وقت MCU کو کم طاقت والے آسکیلیٹر یا برسٹ موڈ آسکیلیٹر سے چلنے والے آئیڈل موڈ میں ہونا چاہیے۔ ADC کو SAR گھڑی کی ضرورت ہے۔
جب استعمال میں نہ ہو، EZRadioPRO کو شٹ ڈاؤن موڈ میں ہونا چاہیے جس میں SDN پن اونچی چلائی جائے۔ اس کے لیے MCU سے ہارڈ وائرڈ کنکشن درکار ہے۔ EZ ریڈیو پرو کے رجسٹر شٹ ڈاؤن موڈ میں محفوظ نہیں ہیں۔ لہذا، EZRadioPro کو ہر RTC وقفہ پر شروع کیا جاتا ہے۔ ریڈیو کو شروع کرنے میں 100 µs سے کم وقت لگتا ہے اور 400 nA محفوظ کرتا ہے۔ اس کے نتیجے میں 10 سیکنڈ کے وقفے کی بنیاد پر 10 µJ توانائی کی بچت ہوتی ہے۔
EZRadioPRO کرسٹل POR کے لیے تقریباً 16 ms لیتا ہے۔ یہ تقریباً آٹھ بلاکس کے لیے CRC کا حساب لگانے کے لیے کافی لمبا ہے۔ MCU واپس سو جائے گا اگر یہ کرسٹل کے مستحکم ہونے سے پہلے تمام CRCs کو مکمل کر لیتا ہے۔ اگر انکرپشن کی ضرورت ہو، تو اسے بھی کرسٹل آسیلیٹر پر انتظار کرتے ہوئے شروع کیا جا سکتا ہے۔
MCU کو زیادہ تر کاموں کے لیے کم طاقت والے آسکیلیٹر کا استعمال کرتے ہوئے 20 میگا ہرٹز پر چلنا چاہیے۔ جن کاموں کے لیے ایک درست ٹائم آؤٹ درکار ہوتا ہے ان میں سلیپ موڈ کے بجائے پریزین آکسیلیٹر اور آئیڈل موڈ کا استعمال کرنا چاہیے۔ RTC زیادہ تر کاموں کے لیے کافی ریزولوشن فراہم کرتا ہے۔ T2 میٹر سابق کے لیے پاور مینجمنٹ ٹائم لائنampلی ایپلیکیشن کو شکل 3 میں دکھایا گیا ہے۔
ٹرانسیور کے نفاذ کو عام صورت کے لیے بہتر بنایا جانا چاہیے جب میٹر جاگتا ہے اور کوئی ریڈر موجود نہیں ہوتا ہے۔ کم از کم/زیادہ سے زیادہ ACK ٹائم آؤٹ کافی لمبا ہے تاکہ C8051F930 RTC استعمال کرنا اور MCU کو سلیپ موڈ میں ڈالنا ممکن ہو۔
مینز یا USB سے چلنے والے قارئین کے لیے تعمیر کے اختیارات فراہم کیے گئے ہیں جنہیں سلیپ موڈ استعمال کرنے کی ضرورت نہیں ہے۔ آئیڈل موڈ کو نیند کے بجائے استعمال کیا جائے گا تاکہ USB اور UART MCU میں خلل ڈالیں۔
سادگی سٹوڈیو
MCU اور وائرلیس ٹولز، دستاویزات، سافٹ ویئر، سورس کوڈ لائبریریوں اور مزید تک ایک کلک تک رسائی۔ ونڈوز کے لیے دستیاب ہے،
میک اور لینکس!
 |
 |
 |
 |
| IoT پورٹ فولیو www.silabs.com/IoT |
SW/HW www.silabs.com/simplicity |
معیار www.silabs.com/quality |
سپورٹ اور کمیونٹی community.silabs.com |
ڈس کلیمر
Silicon Labs صارفین کو سسٹم اور سافٹ ویئر نافذ کرنے والوں کے لیے دستیاب تمام پیری فیرلز اور ماڈیولز کی تازہ ترین، درست، اور گہرائی سے دستاویزات فراہم کرنے کا ارادہ رکھتی ہے جو Silicon Labs کی مصنوعات کو استعمال کرنے یا استعمال کرنے کا ارادہ رکھتی ہے۔ کریکٹرائزیشن ڈیٹا، دستیاب ماڈیولز اور پیری فیرلز، میموری کے سائز اور میموری ایڈریس ہر مخصوص ڈیوائس کا حوالہ دیتے ہیں، اور فراہم کردہ "عام" پیرامیٹرز مختلف ایپلی کیشنز میں مختلف ہو سکتے ہیں اور کر سکتے ہیں۔ درخواست سابقampیہاں بیان کردہ les صرف مثالی مقاصد کے لیے ہیں۔ Silicon Labs یہاں پروڈکٹ کی معلومات، وضاحتیں، اور وضاحتوں میں مزید اطلاع اور حد بندی کے بغیر تبدیلیاں کرنے کا حق محفوظ رکھتی ہے، اور شامل معلومات کی درستگی یا مکمل ہونے کی ضمانت نہیں دیتی ہے۔ یہاں فراہم کردہ معلومات کے استعمال کے نتائج کے لیے Silicon Labs کی کوئی ذمہ داری نہیں ہوگی۔ یہ دستاویز کسی بھی مربوط سرکٹس کو ڈیزائن یا من گھڑت بنانے کے لیے یہاں دیے گئے کاپی رائٹ لائسنس کا مطلب یا اظہار نہیں کرتی ہے۔ مصنوعات کو سلیکون لیبز کی مخصوص تحریری اجازت کے بغیر کسی بھی لائف سپورٹ سسٹم میں استعمال کرنے کے لیے ڈیزائن یا اختیار نہیں کیا گیا ہے۔ ایک "لائف سپورٹ سسٹم" کوئی بھی پروڈکٹ یا سسٹم ہے جس کا مقصد زندگی اور/یا صحت کو سہارا دینا یا برقرار رکھنا ہے، جو، اگر یہ ناکام ہوجاتا ہے، تو اس کے نتیجے میں اہم ذاتی چوٹ یا موت کی معقول توقع کی جاسکتی ہے۔ سیلیکون لیبز کی مصنوعات فوجی ایپلی کیشنز کے لیے ڈیزائن یا مجاز نہیں ہیں۔ Silicon Labs کی مصنوعات کو کسی بھی حالت میں بڑے پیمانے پر تباہی پھیلانے والے ہتھیاروں بشمول جوہری، حیاتیاتی، یا کیمیائی ہتھیاروں، یا ایسے ہتھیاروں کو پہنچانے کے قابل میزائلوں میں استعمال نہیں کیا جائے گا۔
ٹریڈ مارک کی معلومات
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs®, اور Silicon Labs logo®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember® ، انرجی مائیکرو، انرجی مائیکرو لوگو اور اس کے مجموعے، "دنیا کے سب سے زیادہ توانائی دوست مائیکرو کنٹرولرز"، Ember®، EZLink®، EZRadio®، EZRadioPRO®، Gecko®، ISOmodem®، Precision32®، ProSLIC®، Simplicity Studio®، SiPHY® , Telegesis, the Telegesis Logo®, USBXpress®، اور دیگر Silicon Labs کے ٹریڈ مارک یا رجسٹرڈ ٹریڈ مارک ہیں۔ ARM، CORTEX، Cortex-M3، اور انگوٹھے ARM Holdings کے ٹریڈ مارک یا رجسٹرڈ ٹریڈ مارک ہیں۔ Keil ARM Limited کا رجسٹرڈ ٹریڈ مارک ہے۔ یہاں ذکر کردہ دیگر تمام مصنوعات یا برانڈ نام ان کے متعلقہ ہولڈرز کے ٹریڈ مارک ہیں۔
سلکان لیبارٹریز انکارپوریٹڈ
400 ویسٹ سیزر شاویز
آسٹن، TX 78701
USA
http://www.silabs.com
دستاویزات / وسائل
 |
SILICON LABS وائرلیس M-BUS سافٹ ویئر کا نفاذ AN451 [پی ڈی ایف] یوزر گائیڈ SILICON LABS, C8051, MCU, and, EZRadioPRO, Wireless M-bus, Wireless, M-BUS, Software, Implementation, AN451 |
