SparkFun Forums

[zogdc]

Hi,

I'm still a bit of a newbie, so forgive me if this is an obvious question.

I'm trying to use the XSTANDBY pin on a Copernicus II module to put the module into standby (low power) mode. According to the manual, "This logic level input is used to control the RUN/STANDBY state of the module. If this signal is High, the unit will run normally. If this signal is Low, the unit will go to “STANDBY” mode." Easy enough.

Now, I'm powering the GPS module through a Breadboard power supply stick (at 3.3v of course), so I'm thinking that I should just be able to connect the XSTANDBY pin to ground. However, when I do that the power indicator LED on my power supply stick blinks off, which suggests trouble to me. Sure enough, my DMM shows a short between the VCC and XSTANDBY pins on the GPS module (with the module complete disconnected from anything else).

My newbie question is: is this normal for this module or does this suggest it's broken? I've soldered in some header pins, but I'm quite sure my soldering job is okay. The schematic also shows a solder jumper between VCC and XSTANDBY, but I haven't touched it, and it looks good (i.e., open) to me.

[shraken]

Hi Zogdc,

I would recommend not using the XSTANDBY pin on the Copernicus module. I found there is no way to wake up the module up after switching the XSTANDBY pin to low. I would recommend instead using NMEA or their serial protocol.

As for the problem you are describing, if the power for your LED supply is flashing off it suggests a short. Can you put a DVM as an ammeter in series to monitor the current draw? The current draw for the Copernicus 2 module should not exceed 50 mA or so when fully powered on.

For reference, I use the following on the 4800 bps UART to shut the module off: "$PTNLSRT,S,0,2,0*32\r\n" and I use "$PTNLSRT,H,0,0,0*2B\n\n" to wake the module up. This sets the module to sleep until data is on the Trimble TX pin with hot start.

[zogdc]

Hi shraken. Thanks for your insights.

I would recommend not using the XSTANDBY pin on the Copernicus module. I found there is no way to wake up the module up after switching the XSTANDBY pin to low. I would recommend instead using NMEA or their serial protocol.

Wow, that's very surprising. Not at all what the documentation describes, and suggests that either the module or perhaps the BOB is seriously flawed. Hardware-based standby mode is essentially useless then(??).

As for the problem you are describing, if the power for your LED supply is flashing off it suggests a short. Can you put a DVM as an ammeter in series to monitor the current draw? The current draw for the Copernicus 2 module should not exceed 50 mA or so when fully powered on.

Yes, I'm quite certain there's a short on my module b/t VCC and XSTANDBY, my DMM confirms that. What's weird to me is that the board layout is VCC / GND / XSTANDBY and I'm not reading a short b/t VCC-GND or GND-XSTANBY, so I don't think it's a solder jumper or anything like that. I think I don't understand how the board works, or something is toast.

For reference, I use the following on the 4800 bps UART to shut the module off: "$PTNLSRT,S,0,2,0*32\r\n" and I use "$PTNLSRT,H,0,0,0*2B\n\n" to wake the module up. This sets the module to sleep until data is on the Trimble TX pin with hot start.

I thought about that, but I want my project to power down with a simple SPST switch, with a battery providing standby power to the GPS through the XBAT pin so I can do hot/warm starts. A lot more complicated if the Arduino has to detect the switch, set the GPS to standby, then power itself down.

I've spent a lot of time trying to get the Copernicus module to work well, and I'm just about ready to throw in the towel. Any experience with the Venus GPS?

[shraken]

1. I could never get the module to wake back up when I pulled XSTANDBY low. The datasheet shows a timing diagram with a 50 msec process time to goto sleep.

2. Are you using the Sparkfun Copernicus kit? I have the version 1.0 of this breakout board. I used my Fluke to test for continuity between XSTANDBY and VCC and it's not shorted.

Does your module output NMEA or TAIP messages on the UART interface? What is the current draw of the module when powered from a 3.3V power supply?

3. I agree. The ideal solution would be a hardware standby condition to power both the GPS module and microcontroller off with a single switch. Sounds like you have a good idea for what to do on the software route. Certainly not impossible but a bit of a hassle. If done right in software the performance is just as good as hardware, you can get a MCU to draw around sub 1 uA in sleep mode, I do this in application I'm working on.

I have not used the Venus chip but assume it has a similar power feature. I'm tepid to use it because of the BGA package is a challenge to prototype with in small runs. I'm eventually moving to using uBlox GPS modules because they're easier to source, well documented and well maintained with a regular release cycle.

[zogdc]

Update: it turns out that the latest version of this module does indeed have a solder bridge between VCC and XSTANDBY that is connected by default. The connection wasn't quite clear on the schematic but it makes perfect sense. Once I broke the trace, everything seems to work as expected. I can pull XSTANDBY high or low (which I just did by just connecting jumper wires to different rails on a bread board) to control the runtime mode, and NMEA output starts and stops as expected. The solder bridge was not present on previous versions.

@shraken: sounds like you have an older version of the module, which explains why your hookup is different. I wish I had insights on why hardware standby isn't working for you, but it seems to work fine in the latest version.