openhd / openhd Goto Github PK

The RC drops out due to some bug when using the following settings.

RC=Range
Master MAC= (mac of most powerful ground rx/tx card)
Slave MAC= Either 2nd MAC or "0 auto".
BandSwitcher=0 (off)
*I also confirmed the same problem exists if a 3rd card is added as well on the ground.

Note
Master MAC input for dedicated RC uplink DOES works fine only if BandSwitcher=1(enabled)

With mavlink on an inav FC the compass does not update properly. It slightly wiggles so it is getting info but something is wrong obviously.

Might be a driver problem, also may nees alsa mixer on air ground (Pi2 ~~>Pi3b+ only).
*Not compatible with RPI zero.

We have been talking about a new image and have some really awesome features to share.

I think we can all agree that the more new features we add the more experimental the image becomes.

Do we want to release several images with different degrees of risk?

In my mind we have about 3 possible images floating around

1. most stable image just supporting new pi hardware and drivers for new wifi adapter hardware
2. beta image all of 1 plus: with app settings, sound, flir, gpio, osd, improvements and other stuff I am forgetting that is fairly safe and stable
3. alpha image all of 1 and 2 plus: bandwidth switching

I am ok with releasing some risky stuff (with lots of disclaimers) as I think the WBC crowd is pretty experimental oriented.. Thoughts?

See Screenshot, This function does not seem to work, Too many "hotspot connect/disconnect" notifications at times and it interrupts the osd so this should probably be addressed eventually...

SmartSync basically synchronizes the configuration of Openhd-Settings-1.txt file from Ground->Air...

We previously added TXpower for Atheros to the Open hd app but not the .txt config file...

As such, if TX power is changed on the app, then smart sync is implemented by rebooting air and ground, the TX power setting is not relayed to the airside.

So, as a fix...

We either need to add Atheros (And Realtek to keep everything consistent) so that it is synchronized with smart sync.

OR

Somehow make sure TXpower setting on SSync is relayed to the air side...

**Option 1 Makes the most sense IMHO.

Also, I think that TXpower should only apply to the AIR side only and not ground

Reason: The ground does not transmit that many "bits" of data so keeping the ground at Max TX power all the time does not degrade performance like it does unsung air side WiFi cards (Like Ubiquiti 1000mw card)

It was previously shown that GroundPi continued to send "Pings" to air for remote settings even when "RS timeouts" It would be better if the RS terminates on ground completely when timer is set for RS

Frsky F.PORT is a newer protocol somewhat like S.BUS and S.PORT combined into a single-wire bus using a standard serial speed of 115200, 8N1.

The official protocol documentation is here: https://github.com/betaflight/betaflight/files/1491056/F.Port.protocol.betaFlight.V2.1.2017.11.21.pdf

and Betaflight overview here: https://github.com/betaflight/betaflight/wiki/The-FrSky-FPort-Protocol

Implementing this in Open.HD would add the possibility of Frsky users having telemetry which is currently unavailable due to the 'special' baud rate used for S.PORT. The RC portion of F.PORT is already well-handled by e.g. Inav on standard flight controllers. Telemetry would allow people to use the radio as a joystick while still having the usual artificial horizon, alarms, voice confirmation of mode changes and all the lovely things normal Frsky RC control offers.

I am willing to help test should this be implemented sometime.

In a continuing effort to reduce cpu usage it is beneficial to disable the airpi framebuffer so the console does not have to generate text output.

Reported by zipray. Sounds like the new freq(s) do not get forwarded around correctly from GroundPi Linkpi Airpi

I would call this low priority... It is not a good function to begin with as jitter can be caused with this option. But maybe with the new more powerful pi the jitter has gone away.

Screen notifications still appear with quiet=y

GPIO 28 should say 1 in the wiki

rtl8812au chipsets (Alfa awus036ach) seems to have higher than normal packet loss on 5.8ghz.

2.4 ghz is not usable due to constant packet loss and bad blocks. could be related to the modulation or MIMO RX/TX chain config in drivers.

Also, USB3.0 should be permanently disabled as it is not necessary, a high quality micro usb can be used on the alfa card instead of bulky usb 3.0 cable.

The mavlink message we are parsing is for gps alt.
This might not be the most appropriate, as we have multiple other altitude messages to use.

Instead of so much of the C code compiling at boot in order to include settings. Perhaps settings can just be read at runtime with a parser. This would avoid some boot delay.

Additionally as the project becomes more app centric with settings rather than manually editing the sd card, perhaps we can migrate away from all these text settings files. Case in boot is OSDconfig.txt new users probably wont edit it. Most likely only advanced users will edit it so why not change the format to something more easily parsed but less human readable ie xml

From Justin-

I really think that at a minum hotspot "a or g" should be settable under the regular openhdconfig.txt so that it could change with different profiles.

