Sora Interface Design

Sora communicates with the PCIe bus for shortest latency times, and takes binary packets, modulates them into digital signal samples that represent electronic waves, and sends them out via an output interface to one of two possible RF(radio frequency) front-ends, which then convert from a digital wave to an analog wave, amplify, and output via an antenna.

This process is further explained in the documentation included with the Sora SDK.

These two RF front-ends are:

In order to interface with Sora, each of these RF front-ends will need an adapter[1], available from Microsoft (with the case of USRP, this adapter will be available at the end of May).

Sora's FRL (the connection to the RF front-end) currently only supports a single-slot (as of release 1.0). Multiple channels are planned in future firmwares.[2]

User-mode, Kernel-mode, and You

Sora divvies up the "software" portion of software-developed radio into two sections: drivers and executables. Drivers are "applications" that have to be written and compiled in checked, or kernel-mode; that is, you must use the checked compiler included in the Windows WDK required for Sora development to build these portions of Sora.
Executables are applications that are written and compiled in free, or user-mode, and the free-build compiler or even Visual Studio can develop applications in this sense.

SoftWifi IEEE 802.11b is an excellent example of how this distinction occurs.

All functionality is programmed into a driver, i.e. all forms of modulation (QPSK, BPSK, QAM, CCK, and eventually OFDM). None of it is assigned values, yet, this simply serves to define how such modulation should be handled. This can all be considered as part of the physical layer of the OSI model. The link-layer and MAC addressing also is coded in, but not assigned values yet. More specifically, if you were to load this driver into Windows, there would be no MAC address associated with it yet.

Values can be programmed in through a user-mode executable, often command-line. Theoretically, in the future, this could be expanded to C++ or MATLAB based programming, but for now, C is advised. This is how concepts such as Transmission Rates are entered into a Sora setup.

It should be noted that these communications take place through "handles"; and are HEAVILY reliant on the NDIS framework featured in the WDK; this makes sense given the emphasis on packet/frame transmission that Sora features. If this were simple radio waves and not actual data, there would be no need for NDIS.

Sora Links
Wiki Pages References