https://befinitiv.wordpress.com/feed

This year Wifibroadcast has its 10 year anniversary! Time to gather what has happened since then.

This spring I was getting motivated to try out again FPV. So I dug out my almost 20 year old quadcopter with the good old Wifibroadcast and gave it a shot. It did not end well. Reason for it was that I completely lost the control link mid-air (using my Graupner Hott system). It was quite terrifying seeing exactly what is happening via the video stream while being completely helpless. I quickly put the quad back into storage and went shopping for a much smaller 2″ Pavo Pico Pro using ELRS. While waiting for the delivery I explored what has happened in the Wifibroadcast ecosystem in the past 10 year – this is what this post is about.

My research was a rather quick one and is definitely neither fully complete nor fully right. If you have some corrections/additions, please let me know in the comments.

Back in 2015 I entered FPV for the first time – and I was in disbelief. Back then everything ran on analog. I had a hard time understanding this. Why is everyone using 60 year old technology in 2015? Why is there no commercial product offering a digital alternative? Everything seemed to be there: Cheap digital radios, high quality video codecs and encoders in hardware, cheap CMOS image sensors. Therefore I “plugged” all these ingredients together and had a working digital FPV system. That was SO much fun, I really enjoyed the development of Wifibroadcast.

Somewhere around 2016 I stopped development on Wifibroadcast simply because other forks where much more active (namely EZ-Wifibroadcast) and I could not keep up with the pace of their development. I was quite happy to see that the community took great care of the project, so that was a happy “goodbye” for me.

From there I moved on to other (much less useful) projects and when I checked back in this year I did not expect great developments. Back in 2015 Wifibroadcast was the first digital video link and I expected it to become obsolete with commercial products from DJI and alike. But boy was I wrong. The Wifibroadcast ecosystem seems to be more alive than ever. I would have never dreamed of commercial products designed for Wifibroadcast to become a thing but here we are – I am so excited about this!

EZ-Wifibroadcast was one of the first forks of Wifibroadcast. It improved and extended my rather basic WBC images with lots of features and provided a really good starting point for tinkerers. The amount of improvements is impressive and I think this image gave Wifibroadcast a good initial push into the hands of more users. Unfortunately, development stopped seven years ago.

DroneBridge seemed to be quite an ambitious project that also unfortunately seems to have stopped development 4 year ago. It was intended as an all-in-one package which does RC link, video link, telemetry link all together with a custom Android app.

OpenHD seems to be one of the most active forks of Wifibroadcast. They as well deliver the “full package” of air unit plus ground station software. The hardware support seems to focus mostly on the traditional SBC setup, which makes it a bit bulkier than more integrated hardware solutions. But since they anyhow seem to target more traditional larger aircrafts and not so much super micro racing drones that shouldn’t matter too much.

What I really like about OpenHD (and something I regret to not have included in my original Wifibroadcast license terms) is their explicit prohibition of military usage of their project. Wifibroadcast was always intended as something to bring people joy not harm. So both thumbs up to the OpenHD team for making this explicit!

FPV_VR was an Android app that forked my very primitive app and made it into something gorgeous. Decrease in latency, a fully featured OSD, ease of use. Unfortunately, this app also seems to be discontinued. Question to better informed people: Was it merged into the OpenHD app?

FPVue is in my opinion quite a game changer when it comes to the receiving end of Wifibroadcast. Apps like FPV_VR required h264/h265 video stream via network as an input. The issue is: How to you extract that from a Wifibroadcast air signal? The typical approach is to have an SBC with a suitable wifi card that receives the packages, does the Wifibroadcast decoding and forwards that decoded stream to the Android app. This is a bit cumbersome because you still need the SBC with its power supply and cabling to show an image on an Android device. FPVue was able to get rid of all this extra hardware and allows to directly connect a wifi card to the android device via USB. How is it able to do this? Pure magic The app actually implements a user space USB driver for the wifi card. I was really blown away by this fact. Additionally, it also ported wfb-ng to Android so the App is able to do everything on its own: Receiving wifi frames, unpacking them with wfb-ng, decoding and displaying the video. Great stuff!

FPVue seems to be unmaintained since one year but luckily the OpenIPC ecosystem stepped in and forked it into https://github.com/OpenIPC/PixelPilot , which is actively maintained and extended.

WFB-NG is a fork of Wifibroadcast that is very similar in terms of scope to the original project but improved it in many ways. Instead of stdin communication it uses UDP packages. Together with RTP this seems a reasonable decision for lowering the latency. The issue with stdin is that this method uses NALU headers to split individual image frames. But… this header is appended to the start of the frame. So to detect the end of a frame you need to wait until the NALU header of the next frame. This adds one frame of unnecessary latency. RTP however does not use NALU headers but wraps the frames using RTP protocol flags. This way you actually can tell the end of a frame when you received the end.

