<texit>\part{Future thoughts}</texit>

STFA

The STFA being a complex module and having evolved over two years, it would be a good idea to re-write it once completely. Here are some ideas on what should be mended and what thoughts should go into a re-structuration of the STFA.

Antenna

The antenna should be a module on its own with an output for the received samples and an input for the sent samples. These two ports should then be connected to the stfa. Advantages:

  • Configuration If for a given antenna we have special parameters, we can define them as easily as in any module
  • Clarification It gives a more constant concept in the software-radio
  • Universality For the moment the software-radio is very TDD-based with the STFA. If the antenna is really an independant module, it would be much more easy to implement other stuff

Chains

The way chains are linked to the STFA is very kludgy. While things are quite OK for RX-chains, it is really not optimal for TX-chains. Consider figure <ref>fig:stfa_tx_kludge</ref> where on the left-hand side you see the actual implementation. The user has to define which modules have to be called at which moment with two function-calls like:

swr_stfa_notice_sdb( stfa, 2, source1 );
swr_stfa_notice_sdb( stfa, 5, source2 );

Actual and proposed design of the TX-chain alertion
Actual and proposed design of the TX-chain alertion
(stfa_tx_kludge.ps)

In order to simplify things and thus taking away possible sources of error, it would be much better, if the STFA would consider the chains on its own, like show in the right-hand part of the figure.

For the TX1-chain, not much would change, only the two above-mentioned function-calls could be left out, because the STFA would call the RRC-module with a message like SUBS_MSG_PRODUCE_DATA. The RRC-module in turn would call the Map-module, which would call the Source1-module. Then, the Source1-module produces some data, and everything is like before.

For the TX2-chain, the distribution of the time of calculation would even be more uniform. If you consider the left-hand side, all the calculations for all the modules is done during slot 3 and 4, even though about half of the calculations are not needed before slot 7! Now, if the STFA would be smart enough to not only call the modules with a message SUBS_MSG_PRODUCE_DATA, but also tag the modules passed this way, only the necessary calculations would be carried out.

So, at the beginning of slot 3, the RRC would be notified with SUBS_MSG_PRODUCE_DATA and tagged active. Then the Map-, Split-, and finally the Source2-module would be notified. Once the Source2-module produced its data, the inverse way will be taken. An important point is to note that the Split-module produces both branches of data, but that only the left branch is followed.

Then, at the beginning of slot 5 1), the RRC of slot 7 would be notified, which would notify the Map-module, which would see that it has some data to process, and stop the notification of further modules. It then processes the data, hands it to the RRC, which processes its data, too, and hands it to the STFA.

Implementation

In fact, it is not really necessary to tag the data. Each module could just

  • Check inputs for whether all necessary inputs are filled with data
  • Notify upper modules if this is not the case
  • Process the data

The idea is that the notification of the upper modules happens synchronously, that is, the notification only returns once it has been carried out. The module can then assume that the data is available.

There are a lot of special cases, just a few here:

  • Multiple inputs of a module, where one or more may be inactive, that is, not connected
  • Loops for creating incremental coding

Visualize

Reading through the reference-part of the visualize-tool, one gets the impression that this tool has been glued together (like oh so many others) more randomly than anything else. Well, unfortunatly, this is true. One project would be to re-design the classes of this tool, and then re-write a more nice version of it.

The steps to do so could include the following:

  • Understand and look at the existing code. Using a tool like Umbrello, one can get quite fast a basic understanding of which classes use which classes.
  • Design a new class-model, where each class has a well-designed purpose.
  • Rewrite the whole tool, doing mostly copy-paste constructs. 2)
1) Coincidence: this is the same slot as the result of the left branch
2) Important: go step-by-step with easy testable parts

Last modified:: %2007/%02/%20 %10:%Feb