wigle

All posts tagged wigle

Things got interesting.

As mentioned in the previous post about WiGLE and the AtomGPS device, I used phones as my only source of gathering with the tiny exception long ago of ministumbler. I have, since that post, become more enamored with the AtomGPS itself especially with the code improvements and community around it. I did want more, and especially other frequencies, so how would I be able to do that?

Another phone, of course! No, really, I had a blind spot for the newer WiFi 6E spectrum, and in discussion this year with El Kentaro it seemed like the Pixel 6 series was a step up from what I was using in several ways. Not only was it a faster device, with custom Google Tensor silicon, tons of RAM, and direct support, but it had the radios I wanted to look into the third spectrum. So, the search began, then stopped, then started, and stopped, and I finally picked one up.

Is it great? Mostly. Is it seeing more networks? Yes. Would I recommend it as a single device? Definitely. Is it the subject of this post?

No.

While having a “main” phone device is a good thing, because it’s self-contained and has many functions apart from WiGLE, there were still other projects out there that piqued my interest. This is a big community, and its members have many ideas, some of which are approachable (AtomGPS) while others are insane and awesome (Lozaning, Mr. Bill, BusySignal, others). I wanted something that could do what a typical phone could do but be dedicated solely to the task. This meant GPS, Bluetooth, 2.4 and 5GHz. The big one that I am always willing to pass on is GSM because, well, who’s counting those?!

Sweet Spot

I’d seen hints of several neat standalone devices, but one kept surfacing as the most interesting option. The JHewitt devices, as they’re known in the community, are compact units based on a PCB designed by the owner of wardriver.uk . This PCB allows for the use of two ESP32 boards, a GPS module, temperature sensor, GSM module, a microSD card interface, and an LCD. This is all housed in a 3D printed enclosure with two or three protruding antennae.

Image is of the rev3 plus the RTLBW16 5GHz module – photograph by Luke Switzer

This unit can then be built around the PCB, using the BOM, and used for wardriving as-is. The larger antennae, at least compared to a typical modern smartphone, should be able to hear those fainter transmissions, but in the basic setup they only listen in on 2.4GHz, BT, and GSM. This was a drawback to me because all modern wireless systems use at least two frequencies, and I wanted more. When I got word that a 5GHz mod with the BW16 was available my ears perked up and I was now very interested.

One of the primary code developers for the AtomGPS Wigler build, Luke Switzer, had shown off some of his builds in the past, but also mentioned that he had some components ready to assemble for eager users. This piqued my interest, and after a few inquiries a build was agreed upon. It turned out that this was the first of this configuration for Luke, and I’m happy to say it was featured on his Twitter account during the assembly and testing. I was very eager to get this custom build and join the crew of those who rock a fully capable wardriving rig that’s self-contained.

I do mean it when I say that this is a standalone unit because it features some incredible software and hardware. The most loved feature of this build is that it has two 18650 batteries powering it, with charging built in, and it’s fully protected from overdraw. I really like the AtomGPS, but powering it from an external battery is a hassle. This community-sourced solution not only means that the 3D-printed case fully supports the battery module, but it’s one cohesive unit that has the feel of a small FRS or HAM radio. This is a good thing, because it’s meatier in the hand while being very balanced.

A side-benefit? The diymore V8 has an external USB-A 5V port for powering other devices. I think that I’m going to use this for powering my AtomGPS once I figure out how to keep it all in one package.

On the software side it’s even more interesting and impressive. The initial setup is all through an onboard web interface where the new user connects to an onboard, ad-hoc AP and web server. It prompts for a known network to connect to for NTP sync and software updates, and a fallback network configuration for use after the initial setup. This works very well and the LCD interface is very good at informing the user about what the unit is doing. This display information includes the IP address, if it’s connecting to the server, and other information prior to the typical status display.

