I had some UI enhancement suggestions I figured I'd mention now that I have a working ESP32-C5 card.
1. Right now it shows the channel and hit count in the top right, but also on the 2nd line. Double information, one could go. Being that channel and hits is relatively fixed size (channel I'd pad out to be a fixed size, hits would likely be 3 digits or less), I'd say keep the top line and remove it from the 2nd line. This frees up room to prevent text overrun. I can't tell if there are spaces between Flock and "/" and ALPR, but they could be removed to save 2 characters. I'll also note that this is inconsistent with how the flipper wifi dev board's UI reads:
<img width="198" height="50" alt="Image" src="https://github.com/user-attachments/assets/47c7e816-0b99-4d93-ae8b-ed15e5f889c9" />
(and I get why, you get less info back on that board so there's less to display, but figured id mention it since it doesn't have a text overrun problem)
2. I'm guessing the G at the end is if the GPS is working or not. I turned it on and left the rest of the settings in place, but never determined if it worked or not since text clobber. The other flock app I used (<img width="235" height="110" alt="Image" src="https://github.com/user-attachments/assets/089b3ae6-915e-4328-8e2c-a506afe64497" />) did a GPS item which was not filled in when it didn't have a lock, and filled in when it did. That was relatively self explanatory, just an idea. You could always shorten it to "G" with the background color idea for space.
3. The detection method is heuristic (OUI, SSID, hidden SSID, etc), however that isn't exposed to the user. Here's a possible hit I got:
<img width="199" height="121" alt="Image" src="https://github.com/user-attachments/assets/951fd5ef-506d-43db-a088-90d81573cc59" />
<img width="216" height="125" alt="Image" src="https://github.com/user-attachments/assets/04dbb067-4ded-4887-91af-579b3ceda0b3" />
What made it a possible hit? I would guess that because it was SSID it was a wifi hit (logical). I see it mentions beacon, so my guess is an SSID beacon for a SSID that fits the regex. However I'm not exactly sure. So here's my suggestions: 1) add a "MAC:" label to the mac address since SSID has one. I'd make RSSI its own line and RSSI a label, plus add the standard wifi strength bars for easier understanding by most users. Same for CH. I'd add a new line that says "Method: " and have it be OUI, SSID Beacon, Hidden SSID Beacon, etc. This gives more context to the "possible" label. Then move the "Seen 1", which I assume means how many times that camera has been seen, to its own line. Seen is kind of a funny word there, more like "times seen" or "observations" but those are too long. I asked ChatGPT for a better word recommendations and none were very good to be honest. I'm also guessing my GPS didn't work, but I'd add that line as well.
Summary of 3:
Old:
```
Possible
Flock / ALPR camera
3C:91:80:XX:XX:XX
SSID: 3CXXXXXXXXXX
RSSI -82 Ch 13 Seen 1 via be
acon
```
New:
```
Flock/ALPR Camera
Method: SSID Beacon
Seen: 1
MAC: 3C:91:80:XX:XX:XX
SSID: 3CXXXXXXXXXX
RSSI: <insert standard wifi signal strength graphic here> -82
Ch: 13
GPS: Unavailable (or -100,100)
```
4. Make a setting that is a minimum alert level for notification (beep/vibrate). I've only ever seen possible hits, and I'd like to alert on those since that's all I see, and this would enable that. You can set the default to what it currently is, but allowing me to change it will allow me to know.
Lastly, looking back through my screenshots to make these suggestions I have some questions. On one trip (July 27, flipper wifi card with marauder) i had 2 hits that weren't saved because it was prior to that update:
```
p 70:C9:4E:XX:XX:XX *0dB
p XXXX-XXXX *<signal strength meter>
```
tonight I had:
```
p 3CXXXXXXXXXX -82dB
```
My guess is that if its a wifi hit it shows the SSID, and if its a bluetooth hit it shows the mac address since that seems logical? I'm also seeing a mix of the last field between db and signal strength meter. I think strength meter is the better option since it takes less characters and the average user understands it better.
On it! I've been so deep in the trenches of ensuring that a hit is always 100% correct that I zoned out from the UI/UX lol and the current one can definitely use some work,. Expect all these suggestions implemented in the next release 🥇
All four are in [v0.49](https://github.com/ReconGrunt/FlipDeFlock/releases/tag/v0.49). Thanks — this was a genuinely useful report, and the screenshots made it easy to act on.
**1. Duplicate channel/hits.** Fixed. Each counter now appears exactly once: channel and hits in the title bar, `frames` on the line below. The channel is width-padded so it stops jittering as the sweep hops, and `FLOCK / ALPR` lost its spaces. That freed width is what stopped the rows overrunning.
**2. GPS.** Now a badge like you suggested — a boxed `GPS`, filled with the satellite count when locked, hollow while searching.
**3. Method.** This was the best catch. The detail screen now says which indicator actually matched:
```
Possible MARKED
Flock / ALPR camera
Method: OUI + beacon
Seen: 1
MAC: 3C:91:80:11:22:33
SSID: 3C9180112233
RSSI: -82 ▂▄▆█
Ch: 13
```
Your screenshot was exactly the `OUI + beacon` case — a `3c:91:80` beacon whose SSID is just its own MAC. Nothing about that name is a Flock pattern, so the OUI prefix was the only thing that put it on the list, which is precisely what you couldn't tell from a bare "Possible". Other values are `SSID + beacon`, `BLE mfg ID`, `IE fp + probe req`.
It's re-derived locally from the stored MAC/SSID/fingerprint rather than taken on the companion's word, so it can't inherit an over-claim from firmware that lags the app. If nothing this side can re-derive matched, it says `ESP probe rule` rather than naming an indicator we don't have.
Also took the `MAC:` label, RSSI/Ch/Seen on their own lines, and the real signal bars. The whole screen is a proper view now instead of a text blob, so no more `via be` / `acon`. I kept the confidence rung on there — `Method:` explains it rather than replacing it.
**4. Alert level.** New Settings item: `Any` / `Likely` / `Confirm`. Default is unchanged at Likely-or-better; `Any` is opt-in and will raise false positives, which is the trade you're choosing. Your reasoning was the deciding argument — an alert you can't switch on isn't an alert.
**On your closing questions:**
Yes, your reading is right — the row shows the SSID when there is one and falls back to the MAC when there isn't. That's not Wi-Fi vs Bluetooth as such: a hidden AP and a probe request also have no name, so those show a MAC too (tagged `[hid]` when we watched it beacon without one).
The dB / meter inconsistency you spotted was a real bug, and thanks for flagging it. The bars helper was hardcoding black, so on the selected (inverted) row the bars rendered invisible and the list quietly fell back to `-82dB` text — one screen showing two notations for one field. It now inherits the row colour, so it's bars everywhere, and I agree the meter is the better default. Exact dBm is on the detail screen.
The `.fap` is on the release. No reflash needed — the companion firmware is unchanged.
Gave the new version a try. Transferred over bluetooth through companion app (first time doing that) and got this:
<img width="393" height="415" alt="Image" src="https://github.com/user-attachments/assets/3111b31b-3895-4bed-aebe-ebb2070aac4d" />
I'm on roguemaster latest release as of 7/29. I wouldn't think that you added too much memory to the app, so maybe there was an issue with the file transfer. I'll try it again later
I'm actually working on optimizing it right now, I ran into the same issue a few times. It's currently riding on the edge of the memory limit. Also make sure you're running v0.50, its the most current and is more lightweight than v0.49.
Not sure if it would help with memory, but the wifi audit seems like it should be its own app, not part of deflock. Netguardian arguably should be its own app as well.
Updates while using 0.50 (or maybe 0.51, i downloaded near your release time and wasn't paying attention).
<img width="259" height="345" alt="Image" src="https://github.com/user-attachments/assets/7adc3272-20e8-42ae-b6d5-c1d8416b67c4" />
I tried out the lock in mode, works amazing. exactly what i had in mind, tested it against 2 cameras and worked perfect.
These are `!` level hits. I have flipper set to `beep+vibrate`, and `any`. However, I got no notification on either so I think that isn't working.
GPS doesn't work. I believe the problem is the app wants to know what pins, however its "built-in" to the board. I tried pin 13/14 since thats the main tx/rx and it didn't lock in either. Maybe it needs to be embedded into the companion and have a new option set.
The new detailed display is great, all the info I would want, including a save date which was extra but good to know.
Of note, when I was originally comparing this app + marauder flipper wifi board the hits on these two locations were iffy. Sometimes it would find them in a minute, sometimes it wouldn't in 5. The other app + esp board would find them near instantly. Now these came up near instantly, and consistently. So that par is great!
Almost 30 hrs of straight optimizing! I'm fixing a few things and making the scans work a bit better than before. GPS should be working now and the polling should be sufficient enough for wardriving. The work doesn't stop here though 🧑💻
You were right on both counts again man.
Alerts were fired from each screen's own timer, and the Locator installs its own timer, so on the exact screen you were watching nothing ever went off. Fixed in v0.52, it comes from the app now so every screen behaves the same.
GPS too. There was no way to use a GPS wired to the ESP, because the pin setting was for the Flipper's own header and that isn't connected to your module, so no number you typed could have worked. v0.52 adds a GPS source setting: set it to Companion and give it the ESP pin the GPS TX lands on (try 13, then 14). You need to reflash the companion, the relay is new firmware.
While in there I found the companion was throwing away every GPS sentence that arrived during a BLE scan, which for wardriving is most of them. It scans in one second slices now and reads GPS between them.
Also two flasher fixes, one of which meant some boards could never flash over UART at all.
Fair warning on the GPS: I have no GPS on my ESP, so I tested the relay with injected sentences rather than a real module. You are the only person I know of with the actual hardware, so if you get a chance to try it I would like to hear either way (no pressure)
To be honest until I get my hands on the next shipment of boards I won't really be confident about this feature but 13/14 should work. If not, please let me know and I'll try a few things out.
I was wrong about the pins, its going to be 15/16 for your setup. 13/14 is only for the ESP32 itself, not its modules/
Did you turn relay on in the settings?
It's off by default and has to be on. It sends a serial command telling the ESP32 which one of its **own** GPIO pins the GPS TX line.
> I was wrong about the pins, its going to be 15/16 for your setup. 13/14 is only for the ESP32 itself, not its modules/ Did you turn relay on in the settings? It's off by default and has to be on. It sends a serial command telling the ESP32 which one of its **own** GPIO pins the GPS TX line.
Turn relay on in settings? I don't see anything that mentions that
It's in the README but **Settings → GPS From** and **ESP GPS Pin** are menu items inside FlipDeFlock's settings. Make sure the companion FW is v.052+ to turn Relay on.
I'll post a picture later of the settings if needed.
Here's a rundown of my settings. I did a fresh companion flash this morning and 0.52 upload, even though I should be there already.
Board mode: companion
Esp port: usart 13/14
Esp baud: 115200
Marauder cmd: probe req
Gps: on
Gps from: esp32
Esp gps pin: 16
Gps port: lpuart 15/16
Gps baud: 115200
Went for a walk, 10min in still no gps signal.
Ps, for the UI I need a way to remove false positives from my list. Prior to making them persistent you would just back out and restart the scan. Now that I keep persistent entries, I cant remove them. Can you add an option in details with a confirmation to remove.
Pps, not sure there's enough room, but it would be cool if there was either a Bluetooth or Wi-Fi icon next to a hit on the flock page, maybe details page too. Since oui could be for either. Rssi would likely be for both as well, so I guess ssid would be the only way to know which technology was the diff. But one small icon would make this info quick to see
Hmm okay. Let me see whats going on. My new C5 is arriving this weekend which will make things easier. Your Flipper-side pin setup looks correct: the ESP/Marauder connection is on USART 13/14, while GPS/NMEA is separated onto LPUART 15/16, so those two UART paths should not conflict.
The ESP GPS pin: 16 setting also sounds correct if the board forwards GPS/NMEA data from the ESP to the Flipper’s GPIO 16 RX line. Since it still has no fix after an outdoor test, I’d check whether GPS power/enable is active, whether the board’s ESP-to-GPS forwarding pin is actually mapped to 16, and whether the GPS module itself is outputting NMEA. From the settings shown, I don’t see an obvious Flipper pin conflict.
Both your suggestions are in [v0.53](https://github.com/ReconGrunt/FlipDeFlock/releases/tag/v0.53).
**Delete:** on the detail screen, Left brings up a confirm showing the MAC, OK removes it. Writes to hits.csv right away so a battery pull won't undo it. It removes the record, not the device, so anything still in range shows up again on the next sighting.
**Icon:** every row now has a Wi-Fi or Bluetooth mark, detail screen too.
**GPS:** I think it's your baud. You have GPS Baud at 115200, and that value gets sent to the ESP as your GPS module's baud, not the link speed. Most modules are 9600. Try that before changing pins. Also GPS Port LPUART 15/16 does nothing when GPS From is ESP32, so ignore that one.
I checked pin 16 against a tri board here and the companion accepted it and replied fine, so your firmware is almost certainly not the problem.
The bigger issue is you had no way to tell any of that apart. The companion reports its GPS state back and the app was throwing that line away. Next release adds a badge that says which thing is wrong, wrong pin versus wrong firmware, instead of sitting on "searching" forever. This should make debugging much easier.
If you want to test without hunting for a camera, there's `tools/flock_emitter` in the repo. Spare ESP32 sketch that cycles through each detection rung including the Flock-Guest false positive. It transmits, so bench only, on a board you own.
.fap only, no reflash needed.
Gave the lower baud a try, still no go. Delete works great, icons look good. Still not getting alerts (sound/vibrate) though.
For gps at this point prob worth just waiting. I have a bunch of wifi false positives I'd like to share and get your opinion on in a less public space. I sent a discord friend request to this name if that's your account
Regarding false positives, I'm actually working on a way for user's to anonymously share logs that get stripped of personal identifiers and aren't linked to a username upon submission. This will go hand in hand with a Discord for the community, just want to be sure most of these silly bugs are smoothed out before focusing on that.
p.s. that user isn't me. ill drop the discord into the .readme tomorrow :)
Believe I may have found a new bug (sound still not working, that's the only one still open).
I had flock running in a college town, and I noticed it flash up a deauth. I was intrigued, so I switched to the pwnagachi screen for net guardian. We left so I went back to flock and now my found devices are all gone. Did a reboot of flock and the device and they won't come back. Maybe net guardian overwrites that list?
> Believe I may have found a new bug (sound still not working, that's the only one still open).
>
> I had flock running in a college town, and I noticed it flash up a deauth. I was intrigued, so I switched to the pwnagachi screen for net guardian. We left so I went back to flock and now my found devices are all gone. Did a reboot of flock and the device and they won't come back. Maybe net guardian overwrites that list?
Thank you for bringing this up. All the more reason to make FDF completely standalone but keep Net Guardian for the security.
Just so I don't forget, here's what I'm going to knock out. Please feel free to add anything you feel is missing.
• Fix audio not working
• Address NetGuardian overwriting FDF devices with a solid backup as well. i don't want you losing logs out in the field again. bashing my head that this wasn't caught earlier by me...
• GPS is still inactive on the C5 board even after lowering baud.
• Private community for discussions and development
• add a stable release and nightly release so that there is always a working fallback (bashing myself even harder for being late on this)
Up Ahead: will be adding an option to add a 2nd ESP32 companion which will run NetGuardian on it or run additional FDF scanning while acting as a standalone node. having it connect to FDF so they work as one is the only minor roadblock that requires an elegant approach.
Happy Sunday and thank you as always.
Expect a release today with the important issues fixed.
P.S this issue thread will be converted into a discussion which I'll integrate with discord if possible.
These all sound like great additions and I appreciate all the rock you're putting in to this!
I drove around today in a new area and wasn't getting many hits. Went to a business that partners with flock and parked next to 3 different cameras and no hits.
<img width="1178" height="1573" alt="Image" src="https://github.com/user-attachments/assets/fcb62799-b248-42bc-af38-7f94f06ae7d3" />
You can see the camera in the background. Maybe these weren't detectable, but it makes me wonder if ble was working correctly or not. Typically ble is the easy one to get on these. Maybe we need a count or indicator to show ble is working correctly.
I'm addressing all the issues right now, apologies for the delay brother! UART0 on on the C 5 is GPIO11/GPIO12
Your screenshot helps more than you imagine because you're on ch132 which is 5GHz but ALPR uplink is 2.4GHz (C5 might be locked on "band all" which defaults to 5G if I'm not mistaken)
I'm working on that logic, will have a new release within the hour.
P.S. i was worried my idea of hybrid polling across multiple bands would cause some issues. my proposed logic is: if 5GHz has more activity then the app will scan that band first and then hop over to 2.4GHz or vice versa. If that doesn't end up working as intended or the results are less than optimal, then my previous idea of having a second node will get expedited: One node will run 2.4GHz and the other one will do 5GHz so nothing is missed.
I was thinking of some gui improvements.
Right now there's a packet counter, and it's good to see it going up to know things are working. However the count is arbitrary. Bluetooth, no idea if it's receiving or not. I was trying to think of a way to have 2 indicators show packets coming in or not. Maybe like a sliding window where no packets is ---- or ____ and then a packet would show a spike like ____/----\___. Then a second later its __/---\_____ . That would give you an idea if you see packets on a specific channel or not. Not set on the idea, maybe you have some ideas. Just throwing it out there. Pretty sure on a multi hour drive that number ticks over back to 0 anyways
STOP COMING UP WITH GOOD IDEAS I DONT HAVE ENOUGH COFFEE PLEASE AND THANK YOU. /s
Seriously, thank you for being so proactive. I'm working on adding that indicator for per channel yield right now. I'll get rid of the FLOCK/ALPR text, replace it with my logo/icon and that'll give us enough space for the packets coming in.
Also I'm just now realizing, where is your GPS module?
The ESP32-C5-WROOM-1 doesn't have built-in GPS from what I can see so if it's a 3rd party board, we need to know what pin out they used. (btw love the OG Флиппер sleeve and that 3D printed case is very well done!)
Still no beep/vibrate alerts on newest version.
Channel hops is now only 2.4, works significantly faster to cover the spectrum.
I assumed this board had gps because the other app I used had the darkened gps after a few seconds as if it had gotten a lock.
<img width="1440" height="1593" alt="Image" src="https://github.com/user-attachments/assets/5e4830e9-c54e-48c9-8fc8-e8bd7feb5714" />
This is also showing a gps lock, but all the new hits show no fix.
The new count system is better, I see ble packets but let's refine a bit.
Current:
```ESP rx35/s b490``` (15 characters)
What about
```ESP rx/s: <Wi-Fi icon> 35, <Bluetooth icon> 4``` (18 characters)
My count shows 4 spaces still open before clobbering gps. Potentially drop the spaces after the icons. May need to adjust ble to something other than /second based on rate TBH since the count may be too low to really show and end up being like .2.
Can you add the version number to the main menu, maybe FlipDeFlock v56 . This will make it a little easier to keep track of the version. Plenty of room there as opposed to adding to the about page.
Beep! Finally. That one had me stuck because everything in the code checked out, so I stopped guessing and added a **Test alert** at the bottom of Settings in [v0.59](https://github.com/ReconGrunt/FlipDeFlock/releases/tag/v0.59). Press left or right and it fires the real alert with your real settings. Should make it obvious next time if it's the app or the Flipper's own notification settings.
Version's on the main menu as of 58, and in About along with a thank you to you.
Header now shows `a<n>` for alerts actually sent, and `b-` when no BLE scan has finished yet so you can tell that apart from `b0` meaning it ran and heard nothing. Spaces dropped like you said.
Good call on the icons in the header, I already have wifi and bluetooth glyphs in the app from the row icons so I'll swap those in next. That buys back the width you were counting.
**GPS**: your board has no GPS chip on it. That's the whole answer, sorry man. The other app showing a lock was lying to you. Your pin was also wrong for a C5 anyway, 16 is flash on that chip. The board reports its own valid pins now but you'd need to reflash the companion.
Nice case by the way. Koko never disappoints!
I reflashed before confirming the beep. I look at the change log before flashing to know what to expect :)
Your app is also giving the dark gps! Icon, which is unexpected given the lack of hardware. But the hits report no fix correctly.
I think the next big push will be false positives. Im getting lots of false positive on wifi. Can't wait to discuss them later.
Thanks for all the quick improvements, this project is really coming along nicely
Oh man I can't wait to get my hands on some logs, those are going to be of great help as I haven't went out for a proper drive yet myself.
Currently I'm fixing the glyphs not looking right as well as those error messages like !PORT, !PIN, !FIRMWARE so they are easier to understand. At some point there will be a full UI/UX rework but detection accuracy is most important right now.
I added you to the in-app About section with a thank you note & cooking up an asset pack for you as well, will be packaged with future FDF releases 🥇
Catch-up:
- **Header icons** are in like you suggested. Reads `ESP [wifi]55/s [bt]490 a2` now.
- **Version on the main menu** and in About.
- **`a<n>`** counts alerts actually sent. Settings also has a **Test alert** at the bottom, press left or right to fire the real alert on demand.
- **`b-`** means no BLE scan has finished yet, as opposed to `b0` meaning one ran and heard nothing.
- **`GPS!` is gone.** You were right that it read like GPS was working. A filled badge is what the header uses for a lock, so anything starting with "GPS" looks fine no matter what's on the end. Faults now name what to fix: `!PORT`, `!PIN`, `!FW`.
- **New Help & Warnings page** in the main menu. Explains every mark the app can show, what to do about each one, and common fixes.
- **A GPS fault also explains itself on the scan screen** now, with the setting to change. OK dismisses it.
[v0.64](https://github.com/ReconGrunt/FlipDeFlock/releases/tag/v0.64) is current.
I added something into the asset pack just for you, hope you like it! (its a GIF of "h00die" kicking a camera pole xD)