Besides that it added encryption, proper support for distributed usage, etc. So many improvements, too much to write all of them here. Another important work also being done by the same group of people is the development of drivers for the “default” cards RTL8812AU/EU. This work appears to me to be the common backbone of many Wifibroadcast based projects. It might not have the visibility to the end user it deserves but nevertheless is a very important contribution!

OpenIPC makes lots of headlines recently so I also had a look at what they contributed to the Wifibroadcast world.

The OpenIPC project started as an alternative firmware for surveillance cameras. Typically, you can buy these hardware modules very cheaply from China and they come equipped with some proprietary firmware of varying quality. OpenIPC positions itself as an open alternative firmware solution for these cameras. One issue I am having with OpenIPC is that the main streaming application is not open source, which contradicts the name of the project. The main selling point of the project is “Replace your China binary blob with something open” but I think most users of OpenIPC are not aware that the reality is more like “Replace your China binary blob with a Russian binary blob”. Hardly an improvement.

On the plus side they also seem to offer alternatives to Majestic but not as a default. I don’t quite understand why they actually need separate projects instead of just releasing the sources of Majestic but hey, at least there is some kind of open alternative.

Coming back to the contribution they made to the Wifibroadcast ecosystem, I think it is huge. They had already much experience in using IP camera hardware and repurposed this HW to be used also for FPV. And in my opinion the IP camera hardware is almost a 100% match to the requirements of an FPV system.

The SBC based hardware I used originally works ok, but is certainly not optimal for the task. The CPU tends to be a bit overpowered, has lots of unneeded peripherals like a GPU, HDMI out, etc. The PCB design requires external memory chips, many boards also have a USB hub, PCIe lanes, SATA, Ethernet, … all these things add cost, complexity, weight and size.

Compare this to the typical IP camera hardware: A moderately powerful CPU, no GPU, no video output, a powerful ISP/video pipeline, image sensor + SoC on one single board. And these things are produced in millions each year and are therefore much cheaper than SBC+Camera. Other advantages are POP memory, meaning that these SoCs often come in QFN88 packages. Custom PCBs for these chips could be designed by toddlers… And nor-flash for storage is also nice compared to SD cards which are typically used for SBCs. All in all these systems seem to me like a close to 100% match in terms of what you want for a Wifibroadcast system. Small, simple, cheap – almost perfect.

This nice fit has also caught the attention of several companies that now offer IP camera based systems specifically made for being used with some Wifibroadcast-based firmware like OpenIPC and RubyFPV. This is really a major leap forwards from lots of soldering, flashing, modding to simply being able to buy these tiny systems off-the-shelve. I did not yet try these out by myself but they look really nice, I was very happy to learn about these.

Typically, these systems use IMX335 or IMX415 sensors. These are the usual candidates for surveillance camera applications and if configured right, they can deliver quite good image quality. Looking that the footage from people using these systems it seems as if the firmware still require lots of image pipeline tuning. I suspect that they either need to enable multi-exposure HDR or that the tone mapping is not tuned quite right. You can see this quite often in shadowy areas that tend to drown completely in black like for example here:

This is likely an issue of the tone mapping or missing HDR. The chips that these systems use, Sigmastar, actually have a “dark tone enhance” feature that would solve this issue. But… thank to “majestic” being closed source this cannot be solved by the community.

Also, the color tone of the images seems to be off, they look a bit like images from toy cameras. I suspect that the Bayer filter gains are not tuned properly. Maybe this is also due to white balance and saturation issues but this distinctive green tint of the images often comes from Bayer gain mismatches:

For my drone I’ve built a custom Wifibroadcast VTX system (not based on OpenIPC/Ruby/OpenHD, just bare-metal buildroot with a custom streaming application) which also happens to use an IMX335 sensor (but different SoC compared to OpenIPC). With just some moderate tuning of the ISP the images already look so much better:

For reference here is the video from which I took these snapshots (switch to 1080 for close-to-actual quality). The video shows the live downstream:

Parameters of the stream: FHD H265 @ 8Mbit/s

An improvement you could easily realize with IP camera hardware: A low resolution fallback video stream. Most of these SoCs allow you to en/decode several streams in parallel. So you could have one main stream in nice high resolution and high bitrate and a second stream at very low resolution and low bitrate. You would send and decode both streams in parallel and whenever the receiver detects corrupted data in the main stream it would switch to the low resolution second stream until the end of the GOP. This way the typical quite disturbing Wifibroadcast video artifacts could be replaced by simply switching to a lower quality stream. This would be much less disturbing and would lead to better user experience.

