Shipping a product - What info to capture before shipping

I’ll be shipping out my first “product” later this week and I do not anticipate getting the product back in my hands. I wonder what specific info I make sure to capture and document from the hardware perspective that I won’t be able to once it ships and in a customers hand. The product is for a very niche market so definitely less than 50 total products this year. Just trying to avoid a scenario where an issue comes out about hardware say in 6 months from now and I won’t know what devices in the fleet are affected because I didn’t capture x, y or z before I shipped it. For example, after reading this, I now will capture the FW number of the Sara-R410M module: TAN001 - SARA-R410M "124-day" – Particle Support. What other things are like this that I should try and capture now before shipping that could save me some headache in the future? Currently on the list are:
Device ID:
OS version:
Firmware Version:
Product ID:
ICCID:
Serial Number:
Sara-R410M FW Version:
PCB Version (Versioning number I use on the Custom PCB for the application):
Sensor 1 make/model: (The PCB can accept different sensors so i track what I ship with each one)
(other application/hardware specific things unique for my product).

Any guidance from others who may have shipped products before is appreciated!

Everything you have listed except Sara-R410M FW Version is visible in the console, unless of course you won’t have access to this?

Any resources (media files on SD?) version of those, hardware (your pcb) revision.
I usually stick in a load of Variables initially to be able to interrogate what may or may not be going so raw sensor values, etc. If you have a application watchdog can you recover the trace (line) where the program was when it hung?

thanks for the guidance @armor.

Yeah I know most of the info is in the console but thinking I’d add it to my SQL table as well just to quickly look across all devices or if I needed to access any piece of info from any application I can easily do it if it exists in a SQL table. Probably a way to do it via a Particle API as well I suppose instead of trying to manage some of this in my own offline table.

The main item that came to mind that even made me think of asking the question was the Sara-R410M FW version. As I had one device in the past lock up likely due to the 124 day issue. So I’m a bit sensitive to it. The device itself publishes mostly raw sensor values and then I scale it in the cloud vs locally on device.

I am using this as an external RTC for Watchdog and deep power down upon lack of connectivity: app-notes/AN023-Watchdog-Timers at master · particle-iot/app-notes · GitHub

and with every reset event I do capture the reset reason and if the watchdog did the reset. The device publishes this info the next time it connects and I save it to a SQL table. This should give me a log of all reset events across any device and the reason for the reset but doesn’t provide any sort of trace.

  • How would I do this? This seems like it would be good information to capture as part of capturing every reset event. Right now I just capture the reason for different reset conditions but I don’t capture the trace. Is there an example of how to do this? Is this just having a retained memory integer value and then keep updating the value of the integer throughout the firmware? Then capture it at the start of setup()? Or how would I do this?
1 Like

Yes - that’s what I do

2 Likes