Monday, January 30, 2017

Looking for ideas for cable and connector parts

I'm currently looking at what to use to build the power cables for the Mesh Extenders.

As previously posted, one end has a D-SUB 25 socket.  The other end needs to have connectors for:

a solar panel and battery (4 pins),
USB socket (to allow charging of phones from Mesh Extender, where power budget allows),
12/24v automotive power

and it also needs to have a little serial EPROM in the cable, so that the cable can tell the Mesh Extender which radio regulatory region it is in.

All of this needs to be fairly weather proof, so that it can ideally last for at least a year in tropical maritime or outback conditions.

It also needs to be as cheap as possible.

I'm looking for ideas for all parts of the cable, to make the cables as fast and cheap to build as possible, while maintaining adequate performance.

My current thinking is leaning towards:

Using half of a http://au.element14.com/videk/1125/lead-rs232-25w-d-skt-skt-5m/dp/1525869 for the D-SUB 25 end, then putting some currently unknown small sealed junction box on the end of that, and having the solar/battery, USB and automotive power plugs (not all may be fitted on all cables) come out the other end of the junction box.  

Those D-SUB connectors have the problem that they are not UV stabilised or IP rated, however.  Are there good simple coatings (like would spraying them with Armor-all be enough) for UV protection?  Would the connector, sitting inside a lip at at the bottom of the Mesh Extender exclude dust and water adequeately (we can at least test that once we have complete hardware units on hand)? Or does anyone know an affordable source of similar cables that are UV stabilised, and ideally, IP66 or similar rated?

For the solar/battery connector, perhaps something like http://www.banggood.com/10Pairs-DC-MaleFemale-4PIN-24AWG-Waterproof-IP65-PVC-LED-Connectors-p-1073265.html?rmmds=buy, which are outrageously cheap, and already come with tails fitted, so soldering them up on a tiny PCB in a junction box would be easy.  They claim to be UV resistant and IP65 rated, although I must confess I have some suspicions given their very low cost.

I currently have no decent leads on a small junction box that can take a fat cable in one end, and some skinny ones out the other, sealing everything in the middle. Something like the things that Telstra use to join phone cables in pits would be a potential solution (not Scotch-locs, but the bigger things).  But I don't know where to source those from (yet).

Friday, January 27, 2017

Mesh Extender 2.0 Exterior and Interior drawings

Just a quick post with some images that have been generated so far during the design process, to give some idea of how the thing will fit together.  The exact dimensions and details are likely to have changed before we produce physical units, but give a clear idea on the concept.

First, from the front:

 Here  you can see the three antenna mounts: 2 for the UHF packet radio, and 1 for the WiFi. The other two bumps are screw bosses, so that you can make your own shade for hot locations to help keep the innards below 70C.  We have included this, because the thermal budget is just not quite there  for full-sun tropical locations, while sticking to only passive cooling, and with everything in an environmentally sealed case (which also traps heat).  Adding some shade fixes this problem.

We are not at this stage designing a shade, as we figure that they can be easily made by users from whatever they have laying around, for example, an old plastic bucket, waxed cardboard box, or even a drink can split open.

From behind:


The main thing to see here is the curved back to make it easier to strap to a tree or pole, and the ribbing to help provide at least a little air-flow between the unit and whatever it is attached to.


From below:
Here you can see the D-SUB 15 utility/IoT and D-SUB 25 power/radio connectors.  Also, below those you can see a couple of round markings which are drill guides in case you want to get ethernet out.  In their default state, they have gortex moisture seals to allow the unit to maintain equal pressure with the outside, without filling with condensation.

The inside of the top:


Here the main feature to see is the notch and paddle to help hold the PCB firmly in place, to minimise the effects of vibration, e.g., if a unit is mounted on a vehicle.

The PCB itself will sit inside, with fly-leads to the antennae, as shown in the remaining images.  Returning to the thermal properties, the main means for heat to exit from the unit is conductance through the antennae connectors.  Not ideal, but when you are making a sealed unit that you don't want to cost thousands of dollars per piece, your options can be rather limited.







Wednesday, January 18, 2017

Testing Mesh Extender 2.0 Build Process with Farouk from INRIA

This week Farouk from INRIA in Lille, France has been visiting, as we discuss the potential for collaboration.  It looks like what we are doing with Serval and the Mesh Extenders at the moment will be a good fit for the needs of a project that they have at the moment.  As a result, we have spent a couple of days making sure that Farouk can replicate our build process, which also gives us confidence for others building firmware images as well, and transferring as much of the necessary know-how as possible before he heads back to France, and then in a just a couple more days, that I head back to Australia.

In this process, we are also trying to document all of the outstanding software and hardware issues for the Mesh Extenders at http://github.com/servalproject/openwrt, so that we can better coordinate our activities, and also hopefully make it easier for others to contribute or replicate our work.

Tuesday, January 17, 2017

Testing the Super-Capacitor

We have included a 1F 5.5V super-capacitor on the new Mesh Extender board.

The idea of this is so that when power is lost, the unit has a couple of seconds to stop writing to the microSD card, and perhaps tidy things up to ensure a clean boot next time.

However, we haven't managed to get it to work properly yet.

The boards have a 20 Ohm resister in-line with the super-cap, so that there is no unmanaged in-rush current when charging the capacitor from empty.

