Using Bluetooth as Beamcar Interface

"Never are so many lies told as before an election, during a war and after a hunt!" (Otto von Bismarck, Prussian chancellor)

Up to recently, the intended beamcar communications interface was by way of wave guides. This is still a feasible technology, but lately, the Bluetooth standard has surfaced as a very interesting option. As will be shown on this webpage, it is ideally suited to FLYWAYs needs; it is a standard that is specifically designed for volatile communication between moving units. A rather similar standard is VHF Digital Link Mode 4. Whether this standard would be more suitable for our purpose has not been properly investigated yet. This webpage will only deal with Bluetooth.		The work with development of Bluetooth was started by Ericsson Mobile Communication in 1994. It is now (finally) entering the market in form of headsets, computer keyboards and such. For a brief technical description of Bluetooth itself, see the Bluetooth page. Advantages of using Bluetooth Placement of stationary antennas The interface between system nodes and beamcars How it will function Radio interference About Bluetooth antennas

1. Advantages of using Bluetooth

What do we need? he beamcars whiz by at high speed. They need to communicate something fast, to a stationary transceiver. Or they need to be reached with control information from the node computer. Or the beamcars are stationary somewhere. They need to be located for exchange of information. For all of these tasks, the Bluetooth technology would be eminently suitable. Bluetooth is expert on: having some units quickly locating other units dynamically establish communication sessions quickly exchange short bursts of information between moving units handling point-to-multipoint communication handling noisy environments, if needed.

It so happens that these capabilities fulfill all requirements that we have on a reliable and well-functioning node-to-beamcar communication. Actually, 2 networks are involved in this communication. There is the communication between the node computer and all the stationary units that is under its control. And there is the actual Bluetooth-based RF-communication between these stationary units and the beamcars. We will look at all aspects of this setup in turn. To tell the truth; Bluetooth is not good at handling long sequences of data transfer, because of its timeslot-oriented nature. But, as stated elsewhere, it is ideally suited for short messages. So, the communication described on this page will only be used for: controlling and running the network, with emphasis on vehicle control provide traffic-related information to passengers in the beamcars.

Is Bluetooth fast enough? What we are actually asking is: Can Bluetooth's stationary unit connect and disconnect to a passing vehicle fast enough? Can Bluetooth's stationary and mobile units exchange their information fast enough, while the vehicle is within range? Can Bluetooth's stationary and mobile units exchange their information while the information is still relevant? With a range of 100 meters, the travelling beamcar will be within range of the same stationary unit for 200 meters of travelling. Assuming a speed of 100 km/hour on a straight beam segment, which corresponds to 100 000/3600 = 28 m/sec., the 2 units would have 200/28 = (about) 7 seconds to exchange information, and this is plenty of time for Bluetooth. At curves and station areas, the antennas would be closer together, but the beamcar speed would also be considerably slower. A hand-over procedure would of course have to be implemented as the car approaches the next antenna unit, which would have to coincide with the car changing to a new piconet. A rather complicated procedure. But for Bluetooth, there would be plenty of time for this.

2. Placement of Stationary Antennas

Restrictions luetooth's stationary antenna-units could in principle be placed willy-nilly inside the beam. Since the technology assumes that all units could be mobile, no unit is required to even be stationary. In reality, a traffic system such as FlyWay would have to contend with the following 3 restrictions: Range: The range is nominally 10 meters, but could be increased. For beamtraffic-purposes it would be suitable with a range of about 100 meters, but this would then need to be adhered to; i.e. we would need at least 1 stationary unit every 100 meters (shown by 1 in the illustration at right). Capacity: Since each piconet cannot handle more than 8 units, and the stationary unit will have to be the Master in each piconet (and the other 7 (mobile) units would be slaves, as described below), there would have to be a sufficient number of stationary units in station areas and parking areas to handle the maximum number of beamcars that could be there at any one time. For instance, if a buffering beam at a station area has room for 39 vehicles, this beam segment would need at least 6 antenna units to enable the node computer to communicate with all these cars at the same time, since 39/7 < 6. This is shown by 2 in the illustration at right. Line-of-sight: The Bluetooth wavelenghts do not bend with the beams. Thus, there has to be line-of-sight coverage in all sections of the beams, meaning extra antennas wherever the beam bends (shown by 3 in the illustration at right).

Figure 2:1

