Field Day 2014 - Test for basic Power Node v.52

During Field Day I utilized my basic Distributed Power Node (DPN) with a very simple firmware load. It is now packaged in a PA60 Ammo-can using a proto-type wooden chassis.

The LCD panel provides the battery voltage reading and the current consumption sampled every 5 seconds. I also implemented a battery low voltage drop off load control. When the battery voltage drops below this preset value the load is disconnected.

I found during Field Day, the 65 watt solar panel handled all my loads while the sun was up. I had just a FT-817 Yaesu radio and a LDG Z-11 tuner. The 10 Ah SLA battery ran about 3 hours past sun down and then dropped the load as designed. However I did find that once the load dropped off the battery voltage came up enough to be above the set point and then re-enabled the load. This was expected but I did not think it would cycle at a 1-2 second rate. The voltage reading will eventually only be part of the drop out routine and will also consider the total amp-hour consumed before dropping loads.

Here is the setup at Field Day. On the far left side of the table is the Power Node. My laptop ran on our group's generator, you can barely see my FT-817 sitting on top the Z-11 to the right of the laptop.

This is the solar panel setup, the mount worked great and I was able to adjust it every hour or so for sun alignment to get max power.

It would have been nice to have the mains battery changer in the the chassis so I could have plugged it into to the generator at night but that is coming in the next revisions.

The wood chassis takes up a lot of room but I think I will still need to go to a bigger ammo-can to hold everything I intend to implement.

Next steps are to design some tests to verify battery capacity using either a known load or adjustable load. I need to get some baseline run-times for the battery.

Mesh Networks

I have been following the progress of the Broadband-Hamnet group for several years. This group has developed and packaged firmware for use on Linksys routers (and now Ubiquiti) to be used as a WiFi mesh node. Because the 13 cm ham band (2.4 Ghz) overlaps with the 2.4 Ghz ISM band, hams can use larger antennas and power in this segment and achieve a high speed, self discovering, self configuring, fault tolerant, wireless computer network over some significant ranges (up to 10 miles with stock hardware with just external antennas).

I acquired several Linksys routers a while back for use with this firmware but had not had an opportunity to try them yet. After a closer inspection I found that only one of the two Linksys devices I had was compatible (WRT54GS v2). I remember that a fellow ham had acquired several Linksys devices also and I asked if he could bring over what he had so we could experiment with a mesh network. It turned out he had a compatible WRT54G v2 device.

After studying the above Broadband-Hamnet site there are several great documents on loading the firmware and setting up the nodes. The GS model already had OpenWRT on it so I used the upgrade file- bbhn-1.0.0-brcm.trx for that one and on the G model the bin file- bbhn-1.0.0-wrt54g.bin was used.

The firmware is very nice. From what I can tell reading their site, this release (version 1) has many improvements. Since this is a mesh network every node must have a unique set of IP addresses. The firmware does this by using the last three hex values of the network interfaces MAC address as your IP address. The full IP address is then formed as 10.x.y.z where x,y,z are the last three hex values of the network interface. These Linksys devices have have three interfaces (Wifi, LAN, and WAN). The Wifi and LAN interfaces are the ones assigned the 10.x.y.z addresses and the WAN interface is reserved for internet gateway use. The firmware sets up a DHCP server on the LAN side and each node has DNS which is distributed across the mesh. The following diagram is the basic mesh network that was built.

As you can see we have three nodes. The third node was actually a OLSR switch software running on a Windows XP laptop. I had found some basic notes HERE on how to do this and after some experimenting with the OLSR switch, it works but lacks some of the features (e.g. DNS) of the Linksys firmware. However it does function as a full mesh node on the Wifi side. I have yet to try hsmm-pi which runs the mesh software on a Raspberry Pi but it is not as nice as just running it on a everyday Windows laptop. This OLSR switch software is not the most current evolution of OLSR that is running in the HSMM firmware but is workable. The nice thing is that on windows, you can bind it to any of the network interfaces and turn it off and on easily so you can switch from a normal client Wifi use to mesh Wifi. This configuration allowed me to test with routing to the internet as well. Any mesh node roaming into this mesh gets internet access provided by the N6SER-100 node. You can also provide many other services (e.g. web, cameras, etc) in this same way and all nodes in the mesh will automatically have access. As an additional exercise a Linksys WAP54 was added to the LAN port of one of the Linksys mesh nodes and this was used to provide access to the mesh network with a standard wifi client, like a smart phone or any computer with a Wifi interface. The HSMM firmware supports a wireless access point mode as well, however this would need two Linksys devices to achieve this and since the WAP54 model that we had could not be loaded with the HSMM firmware it is a better use of hardware since you would want to you use your HSMM Linksys nodes as mesh nodes.

The next step is to use gain antennas and establish a mesh network over a greater distance perhaps 2-3 miles then maybe 10 miles.

More Power Node Solar Panel Tests

I built a simple PVC mount for the 65 watt solar panel now so I have a more stable platform to operate the panel. This mount is quickly adjustable and will allow tracking the sun from sun up to sun down if I want maximum power.

I ran the panel in a fixed direction on Sunday and collected from about 11 AM in the morning (some overcast) to about 7 PM in the evening.

The smooth roll-off is visible in this plot with the PV current showing the potential power of the panel. The beginning is not as smooth due to the early morning clouds.