The capacitor takes a few minutes to fully charge to about 4.8V (5V - the voltage of the zener diode that forms part of the power loss detection circuit).

At this point, it should be possible to then remove the power source, and have the unit operate powered solely by the super-capacitor, until its voltage level drops below about 3.3V.

GPIO24 is the line that reads our input-power-available signal (effectively the input power before passing through a zener diode, after which it charges both the super-capacitor, as well as powering the rest of the board.  To test the system, I configured that GPIO line for input, and had a little shell script that sits in a loop reading from it.

root@OpenWrt:/# cd /sys/class/gpio
root@OpenWrt:/sys/class/gpio# echo 24 > export
root@OpenWrt:/sys/class/gpio# cd gpio24
root@OpenWrt:/sys/devices/virtual/gpio/gpio24# while [ true ]; do cat value; don

e
1
1
1
1
1
...

It reports 1 when there is an input power supply (other than USB, which is another little problem we need to solve), and 0 when there is no input power supply, but is running on the super-capacitor.  At least that is the theory.

However, with the 20 Ohm resister, the voltage on the low-side is only about 2.2V, much too low to be useful.  Thus I tried putting a 10 Ohm resister in parallel, dropping the combined resistance to about 6.7 Ohms.  That still wasn't enough.

Then I tried bridging the resister by using a multi-meter in current measuring mode after having already charged the capacitor.  This gives effectively 0 Ohms, and provides an upper bound of what is possible with this super-capacitor.  With that configuration, things were more promising, as I saw u-boot try to boot, but as can be seen, as soon as it tried using the DDR RAM, it would reset, as presumably the DDR RAM draws too much power for the super-cap to sustain the supply above 3.3V:

1
1
1
1
1


*********************************************
*        U-Boot 1.1.4  (Jun  6 2015)        *
*********************************************

AP121 (AR9331) U-Boot for DOMINO v1

DRAM:   

*********************************************
*        U-Boot 1.1.4  (Jun  6 2015)        *
*********************************************

AP121 (AR9331) U-Boot for DOMINO v1

DRAM:

*********************************************
*        U-Boot 1.1.4  (Jun  6 2015)        *
*********************************************

AP121 (AR9331) U-Boot for DOMINO v1

D?

*********************************************
*        U-Boot 1.1.4  (Jun  6 2015)        *
*********************************************

AP121 (AR9331) U-Boot for DOMINO v1


*********************************************
*        U-Boot 1.1.4  (Jun  6 2015)        *
*********************************************

AP121 (AR9331) U-Boot for DOMINO v1
?

*********************************************
*        U-Boot 1.1.4  (Jun  6 2015)        *
*********************************************

AP121 (AR9331) U-Boot for DOMINO v1

?

As can be seen above, there is no line with 0, before it hits the u-boot reboot loop, indicating that the board does not operate on the super-capacitor,  even for just a few milliseconds.

We'll have to think of an appropriate solution to this problem, but first we need to understand the situation more completely.  

Is the capacitor unable to provide enough current for the DDR RAM?

Is the capacitor too small?

Also, only one of three super-capacitors seemed to work.  The other two might have been damaged at some point in the process, but having 2/3 faulty makes me think that we shouldn't be relying on them.

Monday, January 16, 2017

Mesh Extender 2.0 second revision prototype boards

The second revision of the Mesh Extender 2.0 (ME2.0) PCBs have arrived.  These were manufactured at almost miraculous speed by RF Design ahead of the Christmas break.  They contain fixes for three of the main problems we encountered with the first revision, fixing problems with both the ethernet and serial level-converter interfaces, as well as the bootstrap pull-up and pull-down on the Domino Core Atheros 9k module.  Here is the new PCBs:

Ethernet - both ethernet ports now work nicely.  One is capable of giga-bit, but sometimes it only connects at 100mbit/sec.  We need to understand what is going on there.


Serial port - the serial port now works without problem, since we have switched to a well-known MAXIM part, instead of the TI level converter, that although in principle capable of level-converting serial lines, turns out to be much too glitchy in our situation.  Other people have had similar problems.

The pull-up registers are now correctly set, although we did still have a problem with one of them apparently not being pulled up hard enough, so we have had to install a single resister to ensure that the Ath9k knows to boot from the 16MB flash, instead of from its internal ROM.  This resister can be seen in the photo below:


We now also have both D-SUB connectors on the same side of the PCB, but having double checked with the 3D-printed case prototype, they are both on the wrong side now, so we will have to fix that in the next revision:


We are currently working on building firmware images for this board, so that we can test other functions, which I'll report on in a separate post.

OpenWRT doesn't see packages from custom feed

Just a quick post to document a problem we encountered with adding a feed to an OpenWRT build process for the Serval Mesh Extender, and how we fixed it.

We followed the process in https://wiki.openwrt.org/doc/devel/feeds to add a new feed, by:

1. Modifying feeds.conf (copying feeds.conf.default, if required)
2. Running ./scripts/feeds update customfeed, with customfeed replaced with the name of the new feed.
3. Running ./scripts/feeds install -p customfeed,  again with customfeed replaced by the name of the new feed.

However, when we did this, and then ran make menuconfig, our new packages were nowhere to be seen.

We solved this by running the following additional command:

./scripts/feeds install -a customfeed