LibrePilot Forum
Development => Firmware General => Topic started by: KarlNapf on December 22, 2016, 07:19:29 pm
-
Hi all,
With the release of LP 16.09 I decided to do the step from OP to LP finally.
I'm running a genuine OP Revo board with the original OP V9 GPS.
During the first dry runs on the workbench, I noticed that the System Health tab
every now and then shows the GPS data as invalid (red "X"). This condition clears
within a second, then keeps ok for 10 to 20 seconds and happens again...
The time span between the occurrences is variable - see the attached Scope/GPS
screenshot.
I disconnected and re-inserted all cables to exclude electrical contact issues.
I downgraded to OP 15.05.02, this version does not show the effect.
I upgraded to LP 15.09, this version does also NOT show the behaviour.
The good thing is: this problem is easily reproducible. As soon as I put 16.09
on the Revo (and do a minimal config via Vehicle Setup Wizard), it shows up.
Btw. I always do the "Erase Settings" before and after version changes.
I attached a .uav file for reference - this is not the setup I'm going to fly with,
just the result of an "Erase Settings" and a quick run through the Vehicle Setup
Wizard.
To me it appears that some kind of timing (eg. wait for valid data) became too
tight with version 16.09. Any ideas?
-
Hi,
Current version is less tolerant and show errors.
You may need to update the OP GPSv9 with new firmware.
GPS issue : https://librepilot.atlassian.net/browse/LP-252
There is various methods, one with stm32flash + ef_gpsplatinum.bin (ef = Entire Flash)
and other with
OPUploaderTool.exe + fw_gpsplatinum.opfw
** You may need to copy the OPUploaderTool.exe close to the librepilot-gcs.exe under c:\Program Files\Librepilot\bin\ directory for Qt dependencies
See attached notes how to flash and firmware, preferably using OPUploaderTool.exe
8/05 Added the new UploadTool.exe file, should works for windows users.
-
Hi Laurent,
thanks, that hit the nail. My GPSv9 obviously has an OP bootloader:
Power on, orange LED lit, then becomes a bit brighter, then starts blinking slowly...
So I skipped part A.
In deed, the uploader tool need to find the Qt stuff - I've learnt this the hard way,
I should have been more patient and wait for your additions to your answer :)
I managed to get to the "SYNC Succeeded" message, but after this,
the tool quits with
QObject::killTimer: Timers cannot be stopped from another thread
QObject::startTimer: Timers cannot be started from another thread
____timeout
Error:Invalid Device
Shorting the pads is mentioned within the step A procedure only.
Do I need to do this for the pure firmware update (B), too?
PS: I'll try the stm32flash with ef_... file and shortened pads tomorrow.
-
What command line you use with uploadertool ?
Be sure the com port used by the ftdi/board is ok.
Just tested under Linux and it works:
[laurent@new-host LibrePilot]$ ./build/uploader_release/OPUploadTool -i -p ./build/firmware/fw_gpsplatinum/fw_gpsplatinum.opfw -t /dev/ttyUSB0
OpenPilot serial firmware uploader tool.
Connect the board
[==================================================] 100%
Connect the board NOW
SYNC Succeded
Uploading...
Erasing, please wait...
Uploading firmware
Uploading firmware[==================================================] 100% Firmware Uploading succeeded
Starting uploading description
Uploading firmware[==================================================] 100% Uploading Succeded!
Tested the win32 and i see the same error.
(https://forum.librepilot.org/index.php?action=dlattach;topic=2780.0;attach=4860)
You may try the stm32flash/entire flash method, need some timing while connecting the device.
-
Windoze here :-[ either 32 or 64 bit, but still M$. :'( Guess the Qt version for Windows caused the errors.
I tried the combridge way to access the GPS+MCU port of the GPS through the Revo.
I know the combridge access is working, as I checked this with the u-blox u-center tool just before.
(Had to shift the com port number from com13 to com4 as the tool apparently accepts single digit numbers only)
When I intentionally start the tool with a non-existing com port as parameter, it doesn't even get to the
"SYNC Succeded" state, so as I got the "SYNC Succeded" message, I believe there was a minimal
communication via the correct com port at least.
Somewhere on my harddisk is an Ubuntu vmware image, maybe I should try to bring up the
GCS and the OPUploaderTool with Linux and see if I can map a PC USB-port to the virtual machine...
Anyway, all these are not OP/LP related problems.
-
You might even try a bootable Linux CD. I would try Mint-Mate. OPUploadTool is a simple text program that might run that way. All you would have to do is get the tool and firmware hex file accessible.
The GPS drivers were made to be a bit more verbal about errors they see.
There is a Ublox issue where the GPS drops all satellites, looses fix, then gets fix back with all sats (maybe minus 1), but the coordinates have jumped. The jumped coordinates is the problem. It can jump a hundred meters or more and that isn't good for your position hold. The jump coordinates quickly drift back to close to the original location.
This is not an LP issue because you can "show diagnostics" (raw GPS, not cooked after EKF) on the map and you can see that the jump drifts back. The jump and each coordinate set in the "drift back" came straight from the GPS. If you can recreate your issue, I suggest that you leave the GPS in one place and watch the GPS map to see what happens to the coordinates when this happens. When I do this, I see a normal wandering around a smallish area, then a jump of several meters and a slow drift back to the original location.
This seems to happen worse in locations where multipath is an issue, for instance next to buildings or indoors. It also happens even if you have allowed time for a full GPS almanac download.
-
Ok, after one evening of unsuccessful struggle with the com-port handling of M$ and the pain of Windows-ported Unix
tools I can report: the firmware is in, the GPSv9 is up and running, no drops in the data flow any more.
I had to use the stm32flash tool on a Raspberry and an FTDI-type adapter to establish a reliable com-connection...
What an effort just to transfer 32k of code ;D
About the position jumps: I can remenber that I've seen something like this when I have the copter indoors on my desk,
but I blamed the general weak reception situation for it. I've never noticed this in flight - guess the EKF does its job and
dampens the error - but i'm not using P/H or the other GPS-based modes too often. Thanks anyway for the warning.
As the number of supported GPS+Compass types increases, a change could be an option. Any recommendations?
Best regards, merry Christmas!
-
Well done :)
-
Ok, after one evening of unsuccessful struggle with the com-port handling of M$ and the pain of Windows-ported Unix
tools I can report: the firmware is in, the GPSv9 is up and running, no drops in the data flow any more.
I had to use the stm32flash tool on a Raspberry and an FTDI-type adapter to establish a reliable com-connection...
What an effort just to transfer 32k of code ;D...
You're probably the first person outside the developers who is actually running the new GPS V9 code. :)
-
Well, perhaps I am the last one who still runs an old OP GPSv9? 8)
(outside the devs., of course)
-
Thanks for this post. I have three V9's that are in retirement because of this issue, I never knew this fix was available.
The fix is way outside my skill set at this point in time but eventually I will take the time to learn how.
-
It isn't bad. You plug the USB to Serial adapter (FTDI is a common brand) first and type the command line to do the flash (without pressing return), then quickly and together plug the GPS in to the adapter then press return. At least that is what I recall. I did it several times and it worked the first time every time. I don't recall, but it may have been necessary to short out the SBL pads on the GPS...
-
Ok I'll give it a try, thanks for the encouragement. Not sure which flavor USB to serial adapter, there seem to be several. Would you mind pointing me to one?
-
Hi,
Current version is less tolerant and show errors.
You may need to update the OP GPSv9 with new firmware.
GPS issue : https://librepilot.atlassian.net/browse/LP-252
There is various methods, one with stm32flash + ef_gpsplatinum.bin (ef = Entire Flash)
and other with
OPUploaderTool.exe + fw_gpsplatinum.opfw
** You may need to copy the OPUploaderTool.exe close to the librepilot-gcs.exe under c:\Program Files\Librepilot\bin\ directory for Qt dependencies
See attached notes how to flash and firmware, preferably using OPUploaderTool.exe
I remember i have used the op 15.05 a year ago, and try velocityroam on a 250 size copter,have not found any strange thing.
Do you mean the old gpsv9 firmware(15.05 or 15.09) still have the problem ,that may have errors, and the 16.09 have fix the errors use new EKF solutions, i should upgrade the firmware?
-
GPS v9 firmware in the 15.xx releases had a bug that sent the FC a couple of corrupted packets each second. The FC routines just ignored them. In early 2016 when TheOtherCliff was working on adding support for the DJI Naza protocol into the FC he noticed the corrupted packets and told me. https://librepilot.atlassian.net/browse/LP-252 I fixed the firmware and it was merged into the next branch in March 2016. The next actual release after that was 16.09. Sometime in the last year the FC firmware was also changed to make it report those previously unreported errors.
The GPS v9 firmware changes didn't affect the EKF solutions, they just eliminated a bug that sent corrupted packets.
-
GPS v9 firmware in the 15.xx releases had a bug that sent the FC a couple of corrupted packets each second. The FC routines just ignored them. In early 2016 when TheOtherCliff was working on adding support for the DJI Naza protocol into the FC he noticed the corrupted packets and told me. https://librepilot.atlassian.net/browse/LP-252 I fixed the firmware and it was merged into the next branch in March 2016. The next actual release after that was 16.09. Sometime in the last year the FC firmware was also changed to make it report those previously unreported errors.
The GPS v9 firmware changes didn't affect the EKF solutions, they just eliminated a bug that sent corrupted packets.
You mean the ublox give some corrupted packets to FC every seconds, firmware of 15.xx may use them and may give some position jump, and the new firmware just ignored these corrupted packets to cause error?
-
No, the GPS v9 firmware sent corrupted packets to the FC, it had nothing to do with the ublox module. It didn't actually affect anything because the FC was throwing away the bad packets. The FC wasn't reporting that it had received and ignored the bad packets so no one noticed them. Now the GPS v9 firmware has been changed to not send the corrupted packets and the FC firmware has been changed to report any bad packets. If you run 16.09 on the FC and the old pre-16.09 firmware on the GPS you may see errors reported.
-
Hank, just a follow up question.
I have 4 of these 'old' GPS/Mag boards, does these changes to the GPS v9 firmware and the changes to the GCS of LP 16 also have effect on the Magnetometer?
Should I upgrade my GPS boards when using latest LP version?
K
-
I recall that it can corrupt any packet, and that would mean it would corrupt some mag packets too, but then the checksum is bad so it ignores any bad packet.
You can use the new (fixed) GPS firmware with any FC firmware that can talk to a GPSv9; old OP or old LP or new LP.
-
Thanks Cliff, I think this spells out I need to upgrade the firmware on the GPSv9.
-
Is there an easy way to update firmware GPS V9 with Win10?
It 'best gps naza clone or V9?
I have original Revolution.
thank you
-
It looks like there is an issue with the Windows version of OpUploadTool.
https://forum.librepilot.org/index.php?topic=2780.msg19383;topicseen#msg19383
I have used the Linux version 5 or 10 times though.
It looks like it requires that qt is installed.
-
Thank you, TheOtherCliff.
It 'best gps naza clone or V9? https://www.amazon.it/Goolsky-NEO-M8N-compatibile-controllore-volo/dp/B01M7ULUPK/ref=sr_1_8?ie=UTF8&qid=1483741533&sr=8-8&keywords=gps+per+naza (https://www.amazon.it/Goolsky-NEO-M8N-compatibile-controllore-volo/dp/B01M7ULUPK/ref=sr_1_8?ie=UTF8&qid=1483741533&sr=8-8&keywords=gps+per+naza)
-
They are both good GPS. I have both and use both. We can change firmware in the GPSv9 if we need to, but it is difficult to find and expensive when you find someone making them. DJI is available now, and everywhere.
The DJI GPS that you linked is a clone. They work, but just to let you know, you can buy authentic DJI Naza GPS for USD $37 (shipped) on eBay (and cheap DJI GPS clones too).
http://www.ebay.com/itm/Original-DJI-Naza-M-Lite-GPS-Module-with-GPS-Bracket-for-RC-Multi-rotor-N7Q4-/291939192093
-
The authentic one is better but that auction doesn't ship to Italy or a lot of other places, mostly he ships only to the USA.
-
So reading below I understand you can update the firmware of GPS V9 using the OpUploadTool under Linux and maybe Windows, but how about using MacOS?
I am setting up a Windows PC but if there are issues I might better find another way...
-
I need to boot a Live Linux DVD, install a few dependencies, write some instructions. It should be fairly easy...
Of course it works fine from my Linux dev PC that already has the dependencies installed, but we need instructions that others (Windows and Mac) can use, till we get the Windows OpUploadTool.exe version fixed.
-
OSX version should work because initially used under OSX.
If you setup a minimal build environment you should be able to build the executable.
https://librepilot.atlassian.net/wiki/display/LPDOC/Mac+-+Building+and+Packaging
Or someone around with OSX, posting the executable.
but we need instructions that others (Windows and Mac)
Instructions are in second post of this thread.
-
f5soh, not sure i understand. Do you mean that if the source code of the OpUploadTool.exe tool is build under OSX then it will result in an app that that can be used on a Mac to upgrade the OP GPSv9?
I have a build environment (xcode, home-brew, sdl) but not sure what code to use or how to get it.
Are these the instructions to be used from post 2?
Early test stage documentation
How to upload the firmware
the following operations are done using the gps firmware development branch that is located amorale/OP-1476_1477_1275_GPSV9_pios_firmware_bootloader
checkout the branch using the following command
git checkout origin/amorale/OP-1476_1477_1275_GPSV9_pios_firmware_bootloader
build the uploader and firmware using
make stm32flash_install uploader ef_gpsplatinum fw_gpsplatinum -j4
you will find:
uploader under ./build/uploader_release/OPUploadTool
firmware under ./build/fw_gpsplatinum/fw_gpsplatinum.opfw
entire flash image under ./build/ef_gpsplatinum/ef_gpsplatinum.bin
stm32flash under ./tools/stm32flash/stm32flash
-
I don't have a mac, I'm on linux but when you do a "make all" of the code it automatically creates the upload tool in ./build/uploader_release. Doesn't the mac version do that too?
-
yes, this command will made the uploader and GPS firmware:
make uploader fw_gpsplatinum
-
Is the Windows version of OpUploadTool still broken? Is there a Jira to fix it?
-
I will look into it soon as I might need to update my opgpsv9 platinum. I have solid PH on 16.09 but have noticed I get a red x health status occasionally. I'll need to look to see if there were lost packets.
-
Also, I thought the gps firmware updated automatically when connected? Or is that just the ublox configs automatically?
-
Firmware update is not automatic, just settings with autoconfig.
Take a look at second post in this thread
If you build the uploader from next, the windows command line uploader should works now.
-
well looked at my gps and def getting the packet errors every few seconds...
unfortunately I am completely lost in flashing the firmware, can't even find where to start with the instructions from the 2nd post haha I don't think I have the programming skills to get it done : /
-
B - Firmware
This is performed using the uploader tool.
Connect a usb serial adapter or a CC/CC3D/revo configured with combridge at 57600.
Run the following command
UploaderTool -p ./build/fw_gpsplatinum/fw_gpsplatinum.opfw -t COMxx
Where COMxx is the serial com port from your USBSerial or Virtual Com Port using CC3D/Revo in Combridge config.
Quickly attach the gps using MCU+GPS port
it should show the sync succeded message and start uploading the firmware.
If it fails retry
You can also connect and start the tool without the initial wait progressbar if you find that more easy to do:
UploaderTool -i -p ./fw_gpsplatinum.opfw -t COMxx
Combridge setup like here but 16.09 do not need baudrate settings :
https://librepilot.atlassian.net/wiki/display/LPDOC/Setup+a+bluetooth+for+telemetry#Setupabluetoothfortelemetry-CC3D-VirtualCOMport-Combridge
-
Just for clarification, updating the GPSv9 (gpsplatinum) firmware is not a requirement. The old GPSv9 firmware only looses a small percentage of packets (not a humanly noticeable flight difference) and it has always been this way; even back to the OP days. It used to simply ignore these bad packets.
It's only now that these bad packets are fixed in the current GPSv9 firmware that the missed packets are reported in the FC firmware; so you know that there is an issue that you can fix by updating the GPS firmware.