P1 vs. Photon Wifi Acquire Time


We have designed a custom PCB based around the P1, and we notice the P1 is slower (many times significantly slower) than a Photon in acquiring and connecting to the same Wifi network. Is this difference to be expected?

Side by side comparison video of P1 on custom PCB vs. Photon on breadboard Wifi acquire time: http://imgur.com/zQ2TGuU

Thank you for your help.

It looks like @peekay123 tried to answer this, but in the wrong thread:

OMG! It’s a good thing there are smarter people than me in the Community! :flushed:

The things I would investigate would be:

  • Antenna (have a tried a known-good antenna with a u.fl connector?)
  • Power supply (using a scope to look at ripple, voltage, current spikes, etc.)


Interference with other hardware is most likely the cause. I noticed the same when I connected a Sparkfun sound detector to the Photon. It even didn’t connect to the WiFi anymore or took a long time.

The sound detector contains an opamp which picked up the WiFi signal and multiplied it causing to much interference. After adding a 100nF C to the feedback to create a lowpass filter and adding some 100Uf C’s to the powerlines I was able to get it working again.

Using the WiFi.RSSI() function you can compare the WiFi signal strengths, most likely the P1 will report a worse value then the Photon.

Goodluck and please report your solution if you find one!

Best regards,

1 Like

Thank you lloydo, peekay123, bko, and lucb. In answer:

Firmware: 0.4.7

User Code: same for Photon and P1 (with exception of P1 spare pins used on P1)
Question: if in SYSTEM_MODE(AUTOMATIC), does user code run prior to WiFi acquisition?

PCB Design: no copper under P1 recommended keep out zone:

Antenna: have not tried known-good antenna with u.fl connector

WiFi Received Signal Strength:
Samples collected from Photon on breadboard and P1 on custom PCB with WiFi.RSSI() funciton, both connected to same WiFi network, 10 samples in a row taken from Photon, then 10 samples in a row taken from P1, samples taken roughly two seconds apart

 Photon on breadboard (dB): -66, -66, -67, -66, -67, -67, -67, -67, -66, -67

 P1 on custom PCB (dB): -75, -77, -77, -75, -76, -76, -75, -75, -76, -76

Question: if multiple WiFi credentials are stored in the P1, how does the P1 go about acquiring a specific SSID? Does the P1 assign any certain priority to each SSID based on when the SSID was stored in memory?

Generally you should have no traces above this either - the antenna needs separation from conductive things otherwise it will couple and that’ll reduce performance. I can see you have a trace on the top and possibly a bit of a web connecting two fills on the bottom too.

If you have ground fills top and bottom, they should be regularly stapled together with vias (every 5mm isn’t a bad idea).

It’s hard to tell much with RSSI (you can quite easily lose 6dB my moving a board a couple of inches or changing orientation), but as it doesn’t look terrible, it’s possible you could be having power supply issues too as you generally won’t see those in an RSSI figure (as it’s RX only). Power issues would mean the EVM of transmitted signals would be impaired, meaning the base station would find it hard to understand what your device was saying. Coupled noise, droop or bad transient response, etc. WiFI PAs take a lot of current very quickly, so good power supply is essential, which is why a 4 layer board with a solid ground & power plane is ideal. You can manage decent performance on 2 layers but you need to take a lot of care - what’s your power routing like, and where are your bypass caps?


Yes, a power trace runs above the P1. 3.3V Power routing is on top layer with 15.7 mil trace width, 3.3V net running from 3.3V regulator output to C21 and C24 then to remainder of P1 VCC pins. Bottom layer is ground plane. Bypass caps are C21, C24, C23, C17, C18, C27, C19, and C20 (C19 and C20 silkscreen cutoff–couldn’t zoom sufficiently).

Re-post of question to Particle team:

If multiple WiFi credentials are stored in the P1, how does the P1 go about acquiring a specific SSID? Does the P1 assign any certain priority to each SSID based on when the SSID was stored in memory?

The most recently added credential is tried first, then older ones.

Thanks, mdma. How long will the P1 try each credential before trying the next stored credential?

I don’t see many ground vias on the bypass caps: you should really drop one from each cap (see my other post about EMC testing an loop area).

On your USB you could do with switching the D+/D- under the module where it’s easy so you can have a direct path to the connector :smile:

I’d thicken up the power traces significantly, especially for the long runs. WiFi PAs go from near zero current to ~250mA in a microsecond or so, which the caps can’t supply so you’ll see some droop which will affect EVM (TX quality). How big is your bulk bypass on the 3.3v rail? What regulator are you using?

There is no duration for trying - it just attempts to connect. Each connect can take up to 7 seconds, but if the wifi network isn’t available or the password is wrong, the time can be much less.

Thank you, MDMA. We have noticed entering the WiFi credentials next-planned-for-use (i.e. keeping the next WiFi credentials planned for use at the top of the credential list) decreases the connection time on the P1 on the custom PCB.

Thank you for the recommendation on adding ground vias to each bypass capacitor.

USB nets: do you mean a direct path on the bottom side of the board? The pads of R25 and R24 provide access to the D+/D- signals.

3.3V regulator: trace widths are 0.4 mm (15.75 mil), and we are using the AOZ1280CI 1.2 A buck regulator. The 3.3V regulator circuit has a 10 uF capacitor at the output, otherwise no other capacitors on the 3.3V rail.

On the USB nets I just noticed the crossing of the traces between the connector and R24/25 was a little ugly - but an easy fix (and unlikely to cause issues with USB1.1 anyway, to be honest).

The AOZ datasheet could be fine on transients, though it’s really hard to tell much from the graphs as they have the scale labeled (eg 1A/div) but no visible divisions… sigh. I can’t see the AOZ layout (it appears to be just out of shot on the right) but note that it doesn’t take much to upset a DCDC into having bad load transient response due to a bad layout. If AOZ have eval board gerbers, download them and check how close you are.

Looking at the P1 datasheet, pins 2 & 3 are “VBAT_WL” which is the 43362 wifi PA supply, so note that they are furthest from your PSU. Also, there are traces cutting the groundplane up in the return path (imagine the path the electrons need to take back to the power supply, and try and make this as short/wide as possible).

I’d personally try and re-route the traces from pins 49 & 50 more on the top layer, and generally pull as many vias breaking out pins 48-64 down (between the 9 center ground pads, there’s plenty of room), to give a good horizontal ground path between the grounds on 1 & 4 and the power supply to the right.

You can always prototype a better power connection by running a thick, short wire from the 10uF cap on the PSU direct to the module power pins on the left. Solder braid wrapped in kapton can work well for this, but obviously keep anything away from the antenna.