Logical configuration et us first look att the logical configuration of the stationary units in the FlyWay beams. A node is responsible for handling all traffic in an alloted area. At its simplest, this area could just constitute 2 beams that join into one, and nothing more. At the other extreme, it could be quite a number of weaving and diverging nodes, together with station areas, and buffering beams for waiting beamcars. Thus, a node computer could have any number of bus connections, each of which could have any number of antenna units. Figure 2:2. shows an example with 4 buscables, and 6 transceiver units on each cable. They would have to be addressable units, the addresses following a logical scheme as illustrated by the red figures. The reason for this is that all information from the node need not always go to all the antennas; this just creates unnecessary cluttering of useless information. This will be explained in detail further down on this page.

Figure 2:2

Placing the cables in the beams ow, look at figure 2:4. It illustrates how 2 node computers distribute their buscables in the beamsegments in their allotted areas (separated by the grey line). The cables enter the beams by being placed inside any suitable pole or beam support (figure 2:3.). Each bus cable then travels along its assigned beamsegment, up to the last antenna unit on that segment. Further down the road, the next antenna might belong to another node, and would thus be connected to that node by another cable. This is indicated at C in the figure. The addressable antenna units are then placed along these cables so as to fulfill the 3 conditions stated above. Each cable is logically a network, so the node computer also functions as a kind of router. But not quite; it has to make some address conversions when conveying messages between the WAN and its local networks. This is explained below. Figure 2:3

Figure 2:4

3. The Interface between System nodes and Beamcars

How the node computer communicates with its attached units. uch because of the structure of the beam system, the networks that connects to the antenna units function as a bus network. The node with the simplest configuration would only have 2 such networks. But there could be any number of these local networks, depending on the size and complexity of the nodeīs assigned area, as shown in figure 2:4 above. Looking at figure 2:2 above, you can see that the node functions as a kind of router as well as an independent computer. We can identify 6 communication modes: communicating with the central computers communicating with other nodes broadcast message to all its stationary units, trying to locate a particular beamcar or general message to all beamcars communicating over a particular stationary unit, to one or more beamcars as router; conveying messages between central computers or other nodes on the one hand, and one or all stationary units on the other hand. This is a rather complicated setup, which is probably best solved by using tunneling and TCP/IP. These are protocols that are widely used and very dependable, and therefore need not be further developed or tested for the beam traffic system. The idea, then, is for nodes and central computers to use regular IP-addresses on the WAN, using the TCP/IP protocol. For messages arriving on the WAN, that are destined to one or more beamcars, the node has to send them on to its local bus networks; either as broadcasts to all stationary units on all its networks, as broadcasts to all stationary units on one network, to some of the units or just to one particular unit.

In cases 3 & 4, the destination address of the data packets have to be converted to that of the stationary units in question. Finally, arriving at the unit, the message and the destination address have to be converted once again, to that which applies to the piconet in question. This would thus be a 3-step process, as illustrated in figure 3:1 below. The example below shows: the message arrives over the WAN from another node computer, using TCP/IP the message, after having its destination address altered to 2:3, is transferred to the stationary unit with that address, using TCP/IP the message, after having its destination address altered to that of the beamcar, is transferred to the beamcar, using the Bluetooth protocol. Figure 3:1

4. How it will function

The ACL mode Figure 4:1; General payload packet format As might be recalled: SCO = Synchronous Connection-Oriented link ACL = Asynchronous Connection-Less link. According to the Bluetooth specification, in the slots not reserved for SCO links, the master can exchange packets with any slave on a per-slot basis. The ACL link provides a packet-switched connection between the master and all active slaves participating in the piconet. Both asynchronous and isochronous services are supported. Between a master and a slave only a single ACL link can exist. For most ACL packets, packet retransmission is applied to assure data integrity. A slave is permitted to return an ACL packet in the slave-to-master slot if and only if it has been addressed in the preceding master-to-slave slot. If the slave fails to decode the slave address in the packet header, it is not allowed to transmit. ACL packets not addressed to a specific slave are considered as broadcast packets and are read by every slave. If there is no data to be sent on the ACL link and no polling is required, no transmission shall take place. It is thus clear that ACL is the mode of communication to be used between beamcars and stationary units in the beam.

