What a cool device. Small word of advice to whoever maintains the FlipperZero website ("webmaster" in the old days): clicking on the logo on any of the Blog pages leads to the blog index, which is not terribly helpful for someone who – like me – landed on a blog article page and then was wondering what this was all about. It would make more sense if the logo, like the "Home" link in the navigation, consistently lead to https://flipperzero.one instead of https://blog.flipperzero.one. Same thing goes for https://shop.flipperzero.one fwiw.
This is a minor annoyance of mine across the internet. Usually on pages that are some kind of subsystem from the main site - i.e support pages, blogs etc.
Which ceiling fan remote? I've been fighting with our bedroom fan, we like the performance but the remote works maybe once out of every 100 presses unless I climb up on our bed and extend my arm into the middle of the fan housing.
I went into the weeds of reverse engineering my Minka Aire ceiling fans with a USB RTL-SDR. In my case the manufacturer's remotes worked fine, but I wanted to integrate it in with Home Assistant. If you're interested, you can see what I did: https://www.riveducha.com/decode-wireless-signal-with-usb-tv...
I used a USB RTL-SDR ($15) and a Raspberry Pi to receive and transmit, but I think the Flipper Zero can do it all-in-one.
Sorry, my wording was unclear. The USB RTL-SDR was for receiving, and I did the capture and analysis on my desktop. The Raspberry Pi was for transmitting using the GPIO pins.
Caution for other readers in the US getting an idea: the flipper zero can read radio fan remote signals, but the FCC doesn't allow it to transmit them. I was hoping I could have an "all the remotes" device with the zero, but radio is fairly limited. Perhaps someone will region unlock these.
The official firmware limits the device to only being able to transmit on frequencies officially supported by the CC1101 chip that handles this range. It's technically capable of transmitting across a wider range but the manufacturer of the chip doesn't support it.
Beyond that the official firmware also limits the available frequencies by the device's region setting. There is a full list of the regional limits here: https://docs.flipperzero.one/sub-ghz/frequencies but they are of course intended to limit the device to only frequencies legally authorized for unlicensed remote control type uses in the region in question. It should generally work for any household appliance remotes, as long as the appliance was designed for the region it's being used in.
Either way, there's a reason I started both of those paragraphs with references to the official firmware. The device firmware is open source and there are multiple community-developed forks as a result, some of which make these limits configurable by the user.
> It should generally work for any household appliance remotes, as long as the appliance was designed for the region it's being used in.
Unfortunately not, I've got multiple fans from different manufacturers that were sold at major US retailers (i.e., not purchased online) and I can read the remote's transmission but I'm region locked out of transmitting it from the flipper zero. Going to try out some of the custom firmware though, thanks for the details.
This is a good example of a problem that's easy to talk about but difficult to fix:
"tell CPU to sleep!" versus this whole lengthy article.
Wondering now if the issues with Linux laptop sleep are related or have similarity.
Linux should generally have no problem with CPU&al sleep, the problem is often devices around, waking up in weird orders or states, or not waking up at all, or not going to sleep.
> The furi_hal_os_sleep() function performs tick suppression inside the OS domain.
Reminds me that many eons ago I witnessed the introduction of CONFIG_NO_HZ in Linux, is it the default now? Combined with timer coalescing this makes for big energy savings.
It's a very common task in embedded development to need to reduce sleep or idle power consumption but in my experience it's never basic nor easy to do it right. Lots of times engineering teams just punt the issue and the customer gets less than great battery life or some other poor compromise is made.
Generally the hardest part is simply making sure that the device can wake up correctly and quickly enough under all situations. Also, tracking down unexpected power draws gets into a nice crossover between electrical and firmware design teams which can either be great or extremely frustrating for either side of that interaction.
Waking up from sleep is an endemic problem across devices. Just google "waking up from sleep" and you'll see all kinds of stuff for both Windows and MacOS. I'm not sure Linux has deep sleep.
I know it's been a problem on MacOS forever, like back in the 68k days. Some peripherals never come back from sleep and you have to power cycle them to get them to "wake up." And sometimes MacOS doesn't come back either.
On STM32 you typically need to go to STOP mode (called deep sleep in places) to get significant power savings. I had F0 and G0 waking up at 100Hz plus on pin interrupts (with maybe 30us latency) consuming 50-100uA (compared to maybe 20mA without sleep). I’m pretty sure you can do better on the WB since it’s actually a low power part, but it all depends on how complicated your software stack is. For example, to get the low latency wake up required only using the low level HAL and custom clock configuration.
Nordic parts are easier - they actually have low power sleep that is fairly automatic.
> Nordic parts are easier - they actually have low power sleep that is fairly automatic.
Came here to say this. Started with the STM32WB5x for a BLE project but got so frustrated with it so I switched over to NRF52. Never looked back. I love (and use) the STM32x for many other applications but the STM32WB BLE-solution is just too opaque with the (close sourced) BLE stack running on the secondary core while still requiring a lot of low level collaboration from the main application core. Would have been a lot easier if was more isolated and just provided a standard HCI interface or something. I suppose one could argue to use a dedicated BLE IC in this case.
Anyway, I'm very happy with the NRF52 I'm using. The events, tasks and peripheral interconnects is also a really nice feature. Documentation is stellar as well IMO. My main gripe with it is that it only comes with one UART port. Two would have been nice. Perhaps the NRF52 successors comes with more. Haven't checked really.
It's in line, I think it might seem high because there are well known microcontrollers which can deep sleep with µA-level current. For example, the ESP32 consumes 0.15mA if the the ULP processor is on, and 10µA if it's off.
I'm pretty sure the STM32WB can go as low as 2µA though. If I recall correctly it has STOP and STOP2 instructions, with the former being what FlipperZero is using and the latter requiring even less power. I think it's really complicated to manage the deeper sleep state and the radio with STOP2 though, and that might be why they stuck with STOP. (edit: whoops, they cover this and more in their write up)
The reason for that is because in sleep states what the MCU needs is only a small part of the whole - stuff like LDOs and DCDC converters also need some current and sometimes other chips are directly connected and take some power even when disabled.
For instance a very cheap 3.3v LDO I was using was taking about 1mA simply for being connected.
I am pretty sure this is a similar situation here and you can't go much lower with the current circuit.
Can this device really be of any use ?
I mean, is it just a beautiful gadget to play with antique tech that is not used anymore ?
Or can you really have fun and make it work on stuff you have at home or around you ?
I easily cloned access cards to the building of a club I'm a member of, as the company managing the security access went the way of the dodo. Granted, it's not a long term solution, but it's a stop-gap measure that allows us to use the facilities until the landlord replaces the system/company. Would I have been able to do that with my professional equipment at my office? Of course, but doing it in the field with a cute dolphin winking at me is nice.
I was able to show that one of my client's building access control is less secure than their lunch system, and for the NFC work I'm doing with some clients, it allows me to have a single device in my pocket with the 30 or so keys in use on the project instead of having 30 dongles in my backpack.
Cards that aren't vulnerable to this attack are 10x-20x more expensive.
I think it's great that a tool like this is being deployed widely into the hands of children (way better than chameleons/proxmark being in the hands of people who know what they are doing and everyone else thinking you're are a paranoid madman for knowing they exist), however it probably means that hotels are going to start charging you for not giving back your room key again before too long...
The only access card system I've personally encountered that my flipper can't copy is the one I deployed myself (modern HID iClass/Seos), specifically with attacks like this in mind, and the vendors still tried to encourage me to pick stuff that would have been vulnerable (this was ~7 years ago).
I was equally skeptical. I actually had two from the kickstarter and sold them at a con last year. Mostly because I didn't think I'd have the time or skill to really use them fully, but also because I live in Scandinavia and it seems like most of our security systems have evolved past simple radio and RFID.
Unless you actually swipe someone's RFID tag it has very little practical security use here.
But in other European countries I'm sure they still rely a lot on radio for gates and parking access.
Scandinavia here. Banks, pharma, industry, commercial buildings still use NFC for building access control. 25% of those use things modern enough to be easily cloned by the F0 (e.g.: not FireDES).
My underground parking sends a wireless signal to open the door after I've typed in my keycode.
Yeah but NFC is the same as RFID, you have to get close to swipe it.
Now the wireless signal to your garage door, that's a surprise to me. I don't even drive tho. I guess it might be fairly common when they want to save space by not burying cables from a keypad reader that is outside the garage.
It's kinda strange, I tried to sell my Flipper Zero and was wondering why people name them weirdly. As it turns out, ebay doesn't allow to sell it. If anyone has an idea where I can offer it (Germany, Europe), let me know.
I've been installing some home networking for the past year and made changes all over, meaning I have to install inline connectors everywhere.
These fail a lot, without warning, and it's hard for me to work out why. Kits like those provided by Fluke are REALLY EXPENSIVE and it got me thinking here... Can I use the Flipper GPIO to build my own network tester?
I would love to be able to test continuity, failures, and even do a 10Gbit line test.
It's worth considering pulling new cable. I don't know how many inline connectors you have installed but at some point you are going to have to grab some fish tape&pull rods...
You could definitely build a continuity checker with it, but that requires something on the far end to loop back the pins. The GPIO won't switch fast enough to act as a TDR though, that requires specific ASICs.
You could test simple continuity with a multimeter. The flipper has can generate nowhere near the frequency needed to test 10gbit Ethernet. Every time I've needed to use one of those fluke things, I've been able to rent one for a few grand. If this is in your home, I agree with the other comments, you should probably just bite the bullet and rerun everything.
I agree it would be nice, but if you wanted to make do with what you have, I wonder: since LoRa bandwidth is so low, could there be a companion LoRa device that connects to the FZ via BLE? Not as convenient, but again, I'm working with what we already have.
Yeah, I was surprised when I received mine that it doesn't have an "off" mode, by default. Granted, the battery lasting over a week is fine, but considering I only use it a couple days a week, it feels a bit wasteful. I might modify it and add an inline power switch. Who needs RTC anyway.
Settings -> Power -> Power OFF seems to be a real "off" mode. I turned it off like that a month or two ago and put the flipper back in the box. When I turned it on just now to get this update, battery was at 82%.
To me it just reads a bit like it was written by an ESL speaker - "starting the firmware version 0.82 ..." is a bit of a giveaway (should probably be "starting from version" or just "from version...", unnecessary "the" is a common mistake made when someone's mother tongue doesn't have articles).
ChatGPT doesn't tend to do this in my experience. But I should stress that it's still perfectly readable and a very minor mistake.
“We are proud to announce that starting the firmware version 0.82, your Flipper Zero's battery life will last up to 1 month! It took us 2 years to resolve all firmware issues that prevented Flipper Zero from switching to power-saving mode, resulting in the same power consumption baseline in both idle and active states. As a result, Flipper Zero's battery life was approximately 1 week instead of the intended 1 month.”