Another way would be to have it dynamically auto switch hotspot depending on openhd 2.5/5ghz settings during boot process.

Hello,

88XXAU chips can be used in MIMO mode for long range (MCS 9-10-11-12) or (VHT 2 Streams)

these board ar 2T2R.

For the moment, when using these boards only one antenna transmit. This is because we are using only one Stream mode (datarate MCS below 9)

I see that aircrack dkms 88xxAU driver is compatible with these multistreams mode (MIMO)

So it's open-hd that dont use these driver capability.

Does anybody could check this? maybe rodizio?

It was discovered that connecting telemetry uses quite a bit of RPI processor resources.

In Mission planner, if you set "Extra2" parameters to a low update rate like 2 or 3, rpi always request a higher update rate of 10hz which is unnecessary and almost certainly use up valuable CPU budget.

I proposed limiting the stream rate from the flight controller to the air RPI for certain parameters.

some answers or information could be available here.

https://docs.px4.io/en/peripherals/mavlink_peripherals.html

Will need to be added back in the builder

The osd is no working in Pi3b+ ,I can't get any data from mavlink.The Proper Wiring must been right.

Implement a way to display latency on the GroundPi.

Better yet would be a way to detect and fix extreme latency and provide warning.

@Davidsastresas
In an effort to combine issues related to open.hd as a whole, I'm copying this issue about custom Mavlink messages from the Image Builder Repo.

https://github.com/HD-Fpv/Open.HD_Image_Builder/issues/47

The APP is hard coded to settings-1.txt . It does not appear to adjust if user selects a different settings number file via gpio.

Perhaps the app needs an option to select which settings file to actually write to

In an effort to stay organised and so we can all be on the same page and avoid duplication of work.
As Jelle suggested, baby steps with this and a lot of rebuild/test cycles

Wfb=wifibroadcast

Obviously not just a 2 step process but here are the 2 big parts I see.

1. Remove wfb from dir names in repo and modify builder

2. Change the wfb-1.txt to OpenHD-1.txt

Thoughts? Do we want to go further in depth searching for any wfb reference? Should we avoid capitalization in the code when referencing OpenHD i.e. above use openhd-1.txt instead?

Does not display with Encryption RC. Not sure where to look here.

Tere is an SSH Bug on the latest builds (4/29 and 5/3)

It appears to be due to the fact that SSH is no longer enabled by default on raspbian. (With Debug=Y)

I connected a monitor and USB keyboard going into raspi-config trying to enable it manually but, doing that simply freezes during boot screen/SSync.

Another option was to add a file named "ssh" without an extension to the boot partition in order to enable SSH but this did not work either... (I might not have done it correctly).

Link about ssh...

https://learn.adafruit.com/adafruits-raspberry-pi-lesson-6-using-ssh/enabling-ssh

In the dev branch currently the airpi has the framebuffer set off. Propose adding a variable in settings to enable turning it on or off so text can be displayed for debugging. Might consider leaving framebuffer off for groundpi and only turning back on for error...

Just found an issue in the current change-settings-scripts implementation that is worth mentioning:
(It will be fixed in the new implementation, but until then keep it in mind:)

Changing the FREQ via the app overrides the FREQSCAN value.
Example:
Before:
FREQ=2372
FREQSCAN=N

After:
FREQ=2372
FREQ=2372

Unfortunately FREQSCAN starts with FREQ and is therefore overridden by the script

3 cards trigger errors after approximately 30 min runtime.

As Open HD is significantly different than ez the wiki needs some serious updating. Here is a list of new subjects that need to be explained

Audio
App Usage
Assigning MAC
Bandswitcher
Encryption
Gpio- quite different now compared to EZ
Introduce Image Builder
Supported Cards and their limitations

Please comment and add more stuff that needs to be worked on. Or even better, write it up! 😋

Good morning,

i checked out the sources yesterday and build a fresh Image. This Image is not booting on a RPi 3A+.
I tried the same Image (on the same SD) with a Pi Zero and a Pi3 -> and it works without problems.

Just to be sure i used the image on a second RPi 3A+ with the same results. It's not booting.

Maybe someone can have a look at this ?

Jens

Setting foundation So we can run optimized profiles for each model

Application would be INav, betaflight, cleanflight

Through MSP_SET_RAW_RC control through msp.

https://github.com/iNavFlight/inav/blob/c13d1ec0d16c90d605564107fc1de4f91c448cd3/src/main/fc/fc_msp.c#L1498

Now that Debug is needed for Ethernet ssh on air side, it makes sense to add this function to the app so no SD card editing is needed...

(Perhaps a little button on top of app or something)

A user from Dronebridge has made a request for a profile with no camera. The application would be for audio and telemetry only.

Some image links in wiki still point back to EZ...

