Displays Arrived. Production Plan and New Features

Displays Arrived. Production Plan and New Features

Good news everyone! The LCD displays have finally arrived. This means that we now have all the components necessary to start mass-producing Flippers. We have 60000 screens, enough for all the devices backed on Kickstarter and for some part of the pre-orders made on our website. Here's what we've been doing while we had to wait for the screens and the latest production and delivery plan.

Boxes full of LCD displays for Flipper Zero

We are now making about 150 devices per week, but the production line will achieve a few thousand devices per week in a month. More on the production plan and estimated delivery time at the end of this blog post.

What's new?

While we waited for the necessary components we kept working on the firmware non-stop. Flipper's firmware is receiving updates, bug fixes, and new features every day. All the firmware commits are logged in our GitHub repo for everyone to see.

More than 30 people are working on Flipper Zero full-time. A tremendous amount of work has been done already, and there is still a lot more to do. Here is what we've done, as a brief review:

  • Wrote over 90k lines of code
  • Completed more than 2000 tasks in Jira
  • 85% of all the advertised Flipper features are working
  • We've got the first app prototypes for Android and iOS
  • Our desktop app qFlipper is available for Windows/macOS/Linux
  • For 20 hard-to-get electrical components, more than 60 alternatives were selected and tested (THIS WAS A REAL PAIN)
It's over 2000!

In addition to development we've been dealing with a lot of other tasks: logistics, accounting, certification, financial planning, procurement, organizing production, testing, packaging, customs declarations and permits, searching for alternatives during the component crisis, and negotiating with the suppliers. We've got a real dream team that handles all this load. Thank you all for the work done in these difficult circumstances.

New Sub-GHz features

Our new Sub-GHz app can decrypt signals from more than 50 different keyfob manufacturers, and it's constantly being extended. We hope that with the help from the community, we will have the most complete open database of radio protocols from different manufacturers.

Frequency analyzer

In order to be able to receive a signal you first need to tune the receiver to the required frequency. But what if you don't know the frequency that the keyfob is working on? To help you with that, we have the frequency analyzer feature added to Flipper. It scans all available frequencies and displays the one that has the strongest signal nearby.

[Video] Frequency Analyzer demo

Of course, this feature can't replace a full-fledged frequency analyzer. The results displayed may be inaccurate and there is always a certain margin of error, but it will be able to tell you the frequency range you need. Most often it's one of the channels from a popular 315/433/868 MHz band.

Signal interception

The main subjective of our Sub-GHz subsystem is to analyze the signals it captured. And right now the signal interception feature has become really powerful. You can easily find out the protocol for a particular keyfob and have the decoded signal displayed immediately. The lock icon shows if the protocol is encrypted or not.

[Video] Signal interception demo
You will need to have the databases on the SD card for this to work.
Flipper uses cryptographic keys and manufacturer codes to decrypt dynamic protocols. These files are automatically installed on the SD card with the rest of the databases during firmware upgrade. You will need to insert an SD card and update the firmware with qFlipper or Web Updater to get the latest data.

Capturing RAW signals

There may be cases when Flipper isn't familiar with a certain protocol, but even in this case it still can capture the raw signal. This feature allows recording all the signals and dumps them straight to the SD card without trying to process anything.

[Video] Recording RAW Sub-GHz signals

The recorded signal can be replayed right after the recording, or it can be saved for further analysis. This way you can capture even those signals that aren't recognized by Flipper yet and work on decyphering them with the community.

Flipper is not an SDR!
Let's not forget that Flipper's radio is not an SDR, so in order for the "Read RAW" feature to record the signal correctly, you need to know the exact frequency and modulation beforehand.

Wild BadUSB appeared!

The BadUSB is working! We've spent a lot of effort on the USB HID mode and on switching it back to normal mode afterward. This feature is now stable and reliable.

The scripting language for BadUSB is compatible with Rubber Ducky Language, so you can reuse the scripts that are already available for USB Rubber Ducky and other such devices.

[Video] Flipper mimics a keyboard and inputs a sequence of symbols

Right now our BadUSB is still a prototype with no GUI, but it'll be finished soon. We plan to have a couple of demo scripts bundled with the firmware with safe actions such as opening the notepad and the calculator for all operating systems.

USB <-> UART bridge

Thanks to Flipper's GPIO you can use it as a universal USB bridge for a variety of industrial protocols. Right now we implemented the UART as the most popular protocol, the de-facto standard for debug ports and hardware consoles. You won't need a USB-UART adapter anymore if you have a Flipper.

This mode supports DTR/RTS pins as well, so you can flash devices like ESP8266/ESP32, which require flow control signals in addition to the RX/TX data lines.

[Video] Reading the Linux console on an Orange Pi in UART adapter mode

The USB Serial interface you see is still a draft, but soon the user interface is going to look like this:

The new USB->Serial UI

