More details about the Mesh Extender prototype PCBs

I have been asked if I can share the current design documents for the Mesh Extender prototypes, which of course I am happy to do.  I have also confirmed with RF Design who are our PCB design partners (they also make the nice RFD900 / RFD868 radios that we use), that we can share the current schematics as well.

Please remember that all of this information is provisional, and subject to change.

Any feedback and suggested improvements welcome.

The images below have all been uploaded at 300dpi, so click on the image to see in higher resolution.

Jumpers and headers

The first the silk-screen, showing the various connectors:

Note that the only LEDs on the unit at the moment are on the ethernet connectors, so take care in working out whether the unit has power or not. We may put an inline LED in the power cable to make it easier to see if it is powered up or not.  Adding LEDs to the injection-moulded housing would increase costs a lot, and make it harder to achieve the IP65/66 rating we are aiming for.

Going through the headers and jumers from left to right, 

1. Internet of Things / Mesh of Things Interfaces

O1 is opto-coupled input 1, O2 is opto-coupled input 2, and R is the relay-driver output.
I.e., there are two inputs and one output that have some sort of electrically protected interface for IoT/Mesh of Things type applications.

We have allowed some extra flexibility,  not just for during the development phase, on where they will actually connect, i.e., to the GPIOs on the radio module (R position), or to GPIOs on the Ath9k in the Domino Core module (D position).  For R, O1 and O2 the centre pin goes to the relay or optocoupler, and the jumper connects this to either (or possibly both if you had some strange need to do so) the radio module or Ath9k GPIO.  The final decision on which position we default to on shipped units will occur as we continue the development process.

2. Options for powering the device

VIN is for selecting the input power type as automotive (i.e. DC supply or lead acid battery connection) or solar panel input. 

Note to self #1: I'll have to check with RFDesign, if it possible for us to make this selection available on one of the external connectors, so that you don't have to open the unit to make this change.  We could, for example, lose one of CTS or RTS on the UART, in order to make this selection possible externally

For battery charging, you need to select the battery chemistry internally:
LiPO Sets the output charge voltage for charging a 2s LiPO4 battery (as there is no support on the charger IC for load balancing of the cells this type is not recommended)
LiFePO Sets the output charge voltage for charging a 2s LiFePO4 battery
Lead Sets the output charge voltage for the charging a 12V lead acid battery
We will likely make this default to LiFePO, or possibly Lead, but of course it can be easily changed by opening the unit and moving a jumper.


3. Connectivity and debugging

USB is the breakout header for the micro USB connector, in case people want to connect some other device to it.

JTAG is the programmer port for the Domino module.

By default, you need to have a cable on the DB25 connector, in order to tie the Radio and Ath9k serial ports together.  This is on purpose, as it allows for use of an external radio connected by a special cable, that can just re-route the UART from the Ath9k to the external radio.  This is how we intend to allow easy connection to HF radios, for example.  If for some reason you want to operate the device without a cable on the DB25, but still want to bridge the UART to the radio interface, there are some pads just above the DB25 connector that can be soldered to short-circuit the UART connection, so that it doesn't require a cable to complete the circuit.

Schematics

The main thing to note here are the pinouts of the DB25 and DB15 connectors.

These are subject to change! 

All six GPIOs of the RFD900 are exposed on the DB25 connector. These will be used by the radio firmware to check which regulatory domain it is in, and thus, what the allowed frequency and power level is.  It will also share this information (in the form of the 6-bit value) with the Ath9k, where it will be used to tell the firmware updater whether it is allowed to accept 3rd-party firmware or not.

As these values are supplied by the cable, it will be possible for research and development purposes to make your own cable that does not tell the firmware updater to block 3rd-party firmware, even if you received the unit with a cable for a regulatory domain where this is normally enforced.

Anyway, the current pinouts:

1. DB25 - Power and Radio connector

Going from left to right on the connector:

1 - GND

14 - GND

2 - RFD_IO2 (A GPIO from the RFD900/868 radio)

