Is it easy to get FCC certification for a device using the Spark Core?


#43

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:

  1. 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.
  2. 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.


#44

Thanks guys, I’m starting to wrap my head around this!

EDIT (after a lot of googling on everything from TTL vs RS232, OCD, jtag etc):

- Should this TTL serial cable work fine?
http://core-electronics.com.au/test-equipment/data-converters/usb-to-ttl-serial-uart-rs232-adaptor-pl2303hx.html

Could someone advise how you flash a binary via OCD on the programmer shield to a specific location?
IE JTAG programming wise, the github doc (https://github.com/spark/shields/tree/master/photon-shields/programmer-shield#common-commands) doesn’t allude to how you flash files to a specific location, ie 0x0800 4000 for the DCT from the download instructions. Looking through the OCD docu (http://openocd.org/doc-release/html/Flash-Commands.html#Flash-Configuration-Commands) it looks like it may be along the lines of
flash write_image [erase] [unlock] filename [offset] [type]
… though seems an easy way to brick it!

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.


#45

@mohit has the most experience with the Programmer Shield, and can probably chime in.


#46

This is a pretty comprehensive guide, though:


#47

In addition to the documentation that @will mentioned earlier, here is sample set of commands to load a complete binary image onto a Photon (credit @bryce )

openocd -f interface/ftdi/particle-ftdi.cfg -f target/stm32f2x.cfg \
  -c "init" \
  -c "reset init" \
  -c "flash protect 0 0 last off" \
  -c "flash erase_sector 0 0 last" \
  -c "flash write_image /firmware/rc4/combined_BM-09.bin 0x08000000" \
  -c "flash fillh 0x08005D88 0xAAAA 1" \
  -c "flash fillh 0x08009D88 0xAAAA 1" \
  -c "reset run" \
  -c "shutdown"

#48

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?