LP-543 updated .drone.yml and regenerated .drone.sec for Tea-CI
Approved-by: Marcus Proest <proemarc@gmail.com>
Approved-by: Lalanne Laurent <f5soh@free.fr>
Approved-by: Philippe Renon <philippe_renon@yahoo.fr>
LP-540 Adds support for ms5607 and ms5637 to the ms5611 driver and renames it ms56xx.
Approved-by: Lalanne Laurent <f5soh@free.fr>
Approved-by: Alessio Morale <alessiomorale@gmail.com>
Approved-by: Philippe Renon <philippe_renon@yahoo.fr>
Approved-by: Jan NIJS <dr.oblivium@gmail.com>
Approved-by: Brian Webb <webbbn@gmail.com>
if a os specific file (for example default_linux.xml) is found it will be loaded
alongside the common default.xml file.
no os specific dfault files are provided yet...
a simple registry is used to track all configurations ever seen
only new configurations (i.e. not in the registry) are added
merging only applies to plugin and gadget configurations for now
LP-537 update f0 gps to be more similar
Approved-by: Philippe Renon <philippe_renon@yahoo.fr>
Approved-by: Alessio Morale <alessiomorale@gmail.com>
Approved-by: Lalanne Laurent <f5soh@free.fr>
Approved-by: Brian Webb <webbbn@gmail.com>
- I resolve the PRN text scaling issue by comparing the scaled text height with the available space.
If there is not enough space available, the scaling factor is updated so the final scale factor fills the available space as much as possible.
If the height limit has been reached, the corrected scaling is applied to both the PRN and the SNR text to keep both about the same size.
- This scaling works fine on my Windows PC. I therefore removed the maximum width limit for the snrwidget. (was 850px)
The snr widget will now take up all available width. This does not mean that individual bars will be scaled to fit the width of the widget.
However I have implemented a two step scaling for that. If there are less than 16 visible satellites, the width of each bar is calculated
based on a total of 16 bars in the view. Just like before my changes. If there are more than 16 satellites visible, the number of bars displayed
is incremented from 16 to 24. An aging based hysteresis has been added to prevent continuous flapping between both states.
I think this solution is aesthetically more pleasing than scaling the width of the bars to the width of the widget.
Especially for low number of satellites. (This solution would show massive bars if only a few satellites are visible)
- Since there was no copyright header in gpssnrwidget.cpp and gpssnrwidget.h, I have added one. The OP line is based on the last changes seen in the OP repo.
- more professional looking toggle code.
- change PRN font to Digital-7
- updated font size factor for SNR PRN text from .56 to .68
- moved a few class includes from the .h to the .cpp file & forward declared QGraphicsSvgItem class in flatearthwidget.h
- hide marker before resize, display it again after resize.
- corrected issue where marker was crawling to the south on continuous resizes.
Instead of nudging the marker, added a proper forceUpdate parameter to the setPosition() function.
- made sure that only one @author tag is present.
- centered both flatEarth and constellation widgets in their boxes.
- lowered resolution of the map image 1440 -> 1080 & used JPG instead of PNG. Size went from 1105KB on disk to 155KB on disk (PNG version for this resolution is 634KB).
The resolution change has a minor impact on the level of detail seen in the zoomed view.
- added margin for the SNR widget. Although I start to think the SNR widget isn't all that interesting. Removal may be an option.
- Also removed gridLayout_2 from the top left, leftover from a test.
- Delete scene in the widget destructor. I saw this was done in constellation widget, therefore did the same.
I used NULL instead of 0. Looks more correct for pointers to me.
What I didn't implement:
- wider bars in the SNR widget when less than the max number of satellites are shown.
Currently the total width of the SNR widget is limited to 850px. If we go wider with the current implementation, the text becomes too large.
At this time, I don't have a good idea how to handle that.
There is no need to transmit one telemetry update per second for this uavo on controllers where no OP-GPS is present.
For the controllers where an OP-GPS is present, the FlightTime field updates will trigger a telemetry update.
UBX-NAV-SVINFO (id 30) and UBX-NAV-SAT (id 35) packets are NOT critical to the navigation.
Their only use is to update the nice GPS constellation widget in the GCS.
These packets become very large when a lot of SV (Space Vehicles) are tracked. (8 + 12 * <number of SV>) bytes
In the case of 3 simultaneously enabled GNSS, it is easy to reach the currently defined tracking limit of 32 SV.
The memory taken up by this is 8 + 12 * 32 = 392 bytes
The NEO-M8N has been seen to send out information for more than 32 SV. This causes overflow errors.
We will ignore these informational packets if they become too large.
The downside of this is no more constellation updates in the GCS when we reach the limit.
An alternative fix could be to increment the maximum number of satellites: MAX_SVS and UBX_CFG_GNSS_NUMCH_VER8 in UBX.h
This would use extra memory for little gain. Both fixes can be combined.
Tests indicate that, once we reach this amount of tracked SV, the NEO-M8N module positioning output
becomes jittery (in time) and therefore less accurate.
The recommendation is to limit the maximum number of simultaneously used GNSS to a value of 2.
This will help keep the number of tracked satellites in line.