Also, I noticed that for the OpenIPC-hardware you need an Ethernet adapter to access the system. This is quite annoying, you tend to forget these adapters at home when you go flying. If only these systems would have Wifi… wait a second – they do! Only issue is that the Wifi card is configured in monitor mode which prohibits normal usage as a client or as an AP (via hostapd). But… Wifibroadcast does already send and receive arbitrary 802.11 frames. So in theory it should be possible to develop a very primitive hostapd equivalent that is able to spawn an AP on a monitor interface. We’ll see, maybe I’ll find some time to hack together something like this in the near future

8GB of music data on an 8cm optical disc? WOOW! At least in the year 2000 you would have said “wow”. Today it is nothing but a joke, considering the memory sizes of even cheap SD cards. But for some strange reason I still wanted to have such an “impressive” device. So I built it:

This post shows a setup that is able to run a backup server for daily backups at close to zero cost – both in terms of initial costs as well as running costs.

—

Backups are an annoying necessity of today’s life. Without them, loosing all your data in an instant is a realistic scenario. Sure, you might use cloudy stuff for your data that is (hopefully?) backed up but this comes with its own issues: Giving away your data, paying for the service, …

I, however, like to keep my data under my control. Therefore, I’d like to share my backup solution which might be useful for some of you – especially in these days of ever increasing energy prices.

My backup system needed to fulfill the following requirements:

• Automated on a daily basis with snapshots for each day
• Encrypted
• Off-site
• Under my control
• Append only: Snapshots can only be added, never changed or deleted (to protect against ransomware attacks)
• Cheap to build and cheap to run

Many of these requirements can already be fulfilled by choosing the right backup software. I choose Restic, an in my opinion excellent piece of software for doing backups. It fixed the following requirements for me:

• Automated on a daily basis with snapshots for each backup: Since restic does automatic deduplication, doing daily snapshots does not hurt at all. I back up ~500k files with 500GB and typically each daily snapshot consumes a couple of KB + newly created data
• Encrypted: Restic encrypts backups by default
• Under my control: Restic is running on my hardware, using FOSS stacks
• Append only: Restic allows to use true append-only operation

So what I needed to fix by myself was “offsite” and “cheap to build and run”.

For the offsite requirement I decided to use some kind of machine that does not sit in my house. I considered both vServers as well as dedicated hardware.

A typical vServer that would be suitable for my needs would cost me around 15€ per month. Mh, so I would need to pay 180€ per year for something that I hopefully will never need… mmmh, nah, too little value for the money.

Next I considered running my own backup server in my garden shed (which has power but only wireless connectivity). This would cost me maybe 100€ of initial cost for the hardware (like a RPI or similar). And then, assuming a power consumption of 5W and 0.4€/kWh (yey, I live in Germany with the highest electricity costs worldwide) I would need to add another roughly 20€ per year for this device. So, yes, this seems okish but somehow I really don’t like the fact of having a RPI heating up my garden shed 24/7 while it is idling most of the time. In addition, RPIs are not exactly easy to get right now.

Since my garden shed does not have LAN, using techniques like Wake-On-LAN were also not possible. But luckily, I learned about a not very well known ACPI feature present in most machines: RTC wakeup. With this feature, you can instruct the real-time clock of your PC to wake up the machine at a specific time. Interestingly, this even works when the machine is turned off completely (not in standby or hibernate). With this, all my issues were solved: I can recycle a 15 year old laptop as a backup server and reduce its energy consumption to almost zero. This works as follows:

The RTC wakeup powers on the machine each day at 3am. My server that I want to back up notices the presence of the backup machine, starts a backup and after completion turns the backup machine off. Since Restic is blazingly fast (it takes 3 minutes to back up my 500k files, 500GB data), the machine only consumes its 7W for a duration of 3 minutes and the rest of the day 0W. This equals to 15mW on average, a power that you could even easily provide from a small solar cell in case you even do not have any power at all (think of a backup box just sitting in your garden).

The realization of such a system is very easy: On my data server I have a script that monitors the presence of the backup machine and if present, starts a backup and powers the machine back off. On the backup machine I just have an append-only restic server running.

This is the script running on my data server:

#!/bin/bash


# What should be backed up?
BACKUP_DATA="/data/"
NEXT_BACKUP="tomorrow 3am"

SERVER="backup-server-address" #ie 192.168.1.123
REST_USER="backup"
REST_PASSWORD="backup"

REPO_URL="rest:http://$REST_USER:$REST_PASSWORD@$SERVER/"
REPO_PASSWORD="backup"


SSH_USER="backup"