@yves the gpio pic I uploaded needs to be renamed. I don't know how to rename it. If you could tell me or do it I would appreciate it! thanks!

The barometric altitude does not update with either imperial or metric units.

The test bed has an RPi Model 3 A+ as airpi, RPi Model 3 B+ as groundpi, mRo Pixhawk with Arduplane 3.9.5, Mission Planner 1.3.64, build 1.3.7032.578, Windows 10 Dell laptop and one Alpha 36NHA adapter on each end. A Taranas X9D provides the joystick inputs.

The barometric altitude data in Arduplane and in the Mission Planner HUD responds to altitude changes.

I uncommented the portion of the osdconfig file that corresponds to the baro altitude:

#define BAROALT
#define BAROALT_POS_X 93
#define BAROALT_POS_Y 16
#define BAROALT_SCALE 0.6

I also tried it with the altitude ladder on and off and made sure that the setting was to use barometric altitude:

//#define ALTLADDER
#define ALTLADDER_POS_X 87
#define ALTLADDER_SCALE 1.1
#define ALTLADDER_USEBAROALT true // set to true to use barometer altitude instead of gps altitude

April 14 Open.HD release. The test bed has an RPi Model 3 A+ as airpi, RPi Model 3 B+ as groundpi, mRo Pixhawk with Arduplane 3.9.5, Mission Planner 1.3.64, build 1.3.7032.578, Windows 10 Dell laptop and one Alpha 36NHA adapter on each end. A Taranas X9D provides the joystick inputs.

With everything up and running nominally, I pull the USB cable connecting the Taranis joystick controller to the groundpi. The system goes into failsafe and issues a message on the Mission Planner HUD that there is no RC Receiver. The flight mode changes to RTL as programmed in Arduplane.

I restore the joystick connection and after 15 seconds the failsafe event ends. The system sees the RC receiver again and I can see the PWM channel values changing in the "Status" tab of the Mission Planner display, including the flight mode channel.

However, the flight mode no longer changes in response to flight mode commands from the joystick.

Hello,

I test the last revision (wiki download link) and STBC is not activated….

This feature permit to use all the antennas of the 88XX chipset for best performance….

Vasily and Yes21 made it work….

Could you please add it to next official release?

This parallels the other ethernet issue not working.

However, I noticed that the smart sync screen just stays locked to screen if ethernet is connected to the ground...

Aerodump seems to run through channel scans but does not end up displaying any useful information afterwards... This did work well with 1.6 and I believe some people still use it. If we do not want to continue using it, we could remove it all together...?? Thoughts???

1-8 analog channels are very valuable and should be used mainly for general control of aircraft, or we should consider using 9-16 switch channels to perform camera switching, band switching and other special functions.For example, 4-way camera switching can be completely realized with the combination of 9ch and 10ch switch channels. The same is true for band switching. It is very convenient to set mixed switch channels on the RC of open tx firmware.

The save video function over USB after flight is reported not to be working, please investigate.

With a new image release the code here should reflect the latest release. How does everyone (@careyer @RespawnDespair @bortek @htcohio @Yes21 @user1321) want to do this migration?

1- Leave the underlying structure the same and just bring over the relevant builder that points to @RespawnDespair repo or @user1321 repo?
pros/cons less work but we are still dancing around through multiple repos...

2- Change the builder structure so that all source (other than pi, drivers, etc) is contained in this repo?
pros/cons more work but more easily managed and workable in the long run- this raises the question as far as how to structure it- Just directories for what is currently other repos?

Other decisions will need to be made as far as promoting development here. I propose at least a master branch that reflects the latest stable release and at least one development branch. Ultimately it would be nice to see everything come under one roof. Thoughts?

1) Overview
I want to create a simple server program for the Open.HD pi that makes it easier for external devices to query Informations about the system, change settings and communicate over a lossless TCP connection.

2) Implementation:
The program should listen for incoming TCP connections on a fixed port. This will be implemented as a simple main loop like most Open.HD scripts.
For communication I am going to use a simple text -based protocol. Unless I find another library for that, I'l just send utf-8 strings over TCP, terminated by a newline character.

Milestone 1:
Query the Open.HD version / build number.
The server should respond to 'VERSION \n' with 'Version X\n'
More milestones will follow shortly.

https://github.com/HD-Fpv/Open.HD/blob/1e0507fb054164f6c134333818142763a7979ebd/wifibroadcast-osd/ltm.c#L167
https://github.com/HD-Fpv/Open.HD/blob/1e0507fb054164f6c134333818142763a7979ebd/wifibroadcast-osd/ltm.c#L168
https://github.com/HD-Fpv/Open.HD/blob/1e0507fb054164f6c134333818142763a7979ebd/wifibroadcast-osd/ltm.c#L169

Pi zero gpio pins get read at 30s mark during boot