The Access Code Types These will be of crucial importance to the beam network. Without them, the Bluetooth interface could not function at all. Each packet starts with an access code. If a packet header follows, the access code is 72 bits long, otherwise the access code is 68 bits long. This access code is used for synchronization, DC offset compensation and identification. The access code identifies all packets exchanged on the channel of the piconet. All packets sent in the same piconet are preceded by the same channel access code. In the receiver of the Bluetooth unit, a sliding correlator correlates against the access code and triggers when a threshold is exceeded. This trigger signal is used to determine the receive timing. The access code is also used in paging and inquiry procedures. In this case, the access code itself is used as a signalling message and neither a header nor a payload is present. Code type LAP Code length Short for: CAC Master 72 Channel Access Code DAC Paged unit 68-72 Device Access Code GIAC Reserved 68-72 General Inquiry Access Code DIAC Dedicated 68-72 Dedicated Inquiry Access Code The respective access code types are used for a Bluetooth unit in different operating modes. The channel access code identifies a piconet. This code is included in all packets exchanged on the piconet channel. The device access code is used for special signalling procedures, e.g. paging and response to paging. For the inquiry access code there are two variations. A general inquiry access code (GIAC) is common to all devices. The GIAC can be used to discover which other Bluetooth units are in range. The dedicated inquiry access code (DIAC) is common for a dedicated group of Bluetooth units that share a common characteristic. The DIAC can be used to discover only these dedicated Bluetooth units in range.

General functionality fter the general descriptions above, we should now be ready to look at the details. This is important, since this is a new application of the Bluetooth technology that, as far as we know, has not been seriously considered before. First of all, if both of SwedeTracks Bluetooth-proposals are implemented, each beamcar will carry 2 Bluetooth-units; one mounted on the cabin, for passenger interface, and the other mounted on the propulsion vehicle inside the beam. This page only deals with this last one, on the propulsion vehicle. Figure 4:2 At the outset, an idle beamcar has its Bluetooth-unit in standby-mode, ready to answer any call. The node-connected Bluetooth-units will likewise be in standby-mode. When a stationary unit calls a beamcar, it will be in the role of master. A stationary unit can keep up active session with up to 7 beamcars at the same time. Entering a piconet: When a mobile (i.e. beamcar) unit calls a node, it will initially be master. But as soon as contact has been achieved with a stationary and idle unit, they will switch roles, the stationary unit becoming master. If the stationary unit that answers the call isnīt idle, the mobile unit will, after the initial contact, enter the piconet that is already in existence. A stationary unit within range that receives a call from a mobile unit, but already has its quota of 7 slaves filled, will not answer that call. Nor will it comply immediately with a request from the node to contact a mobile unit, or send an inquiry or page scan. If more than one stationary unit receives the same call, they will all answer, whereupon the mobile unit will pick one of them, according to some criteria, and establish contact. The best such criteria would be if the mobile unit could go with the strongest answering signal. Figure 4:3 A mobile unit that seeks contact, will send an "Inquiry Message", which amounts to asking "Is anybody listening?" This Inquiry Message could be qualified by a "dedicated inquiry access code" (DIAC), which has an address space of 68-72 bits. This means that every Bluetooth unit on a reasonably big network could have its own DIAC, and a beamcar seeking contact with a particular node, could qualify its inquiry by sending what amounts to "Is node 345 listening?" Thus, being within range of more than one node, the beamcar could establish direct contact with the "right" node computer in this manner. The stationary units will of course know which DIAC belongs to them. An active car should in principle always maintain an active piconet-presence. Thus, a stationary unit should only park a mobile unit when it is ordered to do so by the node computer, as stated above. The mobile unit could, according to relevant critera, object to this parking and re-enter the piconet. If so, it would hav to justify this decision to the node computer.

