No fix on u-blox neo 6m

Hi

I purchased a couple maple-mini clones from ebay in order to test their capabilities and see if they could replace my Teensy on some finished and ongoing projects. I managed to program them quite easily (Thanks to all of you!).

Hooked up a cheap GPS module (u-blox neo 6m) and I’m having a lot of trouble making it getting a fix. The wiring and serial connection are working as I see the incoming data in the serial monitor. Also, I’m getting a fix almost instantaneously in the Teensy and a NANO.
I have tried to replicate the same conditions on the other boards, but it seems like the only ones which are not working properly are the maple clones.

At first I thought it could be a power issue, as the VCC line is not that smooth as on the Teensy. But the same issue is observed by powering it from Vin. Tried with a 3.3 voltage regulator but even that seems to fail.

Right now I’m running out of ideas. Does any of you know what could be happening?

Thanks!

What exactly is not working? Which serial interface are you using?

You need to separate out the changes and test them individually in a scientific way.

E.g. if you think the problem is power supply noise or instability, then power the GPS from the Maple but connect the Serial data lines to the AVR ( and also connect their GND together)

Also try holding the Maple mini in reset in another test in this config.

Then do it the other way, e.g perhaps power from the Teensy, but data to the Maple mini

Or power the GPS from a battery and only connect serial plus gnd to the Maple mini

Perhaps also consider RF noise, e.g. power and data to AVR but also run the Maple mini to generate noise

Hi Steve and Roger, sorry for the poor description.

These devices use USART. I’m using Serial1.
The reported NMEA sentences show no information regarding time/date or any position. They do appear in the correct format, but the info between the delimiters is just a bunch of invalid data (9999 or similar, typical default numbers I guess) or no data at all. This changes as soon as I power it using the Teensy, keeping the data line on the maple and grounding them together as Roger suggested. That is why I first thought it was a power related issue.

I’ve estimated the current output with the module on and have not seen anything higher than 100mA.

The voltage regulators on some Maple mini and generic STM32 boards are very low quality

I’d recommend if you need 3.3V to power it (rather than 5V) then use a different source of 3.3V.

Next you’d need to see if the data that the Maple mini thinks is garbage is really garbage or its its interpretation of valid data.

There is nothing to stop you connecting a USB to Serial adaptor RX input to the RX input of the Maple mini and look at the data that appears on both, to determine if the data is corrupt or not

As Roger indicated, try separate 3.3V power supply for that module.
How do you inspect the serial data comming out of the module? On PC with the serial monitor? Can you show the hw connection on a picture?

jucordero wrote:Hi Steve and Roger, sorry for the poor description.

These devices use USART. I’m using Serial1.
The reported NMEA sentences show no information regarding time/date or any position. They do appear in the correct format, but the info between the delimiters is just a bunch of invalid data (9999 or similar, typical default numbers I guess) or no data at all. This changes as soon as I power it using the Teensy, keeping the data line on the maple and grounding them together as Roger suggested. That is why I first thought it was a power related issue.

I’ve estimated the current output with the module on and have not seen anything higher than 100mA.

Hi again!

Thank you all for your replies.

Steve: I’m inspecting data directly in the serial monitor, by printing all data received by the serial port.

Here is an example of the typical incoming data:

$GPRMC,215449.00,V,,,,,,,301016,,,N*77
$GPVTG,,,,,,,,,N*30
$GPGGA,215449.00,,,,,0,00,99.99,,,,,,*69
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,2,1,05,03,,,21,15,,,18,20,,,22,22,,,28*7A
$GPGSV,2,2,05,31,,,30*7D
$GPGLL,,,,,215449.00,V,N*45


An oscilloscope on the power input to the GPS module might provide some clues, you may simply need a few more decoupling capacitors or shorter leads.

jucordero wrote:
Here is an example of the typical incoming data:

$GPRMC,215449.00,V,,,,,,,301016,,,N*77
$GPVTG,,,,,,,,,N*30
$GPGGA,215449.00,,,,,0,00,99.99,,,,,,*69
$GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30
$GPGSV,2,1,05,03,,,21,15,,,18,20,,,22,22,,,28*7A
$GPGSV,2,2,05,31,,,30*7D
$GPGLL,,,,,215449.00,V,N*45


Yes, it is possible to change the online 3.3V regulator, just pick up one with the same pinout but at least 200mA.

