FrSky GPS questions

sporez · Post by **sporez** » Mon Mar 26, 2012 11:03 pm

Well now that my radio is modded for telemetry (thanks Erez!

) I've been getting the FrSky hub and GPS set up. I haven't had a chance to test it in flight because of the weather but just doing some ground testing I've noticed that after the GPS gets a lock it starts saying my altitude is 200-something feet. Why is it telling me that when I'm on the ground? Is there a setting I need to adjust or something?

Also, I'm a little confused on what the two analogue ports on the side of the RX can be used for??

sporez · Post by **sporez** » Tue Mar 27, 2012 7:24 pm

Today I was able to try the gps out in air. Overall it did very well. Altitude would not zero however. On the ground it was reporting about 270ft. However in air it did seem to go up and down as appropriate it was just 270ft too high. Maybe there needs to be a feature in er9x to zero the gps altitude??

Crashj007 · Post by **Crashj007** » Tue Mar 27, 2012 7:41 pm

So where are you? New York? Altitude is MSL in the GPS.

sporez · Post by **sporez** » Tue Mar 27, 2012 9:00 pm

Yes Western NY...It appears where I am it's about 273 meters ASL so that might explain it. So the GPS is measuring altitude in meters then??

Post by **MikeB** » Tue Mar 27, 2012 9:52 pm

I'll look into a 'zero the altitude for GPS', we already have one for the FrSky vario and the WS how hi unit. Perhaps what we really need is an option to choose your altitude source, then just have a single altitude value to be displayed. The FrSky dispay also has a metric/imperial option as well.

Mike.

sporez · Post by **sporez** » Tue Mar 27, 2012 9:55 pm

Yes, a zero option would be great. And I have it set on imperial but it seems it's measuring altitude in meters...not 100% sure on that.

Post by **Kilrah** » Wed Mar 28, 2012 7:24 pm

From what I understood the imperial / metric only applies to the barometric altitude, not the GPS one, right?

sporez · Post by **sporez** » Sat Mar 31, 2012 5:15 pm

I'm not sure. It'd be nice if one of the developers could confirm what exactly it is measuring in.

Post by **MikeB** » Sat Mar 31, 2012 5:30 pm

I'm putting an option in to er9x that will allow the GPS altitude reading to be used instead of the barometric reading. All the code that follows the barometric reading, e.g. zeroing, metric/imperial, altitude alarm, will then apply. This will be visible on the telemetry screens that currently display the barometric or WS how hi value. At his point, the GPS altitude value (on the screen with LAT and LON) will continue to display the raw GPS altitude reading.
Not sure when this will get out, busy with the first Beta testers of ersky9x, but will try to release sometime this weekend.

Mike.

sporez · Post by **sporez** » Sat Mar 31, 2012 10:58 pm

Great news!

thanks.

Post by **MikeB** » Sun Apr 01, 2012 2:57 pm

I've just committed new sources, when Erazz gets a chance he will build them and the new hex files will be available. I don't have a GPS on my tlemetry so can't fully test it, but there is an option to select the GPS altitude as the main altitude source, the you should be able to zero it, set it to imperial, and have an alarm.

Mike.

ReSt · Post by **ReSt** » Sun Apr 01, 2012 4:51 pm

Looks like there is something missing.
When I compile the downloaded r746 I get for menus.cpp:
'PARAM_OFS' was not declared in this scope
'onoffMenuitem' was not declared in this scope

Reinhard

ReSt · Post by **ReSt** » Sun Apr 01, 2012 5:42 pm

Tried to compile with the old menus.cpp from r744
Compiled without error, but I get reproducable reboots when I return from the telemetrie screen and and then use right[long] key.
I have a sequence that reproduces the failure nearly every time.

But I assume there is simply an incompatibility between the two menus.cpp files.

Reinhard

Post by **MikeB** » Sun Apr 01, 2012 7:30 pm

Try r747!. I move onoffMenuItem() up the file, but dropped it in a #if FRSKY area, so the FRSKY version compiles OK, but the standard version did not.

Mike.