However, an active carīs mobile unit should be able to temporarily and voluntarily go into "park" mode while the vehicle is loading/unloading at a berth, or waiting in a queue. The purpose would be to release its active piconet address to a car passing thru, if the stationary unit (i.e. the Master of the piconet) indicates that it is out of addresses. See below under "Specific Situations". Thus, the mobile unit should be able to park itself, and this would only happen in any of the following circumstances: when the car has no more assignments, and has found a spot where it can go into idle mode when the car is faulty, and removes itself from active duty when the car is buffered or waiting at a stop for travellers when it is being loaded or used on the ground for some duration (at least 5 minutes) when it has been booked and is waiting for the travellers when it is running on a schedule and waiting for its departure time. A passenger car often knows "better" than the node what goes on in the beamcarīs vicinity. For instance, a beamcar that has just been made idle by the system, could at that moment be occupied by a traveler, who gains access to the car through its passenger interface (like hitching a free taxicab in the street). The unit of an active car will start scanning for another stationary unit, as soon as it has become member of a piconet. This is explained in detail in connection with figure 4:6 at the end of this page. All datablocks transmitted contain a "channel access code" (CAC). This code identifies a piconet, and prevents mixup in communications between piconets that are in close vicinity to each other. All datablocks transmitted from a beamcar contain a "device access code" (DAC), which is used for special signalling procedures, e.g., paging and response to paging. The beamcars will use this code to announce their identity to the node. The addressing space of DAC is sufficiently large (68 to 72 bits) to allow all Bluetooth units in a beam network of any size to have their own DAC (just 34 bits corresponds to more than 16 billion addresses!). Paging messages sent from stationary units, destined for a certain beamcar, will contain a DAC with the identity of the unit carried by that car, and thus only the right beamcar will answer. Once connection has been established, the mobile unit (i.e. the beamcar) will be assigned a piconet-address, and that address will be used for the rest of the session. Such a session ends when a mobile unit is "parked" or when it leaves the piconet by moving out of its range. Stationary units will never have reason to send Inquiry messages. They will either send broadcast messages, destined for all units in their piconets, or page for a certain beamcarīs unit (using the DAC of the mobile unit), our category of beamcars. Stationary units will thus only send broadcasts or Paging messages. Paging messages sent from stationary units, destined for a certain beamcar, will be sent from one or more stationary units. The decision as to which units that will be used for this transmission will be based on the information about the whereabouts of the beamcar which is stored in the node computer. If the exact beamcar position is known, only the one stationary unit that is nearest will be activated, provided it has free capacity. Is the exact position not known, the node will direct some or all of its units to send the same Inquiry Message. As default, a node will always know the approximate position of all beamcars within its area. This information is stored in the node computerīs database, and is constantly being updated by way of log reports from the beamcarsī mobile units. These reports are then regularly bundled together by the node, and forwarded over the WAN to the centrally located computer for logging and statistics. Leaving a piconet: Considering that beamcars will often move quite fast, it might (?) be a common occurence that communications sessions will be interrupted, because the car moves out of range. An active beamcar, which is being used (as opposed to an idle beamcar) will always have to be an active member of a piconet. The moment the carīs Bluetooth unit senses that it receives no signals from its piconet master, it will have to emit inquiry messages to try and find a new stationary unit. Once such a contact has been made, the car will immediately announce its identity. In this way, the nodes will keep track of all active cars (as stated above), and the positions of idle cars will be known by the node responsible; this data will be stored by the node the moment the car leaves active service. Routines for leaving a piconet: From the foregoing point, it can be noted that the normal manner for a mobile unit to leave a piconet is not an orderly "signing off", but rather that the mobile unit moves out of range, and suddenly does not answer the master. The FLYWAY method of handling this would have to be for the master to, failing to receive a response from the mobile unit in its assigned timeslot, make only one attempt to re-establish contact. If this too is not answered, the active Bluetooth address of this unit should be considered free, and available for another mobile unit. This is illustrated in figure 4:4 below. The master unitīs contact attempt with slave nr. 13 at point 1 is just met with silence. When the next contact opportunity comes around, at point 2, the master tries again. If there is still no answer, the master will assume that this slave has left the piconet, and the address will be made available to another unit, whenever such a unit tries to establish contact.

The Bluetooth standard has this to say about lost connections: LINK SUPERVISION connection may break down due to various reasons, such as a device moving out of range or a power failure condition. Since this may happen without any prior warning, it is important to monitor the link on both the master and the slave side to avoid possible collisions when the AM_ADDR is reassigned to another slave. To be able to supervise link loss, both the master and the slave use link super-vision timers, T supervision. Upon reception of a packet that passes the HEC check and has the correct AM_ADDR, the timer is reset.

If at any time in connection state, the timer reaches the "supervisionTO" value, the connection is reset. The same timeout value is used for both SCO and ACL connections. This supervision timeout period, supervisionTO, is negotiated at the LM level. Its value is chosen so that the supervision timeout will be longer than hold and sniff periods. Link supervision of a parked slave will be done by unparking and re-parking the slave. In addition, each Bluetooth link has a timer that is used for link supervision. This timer is used to detect link loss caused by devices moving out of range, a device’s power-down, or other similar failure cases. An LMP procedure is used to set the value of the supervision timeout.

