Wi-Fi HaLow Video Streaming Between Two Raspberry Pi 4s

I am trying to stream video over Wi-Fi HaLow from one Raspberry Pi to another, but I am unable to get any video stream detected on the access point.

Setup details:

  • Two Raspberry Pi 4 boards

  • WM1302 Raspberry Pi HATs

  • Seeed Studio Wio-WM6108 Wi-Fi HaLow mini-PCIe modules

  • Raspberry Pi Camera v2 connected to the client Pi

What I’m trying to do:

  • Stream live video from the client Pi to the access point over Wi-Fi HaLow

  • View the stream on the AP side

Issue:

  • The access point does not detect any camera or video stream on the network

What I’ve tried so far:

  • Morse Micro reference image

  • OpenMANET image

  • Replaced the Pi Camera with an IP camera on the client side (same result)

At this point, I’m not sure whether I’m missing a configuration step, using an incorrect network setup, or misunderstanding how video streaming should be handled over Wi-Fi HaLow.

Any guidance on required configuration, known limitations, or a recommended approach for video streaming over HaLow would be greatly appreciated.

Before jumping to streaming video - have you been able to establish a connection between the two devices? One operating as an Access Point, the other operating as a Station?

A Raspberry Pi with a HaLow hat is very similar to our OpenWrt based EKH01 reference image which comes with mediamtx servers and a LuCI dashboard to view RTSP streams. My suggestion would be to look at using that image if possible.

You will need to build a custom device tree overlay to support the WM1302 hat, as well as forcing a BCF for the Quectel module.
Have you created device tree overlays before?

Yes, I have setup the two devices and established connection. The web UI of the AP shows it is connected to STA at 192.168.1.1.

No I am not capable of creating device tree overlays, but i will try to learn it. For now, what do you think will be the quickest way for me to get a video stream and bidirectional audio streams setup over Halow? I did see the BCF warning on the Web UI but I ignored it. I will look deeper into it.

I have managed to establish connection all the time, but I haven’t been able to get a stable end-to-end video stream working. So far I’ve tried HaLow dongles, a Heltec HD01 + HT7608 setup, and WM6108 mini-PCIe modules with WM1302 HATs on Raspberry Pi 4.

Using the EKH01 image sounds promising, but creating device tree overlays and handling BCF configuration is currently beyond my experience. Do you think moving to the EKH01 kit would be the more practical path for me at this stage?

1 Like

Hey @Shoes

I had a response written for you with respective to devicetree for the WM1302, but never actually hit send! See below


Take a look online for some device tree documentation, especially device tree overlays.

To help you out a bit, I’ve attempted a device tree overlay for the Raspberry Pi 4 with a WM1302 hat

wm1302-halow-spi-overlay.dts:

/dts-v1/;
/plugin/;

/ {
        compatible = "brcm,bcm2835", "brcm,bcm2836", "brcm,bcm2708", "brcm,bcm2709", "brcm,bcm2711";

        fragment@0 {
                target = <&spi0>;
                frag0: __overlay__ {
                        pinctrl-0 = <&spi0_pins &spi0_cs_pins &morse_wake &morse_busy &morse_irq &morse_reset>;
                        cs-gpios = <&gpio 8 1>;
                        #address-cells = <1>;
                        #size-cells = <0>;
                        status = "okay";

                        mm6108: mm6108@0 {
                                compatible = "morse,mm610x-spi";
                                reg = <0>;
                                reset-gpios = <&gpio 17 0>;
                                power-gpios = <&gpio 23 0>,
                                              <&gpio 24 0>;
                                spi-irq-gpios = <&gpio 25 0>;
                                spi-max-frequency = <50000000>;
                                status = "okay";
                        };
                        spidev@0 {
                                reg = <0>;
                                status = "disabled";
                        };
                        spidev@1 {
                                reg = <1>;
                                status = "disabled";
                        };

                };
        };

        fragment@1 {
                target = <&spi0_cs_pins>;
                frag1: __overlay__ {
                        function = "gpio";
                        pins = "gpio8";
                        bias-pull-up;
                };
        };

        fragment@2 {
                target = <&gpio>;
                frag2: __overlay__ {
                        morse_wake: morse_wake {
                                function = "gpio";
                                pins = "gpio23";
                                output-high;
                                bias-disable;
                        };

                        morse_busy: morse_busy {
                                function = "gpio";
                                pins = "gpio24";
                                input;
                                bias-pull-down;
                        };

                        morse_irq: morse_irq {
                                function = "gpio";
                                pins = "gpio5";
                                bias-pull-up;
                                input;
                        };

                        morse_reset: morse_reset {
                                function = "gpio";
                                pins = "gpio17";
                                output-high;
                                bias-disable;
                        };
                };
        };

        fragment@3 {
                target = <&spi0_pins >;
                frag3: __overlay__ {
                        bias-disable;
                };
        };
};

You would then need to compile this into a device tree overlay with something like `dtc -I dts -O dtb -o wm1302-halow-spi.dtbo wm1302-halow-spi-overlay.dts


If the cost is feasbile (I know they are expensive kits :sad_but_relieved_face: ) the EKH01 will probably give you the best chance of validating HaLow with cameras attached - as there are camera versions of that kit!

Hi @ajudge

Thank you for the overlay, but i don’t seem to be able to get the setup working for transmitting video. Transmitting HD video and bidirectional audio across RCC walls is the primary purpose of my project. but i cannot seem to get the seed studio setup working despite multiple attempts. I am successfully able to establish connection and send pings, but Services → Cameras always says (No ONVIF compatible cameras)

Do you think the EKH01 kit (couple) will be the best chance for getting things working out of the box? For transmission across RCC walls, should i use an LNA for better penetration?

Another parallel question was if i can use the MM8108-EKH19 Evaluation Kit as a standalone dongle with the Rpi to get the benefits of wifi halow transmission?

Thank you again for helping out.

The camera setup we use relies on ONVIF for discovery, which is handled by two bits of software. rpcd-mod-onvif on the receiving device to carry out WS-Discoveries and various ONVIF control functions, and camera-mod-onvif on the camera device side to respond. Here’s a bit of an informal diagram:

There are a few reasons this might fail:

  • either rpcd-mod-onvif is sending ONVIF out the wrong interface;
  • camera-onvif-server isn’t listening on the correct interface;
  • /dev/video0 on the camera device has not come up - which camera are you using? You may need an additional driver

On the camera side, what is the output of logread | grep camera-onvif-server.
On the viewing side, what interface is it configured for in the WebUI?

Yes, but let’s try some debugging first :slight_smile:

You can plug the dongle into a Raspberry Pi. The steps as followed in Build Thread: HaLow for Raspberry Pi OS will be largely the same, except for USB you won’t need to worry about device tree.