Once set up there are several features that make this almost as good as a phone. When it’s connected to that configured network, prior to fully booting, there’s a 60-second timer before the web server shuts down and scanning begins. This timer reset if a user connects to the displayed IP and makes changes. Some of the neat features also include adding your WiGLE API key for manual uploads, and there’s also an option for it to automatically upload as well! If you want to download the files individually and upload them separately, this is also an option that’s pretty easy to do.

The hardware is brilliant, with several case front options. I chose the more temperature-friendly one with the hexagonal design, favoring airflow over style or weatherproofing.

Using the JHewittrev3 (mod)

Startup from off is a single tap of the right-side button. Booting shows the software version, connecting to NTP, the wardriver.uk server if enabled, and the option to press the power button during boot to reset to initial settings. Following that, and if a known network is found, any pending uploads will take place automatically if configured. Then starts the 60-second countdown for the web configuration, displaying said timer and local IP address. Make sure that you configure the device on a network with peer visibility…ask me how I know.

Finally you will be greeted with the rev3’s dashboard, displaying seen networks, bluetooth, GPS status, date, time, and temperature. For those who can see it unassisted you’ll find that there are no stats akin to the Android WiGLE client where it’s doing database comparisons. We’re just collecting networks and not doing any data analysis here, so you won’t see any statistics for your run…unless you want to fork the code and take that on yourself!

This fully-stocked unit is easy to handle for those with medium to large hands. The grip, as mentioned previously, is like a large FRS or HAM radio. It’s well contoured and light enough that walking with it in hand is easy. I have done this on several walks, antennas horizontal, and not found any fatigue. I did also add a small Scoche magnetic plate to the left side for car mounting. It’s mostly been used in a vent mount and hasn’t overwhelmed the mount or the vent.

Battery life is good, considering you have two big ESP32s and the BW16 onboard with a display and GPS. With what I expect to be a full battery charge I have exhausted the battery over the course of a long day. On my unit there is no way to see or measure the status of the batteries, but I have become more willing to power it down when I’m not moving or in a new area. This increases the number of files, but it is a good idea if you’re away from charging capability.

On that note, this diymore battery pack would be even cooler if it supported hot-swapping of the 18650 batteries, but its protection circuitry doesn’t allow for that. If you pull a battery out and place it back in the holder it will almost certainly not then be drawing current. To be fair, I’ve not tested pulling out one, putting it back in, then taking out the other. However, I’ve read the documentation and user comments about the required power cycle when charging. If you plug the pack in and the unit is on, it will charge and run as expected, but pulling the power will force a power cycle. This could be used strategically with an external battery pack to extend the run, of course, but remember that unplugging it or turning off the pack will restart it.

Performance

So, how well does it perform?

I’ve been using it with the AtomGPS and the two Android phones for a week now and I am impressed. I’m in the habit of uploading the Moto first, then the Pixel, then the rev3. I’ll add the AtomGPS less frequently simply because of the work involved. So far I am impressed!

If you are looking for a BT sponge this is not your device. The Pixel 6 and most phones will do a much better job at finding those than an ESP32 or BW16. As for the other numbers, well, they’re impressive. I’ve been seeing very solid network observations when analyzing the WiGLE upload statistics. The rev3 always has significant new networks to add even after the Moto and Pixel have submitted theirs. The antennas being a higher sensitivity is giving it a huge advantage, and making each trip a little more effective. This is what I wanted, and it’s really boosting my upload totals.

This is a sample of a recent run, with the Moto on the top line, Pixel in the middle, and JHewitt rev3 on the bottom. Those are some impressive numbers!

One of the neat things that having external antennae allow is for bigger, or different designs. Do you have an old AC1300 Nighthawk in a drawer? Grab some of those cool blade antenna and swap them in. Have an old Yagi in a closet, or maybe a magnetic omni? Let’s go for a roadtrip!

Conclusion