I did a 60 sample average of the peak PV current to get a better idea of what the actual charge current is and plotted it with GNUPlot.

Power Node Test Run

I had some time on Sunday and was able work out the issue with the INA169 current sensor (it was a software scaling problem not hardware) on the power node.

I connected the power node to my solar panel for about 9 hours and collected the voltage and current sensor measurements. The area where I placed the panel was not in full sun initially when I began collecting and because of houses and walls this area also becomes shaded later in the day. Below is the plot of the data.
The plot can also be viewed on Plot.ly --> HERE. Viewing on Plot.ly will allow zooming in and analyzing the data in greater detail.

 

Several lessons were learned from this test and will help with the further development of the Distributed Power Node design. Here is a quick outline of the lessons learned:

• The solar panels function very differently from a power supply (e.g. switch mode type). The open circuit voltage of the panels is over 20 volts and under load between 19 and 16 volts. The panels can provide about 4 Amps max. If a 19 volt 4 Amp switch mode PS is connected to the charge controller the PS voltage drops to 4.5 volts. If I current limit the PS with 22 ohms of ballast it will charge via the controller but barely.
• The charge controller appears to provide the peak current of the panel when charging (PWM). I was sampling at a 5 sec rate with the Arduino and in the graph you can see the PV current pulses are in the 3000 mA range, turning on and off to keep the battery changed. Since I can see that current I may be able to calculate the potential maximum power the panel could have delivered.
• There is a need to take multiple sample sets and perform a running average to get a more meaningful PV current reading.
• Because of the way the SCC-3 charge controller works a switch mode PS can not be used for node to node power transfers with it as a source. A separate charge controller for the 300 VDC bus will be needed.
• State of Charge (SoC) and power usage calculation seem to be straight forward in firmware. Calculations made from the graph data agree with the Arduino code power usage. The whole run was about 64 Watt-hours with 28 Watt-hours on battery.

The next test will run for several days with varying loads. The load management code will need to be implemented so the battery will not be over discharged.

Grid Frequency Measurements streamed to Xively and Plot.ly

In an effort to measure the local Grid Frequency and ease the analysis of the data, I have been experimenting with some of the cloud-based graphing and plotting services. Pachube was the leader but has now become known as Xively,  another one I stumbled on is Plot.ly which I had used for just basic graphing and discovered they have streaming capabilities. I wanted to capture and plot my grid frequency data so I could look at it anytime via a browser. Both services work well and have benefits. I first used Xively and connected the Arduino via serial (USB) to a laptop running a python script. It would run for hours but then it would crash with a time-out error. It was a klunky setup and tied up a laptop. On both the Xively site and Plot.ly I had seen instructions on using Arduino's using a network interface. There was example code for both the basic Ethernet shield and Wifi shields and boards. A friend had a Seeed Ethernet Shield sold by Radio Shack so I asked to borrow it. The Plot.ly example code worked instantly and was easy to understand so I ran with Plot.ly over the weekend. I was amazed at the update rate. In the example code below it is reading two analog ports and updates every 5 seconds. For the grid monitoring I generated the graph at the top of the post with a 15 second rate. The good news is that these cloud plotting and graphing services are great, the bad news is that the my grid monitoring method is still problematic. I am now planning on trying the method used HERE. This method uses the zero crossings. He has a feed to Xively and he does not show any wild frequency swings like I am getting see his feed --> Desert Home Feed. I also want to measure home power usage via the IR pulse on my SmartMeter.

 #include <Ethernet.h>  
 #include <SPI.h>  
 #include "plotly_streaming_ethernet.h"  
 // Sign up to plotly here: https://plot.ly  
 // View your API key and streamtokens here: https://plot.ly/settings  
 #define nTraces 2  
 // View your tokens here: https://plot.ly/settings  
 // Supply as many tokens as data traces  
 // e.g. if you want to ploty A0 and A1 vs time, supply two tokens  
 char *tokens[nTraces] = {"token_1", "token_2"};  
 // arguments: username, api key, streaming token, filename  
 plotly graph = plotly("username", "apikey", tokens, "test", nTraces);  
 byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };  
 byte my_ip[] = { 199, 168, 1, 177 }; // google will tell you: "public ip address"  
 void startEthernet(){  
   Serial.println("... Initializing ethernet");  
   if(Ethernet.begin(mac) == 0){  
     Serial.println("... Failed to configure Ethernet using DHCP");  
     // no point in carrying on, so do nothing forevermore:  
     // try to congifure using IP address instead of DHCP:  
     Ethernet.begin(mac, my_ip);  
   }  
   Serial.println("... Done initializing ethernet");  
   delay(1000);  
 }  
 void setup() {  
  // Open serial communications and wait for port to open:  
  Serial.begin(9600);  
  while (!Serial) {  
   ; // wait for serial port to connect. Needed for Leonardo only  
  }  
  startEthernet();  
  graph.maxpoints = 5000;  
  graph.fileopt="extend"; // See the "Usage" section in https://github.com/plotly/arduino-api for details  
  bool success;  
  success = graph.init();  
  if(!success){while(true){}}  
  graph.openStream();  
 }  
 unsigned long x;  
 int y;  
 void loop() {  
  graph.plot(millis(), analogRead(A0), tokens[0]);  
  graph.plot(millis(), analogRead(A1), tokens[1]);  
  delay(5000);  
 }