start_backup() {
        export RESTIC_PASSWORD="$REPO_PASSWORD"
        restic -r $REPO_URL backup $BACKUP_DATA
}


schedule_next_backup_and_power_off() {
        echo "Shutting down server, will wake up again at $NEXT_BACKUP"
        ssh $SSH_USER@$SERVER sudo rtcwake -m off -t $(date --date="$NEXT_BACKUP" +%s)
}


while true
do
        if nc -z $SERVER 80 &> /dev/null; then
                echo "Server online. Backing up..."
                start_backup
                schedule_next_backup_and_power_off
        fi

        sleep 5
done

The above script should be started on boot, for example by a SystemD service.

On my backup machine I simply run the restic server like so:

sudo docker run --env OPTIONS=--append-only -d -p 80:8000 -v /mnt/restic:/data --restart always --name rest_server restic/rest-server

# Add restic user after first start
docker exec -it rest_server create_user backup backup 

Since the data server issues the rtcwake command on the backup server, we need to make sure that the access via ssh onto the backup server cannot do anything harmful (to not allow an attacker to circumvent the append-only nature of the setup). To do so, issue the following commands on the backup server:

sudo su
# Only allow restricted shell
usermod -s /bin/rbash backup

# Allow to run rtcwake
echo "ALL ALL=(ALL) NOPASSWD: /sbin/shutdown, /sbin/poweroff, /sbin/halt, /sbin/reboot, /usr/sbin/rtcwake" >> /etc/sudoers

In addition, you should add the public key from your data server to the authorized keys of the backup server:

# on your data server as root
ssh-copy-id backup@backup-server

A backup server made out of trashy old laptops, costing me 7ct/year to operate? Yes please! I am running this setup for a couple of weeks now and so far I am really really happy with it.

The Nokia communicator was quite expensive back when it came out and unfortunately, the devices still are today (since they became collectables).

Therefore, I built my own device, based on a Nokia 5110 brickphone:

Inside of the original battery I placed a custom designed micro Bluetooth keyboard:

The front cover has been turned as well into a Bluetooth keyboard:

Design files can be found here:

PCB & Mechanics: https://github.com/befinitiv/nokia5110_communicator
Source code: https://github.com/befinitiv/ble_app_hid_keyboard_nokia

This post describes a simple DIY battery replacement that powers an oscilloscope multimeter from USB-C instead of batteries.

Recently, I bought an oscilloscope multimeter which is nice to have, but really eats away the batteries. Therefore, I built a replacement battery that powers the device from USB-C:

The Openscad design can be found here: https://gist.github.com/befinitiv/1568857c133cee344a5894d7f8c03d1b

This post presents an easy to use Youtube Music player that plays music from small token objects

—

The player presented in this post plays music based on Youtube URLs that are encoded as a QR tag and attached to “tag objects”.

If these objects are placed on top of the box, the music will get played immediately. You can see it in action here:

The source code as well as the schematics can be found in my Github: befinitiv/befibox

TLDR: Bought a Samsung S21 5G, it broke 3 times within warranty time, Samsung gave up repairing it and leaves me with a broken 700€ phone.

Last year my old phone broke and I replaced it with the Samsung top model because I expected it to give me the least trouble. The opposite was the case.

After a month the camera started to shake on its own, even when sitting on a tripod. Clearly, this was a malfunctioning image stabilization.

Next, the mainboard had a fault and the phone crashed and rebooted every minute or so.

Samsung repaired the faults so I was okish with them. Still, I was left for weeks without a phone and they did not provide me a replacement device during that time.

The phone worked ok for a couple of months but then started to break in a quite hilarious way: The actual phone functionality broke. During calls my microphone stopped working after approximately one minute and at the other end you would here nothing but nasty digital noise.

So I did the usual: I sent the phone to Samsung to repair it, they sat on it for weeks and finally returned it together with a letter that said:

Sorry, we cannot repair your device because we do not have any replacement parts for it.

So, Samsung, are you saying: We, the manufacturer of the device, do not have any replacement parts for our top of the line product, which is still in production?

It is really hard for me to decide which is the worst. That their best phone model broke 3 times within a couple of months? That this is a well known problem and they are unwilling to acknowledge it? That they used the silliest possible excuse to avoid repairing it? That they leave me with a phone that cannot do any calls? That I bought a 700€ Phone and they just show me the finger and leave me with a broken device?

So, if you as a customer read this, I hope that your conclusion is the same as mine: Do not buy Smartphones from Samsung. Their quality is laughable, they are dishonest about this fact and they do not care at all about you as a customer.

Have you ever been annoyed by having to charge your headphones? There is a cure for that

Ever wanted to take digital pictures and videos with your old analog camera? How about live video streaming over WiFi? You can