Flight-Control
S | M | T | W | F | T | S | |
---|---|---|---|---|---|---|---|
44 | 27 27 | 28 28 | 29 29 | 30 30 | 31 31 | 01 01 | 02 |
45 | 03 | 04 | 05 | 06 | 07 | 08 | 09 |
46 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
47 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |
48 | 24 | 25 | 26 | 27 | 28 | 29 | 30 |
|
Hot Projects
S | M | T | W | F | T | S | |
---|---|---|---|---|---|---|---|
44 | 27 27 27 | 28 28 28 | 29 29 29 | 30 30 30 | 31 31 31 | 01 01 01 | 02 02 |
45 | 03 03 | 04 04 | 05 05 | 06 06 | 07 07 | 08 08 | 09 09 |
46 | 10 10 | 11 11 | 12 12 | 13 13 | 14 14 | 15 15 | 16 16 |
47 | 17 17 | 18 18 | 19 19 | 20 20 | 21 21 | 22 22 | 23 23 |
48 | 24 24 | 25 25 | 26 26 | 27 27 | 28 28 | 29 29 | 30 30 |
|
This is an old revision of the document!
This is an early draft proposal for a solid, modular and distributed communication/monitoring system shared and operated by communities (not everyone needs his own equipment in a neighboring area). It will offer services locally for community members and the nodes should be interconnected worldwide to create a global network of free-to-access Communication- & Monitoring-Nodes (CMN).
Each node can be configured for individual needs and available budget. A basic node will only provide connectivity features, a fully equipped node will offer complete communication and RF-/Environmental-Monitoring options (distributed com/weather grid). Ideally, the ATMega, a low-power 4-Port USB Hub Controller and the power converters should be assembled together, on a matching daughterboard, to easily combine the ARM Host and the supporting infrastructure.
After searching a while for a suitable WLAN capable host system the project looked pretty busted since it seemed impossible to find an embedded WLAN system that draws less than 7W. Although 7W might not sound like much, it's the 24/7 operational state that kills the application because it would require at least 50/75W solar panels and big batteries. Even at only 7W, the total power consumption would sum up to 168Wh per day, just for the base system without any modules.
The TP-Link TL-MR3020 by itself consumes a maximum of 1.25W. That totals at 30Wh per day and is, for the moment that is, the perfect choice for an independent, self-sustainable embedded Linux system with built-in WLAN capability. It will be interesting to see, what the RaspberryPi with additional WLAN (USB?) is going to consume, but for now, the MR3020 will be the host of choice.
The following table shows early measurements of the basic TL-MR3020 itself (measuring the 5V DC supply in order to mitigate measurement errors due to AC/DC conversion losses), more measurements with an USB HUB and a HAMA Nano (rtlsdr) will follow soon. The results also show, that the device consumes less power with OpenWRT instead of the original firmware.
Condition | TP-LINK FW | Open-WRT |
---|---|---|
Boot | 150mA | 100mA |
Idle | 125mA | 68mA |
Idle + LAN | 155mA | 108mA |
Idle + WLAN | 125mA | 105mA |
Idle + LAN + WLAN | 155mA | 148mA |
Idle + LAN + WLAN + USB | 210mA | 205mA |
Active Download + LAN + WLAN + USB | 260mA | 255mA |
AP + Monitor + Dump on USB + LAN + WLAN + USB | N/A | 230mA |
The power analysis has shown that the TL-MR3020 is indeed a very suitable platform for this approach since it's within the realm of a solar or wind powered system. Although probably many nodes can/will have access to grid power, the goal of this design should be to draw as little power as possible to keep remote/independent deployment as an option and to make it more attractive for people to deploy a node connected to their grid, since the costs won't be a significant factor.
The only major drawback of the TL-MR3020 is the lack of an external antenna connector, this however can be easily hacked in a couple of simple steps and takes less than 15 minutes. The OpenWRT-Wiki for the TL-MR3020 has a good manual on how to open the case, it worked well here.
Although it appears as if the AR9330 has two symmetric antenna outputs on-board and the TL-MR3020 has two etched antennas on the PCB, the route to Antenna1 is actually going to Antenna2. The route originally going to Antenna2 is only partly equipped (probably termination) and not connected to any antenna.
The lack of available datasheets for the AR9330 made this a guess and test hack and although the first approach (see below) worked for us, it unfortunately introduced EM related problems for some other people. This is the revisited hack, using a PCB edge RP-SMA connector to either use an antenna directly or connect better coax cable with less loss to the antenna. You should try to get these types of connectors, specifically designed to be attached to the side/edge of a PCB:
Of course there is also an example for a pigtail as well.
HOWTO:
Unsolder the pigtail and re-solder a 0-Ohm resistor at J4 or create a solder bridge.
Cut/file the edge of the PCB as shown in the image. Make sure that there is no connection left between the two golden strips at the edge.
Solder the center of RG-174 (or the like) coax cable to the left pad (connected to C43 - see Image) and the braid/shield of the coax to the right strip (GND).
Solder the center pin (round) to the left pad (connected to C43 - see Image) and the right pin of the connector to the right pad (GND).
Use hot glue or something like it to fix the cable/connector right in front of the soldered points to prevent the pads from breaking off the PCB due to lift forces from the cable. If you want to use the original case, drill a hole for the RP-SMA connector to stick out.
Special thanks go to cosmo, for donating this device as a guinea pig to make this hack possible.
If anyone has the datasheets and could share some insight on the AR9330's antenna configuration, to enable the 2nd antenna for MIMO/Diversity, please drop a note.
There have been reports of EM related damage to MR3020 routers that have been hacked the way shown below. It seems that the cut off capacitors after J4 were put there for EM protection rather than matching the antenna. Please follow the method shown above to have proper EM protection for your router's external antenna. The following images are only left as a reference for now
Combined with a cheap USB DVB-T Stick like the HAMA Nano or any other Elonics E4000/RTL2832 based device or better yet an OsmoSDR, the node can offer the raw IQ datastream (maybe even as IPv6 multicast) so that anyone can connect his local GNURadio instance to remote control and source the stream from any distant node. This would also allow more software nerds to hack on SDR software who don't want or can't get the hardware locally.
WMO guidelines
40EUR
http://www.mikrocontroller.net/mc-project/Pages/Projekte/Wetterstation/sensors/SHT75/SHT75.html http://www.mikrocontroller.net/topic/145736#1705005
WMO guidelines
DS18S20
WMO guidelines
DS18S20
Absolute Pressure
Bosch BMP086 High Precision Sensor
Anemometer
Radius | 68mm |
Cup-Diameter | 30mm |
Cup-Depth | 15mm |
Shaft Diameter | 4mm |
Arrow-Fin
Length | 225mm |
Dist-Tip-to-Center | 90mm |
Dist-Center-to-Vane-End | 135mm |
Cup-Diameter | 48mm |
Cup-Height | 28mm |
Shaft Diameter | 4mm |
(fast response)
Conventional heated Rain Detection sensor
Alternative new Rain Detection sensor
In time the heated sensor should be replaced by a new type of rain detection sensor that matches the following points:
Having the ability to freely access a global network of distributed ionizing radiation sensors will help to identify areas with elevated radiation levels in case of accidents, catastrophes or natural disasters. This is another step to free ourselves from corporate/governmental media spinning.
Humans will have to continue to use dangerous substances which - if handled poorly - may have devastating effects on the environment habitable to us and of course are also very harmful to our bodies if we come into direct contact. Unfortunately, most of them we simply can't see, touch, hear or smell, which makes them somewhat unreal to our primitive brain when it comes to assessing danger.
Accidents like the Three Mile Island and catastrophes like Chernobyl and Fukushima have shown that official numbers for the radiation levels always seem to be tweaked/faked, to keep people calm.
The following alpha/beta/gamma geiger-müller tubes have been obtained and tested:
The pigi was designed in such a universal way, that it can be used for Argus as well. It creates the required high voltage for the tubes and inverts the counting impulses of the tube into falling edges, captured by interrupt driven software on the sensor controller.
According to WMO guidelines, the external Environmental Monitoring Station (EMS) has to be placed at a specific minimum distance (see WMO guidelines) from any structure that might influence the measurement results (especially wind/temperature). Therefore the unit has to be equipped with its own solar power supply. The following calculations will be a first estimate to design the system at 12V nominal voltage with a 1-day reserve (i.e. no sun at all):
As of now it seems impossible to me to predict the average power consumption. I can only assume that the base consumption level will have to cover the uC and the fan, the uC will consume 20mA worst case, the fan about 40-50mA, the sensors may not exceed 5mA altogether. The unpredictable part is rain, because the rain detector must heat the plate up, when it's raining and will draw significantly more power (and the sun isn't shining when it rains, so all heating power will be drawn from the battery. My best avg. guess (and slightly skewed downwards in favor of “do it anyways”) will be an average power consumption of about 150mA :) Alternatively it would be wise to come up with a new, reliable scheme for fast and accurate low power rain detection that won't need to burn energy (evaporating the water on the sensors surface in order to detect “no more rain” more quickly) for its basic mode of operation.
Estimated average Power consumption for 24h operation:
<x 14>12V * 150mA = 1.8W * 24h \approx 44Wh + 10% Losses \approx 50Wh</x>
Calculation for 1-day reserve:
<x 14>50Wh + 30% reserve margin \approx 65Wh</x>
Estimated Battery capacity:
Due to the cyclic nature of this system, the battery must not be drained more than 50% of its capacity, in order to get at least 800-1k cycles out of it. The goal should be at least 3 years here - batteries take up a lot of resources to get produced - so one should consider giving them a long life. The estimated capacity (6Ah) has to be doubled to 12Ah to accommodate this.
<x 14>{65Wh}/{12V} \approx 6Ah * 2 = 12Ah</x>
Solar panel estimation:
<x 14>30Wp * 4h = 120Wh</x>
So, a 30Wp panel should cover the system easily, I got lucky and shot a new mono 30Wp Panel for about 30Eur at ebay, so there should be plenty of capacity for extensions.
In order to get familiar with MPPT battery charge controller I plan to build an ATmega based controller to handle peak power tracking to suck every mW of obtainable energy out of it. → Fork Subproject
Basic MPPT Algorithm:
void FindMPP(void) { PWM++; newpower = rawW; if(newpower == oldpower){ PWM = PWM-INC; } if(newpower > oldpower && direction == UP && PWM < MAX){ PWM = PWM+INC; } else if(newpower > oldpower && direction == DOWN && PWM > MIN){ PWM = PWM-INC; } if(newpower < oldpower && direction == UP){ PWM = PWM-INC; direction = DOWN; } else if(newpower < oldpower && direction == DOWN){ PWM = PWM+INC; direction = UP; } oldpower = newpower; }
Based on LM-2672M5.0 (1A Simple Switcher Buck Converter) with >90% efficiency.
Supply for MR3020 Wireless LAN Node
For ATmega and Sensors
Atmega 328p
Fuses: low=0xFF high=0xD9
read fuses: avrdude -pm328p -cavrisp2 -Pusb -v -U hfuse:r:-:i write fueses: avrdude -p m328p -c stk500v2 -P /dev/ttyUSB0 -v -U lfuse:w:0xFF:m