GPS sensor
Moderator: rainer
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
Pressing reset button immediately starts it working.
Re: GPS sensor
I just had a look at the log.
I have an entry in the log every 0.5 sec.
I compare consecutive entries in the log having the same values in Vspeed, Alt, GPS Alt, GPS speed, GPS Heading and GPS long/lat.
Over the 100 min the test was running, I found only 1 case where the values remained unchanged for 4 sec (8 identical consecutives entries)
This does not seems me so abnormal (taking into account that oXs did not move at all; it was just put on the table).
In order to avoid repetitive identical values, I could make a new version of oXs where I transmit a field TEST_1 that I increase by 1 every 100 msec (e.g.)
If I remember well, you said that your oXs was blocked for about 10 sec(?).
How do you detect It?
Can you make a test with the version I put on github about 1 hour ago (and the same config file , except the interrupt pin for IMU?
I have an entry in the log every 0.5 sec.
I compare consecutive entries in the log having the same values in Vspeed, Alt, GPS Alt, GPS speed, GPS Heading and GPS long/lat.
Over the 100 min the test was running, I found only 1 case where the values remained unchanged for 4 sec (8 identical consecutives entries)
This does not seems me so abnormal (taking into account that oXs did not move at all; it was just put on the table).
In order to avoid repetitive identical values, I could make a new version of oXs where I transmit a field TEST_1 that I increase by 1 every 100 msec (e.g.)
If I remember well, you said that your oXs was blocked for about 10 sec(?).
How do you detect It?
Can you make a test with the version I put on github about 1 hour ago (and the same config file , except the interrupt pin for IMU?
Re: GPS sensor
nigelsheffield wrote: Maybe I fixed it heating it up with hair dryer lol
hmm, maybe it wasn't hot enough??nigelsheffield wrote:No , its just stopped working now lol.??
Joking, of course
João
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9
Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9
Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
Re: GPS sensor
Yesterday i used your script, it ran without issues, the actual oXs master today runs also fine (GY-86, Ublox7N32 GPS, pro micro). Next step: change the arduino? I had no problems for a long period, but recently 2 faulty pro mini.nigelsheffield wrote:
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
i think i have ruled out the arduino by building another sensor with a known good arduino which has been running standard vario altimeter fine and this still went wrong.
I detect the values in the opentx telemetry screen, there are stars next to sensors which are being recieved, these all dissapear when it goes wrong just as if I had unplugged the sensor, the lights are all still on when it goes wrong so its not loss of power.
the length of time it stays off varies a lot, from maybe 10 seconds to 5 minutes.
Carbo did you use the version of openxsensor I have uploaded on rcgroups or set up your own?
I will try the version on github and see what happens then!
I detect the values in the opentx telemetry screen, there are stars next to sensors which are being recieved, these all dissapear when it goes wrong just as if I had unplugged the sensor, the lights are all still on when it goes wrong so its not loss of power.
the length of time it stays off varies a lot, from maybe 10 seconds to 5 minutes.
Carbo did you use the version of openxsensor I have uploaded on rcgroups or set up your own?
I will try the version on github and see what happens then!
Re: GPS sensor
OK, did you try to run arduino + GY-86 without the gps, does the data loss still happen?nigelsheffield wrote:i think i have ruled out the arduino by building another sensor with a known good arduino which has been running standard vario altimeter fine and this still went wrong.
No, i have used the one, you have posted here, see my quote above. This one worked, and the actual master worked also.nigelsheffield wrote:Carbo did you use the version of openxsensor I have uploaded on rcgroups or set up your own?
Re: GPS sensor
I am currently running a new test where oXs sent also Temp1 and Temp2 with a value that has to be incremented every 100msec.
This version is not currently loaded on github.
I will let it run for 1 hour and then look at the new log.
This version is not currently loaded on github.
I will let it run for 1 hour and then look at the new log.
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
Have not tried it without GPS, but watching it I noticed it does not seem related to GPS lock at all. And I have built the new sensor with a new GPS too so no components are same.Carbo wrote:OK, did you try to run arduino + GY-86 without the gps, does the data loss still happen?nigelsheffield wrote:i think i have ruled out the arduino by building another sensor with a known good arduino which has been running standard vario altimeter fine and this still went wrong.
No, i have used the one, you have posted here, see my quote above. This one worked, and the actual master worked also.nigelsheffield wrote:Carbo did you use the version of openxsensor I have uploaded on rcgroups or set up your own?
I am running the version now from github been running since 2:25pm no problems so far with sensor all wrapped up ..
Will leave it running another 25 mins or so and then perhaps look at getting ACC values working
Strange that carbo you have not had the problem and use same version as me, something very odd going on..
Re: GPS sensor
So we have 3 completely different sets of hardware, and the only working set is mine? Really odd! How long do i have to run the test to be sure? I will test it again later.
Running the test without gps would reduce the data to transmit a lot, maybe it is worth a try, to see if the amount of data is a possible reason for the issue? It is no concrete suspicion, but it is always a good idea, to reduce the number of components when troubleshooting.
Running the test without gps would reduce the data to transmit a lot, maybe it is worth a try, to see if the amount of data is a possible reason for the issue? It is no concrete suspicion, but it is always a good idea, to reduce the number of components when troubleshooting.
Re: GPS sensor
I expect that my device is running fine.
Having no change in telemetry data for 4 sec while sensor is not moving seems not abnormal. It can be the result of GPS and vario keeping the same values and not of a telemetry lost.
Sorry but I have to rerun my the test with TEMP1 and TEMP2 increasing automatically every 100msec because I forgot to add those fileds in the log.
Having no change in telemetry data for 4 sec while sensor is not moving seems not abnormal. It can be the result of GPS and vario keeping the same values and not of a telemetry lost.
Sorry but I have to rerun my the test with TEMP1 and TEMP2 increasing automatically every 100msec because I forgot to add those fileds in the log.
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
Mstrens I thought only did things like that lol!
I must be sending my confusion over to you, sorry about that!!
Would you try the 3 acc values as that is what I will be using.
I presume I can still have all the yaw pitch and roll sent to ACC values like before or was that just a test version?
Still working now anyway so I will go look.
I must be sending my confusion over to you, sorry about that!!
Would you try the 3 acc values as that is what I will be using.
I presume I can still have all the yaw pitch and roll sent to ACC values like before or was that just a test version?
Still working now anyway so I will go look.
Re: GPS sensor
Take care that if you want to send Acc with values from TEST_1, 2, 3, you have to look in the ino file in order to fill test1... with the right values.nigelsheffield wrote:Will leave it running another 25 mins or so and then perhaps look at getting ACC values working
I am not sure that the current version on github fills TEST_1, ... with the values you expect (because it happens often that I change this part).
I do not remember which values you expected.
Is it pitch, roll, yaw (in this sequence)
It could be useful to let you assign them (pitch,roll,yaw) in the config.h without having to use TEST_1,2,3 (because normally TEST values are more for development)
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
Yes I think so , yes it would much easier to be able to assign them as yaw pitch and roll, would that be possible?
Should I just wait till its done and then try it?
Also the difference between s.port ACC values and hub values I have to remember how to do it, but I have that written down.
Should I just wait till its done and then try it?
Also the difference between s.port ACC values and hub values I have to remember how to do it, but I have that written down.
Re: GPS sensor
I need probably 1 or 2 hours to provide a version that allow to assign yaw pitch and roll directly.
It is up to you to decide to wait or not.
It is up to you to decide to wait or not.
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
Thanks, I am happy to wait if you are happy to do it, no rush I need to go walk the dog anyway lol.
Appreciate it!
Appreciate it!
Re: GPS sensor
I put on github a new version that allows to send pitch, yaw, roll in ACC fileds.
It is done for the 2 Frsky protocols (tested only for SPORT) but not 'yet) for Hott or Multiplex
It is done for the 2 Frsky protocols (tested only for SPORT) but not 'yet) for Hott or Multiplex
Re: GPS sensor
Note : in the new version on Github, I fill TEST_1 and TEST_2 with a counter that is incremented every 100ms.
If you transmit those fields (e.g. as TEMP1 and TEMP2), you can easily see
- in the log if telemetry has been blocked (you would have several lines with the same values)
- if a reset occurs (counter will start again at zero).
In a run I made, I had no one telemetry issue with oXs
If you transmit those fields (e.g. as TEMP1 and TEMP2), you can easily see
- in the log if telemetry has been blocked (you would have several lines with the same values)
- if a reset occurs (counter will start again at zero).
In a run I made, I had no one telemetry issue with oXs
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
great thanks, I just tested quickly and it all works on both hub and s.port, not sure if opentx will ever fix the discrepency between hub and s.port on the acc values because other projects have already taken this discrepency into account and kilrah says he would like to fix it but would need all the other projects to be notified and pull requests done..
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
will do a long test now and see what happens!
thanks again!
thanks again!
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
Sorry but I cant get t1 or t2 to work, on hub i get t1 but no values on it, on s.port i tried discover new sensor but nothing appeared?
Good news is so far sensor has not stopped working!
Good news is so far sensor has not stopped working!
Re: GPS sensor
TEMP1 and TEMP2 worked in a previous version but I made a minor type fout in the version I put on Github.
In ino file, you should have
#define DEBUG_CHANGE_IN_TEST12
#if defined( DEBUG_CHANGE_IN_TEST12 ) // here, there was a typo fout having 2 "_" in CHANGE__IN_TEST12
Corrected version is now on github.
In ino file, you should have
#define DEBUG_CHANGE_IN_TEST12
#if defined( DEBUG_CHANGE_IN_TEST12 ) // here, there was a typo fout having 2 "_" in CHANGE__IN_TEST12
Corrected version is now on github.
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
Great thanks!
Still working after 50 mins testing..fingers crossed and touch wood!
Still working after 50 mins testing..fingers crossed and touch wood!
Re: GPS sensor
@nigelsheffield
Currently pitch, roll and yaw are just the values returned by the internal calculation performs in 6050 IMU.
If you feel that the values are too noisy( change too fast), I could add some filtering in oXs
Let me know if this is required.
Currently pitch, roll and yaw are just the values returned by the internal calculation performs in 6050 IMU.
If you feel that the values are too noisy( change too fast), I could add some filtering in oXs
Let me know if this is required.
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
Thanks , I will have another look next time I fly, won't be for a few days looking at forcast...
I think more the problem is that the levels are not exactly correct, they are definitely useable though as I proved last time I flew I could return to base with just the tx screen!
Dont know if it can be fixed but What I did notice wrong was in a turn the pulling up of the elevator to keep nose level made the nose appear to rise on the screen, I guess this is due to the gravity based sensor output? And turning would appear to do a similar thing, I think it's just that the g forces involved in the manauver as you pull on the stick to turn and pull are giving false indications ie the screen was following the stick inputs ...
There was still enough proper info to fly though so it's possible I could filter this somewhat in the lua script based on stick inputs , it was a while ago now that I looked at the imu yaw pitch roll levels but I remember there was another set of levels could be calculated which would allow inverted measurement too , would these values also be effected by the stick inputs I wonder, but I also remember there was a possible drift problem with these readings?
I think more the problem is that the levels are not exactly correct, they are definitely useable though as I proved last time I flew I could return to base with just the tx screen!
Dont know if it can be fixed but What I did notice wrong was in a turn the pulling up of the elevator to keep nose level made the nose appear to rise on the screen, I guess this is due to the gravity based sensor output? And turning would appear to do a similar thing, I think it's just that the g forces involved in the manauver as you pull on the stick to turn and pull are giving false indications ie the screen was following the stick inputs ...
There was still enough proper info to fly though so it's possible I could filter this somewhat in the lua script based on stick inputs , it was a while ago now that I looked at the imu yaw pitch roll levels but I remember there was another set of levels could be calculated which would allow inverted measurement too , would these values also be effected by the stick inputs I wonder, but I also remember there was a possible drift problem with these readings?
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
I flew the other day and everything was fine, no loss of temetry at all.
I dont know if filtering is really needed on the levels, the taranis display showed them working well enough.
Main advantage is the fast vario tones but I will use the GPS for waypoint racing later on.
I've built another now and will install then in the next couple of weeks.
Thanks mstrens.
I dont know if filtering is really needed on the levels, the taranis display showed them working well enough.
Main advantage is the fast vario tones but I will use the GPS for waypoint racing later on.
I've built another now and will install then in the next couple of weeks.
Thanks mstrens.
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
flying some more today and its becoming obvious that the roll angles could be a LOT better, I find I am using the heading to establish if plane is flying level or turning, Ive just altered the script to calculate yaw rate from yaw data and fed this into the roll calculation, its a bit jerky but working on bench,
I will have to wait for some better weather again now to test it, if it works it would be better to calculate yaw rate in the sensor and send this down rather then calculating it in the script because of the speed of the data sent.
I also wondered about the pitch because the nose appears to point upwards in a tight turn, perhaps adding the yaw rate to the pitch angles calculation might work, ie a greater yaw rate makes for less pitch reading? this could be done in the script I think.
Could yaw rate be calculated easily on the sensor? It might be useful for other things like I was thinking of adding return to home by giving the rudder control over to the script..
I will have to wait for some better weather again now to test it, if it works it would be better to calculate yaw rate in the sensor and send this down rather then calculating it in the script because of the speed of the data sent.
I also wondered about the pitch because the nose appears to point upwards in a tight turn, perhaps adding the yaw rate to the pitch angles calculation might work, ie a greater yaw rate makes for less pitch reading? this could be done in the script I think.
Could yaw rate be calculated easily on the sensor? It might be useful for other things like I was thinking of adding return to home by giving the rudder control over to the script..
Re: GPS sensor
Following you, waiting for me to get some time for this one.
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
Braved the winds in a break from the rain and tested it out, its incredibly NOISY and Jumping around due to slow data and lack of of any filtering but it seemed to work, I could fly a circle continuously and the angle was shown correctly and exiting the circle seemed OK.
I think it might work with the yaw rate calculated in the sensor.
I think it might work with the yaw rate calculated in the sensor.
Re: GPS sensor
I presume the yaw rate could be calculated in the sensor.
I see 2 options;
- calculate the difference of yaw every 0.5 sec
- use the gyro values provided by the sensor (which are just rotation rates) and calculate the yaw rate taking into account the gravity vertor (giving orientation of the sensor). I expect this would be better (at least more reactive) but I do not know which formula to use to calculate the yaw rate using gravity vector. Do you know it?
I see 2 options;
- calculate the difference of yaw every 0.5 sec
- use the gyro values provided by the sensor (which are just rotation rates) and calculate the yaw rate taking into account the gravity vertor (giving orientation of the sensor). I expect this would be better (at least more reactive) but I do not know which formula to use to calculate the yaw rate using gravity vector. Do you know it?
-
- Posts: 308
- Joined: Fri Nov 08, 2013 9:56 pm
- Country: -
Re: GPS sensor
Second option would definitely be better, I don't know the calculation, sorry..I can Google it later if it helps,
I wonder though if there might be problems again with centigugal forces with that?
If first option is easier and could be calcuted and sent maybe 5 times a second it might be enough..
I wonder though if there might be problems again with centigugal forces with that?
If first option is easier and could be calcuted and sent maybe 5 times a second it might be enough..