15 - RFD_IO6 (A GPIO from the RFD900/868 radio)

3 - RFD_IO3 (A GPIO from the RFD900/868 radio)

16 - RFD_IO1 (A GPIO from the RFD900/868 radio)

4 - RFD_IO4 (A GPIO from the RFD900/868 radio)

17 - RFD_IO5 (A GPIO from the RFD900/868 radio)

5 - Domino_TX_H (UART TX line on Ath9k module. Should ordinarily be connected to pin 18)

18 - RFD_TX (UART TX line on RFD900 module. Should ordinarily be connected to pin 5) 

6 - RFD_RX (UART RX line for the RFD900 module. Should ordinarily be connected to pin 19)

19 - Domino_RX_H (UART RX line on Ath9k module. Should ordinarily be connected to pin 6)

Note to self #2: Check if UART lines are around the right way here, or if we need to move them, to ensure that UART bridging can be achieved with just solder blobs between adjacent pins.

7 - RFD_RTS

20 - RFD_CTS

8 - Ath9k CTS

21 - Ath9k RTS

Note to self #3: Do we really need CTS/RTS lines, and are they also paired the right way around?

9 - Domino Ath9k GPIO0

22 - Domino Ath9k GPIO1

10 - Battery negative (-) pole

23 - Battery centre pole for two-cell configurations (Lithium batteries only?)

11  -Battery positive (+) pole

24 - Solar/Automotive power GND

12 - Solar/Automotive power positive (+) pole

25 - GND

13 - +5V

The UART connections to the Ath9k go through a TXB0104 level converter, making them 5V tolerant.

The +5V line (on both the DB25 and DB15 connectors) can be either used to supply a modest amount of power to some external device, or to supply power to the board.  Thus a minimal DB25 power connector would simply connect the +5V and GND, e.g., from a USB cable, and short the appropriate pairs of pins to connect the UART of the radio module to the Ath9k, and optionally short pins to GND or +5V as required to encode the appropriate radio regulatory domain.

2. DB15 Utility / IoT / Mesh of Things connector

Again, from left to right.

Note that on the prototype PCBs this connector is on the opposite side of the PCB to the DB25 connector.  This is not how it will be in the production units.  I expect that we will be able to re-route the connector without changing the pinout, but nothing is certain yet.

15 - +3.3V

7 - Opto-isolated input 1

8 - Domino GPIO14 (no protection)

14 - Domino GPIO13 (no protection)

6 - Opto-isolated input 2

10 - Domino GPIO26 (no protection)

13 - GND

5 - Domino GPIO27 (no protection)

2 - GND

12 - Relay P3 (The centre-pole of the integrated 5V relay)

4 - Domino GPIO17 (no protection)

9 - Domino GPIO15 (no protection)

11 - Relay P5 (The normally disconnected pole of the integrated 5V relay)

3 - Domino GPIO16 (no protection)

1 - +5V

It should be stressed that the GPIO lines on this connector have no electrical protection whatever, and connect directly to the Ath9k on the Core Domino module.  We have exposed them to provide the maximum flexibility possible with this device.

Regarding the relay: 

The relay itself is an IMC03, which is rated up to 240V and loads of up to ~60VA, and could thus potentially directly switch low-power loads, however, we would recommend using it only as a staging relay, to something larger externally, e.g., a low-cost automotive relay if you were planning on switching low-voltage equipment.

When the relay is activated (via the XLNA pin from the Ath9k, or the IO2 line from the RFD radio module), then pins 11 and 12 will be connected, or disconnected otherwise.  This facility can be used to drive higher-voltage relays externally, e.g., to actuate controllers of various kinds.  

I'll post more information about the Mesh Extender design itself as time allows.

In the meantime, it would be great if someone were interested in starting creating a page for the Serval Mesh Extender 1.0 to the OpenWRT hardware table, so that we can collect and maintain the appropriate information there, and look at creating a relevant target in the OpenWrt DD build system, as I'd greatly prefer if we can include the Mesh Extender in OpenWRT's supported hardware.