When running the EKH03 as an AP I’ve seem to run into an issue where it doesn’t properly detect any camera servers on the network (this is when scanning both br-ahwlan, and br-lan). Both have the latest Morse Micro OpenWRT 2.6.6 images as provided in the customer portal.
I have installed a Pi Camera Module 3 on the EKH01, which uses a IMX708, that appears to be supported based on the config files in the github repo.
When opening the EKH01’s Web UI it does show an active camera interface (as seen below). This stream doesn’t show up if I switch to wlan0.
The other links to the Proxy RTSP, WebRTC, and HLS servers all work as well.
I don’t see a reason that auto-detection on the AP’s end shouldn’t be working since I can access it from my PC that is bridged into the network. My best guess is I missed something simple along the way given this seems like it’d be a fairly simple thing to do, however after reading the camera setup procedure in the user guide a few times over I’m not sure what that would be.
Any help or resources for further reading would be greatly appreciated!
The most likely situation is that the onvif server configuration on your station is not set to the correct interface (it’s only setup to listen on one interface). Unfortunately, there’s a oversight (ok, a bug) in 2.6.6 where the wizard doesn’t change the camera-onvif-server config when it moves things around.
To fix this, go to the device where you have the camera and change /etc/config/camera-onvif-server to have ‘ahwlan’ rather than ‘lan’ (assuming you have a standard-ish configuration), then run service camera-onvif-server reload.
If this doesn’t work, put your network/wireless/camera-onvif-server config files here, and ideally the output of logread | grep camera-onvif-server. Note that using the EKH03 both as an AP and for repackaging the video will put a lot of pressure on the EKH03’s slow CPU, reducing the maximum wifi bandwidth.
Out of interest, is there a particular use case you’re looking into here? Our camera support on the EKH01 is mostly there for easy demos, but if you’re looking for a more polished experience I’d recommend using an existing 2.4/ethernet camera and its web interface, and have the EKH devices purely for the range extension. On the other hand, if you are finding it useful for other reasons, this would help us direct further development.
Thanks James! Changing the config and reloading the service went without a hitch, everything’s working fine now. I’ll keep in mind the note about the EKH03 bandwidth being used up by processing video streams.
I’m a part of a university team that competes in a rocketry competition each year, and was looking into this for live telemetry between the ground and rocket without concern for latency. This telemetry would include both sensor data and a video stream provided by a Pi Camera. I’ve just gotten started looking into this (I only set this up for the first time yesterday). I am currently exploring what you can do with the image provided by Morse Micro as I’m unfamiliar with OpenWRT and how it works as opposed to a normal Linux distro. I’m just considering whether it’d make sense to iterate on the OpenWRT image or port the drivers to Raspbian and go that route with development.
…Needless to say this is probably far from a typical use case for this sort of hardware, and if there’s anything here that raises an eyebrow I’d be happy to hear about it as well.
That sounds awesome! I imagine our marketing people would be excited about it, even if WiFi HaLow for rockets is never going to be a key market for us, so do let us know if you run into any annoyances.
Re sticking with OpenWrt or moving to Raspbian, my instinct would be to run Raspbian in the rocket and use one of our standard OpenWrt images on the AP (just connect via USB or ethernet to whatever’s actually running your software on the ground). OpenWrt is designed for cross-compiling and building images for routers/APs, its package repository may be missing things that are critical, and it won’t be as straightforward to iterate on. Relatedly, we use MediaMTX to provide the camera stream, but there’s no need to tie yourself to that if it doesn’t meet your needs.
By the way, if you’re putting the AP on the ground and the Client/Station in the sky, note that by default on our EKH kits powersave is enabled, which may affect AP → Client latency (as it does for any WiFi). You can disable powersave in the advanced settings in the Network->Wireless section of the menu.
Thank you! This might be a bit of a stretch, but would it be possible to get in touch with someone from your marketing team, or someone who handles sponsorships? Our team’s funding is limited, and we would be interested in getting additional hardware somewhere down the line. We would be happy to provide any live video footage we capture along with any additional promotional materials desired.
Your instinct seems to be in line with what I was thinking as well regarding using Raspbian for development which is good to hear. When it comes to video streaming I’m not too picky about the solution, just as long as it provides intelligible video regardless of noise. We expect to be operating in an environment with a lot of non-802.11ah traffic on the 900MHz band.
Good to know about the power save option as well! I’ll make sure to get that turned off when doing further testing.
I’ll begin working on compiling a patched kernel then, and if all goes smoothly with our test launches I’ll have some sweet video to post on the forum sooner rather than later
I’ve raised this internally, but I don’t have a good sense of whether anything is likely to happen. A lot of people are on holidays, so don’t expect a fast response.
This concerns me, because I’m guessing the other teams will be doing other 900MHz ‘stuff’ and it would be hard to test in advance.
Thanks James! I really appreciate you bringing it up internally regardless of outcome.
We’re looking at doing some interference testing later on with multiple sources of noise (LoRa & FHSS transceivers, etc) that we’re likely to see in use which hopefully will give us a clearer idea. For now we’re basing most of our assumptions off of Yukimasa Nagai, et al. which mentions how 802.11ah interacts specifically 802.15.4g signals in section 3, but is an incomplete view for our use case.
