Gordon, Sep 20, 9pm

After some hacking, bluetooth networking is working well.

Initially tried the bluetooth access points on a metal pole mounted on the NW corner of the base trailer. All three radios were on the same pole.

BTAP2, serving sites 8-13 was placed highest on the pole, since we felt it had the worst line-of-site view of its stations. BTAP1, serving sites 1-7, and the AP3, the Bluegiga 3241, serving 14-19 were lower.

We were only able to connect to sites 1,8,13,14,15 and 17.

Later found two issues that might have prevented good connections:

  1. a bug (mine) in the blue_check.sh script on the DSMs, where it did not restart the pand process if ping failed
  2. some of the dipole antennas on the radios were not screwed on tightly. I didn't note which stations.

Those 6 sites had pretty good LOS. However other sites which also had good LOS did not come in, which may have been due to the above 2 issues. The dorm buildings were in the way of line-of-site to 5,6,7,9,10,11,12. None of these sites with poor LOS were received.

The WIFI AP24 was also mounted lower on the same pole, and was transmitting, successfully connecting to the ISS-SODAR Etherant EantH.

After lunch, moved the bluetooth radios over to the deck on the back of dorm #2, which has good LOS to all sites. The pole was just bungied to the step railing. AP3 was at the level of the railing, AP1 about a foot above that,
and AP2 about 3 feet above the railing.

Lo-and-behold, only the same connections came in (1,8,13,14,15 and 17), but, initially at least, no others.

Went out to site 4 and discovered the issue with the blue_check.sh script. However, then noticed that several stations started connecting by themselves, despite the bug in the script. So I believe the communications are better from the dorm deck than from the pole on the trailer. To work from the trailer, I believe the radios would have to be raised.

Also at this time noticed that the bluetooth antennas were loose and needed to be screwed on tighter at three sites, but forgot what sites.

The bluetooth connections have stayed up since 5pm this afternoon.

The bluetooth access points are on the pole strapped to the deck stairs. The AP24 WIFI is running, leaning against the deck railing fence. The stations are all sending their data via UDP to the flux laptop (192.168.0.12). The DSMs at main and C are not on.

Here are some connection quality numbers. All bluetooth MAC addresses (aka bdaddr) start with 00:07:80:4f.

For BTAP1 and BTAP2 access points connected to the "flux" laptop (via 2 bluetooth extension cords leading to one powered hub!) I've created a script query_radios.sh, which runs hcitool on the corresponding radio based on its hci device name (hci0 or hci1), querying the radios with rssi, lq (link quality), tp (transmit power) and afh (adaptive frequency hopping).

tp was 19 on all stations (1-13) served by BTAP1 and 2. AFH was typically something like 0xff00f03f00ff03f0ff7f. I believe perhaps that bit of 1 indicates a good channel.

site

bdaddr

RSSI

LQ

1

d4:f1

-7

141

2

d4:ef

-7

209

3

d4:ee

-1

209

4

d4:f7

-2

209

5

d4:d9

-2

209

6

d4:f8

-4

207

7

d4:eb

-2

212

8

d4:e4

-6

210

9

d4:ed

0

212

10

d4:e9

-3

211

11

d4:fb

-6

191

12

d4:e7

-2

211

13

d4:f6

-5

186

To see the RSSI (received signal strength indicator) and BER (bit error rate) on the Bluegiga AP3241, ssh to root@192.168.0.13, and run the inq comand:

site

bdaddr

RSSI

BER

14

d4:fc

-63

0.9

15

d4:f2

-62

0.34

16

d4:f5

-62

0.34

17

d4:f0

-69

0.82

18

d5:00

-67

0.74

19

d4:ff

-76

2.26

Note that RSSI is a relative number, and can't be compared between the two types of access points.