Boron / Xenon / Argon Carrier for Outdoor Applications

Great build, thank you for sharing!

Was the watchdog configured for RST or EN pin or RST pin when tested with A3, and which config do you prefer?

With the watchdog configured for the EN pin, it should be fully functional to connect a battery directly to the Boron connector except you loose the protection?

@thrmttnw,

It was connected to RST. I easily changed the pin as pictured but I am being told that this issue is fixed with release 1.2.0 of the deviceOS.

Yes, you could connect directly to the Boron with the EN pin but, the connector on the board will do exactly the same thing and gives some protection. Your call.

Glad you liked the project. Will share more as I continue testing.

Chip

All, I have been using this carrier board for a couple months and am satisfied that it is working well. Next stop is to get some made at MacroFab. I will place the order in a few days so two things:

  1. If you have any last minute comments / suggestions, now is the time to make them
  2. If you would like to piggy back on my order, send me a message. The more we order, the cheaper they are. When we get closer, I will let everyone know the price but initial run will likely be ~$45 a piece.

Github Repo here: https://github.com/chipmc/Particle-Boron-Carrier-v1.1

OshPark Render and Bare Board Order here: https://oshpark.com/shared_projects/sx45mqCY

The schematics and layout are unchanged with the only exception being the 1x6 SPI header is now a 2x3 SPI header.

Botton

Top

Thanks,

Chip

1 Like

Hey Chip, just curious here. $45 is the pcb only or with components mounted? Thanks

@gusgonnet,

Yes, sorry if I was not clear. That price was for the assembled board from MacroFab. The actual cost will depend on the volume. I will publish the price / volume curve as I am not trying to make money on this. My only motivation is to get a few folks to jump on and lower the per board price we all pay.

If you want the bare boards, you can follow the link to OSHPark and get 3 for $26.

Thanks,

Chip

3 Likes

Great board - one comment on your rx/tx header J3 - add a GND pin to make wiring easier ?

1 Like

@shanevanj,

Good idea, Will do.

Chip

Another comment / suggestion - the two headers J1 and J2 are mirrored this means if you plug a cable into J1 GND is on pin 4 but on J2 GND is on pin 1 - if someone inadvertently swaps cables you could have VCC and GND going somewhere its shouldn’t ?

@shanevanj,

Ouch, that could have been a painful mistake. VCC on 3 and GND on 4 as per the Grove Standard.

Also reminded me to put vias in the pads on the grove connectors for better mechanical strength.

Chip

On second thoughts (I know it takes price up …) what about adding another grove connector instead of the header for the rx/tx - then you have power and etc and all nicely in same standard cabling ?

1 Like

@shanevanj,

I feel like I owe you one for the last comment - OK, will put this in. Then, let’s see what MacroFab charges - can always leave unpopulated

Chip

1 Like

I think I need to put a Real Time Clock on this board to enable sleep and improve time based functionality. There are two BIG reasons for this:

  1. The 3rd Generation devices have no real time clock so the cannot do time functions (like Time.minute()) until they connect to the network.

  2. You cannot use wake on time for DEEP sleep preventing lowest energy usage.

Thoughts? Comments?

I will post a new design once I have it.

Thanks, Chip

I am using a PCF8523 for this - there are standard libraries available - advantages are low power , batt backup and I2C AND you can create an alarm that will generate awake signal on a pin - so now you can deep sleep to really max power savings :slight_smile: or you could use the alarm output as a “reverse watchdog” i.e keep setting the alarm 5 mins ahead in the loop and if it does fire it triggers simple RC circuit or 555 timer to yank the power

1 Like

@shanevanj,

Let me take a look at that one. I have already slapped the DS1339 with a supercap on the board. Take a look at this part (I have a library that works as well). I will do the same with the PCF8523

Thanks, Chip

@chipmc, don’t forget about @rickkas7’s MCP79410RK RTC library:

1 Like

@peekay123,

Right, will take a look. If @rickkas7 has done the work I am sure it is 1st rate.

I took a quick look and it looks like it will do what I need - including the synchronization from RTC on bootup.

Will need to look at the datasheet but, I don’t want to have a coin cell (another battery) and want to use a supercap instead. Need to validate this.

Thanks, Chip

Choices choices, for me the MCP79410 is out as is seems the interupt output does not function on batt backup. The PCF does provide the output on batt and also has a watchdog function but I like the super cap option in the DS. Perhaps a discrete trickle feed to super cap and the PCF may be the one ?

@shanevanj,

OK, so interrupt on battery power is a must. One possible deployment model for this device is to allow it to pull EN low turning off the Boron and the devices it is powering completely off. This is part of my goal to build a Boron device that can call in every hour (for at least 18 hours a day) and last on a single battery for one year. May take a couple steps to get there but ...

I will look at these two. Can you send a link to the Particle (?) library for the the MCP79410? I have shared my DS1339 project below and am working on getting the library ready to publish.

I want to make the best choice here so will look at this over the next day or so.

Thanks,

Chip

Try import into workbench

bash-3.2$ particle library search MCP79410RK
> Found 1 library matching MCP79410RK
MCP79410RK 0.0.3 299 Particle driver for MCP79410 RTC
bash-3.2$ 

In hindsight this is not an issue - the batt (on the RTC) is only there to preserve time where is no power to the board (so even if the INT did work on batt - there would be no power to start up the particle any way :slight_smile: !)

If this is then back in the game, I like it because it saves the brown out time to itself so you can get it back once the particle resumes power - additionally there is some EEPROM that can be used to keep board level info i.e. a PCB serial number (since the particle is socketed this gives you track n trace on your boards tied to a location perhaps) or it could be used for a PCB variants id so the particle knows what its dealing with on start?