• Typical features
• Introduction
• Functional Description
  • Operating States
• The Host Interface
  • Signals
  • Host To FRPC2 Data Transfer
  • Host < > FRPC2 Packet Format
• FRPC2's Switches
  • PS0 & PS1 - Power Saving
  • HTO & RTO - Interface Time-Out
  • WE - EEPROM Write Enable
  • LBT & DBT
• User Configurable Parameters In EEPROM
• Diagnostic / Debug Test Modes
• Appendix-A
• Appendix-B
• Appendix-C
• Appendix-D

Typical features

• SAW controlled FM transmitter and superhet receiver
• Reliable 50m in-building range, 200m open ground
• Built-in self-test / diagnostics / status LED's
• Complies with ETSI EN 300 220-3
• Complies with ETSI EN 301 489-3
• Single 5V supply @ < 25mA
• 160kbps half duplex
• Free format packets of 1 - 60 bytes
• Packet framing and error checking are user transparent
• Collision avoidance (Listen Before Transmit)
• Direct interface to 5V CMOS logic
• Power save mode

INTRODUCTION

The FRPC2 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 60 bytes downloaded by a Host microcontroller into the FRPC2's packet buffer is transmitted by the FRPC2's transceiver and will "appear" in the receive buffer of all the FRPC2's within radio range.

A data packet received by the FRPC2'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: FRPC2 + HOST µController

figure 2: FRPC2-433-160 block diagram

figure 3: physical dimensions

figure 4: FRPC2's pinout

1. FUNCTIONAL DESCRIPTION

On receipt of a packet downloaded by the Host, the FRPC2 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 BiM2 Transceiver as a 160kbit/s synchronous stream. One of four methods of collision avoidance (Listen Before TX) may be user selected.

When not in transmit mode, the FRPC2 continuously searches the radio noise for valid preamble. On detection of preamble, the FRPC2 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 FRPC2 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 FRPC2 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 FRPC2 is has four normal operating states:

• IDLE / SLEEP
• HOST TRANSFER
• TRANSMIT
• RECEIVE

IDLE/SLEEP
The IDLE state is the quiescent/rest state of the FRPC2. In IDLE the FRPC2 enables the receiver and continuously searches the radio noise for message preamble. If the power saving modes have been enabled the FRPC2 will pulse the receiver on, check for preamble and go back to SLEEP if nothing is found. The 'ON' time is 2.5ms, OFF time is programmable in the FRPC2's EEPROM and can vary between 22 ms and 181ms. 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 FRPC2 up from SLEEP mode.

HOST TRANSFERS
If the host sets the TX Request line low a data transfer from the Host to the FRPC2 will be initiated. Similarly the FRPC2 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 FRPC2 transfer. It is desirable that all transfers are completed quickly since the radio transceiver is disabled until the Host <> FRPC2 transfer is completed. Typically a fast host can transfer a 60 byte packet to / from the FRPC2 in under 1ms.