This mode has several options available:

  • COM Port — the virtual USB COM-port to use. When choosing 0 (CLI) the main Flipper console will be used. When choosing 1 a second COM-port will be created, with the main OS console still available on its original port.
  • Baud rate — determines the UART speed. You can set it manually depending on your device, or switch to Host mode so that the baud rate will be chosen automatically when connecting to the port in tools like screen or minicom
  • UART Pins — Flipper has two hardware UARTs on pins 13,14 (USART) and 15,16 (LPUART)
  • DTR/CTR — the pins for the flow control signals. Since they are implemented in software, you can choose any digital pin on the GPIO

The new qFlipper

qFlipper — is a cross-platform desktop tool that can be used to update firmware and the databases, create backups, and a lot more. It is Qt-based and works in all the popular operating systems: Windows/macOS/Linux.

It's being actively developed right now, but you can already update the firmware, the radio core, and the databases.

[Video] qFlipper Firmware update process

Flipper Protobuf RPC

Flipper now has a Protobuf RPC API, available both through USB, and Bluetooth LE. This protocol is used when updating the databases on the SD card and for any other external interactions. For example, you can stream Flipper's screen using this protocol:

[Video] Screen streaming over Protobuf with ASCII/ANSI rendering

In this demo, the graphics are rendered using symbols right in the terminal, similarly to the programs that use ncurses. This means that such screen streaming can be used without any GUI at all, for example through SSH.

We've prepared a high-level library in Go for convenience, it allows you easy access to Flipper's API. We hope that implementations in other popular languages will soon follow.

The components of suffering

Due to the crisis, we had to replace the already tried and tested components on the go. We've replaced about 20 components in total. At times it was easy, but there were other times when the PCB had to be redesigned. This was quite an ordeal, because some components had a surprise in store, baffling us with things unforeseen. Here's one that was a particular source of irritation. There were actually a lot more of them, but let's showcase this one.

The power struggle

This one brought us a lot of pain. In one of the previous blog posts, we've noted that we have trouble buying the DC-DC converters. So we had to switch to an alternative. For example, we've switched TI TPS62743 for a TI LM3281YFQR.

Judging by the datasheets alone everything should fit perfectly. We tested it in actual device circuits, and when we were about to approve the new design, it turned out that Bluetooth LE starts misbehaving under certain conditions. The insidiousness of this problem lies in that it couldn't always be reliably reproduced in tests at first.

It turns out, that 3.3v line pulsations were to blame. Despite the fact that there is nothing in the STM32WB55 datasheet about pulsations disturbing the operation of the CPU. Here's a thread on the ST forum about this issue: Power supply ripple/pulsation causing BLE TX to fail

This is the problem itself and the solution on the oscillogram:

The problematic power spikes (in red) and the same spikes after a filter (in yellow)

The red line shows the output signal from LM3281 in ECO-mode, that matches the datasheet completely. You can see pulses in the range of 40mV. This is completely normal for this microcircuit and is not a problem in itself. However, during testing, it turned out that if the rising edge happens to be faster than 6mV/us it breaks Bluetooth LE. In yellow you can see the signal we've achieved after a little refinement.

We had to deviate from the LM3281 datasheet: we've managed to pat down the spikes by worsening the Q factor of L14 in the LC-circuit by the means of additional resistance; and we've also added another LC-filter, to distance ourselves from the value that caused so much trouble.

Stable subsystem work and the resulting power consumption was our top priority. If you worked with LM3281 you may want to bring up the question of PWM-mode that this chip supports having no pulsations. Unfortunately switching to PWM-mode had to be discarded early on due to additional power drain and lack of guarantees from ST that this problem only affects BLE.

Our solution to power pulsing on the LM3281

Wi-Fi Module

The first version of the developer board extension was based on the ST-Link V3 module, which is currently not available for purchase. We have been negotiating with ST for a long time, hoping to get 6 thousand of these boards ordered by backers, but so far it seems that this module will not be on sale for a long time.

We got out of this sticky situation by designing a completely new board based on the ESP32-S2. It also allows debugging Flipper with Black Magic Probe software, which was updated by our developers to support Flipper Zero.

ST-Link Devboard will be replaced with Wi-Fi Module

Thanks to onboard Wi-Fi, the board can handle a much wider range of tasks and is now useful not only for developers. After all the backers' orders are shipped, the board will be available in our shop. Don't worry if you haven't ordered it in BackerKit.

A prototype of the Wi-Fi module, which will replace ST-Link devboard

Production Plan

We have officially entered the MP (Mass Production) stage with our factory. Within 4 weeks, the production line will reach a capacity of 1k units per week and will gradually increase to 10k units per week.

Shipments to backers will begin in December. Due to the complexity of logistics, we need to accumulate a certain volume of parcels for import to each specific country. This is due to the limitations imposed by the logistics broker. We expect to ship most of the backer orders by the end of January.

The screens are now covered with the proper protective film

Stay Tuned

Our social media subscribers get all the Flipper Zero news first! Join in and get access to sneak peeks, insides, and more.