Hey Chip, did your BSOM carrier board make it to production and testing?
This project fell victim to my move to Singapore. I do plan to restart my efforts here likely over the holiday. I just need to look at the new Particle hardware roadmap and make sure I am still on the right path.
Chip
1 Like
Hi Chip,
I have interest of a European version of such a device which is able to log ICM-42688 IMU acceleration values over SPI at high speed (4KHz) on wakeup.
Regards,
Ivan
iarakis,
The BSOM524 is capable of communicating at up to 32MHz so is can likely keep up with that data rate as long as you account for both sampling and storing the data (I assume on a Flash device also on the SPI bus).
I need to make sure I have the bandwidth myself for this project. Thank you for your interest. I will give it a think.
Chip
Hey Chip, et all,
I wonder if the functionality the Muon offers today (ok, very soon) is able to fulfill the need of this (future & potential) carrier for BSOM/B5SOM.
With its Qwiic connector, onboard watchdog and RTC, and the 40 pin connector Raspberry Pi compatible, what is the case for the carrier?
Yes, the Muon a dev board, but this is a Particle dev board - they build dev boards ready to go to scale with them. Just take a look at the Boron 
I'm asking out of curiosity here, by all means please proceed with the carrier if that is what is needed.
Thanks!
You are asking the right question. From what I can tell this is a great little board. It includes much of what my current carrier boards have:
- Watchdog
- RTC - I noticed there is a RTC battery connector need to test this.
- Qwiic connector
- Temperature sensor to manage LiPO charging (too hot / cold to charge)
But it is missing a few things:
- An On / Off switch that would enable long term storage
- Connector for sensors with interrupts to support low-power operations
- Low power consumption in sleep / standby (<0.5mA)
- An easy was to disable the wired Ethernet to reduce power
- ESD protection for off-board sensors
Muon datasheet | Reference | Particle - Fuse for short protection on power to external devices
- Persistent memory on carrier to maintain configuration with module change.
I am actually not sure how important all of these are. Would be interesting to see what folks think. It may be that many of these items are addressed and I have not had enough time to look at the data sheet. Finally, some of these are much less important if the whole system is sealed versus if there will be external sensors which may be exposed to static discharge or water.
BTW, I fired up my M524 with the Muon Development Board here in Singapore - AND IT WORKED! Very happy as Singapore is not listed as a supported country. Let's see how long this happy situation lasts.
What do you think - Perhaps all that is needed is a custom "Hat" for the essential items not on the Dev board? It would be much easier to build than a full carrier board.
That was very cool!
Now I tell you what I know, which may or may not work:
- on/off switch: the PMIC can be set in shipping mode.
- low power consumption, this below is for the msom, we still miss the data for the Muon as a whole bord:
About this, I want to add that there is a 3V3_AUX that powers the ethernet/LoRa/QWIIC/40 pin connector which can be disabled when going to sleep (or only turned on when needed - example: take a reading of a sensor).
- the Ethernet chip can be set to low power, still consumes 13mA from the datasheet (but killing 3v3_aux might be the way to go)
- ESD protec: no clue
- Fuse: no clue
- persistent memory: the MSoM has an 8 MB flash file system
Like you mentioned, perhaps one alternative is to create a Hat for what is needed, or look into using an already developed hat.
Best,
1 Like
To add to @gusgonnet comments, the only catch is that any sensor with interrupts sitting on a Hat would be disabled if it powered by 3V3_AUX and it is turned off. You would need to power the Hat or sensor independently.
Beyond the USB-C ESD protection, I could not see any dedicated ESD protection on the QWIK connector or the 40-pin expansion connector. Protection would need to be added on a Hat board as required.
As for the fuse, I tend to want isolate a board's power from off-board peripheral power. The problem with SMD fuses is that once they blow, which they don't do very fast, they never recover the same initial "closed" resistance. I have used a switching supply with it's own set of protections to isolate peripheral power. Many of these regulators will also have a FAULT output that could be monitord by the Muon. If you want to get really fancy, you could also monitor the peripheral current and disable the regulator!
3 Likes
@peekay123 and @gusgonnet ,
I like the idea of a separate power supply for off-board connections - this is something I have put into my previous carrier boards as well. The "Fault" pin monitoring is not something that had occurred to me - clever!
So, a "hat" could deliver all these capabilities:
- 4 (x2) and 6 pin (x4) i2c JST-ST connectors. The 6-pin i2c connectors support hardware interrupts
- a 6-pin SPI connector
- GPIO Connectors 6-pin 2x Analog and 2x Digital
- ESD protection on all IO lines
- A power on-off switch if possible - I don't think this is possible - no connector
- A 3.3V power supply with short / over current and "fault" modes
I was hoping there would be a solder jumper for the Ethernet port but it does not look like there is one from the schematic (only a jumper for ethernet reset).
Also, it is not clear why there is a battery connector for the RTC. I looks like the RTC has its own power supply that is connected to the LiPO battery. This should be sufficient.
Having memory on the carrier board is a "nice to have" which makes it possible to preserve the configuration of the device across M2 module changes. This is an edge case however.
So, it looks like an IO centric hat could be a thing
2 Likes
I'm not sure either.
@rickkas7 Do you mind commenting on the intention of this extra battery connector to the AB1805 on the Muons, please?
It's connected to the VBAT pin on the AB1805. You can use it to power its RTC with a lithium coin cell or supercap. This isn't necessary when powering the Muon with a LiPo, but if you want to preserve the RTC when only powered by VIN, USB, or PoE, you can use that feature.
2 Likes