GPS sensor

[nigelsheffield]

Tested today for real with the heads up display and it all worked great, the pitch and yaw levels did get thrown a little with g forces but still flyable and I returned to base many times just using the taranis display!
The vario tones responded well too, I was definitely able to core thermals easier.

Only problem I had was intermittent total loss of telemetry from the sensor, it would dissapear for a few minutes or so and then come back, I think I may have a lose connection but I can't force the problem by taping or wiggling etc, I have a feeling it may be linked to GPS signals, because it happens when I circle tightly and comes back onmly when I've been flying steadily for quite a while, I had this problem in ground testing and thought it was the GPS being effected by RX swamping ,
Once it would not come back so I landed and unplugged and plugged back in and it worked again ,
It's odd though because when I start there is no GPS lock but the rest of sensor works, but maybe if GPS stops sending data because it then looses signal it is effecting the rest of sensor?
Need more testing I think...

Anyone else had this problem?
I will be building my other sensors adding the gy521 and GPS to the ms5611 I already have built so I will be able to see if they do it too.

[lshems]

Nice !! Im in for waypoint flying competities.

[mstrens]

Perhaps a bug in oXs that occurs in rare conditions.
When you say that you loose telemetry from the sensor, I expect you mean that you do not get any data from oXs but that you still get other telemetry data from the receiver (e.g. the Rx voltage level).

Normally if GPS loose the signal, oXs should not block other data.

Which kind of Rx do you use (Frsky Sport?).
Perhaps good to test with another type of Rx (Hub protocol) if you can.

If you currently only use a MS5611 and a GPS, there is plenty of free ram in Arduino. So you could also try to change the optimisation level of compiler in arduino IDE. Best would be to try to compile with no optimisation at all and see if blocking still occurs.
If you do not know how to change optimisation level in arduino IDE I could search on it and let you know (you have to edit a file manually but I do not remember which file and where)

[nigelsheffield]

Yes, RX volts and rssi etc still OK, just openxsensor data not there.
This was done on s.port RX, I have tested on hub type but not in air and I never had the problem so I think it might be s.port related.
Testing now with another RX is not easy as everything is now installed , also running opentx 2.1 when I swap RX type I have to reset a LOT of things as the ID changes and my setting for RX volts and vario all go wrong , last time I had to forget all sensors and discover them again and then go through all my settings which had anything to do with those sensors....!
Still if it needs doing then I will do it, I will fly some more today as its flying weather , then I will build more sensors and try them on different rxs and also look into the optimisation levels of arduino.

I also noted that I could not get GPS to lock whilst flying for first time unless I waited on ground for the lock to occur, I have my home coordinates hard programmed into the lua script so that I would not have to wait for GPS lock to start flying, is there some way to allow a lock whilst flying?

[nigelsheffield]

Flew for a couple of hours this afternoon, first hour I only lost the openxsensor telemetry once for about a minute, second hour after a battery change it did it about 5 times..
But wow those vario tones work really well now , I cored many thermals and it was faster and more precise and easy to do with the instant response!

[mstrens]

I will try to reproduce the issue (telemetry lost).
I presume you are using the latest version oXs (version 7).

Could you send me your config.h file and also the version of Arduino IDE (e.g. 1.6.5).
Could you confirm that you are using an Arduino at 5volt and 16 Mhz.

Normally, GPS should lock whilst flying. I do not think that this is an oXs issue.
Perhaps that the GPS does not get a clear signal from the satelites or that there is to much noise on the power supply when flying.

It would be good to know if other people using oXs with a GPS have the same issue.
I presume that at least Carbo could share his experience.

[nigelsheffield]

Will do , I am using 5v 16m arduino and recent version of osx but not sure if it's 7 or not, I will send it all

[nigelsheffield]

openXsensor-master pitch roll yaw faster heading using accx y z.zip

(1.03 MiB) Downloaded 219 times

zip file with my version I'm using, so im using gy86 and gps at 5hz ,
I know its not the latest version but I did not see anything thats changed which would fix this problem.
hope you can find something and its not just something ive done wrong, only thing I can think i may have wrong is I supply 5v not 3.3v ( but i tested on single cell and still had this problem) and im using a 5.6k resistor to gps rx pin but like you say it may be something odd with my gps.

I think it has to do with gps lock as I think remember doing a test where I deliberatly blocked gps signal and noted the rest of the sensor stopped working..
Also note the start up problem where altitude is not working unless I plug and unplug power , not sure if that might be related so I mention it.
Thanks!
Nigel.

