GPS interference from Electron

bsturgess · February 9, 2018, 1:36pm

Hello

So, on a board with a particle electron and a PA6H GPS unit directly next to it, (cellular antenna end), I have a issue that the GPS can not get a fix while the Electron is on, even if the cellular is turned off (with Cellular.off, verified off). This has been tested on 3 units and for over an hour each.

The only way I can get a fix is by setting the Electron into SLEEP_MODE_DEEP or SLEEP_MODE_SOFTPOWEROFF, then the GPS will get a fix as normal.

So something must be interfering when powered on. Picture of layout attached.

Any ideas?!

peekay123 · February 9, 2018, 1:54pm

@bsturgess, you placed your GPS module/antenna right next to the most active radiator area of the Electron - the antenna connector. This is not generally good practice. However, some mitigation can be implemented including good ground plane design in you PCB, lots of decoupling caps and, ideally, a selective SAW filter on the GPS antenna to reduce noise interference. The latter is not possible due to the nature of your GPS module. From what I can see on your PCB, it is a 2 layer board which may not be enough. Placing the GPS unit away from the antenna connector may help. If you look at the Particle Asset Tracker V2, you will see that the GPS unit and antenna are at the opposite end of the Electron, on a 4-layer board. I suggest you need to reconsider your hardware design.

bsturgess · February 9, 2018, 2:07pm

@peekay123 Yes I understand the logic if the cellular modem was on, but if the cellular modem is completely off, does this not mitigate the placement issue? I never planned to have the GPS and cellular on at the same time for the reasons you mentioned.

In the same way that if the electron is unpowered or in sleep, there is no problem. Do you see my point?

peekay123 · February 9, 2018, 2:14pm

Perhaps @rickkas7 can pipe in here.

ScruffR · February 9, 2018, 2:17pm

I could also imagine the controller itself and the crystals/oscillators near that area might produce some “noise” which may “leak out” via the transmit circuitry while running.
Physical seperation of a few millimeters more, an extra ground plane and more caps should help tho’.

rickkas7 · February 9, 2018, 2:50pm

I agree with peekay123 and ScruffR’s recommendations.

Given that the GPS works in SLEEP_MODE_DEEP I’d guess it’s the STM32F205 processor that’s causing the interference. It’s right in the middle on the bottom. Maybe the traces running right under it are picking up noise too.

RWB · February 9, 2018, 5:29pm

@bsturgess I can tell you that I have an Electron + this GPS sensor sitting right next to the transmitting end of the Electron like you have and I have zero issues with receiving GPS data while the Electron is ON and sending and receiving data.

I would ditch the older Ultimate GPS receiver and go with the newer smaller Gtop GPS receiver that I’m using if you want to keep the GPS module close like you have it.

Moors7 · February 9, 2018, 5:41pm

Though it’s great that it works in your case, I don’t think you can compare a bread-board setup with a PCB. The layout, traces, ground pads, parasitic behaviors and whatnot that come into play with a PCB makes for a different environment than found on a breadboard.
In general I wouldn’t recommend just using different hardware to be able to ‘make it work’ while ignoring best practices. The hardware used is capable enough, but you do have to consider design guidelines when designing a product like that. Can’t just toss out physics in the process
Don’t get me wrong, I’m not saying that switching to a different module won’t make a difference. I’m saying it’d be best to adhere to best-practices while designing with any piece of hardware to ensure it works like it should, regardless of what module you’re using.

RWB · February 9, 2018, 6:18pm

I agree with that but I have also seen the a few other threads on here where people had issues with the Ultimate GPS module in the same breadboard setups, even when the GPS module was moved 6 or more inches away from an Electron and Photon.

What I find interesting is that I can use this different GPS receiver placed as close to the Electron as you can see it and it works fine vs the Ultimate GPS just not working at the same distance or even 6 inches away, this leads me to believe it's more susceptible to interference than other GPS modules.

So maybe this newer GPS module has better performance and better interference immunity than the Ultimate GPS to the point you don't have to take as much care as you do with the Ultimate GPS.

You can take care to layout the PCB so it's laid out more like the breadboard setup is as far as ground planes and trace routing.

I've used the Ultimate GPS in other projects without troubles also but when combined with the Photon and Electron it becomes less of a Capable module, something causes problems when they are combined together that prevents the normal expected performance, especially when the layout is not optimized.

I'm guessing the move to the Asset Tracker v2 with the better GPS module was to improve upon the performance of the Ultimate GPS unit used in the Asset Tracker v1.

I agree with that also.

I try to stick with the evaluation modules schematic and board layout as much as possible since usually they are proven designs that are recommended by the chip manufacturer and their seasoned design engineers.

I say switching to the less affected GPS module is a good move if you want to keep that close distance between the Electron and GPS module. Looks like your going to need to redesign the PCB anyway.

bsturgess · February 10, 2018, 4:48pm

I have tried Gms-g6 (3333 chipset), same issue.

Have also just tested with both original Particle tracker board and the new one, similar issue, both get a fix much quicker when particle is in DEEP SLEEP. There must be a serious amount of noise coming out of that STM32 layout.

RWB · February 10, 2018, 5:25pm

@bsturgess Here is one of the threads I was taking about where they were also having issues with the Ultimate GPS same as you.

