b3nn0 / stratux

Fork of the original cyoung/stratux with multiple patches for flying in europe
BSD 3-Clause "New" or "Revised" License
155 stars 66 forks source link

gps manual configuration via config system #266

Closed paony closed 10 months ago

paony commented 10 months ago

support manual configuration of gps parameters.

parameters are implemented in the config system but not yet in the web frontend. You can change them by editing the config file: nano /boot/stratux.conf Should these options be accessible from the web frontend?

at the moment the following parameters exist:

GpsManualConfig true or false, default false set to true to use manual config if set to false behaviour is exactly as it was before this change, settings below are ignored

GpsManualChip possible values: ublox6, ublox7, ublox8, ublox9, ublox, unknown ublox: just run the generic ublox setup code unknown: do not recofigure gps at all, just try to connect probably ther should be additional options, I only have an ublox device so I could not test them. Further options should be easy to implement.

GpsManualDevice default is "/dev/ttyAMA0"

GpsManualTargetBaud the baudrate to be used for the gps connection after reconfiguring. defaults to 115200 which is also the hardcoded value for current ublox auto config. much higher baud rates are possible: with a raspberry pi 4 and a Beitian BK-182 gps (ublox9) 1000000 baud worked very well the following baudrates are autodetected at startup: 115200, 38400, 9600, 230400, 500000, 1000000, 2000000

additional option: ClearLogOnStart (bool) default yes useful for testing

b3nn0 commented 10 months ago

Looks good to me. Only remark: You replaced a few if globalSettings.DEBUG { with if false. Mind undoing those? Or probably rather replace with your new logDbg function?

I prefer it not being in the web interface. It is a very individual setup, and users seem to love to randomly configure stuff without knowing what it does. Most users use the USB GPSes anyway. It might make sense to write a short wiki page describing the options, though, if you don't mind.

VirusPilot commented 10 months ago

Please add ublox10 to the list of possible values for "GpsManualChip". The u-blox M10 is used more and more and particularly on the T-Beam Supreme.

paony commented 10 months ago

You replaced a few if globalSettings.DEBUG { with if false. Mind undoing those? Or probably rather replace with your new logDbg function? -> I just forgot to re-enable that logs, will do that

I prefer it not being in the web interface. -> I agree

It might make sense to write a short wiki page describing the options, though, if you don't mind. -> I will do that once the code is merged

Please add ublox10 to the list of possible values -> I have an ublox10 myself and have thought about it. The reason that I have not added it, is that I have not found any dedicated ublox10 configuration code in gps.go. I can add it - but which configuration code should be used then? ublox9? would it make sense to also add a config parameter for the refresh rate, then? Or is the refresh rate configured by by the T-Beam Supreme? Maybe there should be an option TBeamSupreme for GpsManualChip with specific TBeamSupreme setup code?

VirusPilot commented 10 months ago

The u-blox M10 default parameters are good enough, I am changing them inside the SoftRF code but there is at least one case in the Stratux code where an M10 case would make sense. TBeamSupreme is maybe not a good idea as there is an alternative TBeamSupreme version with a different GPS chips.

VirusPilot commented 10 months ago

Here are the parameter sets for M10 that I am using in SoftRF: https://github.com/VirusPilot/SoftRF/blob/1fabe7f525086b129daede912a981363d31f1af2/software/firmware/source/SoftRF/src/driver/GNSS.cpp#L225 And here is the section where the parameters are applied: https://github.com/VirusPilot/SoftRF/blob/1fabe7f525086b129daede912a981363d31f1af2/software/firmware/source/SoftRF/src/driver/GNSS.cpp#L556

paony commented 10 months ago

ok I will add ublox10 then. To be consistent with the other options, it has to be optimized for a ublox10 device attached directly to the raspberry pi uart and not for some special hardware, so it will just run the generic ublox setup code for the moment. If that works for you that should be fine. If you need to run some t-beam-supreme specific setup code on the stratux side, maybe there should be another option like "ConfigureSpecificHardware" that can be set to t-beam. That code could then also read the ublox version set via GpsManualChip and setup the b-beam according to the ublox version

b3nn0 commented 10 months ago

When adding it like this, IIRC it also needs to be added here to show correctly on the web interface: https://github.com/b3nn0/stratux/blob/d86cbf1739a6cb6ecd6ea48519a02738ee6e197a/web/plates/js/status.js#L88

paony commented 10 months ago

@b3nn0 Ah, I haven't seen that file before. Here the options are prefixed with "USB" ("eg. USB u-blox 9 GNSS receiver"), what is not true for a direct serial connection. So how do you want this to be solved? Remove the "USB"? Or replace it with "USB/serial" Or anything else?

Additionally there seem to be only very few unused constants left, because the constants are masked with 0x0f in status.js line 86, which limits the usable range from 0 to 15. What is the reason for this masking?

b3nn0 commented 10 months ago

Hmm, feel free to remove the "USB" part.. guess it's not always true. The reason for this masking is, that globalStatus.GPS_detected_type is a combination of the detected GPS Chip, and the protocol that is in use (usually NMEA). See e.g. here: https://github.com/b3nn0/stratux/blob/d86cbf1739a6cb6ecd6ea48519a02738ee6e197a/main/gps.go#L1154C2-L1154C2

Don't ask me why it was done like that in the first place - that was before my time. But unfortunately, it will be hard to change that without potentially breaking backwards compatibility..

VirusPilot commented 10 months ago

ok I will add ublox10 then. To be consistent with the other options, it has to be optimized for a ublox10 device attached directly to the raspberry pi uart and not for some special hardware, so it will just run the generic ublox setup code for the moment. If that works for you that should be fine. If you need to run some t-beam-supreme specific setup code on the stratux side, maybe there should be another option like "ConfigureSpecificHardware" that can be set to t-beam. That code could then also read the ublox version set via GpsManualChip and setup the b-beam according to the ublox version

I can certainly provide code for that but keep in mind that SoftRF does not allow "passthrough" GPS configuration but other tracker implementations might allow for it.

b3nn0 commented 10 months ago

Alright, looks good to me. If you consider it finished, I will merge.

paony commented 10 months ago

I will just cleanup some comments and some logging - I well let you know when I'm done

paony commented 10 months ago

finished, ready for merging I'll start creating a wiki page about GPS the