A newbie's first steps blog

Help / Getting Started
1

hey Folks,

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 :slight_smile: . 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

firmware:

  • OpenHD 2.0.0 stable for buster

ground:

  • RPi 3B or RPi 4B
  • 7’’ waveshare touch display or original RaspberryPi Touch display
  • AWUS036ACH
  • home-made LT8610A based 5.3V/3.5A SR + battery

air:

  • RPi 3A+
  • AWUS036AC
  • 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.

Quick Summary

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.

The First Efforts

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. :frowning:

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.

The Second Efforts

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! :grinning: :crazy_face: :sunglasses:

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

ground:

  • RPi 3B or RPi 4B
  • original RaspberryPi Touch display
  • AWUS036ACH

air:

  • RPi 3A+
  • AWUS036AC
  • 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 :+1:. 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).

The Third Efforts

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. :sob: :sob: :sob: (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.

Conclusions so far

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 :smiley:

Cheers, Olli

2 Likes
2

The Third Efforts II

As regards the issue of the huge latency when I use the Aliexpress DCDZ HDMI-CSI adapter + GoPro Hero5 black, I was suggested in HDMI-CSI converter with GoPro Hero5, huge latency, what to do? that I should reduce the value of the parameter BITRATE_PERCENT (many thx for the help :+1:). It is not totally clear to me if that value affects only the air or both air and ground, so I updated it through forced smartsync.

I found that I had to reduce that value from the default quite substantially. After some substantial testing, I finally ended up with using 27. The bit rate is then on the order of 5 Mbps, which is much lower than what I observe with the 10Eur cam and the default BITRATE_PERCENT value, but I somehow got more disturbances when I went higher. So, 27. LOL.

Anyway: Aliexpress DCDZ HDMI-CSI adapter + GoPro Hero5 black works :+1::+1::+1:

BTW: In case anyone wonders: As regards using the DCDZ HDMI-CSI adapter with RPi one can find lots of web pages which tell that one has to do this and that patch of the kernel or of a driver and what ever fancy thing. The latest I found was saying that e.g. raspivid would not support it, and that raspivid would now spit out a text warning message. However, I’ve just installed a fresh latest raspbian image, and with it it works just all fine out of the box. So, it seems that this issue has been finally resolved.

The Fourth Efforts

Having been curious about how the RPi Zero would do, I realized that while I can’t yet connect my 10Eur cam to it I can do so for the DCDZ HDMI-CSI adapter + GoPro Hero5 black (the DCDZ HDMI-CSI adapter comes with the required cables). So, I did that. And:

It worked out of the box. Fantastic.

Now, given the above cpu numbers, I was most curious about how that is with the RPi0. And, well, it can go momentarily to high values, but most of the time it is in the range of 25-30%. This is fantastic, isn’t it?

It’s also somewhat confusing. Just a moment ago I have read the release notes for OpenHD 2.0.1, which for the RPi0 says that “CPU use should now be around 25-30%, down from 60-70% or higher, The fix only works on Stretch at the moment, so you MUST use the Stretch image on the Pi Zero for now”

Remember, I’m using OpenHD 2.0.0 buster, and that’s also what I used for the RPi0 test, and I get miracuously similar values of 25-30%, on buster, without that fix…

Anyway, I guess the great message is that the cpu load on the RPi0 is, or is going to come down to the expected level.

Cheers, Olli

3

The project requires patience, persistence, and money… I don’t think many ppl achieve the ultimate openhd build on their first attempt. It’s a journey and as your build evolves, so too will the project. Thanks for taking the time to write this as it will be helpful to those who come behind you.

Believe it or not Openhd seems to be growing, improving, and attracting more people than it ever has. I think the fundamentals of the project are sound and the project’s success will hinge on the contributions of volunteers.

4

well … I’m not sure I understand why you felt it important to drop some of the comments which you’ve dropped. I think I’ve made an effort to describe my rationals in a way which should not diminish your efforts, to the contrast. But technical aspects are as they are.

And I think one could derive conclusions from them, which IMHO would help the project better than yet another fancy feature.

For instance, in the recent times things came across as if there is a move towards discouraging the RPiZero. Evidence however pointed towards that there is no reasons performance-wise, and with 2.0.1 it seems it is confirmed. I would argue that you rather should strive to make the RPiZero a beloved possibility, and not discouraging it.

For instance, I think more resources should be going into finding more and potentially cheaper 5GHz adapters. I remember that few years ago there had been massive efforts in this direction (you easily can trace it in the various wikis), obsolete now however. I e.g. find it not so easy to understand that there is nearly no info (is it good or bad?) on the RTL8811 variants, or the AWUS036AC, and some more. A single person like me can’t them buy all, given the costs, but the community, some of which has at least some level of funding, could do.

For instance, some of the members in this secret telegram obviously have tremendously high electronics skills. Why isn’t there more coming out of this, becoming better available to the masses and first-comers.

For instance, there are other projects based on wbc, why not taking over the good aspects of them. I at least could (yet) not figure that out.

For instance, code could be better structured (and better documented), which indeed would make it easier for volunteers to contribute (I e.g. very much like DroneBridge in this regards).

…

None of that is criticism, but - IMHO - can help to make things better.

5

No offense was taken :smile:

I sincerely think that your write up is constructive and will be useful!

I would say that there is no “secret” telegram group- it’s here

For whatever reason telegram is the most popular way most people involved in openhd communicate. It’s VERY active with the main group that’s approaching 600 members. There is also a large Russian group. This forum is a distant second as far as activity and kind of used as a way to preserve some of the info from telegram as after some finite amount of time things drop off in telegram.

If you want immediate answers to many questions, telegram is the place (for better or worse, like it or not)

The wiki is and should be the official source. but it has always lagged behind the code. I don’t think that will change either… Unless more volunteers decide to do it, but it’s kind of thankless

6

I can make direct comments regarding the zero… To sum up a long story on the zero- it was playing with fire as some settings and cards (some cards can offload functions onto the cpu) could trigger cpu load spikes that would result in lost packets. For a long time the zero has been barely keeping up with packet injection at the expense of fec.

Stephen has confirmed that much of this has been kernel issues unrelated to OpenHD. Now he has got lower cpu usage with a new kernel AND it is now working for him on stretch and buster.

Stephen has succeeded where the rest of us failed when it comes to lowering cpu usage on the zero. The rest of us attempted for years to get the zero cpu usage lower… It created all kinds of tailored work arounds just for the zero and in the past you could still trigger lost packets and latency in the video. Personally I gave up on the zero about a year ago and considered it a risky option. But as you say- now perhaps there is new life breathed into it. It’s hard for me to type that :sweat_smile:

7

“secret” to me means here that one can’t see anything of it unless one registers … like e.g. facebook, and similar, the info there, as good as it may be, is of no value unless you are a facebook user

many thx on the background on the RPiZero. Very interesting.

Being a first time user I of course can’t claim to know anything, especially not of the deep details. However, I can (and I do) read and try to piece info together and see if they give a consistent, meaningful story (and I’m reading on wbc and follow ups since a while). What I note is that in your exploit the story is interestingly different (and makes more sense to me); all I essentially was reading so far was kind of “the load is about 50-60%” or “the RPiZero is basically maxed out” and such sort of comments. As I’ve indicated, from a scaling point of view this doesn’t play out. I thus was, and am surpised that I find loads of 25-30% - with OHD 2.0.0 buster, which according to the release notes does not have that said fix (!?!) - which from the scaling makes more sense. Temporary cpu load spikes are something quite different, and I must say, make much more sense to me. Many thanks for this clarification!

8

The Fifth Efforts

Having now played a bit more with my setup, I decided to collected a bit more info on the two wifi cards I’m using, for my own reference, but also because at least some of the info might be of interest more generally.

The result is this: OlliW's Bastelseiten » WifiBroadcast, OpenHD, DroneBridge: 5 GHz Wifi Cards

The Alfa AWUS036ACH is already well described in the OpenHD wiki, and I don’t have anything to add which I would think is noteworthy here.

The Alfa AWUS036AC is not in the OpenHD wiki, and the one point I think one might mention here is that datasheets of the used power amplifiers suggest a power of 18 dBm or 63 mW per antenna. Given it has two antennas it might not be too bad.

Maybe noteworthy is also, that both cards do not have the shielding case populated, and they thus might need more care with shielding. In contrast, the popular USB AC56 does have the electronics covered in a shielding case, and it might be thus better from this perspective.

Lastly, in the above I was wondering if it would be better to have two single-antenna wifi cards and to benefit from OpenHDs diversity or one dual-antenna wifi card like the Alfa cards I use. I now came to the conclusion that the latter is better, because what these cards is not only the conventional swicthover to the better antenna but in fact do MIMO. For MIMO read wikipedia. It seems clear to me that this is much more sophisticated and powerfull than the simple diversity.

9

Although I’m not positive, the AC56 does appear to have the capacity to have two antennas, and actually two internal, or two external. I have seen photos where a person replaced the two internal antennas with soldered on coax cable to make them a more usable external two antenna setup. For the most part reading the MIMO wiki is a bit over my head, but I was wondering if you’d looked into the AC56 for the dual antenna capability.
Also, I wanted to say you’ve done a very good writeup with your experiences, thank you for that.

10

I don’t have a USB AC56, because I just found it too expensive. But form the info on the web it has an internal antenna instead of a second external antenna, but you’ll find several reports here there folks did replace it. So, yes, the electronics is there and the USB AC56 can be modified to a dual external antenna system.

that’s probably a goto thread for the USB AC56: ASUS USB-AC56, wiring, antennas, etc

11

I was wondering if you were able to verify your conclusion that the Alfa AWUS036ACH benefits from the MIMO more so than simple software diversity?

1 Like
12

Very helpful post that i believe helped eveyone that started with this after you. Thanks.
One thing i never managed to understand (by the way we are working on a rover). Can the system work without a flight controller? Can it be only a raspberry and a motor controller for example?
I can not find any help with that.
Thanks in advance