From this thread Adafruit GPS Photon problem

The GPS unit I recommend works right next to the Electron which leads me to believe it’s much better with interference immunity compared to the Ultimate GPS which may help solve your issues.

I’ve used the Electron and GTop GPS unit to log my position while driving hundreds of miles and it’s always worked perfectly while the Electron is ON and sending data.

bsturgess · February 11, 2018, 11:26am

@RWB Thanks, although I have tried the titan, and same issue.

chipmc · February 11, 2018, 4:42pm

@bsturgess,

I was able to get the Adafruit Ultimate GPS to work but initially ran into the same issues you see. My issue seemed to be linked to noise / sag on the Electron’s 3.3V output. I could never get a fix when I was powering the GPS from the Electron but, when I powered the GPS directly from the LiPo battery, it worked like a charm.

In fact, this is a quote from the Adafruit tutorial on this product: VIN - power input, connect to 3-5VDC. It’s important to connect to a clean and quiet power supply. GPS’s are very sensitive, so you want a nice and quiet power supply. Don’t connect to a switching supply if you can avoid it, an LDO will be less noisy!

So, I think the switched power supply on the Electron is too noisy.

Here is a link to the guide I published, happy to share more.

Chip

RWB · February 15, 2018, 12:30am

@bsturgess I’m suprised the Titan did not work for you.

To be clear I was using i2c communication with the Titan GPS module and not the UART on the TX & RX lines. Not sure if that makes any difference, but it works perfectly for me as pictured.

Have you made any progress with something that does work?

Iras · June 21, 2018, 9:56pm

Just came across this thread. I, too, have problems with getting GPS fixes with a GPS sensor attached to an Electron.

The sensor I’m using is a GP-20U7 module (I’ve also tried a U-BLOX UBX-G7020-KT).

The GP-20U7 module has been rock-solid when used with an ESP-8266 platform or an ESP-32 platform. Rock Solid! But in converting the project to the Electron, the module has problems getting a fix. When I monitor the serial data stream, the data seems incomplete (dropped characters or bad characters). Even when I try to just use the GPS module with sample code, same issue.

This thread seems to point to one of two problems - either RF interference from the electron, or noisy power. During testing, the GPS module is on pigtails about a foot from the electron. No help. As far as power, GPS power is coming from the electron’s 3.3V pin, with the Lipo battery attached and USB power coming from a laptop (or 120V wall wart).

One other bit of information. The UBX-G7020-KT has an onboard LED that lights up when it gets a fix. I assume that happens independently from any communications to the electron, so even if the serial data stream is getting corrupted, I would think that the LED would still show good status - and it doesn’t indicate a fix. So I’m inclined to eliminate an issue related to serial transmission.

Any insight would be appreciated. I have the entire project converted to run on the electron (temp sensing, Bluetooth communication to a remote module, OLED display, etc) and the only thing holding this up is getting the GPS piece to work reliably. NOTE: during testing, all of this other stuff isn’t there - just the TinyGPS example code.

rickkas7 · June 21, 2018, 10:03pm

There are two additional possibilities.

In the default automatic with system thread disabled mode, the loop() is only called 100 times per second. This could cause a loss of data if there’s a lot of serial data coming from the GPS as the FIFO is only 64 bytes deep. Enabling SYSTEM_THREAD(ENABLED) allows the loop to run significantly faster.

Also, if you’re using the AssetTracker library, I’m not a fan of the Adafruit GPS parser in it. I prefer the TinyGPS++ parser. That’s the one I use in my replacement library AssetTrackerRK.

If you are using you own parser or directly calling TinyGPS or TinyGPS++ make sure you process all of the available serial bytes, not one per loop.

Iras · June 21, 2018, 11:37pm

I definitely have SYSTEM_THREAD(ENABLED) because in the live project I don’t want PUBLISH’s to block if there is no connection.

I’m using:

#include “TinyGPS.h”

And the test loop is:

  bool isValidGPS = false;

  while (Serial5.available()){
        char c = Serial5.read();
        Serial.print(c);
        
        // parse GPS data
        if (gps.encode(c))
            isValidGPS = true;
    }
    if (isValidGPS){
       float lat, lon;
       unsigned long age;

       gps.f_get_position(&lat, &lon, &age);
    
       sprintf(szInfo, "%.6f,%.6f", (lat == TinyGPS::GPS_INVALID_F_ANGLE ? 0.0 : lat), (lon == TinyGPS::GPS_INVALID_F_ANGLE ? 0.0 : lon));
    }

I’m using serial5 because serial1 is used for BT in the “real” project. Also tried serial4, but really the same.

What is TinyGPS++ and how is it different/better?

Thanks.

Topic		Replies	Views
GPS causes hanging on wake from SLEEP_MODE_DEEP Troubleshooting	2	1629	August 29, 2017
3G Electron _ Unable To Get GPS Location General	7	967	December 5, 2018
Electron sleep problems, yet again Troubleshooting	39	3769	August 20, 2019
Cellular.connecting and deepsleep Troubleshooting	4	600	May 16, 2018
Asset tracker GPS - wrongly indicated that a GPS fix is found Hardware	12	2592	August 6, 2017

GPS interference from Electron

Related Topics