A general safety concern is that if information exchanges only occur when there is a change in vehicle trajectories or leader/follower relationships, then a lack of communication can be assumed to imply no change, even though it might in fact represent a failed communications link. The use of periodic beacons can help to establish that the vehicle is still operational, and this is part of the Bluetooth protocol. However, if a vehicle with a broken transmitter comes into range, it would not be detected in the first place. For these reasons, additional systems are almost certainly needed to verify vehicle detection and operation. These need not be part of the system infrastructure, but, in the case of FlyWay, this is where the obstacle detection system is needed.

Specific situations Activating an idle car: A directive will come, most likely from the central booking computer, to the node, to activate a certain car, and send it to a specified address. All nodes inform the central computers of the whereabouts of idle cars as soon as these cars leave duty. In a network such as FlyWay, vehicles that go off duty for a period of time (such as for the night) do not necessarily have to be brought to a garage. They can be left anywhere where they are not in the way, but the traffic control system has to know where they are. Consequently, the booking computer ought to know to which node the request should be sent. The node then relays this request to a suitable stationary unit, which has to activate the car. The Bluetooth specification says, regarding this: "A slave in park mode can be identified by its BD_ADDR or by a dedicated parked member address (PM_ADDR). This latter address is a 8-bit member address that separates the parked slaves. The PM_ADDR is only valid as long as the slave is parked. When the slave is activated, it is assigned an AM_ADDR but loses the PM_ADDR. The PM_ADDR is assigned to the slave the moment it is parked. The all-zero PM_ADDR is reserved for parked slaves that only use their BD_ADDR to be unparked." Thus, this particular stationary unit knows, as master, about its parked units, and can use this PM_ADDR instead of sending an Inquiry message. Giving a new assignment to an active car: This directive will come, (most likely from the central booking computer), to the node in which area the car is at the moment. The node knows where the car is, since the node computerīs data bank is constantly being updated of the activities of all its piconets. Thus, the node will just relay the request to the appropriate stationary unit. A trickier situation would arise if the nodes did not constantly informed the central computers of the movement on the net. In that case, a request to locate the car would have to be broadcasts to all the nodes. All nodes would search their data banks, and the node in question would answer. Following this, the actual request would be addressed to that node. This extra round of information exchange takes time, and time is crucial, considering that active cars are constantly moving from one piconet to another. If they have to be reached for conveying some kind of information,they might have to be "chased" from one piconet to another, as they travel along, which might create considerable overhead traffic on the WAN.

For this reason, it is recommended that nodes constantly send information of the movement of cars to the central computers. These mesages would be second class; if the network is congested, more important data traffic would have precedence. Activating any idle car: When a traveler requests a car, most likely, any car might do. Or, a car of a certain category is requested. In the FLYWAY system, the car category (i.e. whether it seats 4 or 6 people, or whatever) is part of its identity, and thus could be found with an Inquiry message. Since each node knows where its idle cars are, it can direct the request to the right stationary unit. Handling interrupted sessions: It is conceivable that a car on the move establishes a new piconet connection, but does not find the time to switch to slave mode and deliver its message before the connection is broken, for some reason or another. Or, the stationary unit cannot take the call, because it already has sessions with 7 slave units. Or, the stationary unit could be malfunctioning. Calculations show that this is very unlikely to happen, but should it happen it could be potentially dangerous. A beamcar could for instance approach a weaving node without the node computer knowing about it. This is cause enough for the carīs mobile unit to command the car to stop, until connection with a stationary unit could once again be established. Thus, beamcars in the FLYWAY system will not move whenever they donīt have an established piconet connection. Preventing congestion and interrupted sessions: The best way to prevent this from happening would be to place more stationary units in the beams, closer together. The extra cost would be comparatively negligible, and there would be no negative effects from doing this. Bluetooth piconets placed closely together do not interfere with one another. A case in point would be if a queue of cars should come about, at a place where the stationary units might be 100 meters apart; they could not handle the ensuing extra load of slave units. As stationary antenna units are placed closer together, their transmission power should be reduced from the 100 meter range to a more suitable distance.

