[KarlNapf]

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?

[f5soh]

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.

[KarlNapf]

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.

[f5soh]

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:

Code: [Select]

[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.

You may try the stm32flash/entire flash method, need some timing while connecting the device.

[KarlNapf]

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.

[TheOtherCliff]

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.

[KarlNapf]

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 

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!

 

[f5soh]

Well done

[hwh]

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  ...

You're probably the first person outside the developers who is actually running the new GPS V9 code. 

[KarlNapf]

Well, perhaps I am the last one who still runs an old OP GPSv9?   
(outside the devs., of course)

[ggrif]

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.

[TheOtherCliff]

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...

[ggrif]

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?

[xfce]

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?

[hwh]

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.