After monitoring the QRSS beacon for almost a week I noticed something interesting. I had been using Spectran by I2PHD to capture the beacon but have now switched to QRSS VD by AJ4VD which allows me to easily review many hours of collected traces. It seems just after sunrise when the building where the beacon is housed gets heated by the sun the beacon frequency raises by 10-20 Hz and stays there all day and then cools down at night. Click the image below for the details. This is about a one hour segment and starting at 8:40 AM this morning it starts to go up and stabilizes at 9:05 AM.
Saturday, December 19, 2015
Monday, December 14, 2015
40 Meter QRSS Beacon
I have activated a 40 meter QRSS beacon at grid DM24.
This beacon is a retired kit I built a few years ago by Hans Summers G0UPL. It is setup to run off 12 volts and tapped directly to a battery array on solar installation in the Arizona desert. The antenna is a DX80 off center fed dipole with its vertex at 15 feet. The screen shot is the signal at my home QTH (DM03) approximately 300 miles from the beacon. So far it seems to appear about 15 minutes after sunrise and disappear about 45 after sunset.
This beacon is a retired kit I built a few years ago by Hans Summers G0UPL. It is setup to run off 12 volts and tapped directly to a battery array on solar installation in the Arizona desert. The antenna is a DX80 off center fed dipole with its vertex at 15 feet. The screen shot is the signal at my home QTH (DM03) approximately 300 miles from the beacon. So far it seems to appear about 15 minutes after sunrise and disappear about 45 after sunset.
Sunday, December 6, 2015
Double Side Band (DSB) Generation III
I have now built the Si5351 clock generator, attenuators, and Arduino Uno in one metal box and the NE612 mixer in another. This shielding was required because the clock generator was so powerful it was getting into the measurement receiver by radiating it! Here are the tin boxes I used:
Here they are open:
The below image is a screen shot from the 817 Commander tool that has a scanner function which plots the s-meter values over the scanned frequencies. I was feeding the balanced modulator with the carrier and a 4 kHz audio tone. You can see the two side bands and the center carrier. The carrier is in fact below the side bands as I expected. Using my FT-817 as the measurement receiver and using the s-meter measurement method, I was able to confirm the suppressed carrier.
Based on the FT-817 S-meter calibration data I found HERE this is ~ 27 db below the side bands and probably at least 30 db since the s-meter on the 817 is not linear. Next step is the RF amplifier stages to bring the level up to a couple of watts.
Here they are open:
The below image is a screen shot from the 817 Commander tool that has a scanner function which plots the s-meter values over the scanned frequencies. I was feeding the balanced modulator with the carrier and a 4 kHz audio tone. You can see the two side bands and the center carrier. The carrier is in fact below the side bands as I expected. Using my FT-817 as the measurement receiver and using the s-meter measurement method, I was able to confirm the suppressed carrier.
Based on the FT-817 S-meter calibration data I found HERE this is ~ 27 db below the side bands and probably at least 30 db since the s-meter on the 817 is not linear. Next step is the RF amplifier stages to bring the level up to a couple of watts.
Sunday, November 22, 2015
Double Side Band (DSB) Generation II
I made some progress with my NE612 DSB Generator. I built it up in a shielded box and I have observed at least a reduced carrier of 20 db below the side bands now. My problem was with my measurement receiver, it was receiving the radiated carrier! I also have attenuated the Si5351 oscillator separately and not in the same box and then injected it into the NE612. Note the 10 db pad. Next I will try a balancing pot across pins 1 and 2 with the wiper to ground. I should be able to get 30 db of reduced carrier with the NE612. The audio fidelity is very good and I believe this will be able to produce eDSB (Extended Double Side Band).
Sunday, November 15, 2015
Double Side Band (DSB) Generation
In my quest for a simple QRP phone rig, I have been experimenting with Double Side Band (DSB) Generation. Using the Si5351 as a local oscillator I have tried both a high level mixer (passive) and a NE612 (active). Both of these produced DSB but with a carrier higher than expected. This was all done on a open breadboard so I believe I am getting carrier leakage. As you can see in in the HDSDR image below I have a very broad DSB signal.
The other test involved here is the fact that I was using my simple Direct Conversion (DC) receiver from my Prototype Radio experiments. A DC receiver normally can not receive a DSB single because of its wide bandwidth causing it to hear both side bands at once. However in the case above, I am feeding the audio from the DC receiver to HDSDR on my PC. Using the left channel only since the DC receiver does not have a I/Q stereo output (see below the feature in HDSDR).
The other test involved here is the fact that I was using my simple Direct Conversion (DC) receiver from my Prototype Radio experiments. A DC receiver normally can not receive a DSB single because of its wide bandwidth causing it to hear both side bands at once. However in the case above, I am feeding the audio from the DC receiver to HDSDR on my PC. Using the left channel only since the DC receiver does not have a I/Q stereo output (see below the feature in HDSDR).
This method allows the use of a low frequency Intermediate Frequency (IF), in this case 10 kHz allowing the DC receiver with HDSDR to demodulate DSB by receiving either USB or LSB and even ECSS (the DSB feature in HDSDR).
There are other problems with this method like multiple images, however it allows very simple hardware to be used for rigs and I believe two simple DSB transceiver would be able to communicate with each other using this method.
Saturday, October 24, 2015
Enhanced Single Side Band (SSB)
I was interested in enhanced SSB so I used two instances of PowerSDR SR40 across two computers with one in transmit mode and the other in receive. I was able to increase the transmit bandwidth to 6 kHz and the audio was amazing. The connection is just line out stereo to line in stereo. This contains the I/Q data. I experimented with USB, LSB, and AM.
The following is a Design to try
The following is a Design to try
Saturday, October 17, 2015
Tacoma Compass/Temp Gauge
My new truck had a few minor issues. One was that the Electronic Compass/Temp gauge was dead. A quick check on the Internet forums found known issues with this device particularly with a part that lifts off the board due to heat. I disassembled mine and found exactly that issue.
The surface mount resistor had in fact lifted off the board.
I re-soldered the resistor and powered it up and it is working again. Awesome!
The surface mount resistor had in fact lifted off the board.
I re-soldered the resistor and powered it up and it is working again. Awesome!
Sunday, October 4, 2015
Maker Faire
Saturday, September 26, 2015
Payload Field Test
I did some tests from Signal Hill with the tracker. It was picked up both directly and via several digipeaters.
The below log show it picked up directly about 6 miles from the hill and over 30 miles away by a digipeater on Keller Peak.
The below log show it picked up directly about 6 miles from the hill and over 30 miles away by a digipeater on Keller Peak.
1:Fm WA6PZB-15 To APOT30 Via WIDE2-1 [11:35:56R]
/183531h3348.05N/11809.66W>114/000/A=000377 08.8V 110F
1:Fm WA6PZB-15 To APOT30 Via KELLER*,WIDE2* [11:35:57R]
/183531h3348.05N/11809.66W>114/000/A=000377 08.8V 110F
Sunday, September 13, 2015
Hamcon 2015
I attended Hamcon 2015 on Saturday and enjoyed all the talks. The turn out was great. Here are the talks that I attended:
- VOA - Delano DL-8 (saving a 250KW transmitter)
- Smarter than Smartphone: Meet Karena (The future of HTs?)
- Present and Future of County Affiliated Disaster Amateur Radio
- ARRL Lab
- AREDN Amateur Radio Emergency Data Network (what BBHN has become)
- HF Antenna Design (a simple 3 band vertical design)
- Maker Faire: Bring Ham Radio to the Community
Saturday, September 5, 2015
Vehicle On-board Diagnostics (OBD 2)
I got an Check Engine light on my car recently and was thinking about getting one of those handheld diagnostic code scanners to read the On-board Diagnostic information (OBD) and decided to do a quick look for other options instead of a dedicated device. I searched for Arduino shields, USB/serial cables, etc. I found this cool device for about $20 on Amazon --> HERE. It is a WiFi OBD 2 dongle that plugs right into your car's OBD jack and is powered directly off the car connector as well.
The device basically acts like a WiFi Access Point. So you have several options for connecting to it. I first got a free iPhone app called FourStroke which worked just fine. The device gives your phone an IP address of 192.168.0.11 and the dongle is at 192.168.0.10 on port 35000.
FourStroke works pretty good for a free app but has several features that need to be paid for to work, so I did more research and found the DashCommand App that is feature packed but cost $10.
Both of these apps are able to pull my fault codes and even clear the check engine light, but I was wondering how this thing works and discovered about the ELM327 that the dongle uses. The ELM327 translates the OBD2 protocol to serial. The serial data is presented on a TCP port via the WiFi network. With this knowledge I used the trusty Virtual Serial Port Emulator software VSPE that I have used in my other projects and setup a COM port connector (COM4 <--> COM7) and a TCP client on 192.168.0.10 port 35000 connected to COM7.
Then using Putty I connected to COM4 and bingo, I was at the ELM327 command prompt! Believe it or not ELM327 uses AT commands like the old serial MODEMs. The below output from Putty is showing the output after I issued an "AT DP" to Display Protocol. In this case it returned ISO 9141-2.
Wikipedia says this protocol has an asynchronous serial data rate of 10.4 kbit/s. It is somewhat similar to RS-232; however, the signal levels are different, and communications happens on a single, bidirectional line without additional handshake signals. ISO 9141-2 is primarily used in Chrysler, European, and Asian vehicles.
This makes sense since my car is a Toyota. The ELM327 abstracts all of the above for you. I found the basic commands to read codes from the car at this site --> HERE. The first command 010C is a request for the RPM. The last two bytes are the RPM (0A EC) in hex. 0AEC hex is 2796 in decimal and needs to be divided by 4 to get the actual RPM which is 699 rpm. I queried it again and got 0B0F which is 707 rpm. I performed the other exercises from the site above and everything worked as expected.
The device basically acts like a WiFi Access Point. So you have several options for connecting to it. I first got a free iPhone app called FourStroke which worked just fine. The device gives your phone an IP address of 192.168.0.11 and the dongle is at 192.168.0.10 on port 35000.
FourStroke works pretty good for a free app but has several features that need to be paid for to work, so I did more research and found the DashCommand App that is feature packed but cost $10.
Both of these apps are able to pull my fault codes and even clear the check engine light, but I was wondering how this thing works and discovered about the ELM327 that the dongle uses. The ELM327 translates the OBD2 protocol to serial. The serial data is presented on a TCP port via the WiFi network. With this knowledge I used the trusty Virtual Serial Port Emulator software VSPE that I have used in my other projects and setup a COM port connector (COM4 <--> COM7) and a TCP client on 192.168.0.10 port 35000 connected to COM7.
Then using Putty I connected to COM4 and bingo, I was at the ELM327 command prompt! Believe it or not ELM327 uses AT commands like the old serial MODEMs. The below output from Putty is showing the output after I issued an "AT DP" to Display Protocol. In this case it returned ISO 9141-2.
Wikipedia says this protocol has an asynchronous serial data rate of 10.4 kbit/s. It is somewhat similar to RS-232; however, the signal levels are different, and communications happens on a single, bidirectional line without additional handshake signals. ISO 9141-2 is primarily used in Chrysler, European, and Asian vehicles.
This makes sense since my car is a Toyota. The ELM327 abstracts all of the above for you. I found the basic commands to read codes from the car at this site --> HERE. The first command 010C is a request for the RPM. The last two bytes are the RPM (0A EC) in hex. 0AEC hex is 2796 in decimal and needs to be divided by 4 to get the actual RPM which is 699 rpm. I queried it again and got 0B0F which is 707 rpm. I performed the other exercises from the site above and everything worked as expected.
The dongle came with some software on a small CD that was a bit questionable, but I did try one called ScanMaster-ELM. I ran it on a WinXP SP3 laptop because it is old software, however it did work and I was able to pull codes like the iPhone apps and clear codes, etc. It did hang a few times so it may be buggy and or touchy in how it is used..
Now that I know that OBD/ELM327 works using a polling method, I should be able to code up a scanner to do anything I need and perhaps do specific logging for analysis, etc.
This was much more fun than just buying a dedicated OBD scanner.
73, Dan
Saturday, August 22, 2015
Balloon Payload Update
The balloon tracker payload is almost finished. I integrated the DC/DC converter for the transmitter power and tested the whole package running on it own with the battery pack and the dipole antenna.
The antenna mounts to the box with plastic bolts. I am running it on alkaline batteries now but will be using lithium batteries for the flight. The total weight is 315 grams - Battery (160g), Tracker (75g), Box (70g), and antenna (10g).
I placed it at about 20 feet and I was picked up by other digipeaters:
The antenna mounts to the box with plastic bolts. I am running it on alkaline batteries now but will be using lithium batteries for the flight. The total weight is 315 grams - Battery (160g), Tracker (75g), Box (70g), and antenna (10g).
I placed it at about 20 feet and I was picked up by other digipeaters:
2015-08-23 00:59:16 UTC: WA6PZB-15>APOT30,N6EX-1*,qAR,K6CPP:>Ballon Experiment 001 2015-08-23 00:59:16 UTC: WA6PZB-15>APOT30,N6EX-1*,qAR,K6CPP:/005856h3346.60N/11802.42WO012/000/A=000039 09.0V 123F 2015-08-23 01:00:09 UTC: WA6PZB-15>APOT30,N6EX-1*,qAR,W6KL-2:>Ballon Experiment 001 2015-08-23 01:00:09 UTC: WA6PZB-15>APOT30,N6EX-1*,qAR,W6KL-2:/005856h3346.60N/11802.42WO012/000/A=000039 09.0V 123F 2015-08-23 01:00:28 UTC: WA6PZB-15>APOT30,N6EX-1*,qAR,K6CPP:/010017h3346.61N/11802.42WO301/000/A=000037 09.0V 122F 2015-08-23 01:00:37 UTC: WA6PZB-15>APOT30,N6EX-4*,qAR,K6CPP:/010024h3346.61N/11802.42WO223/000/A=000037 09.0V 122F 2015-08-23 01:01:17 UTC: WA6PZB-15>APOT30,N6EX-4*,qAR,K6CPP:>Ballon Experiment 001 2015-08-23 01:01:18 UTC: WA6PZB-15>APOT30,N6EX-4*,qAR,W6KL-2:/010024h3346.61N/11802.42WO223/000/A=000037 09.0V 122F 2015-08-23 01:02:04 UTC: WA6PZB-15>APOT30,N6EX-4*,qAR,W6KL-2:>Ballon Experiment 001 2015-08-23 01:02:30 UTC: WA6PZB-15>APOT30,N6EX-1*,qAR,K6CPP:/010214h3346.61N/11802.42WO343/000/A=000036 09.0V 119F 2015-08-23 01:03:35 UTC: WA6PZB-15>APOT30,N6EX-1*,qAR,W6KL-2:/010214h3346.61N/11802.42WO343/000/A=000036 09.0V 119F
Wednesday, August 5, 2015
Payload Box
Tuesday, July 28, 2015
Payload Tracker Antenna
Sunday, July 5, 2015
4th of July
Field Day 2015
Field Day went well except for the overcast conditions. I had not planned for this and thought my solar panel would provide me all the power I would need. I need to at least setup an external charge input for my DPN. I operated almost exclusively on 15 meters. I am thinking of being 100% HOMEBREW and QRP next year. Antenna may be a Moxon beam.
Tuesday, June 23, 2015
Field Day Logging
Saturday, June 13, 2015
APRS Balloon Payload 2
A small wood frame has been built for the APRS tracker that will be placed in a foam box. The GPS receiver is mounted at the top of the frame facing up and the transmitter and tracker boards are below. It is sitting on top of the battery pack. The plan is to use lithium AA batteries. The pack is a 6 cells which should deliver 9 volts.
I am working on the dipole antenna that will be mounted to the side of the foam box. I also need to setup a regulator for the transmitter since 9 volts exceeds it's max voltage.
I am working on the dipole antenna that will be mounted to the side of the foam box. I also need to setup a regulator for the transmitter since 9 volts exceeds it's max voltage.
Wednesday, June 10, 2015
APRS Balloon Tracker
This last weekend I lashed up the components for the new APRS balloon tracker. All the items were obtained from ArgentData:
Tracker3 Model T3-Mini
ADS-GM2 GPS Receiver
SRB MX145 Transmitter
With 5 volts running everything and the transmitter connected to a dummy load I had approximately 200 mW output. The T3 audio out was connected directly to the audio in on the transmitter. I have not yet verified the deviation level but I was able to decode with a local receiver. Later I connected the transmitter to my 2 meter ground plane and the tracker was heard on the APRS-IS network and here is the APRS.fi raw log:
Tracker3 Model T3-Mini
ADS-GM2 GPS Receiver
SRB MX145 Transmitter
With 5 volts running everything and the transmitter connected to a dummy load I had approximately 200 mW output. The T3 audio out was connected directly to the audio in on the transmitter. I have not yet verified the deviation level but I was able to decode with a local receiver. Later I connected the transmitter to my 2 meter ground plane and the tracker was heard on the APRS-IS network and here is the APRS.fi raw log:
Next step is build a chassis to mount the boards in the payload box and to verify the deviation level. I have found a great method to measure deviation using a SDR dongle HERE.
Tuesday, May 19, 2015
ADS-GM2 GPS
I received my new GPS module from ArgentData ADS-GM2 that I will be using for a balloon tracker and decided to give it a bench test.
The connections are broken out in two ways. The connections on the left of the board are setup to mate to a DB-9 female or to the right with a 6 pin mini wafer connector. Since I will be using the RS-232 pins I decided to just use the DB-9 side. All the connection I need are on the top of the board so I used a .100 inch header soldered to the top of the board to break out the pins:
2 - RS-232 out
3 - RS-232 in
4 - Power
5 - Ground
Pin 1 is marked on the board as X1. I powered the board with 5 volts and connected my USB to RS-232 adapter to it and was able to see the serial NMEA sentences at 4800 baud on pin 2.
Just for fun I wanted to see the accuracy of this GPS module and had I found an interesting piece of freeware called VisualGPS. The software is designed to take the NMEA data from the GPS for a period of time while it is stationary and produce an analysis of the variations. The following is the analysis after about 12 hours.
It is interesting to see the variance over time. The GPS system is very complex and many calculations are made, both in the GPS module and in the system as a whole via the ground stations and uplinked via the satellite messaging.
The NMEA strings contain position information of the satellites which VisualGPS can also plot:
As well as a coverage plot:
The longer you collect data the more complete the plot will become. This can be useful for evaluating the antenna and the orientation of the antenna.
The connections are broken out in two ways. The connections on the left of the board are setup to mate to a DB-9 female or to the right with a 6 pin mini wafer connector. Since I will be using the RS-232 pins I decided to just use the DB-9 side. All the connection I need are on the top of the board so I used a .100 inch header soldered to the top of the board to break out the pins:
2 - RS-232 out
3 - RS-232 in
4 - Power
5 - Ground
Pin 1 is marked on the board as X1. I powered the board with 5 volts and connected my USB to RS-232 adapter to it and was able to see the serial NMEA sentences at 4800 baud on pin 2.
Just for fun I wanted to see the accuracy of this GPS module and had I found an interesting piece of freeware called VisualGPS. The software is designed to take the NMEA data from the GPS for a period of time while it is stationary and produce an analysis of the variations. The following is the analysis after about 12 hours.
It is interesting to see the variance over time. The GPS system is very complex and many calculations are made, both in the GPS module and in the system as a whole via the ground stations and uplinked via the satellite messaging.
The NMEA strings contain position information of the satellites which VisualGPS can also plot:
As well as a coverage plot:
The longer you collect data the more complete the plot will become. This can be useful for evaluating the antenna and the orientation of the antenna.
Tuesday, May 12, 2015
How to use your Cellphone for voice, video, and chat when cell service is DOWN
After using Linphone from the post HERE , I realized how simple it would be to create a ad hoc phone, video, and messaging network with just a wireless access point and smart phones loaded with the Linphone application. The basic recipe is one wireless access point like an old Linksys and two smartphones with Linphone loaded. The two smartphone will need to join the Linksys wireless network. The Linksys does not need to be connected to the Internet. The two smartphone will basically just be on the local wireless network offered by the Linksys. The only catch is you do need to know each others IP addresses to communicate. Once you know that you can call each other by just using the SIP address in the form - name@IPAddress:5060 the name can actually be anything (e.g. Bill@192.168.1.50:5060).
What this means is that if you take a old Linksys Access Point and run it off a battery and maybe put it up on a mast in the air say 20 to 30 feet up you could provide voice, video, and chat capabilities to a parking lot full of people. This may be useful for an emergency situation, etc.
If the WiFi setup included a registration process, perhaps a directory could be populated so people joining the network would "see" the other members.
I am looking at a Raspberry Pi image that can run as an Access Point, this would then allow a web server to be part of the network. Also the Rasp Pi is small and light and should use less power than a old Linksys wireless router, will need to verify.
What this means is that if you take a old Linksys Access Point and run it off a battery and maybe put it up on a mast in the air say 20 to 30 feet up you could provide voice, video, and chat capabilities to a parking lot full of people. This may be useful for an emergency situation, etc.
If the WiFi setup included a registration process, perhaps a directory could be populated so people joining the network would "see" the other members.
I am looking at a Raspberry Pi image that can run as an Access Point, this would then allow a web server to be part of the network. Also the Rasp Pi is small and light and should use less power than a old Linksys wireless router, will need to verify.
Tuesday, May 5, 2015
Teensy 3.1 APRS
I came across an interesting post in the Teensy PJRC Forum about using a Teensy 3.1 as a APRS tracker. This is based on the trackuino code, but since the Teensy 3.1 has a 12 bit DAC no external hardware is needed thanks to this modified code.
I wanted to try out the code posted HERE but it took a few steps to get it running in the Arduino IDE so I thought I would share what I did:
I wanted to try out the code posted HERE but it took a few steps to get it running in the Arduino IDE so I thought I would share what I did:
- I took the posted code and placed it in a folder called "Aprs" in the Arduino IDE "libraries" folder.
- I removed the file called "APRSExample.cpp" from that "libraries" folder.
- I also grabbed the Adafruit GPS Library files from HERE and placed them in a folder called "Gps" in the Arduino IDE "libraries" folder.
- Next I started the Arduino IDE and opened a new sketch and pasted the content of the "APRSExample.cpp" into the editor.
- Next I tried to compile it and got a few errors and ended up removing the bottom 10 lines that contain the "int main(void)" section (not valid in Arduino sketches). After that it compiled (cool!).
Since I don't currently have a GPS connected to my Teensy 3.1 and wanted to try it without a GPS so I needed to make a few more changes to the code. Basically I just commented the original "aprs_send" method and substituted my own with fixed values for time, lat/lon, speed, heading, etc. and in the main "loop" commented all the "if" statements out so it would just loop and send every 10 seconds. If this was used the define sections in the code would need to reflect the call sign, ID, etc.
Below is the working code running in my Arduino IDE v1.0.6 and the teensyduino add-on. I hope to further modifiy the code to support other APRS packet types like weather and telemetry.
Below is the working code running in my Arduino IDE v1.0.6 and the teensyduino add-on. I hope to further modifiy the code to support other APRS packet types like weather and telemetry.
/*
aprs-teensy31
=============
Example code for generating APRS
packet "sounds" on the teensy 3.1's DAC pin.
Summary
=======
This code is intended to be used with the Arduino Library
for Teensy 3.1. For simplicity you can use Teensyduino.
aprs.h contains the two function calls you need.
Call aprs_setup with the parameters you want.
Call aprs_send to send a packet.
Note:
=====
It will not return until the entire packet has been sent.
The code is structured as generic C-code with no clases
or object oriented features. It is purely functional in nature anyway.
Acknowledgement
===============
The APRS library is based on code retrieved from the Trackuino project.
This is a hardware/software project designed to use the
Arduino and a Radiometrix HX1 transmitter as a position tracking system.
The code was written by Javier Martin under the same GNU General
Public License.
*/
#include <WProgram.h>
// Note: this example uses my GPS library for the Adafruit Ultimate GPS
// Code located here: https://github.com/rvnash/ultimate_gps_teensy3
#include <GPS.h>
#include <aprs.h>
// APRS Information
#define PTT_PIN 13 // Push to talk pin
// Set your callsign and SSID here. Common values for the SSID are
#define S_CALLSIGN "KC3ARY"
#define S_CALLSIGN_ID 1 // 11 is usually for balloons
// Destination callsign: APRS (with SSID=0) is usually okay.
#define D_CALLSIGN "APRS"
#define D_CALLSIGN_ID 0
// Symbol Table: '/' is primary table '\' is secondary table
#define SYMBOL_TABLE '/'
// Primary Table Symbols: /O=balloon, /-=House, /v=Blue Van, />=Red Car
#define SYMBOL_CHAR 'v'
struct PathAddress addresses[] = {
{(char *)D_CALLSIGN, D_CALLSIGN_ID}, // Destination callsign
{(char *)S_CALLSIGN, S_CALLSIGN_ID}, // Source callsign
{(char *)NULL, 0}, // Digi1 (first digi in the chain)
{(char *)NULL, 0} // Digi2 (second digi in the chain)
};
HardwareSerial &gpsSerial = Serial1;
GPS gps(&gpsSerial,true);
// setup() method runs once, when the sketch starts
void setup()
{
Serial.begin(9600); // For debugging output over the USB port
gps.startSerial(9600);
delay(1000);
gps.setSentencesToReceive(OUTPUT_RMC_GGA);
// Set up the APRS module
aprs_setup(50, // number of preamble flags to send
PTT_PIN, // Use PTT pin
100, // ms to wait after PTT to transmit
0, 0 // No VOX ton
);
}
// Function to broadcast your location
void broadcastLocation(GPS &gps, const char *comment)
{
// If above 5000 feet switch to a single hop path
int nAddresses;
if (gps.altitude > 1500) {
// APRS recomendations for > 5000 feet is:
// Path: WIDE2-1 is acceptable, but no path is preferred.
nAddresses = 3;
addresses[2].callsign = "WIDE2";
addresses[2].ssid = 1;
} else {
// Below 1500 meters use a much more generous path (assuming a mobile station)
// Path is "WIDE1-1,WIDE2-2"
nAddresses = 4;
addresses[2].callsign = "WIDE1";
addresses[2].ssid = 1;
addresses[3].callsign = "WIDE2";
addresses[3].ssid = 2;
}
// For debugging print out the path
Serial.print("APRS(");
Serial.print(nAddresses);
Serial.print("): ");
for (int i=0; i < nAddresses; i++) {
Serial.print(addresses[i].callsign);
Serial.print('-');
Serial.print(addresses[i].ssid);
if (i < nAddresses-1)
Serial.print(',');
}
Serial.print(' ');
Serial.print(SYMBOL_TABLE);
Serial.print(SYMBOL_CHAR);
Serial.println();
// Send the packet
/*
aprs_send(addresses, nAddresses
,gps.day, gps.hour, gps.minute
,gps.latitude, gps.longitude // degrees
,gps.altitude // meters
,gps.heading
,gps.speed
,SYMBOL_TABLE
,SYMBOL_CHAR
,comment);
*/
aprs_send(addresses, nAddresses
,1, 15, 59
,33.47,-118 // degrees
,10 // meters
,0
,0
,SYMBOL_TABLE
,SYMBOL_CHAR
,comment);
}
uint32_t timeOfAPRS = 0;
bool gotGPS = false;
// the loop() methor runs over and over again,
// as long as the board has power
void loop()
{
//if (gps.sentenceAvailable()) gps.parseSentence();
//if (gps.newValuesSinceDataRead()) {
//gotGPS = true; // @TODO: Should really check to see if the location data is still valid
//gps.dataRead();
//Serial.printf("Location: %f, %f altitude %f\n\r",
//gps.latitude, gps.longitude, gps.altitude);
//}
//if (gotGPS && timeOfAPRS + 60000 < millis()) {
broadcastLocation(gps, "Hi Gary N6SER" );
//timeOfAPRS = millis();
delay(10000);
//}
}
Monday, April 27, 2015
APRS & GPS Software
I continue to explore different software packages to aid in balloon payload tracking using APRS.
I came across two applications that may be useful:
The extModem application is a command line tool that implements a software packet modem. What's interesting is that it supports the KISS protocol via a TCP port. I have used SoundModem which is very good but only supports the AGW Packet engine API. With extModem and the Virtual Serial Port Emulator I can connect the modem to APRS applications that use KISS modems over COM ports.
The NMEA GPS application is an iPhone application that allows me to send GPS data to other applications over the local network. In this case I can again use the Virtual Serial Port Emulator to connect my iPhone GPS to legacy APRS applications that need to use a COM port.
Below are some notes of how I connected the extModem and NMEA GPS to UI-View32 using the Virtual Serial Ports:
Here is my Virtual Serial Port Emulator configuration
I came across two applications that may be useful:
The extModem application is a command line tool that implements a software packet modem. What's interesting is that it supports the KISS protocol via a TCP port. I have used SoundModem which is very good but only supports the AGW Packet engine API. With extModem and the Virtual Serial Port Emulator I can connect the modem to APRS applications that use KISS modems over COM ports.
The NMEA GPS application is an iPhone application that allows me to send GPS data to other applications over the local network. In this case I can again use the Virtual Serial Port Emulator to connect my iPhone GPS to legacy APRS applications that need to use a COM port.
Below are some notes of how I connected the extModem and NMEA GPS to UI-View32 using the Virtual Serial Ports:
Here is my Virtual Serial Port Emulator configuration
Sunday, April 19, 2015
VOIP Audio Tools for Ham Radio
I like to operate my FT-817 remotely over my local LAN and have been using IPSound to carry the audio for many years. This has worked great using Ham Radio Deluxe 5.x to control the radio tuning, etc. however I was thinking there must be something out there that will work with my iPad by now since IPSound is a Windows only application.
I figured I would look for a Open Source Voice Over IP (VOIP) application and found one called Linphone. Linphone is one of many SIP telephone applications available. What interesting is I have seen Hams using Wifi Mesh applications like Broadband-Hamnet and connecting ATA phone adapters like a Grandstream HT701 so they can talk over the mesh. They of course are using a analog phone and to dial each other you just use the IP address of each station, but why do that when you can just use a softphone like Linphone. You can setup the contacts and you will not need to remember IP addresses, etc. I guess depending on the analog phones they use with the ATA adapters they could have memories in the phones. The analog phone do make it simpler to use if it were needed in some emergency communication situations.
Anyway, I did successfully get Linphone running on my Windows XP PC that I use to control my FT-817 and another copy on my iPad. The only thing I discovered is that I could not achieve the same audio quality as IPSound. I tried all the Linphone CODECs and the best one was the G722. For standard HF radio use this is fine. There may be better CODECs available as plugins but I have not yet pursued that direction.
Since Linphone is multi-platform it makes it very handy (e.g. Andriod, IOS, Linux, Windows, etc.) There is also a command line mode that I have not tested yet. All in all this seems like a usable solution and I will use it to monitor some of the HF nets for the next few weeks.
I figured I would look for a Open Source Voice Over IP (VOIP) application and found one called Linphone. Linphone is one of many SIP telephone applications available. What interesting is I have seen Hams using Wifi Mesh applications like Broadband-Hamnet and connecting ATA phone adapters like a Grandstream HT701 so they can talk over the mesh. They of course are using a analog phone and to dial each other you just use the IP address of each station, but why do that when you can just use a softphone like Linphone. You can setup the contacts and you will not need to remember IP addresses, etc. I guess depending on the analog phones they use with the ATA adapters they could have memories in the phones. The analog phone do make it simpler to use if it were needed in some emergency communication situations.
Anyway, I did successfully get Linphone running on my Windows XP PC that I use to control my FT-817 and another copy on my iPad. The only thing I discovered is that I could not achieve the same audio quality as IPSound. I tried all the Linphone CODECs and the best one was the G722. For standard HF radio use this is fine. There may be better CODECs available as plugins but I have not yet pursued that direction.
Since Linphone is multi-platform it makes it very handy (e.g. Andriod, IOS, Linux, Windows, etc.) There is also a command line mode that I have not tested yet. All in all this seems like a usable solution and I will use it to monitor some of the HF nets for the next few weeks.
Sunday, April 12, 2015
Balloon Tracking Simulation Experiment
I was thinking about how to prepared for a balloon launch carrying an APRS payload without actually launching a balloon and thought that if the APRS data could be simulated and transmitted from the ground anyone receiving the APRS packet would interpret it as if it where real and coming from a balloon. This would allow us to create a simulated balloon flight profile and then transmit it from the same area it would be flying from but it would not be in the air, but instead from a mobile vehicle. We could have two groups (e.g. one tracking team and one simulated balloon team) go out and exercise the equipment and verify they could recover the payload by succesfully finding the simulated payload. This method should also be picked up via the APRS IGATEs and on the Internet APRS-IS network so the folks supporting us from their home QTH could monitor APRS.fi and track it as well.
I searched the Internet for various solutions and settled on the following:
I searched the Internet for various solutions and settled on the following:
UI-View32 is a very popular APRS applications and I have spent many hours exploring it and I still find new things it can do (like this!). It has the ability to connect a GPS to it via a COM port. When a GPS is connected to UI-View it basically becomes a tracker like you would use in a balloon, but it is running on a PC. The next component is the NMEA Generator. I found the link to this on WA8LMF site which is a great resource for all things APRS. The NMEA Generator is the key and it basically can generate the serial strings that come from a GPS and send them to a COM port. This makes UI-View think it is receiving GPS location data. So now I need to connect the NMEA Generator to UI-View32. To do this I use a Virtual Serial Port emulator. This allows both applications to run on the same PC and talk to each other. The nice feature of the NMEA Generator is its ability to take a .INI file that you have created and drag and drop onto the application (read the docs) and it will load a set of points that you have created for the flight or trip into the generator. See below for a file I created ti simulate a flight. I created the flight profile using real wind data and balloon weights, etc. using Balloon Track for Windows another outstanding application. Balloon Track can export in many formats but I used CSV .because I need Lat, Lon, Altitude, and speed (mind your units!). Then I used Excel to format it to work in the INI file (Note: you need a sequence number D1, D2, D3, etc.)The key thing I discovered was unless you want the NMEA Generator to loop and repeat your data points, the last record should have a blank speed value. In addition, if you don't want the simulated balloon to continue to drift forever on the ground, the second to last speed value should be set to zero '0'.
I did all the experiments connected the APRS-IS and have not transmitted any of the packets on the air which is the next step and the final goal. I will need to see how this setup will run on a 800 Mhz Windows XP laptop.
I did all the experiments connected the APRS-IS and have not transmitted any of the packets on the air which is the next step and the final goal. I will need to see how this setup will run on a 800 Mhz Windows XP laptop.
[Option]
SpeedUnit=0
Version=Ver1.18
EngCharset=0
EngFontName=Arial
EngFontSize=8
JpCharset=1
JpFontName=Tahoma
JpFontSize=8
TrackMax=50
TimeDiff=
MagVari=
MainTop=36
MainLeft=28
[Track]
D1=33.75176235,-118.0567753,85,2
D2=33.75188794,-118.0565514,106,20.37468822
D3=33.75331956,-118.0536856,323,24.08305198
D4=33.75508722,-118.0504115,542,27.7701033
D5=33.75649766,-118.0470814,768,25.93723385
D6=33.75714538,-118.0441726,999,20.37468822
D7=33.757194,-118.0424913,1235,11.10377883
D8=33.75679214,-118.0421775,1478,3.708363756
D9=33.75572611,-118.0429181,1729,9.249596954
D10=33.75412309,-118.0443713,1983,14.81214259
D11=33.75231754,-118.0461303,2246,16.66632447
D12=33.75014851,-118.0479573,2514,18.52050634
D13=33.74745902,-118.0495352,2791,20.37468822
D14=33.74472201,-118.0502351,3075,18.52050634
D15=33.73888334,-118.0503581,3667,18.52050634
D16=33.73346457,-118.048734,4297,16.66632447
D17=33.7281628,-118.0484004,4971,14.81214259
D18=33.72100578,-118.0522323,5694,20.37468822
D19=33.71070127,-118.0585446,6477,27.7701033
D20=33.69364442,-118.0672461,7332,40.74937644
D21=33.66465533,-118.079235,8275,61.12406466
D22=33.62329029,-118.0992921,9329,79.64457101
D23=33.59469352,-118.1175273,9999,90.74834984
D24=33.5864404,-118.1227875,9329,90.74834984
D25=33.57353805,-118.1290326,8275,79.64457101
D26=33.56386113,-118.1330223,7332,61.12406466
D27=33.55781541,-118.1360955,6477,40.74937644
D28=33.55396045,-118.1384479,5694,27.7701033
D29=33.55114968,-118.1399464,4971,20.37468822
D30=33.54897387,-118.1398074,4297,14.81214259
D31=33.54665698,-118.139112,3667,16.66632447
D32=33.54406341,-118.1391638,3075,18.52050634
D33=33.54282553,-118.1394783,2791,18.52050634
D34=33.54158725,-118.1402014,2514,20.37468822
D35=33.54057153,-118.1410532,2246,18.52050634
D36=33.53971191,-118.141887,1983,16.66632447
D37=33.53893682,-118.1425865,1729,14.81214259
D38=33.53841359,-118.1429483,1478,9.249596954
D39=33.53821353,-118.1427921,1235,3.708363756
D40=33.53823878,-118.1419447,999,11.10377883
D41=33.53857184,-118.1404583,768,20.37468822
D42=33.53930566,-118.1387338,542,25.93723385
D43=33.54023695,-118.1370163,323,27.7701033
D44=33.54100122,-118.1354928,106,24.08305198
D45=33.54132354,-118.1349205,7,20.37468822
D46=33.54134483,-118.134878,0,0
D47=33.54134483,-118.134878,0,
[DGPS]
Invalid=,
SPS=,
Thursday, April 9, 2015
Club Balloon Launch (no payload)
Last Saturday was our planned Club Balloon launch. Everything was going very well until we discovered our APRS payload was not working. After we spent more than 2 hours trying to resolve the issue we had to abort, however we had already filled the balloon partially so we ended up just releasing the balloon with no payload attached. Lesson learned was don't start filling the balloon until the complete payload chain is operational!
That lesson cost us a $40 balloon and $60 of helium.
That lesson cost us a $40 balloon and $60 of helium.
Sunday, March 29, 2015
Teensy 3.1 Impressions and the Audio Library
I have been hearing a lot of good things about the Teensy 3.1 development board regarding its use as a SDR platform HERE. It seems like it has a great deal of capability over the the Teensy 2.0 that I have been using. This power is due to it's 32 bit ARM processor. The coolest thing is that it uses the Arduino IDE and nearly all of your sketches will run on it. The Teensy SDR linked above exploits the Teensy 3.1 audio DSP functions and PJRC has created a simple GUI tool to help you create your audio projects easily.
As a simple test after I powered up my Teensy 3.1, I used the audio design tool to define two sine wave sources, mix them together and output them to the on-board DAC. Below is an image of my session with the tool (it is web based or you can download and run locally).
After the design is completed in the tool you just press the RED "Export" button and it will output the code for your sketch. I ended up tailoring mine to generate a Dial Tone and I was blown away how good it sounded! I just took the output of the DAC and feed it directly into a standard PC powered speaker.
You do need to do a little coding since the tool just sets up the streams. The tool generated the code that is between the "// GUItool ..." comments below in the example. I needed to call the audio objects in the "loop()" section which you can figure out from the docs and the examples provided. The comment section at the bottom is when I was playing with other Tel-co sounds (e.g. Busy Signal).
I am very impressed with the Teensy 3.1 platform and intend on replacing my Teensy 2.0 in my Proto Type Radio with it soon and try out some of the audio SDR functions.
Example Code:
As a simple test after I powered up my Teensy 3.1, I used the audio design tool to define two sine wave sources, mix them together and output them to the on-board DAC. Below is an image of my session with the tool (it is web based or you can download and run locally).
After the design is completed in the tool you just press the RED "Export" button and it will output the code for your sketch. I ended up tailoring mine to generate a Dial Tone and I was blown away how good it sounded! I just took the output of the DAC and feed it directly into a standard PC powered speaker.
You do need to do a little coding since the tool just sets up the streams. The tool generated the code that is between the "// GUItool ..." comments below in the example. I needed to call the audio objects in the "loop()" section which you can figure out from the docs and the examples provided. The comment section at the bottom is when I was playing with other Tel-co sounds (e.g. Busy Signal).
I am very impressed with the Teensy 3.1 platform and intend on replacing my Teensy 2.0 in my Proto Type Radio with it soon and try out some of the audio SDR functions.
Example Code:
// Simple Mixer to generate a Dialtone
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
// GUItool: begin automatically generated code
AudioSynthWaveformSine sine1; //xy=183,181
AudioSynthWaveformSine sine2; //xy=192,251
AudioMixer4 mixer1; //xy=392,207
AudioOutputAnalog dac; //xy=591,178
AudioConnection patchCord1(sine1, 0, mixer1, 0);
AudioConnection patchCord2(sine2, 0, mixer1, 1);
AudioConnection patchCord3(mixer1, dac);
// GUItool: end automatically generated code
void setup() {
// Audio connections require memory to work. For more
// detailed information, see the MemoryAndCpuUsage example
AudioMemory(3);
}
void loop() {
sine1.frequency(350); //350
sine1.amplitude(0.1);
sine2.frequency(440);//440
sine2.amplitude(0.1);
//delay(100);
//sine1.amplitude(0);
//sine2.amplitude(0);
//delay(100);
}
Saturday, March 14, 2015
Prototype Radio V - CAT Control with Omni-Rig
I continue to experiment with the CAT control of the Si5351 with the simple DC receiver. I wanted to document the use of Omni-rig that I mentioned in the last post. After Omni-Rig is installed, HDSDR will be able to access the Omni-Rig setup screen below. You just select the rig type, the COM port the Arduino is on, and the baud rate (e.g. we are using 4800, but it can be changed in the code).
The best way to run it is to Sync the LO frequency and then check the sync to/from Omni-Rig as seen below. The you just click on the frequency and type in the frequency you want and press enter. Then you will see the span of frequencies based on your bandwidth setting. To tune around at this point, change the LO not the TUNE frequency. Your offsite will remain fixed based on the setting below. This works well for me at this point. I am able to use 192K sample rate which gives me more than 80 Khz (this is half of the 192 since this is not a true SDR which would center you and give you 80 below and 80 above)
There is a setting that positions the SDR cursor when you tune it. The default is 10000 hz or 10Khz, but you may want to adjust it to the best part of the pass-band. I find that 40khz is the lowest noise part of my pass-band for my setup. I have also been investigating noise issues that are caused by the PC's USB port. I will need to devise some filtering next. In the mean time I have found that placing an "un-powered" USB power block across the DC buss cuts most of the noise. I just use a USB cable that has the power pins broken out to pins plugged into the breadboard and plugged into the power block.
Here is the offsite screen with the default 10khz setting.
The best way to run it is to Sync the LO frequency and then check the sync to/from Omni-Rig as seen below. The you just click on the frequency and type in the frequency you want and press enter. Then you will see the span of frequencies based on your bandwidth setting. To tune around at this point, change the LO not the TUNE frequency. Your offsite will remain fixed based on the setting below. This works well for me at this point. I am able to use 192K sample rate which gives me more than 80 Khz (this is half of the 192 since this is not a true SDR which would center you and give you 80 below and 80 above)
There is a setting that positions the SDR cursor when you tune it. The default is 10000 hz or 10Khz, but you may want to adjust it to the best part of the pass-band. I find that 40khz is the lowest noise part of my pass-band for my setup. I have also been investigating noise issues that are caused by the PC's USB port. I will need to devise some filtering next. In the mean time I have found that placing an "un-powered" USB power block across the DC buss cuts most of the noise. I just use a USB cable that has the power pins broken out to pins plugged into the breadboard and plugged into the power block.
Here is the offsite screen with the default 10khz setting.
Sunday, March 8, 2015
Prototype Radio IV - CAT Control
I mentioned to my friend Gary N6SER how cool it would be to write some code for the Arduino to control the Si5351 via the standard Computer Aided Transceiver (CAT) control. He used Ham Radio Deluxe HRD as his standard platform for testing and picked the Elecraft K2 to model. Here is the programming guide --> HERE. He got a basic sketch running that controlled frequency and Mode (e.g. CW, LSB, USB, etc). I then took his sketch and incorporated the Si5351 library to control the clock module. The idea is to build the simplest radio system and use the Arduino serial port to control it with already existing software that uses the CAT interface. No display is needed, no knobs, switches, etc. the software provides the front panel. The sketch has now been tested on my Prototype Radio with HRD version 5.x, FLRig, Commander, and most exciting - OmniRig with HDSDR. The choice of using the K2 was brilliant because it has one of the simplest command structures. There is more work to be done but it does work. One issue is that the Arduino connected to the computer couples a lot of noise sources into the prototype radio's simple direct conversion receiver. I had no problem tuning around with HDSDR and it controlling the local oscillator (LO) of the Si5351. The OmniRig integration with HDSDR worked great. Below is what the code looks like so far. I do have a simple LCD display on it for debugging purposes only.
1: #include <Wire.h>
2: //#include <Encoder.h>
3: #include "si5351.h"
4: #include <LiquidCrystal_I2C.h> // F Malpartida's NewLiquidCrystal library
5: #define I2C_ADDR 0x20 // Define I2C Address where the PCF8574A is
6: #define BACKLIGHT_PIN 7
7: #define En_pin 4
8: #define Rw_pin 5
9: #define Rs_pin 6
10: #define D4_pin 0
11: #define D5_pin 1
12: #define D6_pin 2
13: #define D7_pin 3
14: LiquidCrystal_I2C lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin);
15: Si5351 clockgen;
16: long int freq = 7040000; // In Hz
17: long int frequency = freq;
18: int mode = 1; //(1=LSB, 2=USB, 3=CW, 6=RTTY, 7=CW-REV, 9=RTTY-REV)
19: String received;
20: String command;
21: String parameter;
22: String sent;
23: const int ledPin = 11;
24: void setup()
25: {
26: // Setup for Ham Radio Deluxe 5.24.0.38
27: // Elecraft K2
28: Serial.begin(4800);
29: lcd.begin (8,2); // initialize the lcd
30: lcd.home();
31: lcd.print("CAT-RMT");
32: lcd.setCursor(0, 1);
33: lcd.print("v1.35");
34: delay(4000);
35: lcd.clear();
36: pinMode(ledPin, OUTPUT);
37: clockgen.init(SI5351_CRYSTAL_LOAD_8PF);
38: // Set CLK0 to output current value with a fixed PLL frequency
39: clockgen.set_pll(SI5351_PLL_FIXED, SI5351_PLLA);
40: clockgen.set_freq(frequency, SI5351_PLL_FIXED, SI5351_CLK0);
41: }
42: void loop()
43: {
44: if(Serial.available() > 0)
45: {
46: received = Serial.readStringUntil(';');
47: received.toUpperCase();
48: received.replace("\n","");
49: command = received.substring(0,2);
50: parameter = received.substring(2,received.length());
51: if (command == "FA")
52: {
53: if (parameter != "")
54: {
55: freq = parameter.toInt();
56: frequency = freq;
57: clockgen.set_freq(frequency, SI5351_PLL_FIXED, SI5351_CLK0);
58: lcd.setCursor(0, 0);
59: lcd.print(frequency);
60: lcd.setCursor(0, 0);
61: }
62: sent = "FA" // Return 11 digit frequency in Hz.
63: + String("00000000000").substring(0,11-(String(freq).length()))
64: + String(freq) + ";";
65: }
66: else if (command == "IF")
67: {
68: sent = "IF" // Return 11 digit frequency in Hz.
69: + String("00000000000").substring(0,11-(String(freq).length()))
70: + String(freq) + String(" ") + "+" + "0000" + "0" + "0" + String(" ") + "00" + "0" + String(mode) + "0" + "0" + "0" + "0" + "01" + String(" ") + ";";
71: }
72: else if (command == "MD")
73: {
74: if (parameter != "")
75: {
76: mode = parameter.toInt();
77: //PrintToTft(String(mode),9);
78: lcd.setCursor(0, 1);
79: lcd.print(String(mode));
80: lcd.setCursor(0, 1);
81: }
82: sent = "MD"
83: + String(mode) + ";";
84: }
85: else if (command == "ID")
86: {
87: sent = "ID"
88: + String("017") + ";";
89: }
90: else if (command == "TX")
91: {
92: digitalWrite(ledPin, HIGH);
93: sent = command
94: + String(parameter) + ";";
95: }
96: else if (command == "RX")
97: {
98: digitalWrite(ledPin, LOW);
99: sent = command
100: + String(parameter) + ";";
101: }
102: else if (command == "SM")
103: {
104: sent = command
105: + String(parameter) + "0010" + ";";
106: }
107: else
108: {
109: sent = command
110: + String(parameter) + ";";
111: }
112: Serial.println(sent);
113: //PrintToTft(sent,5);
114: sent = String("");
115: }
116: }
Saturday, February 28, 2015
PFR-3A Field Tests
Using VMEPT and a Hellschreiber WAV file I set up a beacon to transmit every two minutes with my Yeasu FT-817. Then using a half-wave piece of wire (end-fed) and a counter poise wire, I used the PFR-3A as a receiver with the internal antenna tuner to test NVIS propagation around my QTH in a 10 mile radius.
I was able to successfully decode Hellschreiber in the field using my iPhone app HERE. I also connected a small amplified speaker and recorded the audio and used that with FLDIGI to produce the screen shot above. I had hoped to use the PFR-3A to decode FSQCall but the software is centered on 1000 hz verses the 600 hz center of the PFR-3A CW crystal filter.
Saturday, February 21, 2015
Prototype Radio III - WSPR RX
Using the prototype radio from THIS post I added a simple one stage 2N2222 audio amp and after working out the frequency offset of the Si5351 clock module I was able to get successful WSPR decodes. I am driving the audio from the amp directly into the mic input of the PC and using the WSPR v2.12 software. This new version has a I-Q mode that I am taking advantage of to bring the receiver pass band up in frequency a bit. This is normally used with a SDR like a softrock but it will also work with this simple direct conversion (DC) receiver. I am currently using a Fiq in the software of 3000hz (3Khz). This is to get the pass band out of the lower noise region of the DC receiver (sort of a low IF). I will try higher Fiq settings later to see if there is a difference (default is 12Khz).
This is the circuit I am using. Not shown is the Si5351 clock module and the 10db 50 ohm pad used to feed the VFO input. This circuit with my simple dipole antenna and the WSPR software has achieved decodes of station from 600 to over 3000 km on 30 meters today.
This is the circuit I am using. Not shown is the Si5351 clock module and the 10db 50 ohm pad used to feed the VFO input. This circuit with my simple dipole antenna and the WSPR software has achieved decodes of station from 600 to over 3000 km on 30 meters today.
This is my current Si5351 LO frequency shown below. I have not performed a calibration on my Si5351 yet which would allow the corrected frequency to be displayed (looks like it about 100hz low). This LO of 10.135.500 hz plus the 3khz I-Q mode IF of the WSPR software places me at the equivalent dial frequency of 10.138.700 hz and the WSPR tones begin 1500 hz above that with a frequency of 10.140.100 to 10.140.300 (a 200 hz wide bandwidth).
I continue to be impressed with the Si5351 clock module and this experiment validates its stability. I want to continue to work on this receiver to see how minimal I can make it. This receiver currently has no filtering to speak of outside of the antenna tuner I use to couple to my dipole. I plan to try plug-in band-pass filters and expand it in to a minimal transmitter as well.
Sunday, February 15, 2015
FSQ - Fast Simple QSO (chat) mode for HF and VHF
There is a new chat digital mode that is really slick that I have been testing. It's called FSQ for Fast Simple QSO. You can read all the details on FSQ <--HERE on ZL1BPU/ZL2AFP's web link. This mode has four speeds 6, 4.5, 3 and 2 baud. Sensitivity is believed to be about -13 dB SNR at 6 baud, and -16 dB SNR at 3 baud. That's about 10dB better and several times faster than 12 WPM Morse. The speed setting only effects the transmit speed of the app and when monitoring it will capture any for the four speeds on receive (auto-speed adjust).
The coolest feature is SELCAL. You can have it monitoring on a frequency and it will not print anything unless the message is addressed to your call sign. There are many other features with SELCAL as well including the ability to query another station to get your signal strength, their location, etc. For being a Beta version it works pretty well. I have just been testing "Acoustically Coupled" between two PC across the room so the next step is to try it on the air. It will be interesting to see if this is usable as a QRP NVIS mode. I plan to test it on receive with a 600 Hz CW filter.
The coolest feature is SELCAL. You can have it monitoring on a frequency and it will not print anything unless the message is addressed to your call sign. There are many other features with SELCAL as well including the ability to query another station to get your signal strength, their location, etc. For being a Beta version it works pretty well. I have just been testing "Acoustically Coupled" between two PC across the room so the next step is to try it on the air. It will be interesting to see if this is usable as a QRP NVIS mode. I plan to test it on receive with a 600 Hz CW filter.
Sunday, February 8, 2015
Balloon RDF Transmitter Package
My club W6SCE is planning a balloon launch and I am providing a backup tracking solution. The solution is a Squawkbox 2 packaged in a foamcore box with a dipole antenna made from music wire and a Lithium 9 volt battery. The transmitter draws 60 mA when on so with a 600 mAh battery, thats a good 10 hours since it will be transmitting every 10 secs for 5 seconds.
The completed package weighs just 5 ounces.Here it is hanging in the operating position. The antenna is horizontally polarized which should be fine since we will be using DF antennas.
The completed package weighs just 5 ounces.Here it is hanging in the operating position. The antenna is horizontally polarized which should be fine since we will be using DF antennas.
Tuesday, February 3, 2015
Prototype Radio II
I continued on the proto-board radio modules and constructed the first version of a direct conversion receiver. In the picture item #1 is the LCD I2C display, #2 is the rotary encoder, #3 is the Teensy 2.0, #4 is the SA612 mixer, and #5 is a 10 db attenuator pad for the Si5351 clock module to the right of the teensy. I drove a amplified speaker right from the output of the mixer. This does work and I copied strong CW and SSB signals.
A audio buffer amp is needed and tests will be done with SDR software next weekend.
A audio buffer amp is needed and tests will be done with SDR software next weekend.
Subscribe to:
Posts (Atom)