Next Generation MeshPotato

Needs

 * VoIP
 * either through local FXS port or audio port
 * WiFi
 * Preferabley 802.11n (?)
 * with 2x2 or up to 4x4 spatial streams?
 * Ethernet
 * a 10/100Mbit minimum port
 * 4+ port switch?
 * Storage
 * External flexible storage (through USB?)
 * Internal secure storage for crypto keys and certificates

Single cat5 for power/data/phone
This is possible with the MP01 and the new 24V PSUs, but requires some creative crimping.

On the MP end of the cat5, crimp the RJ45 greens/oranges (1,2,3,6) and brown-solid (8) as usual, but put brown-stripe in one of the blues (4 or 5). Then crimp the blues into the centre pins of the RJ11.

On the phone/power side, use a RJ45/RJ11 double wall socket. Krone power into browns (stripe=positive), greens/oranges as normal, and bridge RJ45 blues with the center pins of the RJ11 socket.

Watchdog
I see several different kinds of failures on OpenWRT routers.

The most common is dropbear (ssh login) failure but the router still responds to ping on wifi and eth. This requires a manual hard reboot and therefore physical access to the router - tough when it's up a mountain. So I have added a cron job to such routers to reboot themselves once day, ensuring that downtime is limited to <24 hours. Unfortunately one never gets to inspect the dmesg from these failures.

The toughest kind of failure to resolve is where the cron hangs too - only option is to go up the mountain (hike planned today for that purpose). This is where an independent watchdog would be handy, and because it is needed most on remote routers, integration into a UPS unit would be helpful.

There are dozens of circuits online for power regulation and lead-acid battery management, but none seem to fit our purpose exactly. What we need is a microcontroller-based PSU with: for power-hungry ATAs, but low enough not to blow other 12VDC devices). linked to charge/discharge cycle so that solar-powered units reboot 8 hours after sunset (i.e. at 3am).
 * 1) Power input of 16-30VDC (to cater for AC PSUs, solar and wind).
 * 2) Up-regulated power output of 16VDC (high enough to carry far enough
 * 1) Cycle (14.4-15V) and float (13.5-13.8V) charging.
 * 2) 3A regulators for max 45W of battery charging.
 * 3) Temperature sensor for optimal charge voltage (important for lead-acid).
 * 4) Load cut at 50% battery discharge.
 * 5) Timer that cuts power every 24 hours for 10 seconds, preferably

Such a PSU should be able to operate without a battery too, so that it just acts as a conditioner and cycler for mains-connected routers. UPS becomes as easy as connecting a battery. Stick to lead-acid - it's ubiquitous and inexpensive compared to nickel & lithium, whose only advantage is with portability.

Regarding solar, leave MPPT and other fancy solar tricks - spend money on looking after the battery rather than drawing max power from panel.

Such a microcontroller-based power unit could power any 12V-<=6W installation, not just MPs, so it would be a useful unit on its own.

Modular design
I agree with the abovementioned concepts for MP v2. Only weatherproof the WiFi units - they're the only ones that need to go outside, and then VT can use any current or future WiFi hardware.

Have a box inside with new Atheros SoC and: 1. RJ45 connections with 10/100 ethernet switch on the greens/oranges and 16V PoE on the blues/browns as per MP and Ubiquity. Power unit can plug into any of them to feed all other attached devices. 2. USB ports for storage and other serial comms. 3. Analogue I/O for apps described already and a host of others.

VoIP I/O can take the form of:
 * 1) IP phone
 * 2) USB phone
 * 3) Separate PoE-linked ATA.

So to summarize proposed modules:
 * 1) VT box.
 * 2) Power module.
 * 3) IP ATA module.

All connected with RJ45 so only cat5 cable required for installation (can make up 3cm long cat5 cables and the system becomes like lego).

I have attached a pics of 4 solar stations (almost) ready for deployment in the mountains around our village. Nanos unfortunately, as the serial port is used to communicate with a VHF spectrometer that will be looking for tracking collars on our local baboons. However these stations will also act as high site relays for the SWUG mesh (including possibly to the next village), which is slowly becoming a MP network. Specs are: between rocks, so only a few hours of direct sun a day. I have also run the power load through the cat5 to the panel on the greens, with panel input on the other wires. This will cause the router to go down if the panel is disconnected. Combined with camouflage and regular ping, these are the best anti-theft measures I can think of.
 * 1) IP65 weatherproof boxes.
 * 2) Solsum Steca 6.6f solar regulators.
 * 3) 18AH lead-acid batteries.
 * 4) 2W Nanostations.
 * 5) 2W VHF-RS232 spectrometers.
 * 6) 35W panels - overspec for load, but I plan to hide the panels
 * 1) Home-made VHF dipoles.

In the meantime, my head is buzzing with MP01 IP address-less, phone number only, DTMF configured firmware for 4000 nodes, duplicate address detection and a one page manual. I don't want to install another mesh without it. Hopefully I find a week in December to finish it off.

Suggestion from Dave Duchesneau
NEXT-GEN MP NEEDS

