Changes made to the Baseband implementation

Control

For the Link Manager to work it has to be able to set the state of the Baseband (Inquiry, Standby and Page) which has been implemented by adding a port for this specific purpose. An Inquiry will expire after a timeout value or when the indicated number of slaves has responded. If in the Page state, we will look through the list of slaves that has formerly responded to an inquiry, but even if the slave is not found we allow the address to be paged in order to allow for small networks in which all devices are known and no inquiry is necessary.

The code previously ignored information about the Active Member address, and instead had an extra piece of information (DestinationBDADDR) in each packet header to hack around this problem. I have corrected the use of Active Member addresses and thus added an extra port to let the higher levels know of the AM address to use for a given BD address. There still needs to be cleaned up in one place - namely in the Composer where null packets are sent without information about the AM address of the receiver - to solve this problem the internal workings of the Baseband would have to be changed (since the Composer would need to know of the BD to AM address pairing) which I did not want to start doing as the problem is not that big (only happens during setup and does not increase the amount of traffic considerably).

Five slot packets were incorrectly handled (seems there was a bit of copying and pasting from the one slot packet handling code that went wrong), which meant that the information in them would be cropped. This has been fixed.

Upon initialisation the Baseband informs the Link Manager of it's Bluetooth Device Address.

Disconnection wasn't really possible when there was no use of the Active Member address (as disconnection simply means to give up one's status as an active member). This now makes sense.

Transmit and Receive

The DM1 and DM5 packets have been added. These contain less data than the corresponding DH1 and DH5 packets as the data is FEC2/3 encoded. As I did not have time to get into the coding and encoding or their implementation in the Baseband I have made support for these by copying bits and pieces from the DH packet code and other packets that uses the encoding. As the data comes through unmodified I assume this to work, but as I have not have a single look at the specification for this I cannot guarantee it (sorry!).