in Newbie, some questions pl I was asking some questions, and now I’d like to give a first report/feedback on how things go . So, this here is not a questions post (my further questions I will post there), but indeed more a blog thing, but I didn’t found a better section, so place it here. Also, I’d like to do this because I actually found the (few) build reports in this forum quite helpful, and in fact often wished that more detailed info would have been shared.
I’ve used this
- OpenHD 2.0.0 stable for buster
- RPi 3B or RPi 4B
- 7’’ waveshare touch display or original RaspberryPi Touch display
- home-made LT8610A based 5.3V/3.5A SR + battery
- RPi 3A+
- home-made LT8610A based 5.3V/3.5A SR + battery
- cheap 10Eur camera (they called it RPI JT CAM 5MP OV5647) or Aliexpress DCDZ HDMI-CSI adapter + GoPro Hero5 black
I’ve decided to take the risk and buy the not-listed AWUS036AC instead of e.g. the USB AC56, simply because it is soo much cheaper (and dual antenna cannot hurt I hope LOL).
I’ve done my tests so far on the bench only. It actually will be still a long mile before I could/would consider a flight test.
With the right setup it works “out of the box”, but it is as it’s usually with linux: Everything is possible but nearly nothing works.
And - at least on my yard stick - it is really anything else than cheap. Don’t think one can get away with 200 Eur.
I started with using the RPi3B and the 7’’ waveshare touch display. On the air pi I used the 10Eur cam, which I did test before. I actually bought this cam exactly for this purpose, to have a “working reference cam”, and thus took the cheapest I could find in my area.
And this did NOT work. Bummer.
I don’t want to describe at length the error pattern, also because the error pattern “changed” during the course of my efforts, and the complete systematics I didn’t work out.
I first thought that it’s due to me using the RPi 3B, since I’ve seen in the release notes that 2.0.0 for buster has/can have issues with it. I must say I was a bit upset by this, I mean, when one has said one wants to use the RPi 3B and asks “Any “dark secrets” one should know? Any hardware items I missed? Any other typical blockers?” one would think one would get a hint on this. However, I then came to the conclusion that it is the 7’’ waveshare touch display. That is disappointing, and a bummer. I’m using this display since more than a year or so, in various situations, and it always worked just fine for me. Adds another notch to my general conclusion about linux LOL.
So, I’ve replaced the RPi 3B and the 7’’ waveshare touch display by a RPi 4B and RPi touch display, and on the air pi I continued to use the 10Eur cam.
And this worked! Right out of the box. Fantastic!
Having now a working reference, I’ve spend a bit more time on figuring out what went wrong in the first efforts, and e.g. also switched back to the RPi 3B, and now even this worked perfectly fine! I then tried the RPi 4B with the wavesahre display and again it didn’t worked. That’s why I concluded it’s a problem with the waveshare display.
I believe what needs to be done is to allow for a display configuration step like with when you start with a fresh raspbian image.
So, my working configuration is
- RPi 3B or RPi 4B
- original RaspberryPi Touch display
- RPi 3A+
- cheap 10Eur camera
I’ve played when with this system for quite a couple of hours, to learn the OpenHD system a bit better, and overall things seem to work. But there seem to be also some glitches here and there. Nothing serious, but not perfect. The QOpenHD configuration is really great, very very helpful . I’m not so sure about the SmartSync thing. It’s a bit less transparent what is really going on, and when. And I also find it strange that there is a “Ground” menu but no “Air” menu. I mean, some settings like e.g. a sumd output should be in an air tab, and I also had the feeling that not all settings are there one naively would expect them. But that’s really criticism on a high level, right.
I then tried to bring the video also to MissionPlanner. I am happy to report that this - in stark contrast to what is written in the wiki - just works very easily. You connect to the Open.HD AP, start MissionPlanner, and it’s coming up in the HUD. Nothing else to do! (no need to configure anything, or to connect, or such). It can take a while before the video comes up, especially the very first time it really took some time, but it will come up. That’s actually expected, since MissionPlanner now comes with all this gstreamer stuff and does a lot of fancy things in the background to detect video streams.
What I don’t like is that it is somehow difficult to get into the linux system. E.g. to configure a display. Or for whatever other reason. Usually I ssh into the raspi, or even more often use VNC, but not with this AP thing … seems not to be possible, also when I disable the AP. It’s also not so easy to bring up a console (yeah, there is this cntrl-alt-f12 thing, but…).
What I found interesting is that the cpu numbers are generally very low, like few %. I’m not sure what they mean, but if they mean what one would think they mean (the cpu load LOL), when I would have expected higher values. I’m actually wondering why the RPi Zero is said to be maxed out, I mean, it is quite slower than a RPi 3B, but not by a factor of 20. I thus certainly will test also a RPi Zero (I just need a cable adapter for the cam, ordered a wrong one LOL).
So I went ahead and replaced the cheap 10Eur cam with the Aliexpress DCDZ HDMI-CSI adapter + GoPro Hero5 black, which would be actually the goal.
It actually was much easier to get working than I initially had expected. In the GoPro one just needs to set to Monitor or Live mode, which it is anyways by default, so one actually doesn’t have to do anything, conncet the things up, et voila. Well, it’s not as trouble free. One needs to first connect everything and then power the air stuff. The HDMI-CSI adapter seems to not like disconnecting/connecting the camera while it’s running. But it works really easier than I thought.
BUT: The latency is just terrible! Easily 4 seconds or so. That’s really a very big BUT. (EDIT: solved, see next post)
I had read such reports before, and found comments like “just disable the EIS”. So I of course ensured that I had this disabled. Yet, 4 seconds lag. I also tried all sorts of res and fps, always the same. Always 4sec lag.
What I note is that the bit rate goes up to 10Mbs in the OHD display. I guess one needs to tweak the right parameters to get this down to levels which the system can handle. I at least hope that this would solve it. I could surprisingly not find anything on the web so far on that matter.
So, this does not yet work.
I’m not sure what I should think.
In some way I’m VERY impressed. There is a lot of cool stuff. And - with a canonical setup - it’s easy to set up and use. Given the nature of linux, and the many pieces which need to be put together to work, it’s obvious that a heck of work went into this to get there it is now.
However, there are also lots of cons. Most of them have little to do with OpenHD itself, but with wifibroadcast per se.
It is anything than cheap. 5 years ago, when befinitiv started, it was really very innovative, and indeed a potential alternative, since at that time essentially only DJI was there, and it was f…ing expensive. However, today, the market is full of complete, integrated, digitial video transmission systems. Sure, they are all more expensive, above 500Eur, but below 1000Eur. A comparable wifibroadcast system however will also be a couple of 100Eur, I’d say easily 350-400Eur for an AIO (with which one should compare)(and unless one is making serious compromises).
It is anything than competitive specs wise. There is not a single figure, weight, size, resolution, bitrate, latency, dual hdmi, in which it can even closely compete with commercial systems.
And - besides the heroic efforts by the devs - it is not comparable as regards maturity, ease of use, support, and so on.
So, unless I miss a key point, I am not sure if all these efforts really will pay out. The last bullet can be sorted out. And OpenHD went a long mile in this point. But I can’t see how one could overcome the first two. As said, I’m not sure what I should think.
But it is certainly F U N