[nigelsheffield]

OH this afternoons first flight got gps lock very fast (on ground) and then was relatively trouble free so I imagine gps signal strength must vary and this was why I had less trouble, maybe later the gps strength was not so good and why I had more trouble..

[Carbo]

It would be good to know if other people using oXs with a GPS have the same issue.
I presume that at least Carbo could share his experience.

My last GPS-flights date from Nov. 2015. I can presumably make some flights on the weekend with the same hardware. GPS-fix in flight was never a problem and i never lost GPS after that fix. But to be clear: i never flew the combination imu-vario together with GPS as nigel did, i have only made some tests with the car - without any issues.

Nigel: Was an oXs (GY-521) connected to the TX S-Port while the GPS-issue occured?

[nigelsheffield]

No, I have not built the sensor for tx yet, one step at a time so I know each part works properly.
But I wonder if it is the combination of the gy86 l and GPS causing trouble..
Note that is is a long time working before error occurs..

[nigelsheffield]

Tested this mornjng by leaving it outside to get a gps lock and then bringing it back indoors to lose the lock and all other sensors worked still, repeated a this just to check and still all sensors worked.
Maybe I just just a have a bad arduino or something, but still no amount of taping around looking for lose connections makes anything happen..

[mstrens]

I had a short look at the code this morning and I do not find a reason why loosing gps lock (or even disconecting GPS serial signal) would block oXs sending other telemetry data.

Could it be that the issue would be temperature related?
If you connect your battery to Arduino raw and if GPS VCC + MS5611 VCC are connected to Arduino VCC, it means that Arduino voltage regulator has to provide power for Arduino + GPS + MS5611.
Perhpas it exceeds the capacity of Arduino voltage regulator.
Perhaps that when GPS is searching for a lock, it uses more courant what increases risk of overload of arduino voltage regulator.
This is just an hypothese.
If your GPS is not connected to Arduino VCC but directly to the battery or to Arduino Raw pin, then this should not be the reason of your issue.

[nigelsheffield]

I wondered the same, but it seems not to be related now to GPS after a few tests ..
I took rx apart and found one side of earth connection not soldered so I soldered that and tested again , it still went wrong just sitting on floor with wing fixed on.
I just built another sensor today with an arduino nano and ms5611 and gy521 ..I tested this on same RX and got no problems on ground at least with wing off , now I am testing suspect sensor with a d8r and it's been running for ages with wing off with no sign of a problem..

It's frustrating this sort problem because sometimes everything works for ages anyway , I tried pulling on all the wires taping and shaking the sensor to see if made any difference, I held my thumb over the regulator and over the 328 to the to heat it up a bit but nothing.
When it did stop working it was shortly after plugging in with 5 minutes, I cycled power and it worked right away..
I have another sensor to build with another pro mini , maybe this will prove something ...
I am supplying raw with 5v and then everything else is powered from vcc so it could be a low voltage situation I suppose but why does it not effect the d8r I wonder?

[Carbo]

......I am supplying raw with 5v and then everything else is powered from vcc so it could be a low voltage situation I suppose but why does it not effect the d8r I wonder?

Presumably the 5V are from a BEC and stabilized. An easy test is, to supply all components directly with 5V, without using arduino raw. You have a loss of nearly 1V supplying everything over raw. But i do not know, if this can be the reason for the different behaviour in the two modes.

[nigelsheffield]

I noticed something, when I use nano sensor the altidue works first time , when I use the pro mini the altitude gets stuck at zero and needs power cycling to get it to work.but this is only true of s.port connection?!?!l
The nano has a better regulator so maybe this is a sign of insufficient power with the pro mini.
I will remove sensor again and connect power direct to the vcc and make only to ever connect 5v to this sensor.
Can I just link across the 5v reg ?
Or should I still use the reg for the pro mini but supply the GPS with 5vmbut it seems maybe the gy86 needs a 5v maybe too?

[Carbo]

Best is to connect the 5V directly to vcc at the pro mini and also to the other components. I have never measured it, but i think, the regulator needs more than 6V to be able to stabilize the raw input.

[mstrens]

If you use a 5 volt BEC, you can connect the 5Volt directly to arduino Vcc. When Arduino Pro mini is connected to a FTDI, VCC from FTDI bypass the voltage regulator too.

Gy86 has his own voltage regulator I think. So can also connect it directly to BEC VCC if you want

[nigelsheffield]

