על ידי ibm123 » ב' אפריל 04, 2011 10:28 pm
שולם ותודה
יש הרבה דרכים מוזרות לעקוף את העניין.. אבל נראה לי שהכי טוב זה להבין מה הסיבה
וע"י כך לגרום לשידור ולקליטה להיות תקינים
אני מצרף מספר דברים שקראתי לגבי העניין.. אולי תוכלו לעזור לי לגבש אסטרטגיה
I've been playing with the 4800bps 434MHz modules and have gotten them working. There are a few details I discovered using a logic analyzer and I thought I'd post them for everybody's benefit. Some of this has been noted before, but it is worth repeating.
1) If you let the TX data line stay low for a while it stops transmitting, causing the receiver to crank up its AGC and receive noise. Note that the noise is structured such that it will cause bogus bytes to be received
2) If you let the TX data line stay high for a while, the receiver starts to receive a low value. I think the TX is still on, but the RX must be filtering our LF or DC components.
3) If you send data continuously, you do not run afoul of #1 or #2. However, you should periodically allow TX to go idle for just over 1 frame time to ensure the UARTs stay in sync.
4) If you do hit #1 or #2, then you will need to send some bytes to get the RX module's AGF and HPF happy with your data. At 2400bps, I found 2 bytes usually sufficient, and at 4800bps, 10 usually got things going again.
5) The H->L edge latency seems to be around 33uS, but the L->H edge latency is around 100uS. This prevented me from getting the link working at 7200 or 8000 bps. The latency difference may be due to the low drive current of the RX data line. A buffer might help make things more symmetrical and allow slightly higher data rates.
The algorithm I settled on is as follows:
Each packet starts with a preamble of 0x55 bytes (3 for 2400bps, 12 for 4800bps), followed by a 1-frame-time gap so the RX UART can get back in sync, followed by a 0x0f start byte, then the payload data, and then a checksum. Packets are kept fairly short (~128 bytes) due to a fairly high error rate.