WARP Project Forums - Wireless Open-Access Research Platform

sbarra wrote:

1 - I assume that the system I want to build cannot be done with WARPLab. Am I right?

From the sound of it, the stock unmodified WARPLab Reference Design probably isn't a good fit for the project. However, we always intend for projects to be able to modify the WARPLab hardware project if they need to. When you were using WARPLab to tune to different channels, that was all happening in a MATLAB script, right? You could push that behavior down to the C running on the board. For example, when the Rx buffer starts, C code could tune to a new frequency every few microseconds. Then you could retrieve the large buffer at the end and have the entire "scan" present in it. I imagine that would be a lot faster than having MATLAB in the loop.

sbarra wrote:

I was thinking about trying with the 802.11 ref design and use the wlan_mac_get_status() function.

I think you could do something with this, but it would require some pretty deep modifications to the C side. I can't think of everything that would need to be changed, but at a high level something like this could work:

1) Use NOMAC for CPU_LOW and disable both the PHY receivers

2) Set the DIFS with to N microseconds. This will ensure that a spike of energy will hold WLAN_MAC_STATUS_MASK_CCA_BUSY high for a N microseconds.

3) In the main() loop of NOMAC, read the WLAN_MAC_STATUS_MASK_CCA_BUSY once every N microseconds and report the value to CPU_HIGH via a new IPC message. Also include the current channel and the current timestamp. After reading these values, tune the radio to a new channel.

4) In CPU_HIGH, form a new log entry type for the CCA status log it to DRAM.

5) Using the wlan_exp Python framework, retrieve the log of CCA bit statuses and do your processing there.

sbarra wrote:

2 - Would it be possible to have multiple RF interfaces (on the same WARP) tuned to different channels (e.g., #36 and #40) and check its occupancy right at the same time?

If you are going the route of modifying WARPLab, yes. This feature is already there. Up to 4 RF interfaces can receive at once and they need not be on the same channel. For the 802.11 design modification, this isn't really possible without customizing the hardware design. The CCA bit is tied to a single interface.

sbarra wrote:

3 - Then, I guess I could try to synchronize other WARPs with RFs tuned to other channels and aggregate the whole snapshot. Is that feasible?

Same story here -- synchronizing the Rx events of many WARP boards is easy with WARPLab. That design already supports externally triggering multiple Rx nodes. This is less feasible for the 802.11 design modification.



All in all, I personally would give modifying the WARPLab design a shot before going down the road of modifying the 802.11 design the way I described.