1. GPS knows the current date and time (so it has a signal)
2. GPS is showing multiple satellites (so it has multiple signals)
3. GPS doesn’t know where it is (satellites have no relative position info, and the other position fields are empty)
4. GPS doesn’t have a lock (see #3)
5. GPS doesn’t have many satellites with strong (greater than 25dB) signals

3, 4, 5:

On Neo-6 units I have purchased from China, the worst-case time to work through the “where am I” logic has been a few minutes over 10 hours! This has been repeated 5 times with new units, so do not give up. It all depends on signal strength, sats in view, and many other little issues.

After the first full sync, power-on to lock is under 30 seconds consistently.
Ray

The true mystery is the fact that the receiver does fix its position within a reasonable TTFF (30 seconds) placing it on the same breadboard with a different MCU. Again, it doesn’t seem to be a signal strength issue or sky view, unless the Signal to Noise has any dependence on the internals of the device.

same cpu e.g. both blue pill or blue pill v maple mini
or maybe avr v stm32 e.g. 16MHz / 72MHz
capacitor quality & quantity?
srp

jucordero wrote:The true mystery is the fact that the receiver does fix its position within a reasonable TTFF (30 seconds) placing it on the same breadboard with a different MCU. Again, it doesn’t seem to be a signal strength issue or sky view, unless the Signal to Noise has any dependence on the internals of the device.

Try to pass all three wires (gnd, vcc, data) via a ferrite bead/toroide (2-3 windings through the toroid for example).
GPS —> ferrite —-> Maple

filter.JPG (10.51 KiB) Viewed 1367 times

zmemw16 wrote:same cpu e.g. both blue pill or blue pill v maple mini
or maybe avr v stm32 e.g. 16MHz / 72MHz
capacitor quality & quantity?
srp

Did someone manage to make it work. I have the same problem, I will try to scientifically test tomorrow, because all my receivers work either with the Arduino Pro Mini or directly connected with USB to serial with the u-center (even through wine on linux). I also used couple of decoupling capacitors on the GPS and still a no-go (Both with external LDO and with the build in, no difference).

Tried with NeoGPS/TinyGPS++ libs, so if someone has any ideas I’m all ears. Thanks

Hi,

I want to report back and seek some advice. It seems that if I connect the GPS directly to a power source on the breadboard everything is fine. Nothing else on the breadboard is powered (I have an SPI device, the Blue Pill and I2C device /10DOF-IMU/). Once I connect the GND to the GND of the Blue Pill, the GPS stops working correctly. Again, nothing else is connected, nor is the Blue Pill powered, just attaching the GND to the GND of the breadboard (where the GPS is already connected).

I disconnected the GND from the Blue Pill and attached the RX/TX wires from the GPS to the Blue Pill. Again, nothing else is connected or powered (except the GPS), This also messes up the GPS but also causes the Power LED of the Blue Pill to start blinking in sync with the LED of the GPS. I’m a bit lost here. I don’t have an oscilloscope around, just a very cheap multi-meter. Any ideas guys? Seems like either something is shorted on the Blue Pill (it is the same with my whole batch, I have 5 of them) or it is some grounding/decoupling issue.

Any help will be greatly appreciated.

It could simply be picking up so much noise (unfiltered mains hum, or other environmental RF for example) from the room, due to the long ground wires acting as an antenna, that it swamps out the signals. Are there RF screening cans surrounding the high frequency GPS components, if so are they grounded or are the components simply on a bare board?

Show us some pictures of your exact setup. The blinking in time to the LED suggests a poor connection somewhere, or your power supply is sagging under load.

You may need to fabricate some “tin hats” for some of the elements of the system to keep the mischievous RF pixies from getting into, or indeed out, of things they shouldn’t. You may be able to fabricate something using tin snips or stout scissors, and a few thin steel “tin cans”, or even just hide the sensitive bits under some earthed single sided PCB material. A more professional finish would require some tin or brass sheet. Easily obtainable from all the usual ebay suspects. Small brass sheet offcuts would to the trick and are pretty cheap. For example -> http://stores.ebay.co.uk/SGS-Metals/Cle … 34.c0.m322

I dont think you should need to go to these lengths, but recently I have been using some 1W 5V DC to DC isolators, to prevent CPU noise getting into the audio input of HiFi amplifiers.

They are fairly inexpensive, I think about $2 each, and provide complete galvanic isolation, and are good at getting rid of high frequency noise. ( however they may not get rid of terrible hum)

There could be an issue with BP’s oscillator harmonics. The ~21st harmonic of the 72MHz may jam the GPS receiver.
As an experiment, try to change the BP’s clock, what happens.

Hi. In reverse order. I’ll change to 48 Mhz, to see if that will have some effect (I’m using a ST-LINK to upload and I’m using Serial3 for serial).

I’ll look into the DC to DC isolators, hopefully those could help, if I can get my hands on those soon enough.

Btw, here are the pictures of the setup. Essentially I have the same on another breadboard but with Pro Mini, and the same setup works.
https://www.dropbox.com/sh/usmsbtvekcj1 … W9APa?dl=0

Sidenote, I’m also having problems with my LoRa module and the LMIC, but that is a problem for another day. I’m using the modified version of LMIC by Tomtor, but I’ll ping him directly for ideas on the email from github, although I suppose the issues might be related to the one I have with the GPS.

OK, I tried with 48 Mhz. That didn’t help but I still think it’s not a RF problem, because as I mentioned, as long as the GPS is connected to either the GND or any of the RX/TX pins on the Blue Pill, the GPS doesn’t work. This is when the Blue PIll is not even powered. Again I repeat, the MCU is not powered.

As I mentioned, if the RX/TX pins are connected from the GPS to the Blue Pill, this causes the power pin of the Blue Pill to blink too. Again the Blue Pill is not connected to either GND or Vcc.

I’m using 3.3 external LDO to power he devices btw.

I wonder, could the GPS breakout board be the problem, as I think it is 3.3/5V tolerant, could the level shifting cause problems?

Is the GPS 5V device?? Are the GPS’s TX/RX 5V logic?
If yes then you are powering the BP via the internal BPs clamp diodes from the GPS’s TX/RX pins as they are 5V idle.
Put 1k (or 2k2 or 3k3 or 4k7) resistors in series with Tx and Rx:
BP TX ——[1k]—— GPS RX
BP RX ——[1k]—— GPS TX

This is a 5V tolerant device. It is one of the so called Neo-6M GPS from the Chinese manuf. Actually it has the exact same LDO as the one on the Blue Pill. I tried with 2k2 in series with TX/RX. Same situation. If I connect this device with the exact same setup on another breadboard with ProMini (8V/3.3) everything works. The GPS works if connected to USB-to-serial converter. Once I connect it to the Blue Pill (GND/RX/TX) the GPS goes crazy. Seems the only pin that does not affect it is Vcc. And this is when connecting to a Blue Pill that is not even powered on.

The only thing I haven’t tested is to connect the GPS directly to the Blue Pill without the breadboard. *The breadboard is OK, as the 10DOF is working fine on the I2C.

Completely stunned by this situation. I know there is communication between the GPS and the Blue Pill, but the data is corrupted for some reason. The serials on the blue pill are fine, tested them with serial to USB and the GPS is ok, again USB to serial. Also GPS to Arduino is fine. I’m getting frustrated as I’m trying to build a POC, but I would like to use HW Serials and the AVRs don’t have enough (except the Mega, which I don’t have around currently)

If I connect this device with the exact same setup on another breadboard
BTW, there are breadboards which do not have continual GND and VCC rails, you must use jumpers. Just an idea when all is the same but only the breadboards change..

+1

I think you should try without the breadboard, its a nest of various lengths of hundreds of wires, all capacitively coupled together.

Use a single ground, put RF chokes in both ground and supply to the BP, keep wires short. If necessary, shield the BP inside a aluminium foil box.

Hi Roger and all,

Just coming back to report back. I basically discarded the breadboard, connected the GPS directly with jumper wires to the Blue Pill and everything works pretty nice. Then connected the 10 DOF IMU to the I2C, both working fine.

On that note, I can confirm that TinyGPS++ works nice on the Blue Pill, also NeoGPS works pretty nice too in NMEA mode.

Now let’s see if I’ll be able to make the InAir9B work. I connected it to another Blue Pill, and I just started debugging.

Thank you all for the support. Sidenote I always hated breadboards, but when prototyping with a lot of sensors it’s usually handy.

Thanks for letting us know the outcome.

Can you change the thread title, to indicate you now have a fix.

Hi Roger, sorry for not getting back earlier, got a bit of a flu or something. This actually is not my thread, I shamelessly hijacked it, because it was exactly the same situation I was facing. Sidenote, with a bit of help from Tomtor LoRaWAN is working flawlessly with Arduino-LMIC lib. I don’t know what is the proper way of reporting working libs, but if someone does a search – LMIC works, you just need tomtor’s LMIC github repo.

People sometimes post to the libraries section if they have ported a library, or if they find a particular library works with no changes.

I should probably formalise this.

I should probably do something similar for hardware, e.g. I tried one of those H Bridge motor controllers the other day, and it seemed to work fine wirh 3.3v PWM

[RogerClark – Wed Jun 21, 2017 10:36 pm] –
People sometimes post to the libraries section if they have ported a library, or if they find a particular library works with no changes.

I should probably formalise this.

I should probably do something similar for hardware, e.g. I tried one of those H Bridge motor controllers the other day, and it seemed to work fine wirh 3.3v PWM

Sounds like a good thing to put in the Wiki, perhaps a section for working hardware and a section for working libraries.

Ilf, thank you for reviving this post. I actually could not resolve the issue. Even changed the LDO for two maple mini clones with no results, but never tried removing the breadboard from the equation. I’ll give it a try today so we can have a larger sample of results.

[jucordero – Fri Jul 14, 2017 12:40 pm] –
Ilf, thank you for reviving this post. I actually could not resolve the issue. Even changed the LDO for two maple mini clones with no results, but never tried removing the breadboard from the equation. I’ll give it a try today so we can have a larger sample of results.

… There is not an issue with Neo 6 and the Maple Mini clone – I have used both many times with Adafruit’s GPS library and even my own non-library parsing function. I do however use the 9600 BAUD default serial speed of the ublox.

Example project

When the Neo6’s arrive from China, they will take a very long time to get the first fix; My worst case was over 10 hours.

Ray

Ray,

Can you an approximate location to the GPS to help it with its initial fix?

I think some GPS units support this.

Also puttin the unit outside so it gets a clear view of as many satellites as possible normally speeds up acquisition time.