Best practice for commissioning Electron Product Prototypes?

The Archive Product Creation
1

I’m working with a small volunteer team [1 hw guy (me), plus a couple software guys and several less techie volunteers] and we building about a dozen prototype flood sensors using Electrons for a field deployment test. We aren’t able to push an initial firmware load OTA from the from the devices tab on https://console.particle.io/svpa-floodsensor-2016-001/devices because we are getting a “This device is not reporting the correct product ID,” error. We are struggling on how best to flash an initial firmware so that we can select and push test builds OTA.

To that end What is the recommended flow from hardware assembly through to in factory testing to customer delivery through customer provisioning to use in the field?

BTW our firmware is available at https://github.com/tsayles/SVPA-FloodSensor-2016

2

Hi,

as written in the docs (and referred next to the upload-button):
Specifically, you must add PRODUCT_ID([your product ID]) and PRODUCT VERSION([version]) into the application code of your firmware.
https://docs.particle.io/guide/tools-and-features/console/#preparing-a-binary

regards

3

If you look in his code, he has :wink:

1 Like
4

missed that,… does it matter that it is included SVPA-FloodSensor-2016.ino but not in weather-ranger.ino?

5

On the initial compile of v1, I was able to flash to one device directly from my Atom plug-in. This device updates very nicely OTA through the https://console.particle.io/svpa-floodsensor-2016-001/devices dashboard. However when we built up a few more devices, we were unable to push the initial load of firmware OTA.

Really what I am looking for is “What is the [prototype scale] manufacturing flow envisioned by the Particle.io development team?” as I want to adapt our way of working to that flow rather than bend it to what we think it might be.

1 Like
6

That depends what binary should be uploaded, but since weather-ranger.ino is 8 months old I'd say that's not the code that produced the binary.
A project can only have one .ino file as source.

3 Likes
7

Sorry. The weather-ranger.ino is for an earlier prototype [Photon based]. The other .ino is what I generated our .bin files from. And the bin files all run fine and update OTA fine on or first electron prototype.

8

Still looking for an explanation of how “Flash code over-the-air during initial setup” is supposed to work for Electron. Are there actions is the user supposed to take with the device out of the box?
https://docs.particle.io/guide/how-to-build-a-product/manufacturing/#programming-the-device

9

@jeiden, could you have a look please?

10

@TSayles - The process I’ve been using for my electron sensor hubs has been to pre-flash them with the firmware via the USB and then register them with my product. Here’s my full process:

  1. Flash test firmware via USB
  2. Test
  3. Flash product firmware
  4. Get the ID, IMEI, and ICCID from the electron
  5. Store the Electron info in our database
  6. Add the Electron to our product in the dashboard (Post to https://api.particle.io/v1/products/.../devices)

When the customer gets the Sensor Hub, he or she enters the Electron’s ID in our web app. Our system then claims the Electron for them.

There still isn’t a clean way to activate the SIM card. Particle says this will be available soon.

I’m sure the process could use a lot of improvment but thought I would share.

1 Like
11

@TSayles,

I would start by closely reading the docs on the product creator workflow here: https://docs.particle.io/guide/tools-and-features/console/#your-product-id if you haven’t already. The flow we’ve imagined goes something like this:

  1. You purchase a group of devices from the store or order reels/treys of modules for large manufacturing runs.

  2. Create a product, and import those devices into the product on the devices page. This tells the Particle cloud that these are approved devices that should be treated as part of your product fleet.

  3. Upload a firmware binary to your product on the firmware page. This represents the firmware that you’d like your fleet of devices to run.

  4. Flash this firmware directly to a test device (or group of test devices) by any of the various ways to flash firmware to an individual device:

  • Using “Lock and Flash” on the Console
  • Select the device in the Web IDE and flash
  • Flash using the CLI
  • Flash over USB

The idea here is to ensure that the firmware works as expected, and is ready for rolling out to the entire fleet

  1. Once you are confident in the firmware, you go ahead and “Release the firmware” on the console. This tells our cloud that devices in the product should download and run this firmware (unless they have been locked to a different fw version).

  2. When end users set up their device, they will automatically receive an update upon cloud connection to download the released firmware

These steps should all be outlined in the docs above, but let me know if you have additional questions. Hopefully this is helpful!

2 Likes