[Feedback] Collection of HW Design Reviews from our "inner circle"

Summary:

This issue is the collection of all the feedback from our inner circle reviewers.

1. Fabien Ferrero

The layout looks quite optimal. For the RF paths, you have a similar approach with the Nucleo board (I guess that there are not so many options). Good point to have a UFL connector, always useful for debug. Usually, I would recommend adding more vias on the ground plane. Especially on the board edge. The antenna is going to generate strong current on the ground plane, it is important to avoid any zig-zag to radiate max power. I'm surprised that you have not included a shielding (or at least the possibility to add one). You don"t need to pass FCC certification ? The chip is similar to SX1262, so you will certainly need one for certification. Concerning the antenna from Ethertronics, I've recently reviewed one design using this antenna. This solution is really nice and can give good performance. It is based on inductive coupling, so you are exciting the current on the PCB board. Normally it should be placed at the center of the longest edge of the terminal. From what I see, it is not really possible here. You should use a capacitive coupling antenna. If you need some support from Ethertronics, I get a direct contact with the antenna support team, they are really smart. I guess that a solution from Fractus would also work well. The antenna choice and optimization might be challenging if you want to support both 868 and 915MHz band. Especially, if you want to radiate the maximum power (22dBm) at 915MHz, you will need a very good antenna matching (<-10dB).

2. Kris Winer (Tlera Corp)

We have some questions and comments on several aspects of the Generic Node v.01 design.

But first, our open-source philosophy: 1) simple, easy-to-reproduce and easy-to-customize hardware design, 2) robust, complete, power- and memory-efficient HAL with an easy-to-use C++ Arduino-based wrapper. We want users to focus on their application goals, not struggle to produce hardware and write thousands of lines of code.

1) Who is the intended user and what is the typical use scenario?

You said: “we are aiming to meet enterprise and hobbyist/maker users. Therefore the design will have a functionality as a dev-board and as an enterprise ready, plug-and-play device. We're using gcc tools with OpenOCD (baremetal), and once ST releases their official support for their STM32CubeIDE support, we will support that too. “

In our view, the Generic Node v.01 meets the needs of neither of these two groups. The hobbyist/makers will find the 2 x 7 connector a barrier to use and the STCubeIDE impossible to navigate compared to using the Arduino IDE over USB. Enterprise users will be able to manage the program connector using an appropriate tool chain but expansion capabilities are minimal on the board. We do not think exposing I2C and UART via the 2 x 7 connector is adequate for either group to customize the device for their particular applications. The Grove I2C connector lacks provision for one or more interrupts limiting its utility. The board is designed more like an ST Discovery board than a Nucleo board but without the connectors exposing GPIOs/peripherals to the user.

Furthermore, reliance on the ST HAL is a mistake in our view. The ST HAL suffers from gaps, race conditions, memory leaks, and lack of workarounds for errata which will frustrate most users. In other words, good software design is as important as the hardware design if the product is to be useful. And good software design, in this case, will require significant effort to get right. Without it, the Generic Node v.01 would be just another variant of some ST Discovery board.

2) The board seems to be designed around the two AA battery holders. Did you consider perhaps using two AAA batteries for a smaller form factor? Is there a provision for using a different battery technology like LiSOCl2? Perhaps a simpler generic battery connector would provide more flexibility for the user to choose the appropriate battery technology while allowing a smaller form factor and/or room for exposing more expansion ports?

3) There are 2 MBytes of SPI flash on the board. Is this intended for data logging? Why not select a 8 MByte capacity SPI flash like the MX25R64 then? This has the advantage of a deep power down current < 100 nA. Why not expose the SPI port to the user so other SPI devices might be added? If not for data logging, then what is its purpose?

5) Load switches control power to the sensors, flash, and secure element, but these are very low power devices already. This seems like an extra expense ($s and GPIOs) and degree of complexity for no real power savings. The LIS2DH12 accelerometer has a 2 uA sleep current. We would recommend you consider the BMA400 which uses 800 nA running at 25 Hz allowing efficient wake-on-motion and sleep-on-no-motion functionality. We use this on our Cicada, a very similar device functionally to the Generic Node v.01.

6) The RF sector is complex and will make it difficult for anyone to make use of the design as the basis for a custom solution. Is there no way to simplify this while preserving most of the capability?