TRANSMIT
On receipt of a data packet from the host, the FRPC2 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 60 byte packet is transmitted in 6ms of TX air time (60 byte data @ 160kb/s + 1.25ms 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 FRPC2 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 FRPC2 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. THE HOST INTERFACE

2.1 SIGNALS

It is recommended that the FRPC2 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.

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 FRPC2 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 FRPC2 connection
Click on the image for EXPANDED VIEW

2.2 HOST TO FRPC2 DATA TRANSFER

Data is transferred between the FRPC2 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 FRPC2 (download)
RX Request & RX Accept: control the flow from the FRPC2 to the HOST (upload)

A packet transferred between host and FRPC2 consists of between 1 and 61 bytes, the first byte of the packet is always the control byte.

There are two classes of HOST<—>FRPC2 transfers:

1. Data Packets: To the transmitter or from the receiver
2. Memory Access: To or from the FRPC2's memory
   
   

3. figure 6: FRPC2 to/from Host data transfer
   

2.2.1 WRITE A BYTE TO FRPC2

The sequence for a byte transfer from the Host to the FRPC2 (i.e. TX download) is asynchronous and proceeds as follows:

1. HOST asserts TX Request line low to initiate transfer
2. Wait for FRPC2 to pull TX Accept low (i.e. request is accepted)
3. Set data lines to output and place LS nibble on the data lines
4. Negate TX Request (set to 1) to tell FRPC2 that data is present.
5. Wait for FRPC2 to negate TX Accept (i.e. data has been accepted)

Repeat steps 1-5 with MS nibble.

figure 7: TX download timing diagram

Notes:

• The data bus must not be set to output until step 3. i.e. after the FRPC2 has accepted the request. The bus may be left as an output until the entire packet has been transferred to the FRPC2, it should then be set back to input (default state).
• The FRPC2'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 FRPC2 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 FRPC2 will respond to the TX Request as normal, i.e. the TX Accept from the FRPC2 will be delayed until the incoming packet has finished. If a valid packet is received this must be uploaded to the Host before the FRPC2 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 FRPC2 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 FRPC2 to the HOST under interrupt control.
• See Appendix B and C. for example FRPC2 driver subroutines.

2.2.2 READ A BYTE FROM THE FRPC2

The sequence for a byte transfer from the FRPC2 to the HOST (i.e. RX upload) is asynchronous and proceeds as follows :-

1. FRPC2 will assert RX Request line low to initiate transfer
2. Host pulls RX Accept low (i.e. request is accepted by the host)
3. FRPC2 will turn on it's bus drivers, place LS nibble onto data lines and negate RX Request (set to 1)
4. 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

Notes:

• The FRPC2 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 FRPC2 driver subroutines.

2.3 HOST<>FRPC2 PACKET FORMAT

2.3.1 THE CONTROL BYTE

The first byte of a FRPC2 <> 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.3.2 SENDING AND RECEIVING DATA PACKETS

Data packets are sent to / received from remote FRPC2's. They begin with a control byte with bit 7 cleared and may be of variable length and contain up to 60 bytes of user determined data.

figure 9: Control byte for data packet

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 FRPC2 performs it's own error checks)
Routing information ( for repeaters)
Link control codes (connect/disconnect/ACK/NAK etc.)
Data field

2.3.3 FRPC2 MEMORY ACCESS

The FRPC2'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: FRPC2 memory access

FRPC2 Memory READS:

Host issues just the control byte, with bit 6 (W/R) cleared, bit 7 (PT) set and the memory address. The FRPC2 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.

FRPC2 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 FRPC2 does not give a response to memory writes.

figure 11: Control byte for memory access

Notes: Memory writes to locations 01 to 3F, write to the non-volatile EEPROM in the FRPC2. The EEPROM has a limit of 100,000 write cycles therefor it's use must be restricted to infrequently changed data. The FRPC2 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).

3.0 FRPC2'S SWITCHES

SWITCHES is memory location 00 in RAM, it contains 8 flags which are used to determine the FRPC2's operation. On FRPC2 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

3.1 PS0 & PS1 - POWER SAVING

The FRPC2 has 4 levels of power saving selected by PS0 & PS1 in SWITCHES. Power saving is achieved by shutting down the Transceiver and the FRPC2 for a period of time (OFF-TIME) when the FRPC2 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 FRPC2 will still respond immediately to a Host TX Request but cannot receive radio signals. After the programmed OFF-TIME the FRPC2 will wake itself up, turn the receiver on and listen for valid preamble. ON time = PWR->RX (EEPROM address 05) + 2.5ms = 3.3ms (using FRPC2 Default values) If preamble is found the FRPC2 will stay ON and decode the packet, if not the FRPC2 will shut down for another OFF time period.

Also see - WAKE-UP (address 02 of EEPROM) and paragraph 2.2.2.

* Sleeptime programmable in EEPROM address 03 H.

The supply current's quoted above are typical for a BiM2 + FRPC2 using the EEPROM default values.

Limitation of liability

The information furnished by Radiometrix Ltd is believed to be accurate and reliable. Radiometrix Ltd reserves the right to make changes or improvements in the design, specification or manufacture of its subassembly products without notice. Radiometrix Ltd does not assume any liability arising from the application or use of any product or circuit described herein, nor for any infringements of patents or other rights of third parties which may result from the use of its products. This data sheet neither states nor implies warranty of any kind, including fitness for any particular application. These radio devices may be subject to radio interference and may not function as intended if interference is present. We do NOT recommend their use for life critical applications.
The Intrastat commodity code for all our modules is: 8542 6000.

R&TTE Directive

After 7 April 2001 the manufacturer can only place finished product on the market under the provisions of the R&TTE Directive. Equipment within the scope of the R&TTE Directive may demonstrate compliance to the essential requirements specified in Article 3 of the Directive, as appropriate to the particular equipment.
Further details are available on The Office of Communications (Ofcom) web site:
Licensing policy manual