The USI stuff is the Broadcom wl test setup; you can’t trigger these things via a cloud function. The device is not “on a network” at the time of testing, and cannot be for a couple of reasons:

It’s in an RF chamber, alone. There’s no AP, not can there be - the tests are looking for emissions from the device alone.

When it’s transmitting (which is most of the testing), it’s doing do at maximum duty cycle. It can’t receive anything.

Unless particle re-link the tool and wltest image (it’s not the standard wifi firmware image) into their own format, you have to load it via JTAG. You also must have the correct UART available in your final design to be able to talk to the WL.EXE dos mode tool which effectively wraps ioctls and sends them over serial.

For my development purposes, the Particle programming shield seems to be a good idea as I can use it for flashing code, replacing the ST-LINKv2 and the old style JTAG shield in the manufacturing docs. However its quite unclear whether it has the appropriate functionality thats a tried and tested path, versus buying the old shield and st-link and following the bouncing ball.

Hey, Zach. The water is still a little muddy for me. I’m working with a testing lab who says that the FCC 2AEMI-PHOTON is no good if I’m embedding the P0 in my product, but your certifications page led me the other directions, and is slightly unclear in it’s language. Can you help set the record straight - do projects incorporating the P0 need intentional radiator testing to comply with FCC? If not, what document substantiates that I can put the P0, with antenna gain and type matching that of the Photon, into my product and just require unintentional radiator testing to be in compliance with FCC?