Radio Packet Controller (RPC)
| Issue 4 |
RPC-UHF data
sheet
|
18th September
1997
|
| Modules: |
IC’s: |
| RPC-418-40: IC+BiM, UK version |
RPC-000-DIL*: 18 pin DIL IC |
| RPC-433-40: IC+BiM, Euro version |
RPC-000-SO* : 18 pin SO IC |
The RPC-418-A module
The RPC-418-40 and RPC-433-40 are intelligent
transceiver modules which enable a radio network/link to be simply
implemented between a number of digital devices. The module combines
a UHF radio transceiver and a 40kbit/s packet controller.
The RPC is a self-contained plug-on radio port which requires only
a simple antenna, 5V supply and a byte-wide I/O port on a host microcontroller
(or bi-directional PC port). The module provides all the RF circuits
and processor intensive low level packet formatting and packet recovery
functions required to inter-connect an number of microcontrollers
in a radio network.
A data packet of 1 to 27 bytes downloaded by a Host microcontroller
into the RPC's packet buffer is transmitted by the RPC's transceiver
and will "appear" in the receive buffer of all the RPC's
within radio range.
A data packet received by the RPC's transceiver is decoded,
stored in a packet buffer and the Host microcontroller signalled that
a valid packet is waiting to be uploaded.
figure 1: RPC + HOST µController
Click on the image for EXPANDED VIEW
figure 2: RPC-418/433-A
block diagram
Click on the image for EXPANDED VIEW
figure 3: physical dimensions
Click on the image for EXPANDED VIEW
figure 4: RPC's pinout
Click on the image for EXPANDED VIEW
- SAW controlled FM transmitter and superhet receiver
- Reliable 30m in-building range, 120m open ground
- Built-in self-test / diagnostics / status LED's
- Complies with ETSi 300-220 regulations
- Single 5V supply @ < 20mA
- 40kbit/s half duplex
- Free format packets of 1 - 27 bytes
- Packet framing and error checking are user transparent
- Collision avoidance (Listen Before Transmit)
- Direct interface to 5V CMOS logic
- Power save mode
On receipt of a packet downloaded by the Host, the RPC will append
to the packet: Preamble, start byte and a error check code. The packet
is then coded for security and mark:space balance and transmitted
through the BiM Transceiver as a 40kbit/s synchronous stream. One
of four methods of collision avoidance (Listen Before TX) may be user
selected.
When not in transmit mode, the RPC continuously searches the radio
noise for valid preamble. On detection of preamble, the RPC synchronises
to the in-coming data stream, decodes the data and validates the check
sum. The Host is then signalled that a valid packet is waiting to
be unloaded. The format of the packet is entirely of the users determination
except the 1st byte (the Control Byte) which must specify the packet
type (control or data) and the packet size. A valid received packet
is presented back to the host in exactly the same form as it was given.
- To preserve versatility, the RPC does not generate routing
information (i.e. source/ destination addresses) nor does it handshake
packets. These network specific functions left for the Host to perform.
Additional features of the RPC include extensive diagnostic/debug
functions for evaluation and debugging of the radio and host driver
software, a built in self test function and a sleep mode / wake-up
mechanism which may be programmed to reduce the average current to
less than 100µA. The operating parameters are fully programmable by
the host and held in EEPROM, the host may also use the EEPROM as a
general purpose non-volatile store for addresses , routing information
etc.
1.1 OPERATING STATES
The RPC is has four normal operating states:
- IDLE / SLEEP
- HOST TRANSFER
- TRANSMIT
- RECEIVE
IDLE/SLEEP
The IDLE state is the quiescent/rest state of the RPC. In IDLE
the RPC enables the receiver and continuously searches the radio noise
for message preamble. If the power saving modes have been enabled
the RPC will pulse the receiver on, check for preamble and go back
to SLEEP if nothing is found. The 'ON' time is 5ms, OFF time
is programmable in the RPC's EEPROM and can vary between 22 ms and
2.9 s. The TX Request line from the Host is constantly monitored and
will be acted upon if found active (low). A TX Request will immediately
wake the RPC up from SLEEP mode.
HOST TRANSFERS
If the host sets the TX Request line low a data transfer from the
Host to the RPC will be initiated. Similarly the RPC will pull RX
Request low when it requires to transfer data to the Host (this may
polled or used to generate a Host interrupt ).
The transfer protocol is fully asynchronous, i.e. the host may service
another interrupt and then continue with the RPC transfer. It is desirable
that all transfers are completed quickly since the radio transceiver
is disabled until the Host <> RPC transfer is completed. Typically
a fast host can transfer a 27 byte packet to / from the RPC in under
1ms.
TRANSMIT
On receipt of a data packet from the host, the RPC will append to
the packet - preamble, frame sync byte and an error check sum. The
packet is then coded for mark:space balance and transmitted. A full
27 byte packet is transmitted in 13.8ms of TX air time (40kb/s + 5ms
preamble).
Collision avoidance (Listen Before Transmit) functions can be enabled
to prevent loss of packets.
Data packets may be sent with either normal or extended preamble.
Extended preamble is used if the remote RPC is in power save mode.
Extended preamble length can be changed in the EEPROM memory.
RECEIVE
On detection of preamble from the radio receiver, the RPC will phase
lock, decode and error check the incoming synchronous data stream
and if successful. The data is then placed in a buffer and the RX
Request line is pulled low to signal to the host that a valid packet
awaits to be uploaded to the Host.
An in-coming data packet is presented back to the host in the same
form as it was given.
2.1 SIGNALS
It is recommended that the RPC be assigned to a byte wide bi-directional
I/O port on the host processor. The port must be such that the 4 data
lines can be direction controlled without affecting the 4 handshake
line.
| pin name |
pin no. |
pin function |
I/O |
description |
| TXR |
6 |
TX Request |
I/P |
Data transfer request from HOST to
RPC |
| TXA |
7 |
TX Accept |
O/P |
Data accept handshake back to HOST
|
| |
|
|
|
|
| RXR |
8 |
RX Request |
O/P |
Data transfer request from RPC to HOST |
| RXA |
9 |
RX Accept |
I/P |
Data accept handshake back to RPC |
| |
|
|
|
|
| D0 |
2 |
Data 0 (4) |
Bi-dir |
4 bit bi-directional data bus. Tri-state |
| D1 |
3 |
Data 1 (5) |
Bi-dir |
between packet transfers, Driven on |
| D2 |
4 |
Data 2 (6) |
Bi-dir |
receipt for Accept signal until packet |
| D3 |
5 |
Data 3 (7) |
Bi-dir |
transfer is complete. |
notes:
- The 4 Handshake lines are active low
- The 4 Data lines true data
- Logic levels are 5 volt CMOS, see electrical specifications
- Input pins have a weak pull-up internally
RESET
The Reset signal, may either be driven by the host (recommended)
or pulled up to Vcc via a suitable resistor (10kW).
A reset aborts any transfers in progress and restarts the Packet
Controller.
HOST DRIVEN RESET
Minimum low time: 1.0 µs, after reset is released (returned high).
The host should allow a delay 1ms after reset for the RPC to initialise
ifself
During this delay the host must hold TXR high (unless DIAGNOSTIC
MODES are required) and RXR signal should be ignored.
figure 5: Host to RPC connection
Click on the image for EXPANDED VIEW
2.2 HOST TO RPC DATA TRANSFER
Data is transferred between the RPC and the HOST 4
bit's (nibbles) at a time using a fully asynchronous protocol. The
nibbles are always sent in pairs to form a byte, the Least Significant
Nibble (bits 0 to 3) is transferred first, followed by the Most
Significant Nibble (bits 4 to 7). Two pairs of handshake
lines, REQUEST & ACCEPT, control the flow of data
in each direction:-
TX Request & TX Accept: control the flow from the
HOST to the RPC (download)
RX Request & RX Accept: control the flow from the
RPC to the HOST (upload)
A packet transferred between host and RPC consists of between 1 and
28 bytes, the first byte of the packet is always the control byte.
There are two classes of HOST RPC transfers:
- Data Packets: To the transmitter or from the receiver
- Memory Access: To or from the RPC's memory
figure 6: RPC to/from Host
data transfer
Click on the image for EXPANDED VIEW
2.1.1 WRITE A BYTE TO RPC
The sequence for a byte transfer from the Host to the RPC (i.e. TX
download) is asynchronous and proceeds as follows:
- HOST asserts TX Request line low to initiate transfer
- Wait for RPC to pull TX Accept low (i.e. request is accepted)
- Set data lines to output and place LS nibble on the data lines
- Negate TX Request (set to 1) to tell RPC that data is present.
- Wait for RPC to negate TX Accept (i.e. data has been accepted)
Repeat steps 1-5 with MS nibble.
figure 7: TX download timing diagram
Click on the image for EXPANDED VIEW
Notes:
- The data bus must not be set to output until step 3. i.e. after
the RPC has accepted the request. The bus may be left as an output
until the entire packet has been transferred to the RPC, it should
then be set back to input (default state).
- The RPC's normal response time to the initial TX Request may be
up to 1ms, thereafter, for the duration of the packet, the response
will be fast.
- The RPC will ignore a TX Request from the Host while it is receiving
a packet from the radio. If the incoming packet fails it's error
check the RPC will respond to the TX Request as normal, i.e. the
TX Accept from the RPC will be delayed until the incoming packet
has finished. If a valid packet is received this must be uploaded
to the Host before the RPC can respond to the Host's TX Request.
Thus an RX Request will be signalled to the Host and not the expected
TX Accept and the Host must upload the incoming packet before the
TX packet can be downloaded. The TX Request should be left asserted
(low) during the upload. The RPC will respond as normal after the
upload is completed.
- For the above reason it is often easier to use RX Request to trigger
a HOST interrupt and upload the RPC to the HOST under interrupt
control.
- See Appendix B and C. for example RPC driver subroutines.
2.1.2 READ A BYTE FROM THE RPC
The sequence for a byte transfer from the RPC to the HOST (i.e. RX
upload) is asynchronous and proceeds as follows :-
- RPC will assert RX Request line low to initiate transfer
- Host pulls RX Accept low (i.e. request is accepted by the host)
- RPC will turn on it's bus drivers, place LS nibble onto data lines
and negate RX Request (set to 1)
- Host reads the data and negates RX Accept (i.e. data has been
accepted)
Repeat steps 1-4 with MS nibble.
figure 8: RX upload timing diagram
Click on the image for EXPANDED VIEW
Notes:
- The RPC will turn off it's data bus drivers after the entire packet
has been uploaded to the HOST.
- See Appendix B and C. for example RPC driver subroutines.
2.2 HOST<>RPC PACKET FORMAT
2.2.1 THE CONTROL BYTE
The first byte of a RPC <> HOST packet transfer is always the
CONTROL BYTE. This byte is used to control the transfer and
contains information about the type of packet, number of bytes to
be transferred, memory address, read/write bit etc. Bit 7 of the control
byte is the Packet Type flag, PT, it determines the class of transfer
and the interpretation of the other bits in the control byte.
2.2.2 SENDING AND RECEIVING DATA PACKETS
Data packets are sent to / received from remote RPC's. They begin
with a control byte with bit 7 cleared and may be of variable length
and contain up to 27 bytes of user determined data.
figure 9: Control byte for
data packet
Click on the image for EXPANDED VIEW
The remainder of the bytes in the data packet are of the users determination.
The packet would usually be made up of a number of fields consisting
of some but not necessarily all of the following :-
- Source address / ID
Destination address / ID
System ID
Packet count
Encryption / Scrambler control
Additional error check codes ( The RPC performs it's own error checks)
Routing information ( for repeaters)
Link control codes (connect/disconnect/ACK/NAK etc.)
Data field
2.2.3 RPC MEMORY ACCESS
The RPC's EEPROM memory can be accessed by setting bit
7 in the control byte. Bit 6 (R/W flag) defines a memory read or write.
The bits left define the address.
figure 10: RPC memory access
Click on the image for EXPANDED VIEW
RPC Memory READS:
Host issues just the control byte, with bit 6 (W/R) cleared, bit
7 (PT) set and the memory address. The RPC will respond with 2 bytes,
the first is a control byte which is an echo of the control byte just
issued by the host, this is useful if the host is using an interrupt
handler. The 2nd byte is the memory contents.
RPC Memory WRITES:
Host issues 2 bytes, the first is the control byte with
bit 6 (W/R) set, bit 7 (PT) set and the memory address. The 2nd byte
is the data to be written. The RPC does not give a response to memory
writes.
figure 11: Control byte for
memory access
Click on the image for EXPANDED VIEW
Notes
- Memory writes to locations 01 to 3F, write to the non-volatile
EEPROM in the RPC. The EEPROM has a limit of 100,000 write cycles
therefor it's use must be restricted to infrequently changed data.
The RPC only writes to the EEPROM when instructed to by the HOST.
Each byte takes 10ms to write. To prevent accidental/spurious writes
to EEPROM the host must set the WE bit in SWITCHES prior to EACH
byte to be written. We recommend that the host performs a read/verify
after each byte write to EEPROM.
The above does not apply to any memory reads nor to writes to SWITCHES
(address 00 H).
SWITCHES is memory location 00 in RAM, it contains 8
flags which are used to determine the RPC's operation. On RPC reset,
power-up or watchdog Time-Out it is loaded from location 08 (in EEPROM).
The default value is 00 hex - this is all functions deselected.
figure 12: Switches
Click on the image for EXPANDED VIEW
3.1 PS0 & PS1 - POWER SAVING
The RPC has 4 levels of power saving selected by PS0 & PS1 in
SWITCHES. Power saving is achieved by shutting down the Transceiver
and the RPC for a period of time (OFF-TIME) when the RPC is
in the Idle state (i.e. nothing happening). During the OFF period
current is reduced to the device leakage of < 50 µA typ. The RPC
will still respond immediately to a Host TX Request but cannot receive
radio signals. After the programmed OFF-TIME the RPC will wake
itself up, turn the receiver on and listen for valid preamble. ON
time = PWR->RX (EEPROM address 05) + 1ms = 4ms (using RPC Default
values) If preamble is found the RPC will stay ON and decode the packet,
if not the RPC will shut down for another OFF time period.
Also see - WAKE-UP (address 02 of EEPROM) and paragraph 2.2.2.
| PS1 |
PS0 |
|
|
| |
|
|
|
| 0 |
0 |
CONTINUOUS |
20mA (no power saving) |
| 0 |
1 |
POWER SAVE |
programmable sleeptime * |
| 1 |
0 |
SLEEP |
< 100µA (fixed off time of 2.9s)
|
| 1 |
1 |
OFF |
< 50µA Transceiver is off (reset
or
TXR to wake-up) |
* Sleeptime programmable in EEPROM address 03 H.
| value |
off
|
-time |
Average current |
| 00 |
22 |
ms |
2.95 mA |
| 01 |
45 |
ms |
1.60 mA |
| 02 |
90 |
ms |
0.85 mA |
| 03 |
181 |
ms |
0.46 mA |
| 04 |
362 |
ms |
0.26 mA |
| 05 |
725 |
ms |
0.16 mA |
| 06 |
1.45 |
s |
0.10 mA |
| 07 |
2.9 |
s |
0.08 mA |
The supply current's quoted above are typical for a BiM + RPC using
the EEPROM default values.
Both the Host and the Radio interfaces can 'hang' the RPC while it
waits for an external event. Under error conditions the RPC will reset
itself if the appropriate HTO or RTO switch is set.
| RTO |
Radio Time Out. |
| 0 |
no time out |
| 1 |
Time-Out and reset if > 2.9s of
plain preamble detected. (note. valid extended preamble used for
wake-ups will not cause a Time-Out to be detected) |
| HTO |
Host Time Out |
| 0 |
no time out |
| 1 |
Time-Out and reset if Host fails to
reply to any request or handshake within 2.9s |
This bit protects the EEPROM from accidental writes, it must be set
to 1 prior to each byte write to the EEPROM (addresses 01h to 3Fh).
This bit will be cleared by the RPC after each byte write.
Writing a 1 to this switch will initiate a radio self test. Both
the transmitter and receiver are enabled, data is feed to the TX and
checked for correct recover from the RX. If the test is good, the
ST bit will set, if the test fails the ST bit will not set. The self
test takes 20ms to complete.
Listen Before Transmit, LBT, and Delay Before Transmit, DBT determine
what collision avoidance the RPC will take before each transmission.
| LBT |
DBT |
Function |
| 0 |
0 |
Immediate TX, no channel check |
| 0 |
1 |
Fixed delay TX, no channel check
(time slots)
This is useful for rapid polling of up to 255 units by a master
station. SLOTS is set to the units ID number, the packet size,
preamble length and change over delay must be the same for all
units being polled.
(see - EEPROM parameters) |
| |
|
|
| 1 |
0 |
Immediate TX, if channel is clear
The receiver is turned on and the channel checked for
preamble or data. The RPC will only go to transmit when the channel
is clear. |
| |
|
|
| 1 |
1 |
Random delay TX, if channel is
clear
This mode is useful in random assess networks where there
is a high statistical probability that more than 2 RPC's could
attempting to transmit at the same time. The receiver is turned
on and the channel checked for preamble or data. If the channel
is clear the RPC will go to transmit, if the channel is busy the
RPC will delay by a random time (setable by TX-BACK-OFF in EEPROM)
then try again for a clear channel. |
The EEPROM has address range 01h - 3Fh (63 Bytes)
The first 15 BYTES (8 are defined) contain parameters used to control
the RPC.
figure 13: RPC's EEPROM memory
Click on the image for EXPANDED VIEW
| Preamble |
Number of "01"
preamble cycles on TX packets |
| |
One '01' cycle takes 50µs
@ 40kbit/s |
address
default
formula
valid range |
01
64
Preamble time = Preamble * 0.05 ms
01 to FF |
| |
|
| Wake-Up |
Number of units of
'Wake-Up Preamble + Please Hold Line'
To be sent as extended preamble to wake-up a remote RPC in power
save mode. Wake-Up should be set to approx. 1.5 times the
remote units OFF Time |
address
default
formula
valid range |
02
FF
Wake-up message = Wake-Up * 13.1 ms
01 to FF |
| |
|
| Sleep-Time |
Power Save 'Off'
Time (RC controlled)
The OFF time is controlled by an RC oscillator in the RPC which
has a wide tolerance of ±30% |
address
default
formula
valid range |
03
05
Off-time = 22* 2Sleep-Time ms
00 to 07 |
| |
|
TX <-> RX
address
default
formula
valid range |
TX <-> RX change
over delay in units of 100µs
04
1E
Delay = TX<->RX * 0.1 ms
01 to FF |
| |
|
PWR RX
address
default
formula
valid range |
RX stabilisation
delay in units of 100µS
05
1E
Delay = PWR-> RX * 0.1 ms
01 to FF |
| |
|
| TX-Back-Off
|
Maximum TX Back-off
delay in units of 1ms
Used when LBT=1 & DBT=1 |
address
default
formula
valid range |
06
03
maximum delay = (2TX-Back-Off - 1) ms
00 to 07 |
| |
00 = 0 - 1 ms
01 = 0 - 3 ms
02 = 0 - 7 ms
03 = 0 - 15 ms |
04= 0 - 31 ms
05 = 0 - 63 ms
06 = 0 - 127 ms
07 = 0 - 255 ms |
| |
|
| TX-Slot |
0 - 255 slot number
for delayed (polled) TX
Delayed TX in packet units, used when LBT=0 & DBT=1 |
address
default
formula |
07
01
delay = TX-Slot * (Preamble*0.05 + Tpacket + 3*TX<->
RX + 0.5) ms where Tpacket = Number of bytes in packet
* 0.30 ms |
| valid range |
00 to FF |
| |
|
| Reset State |
Reset State Of Switches
The contents of this address are copied into Switches on
RPC reset, power-up or watchdog Time-Out |
address
default |
08
00 |
Address 09 to 0F are reserved for future and should not be
used by the HOST
EEPROM Addresses 10h TO 3Fh (48 BYTES) are free for HOST use
as general storage.
These special test modes are useful for system testing and debugging
To select these modes the RPC should be released from
reset with the TXR line held low, normal RPC operation will resume
when the TXR is set high, i.e. TXR should be held while in these test
modes.
figure 14: diagnostic mode
selection timing diagram
Click on the image for EXPANDED VIEW
note: For normal operation of the RPC the TXR line
must be held high for either 1ms after a reset pulse or 100ms after
a power up.
There are 9 test modes which are selected by a binary code applied
to the RPC's data bus. A 4 bit DIL switch or rotary HEX switch connected
between the data bus and 0V will select the modes (the RPC has weak
internal pull-up's). Alternatively the HOST may select the test modes
by holding TXR low, resetting the RPC and driving the required test
mode code onto the data bus.
note: The RPC continuously monitors the mode selected
i.e. a reset is not required on mode changes.
In some modes the RXR output from the RPC is driven low to indicate
'pass' or 'OK'. An LED + 1kW from RXR to 5V is recommended.
| Mode |
Name |
Function |
| 0 |
RX-On |
Preamble Detector On
(RXR LED = preamble detected) |
| 1 |
RX-Pulse |
10ms ON : 10ms OFF, Preamble Detector
On RXR LED |
| 2 |
TX-On-Pre |
Preamble Modulation - send continuous
preamble |
| 3 |
TX-On-Sq |
100 Hz Square Wave Mod - TX
testing on spec. analyser. |
| 4 |
TX-On-255 |
random 40kb/s data for Eye diagram
tests, sync's on RXR |
| 5 |
TX-Pulse |
10ms ON : 10ms OFF, Preamble bursts,
RX lock in tests |
| 6 |
Echo |
Transponder mode, re-transmit
any valid packets received |
| 7 |
Radar |
Send ASCII Test Packet "RADIOMETRIX"
and listen for echo. |
| 8 |
Self-Test |
Loop test, TX > RX (OK on RXR) |
Modes 6 & 7 are particularly useful for software debugging and
range testing.
figure 15: stand-alone diagnostic
mode
Click on the image for EXPANDED VIEW
| D3 |
D2 |
D1 |
D0 |
Mode |
| 0 |
0 |
0 |
0 |
0 |
| 0 |
0 |
0 |
1 |
1 |
| 0 |
0 |
1 |
0 |
2 |
| 0 |
0 |
1 |
1 |
3 |
| 0 |
1 |
0 |
0 |
4 |
| 0 |
1 |
0 |
1 |
5 |
| 0 |
1 |
1 |
0 |
6 |
| 0 |
1 |
1 |
1 |
7 |
| 1 |
0 |
0 |
0 |
8 |
A Detailed look at the RPC's transceiver interface
The RPC interfaces to the transceiver using 4 lines :-
| TX |
output |
Active low enable for the transmitter |
| TXD |
output |
Serial data to be sent. |
| |
|
|
| RX |
output |
Active low enable for the receiver. |
| RXD |
input |
Received serial data. |
note 1 All lines are 5 volt
CMOS levels.
note 2 There is no requirement
for a carrier/signal detect signal from the transceiver nor for the
RXD output to be muted when no signal is present.
The enable lines - TX & RX
These normally high, active low lines are used to control the transceiver.
The RPC is a half-duplex controller thus in normal operation the transceiver
is either transmitting or receiving or off. The RPC only enables the
TX and the RX at the same time during self test (local loop back).
Transmit Data - TXD
TXD is the serial data to the transmitter, it is held low when the
transmitter is not enabled. When the TX is enabled a synchronous 40kbit/s
(25.0 µs/bit) serial code is present to modulate the transmitter.
Receive Data - RXD
RXD is a hi-impedance input which is feed with a 'squared-up' (5V
logic level) signal from the receivers' data slicer. The RPC contains
a very selective, noise immune signal detector and therefor does not
require that the RXD signal be muted in the absence of signal, i.e..
squared-up channel noise may be fed to the RPC when no signal is present.
The RPC's Packet Encoder
The packet is made-up of 4 parts:
Preamble
This is a simple 20kHz square wave, the number of cycles being programmed
by address 01h of the EEPROM. The preamble has two functions, the
initial portion it is used to allow the data slicer in a remote receiver
to establish the correct slicing point (for the BiM-XXX-F this takes
a maximum of 3ms), after the receiver has settled, the remaining portion
is used by the receiving RPC to positively identify and phase lock
onto the incoming the signal (this requires 15 cycles of preamble).
The preamble may extended to wake-up a remote RPC in power saving
mode.
Frame sync
A 7 bit Barker sequence is used to identify the start of the data.
Alternatively if the transmitter is sending extended preamble (to
wake a power saving remote RPC) a complimented 7 bit Barker sequence
is sent every 256 preamble cycles as a 'Please Hold The Line' code.
An 8th balancing bit is added after the Barker sequence.
Data
Each byte in the RPC's buffer is expanded into a 12 bit symbol prior
to sending. The symbol coding has the following properties :-
- Perfect 50:50 balance, i.e.. always 6 one's & 6 zero's
- There are never more than 4 consecutive one's or zero's. This
minimises the low frequency components in the code and allows fast
settling times to be used for the receivers' data slicer.
- Minimum Hamming distance = 2, i.e.. each code is different from
any other code by a minimum of 2 bits, thus all odd number of bit
errors will always be detected.
- In general only 256 of 4096 (6.25%) possible codes are valid,
i.e.. a 93.75 % probability of trapping a byte error.
- Preamble and the Frame sync codes are not part of the symbol alphabet,
an 'clash' signal will cause immediate termination of the current
decode followed by an attempt to lock to the new signal.
Check Sum
Since the receiver checks each symbol for integrity, a simple 8 bit
check sum is used to test for overall packet integrity. This is also
coded into a 12 bit symbol prior to transmission.
The RPC's Packet Decoder
Signal Decoding is in 4 stages :-
Search
Initially the RPC's decoder searches the radio noise on the RXD line
for the 20kHz preamble signal. The search is performed by a 16 times
over-sampling detector which computes the spectral level of 20kHz
in 240 samples of the RXD signal (750µs window). If the level exceeds
a pre-set threshold the decoder will attempt to decode a packet.
Lock-in
The same set of 240 samples are used to compute the phase of the incoming
preamble and synchronise the internal recovery clock to an accuracy
of ±2µs. The recovery clock samples the mid point of each incoming
data bit and shifts the samples trough an 8 bit serial comparator.
The comparator searches the data on a bit by bit basis for the frame
sync byte. While the search is in progress, the decode will abort
if the preamble fails to maintain a certain level of integrity. If
the comparator finds the 'please hold the line' code used during extended
wake-up preamble a phase re-lock is triggered to ensure accurate phase
tracking until the actual packet arrives. When the frame sync is detected
the decoder attains full synchronisation and will move to the Decode
state.
Decode
Data is now taken in 12 bits at a time (one symbol), decoded into
the original byte and placed in the receive buffer. The symbol decoder
verifies each received symbol as valid (only 256 out of a possible
4096 are valid) and will immediately abort the decode on a symbol
failure. The first byte contains the byte count and is used to determine
the end of message.
Check Sum
The last byte is the received check sum, this is verified against
a locally generated sum of all the received bytes in the packet. If
it matches the packet is valid and RXR line will be pulled low to
inform the Host that a packet awaits uploading.
Notes on error handling
The RPC's' decoder is deliberately non bit error tolerant, i.e..
no attempt is made to repair corrupt data bits. All of the redundancy
in the code is directed towards error checking. For an FM radio link
using short packet lengths, e.g. RPC + BiM , packets are either 100%
or so grossly corrupt as to be unrecoverable. By the same reasoning,
the Host is not informed when the RPC decoder aborts a packet decode
since corrupt information is of little value. An packet acknowledge
Time-Out and re-transmission is the preferred strategy for error handling.
Example RPC driver subroutines for Arizona PIC16C73
figure 16: RPC to PIC-uC interface
Click on the image for EXPANDED VIEW
Packet transfers to/from the RPC are best handled in the host by
two subroutines :- OUT_BYTE & IN_BYTE
Additionally LISTEN_BUS is called on completion of a packet transfer
to the RPC to return the data bus to inputs (default state).
RPC DRIVERS
| ; |
|
HOST PROCESSOR PIC16C73
or similar |
| ; |
|
|
|
| RPC |
EQU |
06 |
; USE PORT B ON PIC |
| ; |
|
|
|
| ; |
|
|
** Bit assignments for
RPC PORT ** |
| ; |
|
|
|
| D7 |
EQU |
7 |
;Bi-Dir |
| D6 |
EQU |
6 |
;Bi-Dir |
| D5 |
EQU |
5 |
;Bi-Dir |
| D4 |
EQU |
4 |
;Bi-Dir |
| TXA |
EQU |
3 |
;INPUT |
| TXR |
EQU |
2 |
;OUTPUT |
| RXA |
EQU |
1 |
;OUTPUT |
| RXR |
EQU |
0 |
;INPUT |
| |
|
|
|
| RPC_DDR |
|
86 |
;Data direction register
for port B (RPC) |
| |
|
|
;This register is in
BANK 1 of the register file |
| ; |
|
|
|
| ;---------------------------------------------------------------- |
| ; |
|
|
|
| W |
EQU |
0 |
; Accumulator as Destination |
| F |
EQU |
1 |
; Register File as Destination |
| INDF |
EQU |
00 |
; INDirect File Register |
| ; |
| ; SUBROUTINEIN_BYTE |
| ; |
|
|
|
| ; IN_BYTE |
READ A BYTE FROM THE
RPC INTO FILE POINTED TO BY FSR |
| ; |
W IS DESTROYED |
| ; |
|
|
|
| ; |
NOTE |
THIS ROUTINE WILL HANG
THE HOST UNTIL THE HOST |
| ; |
|
COMPLETES THE TRANSFER
OF TWO NIBBLES. |
| ; |
|
|
|
| ; |
|
THIS SUBROUTINE CAN
BE CONFIGURES TO RUN AS PART OF AN |
| ; |
|
INTERRUPT HANDLER IF
THE RXR LINE FROM THE RPC |
| ; |
|
IS USED TO TRIGGER A
HOST INTERRUPT |
| ; |
|
|
|
| IN_BYTE |
BTFSC |
RPC,RXR |
; WE GOT A RX REQUEST
YET? |
| |
GOTO |
IN-BYTE |
; NO, SO LOOP BACK AND
WAIT |
| ; |
|
|
|
| ; |
READ THE LS NIBBLE FROM
THE RPC |
| ; |
|
|
|
| |
BCF |
RPC,RXA |
;ACCEPT THE REQUEST
(SET ACCEPT LOW) |
| ; |
|
|
|
| AWAITDATA |
BTFSS |
RPC,RXR |
;HAS REQUEST GONE UP?
data is present |
| |
GOTO |
AWAITDATA |
;LOOP BACK TILL IT DOES |
| ; |
|
|
|
| |
NOP |
|
; TIME DELAY TO ENSURE
DATA STABLE |
| |
|
|
; BEFORE READ |
| ; |
|
|
|
| |
MOVF |
RPC,W |
; READ THE LS NIBBLE
FROM THE BUS |
| |
BSF |
RPC,RXA |
; TELL RPC WE GOT NIBBLE
(ACCEPT = 1) |
| |
ANDLW |
B'11110000 |
; JUST THE DATA |
| ; |
|
|
|
| |
MOVWF |
INDF |
; SAVE LS NIBBLE IN
TARGET FILE (VIA FSR) |
| |
SWAPF |
INDF,F |
; RIGHT JUSTIFY LS NIBBLE |
| ; |
|
|
|
| ; |
NOW GET MS NIBBLE FROM
THE RPC |
| ; |
|
|
|
| INNIBBLE |
BTFSC |
RPC,RXR |
; WE GOT NEXT RX REQUEST
YET ? |
| |
GOTO |
INNIBBLE |
; NO , SO LOOP BACK
AND WAIT |
| ; |
|
|
|
| |
BCF |
RPC,RXA |
;ACCEPT REQUEST SET
ACCEPT LOW) |
| ; |
|
|
|
| AWAITD1 |
BTFSS |
RPC,RXR |
;HAS REQUEST GONE UP?
data is present |
| |
GOTO |
AWAITD1 |
;LOOP BACK TILL IT DOES |
| ; |
|
|
|
| |
NOP |
|
;TIME DELAY TO ENSURE
DATA STABLE |
| |
|
|
;BEFORE READ |
| ; |
|
|
|
| |
MOVF |
RPC,W |
;READ THE MS NIBBLE
FROM THE BUS |
| |
BSF |
RPC,RXA |
;TELL RPC WE GOT NIBBLE
(ACCEPT=1) |
| |
ANDLW |
B'11110000' |
;JUST THE DATA |
| ; |
|
|
|
| |
IORWF |
INDF,F |
;COMBINE MS NIBBLE WITH
LS NIBBLE |
| |
|
|
;ALREADY IN THE FILE
(VIA FSR)RETURN |
| ; |
|
|
|
| ; A BYTE HAS BEEN READ
FROM THE RPC INTO ADDRESS POINTED AT BY FSR |
| ; |
|
|
|
| ;---------------------------------------------------------------- |
| ; |
|
|
|
| ; OUT_BYTE WRITE A BYTE
FROM FILE POINTED TO BY FSR TO RPC |
| ; |
W IS DESTROYED |
| ; |
|
|
|
| ; |
NOTE |
THIS ROUTINE WILL HANG
THE HOST UNTIL THE RPC |
| |
|
ACCEPTS THE TRANSFER
OF TWO NIBBLES |
| ; |
|
|
|
| ; |
WARNING |
OUT_BYTE WILL SET THE
DATA BUS TO DRIVE AFTER |
| ; |
|
DETECTING A TXA FROM
THE RPC. |
| ; |
|
THE CALLING ROUTINE
MUST SET 4 DATA LINES |
| ; |
|
BACK TO I/P ON COMPLETION
OF PACKET TRANSFER |
| ; |
|
(i.e. call LISTENBUS) |
| ; |
|
|
|
| OUT_BYTE |
SWAPF |
INDF,W |
; GET LS NIBBLE FROM
FILE (VIA FSR) INTO |
| |
|
|
; BITS 4 to 7 of W |
| |
ANDLW |
B'11110000' |
; JUST THE NIBBLE |
| |
IORLW |
B'00000010' |
; SET TXR LOW, LEAVE
RXA HIGH |
| |
MOVWF |
RPC |
;SET TXR LOW, OUTPUT
NIBBLE |
| ; |
|
|
|
| WACCEPT |
BTFSC |
RPC,TXA |
;WE GOT A TX ACCEPT
BACK YET? |
| |
GOTO |
WACCEPT |
;NO, SO LOOP BACK AND
WAIT |
| ; |
|
|
|
| ; WE GOT ACCEPTANCE
SO IT'S OK TO DRIVE BUS |
| ; |
|
|
|
| |
BSF |
STATUS,RP0 |
; SELECT PAGE 1 |
| |
MOVLW |
B'00001001' |
; DRIVE BUS |
| |
MOVWF |
RPC_DDR |
|
| |
BCF |
STATUS,RP0 |
;SELECT PAGE 0 BUS IS
NOW DRIVING |
| ; |
|
|
|
| |
BSF |
RPC,TXR |
;REMOVE REQUEST, DATA
IS ON BUS |
| WDUN |
BTFSS |
RPC,TXA |
;HAS DATA BEEN READ? |
| |
GOTO |
WDUN |
; WAIT TILL RPC REMOVES
ACCEPT |
| ; |
|
|
|
| ; LS NIBBLE OF (FSR)
IS SENT , NOW DO MS NIBBLE |
| ; |
|
|
|
| |
MOVF |
INDF,W |
;GET MS NIBBLE FROM
FILE (VIA FSR) |
| ; |
|
|
|
| |
ANDLW |
B'11110000' |
;JUST THE MS NIBBLE |
| |
IORLW |
B'00000010' |
;SET TXR LOW (BIT 2),
RXA STAYS HIGH |
| |
MOVWF |
RPC |
; OUTPUT NIBBLE + TXR
LOW |
| WACCEPT1 |
BTFSC |
RPC,TXA |
; WE GOT A TX ACCEPT
BACK YET? |
| |
GOTO |
WACCEPT1 |
; NO, SO LOOP BACK AND
WAIT |
| |
BSF |
RPC,TXR |
;REMOVE REQUEST, DATA
IS ON BUS |
| WDUN1 |
BTFSS |
RPC,TXA |
;HAS DATA BEEN READ? |
| |
GOTO |
WDUN1 |
;WAIT TILL RPC REMOVES
ACCEPT |
| |
RETURN |
|
|
| ; |
BYTE IS SENT TO RPC |
| ;---------------------------------------------------------------- |
| ; SUBROUTINE- LISTEN_BUS
, SET DATA BUS TO INPUT |
| ; |
|
|
|
| LISTEN_BUS |
BSF |
STATUS,RP0 |
;SELECT PAGE 1 |
| |
MOVLW |
B'11111001' |
;BUS TO INPUT |
| |
MOVWF |
RPC_DDR |
|
| |
BCF |
STATUS,RP0 |
;SELECT PAGE 0 |
| |
RETURN |
|
|
| ; ---------------------------------------------------------------- |
| ; |
BUS IS LISTENING TO
RPC |
| ; ---------------------------------------------------------------- |
Example RPC driver subroutines for Motorola
68HC11
figure 17: RPC to HC11-uC interface
Click on the image for EXPANDED VIEW
Packet transfers to / from the RPC are best handled in the host by
two subroutines :- OUT_BYTE & IN_BYTE
Additionally LISTEN_BUS is called on completion of a packet transfer
to the RPC to return the data bus to inputs (default state).
| ***************************************************************** |
| * |
|
|
|
| * CPU REGISTER EQUATION |
| * |
|
|
|
| ***************************************************************** |
| * |
|
|
|
| * This section contains a few
of the necessary register equations used |
| * in the example subroutines. |
| |
|
|
|
| PORTC |
EQU |
$1003 |
;ADDRESS OF RPC PORT |
| |
|
|
|
| DDRC |
EQU |
$1007 |
;DATA DIRECTION REGISTER PORT-C |
| |
|
|
|
| *Port-C7 = RX-accept OUTPUT |
| * Port-C6 = RX-request INPUT |
| * Port-C5 = TX-accept INPUT |
| * Port-C4 = TX-request OUTPUT |
| * Port-C3 = RPC data bit-3 |
| * Port-C2 = RPC data bit-2 |
| * Port-C1 = RPC data bit-1 |
| * Port-C0 = RPC data bit-0 |
| |
|
|
|
| ***************************************************************** |
| * |
| * RANDOM ACCESS MEMORY |
| * |
|
|
|
| ***************************************************************** |
| |
ORG |
RAM |
;RAM AREA DEFINITION |
| SAVE_1 |
RMB |
1 |
;TEMPORARILY SAVE LOCATION 1 |
| SAVE_X |
RMB |
2 |
;HOLDS FILES POINTER FOR IN_BYTE |
| |
|
|
|
| ***************************************************************** |
| * |
|
|
|
| * SUBROUTINE: IN_BYTE |
| * |
|
|
|
| ***************************************************************** |
| |
|
|
|
| * This subroutine is designed to
be called by an interrupt handler to |
| * read a byte from the RPC into
a file pointed at by X |
| * |
|
|
|
| * Note: The interrupt handler
should load the X register with the file |
| * address before calling this
subroutine. |
| |
|
|
|
| IN_BYTE |
CLR |
SAVE_1 |
;CLEAR TEMPORARILY MEMORY LOCATION |
| |
LDAB |
#%10010000 |
; SET CORRECT DATA DIRECTION i/p |
| |
STAB |
DDRC |
|
| WAIT_RQ |
LDAB |
PORTC |
;WAIT FOR RX-REQUEST TO GO LOW |
| |
BITB |
#%01000000 |
|
| |
BNE |
WAIT_RQ |
|
| IN_LP |
LDAB |
PORTC |
|
| |
ANDB |
#%01111111 |
;FORCE RX-ACCEPT TO GO LOW |
| |
STAB |
PORTC |
|
| WAIT_RQ1 |
LDAB |
PORTC |
;WAIT FOR RX-REQUEST TO GO HIGH |
| |
BITB |
#%01000000 |
|
| |
BEQ |
WAIT_RQ1 |
|
| DAT_IN |
LDAA |
PORTC |