Just checked and it wired 5v to raw but that same connection is direct to GPS and gy86,
On the sensor which works first time it 5v to raw but vcc is supplying the GPS and the other sensor.
I will just link the raw to vcc then and see what happens, maybe the pro mini reg is not providing enough volts to allow the 328 to run properly?
Still odd that it works perfect on the hub protocol..

[nigelsheffield]

Right, sensor starts first time now!
Testing now to see if it stays working over time, hopefully this is it!
Must have just not been enough voltage for 328 to work properly.
Thanks and I will let you know how it goes once I've tested it for a while!

[nigelsheffield]

No, its stopped working again lol

[mstrens]

Thanks for testing.

Normally 328 can run at 16 mhz with a quite low voltage. I would have to look at the datasheet but I think it can be as low as 3.8 volt.
Issue could still be some noise on VCC (from servo, ESC,...).

I can't exlude a bug in oXs but it is good to first exclude other possible reasons like voltage regulator.
Still if is OK with hub protocol, I suspect a oXs bug.

I did not yet start my own test because I would have first to rebuild an oXs with GY86 and GPS.

If changing the power supply does not solve the issue, I suggest that you first try the latest version of oXs (would be easier to compare with my own test) and if the issue still exists that you change the Arduino IDE compilation optimisation parameter.
Here a link on how to change this parameter.
http://www.instructables.com/id/Arduino ... /?ALLSTEPS

[nigelsheffield]

If it's a bug its a very strange one! I suspect it will turn out to the something like noise on 5v line but I will keep testing , its been running now for another 30 mins, it stopped working for a short while and then started again by itself and has been solid since..
Moving servos has no effect this is a hard problem to pin down as I just can't work out what makes it go wrong...
I'll try cycling power now and see if that makes it go wrong at all.

[nigelsheffield]

Update on testing
Fault still exists with new better bec and both openxsesnor that I built, I tried a frsky vario in the RX just in case it was a bad RX and ran for over an hour and a half no problems.
I am running on the d8r hub protocol again with sensor wrapped up to try to get it warm this seems to make the problem worse on the x6r ie when I wrap it up ready for install in plane it goes wrong faster and more often, on the d8r its been running for an hour like that and not lost any transmission.
I will update to latest openxsensor code and the go though all the setting in it to get it working for me, its more awkward because of the differences in the expected decimal place in the acc values in s.port verses the hub protocol but I can do it and see if it makes a difference, then I need to try to work out the optimisation thing and try that.
Thanks mstrens

[nigelsheffield]

One thought I had was the levels between sensor and RX, I have it connected directly and it has always been OK, mikeb informed me that the rxs are all 5v tolerant , I don't think this can be the issue but thought it worth a mention.
I could put a 5k6 resistor in line just to see if it made a difference I suppose but the fact that the sensor goes wrong more when it is wrapped up makes me think the sensor is only just coping maybe with the s.port data rate and a little heat build up is enough to stop it working?

[mstrens]

I made an oXs sensor with GY86 and GPS this morning.
It is running for half an hour on the table.
I do not look continously to the Tx but I make a log.
So, if telemetry blocks, I hope to see it in the log afterwards.

Do you have another way to detect immediately if telemetry block (without looking continously to the screen)?

I let it run for one half hour more and then I will look at the log.

I just put on git hub the version (and the config.h) I am using for the test.
I expect it is the same as you (except that I do not ask to send ACC and I use perhaps onther pin for interrupts from IMU).

[nigelsheffield]

Thanks for buidloing so you can test too!
You will see it in logs, I noticed it in mine, I just tried heating up with hair dryer but it made no difference the heat did not stop sensor working,
I thought maybe the covering I used was interfering so I removed the cover but it still went wrong though not as quickly and recovered faster then with cover on.
I fitted a resistor and it still went wrong.
I thought maybe it was antenna proximity because pluging tx near makes all data dissapear and get telemetry lost but having the sesnor near the RX antenna did not seem to effect anything.

[nigelsheffield]

I'll wait and see if you get any loss of data and if you don't I will try your version, mine has been running again now for another hour without going wrong even covered and installed in the fuse.....
Just makes no sense as to when it decides to go wrong...

[nigelsheffield]

I'll wait and see if you get any loss of data and if you don't I will try your version, mine has been running again now for another hour without going wrong even covered and installed in the fuse.....
Just makes no sense as to when it decides to go wrong...

Maybe I fixed it heating it up with hair dryer lol

[nigelsheffield]

No , its just stopped working now lol.??