GNS Module Layout: Battery Proximity

[waymond91]

Hello All,
I am working on a GPS project that uses a CAM-M8 Ublox module.The back of the board has two clips for attaching a AA LifePo4 battery to supply unregulated power to the boards components. To this end, the board was going to be 15x61 mm - the minimum size required to clip onto the AA battery and still accommodate my wider components.



However, according to the hardware integration manual https://www.u-blox.com/en/docs/UBX-15030063 (page 15, section 2.6) for the GNS receiver, I have to:
1) Ensure a minimum ground plane of 20x45 mm
2) Keep 6mm of clearance around the receiver module
3) Keep the receiver at least 10mm from the corners of the board

Ugh fine, so I made the board shorter & wider, and I am now using 14430 LiFePo4 so I can trim the length.
So my question now is, if I have the battery mounted directly underneath the GNS receiver (as shown in the pictures), how much of a problem am I making for myself?
According to the data sheet ‘Note that the embedded GNSS atenna requires a small ground plane clearance and a void read (4.8 x 7.2 mm) for copper plane and trace for all layers under the antenna. Placement of other components is not allowed under the keep-out area on the opposite side.’ Ok, so I've added the keep out zone to board (shown in orange on the PCB layout, and white on the bottom silkscreen of the 3D view)



Is this layout really going to hurt performance? I really don’t have much experience with this and don’t know how to quantify the effect on performance. Perhaps somebody can shed some light on the matter. According to the data sheet, by going this small I have already cut the receiver strength by 6dB ‘A 45-mm wide application board reduces the signal levels by at least 6 dB compared to full 80x40 mm ground plane’

The device is designed to be used on the water, so it should always have a clear view of the sky. However, I don’t want to reduce performance if I don’t have too…
Cheers!
Brett

[Martin Miranda]

the big battery itself is a ground plane. in RF frequencies any big mass of metal is as good as a ground plane. even a VCC/VDD copper pour on your pcb is still a ground plane. (based on that gnss module)

[Martin Miranda]

we developed lorawan gnss tags. is really suggest that have it prototyped quickly as possible first. then get the performance data off the gps module. if this is a wearable you also have to consider the whole body as a ground plane.

[waymond91]

Thank you Martin, this is exactly what I needed to know (and hear)!!!

[jc101]

I recently used the CAM-M8Q (avoid the CAM-M8C if you can) and the ground plane size is critical to getting it to work.  Also important is clean power.  I found that the PLL in the uC I was using generated a harmonic right in the GPS band.  It was really low, but as the GNSS signals are like -130dB it didn't take much to block it.  Popping a 47nF cap right across the battery connector killed the radiated emission and it sprung into life.

Also, don't forget to connect pin 16 to 17 with ideally a 50ohm trace to connect the antenna to the module.  Plus pin 9 (VCC), 8 (V_BCKP), and 1 (VCC_IO) all need to be powered.  I had the 4.7uF decoupling cap on Pin 9 rather than 1.

[waymond91]

Ok this is a big help!
I didn't know that the trace needed to be 50 ohm betwen pins 16 and 17.
Also, the data sheet made it look like the decoupling capacitor needed to be on pin 1, but obviously it should be on pin 9
With regards to the power, I really do not have anything filtering. As I mentioned, my plan was just to pass a lifepo4 battery through a diode/fet for reverse current protection and then just decouple everything and call it a day. Can you point me in the right direction for filtering the power? Would the filter be on the output of the battery or in the input of the module?

I also didn't realize they had two price points for this part, octopart doesn't show any options for the M8Q...

I am not attached to this particular part, I was just looking for something small, low profiles, and didn't invovle doing any of my own RF traces... Perhaps you think there is a better alternative part?

[jc101]

Ideally, it should be 50ohm just to reduce the loss from the antenna.  I just used a 1mm trace between the two pins, which was pretty close and it worked fine for me.

I suspect you might be OK filtering wise, my problem was the PLL in the uC went straight through the buck/boost converter and onto the battery cable - which sat directly over the GPS ~12mm away.  It was way below limits for EMC etc. The units would work fine when not in the box, but with the lid on (battery was stuck to the lid) no GPS lock.  Took a while to figure out the problem was radiated from the battery cable.  I also put the recommended ferrite on the UART RX/TX lines, but a small resistor will do just as well.

The only way to know for sure is to build one and test it.  I also programmed the uC to pass through the TX/RX up to a PC running U-Centre to get all the data from the module during testing.

These are great modules, the Q version has a txco but the C version is just a crustal and it takes much longer to get a fix. I think you also need a better signal with the C over the Q.  The Q's can be hard to find, I got some by ordering "sample" quantities from U-Blox via a UK based distributor.   This gives the differences https://www.u-blox.com/sites/default/files/CAM-TCXO-to-Crystal-Migration-Guide_AppNote_UBX-21004953.pdf