If you are new to WiGLE this isn’t the place to start IMO. The numbers-go-up pleasure from the Android app is quite alluring, even years later. Driving around a new neighborhood and visually seeing a change is nice, and you get a better understanding of what’s out there. It will drive you to get more, or better, devices to do one of two things: more input or consistency. Some phones are just bad, while others are mysterously over-performers. However, if you don’t have a phone with you, you’re breaking rule #1: Always Be Wardriving. Having the AtomGPS in a vehicle or backpack is easy. Same with a phone.

I’ve been part of the WiGLE Project, as a contributor, since 2017. I have a much longer history with the idea and practice of “wardriving” that extends to the early days of wireless internet as a thing. Wardriving was something we would do with a PCMCIA wireless card, an antenna, and a laptop. Or in my case, a portable PDA running Windows Mobile. Most of the data contributed to the greater project is done so with Android phones, which makes sense because they have good antennas, GPS, and respectable processors. Things are getting weird though, and some devices that are neither “computer” nor “phone” are becoming more popular in the fringe. Let’s talk about my step into this new world.

More creative members of the community have latched on to the small, cheap, and powerful ESP32 devices that are increasingly competent and accessible. They’re easy to code for and program, a favorite in DIY projects, and are turning up in some compelling packages. One such project is the M5Stack AtomGPS device. It’s a combination of the M5Stack Atom Lite ESP32 unit, plopped into a saddle that includes SD and GPS, which is a critical part of the WiGLE project.

These are affordable, when they’re available, and cost around $30 USD each. This includes the Atom unit, the GPS saddle, and a USB-C to USB-A cable. Add a 4GB-32GB SD/TF card and you’re good to go for hardware. I obtained mine from Mouser, but other sources include DigiKey. Software, well, that’s a different story. Buckle up!

I do not regularly use ESP32 devices, nor Arduino, but I am loosely familiar with the software IDE. I chose to use Windows for my firmware flashing platform, just as a matter of availability, so here’s where it got interesting.

Note that I am an ESP32 amateur. This guide is merely a verbose interpretation of the README.md. Refer first to that guide, which is updated frequently, and follow this one if you’re looking for another option.

git clone https://github.com/lukeswitz/AtomGPS_wigler.git

Installing Git is easy, especially if you choose the Portable installer. Using the instructions here, or the code above, you can clone the repo. This will place a folder called “AtomGPS_wigler” inside of your Git Portable directory, which is probably in Downloads if you’re using Windows. Why did I prefer the Portable version? It’s quick and easy to use and doesn’t integrate functionality with your computer, making it perfect for a small project like this. The Arduino IDE is also a pretty straightforward install, and it’s an easy interface to use. Once that’s installed there are two very important things to add for the M5Stack Atom specifically: the board and the libraries.

Add the M5Atom libraries, and all of the dependencies, under the Library Manager tab on the left side of the Arduino IDE:

Copy the URL to the library json below, then go back to the Arduino IDE, into File > Preferences, and let’s add this Espressif board library in the “Additional boards manager URLs” area and click the icon to the right, confirm the URL, and click ok.

https://espressif.github.io/arduino-esp32/package_esp32_index.json

Select the Boards Manager tab on the left, search for “esp32” and install the Espressif Systems package.

Now make sure that you have an SD/TF card formatted in FAT32, MBR. 4GB-32GB are tested/supported. The slot is on the back side of the GPS saddle, and has that little click in/out mechanism. Plug the AtomGPS in to your computer and get ready to flash.

Open the repo clone file called “AtomGPS_Wigler.ino” and make sure that the board type is set to M5Stack-ATOM or M5Stack-Core-ESP32. I have both of these here because of mixed success. One should work as expected, while the other may fail.

Restart the Arduino IDE.

Click Upload in the IDE toolbar and wait for the magic to happen…or errors. If things go well you’ll see a white cascade of the flashing process, after which the device will be rebooted. If all goes well, you should see a purple, then green LED flashing on the unit. If it’s red, well, that’s a problem. In my case this meant an older problematic version, which I will cover a little bit later. Future versions fixed this issue and the purple/green is what you’ll be greeted by.

