Roadmap to 2.0

[Yes21]

1 - Make RD's Image Builder script work to generate a working image. (@RespawnDespair / @user1321 / @pilotnbr1 / @Yes21 ) -- WIP --

• The EZ-WBC code used to create this image is stored in RD's separated repositories link.

• If something in these repositories is wrong or missing, it should be corrected in these repositories
  until the generated image woks perfectly.(*@RespawnDespair / @user1321 / @pilotnbr1 / @Yes21 )

• The news features of this first built image will be :
  - done : new kernel( 4.14),
  - done : support for RPI3B+ and RPI3A+
  - done : Mavlink v2.3 support (up to 24Ch RC, solves a lot of the current v1 problems)
  (@careyer/@dino.de)
  - RC switchable AirPi-GPIOs (enables physical actions on the aircraft) (@careyer/@dino.de)
  - RC switchable Ground Station actions. (e.g. switch OSD on/off, change between screens)
  (@careyer/@dino.de)
  - done : FLIRone Thermal Camera support. (@careyer/@dino.de/@pilotnbr1)
  - done : support for rtl8812/14au (@Yes21/@RespawnDespair) link
  - bug fixes: mavlink-routerd, gst-launch, hotspot, DHCP, GPIO pins used for custom profiles.

2 - Transfer the code used to generate this first image from RD's github/projects to ?

• Give this branch the 2.0 number version, and make it the master branch.

• Duplicate this branch to a dev branch where developers could add new features or bugfixes.

3 - Give the 2.0 version number to RD's Image Builder last version script, and duplicate it
to a dev version for next developments.(@RespawnDespair)

4 - Add new features from others images.(@ALL)

• Developers should submit their code and bugfixes to the dev branch,
  and to the RD's dev script (if new packages or patches are needed).

• Anybody can test the new features in building a dev image using the RD's dev script and the dev
  code from dev branch.

• When all is working and well tested, the definitive new image can be generated and published.

• Then the dev branches of the code and the script can become master branches.

• And so on ...

• List of proposed new features :

  • GUI config (@htcohio/@user1321)

  • GPIO 4 camera switcher (@htcohio/@user1321)

  • display: total mAh, km, mins (@wowi69) link

  • OSD enhancements ? (@dposea) link

  • Compile flags/switches (@careyer/ ?) link

[Yes21]

I've copied this roadmap here, but we now have to adapt it to the new situation ...

[RespawnDespair]

Yes we should, also, we should determine the goal again since we are now 'separate' from the main EZWFB project.
When i have some more time available (hopefully this weekend) i'll try and put some of my thoughts in a document to share with you guys, should provide a good starting point for discussion.

[pilotnbr1]

The way I perceive all the images out there and moving forward-

I feel that the strength of ez 1.6rc6 is its reliability. It is also nicely optimized perhaps the best optimized image for space and low cpu usage. But its not as full featured.

OpenHD has some nice cutting edge features (app to set settings and sound) but it might have reliability issues. I havent played with it myself so dont really know.

The russian image appears to be the first to offer more wifi adapter support and thus that hardware advantage may be its strength.

Dronebridge has become its own animal in terms of heavy python usage, better coding practices, plugin ease, carving out a second pi uart, and a different approach to transferring data between pi. It does seem to also favor Inav FC. I have wondered why it is not more successful attracting users ( too different? Bad press from R?) There just isnt much activity or engagement from seeul8tr.

The SVP image has a few nice features too. Encryption being one of the top of my head.

All this to say I would hope we can take the best of all these images and make an ultimate image! I think highest priority is hardware support. Everyone is screaming for more adapter support. Support the newest pi. As for the rest of the stuff it would be interesting to make a poll and just ask the various user groups what they want most. Let the customer tell you your job.

[RespawnDespair]

Well, that's my master plan:

• Better coding standards (As dronebridge, i want to utilize Python for this)
• Plugins for everything (will explain in the future in more detail)
• Rock solid stability, at minimum as solid as the 1.6RC6 (this might mean dropping the more experimental features from the main release and providing them as experimental plugins)
• The ease of config from Open-HD through the app
• The code from SVPCOM for the actual transmission of data (excellent code, UDP pipes for everything)

Basically the best of everything, in the hopes the different projects will merge their efforts into one new project. The image builder would provide all projects with a way of easy upgrades to newer kernels etc. so that's why i see it as the base of it all.

With the release of Ardupilot for F4 i see no reason to support other standards than mavlink, so that should reduce effort on that side.

[Yes21]

I agree.
But to be more concrete, we will soon have to answer to these questions :

• When will we publish 2.0 ?
• Where will we publish it ?
• Will we have to change the name of the project ?
• Will we have to create a new repo for it ?
• Will we have to duplicate the wiki ?

What do all of you think about these questions ?

[htcohio]