I looked around for something equivalent but couldn't really find anything that fitted the bill.

[Martin Miranda]

and it takes much longer to get a fix. I think you also need a better signal with the C over the Q.

a good office window with a clear view of sky, and PATIENCE. a lot of patience for gps to lock. the newer gnss module is fast. but what i worked before is just 

[waymond91]

Thank you so much, this saved me a lot of hassle - especially that bit about the 1mm trace width 
That makes more sense now about the PLL - if its driving the converter than I guess it could be a nasty source of noise - I suppose any switching converter would be for that matter.
For a minute I was doubting everything I know about electronics hahaha

[waymond91]

Are you sure that the trace width between 16 & 17 was 1 mm? It seems a little too large to fit in between the pads without basically doing a fill.

[jc101]

Are you sure that the trace width between 16 & 17 was 1 mm? It seems a little too large to fit in between the pads without basically doing a fill.

Sorry, 1mm long, 0.452mm wide. Between the centre of the pads.

[Leo Bodnar]

This design has always worked well for me in the past.

I didn't know that the trace needed to be 50 ohm betwen pins 16 and 17.

1mm long piece of copper can't be "50Ohms", considering the signal wavelength is 200mm.

Leo

[waymond91]

Leo, that HAB tracker on your profile looks pretty sweet! Pretty similar to what I'm trying to do here.
I don't suppose you have some documentation for it or other reference designs you could point me towards?

As for the 50 ohm trace between the pads, this is all I can find in the manual that references what the impedance should be.

I'm assuming that by the description of RF_OUT that this is supposed to 50 ohm?

Sorry a little extra guidance here would be great - I was using a module with an embedded antenna to avoid this kind of thing.

[jc101]

Leo, that HAB tracker on your profile looks pretty sweet! Pretty similar to what I'm trying to do here.
I don't suppose you have some documentation for it or other reference designs you could point me towards?

As for the 50 ohm trace between the pads, this is all I can find in the manual that references what the impedance should be.

I'm assuming that by the description of RF_OUT that this is supposed to 50 ohm?

Sorry a little extra guidance here would be great - I was using a module with an embedded antenna to avoid this kind of thing.

When I was doing my design I had an hour or so on a VC call with a design engineer, which was quite handy.  The optimal solution is to link the antenna to the RF-IN via a 50ohm trace, the short fat link was as close as I was going to get.  The CAM-M8 has the antenna on the same module, but it isn't physically connected to the GNSS module unless you link the two pins.  So you could have a switching connector to switch between internal / external depending on what you plugin.

I made also life difficult as the design had a UWB radio on the same side of the PCB but opposite edge, and an ECG which needed clean power.

[Martin Miranda]

not related to the topic. you might also want to use the esp-pico-D4.
https://lcsc.com/product-detail/RF-Transceiver-ICs_Espressif-Systems-ESP32-PICO-D4_C193707.html
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/hw-reference/esp32/get-started-pico-kit.html

[Leo Bodnar]

I'm assuming that by the description of RF_OUT that this is supposed to 50 ohm?
Sorry a little extra guidance here would be great - I was using a module with an embedded antenna to avoid this kind of thing.

Transmission line concept only makes sense when its length is comparable to the wavelength of the signal.  Say, for GPS signal 300mm piece of coax is a transmission line but for audio it is just a conductor with a bit of DC capacitance and a bit of DC inductance.  Rule of thumb is: anything smaller than 1/5...1/10th of a wavelength is a lumped component (so just C or R or L.)

1/10th of wavelength for GPS is 20mm in free space and 10mm over FR4.

A driveway in front of your house is a runway for a toy aeroplane but just a patch of concrete for a real car.  You can build it to F1 or NASCAR track standard, of course, but it does not make it 200mph driveway.

