Some notes about RF emulation

Mike Rowehl <[email protected]> Sat, 21 Jun 2003 01:00:52 -0700

Newsgroups	gmane.org.handasarabia.nour
Message-ID	<[email protected]>

Attached are some notes about how I'm thinking about doing the emulation of the
RF medium itself.  Since it's really just a simple message passing mechanism
with a number of different slots, the design is very simple.

The VHCI emulation daemon in BlueZ uses some socket reader/writer covers that
I think come from glib, and they make socket based delimited message passing
look really easy.

I'm probably going to do one more small doc with details about mapping the NOUR
registers to operation on this RF emulation daemon, and unless there are major
objections I'll start trying to divide up the work to begin implementing.

The more I look at this idea of emulating the module and airwaves, the more I 
like it.  With the right hookups for the microcontroller emulation it could be
a really fantastic debugging and development tool.

                                                    Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: nour-unsubscribe-bZJqt4gKw0dwc45b+y0WwMLKnirKmNT7@public.gmane.org
For additional commands, e-mail: [email protected]
Handasa Arabia, http://www.handasarabia.org

rf_link_06_21_2003.txt (text/plain, 3 KB)

Description of the RF emulation daemon
--------------------------------------

The RF daemon component of the NOUR emulation system communicates with the
individual module components using a socket interface (unix domain sockets, 
tcp/ip sockets, it really doesn't matter too much).  There four basic messages
passed between the RF daemon and the emulated modules:

TICK  - message sent by the daemon, indicates a tick of the BT bit clock
TUNE  - message send by modules to the daemon, indicating the state the module
        is putting it's radio into
WRITE - sent by the modules to the daemon, write a bit into the currently tuned
        channel
READ  - send by the daemon to the modules, receive a bit from the air


Connection is done by attaching to the socket provided by the daemon and
waiting for the first tick message to be sent.  A basic round of interaction
between RF daemon and NOUR devices looks like this:

1. The daemon sends a TICK message to each of the devices.

2. All devices respond with a TUNE message.  This message tells if the device
   is going to be listening to a channel, driving a channel, or if it's radio 
   will be shut down for the next bit.  Unless the radio is shut down, the
   message also contains the channel number.  If the device is going to have
   it's radio shut down for the next bit it doesn't participate in the next two
   stages.

3. All modules currently writing to a channel send a WRITE message to the
   daemon.  The message contains the bit image written.

4. All modules currently reading from a channel are sent a READ message by the
   daemon.  The READ message contains the bit image detected on the channel.


After having written the final READ message the daemon starts the next bit with
another TICK message to each of the devices.


Binary structure of messages
----------------------------

All messages are 3 bytes in length.  The encoding is very wastefull, but it 
should make processing a lot simpler.  And it leaves room for additional 
capabilities should they be needed.  The first byte of the message determines
the operation type:

-----------------
TICK = 0

The extra two bytes in the TICK message store a tick number, which is just a
cyclicical counter.  It has no use except for error checking within the 
implementation, and should have no bearing on the operation of the devices in
the absence of programming errors.

-----------------
TUNE = 1

The second byte of the TUNE message gives the state of the device radio:
0x00 = writing to the channel
0x01 = reading from the channel
0xFF = radio is powered down
If the device isn't powered down, the third byte contains the channel number.

-----------------
WRITE = 2

Bit 0 of the second byte contains the bit image being written.  The third byte
is unused at present, but must be present in the message and set to 0x00.

-----------------
READ = 3

Bit 0 of the second byte contains the bit image read.  The third byte is
unused, but must be present and set to 0x00.
-----------------