Okay, yes, that’s all it does. It powers on, it gets a GPS fix, and it scans. Lines are being written to the SD card in a unique file per boot. These are compatible with WiGLE and can be uploaded at your convenience or the next time you see that hot shot delivery van driver you gave $20 to put it in the glovebox…

Now the story begins, as does the other way to flash the AtomGPS:

All of this, and my first try at a pair of new AtomGPS units failed. I spent more time than I care to total in troubleshooting why, until a fellow user pointed out that the code developer noted some reports of SD card detection issues in the older 1.3.2 version. This is the one I was trying to use, and instead of making changes to the code to fix SPI, I decided to use esptool, the alternative way to directly flash a .bin file.

There is a driver from FTDI that I can recommend downloading and installing from here and it is referenced from the M5Stack Github. I have found this not to be necessary, however it’s a simple install.

To use esptool I simply opened the Windows Store and installed the latest version of Python available at the time (3.xx). This done, I opened a command prompt and installed esptool with the “pip install esptool” command, which took very little time. In some environments it would be possible to run “esptool.py” if environment paths were set up properly, but instead I used “python -m esptool” with some arguments:

Note: Refer to the README for updated commands

For version 1.3.1 I used the following command with COM3:

python -m esptool --chip esp32 --port [PORT] --baud 115200 write_flash -z --flash_mode dio --flash_freq 80m --flash_size detect 0x10000 AtomGPS_wigler_v1_3_1.bin

For version 1.4 I used the following command with COM3:

python -m esptool -p [YOUR_PORT] -b 1500000 --before default_reset --after hard_reset --chip esp32 write_flash --flash_mode dio --flash_size detect --flash_freq 80m 0x1000 AtomGPS_wigler_v1_4.bootloader.bin 0x8000 AtomGPS_wigler_v1_4.partitions.bin 0x10000 AtomGPS_wigler_v1_4.bin

Note: versions mentioned below have been superseded by 1.4 and above

Make sure that when you’re copying this code that you replace [PORT] with something like COM3 and do not include the brackets in your script. Ask me how I know that it doesn’t work with brackets…

This directly flashes a .bin file, which needs no libraries or dependencies as It’s a full image, and if it writes successfully then the firmware is good. This done, my first of two AtomGPS units was working with a 16GB SD card. I totally expected the second to work just the same, but it was not so easy. Using a 4GB card I was unable to get the second one to work with esptool and version 1.3.2. Frustrated, I flashed 1.3.1, which was in the Git clone folder. No luck, but in some frustration I swapped in a 32GB SD card and it booted up immediately. This was a surprise.

So, what would you do next? Flash 1.3.2 of course. Did it work? No!

So, after a flash back to 1.3.1 and a few minutes of running, I checked the SD card for the AtomGPS csv files which were now present. It’s not a matter of how well it works, at this point, but that it does. The developers and community will add features and improve some of the code, but there’s not a really compelling reason to make sure that the devices are up-to-date. So, in the interest of not spending any more time on these in the immediate future I’ll be content with two of the AtomGPS units running different versions of the software.

Lessons learned? Plenty. I should have checked with the developer to see if there were any known issues. This would have saved me a lot of time, but it wasn’t all in vain. Having more SD cards available is certainly a plus. Knowing that the developer provides older .bin files in the Git clone was a handy thing because I could fall back on older code to avoid new features and potential issues.

Would I recommend an AtomGPS or other dedicated WiGLE device? Yes. These are super handy to put in a vehicle or somewhere that either has a lot of traffic or itself travels a lot. It’s not necessarily a device that needs a file dump and upload daily, or even weekly. I’ll be putting one in each car and uploading the files when I think it might be good. I’ll also keep using a phone too, because you can never have too many antennas…

Thank you to Luke Switzer for the software development, Lozaning for inspiring it, and pejacoby for showing off the project on social media.