- Segstick: Build Your Own Self-Balancing Vehicle in Just 2 Days with ArduinoPosted 1 week ago
- ZSWatch: An Open-Source Smartwatch Project Based on the Zephyr Operating SystemPosted 4 weeks ago
- What is IoT and which devices to usePosted 1 month ago
- Maker Faire Rome Unveils Thrilling “Padel Smash Future” Pavilion for Sports EnthusiastsPosted 2 months ago
- Make your curtains smartPosted 2 months ago
- Configuring an ESP8266 for Battery PowerPosted 2 months ago
- Creating a Telegram Bot for ESP32Posted 2 months ago
- Mini Course on BlynkPosted 2 months ago
- Creating a Unique Electronic Musical Instrument: The Sound WallPosted 2 months ago
- Building a Laser MicroscopePosted 2 months ago
GSM localizer without GPS – Part 4
Connecting to Google
In order to be able to associate a GSM cell with its geographic coordinates, we utilize a Google Maps Mobile function, which is not documented, though. Before doing this, however, we need to know which cell the remote GSM device is connected to, that is, we need information regarding MCC, MNC, LAC, and CID. To obtain the data we need, the microcontroller must send the following commands to the Enfora module:
AT+COPS? to obtain MCC and MNC
AT+CREG? to obtain LAC e CID
Recall that during the setup stage of the GSM module it is necessary to program Enfora in such a way that it can respond to questions such as the two immediately above. To this end, PIC needs to have sent the module the following commands:
AT+COPS=0,2
AT+CREG=2
Once the data regarding MCC,MNC,LAC and CID have been obtained, the remote device can send Google (www.google.com) a request, using the function HTTP POST. Thus, what one needs to do is first connect to Google and then send a request with the following procedure:
POST /glm/mmap HTTP/1.1
HOST: google.com
Content-Type: application/binary
Content-Length: 82
Connection: close
The relevant string consists of 82 characters which must contain the cell’s data, among other data:
21 | 2 byte | 2 |
0 | 8 byte | 8 10 |
2 | 2 byte | 2 12 |
it | 1 byte | 2 14 |
13 | 2 byte | 13 29 |
Boris Landoni | 1 byte | 2 16 |
7 | 2 byte | 2 31 |
3.0.1.6. | 1 byte | 7 38 |
3 | 2 byte | 2 40 |
Web | 1 byte | 3 43 |
27 | 1 byte | 1 44 |
0 0 3 | 4 byte | 12 56 |
0 | 2 byte | 2 58 |
cid lac mnc mcc 0 0 | 4 byte | 24 82 |
It is essential that the length of the data be adhered to; for instance, header Content-Length: 82 explicitly specifies how many data are to be sent : if the string length should be different, the server will reject the request. After processing the request, the server will respond with a string containing the cell’s geographic data (if that is in the Google databases, obviously) as well as the approximate position of the remote device, that is, its maximum distance from the point in question:
2 byte | a |
1 byte | b |
4 byte | c |
4 byte | latitude |
4 byte | longitude |
4 byte | approximation |
4 byte | d |
2 byte | e |
While testing the device, we were not able to determine with certainty what the data a,b,c,d, correspond to, in part because, as was mentioned above, Google fails to document such functionality; our conclusions are thus based solely on our sniffing the data exchanged between the Google Maps Mobile cellular application and the Google server. We encourage others to look further into this issue …
WM Cell Catcher allows one to find out the data of the cell the phone is connected to