"Parking" active beamcars: The stationary unitsī capability of handling mobile units as slaves could be extended beyond 7 units, by temporarily "parking" units that are not communicating at the moment. Those parked units would give up their addresses, and each be assigned an individual BD_ADDR or, preferably, a PM_ADDR, thus freeing an active address to be temporarily used by another car. Thus, mobile units belonging to beamcars that are waiting at a station or loading/unloading freight or passengers, would momentarily be parked, and their Bluetooth address be "borrowed" by a car which is maybe whizzing by. If this system is used, the capacity has to be properly dimensioned. This means that the number of stationary units would have to be many enough so that unnecessary delays in the traffic do not ensue, because the beamcars are waiting to be assigned addresses. As stated above, there must be redundance in the number of stationary units, and this means that the parking of units would really be used only when their addresses are needed. It is suggested that the limit of parked units per piconet be kept low; not more than 4 or 5 units. The reason, of course, is that they should not have to wait an unduly long time to come back as active members of the piconet. See figure 4:5. Exchanging much information: The Bluetooth standard provides for datablock sizes of up to 5 timeslots, and this much data will rarely need to be exchanged with the beamcars. As stated elsewhere, much information needs to be exchanged, all the time, but the size of the information content in every such exchange is quite small; position, destination (to pick up someone), time to be there, passengerīs destination, speed directives from node (when the beamcar approaches a weaving point), malfunction announcements (by beamcar), travel info to passengers, information (from the system) about altered travel routes, travel log (from the car), position announcement (from the car); this sort of messages can be very brief.

Figure 4:5

Figure 4:6

Switching Piconets during Travel s noted elsewhere, there are 2 handover-proceedures that have to take place simultaneously, in order to ensure that a travelling beamcar stays connected at all times: The stationary computer has to track the beamcar, so it can foresee in advance which of its stationary units will next be communicating with the beamcar, and prepare to communicate by way of that unit. If the next stationary unit belongs to another stationary computer, that computer will have to be notified by the present computer, and brought up to date regarding the status of the beamcar in question. The beamcar has to constantly scan and establish connections with new stationary units. As soon as the travelling beamcarīs Bluetooth-unit has established contact with a stationary unit, it starts scanning for another stationary unit. Why? Well , the reason should be obvious if you look att figure 4:6 above.

The active beamcar needs constant contact with a node (or regional) computer, and since the beamcar is usually moving, it is only a matter of seconds before it moves out of range of the current stationary unit. Consider the illustration above figure 4:6 . The stationary units are, of course, inside the beam, although they are depicted here as being outside. The beamcar, entering from the left and communicating with stationary unit 3:1, rapidly approaches point C in the beam, where it will suddenly be out of touch with unit 3:1. Anticipating this, the carīs mobile unit scans for a the next unit, while still communicating with 3:1. In this example; at point A it gets a reply from unit 4:1, and will thus have time to switch to slave mode (provided that unit 4:1 is idle) and transfer its communication from unit 3:1 to unit 4:1, before the breakoff with 3:1 at point C. The mobile unit on the beamcar will thus have established a new piconet, where it will act as a slave before regular communication in this net commences.

The mobile unit will have to switch to slave mode, since only masters can take the initiative to create news piconets. The mobile unit will thus, for a transitory period, be slave in the piconet where unit 3:1 is Master, and Master in the newly established piconet where unit 4:1 is Master, whereupon the mobile unit and stationary unit 4:1 quickly change roles. It could be that unit 4:1 is available but active; i.e. it is already Master in a piconet, communicating with other mobile units. In this case, the beamcarīs unit will just join up, as a Slave. Now, it could also be that unit 4:1 has a full piconet, and cannot receive any more slaves. In such a case, the beamcar unit will continue to scan, until either unit 4:1 can receive the carīs unit or the car passes point B and comes within range of unit 4:2. In a well-dimensioned network, either of these 2 units will now have the capacity to answer the call. If they donīt, the car will lose communication with the stationary computers at point C. The next opportunity to re-establish contact with a stationary unit comes at point D, but this would, as stated, not be a good state of affairs, and would require a re-design of the disposition of stationary units.

5. Radio Interference

Figure 5:1; Interfering radio waves

s of this writing, no practical tests have been made as to how Bluetooth will behave in the FlyWay beams. But, generally speaking, radiowaves inside the beams that hit the walls will either be reflected or absorbed. To the extent that they will be reflected, they might thus interfere with the quality of reception, as illustrated in figure 5:1. Assuming the mobile antenna to be in receiving mode, it can handle simultaneous transmission from both A and B, because these transmissions will, practically all the time, be on different frequencies. Not so the reflected waves from a certain transmitter. We thus have an option here, to coat the internal walls of the beams with a material that will more or less absorb the waves. Still, assuming that we have interfering waves, not only from walls, ceiling and runway, but also from other propulsion vehicles that get in the way, what can we do? Well, we could design the antennas so that they direct the transmitted waves more along the beams instead of a uniform 360-degree radiation.

