JT65 HF mode

I decided to try JT65 HF. W6CQZ has packaged up Joe Taylor's K1JT JT65A mode in a easy to use program.

I briefly read the ARRL guide HERE, and I was able to make a contact (WE7P - Bruce in Tacoma Washington) in under 5 minutes on 15 meters.

This is not a rag chew mode but uses a very simple set of exchanges, however it makes the best of low power and simple antennas (which I like). I have only worked a few state side contacts so far but I am hearing DX stations too. I also worked another station (N3GTY -  William in Spring Lake North Carolina) on 20 meters.

The other thing that is neat about the JT65 HF client is that everyone running it can be a reverse beacon monitor. I noticed that one of my CQ's was heard in Japan by a stations client setup to report the spots into PSK Reporter.

Crystal Set in storage for the Summer

This last winter I built a simple crystal set radio receiver using oatmeal containers for the inductor forms and a cats whisker assembly along with a couple of variable capacitors. It has been setting on my bench taking up too much room so I thought I would document the build and then store it away. I should  create a chassis or base for it the next time I assemble it. This is the basic schematic.

The antenna was a simple slinky stretched in the attic of the garage, it of course would work better with a larger antenna but my outside dipole is in use for other radio activities. The antenna connection goes to a dual ganged 365 pf variable capacitor (C1) then through a 35 turn inductor wound on the first oatmeal container and then to a cold water pipe ground. The ground is very important for crystal sets. Next I have about 60 turns of wire on the second inductor with taps every 5 to 6 turns. The second inductor is another oat meal container. The two inductors are sitting on top of each other as you can see in this photo. No electrical connection between the two inductors.

Ideally if I set this up again, I will position the inductors horizontally on a wooden rod or something to be able to adjust  the air coupling between the two. The first inductor circuit is the antenna tuner and the second inductor forms the resonate tuning to the desired frequency with capacitor C2. The antenna tuner section could be with a series capacitance like I am using or it could be in parallel depending on the size of the antenna. Some crystal sets let you change all the connection which makes them very versatile. I was using clip leads so I could easily adjust the configuration. My diode detector is a modified MidnightScience unit. It came with a galena crystal, however I found that iron pyrite worked the best for me. I used a 1/2 inch copper pipe cap with adjustment screws to hold the pyrite crystal in place. The chunk I had was much larger than the galena sized holder so I needed to build my own holder.  The pyrite detector is typically twice as loud as the galena with the antenna I use. I have also tested germanium as well and in this set, the pyrite is the best.

With my simple indoor antenna and a good ground, I was able to receive several stations. The strongest were KFI (640 khz) and KNX (1070 khz). Fortunately  these stations had some separation. Two strong stations near each other on a crystal set can be a problem. KNX is actually near a weaker Spanish station that required delicate tuning but with the separate antenna tuning and frequency tuning it did pretty well. The other key to crystal sets are the headphones. I have two pairs of antique high impedance (2000 ohm) magnetic headphones. The ones I used on this set don't look that great but work well. I have also used the small piezo ear pieces but they fail if left connected to the radio for any length of time and in general are not very rugged. I have built many crystal sets over the years but they still bring great enjoyment and fun.

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);  
 }