wardriving
Initial post: Aug 2024
Updated Wigle scan speed section: Sept 16 2025
Updated Signal Sleuth build notes: Sept 17 2025
thebaldgeek finds wardriving very relaxing and a great way to explore the world. Be it just a few blocks around where you live, or the planet. Seeing the ebb and flow of the density of WIFI access points gives him a bigger world view and a touch of humility that he appreciates.
Of course, there is also a baldgeek aspect to the hunt, the RF side of building a rig to capture as many SSIDs as you drive down any given length of road. tbg is fascinated by the idea that it's unknowable. No matter how much you tweak your setup, did you get them all? Is there some other change you can make to accurately catch any more SSID broadcast beacons?
Lastly, tbg is interested in contributing to large public data sets. Adding his travels to the larger community's pool scratches a part of his brain that needs it.
Over-simplifying, wardriving is about picking up as many Wifi SSID's as possible. Second to that, but very importantly, is having them accurately GPS tagged, and striking the balance between range and accuracy.
ie, if you run a high gain directional antenna, sure, you might get a few more SSID's, but they will be poorly tagged with GPS data and thus dilute the value of the data somewhat.
It’s crucial to emphasize a common misconception. wardriving these days does NOT involve CONNECTING to the SSID. It is just passively listening and logging the SSID. That’s it.
NO CONNECTION IS EVER MADE.
wardriving is not about warchalking or trying to hack any wifi, or get anything for free.
The only hacking that is going on is the fun of tweaking your rigs hardware to capture as many beacons as possible.
thebaldgeek joined Wigle around Dec 2015. Before then, he was actively wardriving for about 5 years with many different setups - Orinoco cards in an HP Jornada, for example. He's been testing various setups and antennas, using the Wi-Fi SSIDs' broadcasts as signal sources, as the RF aspect is a strong interest.
If you want to really soak in a good selection of amazing rigs that have been purpose built for wardriving, check out this long photo dump of builds: https://github.com/rfhs/rfhs-wiki/wiki/Community-Builds
(tbg slightly smug cheeky comment - most of these amazing rigs are ranked lower than tbg on the Wigle leaderboard rankings - keep reading for why he thinks that's the case).
Aug 2024 he got the bug again and started pushing for the 1 million mark (Aug 2025, hit the one million Wifi discovered by thebaldgeek).
Once again, this page is a messy brain dump of notes and current setups tbg is running.
Why wardrive?
There are a lot of different goals and reasons to wardrive.
For tbg, living in Southern California (high population density and thus high geek density means that a lot of SoCal has already been wardriven by different methods) means that the big wifi nuggets have been mined and picked over to various extent, so his goal is to build a rig/setup that will extract the flecks of wifi gold that others have missed from the same roads. This does NOT mean high-gain antennas, but rather ensuring that each and _every_ wifi SSID is geotagged as accurately as possible. This means using sensible antenna gain, lower ground speed, higher speed WIFI channel scanning and very good GPS signal / many GPS sats fixing each SSID that is heard.
 |
| SoCal town of Temecula before and after being wardriven by thebaldgeek |
Your goals might be different. Regardless, take a pause to think about why you are wardriving, what your goals are, and how to reach them the most efficient and interesting way.
In June 2025, moving to North Idaho opened up a whole new area to wardrive. thebaldgeek found it a great way to get to know the new hometown location with the goal of diving every road possible. Pointing back to the opening paragraph, tbg found it a very important de-stressing part of the move. Driving while listening to his beloved chill trance is very therapeutic, and being able to add wardrving to the ‘reason’ was a key part of fighting a good amount of anxiety and depression - but enough of that.
Android Phones running Wigle.
Never throw out old Android phones. (But there are age limits.)
Old phones that are, say, more than 6-8+ years old often struggle to have the right SSL certificates, and so they can’t connect to the wigle.net servers. On some, you can side-load the old version of the Wigle APK and get the app running, but generally it's a bit more hassle than it's worth.
Safe to say that simply installing the Wigle app and letting your phone run day in and day out is the easiest way to get going with wardriving.
Do note that Google decided to throttle the wifi channel scanning speed to save a bit of battery power; it's up to you if you want to enable developer mode and disable that throttle or not. tbg turns it off and has not really noticed that much of a battery life hit, but just know that it's an option, and be aware of the downsides. Of course, if it hurts your battery life, turn the throttle back on, experimentation is the name of the wardriving game.
And sorry iPhone folks. Apple does not like its users playing on the other side of its walled garden. Ask some friends, family, or co-workers if you can have / buy their old Android phones they have sitting in the top drawer going unused.
Phones that tbg has tested or currently uses as of Aug 2024:
Note 9 - not great
Pixel 5 - Okish
Pixel 8 Pro - pretty good. Daily driver phone and in-car wigle map display
Samsung G23 - solid. tbg sons daily driver. Tested in-car only.
Samsung G20 - Beast. No, really, this phone is the best wardriving Android that tbg has found hands down.
Nexus 7 - External antenna mod. Great setup, on the large size, but the external antenna mod makes it worth running. (Died Aug 2024 - display issues).
Aug 2025 tbg added:
Pixel 9 Pro XL - pretty good. Replaces the Pixel 8 as the in car daily driver
Note 20 Ultra - horrible. Returned back it to Amazon, it was so bad.
Wifydra - Interesting, mixed results (keep reading)
Wardriving on an electric longboard.
Top speed of 15mph, easy to quietly move around apartment complexes and other tight spaces.
Aug 2024 tbg runs three phones, the P8P in the car showing the wigle map - it’s also scanning of course, P5 and G20 are the main scanners.
The P8P on the left: 2170
Samsung S20 on the right: 3570
Same drive. The S20 really is a wardriving beast.
Scanning Wifi channels.
There are 14 channels on 2.4Ghz and 24 on 5Ghz. The ‘trick’ is to scan _all_ of them looking for the SSID broadcasts while driving down the road.
If you have spent any time on the https://wigle.net/phpbb/ forums you would know that there is a lot of talk about what are the best scan speeds to try and push your phone(s) to pick up the most number of broadcasts for any given ground speed. Keep reading or skip ahead to the test tbg did to find the best scan speed for each of his Android devices.
tbg has seen one website that did the math of the typical range of wifi vs 20mph driving speed vs SSDI broadcast interval.
This website breaks it down by SSID broadcast time vs road speed: https://wardriver.uk/how_it_works_3
Here is the main snip of information from that site:
...scanning WiFi; it scans channels 1-13 and spends 110ms on each channel meaning a full scan takes ~1.4 seconds. Since the average WiFi access point transmits a beacon every ~102ms, every channel hop should yield the vast majority of the WiFi APs in range operating on that channel.
Keep reading for information about the Wifydra that gets around the channel hopping issue - on 2.4Ghz at any rate.
The limitations of the Android app scanning through all these channels (pausing on each one at a time for a short time) is why most hardcore wardrivers run more than one phone. You will get a helpful overlap of each phone scanning different channels at different times. This is exactly why tbg runs three phones and the wifydra. It significantly increases the odds of successfully catching the broadcast of every 2.4GHz SSID at any ground speed. Of course, the phones also pick up the 5Ghz and Bluetooth. Building a 5Ghz wifydra is on the hit list for many wardriving folks.
The other issue with the Android setup is that you cant specify the channel dwell time, just the total scan time. Keep reading for a lot more about finding and setting the scan time in the Wigle app.
Phone placement.
Clearly, just having a phone in the car on a vent or suction cup mount is the safest and cleanest way to set things up. If you have one Android phone as your daily wardriver, then just running the Wigle app while going about your life is fantastic and is good fun.
Once you start running three or more phones, it gets a lot more fun and complicated keeping them charged and uploading after each run.
tbg heard about one guy who runs five phones on every wardrive. 1 daily driver up front with him on the driver's side, one at the front of the car on the passenger side, one on the rear driver's side window, one on the rear passenger side window, and 1 in the middle of the back window. Pretty solid setup. But not something tbg wanted to replicate...
One thing tbg learned the hard way with L-Band ACARS is that often window tint can block GHz signals. In the case of cars, this includes the ceramic and 3M window tint (very popular in SoCal), or any brand that blocks UV radiation (heat). Given this first-hand experience from the placement of 1.7GHz satcom helix antennas, of course, he figured he should test it with his wardriving phone setup.
tbg figured the best place for a GHz RF antenna is outside the car, outside the RF shield, getting an extra few feet of height does not hurt either..
thebaldgeek firmly believes this one change has given him a massive jump in the Wigle leaderboard rankings. Beyond just driving consistently, beyond driving new ground, just getting the phone outside of the Faraday cage that blocks about 50% of the signal!!!
Lets take a look at some numbers to back up that belief.
The commute to work is a good baseline. Take the same route at the same time each day.
Make five runs and see what the average is with the phone on the in-car vent mount.
Move the same phone outside and make the same baseline run 5 times, and see what the difference is.
P5 in-car five run average wifi SSIDs: 2456
P5 roof five run average wifi SSIDs: 4971
Stunning. Almost double the Wi-Fi SSIDs by having the phone on the roof of the car!!!
Same drive, same time, five working-day average. About double the number of SSIDs were heard by the exact same phone just by mounting it on the roof of the car!!!
(As an aside, tbg thinks the 2018 Chevrolet Bolt is the best wardiving car — it’s quiet, cheap, has a good enough turning circle, and most of all, a one-pedal driving mode that can't be beat for wardriving).
Magnets in the base of the blue box floor are holding it to the roof. Not the best, but for a 40mph max speed, 32mph average, 5 drive run, it proved the point.
Please don’t reproduce this setup! You will break/lose your phone!
thebaldgeek then got his CAD / 3D printing guy on the job, and this is what he has now…
 |
| The wiglefin |
The lid pin pulls out, the lid slides up and off, and some foam edges the phone.
150lb pulling force magnets, four of them, hold the wiglefin to the roof. Tested at 82mph on Los Angeles freeways.
Zero movement with the kitchen drawer non-slip coating on the bottom of the fin.
tbg is in the process of printing another red and another white ‘wiglefin’, so will have matching fins for the two cars he drives. (The wife wants them to match in color when she’s in the car <shrug>)
DO NOT use this setup in North Dakota in winter, or Arizona/Texas in summer, you will kill both your phone and battery. This setup is for fair weather/temperature wardrives only. Keep it at 72F / 23C.
You can find the STL files here: https://thebaldgeek.github.io/wardrive.html
If you use them, or modify them (adding vents for example), please include a link to this blog or my GitHub page as a way of saying thanks and for letting folks know the source.
Also please let me know in the comments here what you ended up doing etc.
wifhydra - scan ALL the 2.4Ghz channels ALL the time. #allTheWifi
https://github.com/lozaning/The_Wifydra
Build cost is about $120 to $210 USD, depending on options.. (Note that the Wifydra in a box with real antennas is going to cost around the same cost as a refurb Samsung S20 here in the USA).
BOM:
$30 5 x PCB (5 is the min order).
$32 1 x GPS: https://www.adafruit.com/product/746
$9 1 x MicroSD breakout board: https://www.adafruit.com/product/254
$34 1 x Feather board: https://www.digikey.com/en/products/detail/adafruit-industries-llc/5300/16584014
$68 14 x https://www.seeedstudio.com/Seeed-XIAO-ESP32C3-p-5431.html
Note1: the ESP32C3 each come with a small flexible ‘patch’ antenna on a short coax cable.
Note2: the GPS module uses a CR1223 battery to retain time and GPS data between power cycles. Its highly recommended to buy a battery and put in the module as it will make power-up GPS lock a LOT quicker (less SSIDs saved with 000.000 lat / lon).
Extra tbg Options;
$35 2.4Ghz antenna and adaptor 14 x https://www.seeedstudio.com/2-4GHz-2-81dBi-Antenna-for-XIAO-ESP32C3-p-5475.html
GPS active antenna 1 x https://www.amazon.com/Waterproof-Active-Antenna-28dB-3-5VDC/dp/B00LXRQY9A
GPS adaptor cable 1 x https://www.amazon.com/dp/B00XW2LKNO
microSD card extender 1 x https://www.amazon.com/dp/B07WWVBK8V
Hard case 1 x https://www.amazon.com/dp/B094W9266D
Magnets x 1 set: https://www.amazon.com/dp/B0CC5HC4NG
Program the sub.ino into each ESP, make sure you edit the .ino (its a text file) and change the board number - look for the obvious comment a few lines into the file. They MUST be numbered 1 through 14, don’t use any other number system, the numbers are tied to the code in the dom.ino file in the feather board.
tbg labeled the boards so if he had an issue, he’d know which one it was, not required, but not a bad idea. The sub boards are numbered on the main PCB, but any sub can go in any location.
It's slow(ish) to program all 14 subs because the IDE has to compile for every board just due to changing the one-line boardID, and just FYI, we had to set the specific board type in the IDE. It auto-detects as "ESP32 Family Device" but won't compile unless you select "XIAO-ESP32-C3".
The only thing of note is that we had three of the 14 subs throw this message:
— Failed uploading: uploading error: exit status 2
Thankfully, both worked on retry.
1 Sub ESP32 totally failed. Tip, buy 1-2 extra and save having to reorder and extra shipping.
Program the dom.ino into the feather board.
NOTE!!!! Use the dom.ino code in thebaldgeeks comment. The main github dom.ino WILL NOT WORK with Wigle.
Note that we could not get the Dom to compile and download using the local IDE that we used for the Subs. Once we switched to the cloud based IDE, the dom compiled and downloaded without issue.
Solder up the +v, gnd and two I2C pads on each sub and the pins on the GPS and SD card boards.
Jumper each of the VCC, gnd and both sets of I2C pins on the main PCB.
Apply the three gaks. (1 cut track and three jumpers)
Click on any image to make them bigger/larger.
 |
| Cut track and reminder to bridge |
 |
| Three jumpers need to be added |
tbg never figured out why, but he could not power the board from the Gnd and Vcc pins just above the Dom Feather module.
The board will pull about 1.38 amps at 5 vDC. This is about 7 Watts.
The board worked when powered via the USB-C connector on the Dom Feather module.
(Not sure about why the tiny font on the Dom, if tbg ever works it out, will update this page).
When there is no lock, the GPS will flash its fix LED every second. When the GPS has a fix, it will flash every 15 seconds.
There is no ‘safely remove’ the SD card requirement; the code writes each new SSID to the CSV log file and closes the file, so the card can be ejected at any time that its activity LED is not on.
After the drive, remove the SD card and put it in a reader on your computer, open the latest CSV and remove all the top entries that have 0,0 for the lat lon. They get logged as soon as you turn the board on and before the GPS has lock. You DONT want to upload these to Wigle.
Once you remove the top X number of entries (but NOT the first line with the descriptions), save that file either back to the SD card, or on your computer.
Log in to Wigle and upload all the CSV files created during the run. Best to wipe them out of the SD card once uploaded so you can keep track of what you have sent after each wardrive.
September 2025 update.
New town, new stresses, wardrive to the rescue.
Not going to go into it, but thebaldgeek has a chance to wardrive, but not do as much ACARS website / hardware work as he would like. When the winter snow hits, that may flip 180 deg, but for now....
The brain dump on wardrving continues.
The Wigle forums are hit and miss for good information (Sep 2025 they have been down for over a week), but some folks do some handwavy testing and tbg got sucked into one thread that proclaimed the Samsung Note 20 Ultra was the next big thing (better even than the astounding G20). So he dug deep (money is very tight) and got one off Amazon.
Doing the same drive 3-5 times quicky shows the difference between devices. The Note 20 is thousands of SSIDs behind every other phone. When mounted on the roof, it was about the same as an in car Droid. This is just unacceptable given it's price point (~300 USD). So it was returned.
Since tbg had already negotiated the release of funds, a new direction was taken.
What follows is a live updating of this blog while tbg builds a Signal Sleuth.
While the SS kit is in the mail, lets first settle the major Wigle forum question.
Time after time, post after post, people ask what is the best scan speed (in the dropdown of Wigle app) to pick up the most SSID broadcasts.
Most of the time, its not answered. I think its because its a phone by phone setting.
You can't just take someone elses scan speed, stick it in the app on your phone and replicate their results.
So, lets think about how to find that number. Not so that you can just copy it and blindly put it in your phone - please don't do that - but so that you have a method of finding it for YOUR phone(s).
Wigle scan speed setting
Here is the thing. It seems that not all Androids are the same (pretend shock).
Firstly, it seems clear that there are changes in chips for any given phone during the manufacturing run, but also in how folks set them up.
No two users are the same. Different apps, different background processes are running etc.
How do you find YOUR device best scan speed setting.
I'm not saying tbg has _THE_ method, but here is how he went about it...
 |
| Wigle settings with scan speeds selected and the ones tbg tested highlighted |
Mount the Android in a fixed position. Does not have to be in the final position, but it would be best if it was. But being in a fixed position for every drive during this test is important. You want to reduce the number of variables to just one - changing the scan speed in the app.
Drive the same route twice. Change only the scan speed between runs.
So, pick a route that is about 10 minutes in length and pretty typical of your ground speed.
Does not have to be based on your house location. Just two fixed points with a fixed route between then and should include a solid section of typical wardriving in your style.
Your typical wardrive speed is important. As you move past the SSID broadcast, you need to hear it and log it. Too fast of a ground speed with too slow of a scan rate and you will miss some.
Here is the process thebaldgeek took.
Three droids were tested. S20 on the roof. P5 and P9PXL in the car.
Set the first scan speed you want to measure.
Drive the route. Throw away the results. (Don't argue, just do it).
Drive the route.
Upload to Wigle. Exit the app. Start the app.
Drive the route.
Upload to Wigle. Exit the app. Start the app
Change the scan speed.
Drive the route.
Upload to Wigle. Exit the app. Start the app
Drive the route.
Upload to Wigle. Exit the app. Start the app
Change the scan speed.
Rince, lather, repeat for as many scan speeds you want to test.
You get the idea.
tbg did three different scan times as per the above screenshot - so 7 drives of the same route - yes, its going to take some time, but we are talking about quantifying and ensuring our wardrives are yielding the best results they can and giving us confidence we have tuned our rigs to the their very best performance.
Also keep in mind that once you do this for all your Androids, you should not need to do it again and no matter where you mount it or where you wardrive with it, you will know its scanning the Wifi to its maximin! #AllTheWifi
tbg thinks driving the exact same route at the exact same speed twice per test is important to ensure you have something to average. It is a good sanity check to see both drives have very similar numbers, so you know any change you are seeing over the whole process is a result of changing the scan speed vs some other anomaly in the (one) drive.
Once you are done uploading after the last drive, head over to Wigle and check your uploads page.
Now, lets dive into the numbers....
Firstly, wait. No, really, wait till you see 'success' for ALL the uploads. It could take minutes, hours or even days if there is a big event on at the time you run your test.
Once you hit that status, you are ready to review the numbers.
If you have only one device, hopefully you kept track of what order you changed the scan speeds at.
If, like tbg, you had more than one, here is a tip...
Click on the arrow / three dots to drop down the name of the device that the upload came from.
Ok, lastly, JUST LOOK at the 'Number in File' column. Nothing else.
For this test, we just want to know how many SSID broadcasts have been seen on our very controlled drive.
So, with your numbers now clear, see what the average of your two drives per scan are and review or perhaps plot like them like tbg has here:
 |
| Samsung S20 |
 |
| Pixel 5 |
 |
| Pixel 9 Pro XL |
Safe to say, thebaldgeek is going to be leaving his Androids on 'nonstop' and take the battery life hit.
Your Droid(s) might be different. Your ground speed might be different. Your battery management needs might be different. Regardless plan a route and get wardriving to find out your best scan speed setting.
Last graph on this topic....
Here tbg took the average of all three drives from each device.
The roof top mounted S20 is a solid choice for wardriving as a second (or primary) option.
CPU throttling
Since it seems clear that tbg's devices catch the most amount of SSID broadcasts while running `nonstop`, he wanted to make sure it really was not bound by any choke points, so if you dig into the Samsung settings, you will find this option....
To be clear, tbg has not done the 'drive test' with it on and off and looked at the two drive count to see if it made any difference, but in the sprit of this blog, sharing all the contents of thebaldgeeks brain, this is what he found and has done.
The Pixels sort of have something like it with backgrounding tasks and such, so you can mess with those to push WiGLE to the top of the CPU list.
Building the Signal Sleuth.
 |
| Signal Sleuth Slim kit |
First job is to program the three units.
A, B ESP32 and BW16.
 |
| BW16 is the unit in front |
If, unlike thebaldgeek, you'd rather watch a video about how to do this, I recommend you start with this video for an overview: https://www.youtube.com/watch?v=xgQsn6YhqSk
DONT action any of programming from the first 30 minutes, just watch it, but don't take too many detailed notes.
The main programming process is in the v1.1 YouTube: https://www.youtube.com/watch?v=h77B8F7grRE
tbg finds frame by frame working though videos tedious and would rather read and look at screenshots of how-do stuff....
Use what ever method your brain likes best. You have choices. (tbg has been told these writeups are useless as they are not in PDF format - Sorry you don't have that choice)
First up. Download the Arduino IDE and load up the board profiles.
Click on File -> Preferences -> Settings tab.
At the bottom of the settings tab, click on the icon for "additional Boards manager URLS":
Add the following two URLs
https://raw.githubusercontent.com/Ameba-AIoT/ameba-arduino-d/master/Arduino_package/package_realtek_amebad_index.json
https://raw.githubusercontent.com/espressif/arduino-esp32/gh-pages/package_esp32_index.json
Click Ok, to close that dialog.
Click Ok to close the preferences dialog.
Next is to load the libraries we need.
Hit up wardriver.uk github and get the versions mentioned.
The only variation is that you will need to get v2.3.8 of the OneWire library. NOT the v2.3.7 mentioned.
Just download the zips. You don't need to unzip them. You actually upload the zips to the Arduino IDE.
 |
| tbg has added the zip libraries needed already in this screenshot |
Keep the wardriver.uk page open as you need to setup the IDE correctly.
But, first, there are more files to get.
Download the a.ino and b.ino from the wardriver Github
Download the BW16.ino from: https://github.com/CoD-Segfault/BW16-Open-AT
With that, we are finally ready to start programming.
Start with the BW16.
In the IDE...
Point to the BW16 ino file and it will open it up in a new IDE.
Next, click on the board manger icon and type in 'bw' to find the correct board type.
And then select the known working version from the drop down list.
At this point, you will need to plug in the BW16 to the computer USB port.
If your computer does not find the BW16 board it probably won't find the AorB board...
So add the driver for them as well.
Hit this webpage, download the files for your OS.
I made a 'wardrive' subdirectory and put everything in there.
https://www.silabs.com/software-and-tools/usb-to-uart-bridge-vcp-drivers?tab=downloads
Find the right .inf and right click it, select install.
Once your board shows up in the IDE with a comm port, you can start getting the settings correct for the programming.
First, select the correct comm port.
Note that your computer may have a different number. You can use the device manager to find it if you are unsure.
First, erase the BW16.
You have about 5 seconds to do it, so make sure the BW16 is on a firm desk and you are ready to do that button dance.
Ok, swap out your USB-C for a USB-Micro and you can start on the A&B boards.
Next, make sure you select the known working board version. Chose a higher version at your own risk.
You can see the strict requirements at wardrive.uk, they are as follows.
So, first up, the board type.
Next, the upload speed.
Then the CPU Frequency.
Then the Flash Frequency.
Then the Flash Mode.
Then the Flash Size.
Then the Partition Scheme.
Then the PSRAM.
Finally the last one, the Events Run On.
If you get any compile errors, read them carefully.
thebaldgeek got two sets of errors from missing files.
The two missing ones were:
https://github.com/adafruit/Adafruit_BusIO/blob/master/Adafruit_I2CDevice.h
and
https://github.com/adafruit/Adafruit_BusIO/blob/master/Adafruit_SPIDevice.h
Download the missing files and put them in the A and B directories.
You will need to copy paste those two Adafruit files to the B directory to take care of compile errors as well.
Ok, programming done. Finally thebaldgeeks favorite and fun part, soldering!
Slight deburr with a straight file of the side of the GPS was needed to better fit against the SD card board.
One thing to note that tbg has not seen mentioned anywhere on any of the wardriver.uk or SS pages is that the GPS has 3.3vDC on the antenna socket. So you should use either an active antenna or an antenna that is NOT a DC short.
Back to the build.
You can see its a tight fit between the GPS and the SD card, but just removing the burr from the edge of the GPS is all that is needed for a night flush fit.
Removing the pin spacer after the pins are soldered helps drop it closer to the main PCB.
Installing the antennas and keeping them straight while soldering the sockets ensures a nice neat final look on them.
The kit soldered together really really well.
Its a quick clean build with zero issues along the way.
Last thing to do....
Plug it into a reader and into your computer.
Make sure its formatted to FAT32. No larger than 16Gb.
Make sure its blank.
Right click (on Windows) and create a new txt file.
Name it `cfg.txt`.
Edit the file and add the following.
sb_bw16=yes
tbg did not want the Signal Sleuth spinning up a softAP (software Access Point) every time it booted.
He also did not want it connecting to his home wifi as that also would have caused the SS to transmit.
tbg wanted the SS to be as close to receive only as possible (for reasons to come depending on its wardrving performance).
So tbg added the following line under that last one...
block_reconfigure=yes
This disables that whole first time bootup and disables the 1 minute softAP timer.
On power up, the SS will see this option and drop straight into passive wardriving mode.
Ok, drop the SD card into the Signal Sleuth and go for a drive!
Horrible placement, but will do as a rough proof of life....
The Signal Sleuth is in the game.
The Hydra, as expected for a long time, is just not acceptable by any benchmark.
Something to keep in mind when mounting in a case or car roof top mounting the unit.
More updates to come as tbg starts really logging the miles with the SS.
Comments
Post a Comment