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!
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
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.
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
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?
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.
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
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
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
or maybe avr v stm32 e.g. 16MHz / 72MHz
capacitor quality & quantity?
srp
GPS —> ferrite —-> Maple
- filter.JPG (10.51 KiB) Viewed 1367 times
or maybe avr v stm32 e.g. 16MHz / 72MHz
capacitor quality & quantity?
srp
Tried with NeoGPS/TinyGPS++ libs, so if someone has any ideas I’m all ears. Thanks
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.
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
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)
As an experiment, try to change the BP’s clock, what happens.
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.
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?
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
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)
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..
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.
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.
Can you change the thread title, to indicate you now have a fix.

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.
[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.
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
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.