Hey guys, Just a little bit of info... The open HD version appears to be working very well. I did have an incident where I crashed but, I think it was the result of a loose camera connection and somehow audio transmission was enabled on RPI zero causing a runaway latency and maxed out CPU. I have done as much ground testing as I possibly could with various setups and the only bugs that I can find are as follows: 1. Communication app sometimes requires clicking save several times before they are sent. (I believe this uses SVPCOMs code for the communication) 2. Raspberry Pi zero boat time seems a little longer than the regular image. 3. Open HD splash screen needs some optimization, some monitors it's half cut off. 4. The Android app could use some optimizations, I would like to create a dedicated app that is not mixed with an older version of fpvvr. ***OPEN HD also has the option to choose encrypted RC control. The RPI zero uses a little more CPU from what I can tell but I am not able to identify any reduction in control range or any other drawbacks. Unfortunately we never got the 8812au chipsets to work with our image but we didn't spend most of our time on that. Other than the encrypted RC, the only other enhancements are the synchronized communication program and the gpio trigger which should be pretty simple ... Unfortunately, USER1321 informed me that he is stepping away from development for the foreseeable future. I think that a lot of the Fud and "drama" with Ez on more than a few occasions and the seemingly endless quest for bugs and optimizations could have had an impact on his motivation to continue. I believe he feels that the project has is is in a good spot and has accomplished several milestones. I'm sure he would be happy to provide info or help if you'd like to integrate any of the open HD code. It's unfortunate to see how things have split up lately, however the good news is that every day new people are learning about EZ wifibroadcast and engaging in the Forum. I'm quite certain that next spring summer will bring a lot of exposure to the project and all related branches

[Yes21]

@htcohio Happy to see you here again.
I'm sorry to know that @user1321 decided to give up.
The latest dramas did make too many "victims" !

Now we aren't so many, so let's go together ...

[Yes21]

I will now try to answer to my own questions.
Please keep in mind that it's just my thoughts, and that everybody is free to don't share them ...

• When will we publish 2.0 ?
  When all the adds proposed in the roadmap will be implemented. This will be soon ...
  Before merging functionalities from other projects.

• Where will we publish it ?
  Perhaps on a new github repo.

• Will we have to change the name of the project ?
  Difficult question ! Perhaps EZ-WifiBroadcast-NG ?

• Will we have to create a new repo for it ?
  Perhaps yes. The url could be "https://github.com/ng/EZ-WifiBroadcast-NG"

• Will we have to duplicate the wiki ?
  If we have a new repo, it would be a good thing to have the latest wiki in it, and to maintain it up to date.
  I can try to copy/paste all pages and recreate links, but it will take some time.

And now, let know what you are thinking of it ...

[htcohio]

Hey, that sounds good to me :) I've always supported the idea of a new name just so it is clearly defined as something "new". Open-HD can be used if you would like. As of right now it is just a ISO image floating around in our Google Drive. if not that name, any other name that does not have -"Ez-wifibroadcast" in the title would be great. I promise, only positive things would come from it. @Yes21, you have put countless hours into the 88xxAU support because they are easily accessible. I'm impressed by your motivation and commitment to that goal. User 1321 has not really given up or disappeared permanently, I just think he needed an extended break and needed to focus his efforts on commercial projects and his livelihood. The thing is, after nearly one year I am still intrigued by the possibilities of this project. Probably because it represents RF freedom and it is a "hack" that almost anybody can achieve. On a side note, I think there are many interesting things that can be done with various Wi-Fi card drivers, firmware and EEPROM... Yesterday I came across this Forum and a thread that's a couple years old but it seems as if they unlocked several additional features and channels on older Realtek chipsets. Maybe this is irrelevant but, it seems like this guy (Sysvalo) really knows his stuff with the wireless drivers. https://xiaopan.co/forums/threads/unlocked-channels-tx-power-other-mods-for-atheros-intel-realtek.5359/ Let me know what you think...

…

On Thu, Dec 6, 2018, 3:29 PM Yes21 ***@***.*** wrote: @htcohio <https://github.com/htcohio> Happy to see you here again. I'm sorry to know that @user1321 <https://github.com/user1321> decided to give up. The latest dramas did make too many "victims" ! Now we aren't so many, so let's go together ... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#93 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AcSp0lzjxdXIWPiyOGn8Jp0CeK8d4Ln5ks5u2X4sgaJpZM4ZBnLF> .

[rodizio1]

Please don't use anything with "EZ" or "EZ-WifiBroadcast", that name is associated with the original project.

[RespawnDespair]

@rodizio1 Agreed, that would only confuse things further.
I propose we don't add yet another flavor and adopt the Open-HD (or Open.HD) name for our image.

[dposea]

What is the 8812au status? AWUS1900AC Sseems fine for 5.8 . I've tried investigating 2.4 lost packets but got nowhere. I also could not get svpcom WBC to work in any consistent fashion. The udp stuff is kind of cool but doesnt really do anything any better than a pipe.

I started looking at other boards that have hardware encoders. The new banana pi and odroid c2 look good; but we would need a lot of coding to take advantage of any latency reductions by sending lines of data from the camera rather than waiting on blocks to get filled. I just started working again after 6 years off; so my time is limited.

[pilotnbr1]

@htcohio sorry to hear that about user1321. Between the two of you guys you were cranking out a lot of features and looked like you were having fun doing it! Thanks for offering the Open-HD name, it does have a nice sound to it.

One thing that worries me a bit going forward with this project is that we might inadvertently cause more splits and side projects. If it’s not flexible enough, or enough features, or easy to use, someone with enough knowledge will fill that gap and start making more distribution images. We need to make it simple and easy for the average user to get the image they want but at the same time flexible and open enough to allow the experimenters to build off of the tools here. Bottom line is I would like to cause more of a consolidation of development talent here...

[Yes21]

I agree with Open.HD, even if I don't like it very much but ...

We also need to change the logo !
I've a great idea for it. I will submit it to you this weekend.