1. With regard to memory/NOR capacity, I suggest getting the maximum capacity supported by the selected SoC (64 MB of RAM and 16 MB NOR isn't exactly overkill, but should be adequate).

2. I don't see a WATCHDOG timer listed, but I view that as super-important, so the MP can reboot itself if it hangs or stops communicating.

3. The spec indicates OTP memory for calibration data, but doesn't indicate if any OTP storage is available for encryption keys. A low-cost tamper-proof or tamper-resistant chip for private key storage is essential for survivable networks that are crypto-secure. It costs very little to get it onto a board at the design stage, but a lot as an add-on.

---

4. A real-time clock (RTC) device may be essential for time-based security and communications protocols (which we expect to implement to some degree).

5. SD or SDHC card slot (needs to be supported by the SoC, or it's own SOC). I can't say how many ways this would be incredibly useful (at least for us).

6. Sound jack (see usage ideas and discussion further below). At the least, this should be an output capable of driving a low-power speaker horn for public address purposes, or the line-in input on a pre-amp or amplifier.

WHY WE LIKE THE SWITCH IN THE NEXT-GEN MP

We really like the next-gen MP's 4/1 or 5-port switch, as it will eliminate our having to procure separate switches for our various configurations.

For us, our most basic emergency network repeater/gateway would include four small-scale devices (MP and similar), linked by one or two switches, and operating in various active/active configurations. Since none of the SoCs in these small devices use ECC memory, they are subject to crashing or hanging due memory errors induced by alpha particles, cosmic radiation, etc. This is no big deal for attended devices or consumer use, but not okay for an unattended emergency network with repeater is hard-to-reach locations. Running an active/active combination greatly reduces the risk of downtime due to a transient failure. It also ensures that a node doesn't go down during software upgrades, either, by staggering the upgrades and ensuring success with one upgrade/update before starting the next. (Having SD cards enables relatively simple fall-back to previous versions, too).

Looking forward, we expect to configure an emergency network repeater/gateway with two or three of the next-gen MPs for mesh communications and two to four R-Pi devices for computation and display (e.g., signage, kiosks, or thin Linux-based PCs). Each R-Pi has 256 MB of RAM and will carry its share of services in an active/active arrangement (along the lines of CARP or U-CARP, or clustered). Batman-adv works great on wired networks, too, so the R-Pi and MP devices will all be running interoperable mesh software, although the R-Pi devices have no wireless or ATA interfaces, and the MPs have no HDMI or GPU.

RELEVANT SOUND JACK USAGE IDEAS (with respect to an Emergency Network)

> One new possibility that has occurred to > me is the integration of a sound jack.

I agree, for multiple reasons, but it would be nice if the jack could handle both audio in and out. In a low-budget setup, configuration could occur via IVR, after which the handset/keypad could be disconnected if desired. Some mesh-connected application possibilities:

1. Mesh-distributed radio, podcasts, etc., including NOAA-type severe-weather information.

2. Public Address (PA) functionality, including locally generated mesh-distributed audible warning/alert/alarm enunciators: "TORNADO SIGHTED! Take Cover!" "WILDFIRE heading our way FAST. EVACUATE IMMEDIATELY toward {safe direction}!" "LIGHTNING STORM IN RANGE! Get out of the water!"

3. Ability to integrate with analog two-way radios, enabling a RAN (radio access network), although bands suitable for transmission may depend on country-specific regulations. A simple use would be monitoring a CB/FRS/GMRS walkie-talkie-style radio or other "citizen's" channel or amateur radio channel (especially FM channels, which are normally quiet, and especially a channel reserved primarily for emergency use). Voice output from the analog radio may be connected to the MP's audio in jack, where it is digitized via a suitable codec, packetized, and forwarded to preconfigured destinations (which presumably are monitoring). For example, a call for help from a cheap FRS (Family Radio Service) walkie-talkie having a 2-mile range could be picked up and transmitted via the mesh, through a gateway, to a responder dispatch location that might be hundreds or even thousands of miles away (no regulations would prohibit this, since it doesn't require keying the transmitter). Ignoring regulatory requirements for the moment, the MP audio output could be used to key the VOX (voice-operated transmit) switch in the walkie-talkie, so that the mesh-connected FRS radio which picked up the call for help could also transmit a reply from the monitoring center. In this scenario, it would be better to have a pair of mesh-connected FRS/GMRS radios, with one configured to continuously scan various channels, and the other configured to transmit a response on a specific channel (the MP's GPIO pins could be used for channel selection). Of course, this kind of setup could be applied to any type of two-way radio, with some being better suited than others, and with varying degrees of regulatory restrictions.

4. Distributed call box/intercom/baby monitor functionality (audio monitoring on an as-authorized basis, for privacy reasons). One node could monitor nodes in multiple or locations, or one location could be monitored by several attendants, or some combination of the above. Intercom functions would just be an extension of this (monitoring could be temporarily enabled by a paging call, for example, which alerts potentially monitored subjects to the "listening" status). Button(s) connected to GPIO pins could eliminate need for handset/keypad.

5. Mesh-connected plug-in headsets (secure, full-duplex group or team communication or intercom functionality, equivalent to a conference call without a telephone plugged into the ATA adapter). This would be more relevant to a *mini* version of the MP, without WAN/LAN ports, etc., since it might be carried on one's person. The RJ-11 would be kept, because some headsets could plug in there. Bluetooth headsets could also work, by plugging a USB mini-dongle into the USB port. Of course, this whole entry (#5) might be obviated by a wired or Bluetooth headset connected to a Serval-equipped Android smartphone.