7) There is no provision for USB via an FTDI or STM32F042 USB-to-UART transceiver which could make this board more generally accessible and/or usable as a development board, and more particularly, accessible to Arduino IDE users.

3. Thomas from Lacuna:

1) Do you need all these load switches? We use many of the same chips, and are able to get the entire board under 10uA in sleep, without switching them off. Flash should have its own low-power sleep as well.

Since it's going to be a generic device, not all the sensors have good deep-sleep current, I figured adding ULP load switches will greatly reduce deep-sleep current. Right now, with the MCU in Standby mode, we can achieve ~2uA consumption.

2) Nice buck-boost converter!

Thanks, I did a load test on this and it works well. Consumes only ~350nA Iq in active mode.

3) The MX25R1635 supports Quad-SPI, but you’re not using it. The STM32 supports direct mapping of the flash to memory, but I’m not sure if that’s only on QSPI or on normal SPI as well.

We will definitely investigate more on this, but our current library was written for normal SPI mode, therefore we went with it.

4) Do i understand correctly that you use the TCXO also to clock the STM32? By PB0_VDD_TCXO.

By default the MCU starts with an internal HSI clock, but we can definitely switch the clock input to TCXO for both system clock and for the RF part. Please see the attached clock-tree view.

5) Do you need U10? On the LR1110 we just tie ports 1, 3 and 4 together.

This was done so we can digitally switch between LP (+14dB) and HP (+22dB) modes for the EU and US regions.

6) Are L9 and L10 really the same values (just checking).

Good catch. They're not the same, but very close. L10 should've been 3nH instead of 3.3nH.

One more: the STM32 has native USB, why not add a connector for that?

STM32WL does not have a native USB support.

4. Hamilton from ST: ST_Hamilton_Schematic_PCB_review.pdf

5. Seeedstudio (DFM analysis): Seeed DFM report.xlsx

6. Other remarks:

Eager to see more expansion ports (standard pin headers, QWIC port, USB)
Easy reflashing option over USB
Arduino support
Module approach

7. Patric Fenner - DefProc

I'd question if there is a need for an ESD diode (or at least a footprint) on the battery input (at F1) as I would expect extended contact with human skin at the battery terminals. I know the buck-boost converter has over voltage protection, but I'd want to be very sure I didn't have to include ESD protection for the power input to leave it out. I know it's also common to have a footprint that's jumpered with a 0R resistor to allow it to be replaced by a ferrite on the power input line too, so there's space to tune the design for any unwanted emissions you might find once you get the device in the EMC chamber.

Battery fuel gauge monitoring is a nice extra and a very useful feature, although supply looks like it might be limited for the part. Is it new to market?

It's a shame the green diode isn't available on the D2, I'm assuming that this is from a lack of available microcontroller pins?

Power switches for each peripheral set are very nice, I can see some users won't want to use some parts at all, but even if the sensors are used, they don't have to be powered continuously.

I'd be very happy with the accelerometer and temp/humidity sensor you've chosen. Would you consider having NC SMD jumpers to the supplies for these devices, so they can be completely removed from the circuit if they're not required for the application? I know their current draw is in uA, but it's still double the draw if you'll only use one sensor, plus the gate current of each of the SDA and SCL lines.

Should the pull-up resistors for I2C1 and I2C2 be the same as each other? I note that I2C1 has 2 devices, and I2C2 has only one. It might not be an issue with the bus speeds you're expecting.

I'm aware that there are SCL and SDA available on the DEBUG port, but it would be nice to see VCC_SENSORS, GND, SCL and SDA available together for external I2C devices. One option from SMD pads, through-hole header pads, STEMMA or QWIIC connections would be fine. I think I'd choose QWIIC at the moment.

I would expect to populate C20 with a 100nF capacitor, unless you know that the SW1 is very low noise. I do have a preference for hardware debounce over software debounce though.

If there was a pad at SW1 (on the USR_BTN net) and a corresponding GND point for soldering to, then it would allow PB3 to be used as a GPIO pin if the switch is not needed for the application (assuming there are no free microcontroller pins).

TheThingsIndustries / generic-node-se

[Feedback] Collection of HW Design Reviews from our "inner circle" #50