در مورد این ماژول ها و مدارهای واسط مورد نیاز بحث هایی شد تو قسمت اول. اما اگه بخوایم کاربرد عملیش رو ببینیم چی؟

یه مشکلی که توی این ماژول ها هست اینه که اینا تک کاناله هستند. یعنی شما وقتی با فرکانس ۳۱۵ مگاهرتز ارتباط رو برقرار میکنی اگر ماژول فرستنده یا گیرنده ی دیگه ای هم توی محدوده قرار بگیره طبق اصول فیزیک این موج هایی که تو هوا پخش میشن همپوشانی میکنن و اطلاعاتی که به مقصد میرسه درست نمیرسه بنابراین ارتباط از بین میره. اما راهکار چیه؟

توی شبکه های بیسیم مثل ZigBee مثل اینکه میان مدام تو اون باند فرکانسی که کار میکنن اسکن میکنن باند رو. البته این ماژول ها خودشون حداقل ۱۱ کانال هستن که خب کمک خیلی خوبیه اما بازم در ابعاد بزرگ چاره ی کار نیست. وقتی تو اون باند داده ای تبادل نمیشه ( داده های پرت رو میشه فهمید و حذف کرد با تکنیک هایی) فرصت هست که داده ارسال شه. کاری که تو شبکه های کابلی LAN هم انجام میشه. اونجا هم اگه اشتباه نکنم هر ۱۰۰ میلی ثانیه خط رو به مدت ۱۰ میلی ثانیه چک میکنن. اگه تو اون ۱۰ میلی ثانیه داده ای دریافت شده باشه دوباره از نو شروع میکنن و ۱۰۰ میلی ثانیه بعد دوباره خط رو اسکن میکنن. اما اگه تو اون ۱۰ میلی ثانیه خط آزاد باشه سریع اشغالش میکنن و شروع میکن به ارسال پاکت.

تو چیزی که ما ازش داریم حرف میزنیم فعلا به اون نقطه نرسیدیم که در موردش بحث کنیم اما خواستم بگم که حواستون باشه بعدا با این مشکل روبرو خواهیم شد.

اگه شما فرستنده رو وصل کنید به یه USB2COM و روی ترمینال تایپ کنید و البته سمت گیرنده هم یه USB2COM بزارید و داده ها رو نگاه کنید (مدارهای واسط فراموش نشه) میبینید که داده های دریافتی هیچ شباهتی به داده های انتقالی ندارن. اما اگه دستتون رو روی یه کلید نگه دارید تا اون حرف مدام ارسال شه بعد از چند کاراکتر نامفهوم بلاخره سمت گیرنده کاراکتر مورد نظرتون رو خواهید دید. نکته ی ریز دیگه ای هم که هست اینه که اگه شما مدام داده ی تکراری رو ارسال کنید بازم بعد از یه بازه ی زمانی داده ها از حالت اصلی خارج میشن. شاید به خاطر وجود حالت خازنی و اشباع شدنش باشه(سمت گیرنده) بنابراین باید داده ی رندوم بفرستین و وسط این داده های رندوم پاکت اصلیتون رو ارسال کنید.

نکته ی دیگه اینکه باود ریت انتقال داده رو روی ۲۴۰۰ بیت در ثانیه بزارید. هرچند فرستنده گیرنده تو دیتاشیتشون گفته شده که بیشتر هم می تونن ارسال کنن اما به شخصه بهترین نتیجه رو با این باودریت گرفتم.

اما چطور پاکت رو ارسال کنیم؟ اگه فرض کنیم تابعی به اسم putc داریم که یک بایت رو با پروتکل سریال ارسال میکنه می تونیم برنامه ی ساده ی زیر رو بنویسیم:

void send_packet(unsigned char b1,unsigned char b2,unsigned char b3)
{
	unsigned char cnt=0;
	for(cnt=0;cnt<70;cnt++)
		putc(cnt);
	putch(b1);
	putc(b2);
	putc(b3);
	for(cnt=0;cnt<10;cnt++)
		putc(cnt);
}

در حقیقت ما از یک تا ۷۰ رو برای سینک شدن ارسال میکنیم و بعدش ۳ بایت داده ی اصلیمون رو ارسال میکنیم و بعدش هم ۱۰ بایت داده ی اضافی ارسال میکنیم. البته این ده بایت می تونه کمتر هم باشه اما حداقل باید تا ۲ بایت ارسال شه.

این روش برای ارسال صحیح داده می تونه جواب بده اما سمت گیرنده اینکه از کجا بفهمیم داده ی دریافتی کجاست یه خرده سخته و برنامه حتما با خطاهای زیادی مواجه خواهد شد. بنابراین بهتره یه فریم انتقال داده درست کنیم که اول و آخرش مشخص باشه. مثلا می تونیم بعد از اون ۰ تا ۷۰ تایی که ارسال شدن سه بار کاراکتر S رو ارسال کنیم و بعد سه بایت داده ی اصلی رو بفرستیم. در آخر سه بار حرف E رو ارسال کنیم که نشون بدیم این ته فریممون هستش. البته S و E پیشنهادی هستن و هیچ الزامی به انتخابشون نیست. وقتی فریم ارسال شه سمت گیرنده باید دریافت شه که خیلی مهمه چطور دریافت شه که مطمئن شیم داده درست رسیده…

فرستنده گیرنده ی رادیویی ASK – قسمت دوم
دسته بندی شده در:                                                            

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

+ 66 = 75