Jump to content
ThomasScherrer

GPS module EM406 questions

Recommended Posts

I have a few EM406 modules, and I am very happy about them in general.

but here goes a few comments:

Problem: they can not handle hi power RF at 433MHz and 2.4GHz,

only 200-400mW with antenna located 30-60cm away from GPS will block it.

Fix: I have added extra GPS frequency bandpass filter from Murata type SAFSE1G57KA0T05R00

between patch antenna and GPS LNA input,

now no blocking and GPS work almost as fine as before,

a better solution would be finding a filter with less insertion loss,

and also wider bandpass is fine, maybe another LNA with higher IP3 could be used ? but ok they draw much more current and cost more money.

Question: is it possible to edit a setting in the GPS module ? so the speed and height will be more live ?

Right now I need to travel quite a long time in the same direction before the readings are realistic,

i think the readings are about 5 sec behind the actual values, I would like 1-2 sec if possible please help me ?

Share this post


Link to post
Share on other sites

Five second delay? That is very odd. I know you are not talking about the sentence update period (1Hz), but instead mean the real time nature of the data. From my experience, coordinate data is as fast (or faster) than my Garmin. I'm guessing less than 2-secs. At what speed are you moving when you experience this huge delay?

Comments (some of which apply to other GPS's as well):

* In the static mode, the GPS must move several meters, or travel faster than a few kph, before readings are updated. Otherwise, you may see "noise." Even with static mode turned off, very slow walk travel speeds will not look as accurate as a fast running.

* The coordinate accuracy depends on satellite lock or location and may affect perceived performance.

* Altitude readings are not as accurate as coordinate data. Don't use altitude as a judge of accuracy (this issue is common).

* Some sentences are sent every other update (not enough time to send them all in one packet). Unused NEMA sentences can be turned off.

* I have not checked, but maybe WAAS mode needs to be disabled for best operation in your country? Or, maybe it needs to be turned on, even if not used?

* Do you have a EM-406 or EM406A? Maybe that makes a difference?

* The SiRF III binary protocol manual is available from US Global. It lists all the things you can program via the serial port.

Share this post


Link to post
Share on other sites

Is this a general issue with GPS receivers that they are disturbed by a 2.4Ghz downlink?

I am working on an OSD/GPS project but I do not have a downlink to test with yet. Do I need to put the GPS as far as possible from the transmitter?

Thanks,

Frederic

Share this post


Link to post
Share on other sites

if you look on http://www.webx.dk/rc/video-wireless/video-osd.htm

and DL the file video-fly003-full.avi (sorry it is 32MB)

look at 1:53 and see how late the peak speed is indicated,

I fly with the wind to get max ground speed towards us on the ground,

and against the wing when I fly away from us at the ground,

see what I mean, the speed (and height) results are like in a fifo (first in first out) buffer that is too many sec long.

---

>Do I need to put the GPS as far as possible from the transmitter?

yes ! it is always common practise to construct ANY system:

so that emiters and receivers are as far away as possible.

that means if you have several emitters keep them together

and if you have several receivers keep them together,

and both groups as far as possible.

a 2.4Ghz link can also degrade RC receivers !

so test carefully on ground before flying.

Edited by ThomasScherrer

Share this post


Link to post
Share on other sites

It may have something to do with how you setup the sentences. For example, if the speed is from $GPRMC, keep in mind that it is a field that is periodically skipped if you don't turn off the unused sentences (get rid of GSV).

Although I spent a lot of time confirming the speed accuracy while traveling on roads (it is dead on!), I did not pay any attention to see how "lively" it was. So, this delay may be normal for that particular field. I just don't know.

Edit: Also, if you have some clever buffering going on in your video engine's serial handler, maybe it is just a software pipeline delay? Forgive me if I am off by a mile -- I'm just tossing ideas at you since I don't know what is "under the hood" in your design.

Also, it might be best to test under more conveninet conditions. Quiet roads, while in your car, is nice.

Edited by Mr.RC-Cam

Share this post


Link to post
Share on other sites
Although I spent a lot of time confirming the speed accuracy while traveling on roads (it is dead on!), I did not pay any attention to see how "lively" it was. So, this delay may be normal for that particular field. I just don't know.

I've tested the EM-406 while in the car too. It's "dead-on" and "lively" in the car. Oddly enough, it becomes delayed in the RC plane (as does the altitude) especially if the plane is not flying smoothly (ok, ok, if I'm not flying smoothly :P ).

Share this post


Link to post
Share on other sites

FWIW: My testbed is a currently a Magpie AP, a small 4' electric. Top speed is rarely over 30mph. I just looked at two flight video tapes and it appears to me that the speed data field is decently realtime. For example, during launch I can see the initial flight speed within a couple seconds of my hand toss, and it continues to hold true until I purposely increase throttle. While I fly, the speed seems to follow what I am doing. When I land, the speed goes from the 18mph glide, to zero, very rapidly (the model does not roll when it lands, it sticks to the grass like a lawn dart).

Long story short: If I had to put a number on it, I would say the delay I experience is well under two seconds (probably closer to one sec). It is very odd you see a five second delay.

Share this post


Link to post
Share on other sites

no no it is NOT realtime !

it is several sec behind, I have no way to fix this in a realtime situation,

it can be fixed in a video recording, by simply record the serial nmea and play it a few sec fefore the video and add OSD after in the video edit.

but this is not what I want.

Cars can not change speed and dirrection as fast as model RC planes.

see the video clip I mention the the time I mention, then you will se what I mean,

it is not at all realtime, I fly 80km/hr in one direction and 20km/hr in the other if I am lucky with the wind direction

Edited by ThomasScherrer

Share this post


Link to post
Share on other sites

gps-em406-inside0046.jpg

see inside the GPS module, the internal filter was left out !! so no filtering against blocking at ANY band at all.

with 3 footprints available, either a 3 pol low-pass or hi-pass can be added,

to filter away unwanted stron local transmitters, like video or telemetry.

feel free to see this page about what i did this weekend:

http://www.webx.dk/rc/uhf-link/uhf-link-telemetry.htm

Share this post


Link to post
Share on other sites

I have information from the USGlobal engineer:

no no it is NOT realtime ! it is several sec behind, I have no way to fix this in a realtime situation,

I was advised that the problem is related to changes in direction. The GPS can accept >6 g's acceleration, but only a few g/sec changes in direction. Besides confusing the speed data, severe changes in direction may cause a satellite lock loss.

From what I understand, an aircraft that flies scale-like would not experience the problem. This means that a common model UAV would be fine. On the other hand, a fast stunt model would experience the problem. I can relate to that, since I fly a sport model and have never seen the 5-sec delay problem.

see inside the GPS module, the internal filter was left out !! so no filtering against blocking at ANY band at all.

According to them, the missing L4 component was for antenna tuning and is not needed with the integrated patch they install. The ceramic filter is actually near C4.

I do see that the filter appears to be after the preamp. I doubt they can justify the engr change to place a filter in the front end; GPS receivers like this module are designed for automobile telematics, where RF transmitters are not parked near them. Keep in mind that some of us are also using the EM-406 with video Tx's and don't have any problem with interference. For example, mine is a few inches away from my 600mW Tx and has never caused me any trouble. As usual, each installation is different.

Share this post


Link to post
Share on other sites

i need min 40cm distance to get lock at powerup, if 2.4Ghz tX is on.

I have tried two EM406 modules, but only one 2.4Ghz tx.

if TX is on and I dont have the patience to wait, I will end up flying with GPS not working at all, darn.

I also used both EM406 in my car, compleete loss of sats everytime I TX on my hamradio, on 145 or 435MHz same problem.

same problem when near other transmitters of any type, remember I am a licened radioamateuer so I am most often near transmitters.

About the fast planes: YES I know, my wing is overpowered and I have the skils to fly it like crazy, and so I did when testing the speed and height response.

When using gps even as speed info, a constant direction must be flown, then it react fine to speed and also speed changes.

Share this post


Link to post
Share on other sites

Latest information:

I have just got a few of the latest version EM406A GPS modules,

they seem to be a bit better sensitivity, I see more sats,

in my car driving to work 10-11 sats, so that is nice.

Hovever same problem with blocking,

if GPS is near a radio transmitter opperating at ANY frequency.

Share this post


Link to post
Share on other sites

more measurements and more compares again today.

the A version is a bit slower updating the speed and height.

Anyone found the datasheet over the cheramic GPS patch antenna used on those EM406 modules ?

I'd like to see the impedance and gain curves and how they are matched.

Share this post


Link to post
Share on other sites

Regarding the delay, I seems I also see a delay of a few seconds with my GPS.

This is a video where you can see it. The quality is very poor due to the subsequent compressions. Below you see the distance and direction to the pilot. During the pass-by you will see that the plane has passed the pilot for several seconds before the distance goes thought a minimum. I had severe range problems and the 2nd flight it went wrong... But everything survived. :)

Frederic

Share this post


Link to post
Share on other sites

Watching the altitude data, something does not seem right. It sort of looks to me like there is a software bug with the OSD board. Is there any chance that {in this case} the problem is in the code instead of the GPS? The reason I think this is because it looks like your altitude was "lost" for over fifteen seconds at one point.

Edited by Mr.RC-Cam

Share this post


Link to post
Share on other sites

I doubt it, but a SW bug is always possible.

On the second line on the screen are debug values. The last value is a counter that is incremented each time new GPS data was received. The first value indicates the number of NMEA fields parsed (should be 7) One can see that the GPS info comes in smoothly. The data on the screen is updated each second and different each second.

It is correct that the altitude remains 0 for a long time. I was thinking this was due to the inaccuracy of GPS altitude. The first time the system sees a HDOP < 1.5 for 10 seconds it considers this the position of the pilot and takes this as altitude 0. If the GPS would report values below this value, it would still show as 0. I suppose that is what happens?

Also remember that this is not a EM406 GPS.

Solving my range problem is now my first preoccupation (should have been in the first place :) After that I will do more tests and for example try to fly slower.

Thanks,

Frederic

Share this post


Link to post
Share on other sites
If the GPS would report values below this value, it would still show as 0. I suppose that is what happens?

It might be helpful to report negative altitudes. This is not unrealistic and is useful if you take off from a hill and fly below it. Keep in mind that the delay problem should only be noticed in the speed data. I don't believe that any other field is expected to have problems unless a satellite lock is lost (which can occur if the turn rate is excessive). Or so I have been told.

Also remember that this is not a EM406 GPS.

This oddity is expected to occur with any SiRF equipped GPS (which is found in a huge number of GPS systems).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×