ReSt · Post by **ReSt** » Sun Apr 01, 2012 9:12 pm

Thanks Mike,

r747 compiles ok

BUT

the reboot problem still exists (used the original frsky-nht version)

And this is the procedure how I can recreate the reboot:
(Keyname without [long] means key[short])

Starting on the sytem screen with the horizontal bars
Model 5 (Amigo2) is activ.
Press right[long], right ... till screen 9/11
down, right, menu, (to change metric to imperial or vice versa. Doesn't make a difference)
left, exit, exit (back on system screen)
down[long] (telemetrie screen)
right, left
down (back on system screen)
right[long] --> rebooting

I'm appending the erpom file in case it has something to do with it.

Reinhard

Post by **MikeB** » Sun Apr 01, 2012 9:38 pm

That is really weird, I can reproduce it, but is needs a very specific sequence to make it happen. It seems you do have to change the met/imp field to make it go wrong!
This may take a while to find.

Mike.

ReSt · Post by **ReSt** » Sun Apr 01, 2012 9:46 pm

It does not depend on the single field.
I found that it happens when you change ANY field on that panel

Got it with WSHI and also with changing the A1Channel voltage.

But seems not to happen, when you do not change any value.

With my 'special' compiled version I had to step at least two screen right in the telemetrie screen to get the failure.

Reinhard

ReSt · Post by **ReSt** » Sun Apr 01, 2012 10:29 pm

Found out, that it does not reboot if you press exit[long] just before the last right[long]

Reinhard

Post by **MikeB** » Sun Apr 01, 2012 11:00 pm

It's a very specific sequence that causes this to happen, I changed something on the other telemetry screen and got the reboot, but I can't work out why its happening. Changing other screens does not appear to cause it to happen. It does appear to need the long[down] to make it happen, just stepping to the telemetry screen seems OK.
I shall have to leave it for now, too late, I'll get back on it tomorrow.

The two telemetry screens are special in that they cause telemetry data to be sent to the FrSky Tx module, maybe there is an odd interraction here.

Mike.

Post by **MikeB** » Mon Apr 02, 2012 7:44 am

Just went back to r744, got the same problem, now to find when it got introduced/what it is.

Mike.

ReSt · Post by **ReSt** » Mon Apr 02, 2012 8:48 am

Sure you will find it

More findings for the reboot
Reboot only happens when starting on specific system screens.

Using the key sequence from above

The sequence of the system screens with DOWN[short]:
two big timers ok
Sw 1 - Sw C ok
Sw 1 - Sw 6 ok
Sw Thr - Sw Trn fail
Stick bars fail
Stick digital values fail
Telemetry ok

Maybe that helps a little bit.

Additionally, I think the menu sequence for telemetry is confusing because you get the telemetry screen as a normal system screen with stepping DOWN[short] and also with DOWN[long] (at any time).
Then when you are on your (first) telemetry screen, RIGHT[short] or Left[short] goes either to the next telemety screens or to the configuration screens, depending on which 'first telemetry screen' you were (the sub menues or the system menues).
The same confusion takes place with EXIT[short] or EXIT[long].

I think, the telemtry screen from the above stepping sequence should be removed and telemetry always (and only) be reached with DOWN[long].

Btw,
GPS Altitude is not yet displayed in the screen with the rpm, even though GpsAltMain in screen 10/11 is set to ON. And this setting is lost with power off/on of the Tx

Reinhard

Post by **MikeB** » Mon Apr 02, 2012 9:12 am

Thanks. It is a watchdog reset that is causing the reboot.
I've noticed the watchdog is set to only 16.3 mS timeout. This is very short. It is possible that after changing the Met/Imp value, data is being sent to the tx module, the EEPROM is being updated, and then you change display screens. Going from one screen to another does not trigger the watchdog while it does so. It may be as simple as the code is taking more than the 16.3mS to get round the loop. I'm going to try extending the watchdog time to 65mS.

I'm fixing the lost GpsAltMain setting, I'll look at lack of displayed value later.

Edit: No, I'm wrong, the watchdog is not enabled until later, at 0.5 seconds. The splash screen runs without the watchdog running.
You may be right about down[long]. I could not make it fail if I just stepped to the telemetry screen (not down[long]). I think I'll remove the down[long] option and look into whether we make the telemetry screens separate from the main screen and use down[long] to get to them.

Mike.

ReSt · Post by **ReSt** » Mon Apr 02, 2012 10:07 am

Thanks, Mike.

No hurry, I will test it when your fix is available

Reinhard

Post by **MikeB** » Mon Apr 02, 2012 10:30 am

New sources up, I've probably masked the problem by removing the down[long] option to get to the telemetry screen. I may also have fixed the GpsAltitude setting and display.

Mike.

Post by **MikeB** » Mon Apr 02, 2012 12:18 pm

Testing, with the down[long] back in, I've changed the watchdog timeout to 2 secs, and force retrigger it. Where it would reboot before, there is now a longish wait, then it does get to the model select screen. Seems the processor is waiting for something, possibly the model save, and not running the main code. Investigation continues.

Mike.

Post by **MikeB** » Mon Apr 02, 2012 3:03 pm

I may have fixed this, new sources are committed. When writing to EEPROM, there is a 200mS timeout. When you change a model setting, it schedules a model EEPROM write for a second later. A model using 100 bytes of EEPROM could take more than a second to write (10mS per byte). It will actually have five goes at this, taking 200mS each time. If you now change a general setting (e.g. the main screen view) this schedules a general EEPROM write. This write will be processed BEFORE completing the model write (thats how it is!). If you now select the modelselect screen, this needs to read the model names from the EEPROM, and also allows a check to cause a write to be processed. I reckon all this trips over itself, and stops the main loop from running long enough to allow the watchdog to timeout and reset everything.
I have added a watchdog reset to take place if we get an EEPROM write timeout. I now notice that, sometimes, going to the modelselect screen, the screen update hesitates, and appears to be a mixture of the main screen and the modelselect screen. I also saw this when I had the watchdog set to 2 seconds (its backto 0.5 seconds now).
I did manage to cause a reboot a couple of times without changing a model parameter first.
I think it is also timing related, if you wait long enough after changing the main screen I think the reboot doesn't happen because all EEPROM writes have finished.

I also reckon I've fixed the GPS Altitude as the main altitude display.

Mike.

ReSt · Post by **ReSt** » Mon Apr 02, 2012 3:37 pm

Thanks Mike.

The GpsAltMain flag now is remembered correctly over power off/on.

But the altitude still does not appear on the Rpm screen although I have it on the Gps screen.

I tested the r749 code and the telemetry screen now is only reachable in the sequence of the system screens, the sub screens are selected with right/left[short] and exited with exit[short]. This is ok and I don't have any reboots anymore.

But now you have to step through up to 6 screens before you get the first telemetry screen. I personally would prefer to remove the telemetry screen from the sequence of the system screens and select telemetry with a DOWN[long] from any system screen and the statistic screens only via UP[long].

But I can also live with this solution !!

Reinhard

Post by **MikeB** » Mon Apr 02, 2012 3:55 pm

OK, try r751 sources! long[down] goes to telemetry, still in main sequence, and try the GPS altitude again.

Mike.

ReSt · Post by **ReSt** » Mon Apr 02, 2012 5:11 pm

Ok, telemetry screen are ok, as far as I'm concerned and no more reboots

But

altitude seems not to be our friend.

It's not yet in the rpm screen and now it even disappeared from the GPS screen

I verified the Gps data that are transmitted to the rf link and they really do contain the altitude while it is not displayed on the screens.
Just to clarify, I do not have the true FrSky link hardware, but the hardware as I use it with the NMEA version. And I have switched in an arduino to convert the NMEA protocol to the Frsky HUB protocol and add additional (analogue) values. Up to version r749 I had the altitude on the GPS screen available (and it even got displayed on the rpm screen, when I sent the altitude additionally with ID=0x10).

Reinhard

Post by **MikeB** » Mon Apr 02, 2012 5:55 pm

Thats what comes of trying to do 3 things at once! Try r752.

Mike.

openrcforums