What Ublox appnote really mean is that you should use some good care when your GPS module is in the middle of your large PCB (say, 19" rack component) and your switch is at the back, near the external antenna socket.

Always use common sense!

Leo

[hagster]

I once worked with one of these embedded antenna ublox boards. I guess I was a bit cavalier with the design at first, but had lots of EMI issues with it.

As others have said the ground plane is especially important for this to work. IMO you almost certainly need 4 layers to keep it as solid as possible. Really the small ceramic patches are vastly better, and will work with smaller ground planes.

Interference from any onboard digital signals or switching regs can have an effect. Use the recommended resistors on all IO lines to mitigate this and make sure the supply is clean.

I don't think the proximity of the battery will have much effect.

Not sure if the design guidelines say anything about enclosures but most typical plastic can have a fairly large effect on resonant frequencies is placed close to the antenna.

In free space with a good line of sight to the sky you can get away with a lot, but it will effect accuracy and time to first fix.

UBlox uCenter(the old one rater than uCentre2 which sucks) has an included spectrum analyser(ubx-mon-span message) feature on the latest GPS engines. This lets you see the see any interference fairly easily.

[Leo Bodnar]

If you want to know whether your design is producing crud killing the GPS reception, monitor CW Jamming Indicator in UBX-MON-HW using u-center.
Leo

[waymond91]

Thank you all for the feedback! Here is the latest below.
I feel like I'm closing in on something at least half-way decent given the constraints.
I'm just fiddling around with how to ground the board properly.
Last night as I was working I thought it was necessary to fill the layer the GPS is mounted to with a ground pour, but now I'm suspecting a 3.3V pour would be better.  As I have a ground layer directly below the gps, it seems that having two pours might be making controling the return paths more difficult for myself to comprehend.
The battery has a low side fet for reverse current protection, that all of the current must pass through - you can see it to the left of the GPS module.
I also still need to add a fill to signal layer (green) but I am also unsure what that should actually be, presumably ground?
How am I looking here?
 

[tszaboo]

For that layout, a patch antenna would work better. Also, decide on the enclosure, because that matters.
For such a project, I wouldn't use a module with a built in antenna. Those are OK for proof of concept projects, or boards where you can just place it into a large box, and keep everything away from it.
For small devices, you really want to place the antenna matching yourself, or be prepared, to loose a lot of performance for the signal. Depending on the radio protocol , it can be fine (just set more power to the RF amplifier), but for GPS, the margin for error is not that large.

[Anders Petersson]

Right now I'm having to spend weeks optimizing the GPS of my product, after being overly optimistic the reception quality would be good without bothering with the small details.

Where in doubt, add a footprint and choose later whether to populate it or not. For example decoupling caps.

tszaboo is correct, a patch antenna is better here but perhaps you're constrained to the current design. Second best is using a GPS chip (for example EVA-M8) and a chip antenna with a custom antenna matching. Third best is to support an external active antenna, for example via a small uFL connector or SMA. Ublox has a reference design for this. It's about 10 extra components. That would buy you a backup solution.

As early as possible in the project, test with enclosure(!) and battery in your intended environment. One extra risk in your case: A chip antenna is quite omnidirectional, making it sensitive to GPS signal dropout from multi-path fading when in your scenario the water surface reflects the GPS signal. TTFF (time to first fix), DOP (dilution of precision), number of tracked satellites are some metrics to check.

Lastly, do ask for help to save lots of time. Even paying for help is well worth it, IMHO.

[waymond91]

Ok this was super useful feedback, and it critical that this works correctly so I'm just going to expand the board a bit. I am switching to a patch antenna; I would never have thought of the reflections issue - I'm assuming that a patch antenna is a little more directional, so reflections off the water should be less of an issue?
Anyway, now my plan is to stack two 40x40mm boards on top of eachother, where the top board is a dedicated gps receiver. I know this could be easy enough to buy, but adafruit latest gps module has a logging feature that would allow me to sleep the main controller and save on power and hopefully battery down the line.




How is this looking? My only big question is about the via stitching. I've only ever really done star point grounding before. I'm assuming I shouldn't cut a hole in either of the ground planes in order to constrain the current return path at all?

These are the datasheets I found for the module: https://ufile.io/f/nkx50

[Anders Petersson]

This is much better. Yes a patch antenna is directional (so the users should not place the unit upside-down). The layout is fine... but it looks like L1 connects to the ground plane instead of VCC.
I don't think the ground planes are critical here and the return current path is even less critical. A via or two close to C2 could have a marginal benefit.

Last I checked, CDTop doesn't have as advanced power-saving as uBlox, no wonder given the vast difference in size between the companies. If you need both continuous tracking and low power use, uBlox is a safer bet. My experience is that CDTop is true to their datasheet, so that's good.

Given the global component shortage, what's available to buy might be your biggest constraint here.

[Martin Miranda]

misplaced?

[waymond91]

Thank you both so much! Good catch on the ground 
A quick question regarding power consumption of the uBlox vs. CDTop:
My plan was to use an esp32 of some flavor just to make it easy to offload data after dives.
However, the esp32 seems pretty dang power hungry, especially when compared to something like an avr or some 32 bit arm thing.
So because the CDTop offers tracking, it would allow me to just sleep the esp32 most of the time, the saving quite a bit of power.
Does the sam-m8q module offer anything similar? I've seen that it has memory but nothing about logging features.
My budget isn't so tight that I can't make two design one with each module - but I was just wondering.