This would work both ways; both the transmission and the reception would be concentrated in certain directions, away from the walls. At least 3 general methods are possible: Mounting reflectors on the antennas. Using arrays of antennas, where antennas half a wavelength apart would extinguish each otherīs transmission in the direction of the array. Using more than 2 antennas in such an array, placed at various distances and angles relative to each other, one could get quite a complex radiation pattern. Using waveguides with slots, arranged in such a way that they will strengthen each otherīs carrier waves in certain directions.

Solution 2 might not work satisfactorily, since Bluetooth varies its frequencies, although this variation is only between 3 and 4 percent. But, then, how important is it to attenuate this interference? With Bluetooth, it is surprisingly unimportant! Considering figure 5:1 again, you will note that the reflected wave will practically always travel a distance that is of different length from the direct path. Measuring these distances in wavelengths, we realize that the reflected waves will likely be out-of-phase with the direct wave. With proper design of beams and antennas, these reflected waves are weaker than the direct wave, and the reception will most of the time be legible. This is in large measure due to the fact that the information is digitally coded, and can be reconstructed using the protocol described elsewhere. If, for a certain momentary frequency, the reception is garbled, re-transmission would quickly take place, and this time on a different frequency, where the interference pattern would also be different.

6. About Bluetooth Antennas

Figure 6:1; Controlling directivity of radio waves	Figure 6:2; Constructing a di-pole antenna

he most common antenna, the so-called "di-pole antenna", is typically half a wavelength in length. This means that for higher frequencies, dipole antennas can be made progressively shorter. As noted elsewhere, the Bluetooth-antenna is so small that it can neatly be fitted onto the circuit card in the actual transmitting/receiving device. As noted elsewhere, radiation directivity, as well as reception directivity, might well be a desirable trait when used inside the FlyWay beams. An un-affected transmitting dipole antenna has a field that is uniform in all directions, as shown in A in figure 6:1, where the antenna is seen from one short-end. By arranging transmitting antennas in various configurations (as shown in B), one can get any desirable radiation pattern, depending on distances (in wavelengths) and angles between the antennas. One could also have these antennas radiate out-of-phase with each other, and have them transmit at different powers. Aligning antennas in a row (as shown in C in figure 6:1 above), transversal to the direction of transmission/reception, is the easiest way to achieve directivity. If they are in phase with each other, one gets a correspondlingly stronger field in the direction of the arrows. The same effect is achieved with one antenna, longer than the dipole. The longer the antenna is, measured in wavelengths, the better the directivity. The corresponding effect is (more or less) achieved also for antennas that are receiving.

A transmitting antenna can be regarded as an electrical connection between two capacitor plates. There is an electric field, whose strength is proportional to the electric charge on the plates, and inversely proportional to the distance between them. Now, imagine that these plates are moved apart, as shown in figure 6:2. The electric field between the plates remains, although it will be weakened in proportion to the distance between the plates. This field will take the shortest distance between the plates, which in our example means that they will follow the connector between the capacitor plates, as shown in C in figure 6:2. In addition, we have an alternating electrical current in the conductor, and this current creates a magnetic field, as shown in figure 6:3. This field is 90 degrees out-of-phase with the current, because it is generated only during the phase when the current grows, not when the current is static. What complicates antenna technology is; a) that the electro-static and the electro-magnetic fields influence each other. b) these fields are partly re-absorbed into the antenna as the current change. This effect is also frequency-dependent. c) with increasing frequency, the current inh the connector is more and more concentrated to the surface of the conductor. This is called "skin-effect" and the reason for this effect is the influence of the electro-magnetic field inside the conductor.

Figure 6:3 Dielectric Resonators A new technology, promoted by the british Antenova company, and based on research at the University of Sheffield, England, and at the Griffith University in Brisbane, Australia, provides a solution to the "skin-effect", and has other interesting properties as well. Instead of using metal conductors for the antennas, one can use dielectric resonators, an idea that was originated back in the 1930-ies. The ceramic material used is not electrically conducting. Instead, one gets a displacement current, caused by polarisation of the atoms in the material, as a result of the electro-magnetic field (for receiving antennas) or by the applied voltage (for transmitters). These antennas have considerably higher efficiency than normal antennas; 90% versus about 60-70%. They can also be made smaller.