PCB Version 2 Design / Requirements

We will shortly need to build quite a few more devices - some WiFi and some LoRa so we need a new PCB to support these. Brian has started collecting ideas and suggested requirements Please take a look and post your thoughts here by 30th June then we will try to finalise the specs.

The new PCB is likely to be based on ESP32 which has more GPIO available than ESP8266 based modules (AFAIK). ESPEasy32 (https://www.letscontrolit.com/wiki/index.php/ESPEasy32) exists as a trial but is unfinished. ESP Easy does not support Lora(Wan). It is highly likely we will have to develop our own code and base it on work done by Rob Miles.

Here’s the current requirements list copied over from mattermost.

Item Initial Functionality Wish List Essential
1 Support for GPS (serial)
2 Support for Serial sensors e.g. SDS011 and PMS7003 Y
3 Support for I2C sensors (e.g. BME280) Y
4 Support for 1 Wire devices
5 Support for SPI - RFM95W Y
6 Support for SD card for logging data if no WiFi/Lora
7 WiFi
8 Blue Tooth (comes with some WiFi module) - useful for configuration?
9 Lots of memory for code and to allow OTA updates Y
10 Capable of battery operation with 18650
11 PCB to form a carrier with mounting points for SDS011?
12 RTC – to keep time when offline – included with ESP8266/ESP32 Y
13 Deep sleep capable
14 Switched 5V – using GPIO
15 Switched 3V3 – using GPIO
16 Additional fan to circulate Air (would use #14) to turn it on/off
17 Solar panel support

It would be nice to see what this ESP32-S2 turn out like, since it hits the mark for what we need.
Lower and better power saving, we don’t need the second core (we’re not using Comms at the same time as datalogging and we’re not logging quickly anyway).
It should also be cheaper and we gain usb directly, so no interface chips. Again even cheaper still.
It shouldn’t be long before it’s available on AliExpress, but it’ll still be a few months.

Sounds great!

Yeah, I think I remember something to that effect. I’ve just spend 1/2 the afternoon battling with the ESP single-channel gateway and trying to get the pins right, so an upgrade like that sounds like it would really help.

Quite possibly! You’d have to write an application to talk to it though if you used bluetooth over a custom protocol, unless you fiddled with a bluetooth PAN (personal area network; basically TCP/IP over bluetooth).

Regarding security, a few considerations:

  • We probably want some way of avoiding any random Joe walking down the street from reconfiguring it on-the-fly.
  • A local hotspot could work for the initial configuration, but having the hotspot up permanently isn’t a good idea as it crowds the airwaves
  • Maybe a button on the device that you press to put it into configuration mode would work?

More advanced ideas could include receiving MQTT / downlink messages to instruct it in what to do.

WeMOS pins. I think these are what you need. The SPI pins are standard. For the DIO pins you can use GPIO0 and GPIO2 the RFM95, I believe, sets the DIOs off, high impedance until it has been setup and is receiving/transmitting so it should not affect the boot up of the WeMOS. I could be wrong since I haven’t managed to compile the code either as an Arduino project or a VSCode project. I’ve been trying to convert all to cpp so that header files are not invisible. It’s hard work.

// ----------------------------------------------------------------------------
// For WeMOS D1 Mini.
// SCK  == GPIO14/ PIN D5
// SS   == GPIO15/ PIN D8 CS
// MISO == GPIO12/ PIN D6
// MOSI == GPIO13/ PIN D7
struct pins {
	uint8_t dio0=5;		// GPIO5 pin D1 / Dio0 used for one frequency and one SF
	uint8_t dio1=4;		// GPIO4 pin D2 / Used for CAD, may or not be shared with DIO0
	uint8_t dio2=0;		// GPIO0 pin D3 / Used for frequency hopping, don't care
	uint8_t ss=15;		// GPIO15 pin D8 Select pin connected to GPIO18
	uint8_t rst=14;		// GPIO14 / D5 Reset pin not used	
} pins;
#define SCK 5				// Check
#define MISO 6				// Check
#define MOSI 7				// Check
#define RST 14				// Check
#define SS 8

Not really, it’s an extra thing to keep secure (it’s also removed from the ESP32-S2).
It eats power, it uses more CPU up too. (neither are a problem for our current logging setup though)

  • you would need a way to trigger it on/off and sync.
    We have WiFi as we need it for WiFi based devices, use that for configure, some method to trigger it into AP mode and also to keep it turned off/on, for Lora based devices.
  • Configure can also be done over MQTT once it is setup and running?

So I don’t think BT is a must or need.
Possibly for some projects it is, but not monitAir.

Fair comments.

I guess, by the time we move to an all singing dancing PCB the ESP32-S2 will be available.
Meanwhile @Robin, Rob Miles and I met this week to discuss this and an interim solution using a Heltec to provide Lora capability. We want to move away from using modules, if possible, because the pinouts can change (Ref RM).

Do you mean modules or development boards. The ESP32/8266 comes in various ‘modules’ the small mainboard. The SOC would be much harder to use than the modules and the pins would change anyway with different generations
With the dev boards, it just contains a larger pinout setup for DIL’s or Dupont connectors in reality. Again pinout changes with the SOC/Module used ?
Pinouts are always going to change as they bring out new stuff, I think all the ESP have differences ? One of the problems of using such things.

Dev boards. Well corrected.

Aren’t the current Dev boards (WeMo/nodeMCU) just to add the usb serial interface and 5V

The ESP32-S2 should loose that usb part as it has USB-OTG integrated (much like like the PiZero can be used directly over USB as an OTG device)

Yes. But i havent found a datasheet for the esp32-s2 yet so its hard to design a system using it.

We just need to sit and wait :frowning:

Meanwhile Robin has designed a pcb for the Heltec V2 we are waiting for delivery. We had too many D1 minis that would not wakeup from deep sleep.