Update:
Board back from OSHPark and assembled. Will start testing tomorrow. Fingers crossed!
So far, so good. Couple nits: not crazy about my choice of on/off switch but did not see a better surface mount option. May go back to the three hold EGL1215. Also, the crystal for the Real Time Clock seems huge to me.
Chip
I have just laid out a similar Carrier PCB using a lot of the same IC functional blocks - I looked for alternates to that crystal but that was about the same one I could find.
This looks it really came out well! - Great Job!
Yes, ugly hand soldered but was faster and way cheaper than getting MacroFab to do it. I want to do a higher volume run this next time so need to test it completely.
Chip
From a cost viewpoint if this was going to scale you would want to have 1 side SMT if possible and as many SMT components as feasible. For Rev 1 - Credit for the hand soldering of those tiny components!
@all,
Update on testing.
Thoughts and comments welcome.
Thanks, Chip
I am leaning towards the TLP being the wrong device - if you had a simple timer you could just reset on an I/O (like an ATTiny 85) you could trigger a “pat the dog” the AT starts its 68 minute timer. The RTC MFP is connected to D8 and its wakes system in cycles less that 68mins. when boron wakes - 1st thing is “pat the dog” and 68 mins starts again. The AT will pull down !RESET for 10s on time out ?
This fixes point 4 as well
JST is cool but cables are hard to make up manually without the right (expensive) crimper etc - if you can find a harness maker that will do them at a good price then go for it.
I take your point on the watchdog and will look into alternatives. I can tell you from my original explorations on Digikey that there may not me many alternatives with an 1 hour + cycle time. I do like the ATTiny 85 idea and use this chip in my pressure sensor. However, it does draw much more power and brings the added requirement for a programming footprint on the board (I use Tag connect but then folks need to buy a ~$60 cable). Point is that this is a typical engineering problem with multiple tradeoffs.
I hate crimping cables and as the number of devices I sell increase, I want to get out of the crimping business. I noticed that Digikey carries a number of pre-made cables and I was hoping to move to a model where I just use those. Does that make sense? Problem is picking the right pin counts and the correct JST series as they don’t have PH series today.
Will keep you up to date.
Thanks, Chip
You could put a small SMD 6 pin header (2x3) and use an IDC connector and cable to an arduino nano or similar and program it easily that way (pretty cheap solution) - unless there is a bug the code as a WD timer is hardly going to change. Idle mode (which leaves the timers running) goes to approx 0.35mA. So not a bad option.
In terms of connectors its all a trade off - if you can get pre-made cables - that is 1st prize - for my last project I found a local harness guy who made up about 200 sets for me that had 2,54mm latching plugs - this worked really well and was not that expensive but gave a solid connection once plugged in
So, have been doing homework on the connectors. I think I am going to go with JST - SH/SR. These are the Quiic connectors that are gaining steam for i2c, they are smaller, cheap and there are many options for pre-made connectors in 2, 4 and 6 pin sizings and different lengths. Sparkfun also creates adapters for traditional dupont (2.54") and Grove cables.
Datasheet for the SH/SR connectors: http://www.jst-mfg.com/product/pdf/eng/eSH.pdf
Now, I need to find a better switch and resolve the watchdog question.
Thanks as always for your input.
Chip
I am looking for a new power switch too - slide switch, not tactile like I had before. I ordered some to try from Digi-Key that should be here soon. They’re SPDT through-hole switches, with a 4mm actuator length so it should protrude slightly from my enclosure which is 2mm thick. I’ll adjust the position on the PCB to get just the right length. I was looking for SMD but couldn’t find any at a reasonable price that met the requirements.
https://www.digikey.com/product-detail/en/c-k/OS102011MA1QN1/CKN9559-ND/1981430
Agreed - these will work well for an internally connected board like this and they do have nice positive lock - also opens you up to using any of the SparkFun breadboards that use the Quiic system and so offers many additional sensors - win all the way!
Have you got an inside on the 1Mb Flash unlock? Depends upon what you want to use the memory for. I have added a 1Mbit FRAM using I2C to a gateway board. This provides a nice amount of space (128KB) for a publish Async buffer. You can’t do that with Flash.
No inside scoop on when this will happen but it has been mentioned in various posts but, the reason I am bringing it up here is because I want to do a smaller number of bigger production runs with the 3rd Gen carrier than I did with the Electron carrier. Looking back, I realized I spent a lot more on the carrier boards for the Electron because I ordered 50 or so at a time. So, I am trying to read the tea leaves on the Flash and think about whether I need FRAM.
Actually, I think I am coming to the conclusion that I do. If Flash has a 100,000 read/write cycles lifetime and I am storing the current counts so the device will not loose count if reset, Flash will not last long enough. If I am storing hourly counts, it would be fine but some of my devices count 2-3 events a day.
So, I think I will keep the FRAM and use the Flash - whenever it comes - to store hourly or daily snapshots.
Thanks, Chip
Crazy that something like a switch would be so hard.
I am thinking of using this switch but, I wish there was something like this in a surface mount format. You would think that with almost 4,000 slide switches on Digikey, there would be plenty of choice.
The 100K is for write cycles only as read cycles don’t change the structure of the storage cell. With flash, the key is to spread the writes over the entire device using a basic or advanced wear-leveling library such as SPIFFS. Using wear-leveling, the flash lifetime can be extended by orders of magnitude. The file system proposed to be used for accessing the 2MB of free flash on the Gen3 devices uses wear-leveling. By dedicating 1MB of the 2MB available, a wear-leveled 1MB of flash can be presented to the user with a write cycle lifetime that will most likely be as long the products lifetime.
Wow, did not know that wear leveling was built in. Can I assume that in addition to the wear leveling writes will use “update” so they only write if there is a change?
I don’t see any issue with saving hourly or daily data as even without wear leveling, these would last for years.
My question is in trying to judge the life of the device when I store the current state.
If I have a device that stores its “state” including the current counts and would be an object like this:
For a busy park this object would be updated about 2,000 times a day. Without understanding the effectiveness of the wear leveling program is, how can I estimate the useful life?
That said, I have interacted enough with you on the forum to trust what you say. If there is no easy answer other than “trust the algorithm” I can be OK with that since Flash storage is quite mature and the wear leveling issue must be much more of an impact on devices such as PCs and Servers.
Thanks, Chip
@chipmc, the current EEPROM emulation uses a wear-leveling algorithm thus using more flash than what is presented to the user. The current library used by the DeviceOS for its flash operations is LittleFS which provides power-failure resistance and wear-leveling. I’m not sure if LittleFS will be replaced in future versions but you get the idea.
That said, I am not aware of any “update” capability since writes are done at the page level (typically 256 bytes) and not the byte level per say. Regardless, with wear leveling, you would not have to worry about the lifetime of the flash in your design IMO. However, @rickkas7 and @ScruffR may want to chime in 
I would keep the FRAM ind the design, it can always be changed to (do not mount) status, when the unlocked flash has proved itself to be in existence and reliable.
Could be some users may want to save large amounts of varying data often, in a way that minimise the effect of wear leveling (camera output?).
(Super nice boards!)
Yes, as peekay123 pointed out, you probably should not attempt to use SPI flash in direct sector access mode. Not only does it cause wear, but you are very limited in what you can write. You basically have to erase and write a whole 512 byte sector every time which is a pain and inefficient.
Using SPIFFS or LittleFS on the SPI flash essentially eliminates the wear issue as the data keeps moving around the flash, at least as long as you leave some empty space.
